text:
localPlayerEyePosition is not used

https://github.com/danielkrupinski/Osiris/blob/5c639663cf15f1632a0b0c490b3ea5f29e1c388c/Osiris/Hacks/Aimbot.cpp#L175
https://github.com/danielkrupinski/Osiris/blob/master/Osiris/Hacks/Aimbot.cpp#L182

Wot. You say it's not used but also link to the line exactly where it IS used.. ???
And even if it wasn't used, it's just a pointer; the value would still be used by the game in memory so there's no performance impact by just creating a reference to it.
there's no real reason to create a new issue for this.

Apologise, I should have described the issue (more of a minor annoyance) better.
localPlayerEyePosition is declared as a variable on line 146 but only used on line 163.
localPlayer->getEyePosition() is later called on line 175 and 182 instead of using localPlayerEyePosition.

Apologise, I should have described the issue (more of a minor annoyance) better.
localPlayerEyePosition is declared as a variable on line 146 but only used on line 163.
localPlayer->getEyePosition() is later called on line 175 and 182 instead of using localPlayerEyePosition.

Right, I see.
It might be better off just removing the variable and using getEyePosition() in both calculations, as it takes my machine around 10ms (when debugging at the same time) to iterate the bones list meaning the second time calculateRelativeAngle() is used, the eye position is out of date, which you may not want with an aimbot especially. But overall, yes, a very minor issue hehe


text:
🛑 PSE - Pagos is down

In 07bb834, PSE - Pagos (https://portal.psepagos.com.co/inicio) was down:

HTTP code: 0
Response time: 0 ms

Resolved: PSE - Pagos is back up in d92289a after 333 days, 12 hours, 38 minutes.

source: gharchive/issue

repo: danielqb/status

license: MIT

license_type: permissive

license_source: github-api


text:
Accent not supported

Hello Daniel,
I've implemented your Keyboard Kit library for my Custom Keyboard extension. I'm happy to integrate your library.
Now I want to achieve keyboard accent support for my custom keyboard accent. How can I achieve this?
Please help me out.
Thanks and Regards.

Hi! This is a duplicate of https://github.com/danielsaidi/KeyboardKit/issues/182 so let's continue the discussions there. 👍

authors: danielsaidi jinilp

repo: danielsaidi/KeyboardKit

license: mit

license_source: bigquery


text:
Working with ember-concurrency

Hello,
Is it possible to get ember-data-change-tracker to work with ember-concurrency?
The main issue I'm having is my route model attempts to load data with:
import Route from '@ember/routing/route';
import { task } from 'ember-concurrency';
export default Route.extend({
  model: function (){
    return {
      blog: this.get('blogTask').perform()
    };
  },
  blogTask: task(function *(){
    let blog = yield this.get('store').queryRecord('blog', {today:true});
    return blog;
  });
});

And then my template (via ember-concurrency) can render:
{{
input
    value=model.blog.value.name
    type="text"
    name="name"
    placeholder="Description"
}}

Am I missing something very obvious here?

@dpigera  not sure what you are talking about since you are not even showing that you are using change tracker .. just that you have problem with ember concurrency .. me puzzled .. going to close this since it does not seem to relate to change tracker but feel free to open it again if you can show it does or explain more

authors: danielspaniel dpigera

repo: danielspaniel/ember-data-change-tracker


text:
Cannot read property '_super' of undefined with Ember 2.10.0

We're seeing a large number of our tests fail in Ember 2.10.0 which don't in Ember 2.9.0.
Here is a dummy app which demonstrates the issue:
https://github.com/GavinJoyce/glammer/pull/10
Ember 2.9.0:

Ember 2.10.0:

Here are the stack traces:
Ember 2.9.0:

Ember 2.10.0:

The test failure happens with both Ember Data 2.9.0 and Ember Data 2.10.0:

Ok .. let me bump up to ember 2.10.0 and see what I can find

Thanks @danielspaniel. I'll continue to dig into it from my side too

Some chatter on #dev-ember:

Very odd.. I get no issues on my acceptance tests, only component tests.  Oddly, on another repo ember 2.10.0 my component tests are fine ( using ember-mocha ) . This is puzzler.  Must be some version of qunit ( or something else )  as well ( that makes difference )  because we are seeing different results for same ember/data versions.

@danielspaniel so after digging in with @GavinJoyce it appears that it could be a combination of using the EmbeddedRecordsMixin with the RESTAdapter and the JSONSerializer.
The comments property on the post model is a hasMany of the comment model. The comment model has a custom serializer  which uses the EmbeddedRecordsMixin. If you remove that mixin it works as expected.

I've tried to reproduce it in the Factory Guy tests but having trouble currently, possibly due to the way the shared-adapter-tests are set up.

Ok .. that makes sense .. because that was an ember-data failure .. is that considered an illegal procedure? ( EmbeddedRecordsMixin with JSON serializer ) ..  I think so .. but wonder how you can work around that. you could switch to RestAdapter/RestSerializer and pass the root in the json payload ... that would be the best for long term sanity.
I made special tests just for you with that combination or RESTAdapter/JSONSerializer and you're right, there is special hokus pokus in the testing which might be masking this (ember-data bug ).
Let me know what your thoughts are on what direction your going to take.  I vote for long term sanity. But I don't know exactly whey you are doing that combination of Adapter/Serializer so I can't say for sure that some quick fix might be in order.

Looking at the Ember Data docs it appears that combination is supported https://guides.emberjs.com/v2.9.0/models/customizing-serializers/#toc_embeddedrecordmixin
The example code given is:
import DS from 'ember-data';

export default DS.JSONSerializer.extend(DS.EmbeddedRecordsMixin, {
  attrs: {
    authors: { embedded: 'always' }
  }
});

The reason we use this combination is to continue to use an endpoint format which we were using with Ember Model.

Ok .. great .. glad to be wrong about that ..
let me know if you think there is something I can do to help.

@danielspaniel this seems to happen to DS.RESTSerializer too:
export default DS.RESTSerializer.extend({
  keyForRelationship() {
    console.log('keyForRelationship');
    return this._super(...arguments);
  }
});

Ooo .. interesting .. that is actually good news because it's not whacky edge case. Just plain broken.

Changing this from:
return attrName || keyFn(attribute, kind);
to
return attrName || keyFn.call(this, attribute, kind);
seems to fix it.
I'm going to test if something changed between ember versions next

Oh .. great .. glad to be wrong about that too .. that it was not ember-data bug .. and it's something in factory guy that is triggering that

It looks like it may be a framework bug: https://github.com/GavinJoyce/glammer/pull/11

that is true ( about the this scope being lost ) , the code I have should have barfed long ago.
There must have been something ember was doing to cover it or
you were doing that actually used the serializer function and then it barfed.  ??
Just a thought.

you were doing something recently that actually used the serializer function and then it barfed

Something changes between 2.9 and 2.10. rwjblue and mixonic are trying to discover what caused the change. Although the new behaviour is correct, I don't believe that it was a conscious decision.

Here's a twiddle: https://ember-twiddle.com/ac831005599534deac030080835456e0?openFiles=controllers.application.js%2C

wow .. talk about obscure whacky issue.  Glad you / they uncovered the cause. Nice twiddle by the way .. pretty slick.

I think the test would be to just override serializer method to  force the barfing  .. will try it out later today

@danielspaniel thanks, a test would be great. I'm not familiar with ember-data-factory-guy so that would be a big help

working on it now

fixed in https://github.com/danielspaniel/ember-data-factory-guy/releases/tag/v2.9.4

It looks like some console.logs slipped in: https://github.com/danielspaniel/ember-data-factory-guy/commit/c6d4ed0cbbd6889f10fb60739f4b938b3393c20f

I've a PR to remove them here https://github.com/danielspaniel/ember-data-factory-guy/pull/262

authors: GavinJoyce danielspaniel patocallaghan

repo: danielspaniel/ember-data-factory-guy


text:
[Question] Is there a reason that all linear layers except output layers do not use bias term?

Hi Danijar,
I was wondering if it's on purpose that all intermediate layers do not use bias terms except for output layers. Additionally, all output layers use uniform initialisation, is this also intended? The following is not so important but if you are interested, here is the config parameters that each layer is using:
{'_path': 'agent/wm/rssm/img_out', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/rssm/img_stats', '_submodules': {}, '_units': (1024,), '_act': <function get_act.<locals>.<lambda> at 0x7f783823f820>, '_norm': 'none', '_bias': True, '_outscale': 1.0, '_outnorm': False, '_winit': 'uniform', '_fan': 'avg'}
Tracing train function.
{'_path': 'agent/wm/enc/mlp/h0', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/enc/mlp/h1', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/enc/mlp/h2', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/enc/mlp/h3', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/enc/mlp/h4', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/rssm/img_in', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/rssm/gru', '_submodules': {}, '_units': (3072,), '_act': <function get_act.<locals>.<lambda> at 0x7f77f1fbc9d0>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/rssm/obs_out', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/rssm/obs_stats', '_submodules': {}, '_units': (1024,), '_act': <function get_act.<locals>.<lambda> at 0x7f77ec723280>, '_norm': 'none', '_bias': True, '_outscale': 1.0, '_outnorm': False, '_winit': 'uniform', '_fan': 'avg'}
{'_path': 'agent/wm/dec/mlp/h0', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/dec/mlp/h1', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/dec/mlp/h2', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/dec/mlp/h3', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/dec/mlp/h4', '_submodules': {}, '_units': (1024,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/dec/mlp/dist_vector/out', '_submodules': {}, '_units': (4,), '_act': <function get_act.<locals>.<lambda> at 0x7f77ec723ca0>, '_norm': 'none', '_bias': True, '_outscale': 1.0, '_outnorm': False, '_winit': 'uniform', '_fan': 'avg'}
{'_path': 'agent/wm/rew/h0', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/rew/h1', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/rew/h2', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/rew/dist_out/out', '_submodules': {}, '_units': (255,), '_act': <function get_act.<locals>.<lambda> at 0x7f77ec5e4790>, '_norm': 'none', '_bias': True, '_outscale': 0.0, '_outnorm': False, '_winit': 'uniform', '_fan': 'avg'}
{'_path': 'agent/wm/cont/h0', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/cont/h1', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/cont/h2', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/wm/cont/dist_out/out', '_submodules': {}, '_units': (1,), '_act': <function get_act.<locals>.<lambda> at 0x7f77ec6faee0>, '_norm': 'none', '_bias': True, '_outscale': 1.0, '_outnorm': False, '_winit': 'uniform', '_fan': 'avg'}
Optimizer model_opt has 24,004,356 variables.
{'_path': 'agent/task_behavior/ac/actor/h0', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/task_behavior/ac/actor/h1', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/task_behavior/ac/actor/h2', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/task_behavior/ac/actor/dist_out/out', '_submodules': {}, '_units': (2,), '_act': <function get_act.<locals>.<lambda> at 0x7f77e40c61f0>, '_norm': 'none', '_bias': True, '_outscale': 1.0, '_outnorm': False, '_winit': 'uniform', '_fan': 'avg'}
{'_path': 'agent/task_behavior/critic/net/h0', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/task_behavior/critic/net/h1', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/task_behavior/critic/net/h2', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/task_behavior/critic/net/dist_out/out', '_submodules': {}, '_units': (255,), '_act': <function get_act.<locals>.<lambda> at 0x7f77c8694550>, '_norm': 'none', '_bias': True, '_outscale': 0.0, '_outnorm': False, '_winit': 'uniform', '_fan': 'avg'}
Optimizer actor_opt has 2,135,042 variables.
{'_path': 'agent/task_behavior/critic/slow/h0', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/task_behavior/critic/slow/h1', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/task_behavior/critic/slow/h2', '_submodules': {}, '_units': (640,), '_act': <PjitFunction of <function silu at 0x7f822c97bc10>>, '_norm': 'layer', '_bias': False, '_outscale': 1.0, '_outnorm': False, '_winit': 'normal', '_fan': 'avg'}
{'_path': 'agent/task_behavior/critic/slow/dist_out/out', '_submodules': {}, '_units': (255,), '_act': <function get_act.<locals>.<lambda> at 0x7f77b85914c0>, '_norm': 'none', '_bias': True, '_outscale': 0.0, '_outnorm': False, '_winit': 'uniform', '_fan': 'avg'}

I disabled the bias terms because they are followed by the normalization layer anyways. But the biases would still have an effect, so it could be interesting to see if it makes a difference. Do you have any intuitions for that?

That sounds like a reasonable explanation :)

authors: EdanToledo danijar


text:
Game crashing :/

My games crashes everytime I open it with globed. I only have globed, custom keybinds and the node ids mods turned on. Here is the crashlog:
2024-02-12_14-09-04.log

just curious, does this still happen on the latest version of geode and globed? this is a really strange crash and the crashlog doesn't help me much in resolving the issue

closing due to no response, if this happens again on the latest version please attach a crashlog


text:
Enhancement: Add Google Gemini Context Caching

What features would you like to see added?
Google has launched Context Caching recently to its Gemini products. This significantly reduces the cost of queries where there are long contexts. One of the ways that we use LibreChat internally is that we feed it our documentation (using the Files sidebar for RAG), and ask questions. Since the entire context of the documentation is fairly stable, it would be great to pay lower costs for it through caching.
More details
Context Caching is implemented by providing an expiry date, so this would need to be added somehow. I think it would be best by giving each file an option to cache through the File Manager modal.
Which components are impacted by your request?
General
Pictures
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

also anthropic added the same feature yesterday

also anthropic added the same feature yesterday

Thanks, I am aware. Given that this is a totally different feature/provider, a new issue is in order: https://github.com/danny-avila/LibreChat/issues/3661

authors: danny-avila fret423 tfriedel

repo: danny-avila/LibreChat


text:
Sync user guide

A first draft on adding a guid to syncing the user object in case it was updated outside of Pow.

Cool, this is a great subject for a guide! I think I've some ideas for how to refactor the code. I would definitely just resync in the update_plan/2 call rather than use session to resync in the plug later. It would not be a plug, but it would be much cleaner, contained and best of all, explicit.
This comment I wrote a while ago highlights the plug handling I had in mind, which is simply to reassign by calling Pow.Plug.assign_current_user/3: https://github.com/danschultzer/pow/issues/93#issuecomment-464770426
This way you just add plug :reload_user to the actions/controllers where you need the user to be completely fresh. I think showing these various ways of handling synced user struct would make this guide great.
Also, I think there's an important point that needs to be made in that the app shouldn't really depend on any cached objects (like credentials cache) if the object is expected to be as in the DB. Hence the plug example I wrote above that simply loads the user on each request. The credentials cache is most of all a convenience to keep the app flow lean, and developers can add on top of that as needed. Your example is still good though, just important to let developers know when this is a good idea (e.g. in this case it makes great sense if you would show the current plan users are on but it would be problematic if it's used to authorize users for certain actions for that plan).
I hope these thoughts can be helpful, and I appreciate a lot your help to improve Pow, thanks! 😄

Yeah I thought of explicitly updating it in the controller but I wanted to have an app wide solution for easily requiring the reload of a user. And I didn't want to do it on every request. But your point about the authorisation is really good, didn't think of that 😄
How about adding an extension to Pow for this that can support both reloading on every request or on demand?
Something like:
plug PowReloadUser.Plug.Reload on: :demand
plug PowReloadUser.Plug.Reload on: :every_request
And thanks a lot to you for this great package. I'm learning a lot from your code and from playing around with it! 👍

Hmm, I think it may be too small to justify as an extension, better to have that plug in a guide.
You can DRY it up and make it very easy to work with explicitly:
defmodule MyAppWeb.PowHelper do
  def sync_user(conn, user) do
    config = Pow.Plug.fetch_config(conn)
    plug   = Pow.Plug.get_mod(config)

    plug.do_create(conn, user, config)
  end
end

defmodule MyAppWeb do
  # ...

  def controller do
    quote do
      use Phoenix.Controller, namespace: MyAppWeb

      # ...
      import MyAppWeb.PowHelper
    end
  end

  # ...
end

alias MyAppWeb.PowHelper

# ...

def update_plan(conn, %{"plan" => plan}) do
   case Users.update_plan(conn.assigns.current_user, plan) do
     {:ok, user} ->
       conn
       |> sync_user(user)
       |> put_flash(:info, "Plan updated successfully.")
       |> redirect(to: Routes.profile_path(conn, :show))

     {:error, %Ecto.Changeset{} = changeset} ->
       render(conn, "plan.html", changeset: changeset)
   end
 end

I think this is even less code than adding a plug :smile:

I was moving, but finally got back to this. Just updated the guide with the above considerations. Let me know what you think, if it's good for you then this can be merged 🚀

Looks really good, thanks a lot for making it so clear! 😀

I've invited you to collaborate in the repo. Now you can just open up PR's here instead of in your fork 😄

Thank you very much, hope I can continue to help out 😄

source: gharchive/pull-request

authors: danschultzer humancopy

repo: danschultzer/pow


text:
Brew Tap throws exception

Description
Brew oddly is writing to the Error output when tapping a new cask... I may need a keg for this one...
Tapped 1 cask and 1 formula (31 files, 1.6MB).
   at Xappium.Tools.Brew.ExecuteInternal(Action`1 configure, CancellationToken cancellationToken) in /_/src/Xappium.Cli/Tools/Brew.cs:line 70
   at Xappium.Tools.Brew.InstallAppleSimUtils(CancellationToken cancellationToken) in /_/src/Xappium.Cli/Tools/Brew.cs:line 34
   at Xunit.Record.ExceptionAsync(Func`1 testCode) in C:\Dev\xunit\xunit\src\xunit.core\Record.cs:line 77
  Stack Trace:
     at Xappium.Cli.Tests.Tools.BrewTests.InstallsAppleSimUtils() in /_/tests/Xappium.Cli.Tests/Tests/Tools/BrewTests.cs:line 21

the only way to eliminate Brew from not returning an exit code of 1 after tapping a keg is to run:
git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask fetch --unshallow
brew update

Since these are very expensive and time consuming tasks.. this isn't really something that the tool should do. If someone wants to do it, a brew-update.sh has been added to the base of the repo.


text:
Mutually Exclusive wiki entry

Right now the Mutually Exclusive wiki page is blank.
This is what I propose as the first version. This is based on the existing section in the readme.io site and based on my conversation with @danthorpe.
Mutually Exclusive
A condition can assert whether its operation should be evaluated with mutual exclusion of other operations. This can be very handy for stopping operations from executing at the same time.
For example, if our application presents a modal alert, by executing this in the context of an operation with a mutually exclusive condition, we will prevent any other modal alert from being presented. Given the nature of event based applications this would otherwise be quite tricky. With Operations this can be done like this:
let alert = AlertOperation(presentAlertFrom: viewController)
alert.title = NSLocalizedString("Hello World", comment: "Hello World")
queue.addOperation(alert)

AlertOperation adds a mutually exclusive condition to itself during its initializer.
If your operation runs in isolation, it might be more beneficial to add it to its own queue which has a maxConcurrentOperationCount set to 1. If your operation runs  as a part of a group of operations (using either GroupOperation or simply queuing up multiple operations at the same time), then using mutual exclusion makes more sense.

Note: mutual exclusion does not stop subsequent operations from running. The operation will run once the mutually exclusive blocking operation in front of it finishes.

Implementation
To add mutual exclusion to your own operation you’ll need to create an enum which will be used to define the mutual exclusion. Name it based on the type of operation you’ll be performing.
public enum CoreDataWork { }

Then in your operation, add a condition for mutual exclusion:
self.addCondition(MutuallyExclusive<CoreDataWork>)

If you are going to use this mutual exclusion in multiple operations it might be useful to create a typealias for this mutual exclusion:
public typealias CoreDataExclusive = MutuallyExclusive<CoreDataWork>

Then you can add it to your operation with:
self.addCondition(CoreDataExclusive())

Warning
You can cause a deadlock in your program if you add the same exclusion on a group operation and one of it's children.

Done - https://github.com/danthorpe/Operations/wiki/Mutual-Exclusion
Thanks @ryanjm!

authors: danthorpe ryanjm

repo: danthorpe/Operations


text:
Update extension compatible project

@JamieWhite - this is initial work to fix #182.

Current coverage is 74.29%

Merging #184 into development will not affect coverage as of ff8ef15

@@            development    #184   diff @@
===========================================
  Files                51      51
  Stmts              3240    3240
  Branches              0       0
  Methods               0
===========================================
  Hit                2407    2407
  Partial               0       0
  Missed              833     833

Review entire Coverage Diff as of ff8ef15

Powered by Codecov. Updated on successful CI builds.

authors: codecov-io danthorpe


text:
Because flutter_form_builder 4.0.2 depends on intl ^0.16.1 and no versions of flutter_form_builder match >4.0.2 <5.0.0, flutter_form_builder ^4.0.2 requires intl ^0.16.1.

Because flutter_form_builder 4.0.2 depends on intl ^0.16.1 and no versions of flutter_form_builder match >4.0.2 <5.0.0, flutter_form_builder ^4.0.2 requires intl ^0.16.1.
Can someone help me fix this error please?
dependency_overrides:
intl: ^0.17.0-nullsafety.2
I later did this but the error is still coming as:
Because myapp depends on dependency_overrides from unknown source "intl", version solving failed.
pub get failed (1; Because myapp depends on dependency_overrides from unknown source "intl", version solving failed.)

Duplicates #634

Duplicates #634

@awhitford  I don't get you
can you explain further ?

@awhitford  I don't get you
can you explain further ?


text:
657 DaphneLib implement indexing

This PR closes #657  and makes right and left indexing available on matrices in DaphneLib.
Features:

Use right indexing to access specific slices or indexes of a matrix
Assign a value to  specific slices or indexes of a matrix using left indexing

Changes:

Script-level test cases are added in test/api/python/, ensuring that execution works as expected.
Add __getitem__ and __setitem__ built-in functions for matrices in DaphneLib.
Update the DaphneLib document in  doc\DaphneLib\Overview.md  to add indexing.
Update OperationNode in src\api\python\daphne\operator\operation_node.py to generate the special DaphneDSL syntax for left indexing

Thank @pdamme for your assistance.
To fix the problem related to the left indexing, I have made some changes based on your approach as below:

Add a new attribute consumer_list to OperationNode class to store consumers of the Node
Add a new method update_node_in_input_list to OperationNode class to update the current node in unnamed_input_nodes
In __setitem__, replace all occurrences of the current DAG node in the unnamed parameters of the consumers of the current DAG node, with the newly created copy node

repo: daphne-eu/daphne


text:
Add name template

Description
This adds a name property to the template which shows up in yaml and json outputs of list command.
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #1204
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Extended the documentation

@mukundansundar Should we try to enforce uniqueness on the run file name ?

authors: mukundansundar pravinpushkar

repo: dapr/cli


text:
Missing component in components directory does NOT cause error message nor exception in a gRPC service

In what area(s)?

/area runtime

/area operator
/area placement
/area docs
/area test-and-release

What version of Dapr?

1.0.0

Output of git describe --dirty

Expected Behavior

With a gRPC service, when a pubsub component is missing from the .dapr/components directory and that missing pubsub component is used by a service subscribing to events and specifying that the missing component be used, an error message should show up on the console or log that clearly states the pubsub component is MISSING.
In other words, when my service software subscribes to a pubsub component that is not present, Dapr needs to generate an error message at least.
Even better would be a way to throw an exception in the service software stating that the component subscribed to is not present.  An exception would immediately  bring attention to the issue, while a mere console error message may not be so visible.
Note that at least when using the .NET SDK with gRPC services, that attempting to publish an event to a missing pubsub component does cause an exception in the service code.  For example:
Dapr.DaprException: Publish operation failed: the Dapr endpoint indicated a failure. See InnerException for details.				 ---> Grpc.Core.RpcException: Status(StatusCode="InvalidArgument", Detail="pubsub svs-pubsub-asbtopic not found")
Actual Behavior

When a pubsub component is missing and is subscribed to by a gRPC service, Dapr says nothing to indicate anything is wrong.  This means a  subscribing service  can be happily running for days with the operators thinking all is OK, yet it is not receiving messages and there is no indication anything is wrong.
Here is the output when I had previously removed 2 of the 3 pubsub components from the components directory, but kept the subscription registrations to all 3 in the service code.  There is no indication of anything wrong:
You're up and running! Dapr logs will appear here.
time="2021-03-06T14:16:38.2572424-05:00" level=info msg="app is subscribed to the following topics: [svcADemoEvents1] through pubsub=pubsub" app_id=serviceB instance=A-GeorgeXPS1 scope=dapr.runtime type=log ver=1.0.0
time="2021-03-06T14:16:38.2582381-05:00" level=info msg="app is subscribed to the following topics: [svcADemoEvents1] through pubsub=svs-pubsub-asbtopic" app_id=serviceB instance=A-GeorgeXPS1 scope=dapr.runtime type=log ver=1.0.0
time="2021-03-06T14:16:38.2582381-05:00" level=info msg="app is subscribed to the following topics: [svcADemoEvents1] through pubsub=svs-pubsub-envvarsecrets-asbtopic" app_id=serviceB instance=A-GeorgeXPS1 scope=dapr.runtime type=log ver=1.0.0
The latter 2 pubsub components had been removed from components directory, even though the subscription code remained in the service as shown below:
   public override Task<ListTopicSubscriptionsResponse> ListTopicSubscriptions(Empty request, ServerCallContext context)
    {
        var result = new ListTopicSubscriptionsResponse();
        try
        {
            result.Subscriptions.Add(new TopicSubscription
            {
                // Used with supplied default Redis pubsub component.
                PubsubName = NamesOfQueuesNPubSubs.PubSubDefaultDaprComponent,
                Topic = NamesOfQueuesNPubSubs.ServiceADemoEvents1Topic
            });
            result.Subscriptions.Add(new TopicSubscription
            {
                PubsubName = NamesOfQueuesNPubSubs.PubSubAzServiceBusComponent,
                Topic = NamesOfQueuesNPubSubs.ServiceADemoEvents1Topic
            });
            result.Subscriptions.Add(new TopicSubscription
            {
                PubsubName = NamesOfQueuesNPubSubs.PubSubAzServiceBusEnvVarSecretsComponent,
                Topic = NamesOfQueuesNPubSubs.ServiceADemoEvents1Topic
            });
        }
        catch (Exception ex)
        {
            m_Logger.LogError($"** ServiceB.ListTopicSubscriptions() threw exception ex={ex}");
            throw;
        }
        return Task.FromResult(result);
    }

Note that the above code did not cause an exception.
Steps to Reproduce the Problem

With a gRPC service in the AppCallback interface implementation, subscribe to one or more topics using the default pubsub component.  Then test it to make sure the subscription actually receives and processes published events.  Then stop the gRPC service.  Next remove the pubsub.yaml component from the .dapr/components directory.  Restart the gRPC service and you will see that it successfully subscribes to the topic, and says so, even though the component implementing the subscription is gone and will not work.
Release Note

RELEASE NOTE:

This is confirmed behavior:
from cloudevents.sdk.event import v1
from dapr.ext.grpc import App

import json

app = App()

@app.subscribe(pubsub_name='pubsub_foo', topic='TOPIC_A')
def mytopic(event: v1.Event) -> None:
    data = json.loads(event.Data())
    print(f'Subscriber received: id={data["id"]}, message="{data["message"]}", content_type="{event.content_type}"',flush=True)

app.run(50051)

dapr run --app-id python-subscriber --app-protocol grpc --app-port 50051 python3 subscriber.py

INFO[0000] Initialized name resolution to mdns           app_id=python-subscriber instance=DESKTOP-VT2HV7S.corp.microsoft.com scope=dapr.runtime type=log ver=1.2.2
INFO[0000] component loaded. name: pubsub, type: pubsub.mqtt/v1  app_id=python-subscriber instance=DESKTOP-VT2HV7S.corp.microsoft.com scope=dapr.runtime type=log ver=1.2.2
INFO[0000] waiting for all outstanding components to be processed  app_id=python-subscriber instance=DESKTOP-VT2HV7S.corp.microsoft.com scope=dapr.runtime type=log ver=1.2.2
INFO[0000] component loaded. name: statestore, type: state.redis/v1  app_id=python-subscriber instance=DESKTOP-VT2HV7S.corp.microsoft.com scope=dapr.runtime type=log ver=1.2.2
...
INFO[0000] app is subscribed to the following topics: [TOPIC_A] through pubsub=pubsub_foo  app_id=python-subscriber instance=DESKTOP-VT2HV7S.corp.microsoft.com scope=dapr.runtime type=log ver=1.2.2

We can definitely log an error for this case. We'd have to think about how to surface this for the app.

Surfacing an error would significantly decrease the debug time for this. Sent from Mail for Windows 10 From: Charlie StanleySent: Thursday, July 1, 2021 7:26 PMTo: dapr/daprCc: georgestevens99; AuthorSubject: Re: [dapr/dapr] Missing component in components directory does NOT cause error message nor exception in a gRPC service (#2895) We can definitely log an error for this case. We'd have to think about how to surface this for the app.—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

repo: dapr/dapr


text:
Sidecar Injector doesn't work if Dapr is installed in a namespace other than default

In what area(s)?

/area runtime
Describe the feature
Allow DAPR to be installed in a non-default namepace.
dapr init --kubernetes installs Dapr in the current kubernetes context. So if the context is set to another namespace other than default it does install however the injector doesn't work as the mutating webhook points to a service in the default namespace.

@patnaikshekhar Please install dapr with helm chart to install dapr in the different namespace.

Hey @patnaikshekhar, dapr init --kubernetes doesn't yet support non-default namespaces.
For uses with non default namespaces, see the suggestion from @youngbupark.
This issue makes it clear we need to document this limitation in the docs for the Dapr CLI.

Thanks @youngbupark @yaron2. Will close this once a statement has been added to the docs.

See also https://github.com/dapr/dapr/issues/656

@patnaikshekhar pls close, docs are updated

authors: RicardoNiepel msfussell patnaikshekhar yaron2 youngbupark


text:
Generate presubmit coverage report using CodeCov

Description
Generate presubmit coverage report using CodeCov GitHub action.
Issue reference
Please reference the issue this PR will close: #2069
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[ ] Created/updated tests
[x] Unit tests passing
[x] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

/ok-to-test

Add badge to readme
[![codecov](https://codecov.io/gh/dapr/dapr/branch/master/graph/badge.svg)](https://codecov.io/gh/dapr/dapr)

Add badge to readme
[![codecov](https://codecov.io/gh/dapr/dapr/branch/master/graph/badge.svg)](https://codecov.io/gh/dapr/dapr)

@mchmarny Done! Thanks

@youngbupark I just made some change in the Markdown file (moving Cov badge to the same location with other badges). Can you please take another look? Thanks!

authors: mchmarny tcnghia


text:
fix readme.md

if http.ServeMux already exists Use NewServiceWithMux

flx readme.md

fix eventHandler

fix readme.md

flx grpc readme.md

flx grpc readme.md

repo: dapr/go-sdk


text:
cannot submit block by stratum

Hi,
When daemon detects possible fork and you have this error message:
Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues.

stratum server cannot submit block:
rpc error with daemon instance 0 when submitting block with submitblock {"code":-2,"message":"Safe mode: Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues."}

There was a fork on the network a few days ago due to a difference of opinion between V10 and V11. The V11 caught an invalid masternode payment and refused to take it, after that there was a fork which resulted in some miners getting this error. The fork has sense been resolved and the network looks very healthy now.

I don't think it's solved. Experiencing v11 fork and stuck time to time.

authors: darkcoinproject feeleep75 miningpoolhub

repo: darkcoin/darkcoin


text:
播放音乐没有声音

本地用mpg123一切正常。
log：
➜  ~ tail -f ~/.netease-musicbox/musicbox.log
################################################################################
2018-02-04 23:10:55,272 - WARNING - NEMbox.ui:36: Qt dbus module is not installed.
2018-02-04 23:10:55,273 - WARNING - NEMbox.ui:37: Osdlyrics is not available.
2018-02-04 23:10:55,316 - WARNING - NEMbox.osdlyrics:28: PyQt4 module not installed.
2018-02-04 23:10:55,317 - WARNING - NEMbox.osdlyrics:29: Osdlyrics Not Available.
################################################################################
2018-02-04 23:15:26,896 - WARNING - NEMbox.ui:36: Qt dbus module is not installed.
2018-02-04 23:15:26,896 - WARNING - NEMbox.ui:37: Osdlyrics is not available.
2018-02-04 23:15:26,907 - WARNING - NEMbox.osdlyrics:28: PyQt4 module not installed.
2018-02-04 23:15:26,908 - WARNING - NEMbox.osdlyrics:29: Osdlyrics Not Available.

原因似乎出在这里。
fid都是0

我也是这个错误

日志中这个错误只是：Warning，并不会对播放有什么影响。
能否提供下列信息
系统版本：
musicbox 版本：
播放什么歌曲：

我的已经好了，有声音了

请问是如何解决的？ @MinSnake

我的也是播放没有声音，mpg123正常
tail -f ~/.netease-musicbox/musicbox.log
2018-07-31 10:31:25,174 - WARNING - NEMbox.osdlyrics:27: Osdlyrics Not Available.
################################################################################
2018-07-31 11:22:29,526 - WARNING - NEMbox.osdlyrics:26: PyQt4 module not installed.
2018-07-31 11:22:29,526 - WARNING - NEMbox.osdlyrics:27: Osdlyrics Not Available.

同上，没有声音，没报错，log也只是些警告

同上....
mpg123 播放本地音乐 ok

log 中也没看到有什么异常

同上

本地播放不了，少了驱动好像，怎么处理呢？mac 系统的
mpg123 -o pulse /Users/alongso_pro/Music/QQ音乐/file.mp3
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.25.13; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
[src/libout123/module.c:133] error: Failed to open module pulse.
[src/libout123/libout123.c:455] error: Found no driver out of [pulse] working with device .
main: [src/mpg123.c:314] error: out123 error 3: failure loading driver module

authors: Dazmk MinSnake XIAZY alongsoCJR jiangbiaoah wangKuma xiaolll yonghan zhaochunqi

repo: darknessomi/musicbox


text:
提交变更

您好，以下是这次提交变更的详细信息：
1.增加按键映射功能；
2.修复搜索按键功能映射错误；
3.使用定时器实现自动关闭功能
4.使配置文件夹符合XDG标准
5.增加显示颜色自定义；
bug：
1.快速切换歌曲会播放多首音乐

bug能顺便修复一下吗？

抱歉，python我一天都没学过。

authors: Ken-W-P-Huang kigawas


text:
Trying to understand long report generation

Currently I have multiple "small" 100MB  sized files sent to my pgBadger "processor" where the files are processed with -I -J <cores> every hour as they arived. This is generating a bunch of ___.bin files, and then takes quite a while to generate the HTML reports it seems.
So my questions:

Would the HTMLreport generation be faster if the *.bin files are merged into a single file for the day/week/month? If so, is that something that is possible to achieve (Even if in a phased rocessing)

Would it be possible to, not just do a report per day/week/month (thanks for those) but for a specific time that we had a problem to investigate?

If you want to generate a report for a specific day you just have to give the day binary files as input, for example:
pgbadger -o myreportdir/ data/2022/02/02/*.bin

you will have a report for this specific day.
Normally mutliprocess should also be used to build the report but let me check if -J is taken in account, it is possible that I have only take care of -j.

Despite what I've though there is no multiprocess used for report generation, this could be an improvement.

You can limit the memory by reducing the top number of element stored and the max query length, for example:  -t 15 -m 2048

my trouble when I cut the statement size, is that the devilish details for this specific instance, is in the query data that gets "cut" and the problem statements are those that is in the 10-20 top elements :(=)
will have to handle the RAM spikes in this processing, was hoping for a "swap to disk" option, but I'm an outlier - yet again :D

If you can send the *.bin files required to reproduce your issue to my private email I will try to see what could be improved in pgbadger otherwise I'm afraid I can't do much more for this issue.

authors: darold hevisko hvisage

repo: darold/pgbadger

license: PostgreSQL


text:
This only needs to be done once

when doing the manual, non root method to give permissions through adb, when it says it only needs to be done once, does this mean it needs to be done once but if the phone is restarted, or goes to the lockscreen, it kills it and needs to be done again the next time you use the app?
or is it persistent and doesn't need a connection to adb ever again, and can just read logs straight off the device?
(non root, android 10)

The adb permission granting does not work on newer androids. Or is there a way to enable this without rooting the phone?

adb permission is only once needed, it will stay until you take it away with adb.
And @muziker this works for me up to Android 12 with adb. Lowest was Android 7 where i did it with adb.
Enable USB debugging, type the adb command, open the app to confirm it works, disable USB debugging and enjoy.

repo: darshanparajuli/LogcatReader


text:
Travis: both stable and dev

Make sure we don't break anything in v-next

@kevmoo I don't understand this comment. Is there a pointer where I could read more?

He'd like this project to test on two bots, one on the stable sdk and one on the dev one. Dartdoc is doing it currently:
https://github.com/dart-lang/dartdoc/blob/master/.travis.yml

authors: devoncarew kevmoo lukechurch

repo: dart-lang/dart-services


text:
Shared Preferences can't be renamed

URL: https://pub.dartlang.org/packages/shared_preferences
There is no way to rename the SharedPreference internal file in Flutter like in old Java/Android way.
The generated name always = FlutterSharedPreferences.

@rtyker: this tracker is for the pub site. If you have issue with a package, please open an issue in the package's issue tracker, in this case, the Flutter team's one. I'm moving this over.

This issue was moved to flutter/flutter#17379

authors: isoos rtyker

repo: dart-lang/pub-dartlang-dart


text:
Obsolete Flutter pub package is confusing and should be removed.

See the first result in this query.
It is the "flutter" package, but it has version 0.0.20, but when clicked on, it just takes you to the pub search again.  It's confusing to people, but also to programs that are trying to enumerate packages on pub (most notably "Dash" and "Zeal" who publish offline docs for pub packages).  Can we just remove the "flutter" package, or will the world break?  Barring that, can we give it some contents that make sense, like a current version number and a "Dart 2 compatible" label?
It appears to already have a redirect in place to send the user back to the search page if they try and click on it, but removing it from the results would be the next best thing to removing it entirely.

@isoos I thought we were surpressing it from search results?

I remember that we've removed it from the results at one point, not sure how it managed to come back.
A shortlist to handle packages with redirects:

[ ] removing from /api/packages and sitemap listings
[ ] removing from Job entries
[ ] removing from search index

We had this line to prevent it to be added to the search index, but it is possible that it was not properly removed from the search snapshot in the first place, and we happened to keep it in there ever since.

The change has been deployed, the search no longer lists package:flutter.

authors: gspencergoog isoos mit-mit


text:
observe/polymer: Uppercase and refactor annotation names

This issue was originally filed by @seaneagan

issue #0 argued for upper casing the dart:core annotations, but looks like there just wasn't enough time to make that change before 1.0.  However, it's not too late to make the same change for observe/polymer:
@observable
@reflectable
@published
->
@Observed()
@Reflected()
@Published()
and then hopefully later fix issue #2 shortening them to:
@Observed
@Reflected
@Published
Removing the 'Property' suffix from PublishedProperty and ObservableProperty makes them consistent with the current Reflectable, which could allow them to also be used at the class level to mark all properties as such.  And since @Observable doesn't work, the 'able' suffix doesn't work, but the 'ed' suffix seems to work in all cases, and (FWIW) matches Deprecated.

This issue has been moved to dart-lang/observe#52.

repo: dart-lang/sdk


text:
Analysis_server_test fails locally, but not on buildbot

Running the test analysis_server/test/analysis_server_test locally consistently fails, but the test is not failing on the buildbot.  The error I get is
ERROR: AnalysisServerTest | test_no_duplicate_notifications
Test failed: Caught The null object does not have a getter 'extensions'.
NoSuchMethodError: method not found: 'extensions'
Receiver: null
Arguments: []
dart:core-patch/object_patch.dart 42                       Object._noSuchMethod
dart:core-patch/object_patch.dart 45                       Object.noSuchMethod
package:analyzer/src/plugin/options_plugin.dart 26:38      OptionsPlugin.optionsProcessors
package:analysis_server/src/context_manager.dart 497:43    ContextManagerImpl.processOptionsForContext
package:analysis_server/src/context_manager.dart 881:5     ContextManagerImpl._createContext
package:analysis_server/src/context_manager.dart 912:16    ContextManagerImpl._createContexts
package:analysis_server/src/context_manager.dart 629:9     ContextManagerImpl.setRoots
package:analysis_server/src/analysis_server.dart 951:22    AnalysisServer.setAnalysisRoots
pkg/analysis_server/test/analysis_server_test.dart 329:12  AnalysisServerTest.test_no_duplicate_notifications.
dart:async/future.dart 144                                 Future.Future.microtask.

Actually it was failing on the buildbots too.  See for example http://build.chromium.org/p/client.dart/builders/pkg-linux-be/builds/1263/steps/pkg tests failures/logs/stdio
Fixed by 395b82c041466763e9b738000586e91f389edc99


text:
https://www.dartlang.org/ left sidebar TOC is less useful than it used to be

It used to display all subheaders but now only the main headers are displayed. This makes it more difficult to navigate the style guide and usage guide :(

This issue was moved to dart-lang/www.dartlang.org#1540

authors: BlackHC kevmoo


text:
Typo in the "is a superclass" relation

@gbracha In section 10.9 (3rd edition), we have:

It is a compile-time error if a class C is a superclass of itself.

And just above that is the definition of the "is a superclass" relation:

A class S is a superclass of a class C iff either:
• S is the superclass of C, or
• S is a superclass of a class S0 and S0 is a superclass of C.

This admits reflexive relations.  An implementation that tries to check if C is a superclass of itself using the second case of the definition will get that C is a superclass of itself iff. C is a superclass of itself (by choosing C for the class S0).
We should disallow such compile-time errors unless there is really a transitive chain of "the superclass" from C to C.  The second clause should be changed to:

• S is a superclass of a class S0 and S0 is the superclass of C.

I agree that the change makes everything easier to understand.
I'm not sure the current version is actually wrong.
If you use inductive reasoning, you cannot infer that a class is a superclass of itself unless it actually occurs in the superclass chain of its own declaration - to derive that S is a superclass of C, the proof is a non-empty sequence of X_n is the superclass of X_{n+1} predicates that start with S as X_0 and ends with C as X_{k} (k > 0).
The change enforces that the inference tree is a spine, but the provable statements are the same.
(Co-inductively you do get a problem when S0 can be C).

It is wrong in the sense that it looks to be defining a relation but it is not a definition (not unique).

I'm not sure what it means for a definition of a relation to not be unique - do you mean that the definition is ambiguous and can be used to define two different relations for the same program?
If treated inductively (as such rules are usually interpreted), and assuming that S0 is (implicitly) existentially quantified, then it does define a single specific relation.
That's some assumptions, and it would be better if they were made explicit, but I do believe they are reasonable.
More precisely, the relation being defined is the transitive closure of the "is the superclass of" relation, which is a well-defined relation for any Dart program (each defined class has at most a single superclass).
There may be more than one way to infer that two elements are related, but the rules do uniquely define the "is a superclass of" relation.

Sorry, I meant that it does not define a unique relation.  I agree that it is trying to define the transitive closure of "is the superclass", which is the least relation satisfying this definition.  Perhaps you are right that it should reasonably be assumed.

We obtain 'the superclass' from a with clause or an extends clause (so they're the base cases for this induction).
In the second item, induction is invoked with both 'S is a superclass of S0' and 'S0 is a superclass of C'. I think the simplest fix would be to invoke induction only once and make the second item 'S is a superclass of a class S0, and S0 is the superclass of C'.
Looking again this is exactly what you just proposed in the chat, @kmilikin, I just didn't notice the + and -. So I support your proposal. ;-)

Fixed in ba7748302259e47f40e3838c6b7e729539984aa2

authors: eernstg kmillikin lrhn


text:
support universal function types

From @jmesserly on April 25, 2016 22:15
Initial implementation of #301 may not cover this.

[x] ensure these have a runtime representation (likely done as part of #301)
[x] implement subtyping rules
[x] prevent these types from being treated as callable functions (e.g. (f.runtimeType as dynamic)(int) where f is a generic function). Discussed at the end.

These can't be written down yet, but they can come up in inference, for example:
/*=T*/ f/*<T>*/(/*=T*/x) => x;
main() {
  var y = f;
  y = /*<S>*/(y) => y; // legal
}

Note the generic function expression is #527
I'm not aware of this blocking anything, but for consistentcy with Analyzer we should support it.
Regarding "prevent these types from being treated as callable functions": we may need to split out into its own bug, as it likely requires changing how generic classes look. Generic class types & function typedefs are callable, which was okay because they weren't accessible as first-class values. But universal function types can be gotten from .runtimeType, and will likely have a literal form as well: MyGenericFnType. It's not a huge problem if that value is "dynamically callable", since the Type interface does not say anything about supporting call, but it seems suboptimal.
Copied from original issue: dart-lang/dev_compiler#526

This is now fixed!

The reason these types aren't callable is because we fixed this issue in general by returning user-visible Types that wrap our internal types, preventing implementation details from leaking.


text:
exception when running the analysis server benchmarks with --preview-dart-2

Currently https://dart-review.googlesource.com/c/sdk/+/26461 fails, but we should eventually restore the test.
@devoncarew

This is the exception:
  Analysis failed: /Users/devoncarew/projects/dart-lang/dart-sdk/sdk/pkg/meta/lib/meta.dart context: exception_20171205_161923_021
  Bad state: Some types were not consumed, starting at offset -1
  #0      ResolutionApplier.checkDone (package:analyzer/src/fasta/resolution_applier.dart:72:7)
  #1      LibraryAnalyzer._resolveFile2 (package:analyzer/src/dart/analysis/library_analyzer.dart:734:21)
  #2      LibraryAnalyzer._analyze2.<anonymous closure> (package:analyzer/src/dart/analysis/library_analyzer.dart:208:9)
  #3      _HashVMBase&MapMixin&&_LinkedHashMapMixin.forEach (dart:collection-patch/dart:collection/compact_hash.dart:361)
  #4      LibraryAnalyzer._analyze2 (package:analyzer/src/dart/analysis/library_analyzer.dart:207:13)
  <asynchronous suspension>
  #5      LibraryAnalyzer.analyze.<anonymous closure> (package:analyzer/src/dart/analysis/library_analyzer.dart:95:22)
  <asynchronous suspension>
  #6      _PerformanceTagImpl.makeCurrentWhileAsync (package:analyzer/src/generated/utilities_general.dart:217:21)
  <asynchronous suspension>
  #7      LibraryAnalyzer.analyze (package:analyzer/src/dart/analysis/library_analyzer.dart:93:43)
  <asynchronous suspension>
  #8      AnalysisDriver._computeAnalysisResult.<anonymous closure> (package:analyzer/src/dart/analysis/driver.dart:1216:71)
  <asynchronous suspension>
  #9      PerformanceLog.runAsync (package:front_end/src/base/performance_logger.dart:52:21)
  <asynchronous suspension>
  #10     AnalysisDriver._computeAnalysisResult (package:analyzer/src/dart/analysis/driver.dart:1183:20)
  <asynchronous suspension>
  #11     AnalysisDriver.performWork (package:analyzer/src/dart/analysis/driver.dart:1010:39)
  <asynchronous suspension>
  #12     AnalysisDriverScheduler._run (package:analyzer/src/dart/analysis/driver.dart:1887:24)
  <asynchronous suspension>
  #13     AnalysisDriverScheduler.start (package:analyzer/src/dart/analysis/driver.dart:1830:5)

The benchmark test now passes. The full benchmark (dart pkg/analysis_server/benchmark/benchmarks.dart run --repeat=1 --preview-dart-2 analysis-server) fails with a separate exception:
Class '_CompileTimeError' not found in library 'dart:core'
#0      _ClassTable._getClassIndex (package:kernel/library_index.dart:161:7)
#1      _ClassTable.getMember (package:kernel/library_index.dart:175:12)
#2      LibraryIndex.getMember (package:kernel/library_index.dart:101:38)
#3      CoreTypes.compileTimeErrorDefaultConstructor (package:kernel/core_types.dart:391:16)
#4      Target.buildCompileTimeError (package:kernel/target/targets.dart:195:19)
#5      SourceLoader.buildCompileTimeError (package:front_end/src/fasta/source/source_loader.dart:659:33)
#6      BodyBuilder.buildCompileTimeError (package:front_end/src/fasta/kernel/body_builder.dart:3292:28)
#7      BodyBuilder.wrapInCompileTimeError (package:front_end/src/fasta/kernel/body_builder.dart:3301:9)
#8      TypeInferrerImpl.checkAssignability (package:front_end/src/fasta/type_inference/type_inferrer.dart:403:34)
#9      TypeInferrerImpl.inferInvocation (package:front_end/src/fasta/type_inference/type_inferrer.dart:979:9)
#10     TypeInferrerImpl.inferMethodInvocation (package:front_end/src/fasta/type_inference/type_inferrer.dart:1190:24)
#11     ShadowMethodInvocation._inferExpression (package:front_end/src/fasta/kernel/kernel_shadow_ast.dart:1429:21)
#12     ShadowTypeInferrer.inferExpression (package:front_end/src/fasta/kernel/kernel_shadow_ast.dart:2187:25)
#13     ShadowExpressionStatement._inferStatement (package:front_end/src/fasta/kernel/kernel_shadow_ast.dart:674:14)
#14     ShadowTypeInferrer.inferStatement (package:front_end/src/fasta/kernel/kernel_shadow_ast.dart:2230:24)
#15     ShadowBlock._inferStatement (package:front_end/src/fasta/kernel/kernel_shadow_ast.dart:188:16)

With https://dart-review.googlesource.com/c/sdk/+/29000 we will be able to go a bit further.

We're further now - updated with the current exception:
Unhandled exception:
Analysis failed: /Users/.../pkg/analysis_server/benchmark/benchmarks.dart context: exception_20171212_214227_895
Bad state: (Null) null
#0      _ResolutionApplierContext.enterLocalFunction (package:analyzer/src/dart/analysis/library_analyzer.dart:1153:7)
#1      ResolutionApplier.visitFunctionExpression (package:analyzer/src/fasta/resolution_applier.dart:254:18)
#2      FunctionExpressionImpl.accept (package:analyzer/src/dart/ast/ast.dart:5316:49)
#3      ResolutionApplier._applyResolutionToArguments (package:analyzer/src/fasta/resolution_applier.dart:538:29)
#4      ResolutionApplier.visitMethodInvocation (package:analyzer/src/fasta/resolution_applier.dart:365:5)
#5      MethodInvocationImpl.accept (package:analyzer/src/dart/ast/ast.dart:7595:49)
#6      ResolutionApplier.visitVariableDeclaration (package:analyzer/src/fasta/resolution_applier.dart:507:23)
#7      VariableDeclarationImpl.accept (package:analyzer/src/dart/ast/ast.dart:11058:49)
#8      NodeListImpl.accept (package:analyzer/src/dart/ast/ast.dart:7987:20)
#9      ResolutionApplier.visitVariableDeclarationList (package:analyzer/src/fasta/resolution_applier.dart:523:22)
#10     VariableDeclarationListImpl.accept (package:analyzer/src/dart/ast/ast.dart:11154:15)
#11     VariableDeclarationStatementImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:11215:20)
#12     GeneralizingAstVisitor.visitNode (package:analyzer/dart/ast/visitor.dart:431:10)
#13     GeneralizingAstVisitor.visitStatement (package:analyzer/dart/ast/visitor.dart:494:39)
#14     GeneralizingAstVisitor.visitVariableDeclarationStatement (package:analyzer/dart/ast/visitor.dart:566:7)
#15     VariableDeclarationStatementImpl.accept (package:analyzer/src/dart/ast/ast.dart:11211:15)
#16     NodeListImpl.accept (package:analyzer/src/dart/ast/ast.dart:7987:20)
#17     BlockImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:1346:17)
#18     GeneralizingAstVisitor.visitNode (package:analyzer/dart/ast/visitor.dart:431:10)
#19     GeneralizingAstVisitor.visitStatement (package:analyzer/dart/ast/visitor.dart:494:39)
#20     GeneralizingAstVisitor.visitBlock (package:analyzer/dart/ast/visitor.dart:184:31)
#21     BlockImpl.accept (package:analyzer/src/dart/ast/ast.dart:1342:49)
#22     BlockFunctionBodyImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:1291:13)
#23     GeneralizingAstVisitor.visitNode (package:analyzer/dart/ast/visitor.dart:431:10)
#24     GeneralizingAstVisitor.visitFunctionBody (package:analyzer/dart/ast/visitor.dart:314:45)
#25     GeneralizingAstVisitor.visitBlockFunctionBody (package:analyzer/dart/ast/visitor.dart:187:55)
#26     BlockFunctionBodyImpl.accept (package:analyzer/src/dart/ast/ast.dart:1287:49)
#27     LibraryAnalyzer._resolveFile2 (package:analyzer/src/dart/analysis/library_analyzer.dart:763:25)
#28     LibraryAnalyzer._analyze2.<anonymous closure> (package:analyzer/src/dart/analysis/library_analyzer.dart:208:9)
#29     _HashVMBase&MapMixin&&_LinkedHashMapMixin.forEach (dart:collection-patch/dart:collection/compact_hash.dart:361)
#30     LibraryAnalyzer._analyze2 (package:analyzer/src/dart/analysis/library_analyzer.dart:207:13)
<asynchronous suspension>

This should be fixed in https://dart-review.googlesource.com/c/sdk/+/29002
And the next (yes, we have a next crash waiting for us :-)) is import prefixes resolution https://dart-review.googlesource.com/c/sdk/+/28541, but it might take a while to get it approved :-(

:) thanks for all the fixes
Unhandled exception:
Analysis failed: /Users/.../dart-sdk/sdk/pkg/analysis_server/benchmark/benchmarks.dart context: exception_20171213_080055_754
Bad state: Expected element reference for analyzer offset 3308; got one for kernel offset 3313
#0      ValidatingResolutionApplier._getReferenceFor (package:analyzer/src/fasta/resolution_applier.dart:868:7)
#1      ResolutionApplier.visitSimpleIdentifier (package:analyzer/src/fasta/resolution_applier.dart:440:26)
#2      SimpleIdentifierImpl.accept (package:analyzer/src/dart/ast/ast.dart:9350:49)
#3      ResolutionApplier.visitMethodInvocation (package:analyzer/src/fasta/resolution_applier.dart:345:18)
#4      MethodInvocationImpl.accept (package:analyzer/src/dart/ast/ast.dart:7595:49)
#5      ResolutionApplier.visitAssignmentExpression (package:analyzer/src/fasta/resolution_applier.dart:81:24)
#6      AssignmentExpressionImpl.accept (package:analyzer/src/dart/ast/ast.dart:906:49)
#7      ExpressionStatementImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:4231:18)
#8      GeneralizingAstVisitor.visitNode (package:analyzer/dart/ast/visitor.dart:431:10)
#9      GeneralizingAstVisitor.visitStatement (package:analyzer/dart/ast/visitor.dart:494:39)
#10     GeneralizingAstVisitor.visitExpressionStatement (package:analyzer/dart/ast/visitor.dart:291:59)

Unhandled exception:
Analysis failed: /Users/devoncarew/projects/dart-lang/dart-sdk/sdk/pkg/analysis_server/benchmark/perf/benchmark_angular.dart context: exception_20171231_131148_121
UnimplementedError: type: (FunctionTypeImpl) (String) → dynamic
#0      _ExprBuilder._buildType (package:analyzer/src/kernel/resynthesize.dart:758:5)
#1      _ExprBuilder._buildTypeArgumentList (package:analyzer/src/kernel/resynthesize.dart:766:39)
#2      _ExprBuilder._build (package:analyzer/src/kernel/resynthesize.dart:547:11)
#3      _ExprBuilder.build (package:analyzer/src/kernel/resynthesize.dart:447:14)
#4      _KernelUnitResynthesizerContextImpl.getExpression (package:analyzer/src/kernel/resynthesize.dart:1119:44)
#5      TopLevelVariableElementImpl&ConstVariableElement.constantInitializer (package:analyzer/src/dart/element/element.dart:2642:14)
#6      ConstantEvaluationEngine.computeDependencies (package:analyzer/src/dart/constant/evaluation.dart:278:41)
#7      _ConstantNode.computeDependencies (package:analyzer/src/dart/analysis/library_analyzer.dart:963:22)
#8      Node.getDependencies (package:front_end/src/dependency_walker.dart:42:40)
#9      DependencyWalker.walk.strongConnect (package:front_end/src/dependency_walker.dart:102:40)
#10     DependencyWalker.walk (package:front_end/src/dependency_walker.dart:168:18)
#11     LibraryAnalyzer._computeConstants (package:analyzer/src/dart/analysis/library_analyzer.dart:295:47)
#12     LibraryAnalyzer._analyze2 (package:analyzer/src/dart/analysis/library_analyzer.dart:226:7)
<asynchronous suspension>
#13     LibraryAnalyzer.analyze.<anonymous closure> (package:analyzer/src/dart/analysis/library_analyzer.dart:97:22)
<asynchronous suspension>
#14     _PerformanceTagImpl.makeCurrentWhileAsync (package:analyzer/src/generated/utilities_general.dart:217:21)
<asynchronous suspension>
#15     LibraryAnalyzer.analyze (package:analyzer/src/dart/analysis/library_analyzer.dart:95:43)
<asynchronous suspension>
#16     AnalysisDriver._computeAnalysisResult.<anonymous closure> (package:analyzer/src/dart/analysis/driver.dart:1216:71)

What is the current state of this issue? I know that a lot of the preview-dart-2 issues in analyzer and server have been fixed.

Closing and will re-open as a new issue.

authors: bwilkerson devoncarew scheglov


text:
lib_2/isolate/spawn_uri_nested_vm_test sporadically hangs in app_jitk configuration

tools/test.py -m release -c app_jitk --strong lib_2/isolate/spawn_uri_nested_vm_test

Easily reproducible on Linux - hanged 4 out of 5 runs.
This test spawns a new isolate which spawns a yet another isolate.
It looks like a newly spawned isolate is waiting for kernel service isolate, but it has gone already (as main isolate is shutting down and waiting for other isolates to finish).
Maybe we should not kill kernel service isolate during shutdown until all application isolates are terminated (similarly to VM service isolate).
Stack traces:
Thread 10 (Thread 0x7ffff7fb7700 (LWP 248384)):
#0  0x00007ffff6c59083 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00000000006e3885 in dart::bin::EventHandlerImplementation::Poll (args=39370816) at ../../runtime/bin/eventhandler_linux.cc:389
#2  0x00000000007023be in dart::bin::ThreadStart (data_ptr=<optimized out>) at ../../runtime/bin/thread_linux.cc:85
#3  0x00007ffff79bf494 in start_thread (arg=0x7ffff7fb7700) at pthread_create.c:333
#4  0x00007ffff6c58a8f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 9 (Thread 0x7ffff663f700 (LWP 248385)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00000000009fbcd8 in dart::Monitor::WaitMicros (this=0x286e420, micros=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:444
#2  0x0000000000952e6a in Wait (millis=0, this=<optimized out>) at ../../runtime/vm/lockers.h:169
#3  dart::KernelCompilationRequest::SendAndWaitForResponse (this=0x7ffff663e9c8, request_tag=<optimized out>, kernel_port=976596681,
    script_uri=<optimized out>, platform_kernel=<optimized out>, platform_kernel_size=5512147, source_files_count=0, source_files=0x0,
    incremental_compile=<optimized out>, package_config=0x31a2f78 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/.packages")
    at ../../runtime/vm/kernel_isolate.cc:581
#4  0x0000000000952a1f in dart::KernelIsolate::CompileToKernel (
    script_uri=0x2596580 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/tests/lib_2/isolate/spawn_uri_nested_child2_vm_isolate.dart",
    platform_kernel=0x1660a80 <kPlatformStrongDill> "\220\253\315", <incomplete sequence \357>, platform_kernel_size=5512147, source_file_count=0,
    source_files=0x0, incremental_compile=<optimized out>, package_config=0x31a2f78 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/.packages")
    at ../../runtime/vm/kernel_isolate.cc:713
#5  0x0000000000c76157 in Dart_CompileToKernel (script_uri=0x80 <error: Cannot access memory at address 0x80>,
    platform_kernel=0x1 <error: Cannot access memory at address 0x1>, platform_kernel_size=140737347604831, incremental_compile=false,
    package_config=0xfffffffffffffe00 <error: Cannot access memory at address 0xfffffffffffffe00>) at ../../runtime/vm/dart_api_impl.cc:5910
#6  0x00000000006e0045 in CompileScript (script_uri=0x80 <error: Cannot access memory at address 0x80>, incremental=255,
    package_config=0x31a2f78 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/.packages", this=<optimized out>, strong=<optimized out>)
    at ../../runtime/bin/dfe.cc:207
#7  dart::bin::DFE::CompileAndReadScript (this=<optimized out>, script_uri=0x80 <error: Cannot access memory at address 0x80>, kernel_buffer=0x7ffff663eb50,
    kernel_buffer_size=0x7ffff663eb20, error=0x7ffff663ed50, exit_code=0x7ffff663ecb4, strong=<optimized out>,
    package_config=0x31a2f78 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/.packages") at ../../runtime/bin/dfe.cc:220
#8  0x00000000006dc139 in dart::bin::IsolateSetupHelper (isolate=0x2d35b00, is_main_isolate=false,
    script_uri=0x2596580 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/tests/lib_2/isolate/spawn_uri_nested_child2_vm_isolate.dart",
    package_root=<optimized out>, packages_config=<optimized out>, set_native_resolvers=true, isolate_run_app_snapshot=false, flags=0x7ffff663ed00,
    error=0x7ffff663ed50, exit_code=0x7ffff663ecb4) at ../../runtime/bin/main.cc:331
#9  0x00000000006daf68 in dart::bin::CreateIsolateAndSetupHelper (is_main_isolate=<optimized out>,
    script_uri=0x2596580 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/tests/lib_2/isolate/spawn_uri_nested_child2_vm_isolate.dart",
    main=<optimized out>, package_root=0x0, packages_config=0x2586050 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/.packages",
    flags=0x7ffff663ed00, error=0x7ffff663ed50, exit_code=0x7ffff663ecb4) at ../../runtime/bin/main.cc:710
#10 0x00000000006db95e in dart::bin::CreateIsolateAndSetup (
    script_uri=0x2596580 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/tests/lib_2/isolate/spawn_uri_nested_child2_vm_isolate.dart",
    main=0x257a030 "main", package_root=0x0, package_config=0x2586050 "file:///usr/local/google/home/alexmarkov/work/dart/sdk/.packages",
    flags=0x7ffff663ed00, data=<optimized out>, error=0x7ffff663ed50) at ../../runtime/bin/main.cc:753
#11 0x000000000087ea84 in dart::SpawnIsolateTask::Run (this=0x257c550) at ../../runtime/lib/isolate.cc:132
#12 0x0000000000ae442d in dart::ThreadPool::Worker::Loop (this=0x2584090) at ../../runtime/vm/thread_pool.cc:381
#13 0x0000000000ae42d1 in dart::ThreadPool::Worker::Main (args=39338128) at ../../runtime/vm/thread_pool.cc:436
#14 0x00000000009fb479 in dart::ThreadStart (data_ptr=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:135
#15 0x00007ffff79bf494 in start_thread (arg=0x7ffff663f700) at pthread_create.c:333
#16 0x00007ffff6c58a8f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 8 (Thread 0x7ffff653e700 (LWP 248386)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00000000009fbcc0 in dart::Monitor::WaitMicros (this=0x2584120, micros=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:449
#2  0x0000000000ae44ee in WaitMicros (micros=5000000, this=<optimized out>) at ../../runtime/vm/lockers.h:177
#3  dart::ThreadPool::Worker::Loop (this=0x2584120) at ../../runtime/vm/thread_pool.cc:394
#4  0x0000000000ae42d1 in dart::ThreadPool::Worker::Main (args=39338272) at ../../runtime/vm/thread_pool.cc:436
#5  0x00000000009fb479 in dart::ThreadStart (data_ptr=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:135
#6  0x00007ffff79bf494 in start_thread (arg=0x7ffff653e700) at pthread_create.c:333
#7  0x00007ffff6c58a8f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 7 (Thread 0x7ffff09bf700 (LWP 248387)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00000000009fbcc0 in dart::Monitor::WaitMicros (this=0x25841b0, micros=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:449
#2  0x0000000000ae44ee in WaitMicros (micros=4999999, this=<optimized out>) at ../../runtime/vm/lockers.h:177
#3  dart::ThreadPool::Worker::Loop (this=0x25841b0) at ../../runtime/vm/thread_pool.cc:394
#4  0x0000000000ae42d1 in dart::ThreadPool::Worker::Main (args=39338416) at ../../runtime/vm/thread_pool.cc:436
#5  0x00000000009fb479 in dart::ThreadStart (data_ptr=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:135
#6  0x00007ffff79bf494 in start_thread (arg=0x7ffff09bf700) at pthread_create.c:333
#7  0x00007ffff6c58a8f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 6 (Thread 0x7ffff013f700 (LWP 248388)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00000000009fbcc0 in dart::Monitor::WaitMicros (this=0x2584240, micros=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:449
#2  0x0000000000ae44ee in WaitMicros (micros=5000000, this=<optimized out>) at ../../runtime/vm/lockers.h:177
#3  dart::ThreadPool::Worker::Loop (this=0x2584240) at ../../runtime/vm/thread_pool.cc:394
#4  0x0000000000ae42d1 in dart::ThreadPool::Worker::Main (args=39338560) at ../../runtime/vm/thread_pool.cc:436
#5  0x00000000009fb479 in dart::ThreadStart (data_ptr=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:135
#6  0x00007ffff79bf494 in start_thread (arg=0x7ffff013f700) at pthread_create.c:333
#7  0x00007ffff6c58a8f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 5 (Thread 0x7fffefd3f700 (LWP 248389)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00000000009fbcc0 in dart::Monitor::WaitMicros (this=0x25842d0, micros=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:449
#2  0x0000000000ae44ee in WaitMicros (micros=5000000, this=<optimized out>) at ../../runtime/vm/lockers.h:177
#3  dart::ThreadPool::Worker::Loop (this=0x25842d0) at ../../runtime/vm/thread_pool.cc:394
#4  0x0000000000ae42d1 in dart::ThreadPool::Worker::Main (args=39338704) at ../../runtime/vm/thread_pool.cc:436
#5  0x00000000009fb479 in dart::ThreadStart (data_ptr=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:135
#6  0x00007ffff79bf494 in start_thread (arg=0x7fffefd3f700) at pthread_create.c:333
#7  0x00007ffff6c58a8f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 4 (Thread 0x7fffed17f700 (LWP 248390)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00000000009fbcd8 in dart::Monitor::WaitMicros (this=0x2577a40, micros=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:444
#2  0x000000000093bdfa in Wait (millis=0, this=<optimized out>) at ../../runtime/vm/lockers.h:169
#3  WaitForOutstandingSpawns (this=0x2d34900) at ../../runtime/vm/isolate.cc:2697
#4  dart::ShutdownIsolate (parameter=47401216) at ../../runtime/vm/isolate.cc:1602
#5  0x0000000000962968 in dart::MessageHandler::TaskCallback (this=0x25c0b60) at ../../runtime/vm/message_handler.cc:496
#6  0x0000000000ae442d in dart::ThreadPool::Worker::Loop (this=0x2584360) at ../../runtime/vm/thread_pool.cc:381
#7  0x0000000000ae42d1 in dart::ThreadPool::Worker::Main (args=39338848) at ../../runtime/vm/thread_pool.cc:436
#8  0x00000000009fb479 in dart::ThreadStart (data_ptr=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:135
#9  0x00007ffff79bf494 in start_thread (arg=0x7fffed17f700) at pthread_create.c:333
#10 0x00007ffff6c58a8f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 3 (Thread 0x7fffecfff700 (LWP 248391)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00000000009fbcd8 in dart::Monitor::WaitMicros (this=0x2576900, micros=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:444
#2  0x0000000000c330aa in Wait (millis=0, this=<optimized out>) at ../../runtime/vm/lockers.h:169
#3  dart::BackgroundCompiler::Run (this=0x25752c0) at ../../runtime/vm/compiler/jit/compiler.cc:1788
#4  0x0000000000ae442d in dart::ThreadPool::Worker::Loop (this=0x25843f0) at ../../runtime/vm/thread_pool.cc:381
#5  0x0000000000ae42d1 in dart::ThreadPool::Worker::Main (args=39338992) at ../../runtime/vm/thread_pool.cc:436
#6  0x00000000009fb479 in dart::ThreadStart (data_ptr=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:135
#7  0x00007ffff79bf494 in start_thread (arg=0x7fffecfff700) at pthread_create.c:333
#8  0x00007ffff6c58a8f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7fffe2c7f700 (LWP 248416)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00000000009fbcc0 in dart::Monitor::WaitMicros (this=0x25845a0, micros=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:449
#2  0x0000000000ae44ee in WaitMicros (micros=5000000, this=<optimized out>) at ../../runtime/vm/lockers.h:177
#3  dart::ThreadPool::Worker::Loop (this=0x25845a0) at ../../runtime/vm/thread_pool.cc:394
#4  0x0000000000ae42d1 in dart::ThreadPool::Worker::Main (args=39339424) at ../../runtime/vm/thread_pool.cc:436
#5  0x00000000009fb479 in dart::ThreadStart (data_ptr=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:135
#6  0x00007ffff79bf494 in start_thread (arg=0x7fffe2c7f700) at pthread_create.c:333
#7  0x00007ffff6c58a8f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7ffff7fbac00 (LWP 248380)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00000000009fbcd8 in dart::Monitor::WaitMicros (this=0x25762a0, micros=<optimized out>) at ../../runtime/vm/os_thread_linux.cc:444
#2  0x00000000008fddba in Wait (millis=0, this=<optimized out>) at ../../runtime/vm/lockers.h:169
#3  WaitForApplicationIsolateShutdown () at ../../runtime/vm/dart.cc:339
#4  dart::Dart::Cleanup () at ../../runtime/vm/dart.cc:414
#5  0x0000000000c51c69 in Dart_Cleanup () at ../../runtime/vm/dart_api_impl.cc:1007
#6  0x00000000006db6c7 in dart::bin::main (argc=9, argv=0x7fffffffdad8) at ../../runtime/bin/main.cc:1327
#7  0x00000000006dbef9 in main (argc=39281356, argv=0x80) at ../../runtime/bin/main.cc:1358

/cc @rmacnak-google @a-siva

Agree, the lifecycle of the kernel isolate should be really similar to the lifecycle of the service isolate. I'm surprised it isn't already because I'd figure that would have been the easier thing to do when it was first added.

Related: #28192.

authors: alexmarkov rmacnak-google srawlins


text:
Integrate interface-conflicts.md into dartLangSpec.tex

The interface-conflicts.md CL has now been landed. However, it will probably have to be adjusted such that it uses the fine grained "substructure" on subtyping that we have introduced in extreme-upper-lower-bounds.md. This will be less discriminating (fewer programs will be considered to have conflicts), but more compatible with approaches already in use elsewhere.
(For example implements I, J will no longer be a conflict if I declares dynamic foo() and J declares Object foo(), we just select Object foo() and proceed.)
This issue is concerned with integrating interface-conflicts.md into dartLangSpec.tex; the above-mentioned adjustment will be performed as part of that operation.

Integrated into dartLangSpec.tex in https://dart-review.googlesource.com/c/sdk/+/81263.


text:
dart:async is optional in Flutter but not in the 2.0.0 SDK

The 2.0.0 analyzer will catch usages of dart:async that are missing an import, but the Dart SDK provided by Flutter seems to allow it. This forces users to switch back and forth between SDKs when developing for Flutter and web

Dart VM version: 2.0.0 (Fri Aug 3 10:53:23 2018 +0200) on "macos_x64"
MacOSX

In Dart 2.1, the dart:core library started exporting Future and Stream. Since you can write functions returning Future or Stream without importing dart:async (by using async or async* function bodies), we decided that you should be able to write the type of those functions too without having to import dart:async.
It does mean that any code using that feature should have an SDK requirement of 2.1.0.
The Flutter project has been releasing development versions of the Dart SDK, so they already have the feature, while the stable Dart 2.1 release hasn't been made yet.
(Analyzer people, would it make sense to detect uses of Future and Stream without an import when a package has an SDK requirement <2.1.0?)

Related: #34978.

I'll close this as stale.

authors: johnpryan lrhn srawlins stereotype441


text:
Analyzer assist_internal.dart: NoSuchMethodError: The getter 'name' was called on null

When double-clicking the word "ProcessResult" here, VS Code sent a request for code actions, and this crash happened.

[Error - 7:47:23 AM] Request textDocument/codeAction failed.
  Message: An error occurred while handling textDocument/codeAction request
  Code: -32001
[Error - 7:47:23 AM] An error occurred while handling textDocument/codeAction request: NoSuchMethodError: The getter 'name' was called on null.
Receiver: null
Tried calling: name
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:50:5)
#1      AssistProcessor._addProposal_convertMapFromIterableToForLiteral (package:analysis_server/src/services/correction/assist_internal.dart:974:17)
<asynchronous suspension>
#2      AssistProcessor.compute (package:analysis_server/src/services/correction/assist_internal.dart:155:13)
<asynchronous suspension>
#3      CodeActionHandler._getAssistActions (package:analysis_server/src/lsp/handlers/handler_code_actions.dart:142:39)
<asynchronous suspension>
#4      CodeActionHandler._getCodeActions (package:analysis_server/src/lsp/handlers/handler_code_actions.dart:167:7)
#5      _AsyncAwaitCompleter.start (dart:async-patch/async_patch.dart:49:6)
#6      CodeActionHandler._getCodeActions (package:analysis_server/src/lsp/handlers/handler_code_actions.dart:154:70)
#7      CodeActionHandler.handle.<anonymous closure>.<anonymous closure>.<anonymous closure> (package:analysis_server/src/lsp/handlers/handler_code_actions.dart:64:18)
#8      ErrorOr.mapResult (package:analysis_server/lsp_protocol/protocol_special.dart:217:12)
#9      CodeActionHandler.handle.<anonymous closure>.<anonymous closure> (package:analysis_server/src/lsp/handlers/handler_code_actions.dart:61:26)
#10     ErrorOr.mapResult (package:analysis_server/lsp_protocol/protocol_special.dart:217:12)
#11     CodeActionHandler.handle.<anonymous closure> (package:analysis_server/src/lsp/handlers/handler_code_actions.dart:60:26)
#12     ErrorOr.mapResult (package:analysis_server/lsp_protocol/protocol_special.dart:217:12)
#13     CodeActionHandler.handle (package:analysis_server/src/lsp/handlers/handler_code_actions.dart:57:17)
#14     _asyncThenWrapperHelper.<anonymous closure> (dart:async-patch/async_patch.dart:77:64)
#15     _rootRunUnary (dart:async/zone.dart:1132:38)
#16     _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#17     _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#18     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#19     Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#20     Future._complete (dart:async/future_impl.dart:473:7)
#21     _SyncCompleter.complete (dart:async/future_impl.dart:51:12)
#22     _AsyncAwaitCompleter.complete (dart:async-patch/async_patch.dart:28:18)
#23     _completeOnAsyncReturn (dart:async-patch/async_patch.dart:294:13)
#24     _MessageHandler&Object&Handler.requireResolvedUnit (package:analysis_server/src/lsp/handlers/handlers.dart)
#25     _asyncThenWrapperHelper.<anonymous closure> (dart:async-patch/async_patch.dart:77:64)
#26     _rootRunUnary (dart:async/zone.dart:1132:38)
#27     _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#28     _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#29     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#30     Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#31     Future._completeWithValue (dart:async/future_impl.dart:483:5)
#32     Future._asyncComplete.<anonymous closure> (dart:async/future_impl.dart:513:7)
#33     _rootRun (dart:async/zone.dart:1124:13)
#34     _CustomZone.run (dart:async/zone.dart:1021:19)
#35     _CustomZone.runGuarded (dart:async/zone.dart:923:7)
#36     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:963:23)
#37     _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
#38     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)
#39     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:115:13)
#40     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:172:5)

Oops, I already opened this at #37159.


text:
[NNBD] analyzer type promotion issue

test<T>(T t) {
   if (t is Object) {
     Object foo() => t;
   }
}

Analyzer with '--enable-experiment non-nullable' option produces the following output
dartanalyzer --enable-experiment non-nullable test.dart

Analyzing test.dart...
  error - The return type 'T' isn't a 'Object', as defined by the method 'foo'. - test.dart:3:22 - return_of_invalid_type
  hint - Unnecessary type check, the result is always true. - test.dart:2:8 - unnecessary_type_check_true
  hint - The declaration 'foo' isn't referenced. - test.dart:3:13 - unused_element
1 error and 2 hints found.

There are two issues here.
First, there must be no error. T must be promoted to T&Object which is subtype of Object, so we can return t here
Second,  "hint - Unnecessary type check, the result is always true. - test.dart:2:8 - unnecessary_type_check_true". According to the @eernstg "Looks like a missing update in the analyzer: It thinks that Object is a top type. It should only consider Object?, void, dynamic, and FutureOr<T> where T is a top type as top types."
dartanalyzer version 2.6.0-dev.3.0

Paul fixed type parameters promotion in 8e23f76ac731e8626782f423cbcecd523a1627d4.
I will patch around the existing hint for is Object.
https://dart-review.googlesource.com/c/sdk/+/122700

authors: scheglov sgrekhov


text:
Dartdevk produces an error when null is returned from async function with return type dyncmic

The following co19 test fails on dartdevc compiler with Error: Expected a value of type 'Object', but got one of type 'Null'
Object test1() async {
  Object? o = null;
  return o;
}

dynamic test2() async {
  Object? o = null;
  return o;
}

main() {
  test1();
  test2();
}

Error log
This test works well on all other platforms and must pass on derdevk as well

Drive-by comment: I agree that there is no error in this example. However, the log looks like dartdevk-strong-linux-release-chrome is crashing rather than reporting a (spurious) type error in the program under compilation.

Drive-by comment: I agree that there is no error in this example. However, the log looks like dartdevk-strong-linux-release-chrome is crashing rather than reporting a (spurious) type error in the program under compilation.

Thanks for the report. From my investigation this looks more like it is an issue with the method statically typed to return Object when running in sound mode. DDC has some code that needs to be updated with the change in the spec in regard to the Future value type for returns in async methods. I have a fix in progress.

Thanks for the report. From my investigation this looks more like it is an issue with the method statically typed to return Object when running in sound mode. DDC has some code that needs to be updated with the change in the spec in regard to the Future value type for returns in async methods. I have a fix in progress.

authors: eernstg nshahan sgrekhov


text:
Incorrect behaviour of keys and values iterables of VM LinkedHashMaps

The documentation on Map states "Modifying the map while iterating the keys or values may also break the iteration".
I believe the VM result below is incorrect because the keys are iterated completely between modifications.
import 'dart:collection';

void printIt(String name, Object Function() f) {
  try {
    print('$name: ${f()}');
  } catch (e) {
    print('$name: throws $e');
  }
}

void check(String name, Map<String,Object> m) {
  m['a'] = 1;
  m['b'] = 2;
  final keys = m.keys;
  printIt('$name.keys.length', () => keys.length);
  printIt('$name.keys', () => keys);
  m['c'] = 3;
  printIt('$name.keys.length', () => keys.length);
  printIt('$name.keys', () => keys);
  m['x'] = 24;
  printIt('$name.keys.length', () => keys.length);
  printIt('$name.keys', () => keys);
  m['y'] = 25;
  printIt('$name.keys.length', () => keys.length);
  printIt('$name.keys', () => keys);
}

void main() {
  check('Map', {});
  check('HashMap', HashMap());
  check('SplayTreeMap', SplayTreeMap());
}

VM result:
Map.keys.length: 2
Map.keys: (a, b)
Map.keys.length: 3
Map.keys: (a, b)
Map.keys.length: 4
Map.keys: (a, b)
Map.keys.length: 5
Map.keys: throws Concurrent modification during iteration: _LinkedHashMap len:5.
HashMap.keys.length: 2
HashMap.keys: (a, b)
HashMap.keys.length: 3
HashMap.keys: (c, a, b)
HashMap.keys.length: 4
HashMap.keys: (c, a, b, x)
HashMap.keys.length: 5
HashMap.keys: (y, c, a, b, x)
SplayTreeMap.keys.length: 2
SplayTreeMap.keys: (a, b)
SplayTreeMap.keys.length: 3
SplayTreeMap.keys: (a, b, c)
SplayTreeMap.keys.length: 4
SplayTreeMap.keys: (a, b, c, x)
SplayTreeMap.keys.length: 5
SplayTreeMap.keys: (a, b, c, x, y)

dart2js result
Map.keys.length: 2
Map.keys: (a, b)
Map.keys.length: 3
Map.keys: (a, b, c)
Map.keys.length: 4
Map.keys: (a, b, c, x)
Map.keys.length: 5
Map.keys: (a, b, c, x, y)
HashMap.keys.length: 2
HashMap.keys: (a, b)
HashMap.keys.length: 3
HashMap.keys: (a, b, c)
HashMap.keys.length: 4
HashMap.keys: (a, b, c, x)
HashMap.keys.length: 5
HashMap.keys: (a, b, c, x, y)
SplayTreeMap.keys.length: 2
SplayTreeMap.keys: (a, b)
SplayTreeMap.keys.length: 3
SplayTreeMap.keys: (a, b, c)
SplayTreeMap.keys.length: 4
SplayTreeMap.keys: (a, b, c, x)
SplayTreeMap.keys.length: 5
SplayTreeMap.keys: (a, b, c, x, y)

@lrhn Do you agree the VM is wrong?
Would you prefer tests in corelib or tests in lib/collection?

Interesting, that bug has been there for years.

To fix that bug, the access of _data and _usedData at get:keys needs to be moved later, to the construction of the  Iterator , not the iterable.
This moves the access away from a context that is specialized to the Base by duplication in a mixin application to a context that is unspecialized. The accesses, when moved to the _CompactIterable becomes polymorphic in the Base.
This specific version is fine because it is specialzed _HashVMImmutableBase, but the remaining cases need to be fixed by even more manual duplication.
We will need three versions of _CompactIterable and _CompactIterator for the three bases. I wonder if there is a way to make it happen automatically?

@rakudrama on https://dart-review.googlesource.com/c/sdk/+/231243/6/sdk/lib/_internal/vm/lib/compact_hash.dart#332
Maybe we need to untangle the mixin behavior there when addressing this.

I agree that the VM is wrong. The keys getter is intended to be lazily backed by the map, and not get locked in until you starts iterating, like every other iterable backed by a collection.
I think I'd put the test in lib.collection, but it's been a little inconsistent so far (Map is in dart:core, LinkedHashMap is in dart:collection, but the Map implementation is really LinkedHashMap, so anything goes, really).

I'll make a fix. Shouldn't be too hard.

There is a 10% regression on  Iterators.poly.Map.int.keys.1 for dart-aot.
This indicates that for (final value in map.keys) is slower for a low trip-count loop.
Dart JIT is not affected.
I have not looked at the generated code, but I suspect that _CompactIterable.get:iterator is now just big enough to make AOT shy about inlining, and as a result .keys.iterator is no longer two inlinings followed by the scalar replacement through load-elimination of the ephemeral keys-iterable. JIT is more aggressive inlining which would explain why it is not affected.
Could AOT be more clever in deciding to inline this kind of target - i.e. if an argument is an allocation and the target just uses the argument for loads, we can expect the final fields of the allocation to be store-forwarded and therefore should not be considered?

as a temporary workaround we could just annotation _CompactIterable.get:iterator with @pragma('vm:prefer-inline'). /cc @lrhn

I have looked at this. The reason for the regression is that get:iterator become slightly more expensive: it accesses _data and _usedData through _HashBase interface that has two implementations _HashVMBase and _HashFieldBase. This means compiler is unable to inline table._data and table._usedData and those become virtual (GDT) calls. Previously we would load them from inside get keys => ... / get values =>  which are declared within mixin and copied into the concrete class, so they were simple field accesses.
We need to get rid of _HashVMBase _HashFieldBase split for this to become better.

I have looked at this. The reason for the regression is that get:iterator become slightly more expensive: it accesses _data and _usedData through _HashBase interface that has two implementations _HashVMBase and _HashFieldBase. This means compiler is unable to inline table._data and table._usedData and those become virtual (GDT) calls. Previously we would load them from inside get keys => ... / get values =>  which are declared within mixin and copied into the concrete class, so they were simple field accesses.
We need to get rid of _HashVMBase _HashFieldBase split for this to become better.

I had forgotten about these base classes.
_CompactIterator.moveNext must have the same problem at _table.isModifiedSince. That would be worth inlining.
How difficult is it to un-split _HashBase? If it is too difficult or a long-term project due to dependencies, perhaps the whole Table -> Iterable -> Iterator scheme could be specialized via mixins.

I have not looked at the generated code, but I suspect that _CompactIterable.get:iterator is now just big enough to make AOT shy about inlining, and as a result .keys.iterator is no longer two inlinings followed by the scalar replacement through load-elimination of the ephemeral keys-iterable. JIT is more aggressive inlining which would explain why it is not affected.

This is polymorphic benchmark so call site does not know which iterable it is iterating.

Is the temporary workaround mentioned in https://github.com/dart-lang/sdk/issues/48282#issuecomment-1621272867 still a feasible thing, trying to see if that would be a quick way to address the flutter regression https://github.com/flutter/flutter/issues/130339

@a-siva that workaround was suggested based on the assumption that performance is affected by the get iterator not being inlined, but that was proven to be not the case (at least for the concrete benchmark I have looked at: https://github.com/dart-lang/sdk/issues/48282#issuecomment-1625241307). Let me look at the flutter regression.

Tried to de-polymorph the code: https://dart-review.googlesource.com/c/sdk/+/313380
(Not sure how to test if performance is better.)

Tried to de-polymorph the code: https://dart-review.googlesource.com/c/sdk/+/313380 (Not sure how to test if performance is better.)

Looks like @jason-simmons has a local setup to measure impact of a change on the Flutter benchmark, should we try your change above to see if it has an impact ?

https://dart-review.googlesource.com/c/sdk/+/313380 did not make a significant difference in the complex_layout_scroll_perf_bad_ios__timeline_summary benchmark on an iPhone 11.
(The runs that I did actually showed a slight increase in frame build times with that patch)

I am working on removing _HashVMBase altogether. I will then check generated code to see if it returns back to where it was before this change.

In case anyone else is running tests on stable dart and confused by this failure, the new test here is expected to fail in 3.1:
eseidel@erics-mbp sdk % dart run tests/lib/collection/map_iterables_consistency_test.dart
Unhandled exception:
Concurrent modification during iteration: _Map len:1.
#0      _CompactIterator.moveNext (dart:collection-patch/compact_hash.dart:710:7)
#1      new _GrowableList._ofOther (dart:core-patch/growable_array.dart:202:26)
#2      new _GrowableList.of (dart:core-patch/growable_array.dart:152:26)
#3      new List.of (dart:core-patch/array_patch.dart:47:28)
#4      check (file:///Users/eseidel/Documents/GitHub/dart-sdk/sdk/tests/lib/collection/map_iterables_consistency_test.dart:47:27)
#5      main (file:///Users/eseidel/Documents/GitHub/dart-sdk/sdk/tests/lib/collection/map_iterables_consistency_test.dart:69:3)
#6      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:296:19)
#7      _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:189:12)
eseidel@erics-mbp sdk % dart --version
Dart SDK version: 3.1.5 (stable) (Tue Oct 24 04:57:17 2023 +0000) on "macos_arm64"

authors: a-siva dcharkes eseidel jason-simmons lrhn mraleph rakudrama