text:
update bing chat icon

Bing Chat has had a proper icon for a while now, and I thought we should freshen up its look.
I created a separate "jailbreak" icon ( BingJbIcon.jsx ) instead of coloring the bg of the bing icon
Type of change

[x] Cosmetic change

How Has This Been Tested?
Self tested on pc and mobile. Everything works the same.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code

The border looks a bit pixelated and I think I prefer the original as it's cleaner, too.

The border looks a bit pixelated and I think I prefer the original as it's cleaner, too.

I guess it depends of the viewing resolution, like on my phone it's really sharp
As for the looks, I'm personnaly not a fan of the original but I respect your opinion 🙂

I absolutely love this design, hands down. Even though the regular Bing AI might have a more visually appealing look, I can't deny my strong dislike for the Sydney design. It just doesn't do it for me, especially with its plain white square appearance. In contrast, @fuegovic brings a modern and captivating vibe to Sydney.

Thanks! I was able to find the svg for what microsoft is using for bing chat. Since they are using different logos for the chat and the search engine itself I thought it could be a good idea to do the same. I feel like using the plain bing logo for the chat mode is a bit like if we were using the plain google logo for palm (I know I'm pushing a bit in this example but you get the idea)

I guess it depends of the viewing resolution, like on my phone it's really sharp

I was wrong about that, it's an issue with my screenshots, they look way more pixelated then it really is. I updated them (they still look worse than in app tho, the logos are high quality svg, not made of pixels 😅)

I do like to honor community contributions with this project and glad to see the pixels were just a resolution problem. I will merge this.

Before doing so, can you add back the regular icon as a separate file? I may still use it for something.

Before doing so, can you add back the regular icon as a separate file? I may still use it for something.

Absolutely, I'll add it back when I'm back in front of my pc

btw there is already a bing svg in that folder (bingchaticon.jsx or something similar), and I don't think it's being used for anything at the moment, it might be a copy of what was used (or not?)

I added back the original one , in the original dir, under BingIconBackup.jsx

authors: danny-avila fuegovic

repo: danny-avila/LibreChat


text:
Xamarin.Auth, latest Prism, and Unity problem

Hey Dan,
Have you tried this library with a UWP app and latest Prism.  I'm getting conflicts due to Unity:
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1700,5): error APPX1101: Payload contains two or more files with the same destination path 'Unity.Abstractions.dll'. Source files:
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1700,5): error APPX1101: C:\Users\admin\.nuget\packages\unity\5.7.3\lib\netstandard2.0\Unity.Abstractions.dll
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(1700,5): error APPX1101: C:\Users\admin\.nuget\packages\unity.abstractions\3.3.0\lib\netstandard2.0\Unity.Abstractions.dll

Any ideas?
cliff

Yeah I'm guessing you're using the Unity package from this repo... at the time I last published it I was in sync with what Prism used for Unity which was the Unity NuGet. That has since changed to Unity.Container which is why you're getting two identical references. I'll make a note of this and try to get an updated package out later this week.

btw feel free to send a PR on this as well :)

one quick noob question, how do i use the Directory.build.props to create a local package without editing the project files?

thanks, i had already sorted it.  should've removed the comment.

source: gharchive/issue

authors: dansiegel powerdude

license: MIT

license_type: permissive

license_source: github-api


text:
Can't scroll page

Page in question at:
http://merrillaudio.isaacrivera.com/#/news
It can't be scrolled. I assume it is re-rendering. Any insights?

Solved the issue, though it was complicated. If the items to be laid out contains images the size of which is unknown, the grid will layout with overlaps once the images are loaded in. I did not see in the documentation any way of addressing this. Adding onload events to the images creates an infinite loop between the render method and the onload, which keeps firing everytime the grid re-renders. So I had to add a onload event to the images conditionally. Having in mind the number of items and keeping a count. So that the second time around I dont add the onload.

Hi there,
It seems most of the open issues are to do with loading images of unknown size, so I will treat this as a feature request and try to work this into the measureItems higher-order component for the next release. #2 #4
Glad you found a way around it in the meantime!

Thanks for replying Dan.
If the items laid out are animating or changing in size due to an image load, that should not prompt a re-render. The component could provide a way to re-layout without re-rendering or perhaps optionally rerendering: Grid.layout.update(false); or some such method, perhaps?

I've updated the measureItems higher-order component with some new options, I wonder if you could give it a try? Something like:
const Grid = measureItems(SpringGrid, { measureImages: true })

authors: dantrain izkrivera

repo: dantrain/react-stonecutter

license: mit

license_source: bigquery


text:
how to get scroll info in FormBuilderTypeAhead widget

Hello, i need to implement an infinite scroll in the suggestions of FormBuilderTypeAhead widget is there a way to get scroll info from this widget ?

Hi @yazanIbrahim,
For more customizations on the FormBuilderTypeAhead kindly refer to the flutter_typeahead package which we are making use of within our package.

authors: danvick yazanIbrahim


text:
use fqdn for all image names when dockerhub is the registry

Signed-off-by: Mukundan Sundararajan 65565396+mukundansundar@users.noreply.github.com
Description
Use FQDN when Dockerhub is set as the default regirstry.
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: #1090
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

thanks @pravinpushkar  (see #1180)

source: gharchive/pull-request

authors: matzew mukundansundar

repo: dapr/cli


text:
Proposal: Allow components to perform custom health checks

In what area(s)?
/area runtime
Describe the feature
Dapr currently already provides an healthz endpoint to check if the instance is healthy. In addition to the health of the Dapr instance I'd also like to be able to check the health of the underlying component infrastructure.
A typical health check for an application that uses Redis for example, would be to send a PING command to Redis every once in a while and check if the database is still up. When using Dapr, it would be weird having to write these kinds of health checks directly in the application code, while all other access to the infrastructure is nicely abstracted away by components.
This can be solved by letting component implementations optionally implement health checks for the underlying infrastructure. Health checks could then be run individually by having the application make a call to the sidecar, for example:
http://localhost:3500/v1.0/healthz/<component_name>
http://localhost:3500/v1.0/healthz/statestore

This would allow for very nice integration with the ASP.NET Core health check mechanism amongst others.
Note: Before code checkin, submit a docs PR on this issue https://github.com/dapr/docs/issues/2406

who can help to check #2923 is the right way?
I have changed about statestore health check.(draft)

I think the component-contrib should be merged to the 1.3 version before the test for a dependency.

Removing this from a Milestone until it has traction again.

Component health checks would be a very useful feature, particularly in pubsub components where it's possible to have a subscription which is disconnected and then is unable to reconnect - in this case what currently happens is the app + dapr sidecar appears to be running but is actually silently unhealthy - it's disconnected from the subscription and not receiving messages, but the only way to find that there is a problem is to check logs - there's no alerts.
If, on the other hand, component health checks were implemented and surfaced through to the dapr sidecar health check endpoint, this would enable, when running in Kubernetes,
(1) the fact that the app / sidecar is unhealthy to be made more visible,
(2) the pod / container to be restarted automatically by k8s and
(3) alerts could be configured, e.g. based on the number of restarts

I propose we prioritize this for 1.8.

Triaged to 1.8.

Instead, can we use a more specific path:
http://localhost:3500/v1.0/healthz/components/<component_name> -> Health of a specific component
http://localhost:3500/v1.0/healthz/components -> Health of all components (all required components should be healthy)

After discussing with @artursouza, following points were discussed:

Pinger interface to remain in components-contrib only.
Making Ping function optional so that it doesn't become mandatory for all components to implement it.
Adding http://localhost:3500/v1.0/healthz/components along with http://localhost:3500/v1.0/healthz/components/ as an endpoint.
All stable components to install correctly this Ping function.
Conformance tests to be added for these stable components and targeted in v1.8.
Later, certification tests to be added for these components for this function in v1.9
Need to publish a PR initially with points 1 to 3 incorporated and an example implementation of one stable component.

@moonchanyong Thanks for your PRs that are already there to cater to this issue. They provide a direction to close this issue. I tried to reach you via https://github.com/dapr/components-contrib/pull/1217#issuecomment-1141696676; in order to try this out for v1.8, I will try doing changes on top of your PRs, thanks.
Please feel free if you want to do the changes yourself and we can collaborate.

Also, IMO, every stable component should have this feature implemented. In addition, this should be part of the conformance tests. The negative scenarios (health returns false) should be added to certification tests - these test changes can land in 1.9.

@artursouza who is going to open the issues and prioritize the work to update the certification tests and implement this in stable components though?

Noting here that the absence of this feature is currently creating a gap in the completion of the Pluggable Component implementation.
service StateStore {
  ...
  rpc Ping(PingRequest) returns (PingResponse) {}
}

Is anything happening on this front? This (or some related) issue currently breaks our environment every once in while. We use a pubsub component that very rarely fails to call the app's /subscribe endpoint, most likely due to an error within our app or our message broker:

time="2023-10-20T11:25:45.801096171Z" level=error msg="rabbitmq pub/sub: error in subscriber for [redacted] in ensureSubscription: channel not initialized" app_id=[redacted] component="pub-sub (pubsub.rabbitmq/v1)" instance=[redacted]-7c9db7fb75-bl6gk scope=dapr.contrib type=log ver=1.11.2
time="2023-10-20T11:25:45.801148276Z" level=warning msg="rabbitmq pub/sub: subscriber is reconnecting in 3s ..." app_id=[redacted] component="pub-sub (pubsub.rabbitmq/v1)" instance=[redacted]-7c9db7fb75-bl6gk scope=dapr.contrib type=log ver=1.11.2
time="2023-10-20T11:25:48.802146207Z" level=info msg="rabbitmq pub/sub: connectionCount: current=0 reference=0" app_id=[redacted] component="pub-sub (pubsub.rabbitmq/v1)" instance=[redacted]-7c9db7fb75-bl6gk scope=dapr.contrib type=log ver=1.11.2

time="2023-10-20T11:25:54.345422725Z" level=error msg="error occurred while beginning pubsub for topic [redacted] on component pub-sub: failed to subscribe to topic [redacted]: failed to subscribe to [redacted]" app_id=[redacted] instance=[redacted]-7c9db7fb75-bl6gk scope=dapr.runtime type=log ver=1.11.2
time="2023-10-20T11:25:54.345490731Z" level=info msg="rabbitmq pub/sub: subscription for [redacted] has context canceled" app_id=[redacted] component="pub-sub (pubsub.rabbitmq/v1)" instance=[redacted]-7c9db7fb75-bl6gk scope=dapr.contrib type=log ver=1.11.2

We experienced this issue with both RabbitMQ as well as Azure Service Bus. So far we haven't been able to pinpoint exactly what's going wrong on our side but imho Dapr is sorely lacking a recovery mechanism. Currently Dapr doesn't react at all and continues "functioning" despite the pubsub component not working properly. One solution would be for the component to report its status and make it queryable via /healthz so that Kubernetes knows to restart the container. Currently Dapr just continues running until we notice our services stop functioning and kill the pod manually.
Fixing this is relatively critical to us, if the requirements are clear we would be willing to tackle this issue.

authors: DeepanshuA amolenk artursouza berndverst maurice-freitag moonchanyong olitomlinson yaron2 yordan-pavlov

repo: dapr/dapr


text:
Update components-contrib to 1.0.0-rc2

Description
Updating components contrib to 1.0.0-rc2 for release.
Issue reference
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] 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


text:
mTLS certificate expiration monitoring (in Sentry Service) docs

This is to document github.com/dapr/dapr#3940
The Sentry Service will check certification expiration hourly and log expirations warnings with a time to expiry beginning 30 days prior to certificate expiration.

/assign

Fixed

authors: berndverst msfussell

repo: dapr/docs


text:
Application Insights Otel collector example version update

What content needs to be created or modified?
The open-telemetry-collector-appinsights.yaml example file in the open telemetry collector applinsights documentation uses opentelemetry-collector-contrib:0.40.0.
https://docs.dapr.io/operations/monitoring/tracing/open-telemetry-collector-appinsights/
Describe the solution you'd like
The opentelementry-collector-contrib has recently released version 0.50.0.
Can the example be updated to the newest version?
Additional context
Is a verification process required to ensure everything is still working as expected?

@fabistb - Thanks for raising this. Would you be able to push a suggested PR change having tested this with the new OTEL version?

@fabistb - Thanks for raising this. Would you be able to push a suggested PR change having tested this with the new OTEL version?

@msfussell sure. I just need a couple of days to test the new OTEL version.

Merged

authors: fabistb msfussell


text:
How to persist after reboot?

Hey @daraosn,
Thanks so much for this. Will this persist over reboot or do we need to edit the configs? What exactly needs to be done?
Thanks

If you're still wondering, do this.

Save https://gist.github.com/iamfionn/48531574f06b4796afcd9e73bc18c6f0 as /home/default/wpa.sh.
Edit it.
Make sure it works.
Edit /bin/wifi_setup.sh to launch it on boot.
Check that 100 seconds after reboot the drone changes over to the WPA network.
Shorten the sleep.
Play with your drone.

authors: iamfionn jaboutboul


text:
rebuild does not work without report-per-database

--rebuild does not generate any output without report per database. I found, that %DBLIST is empty at least at the point where build_incremental_reports is called, but could not find where it's cleared.

Hi,
What command do you use? If I try to reproduce the problem with per database report:
perl pgbadger  --explode -I -O /home/git/pgbadger/report/ /data/pglog/multi-small-files/postgresql-2012-03-20_0[89]*
perl pgbadger  --explode -I -O /home/git/pgbadger/report/ --rebuild

or without, it is just working fine:
 perl pgbadger -I -O /home/git/pgbadger/report/ /data/pglog/multi-small-files/postgresql-2012-03-20_0[89]*
perl pgbadger -I -O /home/git/pgbadger/report/ --rebuild

If you can post a debug output using -v option it could help too.

Does this issue can be closed? Otherwise please give additional the information I've asked.

--rebuild tag use the content of tmp file $TMP_DIR/dblist.tmp which is fed only during some parsing of files.
if you try for the example to use the rebuild param in a container where you never did some parsing without share the $TMP_DIR, the tmpfile is empty, and therefore rebuild won't work.
workaround can be to create manually the tmp dblist file.

authors: darold tbe thomasLeclaire

repo: darold/pgbadger

license: PostgreSQL


text:
Don't show custom errors pane if it is disabled in settings

It is quite annoying to see opened errors pane with "No issues" label for non-dart or even for dart projects on the first editor launch.

thanks! lgtm

authors: agudulin devoncarew

repo: dart-atom/dartlang


text:
Check-in pubspec.lock

So we can track as the example is updated – since it’s not published as a package

While we are at it, do you think it would be worthwhile to update the dependency on angular2 so that we limit to the current minor version like we did with the components?

Checking in the lock file kinda does that – folks can see if they change the dependencies that it was checked-in with.

PTAL?

authors: kevmoo nshahan


text:
windows monospace font has no unicode arrow

oh, oh

Actually, mac monospace (I think both mac and windows use Courier New for this) also hasn't this unicode arrow, but for mac, it falls back to the apple symbols font.

This is still an issue on windows. This doesn't look very professional.

Perhaps there's an arrow symbol common to these fonts?

@filiph Would you mind checking on your Windows machine if this is still an issue?

I can see the arrow on my Windows 10 machine. Closing.

authors: RedBrogdon devoncarew filiph kasperpeulen

repo: dart-lang/dart-pad


text:
Index components are cached or vulcanized

#658
Index is vulcanized, locally cached for 3 hours.
@lukechurch @devoncarew

lgtm

Merging.


text:
Add format for week of year

The DateFormat class does not support W to indicate the week of the year.
References:

https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior
http://momentjs.com/docs/#/displaying/

Adding data is non-trivial, but this actually might not require that. That is, assuming we could do it by just computing the week number (we know already what day the locale starts the week on) and formatting that as a number for the locale. But we'd need to confirm that was sufficient.

authors: adamlofts alan-knight

repo: dart-lang/intl


text:
Internal error for URLs with percent encoding

E.g.
https://pub.dartlang.org/api/packages/http/versions/0.9.2+%40
gives 'Internal error'
whereas the "same" request
https://pub.dartlang.org/api/packages/http/versions/0.9.2+A
gives 404

These are not the same urls since "%40" corresponds to "@".
The version "0.9.2+@" is not a valid semantic version, so we get an semantic version parsing exception.
I think an "Internal error" is not as bad as it sounds, but I can make an update to the API handling to return "400 Bad Request".

CL up for review for package:pub_server: https://codereview.chromium.org/1231753007/

The URL https://pub.dartlang.org/api/packages/http/versions/0.9.2+%40 will now return
{"error":{"message":"Version string \"0.9.2+@\" is not a valid semantic version."}}

authors: mkustermann sgjesse

repo: dart-lang/pub-dartlang-dart


text:
periodic 503 Server error

I use pub to access documentation on packages. Periodically it hangs up. Then I try to go to pub and get:

Error: Server Error
The service you requested is not available yet.
Please try again in 30 seconds.

Natalie W. said it is issues with AppEngine. Kevin M requested me to open this and include http response headers. I hope this is what he wants:

Request URL:http://pub.dartlang.org/
Request Method:GET
Status Code:503 Service Unavailable
Remote Address:72.14.249.27:80
Response Headers
view source
Content-Length:302
Content-Type:text/html; charset=UTF-8
Date:Sat, 28 Jan 2017 03:04:17 GMT
Server:Google Frontend
Request Headers
view source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:_ga=GA1.2.1275874948.1465591297; __utmt=1; __utma=168521888.1457866598.1465573460.1485472865.1485572496.99; __utmb=168521888.1.10.1485572496; __utmc=168521888; __utmz=168521888.1484780674.95.35.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Host:pub.dartlang.org
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

We have switched to a newer, hopefully more stable, AppEngine stack.
@patefacio Do you still see this issue?

Closing the issue for now. Please re-open if this happens again.

authors: mkustermann patefacio


text:
Update to use latest mono_repo config

Fixes https://github.com/dart-lang/pub-dartlang-dart/issues/1294

@isoos thoughts on these failures? https://travis-ci.org/dart-lang/pub-dartlang-dart/jobs/379382443#L572

Fixed...
On Tue, May 15, 2018 at 12:59 PM István Soós notifications@github.com
wrote:

@isoos https://github.com/isoos thoughts on these failures?
https://travis-ci.org/dart-lang/pub-dartlang-dart/jobs/379382443#L572
Hm, probably these should be with await:
https://github.com/dart-lang/pub-dartlang-dart/blob/master/app/lib/frontend/backend.dart#L461
https://github.com/dart-lang/pub-dartlang-dart/blob/master/app/lib/frontend/backend.dart#L515
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/pub-dartlang-dart/pull/1299#issuecomment-389294280,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABCil7UriC9WQctXSJ7crXwwuNCnVnAks5tyzOwgaJpZM4T_83P
.


text:
dart2js: Use JS ASTs for generating code used by type checks

The type flags ($isFoo) and substitution functions ($asFoo) are currently generated as strings.
They should be generated as JS ASTs like all the other properties.
Why?
  - better pretty-printing in unminified code
  - smaller minified code
  - better argument renaming in minified code leading to better gzip compression.
As an example (swarm@r22327), using ASTs will automatically get from
Zv:function(a,b){return this.LD($.i4(this.dU,b))},
$ascX:function (S, T) { return [T]; }}
to:
Zv:function(a,b){return this.LD($.i4(this.dU,b))},
$ascX:function(a,b){return[b]}}

ASTs are now used.

repo: dart-lang/sdk


text:
pub search not finding the google_compute_v1beta12_api package

I searched for 'google_compute_v1beta12_api' but pub search did not find it. Please see screenshot.
However, the page exists: https://pub.dartlang.org/packages/google_compute_v1beta12_api

Attachment:
[Screen Shot 2014-09-08 at 3.03.42 PM.png](https://storage.googleapis.com/google-code-attachments/dart/issue-20855/comment-0/Screen Shot 2014-09-08 at 3.03.42 PM.png) (52.33 KB)

This issue has been moved to dart-lang/pub-dartlang#365.

authors: DartBot sethladd


text:
Spurious compile time errors on 'new ..'

Dart2JS fails the following co19 test with 'Error: 'variable' is not a type' (and 'Error: 'function' is not a type', commenting out the reason for the first error):
Language/07_Classes/6_Constructors/2_Factories_A08_t02.
In this test, 'new C()' should fail because C is unresolved (trusting the comment in the test), and an unresolved type is malformed (ECMA-408, 18.1, p113), and 'new <malformed>()' is a run-time error (ECMA-408, 15,12,1, p61).
The statement on p113 requires a little bit of interpretation, though: 'A type T is malformed iff: .. T has the form id or the form prefix.id, and in the enclosing lexical scope, the name id (respectively prefix.id) does not denote a type'.  The point as that we consider 'does not denote a type' to include "is unresolved".
For the remaining checks the case is clear without any extra interpretation, i.e., we should get a static type warning and a run-time error in all four cases.  The run-time error should be a NoSuchMethodError in the last check, which could have been checked, but isn't.

Fixed by https://codereview.chromium.org/1323573002/

authors: eernstg johnniwinther


text:
pub upgrade hanging

This issue was originally filed by @rbishop-bah

Build that was working until this morning now hanging on pub upgrade, presumably due to just-released polymer, web_components, smoke, observe, etc. packages.
pub upgrade --verbose shows the pub solver churning endlessly.
What version of the product are you using?
1.10.0
On what operating system?
Win 7 x64

This issue has been moved to dart-lang/pub#14.


text:
'pub serve' fails when pubspec.lock has changed

When the pubspec.lock file changes, 'pub serve' fails:
The pubspec.lock file has changed since the .packages file was generated, please run "pub get" aga
in.

This requires users to run pub get and then pub serve again.  A workaround is to alias pub get && pub serve to pub serve
Is this intentional?

This is intentional to not run pub serve on outdated dependencies. There was a change recently that this message is only shown when actually dependencies (or version constraints)  were changed but not for transformer config or similar unrelated changes.

I agree running pub serve on outdated dependencies is bad, but is there a reason pub wouldn't attempt to update the dependencies automatically anymore?

I haven't seen doing it in the past.
This issue should be moved to the pub repository.

This issue was moved to dart-lang/pub#1343

authors: floitschG johnpryan zoechi


text:
DDC isn't renaming invalid static method names

These restrictions are only applied to static fields, not methods:
https://github.com/dart-lang/sdk/blob/master/pkg/dev_compiler/lib/src/compiler/js_names.dart#L287
We may need these for static methods as well:
http://www.ecma-international.org/ecma-262/6.0/#sec-arguments-exotic-objects
Safari 10 is complaining about the following generated code from package:stack_trace's Frame class:
    static caller(level) {
      if (level === void 0) level = 1;
      if (dart.notNull(level) < 0) {
        dart.throw(new core.ArgumentError("Argument [level] must be greater than or equal " + "to 0."));
      }
      return src__trace.Trace.current(dart.notNull(level) + 1).frames[dartx.first];
    }

Chrome and FF don't seem to have a problem with it though.

This may be a Safari bug... I'd have to track down old CL discussion, but first thing I would try is switching it to Object.defineProperty instead, and see if that works. But yeah, if not, we should treat static methods same as fields.

@alan-knight FYI - we're still hitting this on the newly released Safari 10.

Here's the current error message on Safari 10:
Safari 10.0.0 (Mac OS X 10.11.6) ERROR
  TypeError: Attempting to change configurable attribute of unconfigurable property.
  at /Users/vsm/dart/sdk/pkg/dev_compiler/gen/codegen_output/pkg/stack_trace.js:170

Getting similar with Object.defineProperty as well.

And if I try to inspect the existing caller property, I get:
TypeError: 'arguments', 'callee', and 'caller' cannot be accessed in strict mode.

@alan-knight

It looks like this was fixed in Safari (tested in a strict mode function in the console) ... we can investigate if it shows up again

authors: jmesserly vsmenon


text:
Support optimized try-catch in DBC

DBC currently bails out to the unoptimized bytecode on try-catch.

Fixed via https://github.com/dart-lang/sdk/commit/6d66f3dea89027c083af791becbce3dbc6e5d257


text:
Recognize file entry-points that should be accessed as package URIs

Users provide entry points to our tools as command line arguments. In some cases those entry points are inside a the lib directory of the package the user is working on, but are specified as file paths.
This can cause the same library file to be imported both using a file URI and a package URI, causing it to be interpreted as two different libraries.
To help users, we should vet the entry point path against its package configuration, and if the entry point could be referenced using a package URI, use that package URI as the URI of the entry-point instead.

What does "entry point" mean in this context? Is it "Dart library with a main() method?"

Yes, any user supplied file name, as long as there is also a way to resolve package URIs.
For application entry points (library containing the main method), we search for a .packages file relative to that library.
Purely single-file or source based tools, like the formatter, usually don't care what URI the library is identified by, so there is no reason to exempt them.

For application entry points (library containing the main method), we search for a .packages file relative to that library.

Actually, we would search for a .packages file for any entry point.

This would be amazing! I've had a lot of issues filed on my projects related to this very problem. A few examples:
flutter_redux:
https://github.com/brianegan/flutter_redux/issues/35
https://github.com/brianegan/flutter_redux/issues/36
scoped_model:
https://github.com/brianegan/scoped_model/issues/15
This is just the tip of the iceberg :)

Another example of this issue, this time on Stack Overflow: https://stackoverflow.com/questions/50913869/flutter-a-value-of-type-lib1object-cant-be-assigned-to-a-variable-of-type-li

This is now the main issue for tracking this problem.
What does this have to do with the CFE, though? Wouldn't this be handled by the analyzer?

What does this have to do with the CFE

My understanding of the proposal is that the CFE would automatically treat lib/some_file.dart as package:the_package/some_file.dart. This isn't a warning to the user - it's accepting the pattern and attempting to do what the user expects.

Oh, love it!

Until this is solved, can we add a TL;DR for users that followed the various bug threads to here for what the bug is and what is the temporary workaround?

@xster I was thinking if it were a good idea to add a comment to lib/main.dart generated by flutter create to not use relative imports in this file and to not import this file from anywhere.

Face the same problem.
This problem is easily overlooked during development, please fix it.

@peter-ahe-google are you still looking at this?

It's next on my todo list.

Proposed fix https://dart-review.googlesource.com/c/sdk/+/78246

Is it possible that the fix will be included in the Dart 2.1 release?

@vanesyan it's looking good, but I can't promise anything.

authors: brianegan lrhn matanlurey mit-mit natebosch peter-ahe-google vanesyan xster xuexin zoechi


text:
VM: Long CheckClass chains

dart2js (running from snapshot) has the following code for instruction.next.
              ;; CheckClass:24(v8 T{Type: class 'HInstruction'} Cids[17: HTypeInfoExpression etc.  cid 1389-1404 | HLocalValue etc.  cid 1406-1410 | HBitNot etc.  cid 1412-1414 | HLessEqual etc.  cid 1417-1421 | HBitXor etc.  cid 1423-1427 | HRemainder etc.  cid 1429-1434
0x7fe6f7508676            testb rcx,1
0x7fe6f7508679            jz 0x00007fe6f7508ce5
0x7fe6f750867f            movzxwq rdx,[rcx+0x1]
0x7fe6f7508684            addl rdx,0xfffffa93
0x7fe6f750868a            cmpl rdx,0xf
0x7fe6f750868d            jna 0x00007fe6f750874a
0x7fe6f7508693            addl rdx,-0x11
0x7fe6f7508696            cmpl rdx,4
0x7fe6f7508699            jna 0x00007fe6f750874a
0x7fe6f750869f            addl rdx,-6
0x7fe6f75086a2            cmpl rdx,2
0x7fe6f75086a5            jna 0x00007fe6f750874a
0x7fe6f75086ab            addl rdx,-5
0x7fe6f75086ae            cmpl rdx,4
0x7fe6f75086b1            jna 0x00007fe6f750874a
0x7fe6f75086b7            addl rdx,-6
0x7fe6f75086ba            cmpl rdx,4
0x7fe6f75086bd            jna 0x00007fe6f750874a
0x7fe6f75086c3            addl rdx,-6
0x7fe6f75086c6            cmpl rdx,5
0x7fe6f75086c9            jna 0x00007fe6f750874a
0x7fe6f75086cf            cmpl rdx,7
0x7fe6f75086d2            jz 0x00007fe6f750874a
0x7fe6f75086d8            addl rdx,-9
0x7fe6f75086db            cmpl rdx,2
0x7fe6f75086de            jna 0x00007fe6f750874a
0x7fe6f75086e4            addl rdx,-4
0x7fe6f75086e7            cmpl rdx,1
0x7fe6f75086ea            jna 0x00007fe6f750874a
0x7fe6f75086f0            addl rdx,-3
0x7fe6f75086f3            cmpl rdx,3
0x7fe6f75086f6            jna 0x00007fe6f750874a
0x7fe6f75086fc            cmpl rdx,5
0x7fe6f75086ff            jz 0x00007fe6f750874a
0x7fe6f7508705            addl rdx,-7
0x7fe6f7508708            cmpl rdx,5
0x7fe6f750870b            jna 0x00007fe6f750874a
0x7fe6f7508711            addl rdx,-7
0x7fe6f7508714            cmpl rdx,3
0x7fe6f7508717            jna 0x00007fe6f750874a
0x7fe6f750871d            addl rdx,-5
0x7fe6f7508720            cmpl rdx,4
0x7fe6f7508723            jna 0x00007fe6f750874a
0x7fe6f7508729            addl rdx,-6
0x7fe6f750872c            cmpl rdx,1
0x7fe6f750872f            jna 0x00007fe6f750874a
0x7fe6f7508735            addl rdx,-4
0x7fe6f7508738            cmpl rdx,2
0x7fe6f750873b            jna 0x00007fe6f750874a
0x7fe6f7508741            cmpl rdx,7
0x7fe6f7508744            jnz 0x00007fe6f7508ce5
  ;; v19 <- LoadField(v8 T{Type: class 'HInstruction'}, 64 {next} [nullable dynamic], immutable=0) T{Type: class 'HInstruction'?}
0x7fe6f750874a            movq rdx,[rcx+0x3f]

The code seems to exclude a lot of little holes in a ~90 class hierarchy.

Can the VM do something to tell that the holes are actually in the hierarchy? One possible reason for holes is abstract classes. Another is that some elements of the hierarchy are rare. We don't care about a false positive for the abstract class since there cannot be an instance.

If the set of Cids must be checked as-is, a table of ~90 bytes would be fewer instructions, fewer branch mispredictions, and about the same bytes, e.g. something like:

movzxwq rdx,[rcx+0x1]
addl rdx,0xfffffa93
cmpl rdx,90
ja deopt
lea r11,[rip+xxx]
test [r11+rdx],1
jz deopt

/cc @mraleph

There are three problems here (potentially in reverse order of importance to solve them):

There are code paths in the call specializer that emit polymorphic CheckClass instructions without applying any sort of cids range expansion that we apply to polymorphic calls. The holes you see are simply never observed classes. However even this expansion would not fully help here because CID expansion algorithms that we have require classes to be finalized and classes are not finalized in app-jit training unless they are actually allocated - meaning that some holes will nevertheless remain.
Backend code pattern for CheckClass is inefficient and should indeed balance between using code driven and data driven approaches.
These CheckClass instructions are redundant to begin with given the strong mode: HInstruction is non-interface type and no subclass overrides get:next - meaning that CheckClass should be replaced with CheckNull instead.

@aartbik Aart, could you look into using static type information better in the JIT pipeline (e.g. eliminating check classes like the one above)?

Small stand-alone reproducer:
abstract class A {
A next;
}
class B extends A {
B(A n) {
this.next = n;
}
}
abstract class C extends A {
}
class D extends C {
D(A n) {
this.next = n;
}
}
yields for:
while (i != null) {
A next = i.next;
....
i = next;
}
this code:
    ;; CheckClass:24(v6 T{!null} Cids[2: B etc.  cid 1025 | D etc.  cid 1027])

0x7fbe4683bab4    f6c101                 testb rcx,1
0x7fbe4683bab7    0f8472000000           jz 0x00007fbe4683bb2f
0x7fbe4683babd    480fb75101             movzxwq rdx,[rcx+0x1]
0x7fbe4683bac2    81fa01040000           cmpl rdx,0x401
0x7fbe4683bac8    740c                   jz 0x00007fbe4683bad6
0x7fbe4683baca    81fa03040000           cmpl rdx,0x403
0x7fbe4683bad0    0f8559000000           jnz 0x00007fbe4683bb2f
;; v13 <- LoadField(v6 T{!null}, 8 {next} [nullable dynamic]) T{Type: class 'A'?}
0x7fbe4683bad6    488b5107               movq rdx,[rcx+0x7]

With AOT, right after ComputeSSA:
B3[target]:20
PushArgument(v4)
CheckNull:24(v4)
v11 <- StaticCall:26( get:next<0> v4)
In contrast, JIT, right after ComputeSSA:
B3[target]:20
PushArgument(v6)
v13 <- InstanceCall:24( get:next<0>, v6 IC[2: D cnt:1 trgt:'A.get_next' | B cnt:1 trgt:'A.get_next'])

@aartbik the difference between AOT and JIT is due to AOT running global closed world analysis passes on Kernel before invoking VM compilation pipeline.

For sure, I just including the AOT and JIT code for the smaller example to contrast the differences that exist right now. The goal is to make JIT behave as good as the closed world case while staying safe wrt subtleties of dynamic class loading.

A quick prototype yields the same code for JIT (by adding a CHA deopt clause on class A):

;; v11 <- LoadField(v4 T{Type: class 'A'}, 8 {next} [nullable dynamic]) T{Type: class 'A'?}
0x7fdb19d712ea    488b5107               movq rdx,[rcx+0x7]
and yields about 10% improvement on the standalone reproducer (which has just two holes in the sparse type hierarchy).
Codesize and runtime improvements for just the core loop in dart2js  should be even better (do you have a particular command line invocation you want me to check specifically?).

@aartbik - Stephen is out on vacation, but I'd be happy to help try it out in dart2js.
He probably came across this by profiling dart2js during our SSA-optimizations. We have a couple compile-time benchmarks you can try in golem, but I can also try it out on a large application and let you know if I see some measurable difference there. Do you have a CL I can patch in?

We can just start by uploading to Golem and looking if anything improves on dart2js-compile target.

I started a golem run. In the meanwhile, you can try out the patch:
https://dart-review.googlesource.com/c/sdk/+/64440
Still, I would be interested in the exact way of invoking dart2js so that optimize.dart is exercised. In my runs of dart2js (on other dart code or on patch), this code is never run.

Will do, thanks!
It is always enabled :) - could it be matter of getting a complex enough input program?

Thanks for the hints. I was able to exercise some of the methods through JIT. Strangely enough not the visitBasicBlock shown above, but at least the very similar method below.
optimize.dart_SsaCheckInserter_visitBasicBlock
which looks like
 while (instruction != null) {
      HInstruction next = instruction.next;
      instruction = instruction.accept(this);
      instruction = next;
    }

When JITted, the intermediate on input for the next getter looks like:
     v11 <- InstanceCall:24( get:next<0>, v6 IC[
        55: HParameterValue cnt:1326 trgt:'HInstruction.get_next' |
              HConstant cnt:2700 trgt:'HInstruction.get_next' |  **very long list** )

Before this would expand to a very long chain. But with the new improvement, the while loop (which enables removing the CheckNull) goes directly into the LoadField:
        ;; Branch if StrictCompare:12(!==, v6, v0) T{bool} goto (3, 4)
0x7fae196a97c1    493b4668               cmpq rax,[thr+0x68]   null
0x7fae196a97c5    0f848f020000           jz 0x00007fae196a9a5a
        ;; B3
        ;;   Loop 0
        ;; v11 <- LoadField(v6 T{Type: class 'HInstruction'}, 64 {next} [nullable dynamic]) T{Type: class 'HInstruction'?}
0x7fae196a97cb    488b483f               movq rcx,[rax+0x3f]

Golem runs are mainly in the noise, even for dart2js-compile (but unsure at this point if that exercises the ssa code above). As expected, however, the microbenchmark that targets this specific case improves quite a bit (and this one "only" has two "holes" in the class hierarchy):
x86:
NextLoop (Intel Core i5)   2.861%
NextLoop (Intel Xeon)      5.721%

ia32:
NextLoop (Intel Core i5)   7.131%
NextLoop (Intel Xeon)     17.91%

armv7:
NextLoop (Odroid-C2)      58.15%

armv8:
NextLoop (Odroid-C2)      55.71%

Investigating the "deopt storm". Without background threads I see, for example the following method compiled twice in unopt mode (once per test run):
Compiling  unopt : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
Compiling  unopt : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
With background threads, the same method goes into some sort of compilation loop, clearly in some nasty interaction with CHA.
Compiling  unopt : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
Compiling opt  : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
....
Compiling opt  : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
Compiling opt  : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
Compiling opt  : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
Compiling opt  : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
Compiling opt  : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
Compiling opt  : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
Compiling opt  : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.

The cycle actually involves two methods, and it is not so much a "deopt storm" as a "recompilation storm" (but of course due to CHA). Both are compiled in the background, and on the same isolate, but both compilations fail, and, even though both are marked with
function.set_is_background_optimizable(false);
failure of one seems to trigger the other right away, round and round we go.
Compiling JIT opt : dart:io__File@14069316_open_<anonymous closure> on isolate vm-service 0x55d1cc76a900
  do not compile again background: dart:io__File@14069316_open_<anonymous closure>
Compiling JIT opt : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316. on isolate vm-service 0x55d1cc76a900
  do not compile again background: dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316.
Compiling JIT opt : dart:io__File@14069316_open_<anonymous closure> on isolate vm-service 0x55d1cc76a900
  do not compile again background: dart:io__File@14069316_open_<anonymous closure>
Compiling JIT opt : dart:io__RandomAccessFile@14069316__RandomAccessFile@14069316. on isolate vm-service 0x55d1cc76a900

I have a fix for the cycle. Two functions remained in the queue of a background thread, but even though set_is_background_optimizable was reset, it kept on looping in this thread rather than releasing it and let the foreground thread take it from there.
This fixes the timeout consistently. Even with this, however, the test sometimes fails as follows, which must be addresses too.
'Uint8List' is not a subtype of type 'String' of 'string'
>testee>err> #0      Utf8Encoder.convert (dart:convert/utf.dart)

With the looping out of the way, this was easy to debug. Both AOT and JIT rely on ICData in subsequent codegen, which can be a mismatch with the static class determined by the new code. For now, I added a bail in such (rare but possible) cases. In the long run we may want to rely on statically determined information instead!

authors: aartbik mraleph rakudrama sigmundch


text:
Proposal: please add [Iterable.all]

  /// Checks whether all elements of this iterable satisfies [test].
  bool all(bool test(E element));

Example:
// Easy to understand
var allCompleted = tasks.all((t) => t.completed);

// Hard to understand
var allCompleted = !tasks.any((t) => !t.completed);

Dart SDK Version = 2.0.0-dev.68.0

There is a method like that. It is called Iterable.every.

authors: jolleekin mraleph


text:
Analyzer: Interface ambiguity not detected

Cf. issue #35278, dartanalyzer fails to report an error for a declaration of a class whose interface contains an ambiguous member signature (that is, none of the superinterfaces provide a member signature whose function type is a subtype of that of them all). Here is an example:
abstract class O {}
abstract class P { O f(O o); }
class OI implements O {}
class PI implements P { OI f(covariant OI o) => null; }
class P2I extends PI implements P {}

In this situation, P2I has superinterfaces PI and P, and they provide member signatures with function types O Function(O) respectively OI Function(OI) for f, and none of those is a subtype of the other.
So the computation of the interface of P2I fails because none of the signatures for f can be used, and this should be reported as a compile-time error.
Presumably, the reason why this case has not been covered before is that we have covariance for a parameter in PI, which makes that signature an unlikely candidate for being a subtype of the others (because it will have a more special argument type), but at the same time that signature offers a covariantly specialized return type (which makes it likely that other signatures will not be subtypes of this one). So in that sense it's a worst case scenario, and this combination of a covariant return type and a covariant parameter type is likely to create a similar conflict whenever it is used.
From a practical point of view, the developer can disambiguate the code by adding an explicit (possibly abstract) declaration of f in the body of P2I: OI f(OI o);. But it is an error when there is no such declaration, following the general principle that we do not invent signatures that do not occur in the program.
We actually discussed (in #31596) how to select the signature for a method when there is an inherited declaration with a more special argument type and some source of covariance, and I argued in https://github.com/dart-lang/sdk/issues/31596#issuecomment-355571973 that we could get a better typing in some situations by allowing such signatures to become the signature of that member in the interface of the class (even though they correspond to function types that are not subtypes of them all: OI Function(OI) is not a subtype of O Function(O)), but we ended up concluding that it is only the function type of the signature that matters.

Analyzer now reports an error for P2I:

Superinterfaces don't have a valid override for 'f': PI.f (OI Function(OI)), P.f (O Function(O)).

authors: eernstg srawlins


text:
Type canonicalization not consistently preserved / reset with ddc hot restart

Note: reproduction of this issue requires a checkout of https://github.com/flutter/flutter/pull/34252 and https://github.com/dart-lang/webdev/pull/440
Dart VM version: 2.3.3-dev.0.0.flutter-3166bbf24b (Tue Jun 11 16:24:18 2019 +0200) on "macos_x64"
Compiling the flutter gallery via the dev compiler/kernel initially succeeds. Applying a hot restart fails in different ways, depending on which library changed.
Case 1: Trigger Hot restart without changing anything
The hot reload fails due to a type error after re-invoking main:
The following assertion was thrown building IconTheme(IconThemeData#4acba(color:
dart_sdk.js:19255 Color(0xff007aff))):
dart_sdk.js:19255 Expected a value of type '(AnimationStatus) => void', but got one of type '(AnimationStatus) => void'

This corresponds to https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/animation/listener_helpers.dart#L170
Case 2: Change something upstream of listener_helpers.dart, like animation.dart.
The hot reload fails due to a slightly different type error
Uncaught (in promise) Error: Expected a value of type '(RawKeyEvent) => void', but got one of type '(RawKeyEvent) => void'

This corresponds to raw_keyboard.dart https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/services/raw_keyboard.dart#L477
Case 3: Change something in foundation.dart
Mostly success!

This seems to be the same as https://github.com/flutter/flutter/issues/34289

Potential workaround: always reload the root module on start.

@jakemac53 @vsmenon has there been any more investigation on fixes vs workarounds here?

I have not been able to isolate the root cause yet.
Are you all still seeing the behavior?

It looks like @grouma is getting close to landing the webdev changes the tool needs. I'll wait until that lands and then start from there

Okay, I've isolated the root cause.  Will work on a fix.
DDC hoists complex type expressions as an optimization - e.g., FrogColor<Color>.  It does not clear / recompute these on a hot restart.
After a restart, FrogColor<Color> canonicalizes differently and does not match the hoisted one.

Here's a unit test repro:
https://dart-review.googlesource.com/c/sdk/+/109100

No update on this since last week.
@jonahwilliams - how blocking is this right now?

I can't land the dwds integration until this is fixed. In the meantime, I'm using a full browser restart which is good enough. I don't believe anyone is on the flutter based workflow yet though.

Fix / workaround here:
https://dart-review.googlesource.com/c/sdk/+/109100
The relevant bit is a one-liner if you are able to try it out.  Fixes @kevmoo 's repro and the unit test.

I will take a look tomorrow and report back, thank you!

I'm still getting some odd type errors when hot restarting with this change applied.  Interestingly this is coming from the precompiled dart sdk and not from any user code (though that may be stopping me from getting to the user code)
Uncaught (in promise) Error: Type '_Future<void>' should be '_Future<void>' to implement expected type 'Future<void>'.
    at Object.throw_ [as throw] (dart_sdk.js:3994)
    at Object.castError (dart_sdk.js:3954)
    at Object.cast [as as] (dart_sdk.js:4276)
    at Function.check_C [as _check] (dart_sdk.js:3910)
    at Array.[dartx.add] (dart_sdk.js:7828)
    at _engine._FontManager.__.registerAsset (dart_sdk.js:128184)
    at _engine.FontCollection.new.registerFonts (dart_sdk.js:128130)
    at registerFonts.next (<anonymous>)
    at onValue (dart_sdk.js:28863)
    at async._RootZone.new.runUnary (dart_sdk.js:28751)
    at _FutureListener.then.handleValue (dart_sdk.js:24677)
    at handleValueCallback (dart_sdk.js:25144)
    at Function._propagateToListeners (dart_sdk.js:25176)
    at _Future.new.[_completeWithValue] (dart_sdk.js:25037)
    at async._AsyncCallbackEntry.new.callback (dart_sdk.js:25055)
    at Object._microtaskLoop (dart_sdk.js:28962)
    at _startMicrotaskLoop (dart_sdk.js:28968)
    at dart_sdk.js:25378
DartError @ dart_sdk.js:5152
throw_ @ dart_sdk.js:3994
castError @ dart_sdk.js:3954
cast @ dart_sdk.js:4276
check_C @ dart_sdk.js:3910
[dartx.add] @ dart_sdk.js:7828
registerAsset @ dart_sdk.js:128184
registerFonts @ dart_sdk.js:128130
onValue @ dart_sdk.js:28863
runUnary @ dart_sdk.js:28751
handleValue @ dart_sdk.js:24677
handleValueCallback @ dart_sdk.js:25144
_propagateToListeners @ dart_sdk.js:25176
[_completeWithValue] @ dart_sdk.js:25037
(anonymous) @ dart_sdk.js:25055
_microtaskLoop @ dart_sdk.js:28962
_startMicrotaskLoop @ dart_sdk.js:28968
(anonymous) @ dart_sdk.js:25378
Promise.then (async)
_scheduleImmediateWithPromise @ dart_sdk.js:25376
_scheduleImmediate @ dart_sdk.js:25382
_scheduleAsyncCallback @ dart_sdk.js:28982
_rootScheduleMicrotask @ dart_sdk.js:29155
scheduleMicrotask @ dart_sdk.js:28771
[_asyncComplete] @ dart_sdk.js:25054
complete @ dart_sdk.js:24580
(anonymous) @ dart_sdk.js:72343
_checkAndCall @ dart_sdk.js:4198
dcall @ dart_sdk.js:4203
(anonymous) @ dart_sdk.js:93132
load (async)
[_addEventListener] @ dart_sdk.js:50826
[dartx.addEventListener] @ dart_sdk.js:50816
[_tryResume] @ dart_sdk.js:93113
_EventStreamSubscription.new @ dart_sdk.js:93133
listen @ dart_sdk.js:92937
request @ dart_sdk.js:72337
load @ dart_sdk.js:117140
runBody @ dart_sdk.js:28882
_async @ dart_sdk.js:28910
load @ dart_sdk.js:117137
registerFonts @ dart_sdk.js:128089
runBody @ dart_sdk.js:28882
_async @ dart_sdk.js:28910
registerFonts @ dart_sdk.js:128086
webOnlySetAssetManager @ dart_sdk.js:116863
runBody @ dart_sdk.js:28882
_async @ dart_sdk.js:28910
webOnlySetAssetManager @ dart_sdk.js:116854
webOnlyInitializePlatform @ dart_sdk.js:116844
runBody @ dart_sdk.js:28882
_async @ dart_sdk.js:28910
webOnlyInitializePlatform @ dart_sdk.js:116839
main @ main_web_entrypoint.dart:5
runBody @ dart_sdk.js:28882
_async @ dart_sdk.js:28910
main$0 @ main_web_entrypoint.dart:4
Function.call$0 @ client.js:26095
call$0 @ client.js:24884
(anonymous) @ client.js:8189
(anonymous) @ client.js:3096
call$2 @ client.js:11462
call$1 @ client.js:11448
runUnary$2$2 @ client.js:12775
call$0 @ client.js:11835
_Future__propagateToListeners @ client.js:3197
_complete$1 @ client.js:11665
complete$1 @ client.js:11505
complete$1 @ client.js:11419
_asyncReturn @ client.js:3069
(anonymous) @ client.js:8226
(anonymous) @ client.js:3096
call$2 @ client.js:11462
call$1 @ client.js:11448
runUnary$2$2 @ client.js:12775
call$0 @ client.js:11835
_Future__propagateToListeners @ client.js:3197
call$0 @ client.js:11764
_microtaskLoop @ client.js:3253
_startMicrotaskLoop @ client.js:3259
call$1 @ client.js:11368
invokeClosure @ client.js:1206
(anonymous) @ client.js:1225
childList (async)
call$1 @ client.js:11378
_scheduleAsyncCallback @ client.js:3272
_rootScheduleMicrotask @ client.js:3395
_asyncComplete$1 @ client.js:11689
complete$1 @ client.js:11489
call$1 @ client.js:17497
call$1 @ client.js:18524
invokeClosure @ client.js:1206
(anonymous) @ client.js:1225
load (async)
_addEventListener$3 @ client.js:17310
addEventListener$3 @ client.js:17304
addEventListener$3$x @ client.js:2881
_tryResume$0 @ client.js:18504
_EventStreamSubscription$ @ client.js:6711
HttpRequest_request @ client.js:6692
(anonymous) @ client.js:8217
(anonymous) @ client.js:3096
call$2 @ client.js:11462
_asyncStartSync @ client.js:3061
_getDigests @ client.js:8229
(anonymous) @ client.js:8142
(anonymous) @ client.js:3096
call$2 @ client.js:11462
call$1 @ client.js:11448
runUnary$2$2 @ client.js:12775
call$0 @ client.js:11835
_Future__propagateToListeners @ client.js:3197
call$0 @ client.js:11764
_microtaskLoop @ client.js:3253
_startMicrotaskLoop @ client.js:3259
call$1 @ client.js:11368
invokeClosure @ client.js:1206
(anonymous) @ client.js:1225
childList (async)
call$1 @ client.js:11378
_scheduleAsyncCallback @ client.js:3272
_rootScheduleMicrotask @ client.js:3395
_asyncComplete$1 @ client.js:11689
complete$1 @ client.js:11489
(anonymous) @ VM159:3
Primitives_applyFunction @ client.js:897
Function_apply @ client.js:4477
_callDartFunctionFast @ client.js:6664
(anonymous) @ client.js:6655
Promise.then (async)
then$2 @ client.js:8860
then$2$x @ client.js:2977
(anonymous) @ client.js:8134
(anonymous) @ client.js:3096
call$2 @ client.js:11462
_asyncStartSync @ client.js:3061
hotRestart @ client.js:8199
call$0 @ client.js:24748
Primitives_applyFunction @ client.js:894
Function_apply @ client.js:4477
_callDartFunctionFast @ client.js:6664
(anonymous) @ client.js:6655
(anonymous) @ VM157:1
Show 51 more frames

Thanks for checking - can you give me repro steps?

checkout https://github.com/flutter/flutter/pull/34252. You may need to force the flutter tool to be rebuilt by deleting bin/cache/flutter_tools.*

checkout flutter/engine following the steps at https://github.com/flutter/flutter/wiki/Setting-up-the-Engine-development-environment. You should have an engine directory adjacent to the flutter directory to make the following steps simpler.

(From here on assuming that flutter/engine is located at engine/src/flutter)

Apply your diff to the dart-sdk located at engine/src/third_party/dart

Set up the gn configuration with ./flutter/tools/gn --unopt --full-dart-sdk and build ninja -C out/host_debug_unopt.

(From here on assuming we're in flutter/flutter)

in flutter/examples/flutter_gallery run flutter run --local-engine=host_debug_unopt -d chrome

Attempt hot restart after build finishes (R)

The above CL should unblock Flutter Web when it rolls in.  I'll keep this issue open to implement a cleaner solution to delineate state that should and should not (internal type tables) be reset.
@jonahwilliams - I'm tentatively lowering the priority here as I think you're unblocked.  Please let me know if you still see the issue.

@nshahan this also looks similar to the bug we were debugging.

authors: jonahwilliams kevmoo srawlins vsmenon


text:
consider dropping most of symbol information (uris and names) when using dwarf stacks

Usually we recommend using obfuscation as a way to reduce code size because it shrinks identifiers (method names and library uri-s). The size drop is rather noticeable on large applications.
We could consider taking this one step further - most of the symbol information is completely unnecessary when running in AOT mode with dwarf-stack traces, so we could consider replacing completely dropping library uri-s and replacing string based symbol names with global numbering (represented as Smi-s).
This might allow to remove significant number of strings from AOT snapshot and thus shrink it.
/cc @mkustermann

@mraleph, @mkustermann, @a-siva - do you have a sense for how much this might help a w/ memory usage of a typical ~large sized Flutter app?

(esp. in light that the Dart heap isn't generally the majority of a Flutter app's RSS)

For customer: money, this could reduce the snapshot size by as much as 9 megabytes uncompressed.

@dnfield are you running with DWARF stack traces & looking at stripped .so file? I am surprised so much strings are left. Unstripped SO would contain all kinds of nonsense including debug info

You are right. I had dwarf stack traces but forgot to strip.
With with a stripped dwarf stack trace app.so, it goes from ~2.8 to ~1.75MB of strings using obfuscation. It's not clear to me how much more would be saved by using numeric identifiers beyond what obfuscation can do here.

According to heapsnapshot of a large application there are actually 5Mb of strings with the following ownership breakdown:
total: 5083628
Instance.@28: 60 0.00%
Instance.@32: 272 0.01%
Instance.@64: 365 0.01%
Instance.@44: 383 0.01%
Instance.@48: 383 0.01%
Instance.@52: 400 0.01%
Instance.@24: 462 0.01%
UnlinkedCall.target_name_: 529 0.01%
Instance.@20: 1578 0.03%
Library.name_: 1748 0.03%
Instance.@92: 5499 0.11%
Instance.@12: 6053 0.12%
Script.url_: 16903 0.33%
Instance.@8: 17551 0.35%
Field.name_: 95561 1.88%
Library.private_key_: 96778 1.90%
Instance.@16: 131513 2.59%
Function.name_: 230479 4.53%
Class.name_: 391934 7.71%
%shared: 1937408 38.11%
Array: 2147769 42.25%

So there is maybe 15% of strings originating from program structure. (maybe slightly more because some of these are also in %shared section).

authors: devoncarew dnfield mraleph


text:
Provide support for code completing expressions in the debug console

Currently the Debug Console in IDEs (where you can type debug expressions while at breakpoints) does not have any code completion, so you have to type full expressions without any assistance. This would presumably need to be an API on the VM Service/DDS.
In the debug adapter protocol the request looks like this:
interface CompletionsArguments {
  frameId?: number;
  text: string;
  column: number;
  line?: number;
}

text is the expression the user has typed and line/col is where the completion was invoked.
The results are an array like this:
interface CompletionItem {
  label: string;
  text?: string;
  sortText?: string;
  type?: CompletionItemType;
  start?: number;
  length?: number;
  selectionStart?: number;
  selectionLength?: number;
}

All fields except label are optional, so in the first instance just an array of strings would be usable.
Ideally, the completion should include fields based on the runtime types of the objects/fields (similar to what we get in hovers) rather than just the static type and it should work in complex expressions, like foo.bar + foo.ba^ (where ^ is where completion is being invoked).
As well as the IDEs, this may be something DevTools could use too (https://github.com/flutter/devtools/issues/2572).
@bkonyi @jacob314 @devoncarew

I don't know whether it's still being used by IntelliJ, but at one point we added an analysis server protocol for this purpose (see execution.getSuggestions).

I don't know whether it's still being used by IntelliJ, but at one point we added an analysis server protocol for this purpose (see execution.getSuggestions).

Ah interesting, I hadn't noticed that.
Although, for the debug adapter for VS Code (and any standalone debug-adapter-protocol implementation that might be extracted from it) there's no ability to talk to the language server, so this would only be usable if exposed through the VM Service (or DDS) - which presumably would require an analysis server (somewhat similar to being described in https://github.com/flutter/devtools/issues/2572?).

Ah interesting, I hadn't noticed that.
Although, for the debug adapter for VS Code (and any standalone debug-adapter-protocol implementation that might be extracted from it) there's no ability to talk to the language server, so this would only be usable if exposed through the VM Service (or DDS) - which presumably would require an analysis server (somewhat similar to being described in https://github.com/flutter/devtools/issues/2572?).

authors: DanTup bwilkerson


text:
Analyzer should warn when patterns are used but not required

Given the following code:
void f(int x) {
  var (num a) = x;
}

the analyzer should warn that the variable pattern is not required and the code could be rewritten as
void f(int x) {
  num a = x;
}

That's what I was originally thinking. An alternative would be to find common patterns over time and add support as users run into these cases.

As far as adding them over time, each such change could be expensive to add, as it could require cleaning the Dart SDK, google3, flutter/flutter, flutter/engine, flutter/plugins, flutter/packages, flutter/cocoon, and the Flutter customer test repos. The ROI is not good there.
Alternatively, writing quick assists to convert trivial patterns into non-patterns can be done incrementally without the clean-up cost, and could be pretty friendly to users.
Maybe it wouldn't be that much work to walk through the spec and dream up as many "trivial pattern" examples as we can early on, to create a warning.

@bwilkerson @srawlins - do we need this on the stable milestone?  Can we move to cleanup?

I vote 'cleanup' milestone.

authors: bwilkerson srawlins vsmenon


text:
[cfe, inline classes] Type inference in the CFE seems to ignore some parts of the context type

Consider the following program:
inline class I<X, Y> {
  final X x;
  I(this.x);
}

void main() {
  I<int, String> i = I(1);
}

This program is accepted by the analyzer, but the common front end reports the following compile-time error:
n012.dart:7:22: Error: A value of type 'I<int, dynamic>' can't be assigned to a variable of type 'I<int, String>'.
  I<int, String> i = I(1);
                     ^

It is as if the context type schema were computed to be something like I<int, _> or I<int, dynamic> rather than I<int, String>, which causes the declaration to be type incorrect.

Closing: This is a duplicate of https://github.com/dart-lang/sdk/issues/51146.


text:
Failures on [cfe] Add ClassMember.memberKind and .getTearOff

There are new test failures on [cfe] Add ClassMember.memberKind and .getTearOff.
The tests
co19/LanguageFeatures/Extension-types/superinterfaces_of_extension_type_A05_t07 CompileTimeError (expected Pass)

are failing on configurations
cfe-strong-linux
cfe-weak-linux
dart2wasm-linux-chrome
dart2wasm-linux-d8
vm-mac-debug-arm64
vm-mac-release-arm64

@eernstg Do we have any specification on whether/when we should report errors on property/method and getter/setter conflicts in extension types? I can't seem to guess what co19 expects.

The test co19/LanguageFeatures/Extension-types/superinterfaces_of_extension_type_A05_t07 should be updated, because it expects no errors in a situation where there is a setter/getter signature conflict (and they should be reported here, just as they are reported for classes etc.).
This test is presumably intended to verify that there is no constraint like the override correctness that we enforce with class member override relations. In particular, it's OK to redeclare a getter (in this case: an implicitly induced external getter) as a method.
It looks like the setter/getter signature conflict is an accident, and in that case the test could just use external final int id2; to avoid introducing the setter in the first place.

I created a co19 issue here: https://github.com/dart-lang/co19/issues/2335.

The test has now been updated and matches our expectations.


text:
[analyzer] Questionable error message with non-exhaustive switch

Thanks to @sgrekhov for bringing up this situation. Consider the following program:
sealed class A {
  final int field;
  A(this.field);
}

class B extends A {
  B(super.field);
}

class C extends A {
  C(super.field);
}

int test(A a) => switch (a) { C(field: 0) as C => 0, C _ => 1 };

void main() {
  test(B(1));
}

With a fresh analyzer (a967ead7e9651f9698a39e6fd4d59a1ed8ed45d2), this program is rejected with the following error message:
  error • n023.dart:9:18 • The type 'A' is not exhaustively matched by the
          switch cases since it doesn't match 'B()'. Try adding a wildcard
          pattern or cases that match 'B()'. •
          non_exhaustive_switch_expression

It is perfectly fine that the program has this error—the exhaustiveness analysis cannot prove that the switch expression is exhaustive, even though it is actually exhaustive. The analysis has to stop at some point, and this case is outside that limit.
However, the error message is confusing. In particular, there are two interpretations of the error message that do not add up to a true statement, and I have difficulties finding an interpretation that makes the statement true.
Assume that the message means "obtain an instance of B; that instance will give rise to a soundness issue because no case matches and there's no value to return". This is not true, because an instance of B will actually be handled in the sense that the type cast as C will throw.
Alternatively, assume that the message means "obtain an instance whose run-time type is a subtype of B; ... [same danger]". This is also not true, because that object could have a type which is a subtype of B and also a subtype of C, and that object will be accepted by the first or the second case.
It is very helpful that the analyzer makes an attempt to produce an error message that exemplifies a way to improve on the code, but in this particular case the message is questionable.
Perhaps the error message could instead inform the developer that the switch is only known to handle instances of type C (and instances of type C whose field is 0, but hopefully we could eliminate redundancies of this kind). That's not quite as helpful, but it is true. ;-)

@johnniwinther  For insight into what the exhaustiveness checker can and can't do here.

From the exhaustiveness checking algorithm's point of view the message is correct. C(field: 0) as C only matches instances of C whose field property is 0 and the as C doesn't do anything.
Currently the messages are derived directly from the exhaustiveness checking, so we are limited to what it can model.
If we were to add more capabilities to the messaging system, perhaps we should add the same capabilities to the model itself.

From the exhaustiveness checking algorithm's point of view the message is correct. C(field: 0) as C only matches instances of C whose field property is 0 and the as C doesn't do anything.

But the message says that B() isn't matched, it never mentions C in the first place, and that isn't true under at least several different interpretations of what that would mean.
Would it make sense to make the error message tell what's covered, and then rely on developers to match that list up against "every possible scrutinee" manually? The rationale would be that the exhaustiveness analysis doesn't have complements to type-sets anyway (that is, we do not have a space that represents "every object which isn't a C"), so we shouldn't even try to describe such sets in the error message (and I think B() is an attempt to describe exactly that).

I understand that the analysis doesn't keep track of complements of sets of objects (like the complement of "every object that completes as C without throwing" == "every object where as C throws"). So the given example is considered to cover all objects of type C and nothing else. So it makes sense to recommend that the switch is enhanced to cover the other immediate subtypes of the sealed type A, which is precisely B.
However, I think it would be helpful if it is made more explicit that the advice is to add another pattern, we're not claiming anything about the result of evaluating B() as an expression.
How about something like this:
  error • n023.dart:9:18 • The type 'A' is not exhaustively matched by the
          switch cases. Try adding a case that matches the pattern 'B()', or a
          wildcard pattern. •
          non_exhaustive_switch_expression

@bwilkerson I've landed https://dart-review.googlesource.com/c/sdk/+/357160 which computes multiple witnesses for switches directly on "sealed types", i.e. enums and sealed classes. Some work on the analyzer is needed to surface this in the errors, lints, fix-its etc.

authors: bwilkerson eernstg johnniwinther


text:
Resource files with native assets

The native assets feature is intended to build and bundle native libraries with a Dart application and abstract away the resolution and loading of these libraries.
This idea can be extended to any resource that one would want to bundle with an application. These resources can be text files, images, binary data, etc. Similar to native libraries, these can be bundled as files next to the applications executable, or they can be bundled directly into the executable.
These resources could be registered in build.dart, just like native libraries. This also allows to generate resources at compile time.
Native assets are identified using library uris, like package:a/a.dart (assed id). This is implemented with @Native() external functions, where you can specify the asset id of the asset, in which the function can be found (https://github.com/dart-lang/sdk/issues/49803). To be able to load other asset types, there need to be different APIs that can load assets using asset ids.
One solution is to add a new Asset class (or Resource) that accepts an asset id and can load the asset similar to a File.
@dcharkes

That is indeed WIP, see https://dart-review.googlesource.com/c/sdk/+/351140. Basically, we need to provide an Asset interface similar to the one in Flutter, and implement where the assets would be stored when running commands such as dart build.

Oh, I did not see that. This is good news then!

authors: Dampfwalze mosuem


text:
Analysis options bugged after upgrading from Flutter 3.22.0-0.2.pre to 3.23.0-0.1.pre

For the last 6 moths I have been using this guide to essentially include all linter rules and then override the conflicts and tune the rules to my taste. I have made this simple little setup into a package that I host on a private GitHub repo and just update the all_linter_rules.yaml file whenever new rules are added, as well as make sure all conflicts are resolved. With the 3.23 beta I am encountering a new error even though my overall methods have remained consistent.
I am now getting warnings about conflicting linter rules in my all_linter_rules.yaml file even though conflicts are properly overridden and the included_file_warning: ignore analyzer error is properly set. The weird part is that when I reference my custom analysis packages' analysis_options.yaml locally the errors are not present. Only when referencing the analysis_options.yaml using a package import, from git hosted or local path, do these warnings appear.

nv_analysis package files

Project files

pubspec.yaml:
dev_dependencies:
  flutter_test:
    sdk: flutter
  nv_analysis:
    git:
      url: git@github.com:Novoid-LLC/nv_flutter_analysis.git
      ref: master

analysis_options.yaml:
include: package:nv_analysis/analysis_options.yaml # local barrel import of file removes warnings
analyzer:
  plugins:
    - custom_lint

Warnings:

Warning in the included options file /Users/$User/.pub-cache/git/nv_flutter_analysis-b80a6a1f77bd738d967c1ff52af94e50788bb94f/lib/all_lint_rules.yaml(1497..1529): The rule 'avoid_types_on_closure_parameters' is incompatible with the rule 'always_specify_types'.dart(included_file_warning)
Warning in the included options file /Users/$User/.pub-cache/git/nv_flutter_analysis-b80a6a1f77bd738d967c1ff52af94e50788bb94f/lib/all_lint_rules.yaml(3522..3546): The rule 'omit_local_variable_types' is incompatible with the rule 'always_specify_types'.dart(included_file_warning)
Warning in the included options file /Users/$User/.pub-cache/git/nv_flutter_analysis-b80a6a1f77bd738d967c1ff52af94e50788bb94f/lib/all_lint_rules.yaml(4302..4324): The rule 'prefer_final_parameters' is incompatible with the rule 'avoid_final_parameters'.dart(included_file_warning)
Warning in the included options file /Users/$User/.pub-cache/git/nv_flutter_analysis-b80a6a1f77bd738d967c1ff52af94e50788bb94f/lib/all_lint_rules.yaml(4906..4928): The rule 'prefer_relative_imports' is incompatible with the rule 'always_use_package_imports'.dart(included_file_warning)
Warning in the included options file /Users/$User/.pub-cache/git/nv_flutter_analysis-b80a6a1f77bd738d967c1ff52af94e50788bb94f/lib/all_lint_rules.yaml(4936..4955): The rule 'prefer_single_quotes' is incompatible with the rule 'prefer_double_quotes'.dart(included_file_warning)
Warning in the included options file /Users/$User/.pub-cache/git/nv_flutter_analysis-b80a6a1f77bd738d967c1ff52af94e50788bb94f/lib/all_lint_rules.yaml(5799..5815): The rule 'unnecessary_final' is incompatible with the rule 'prefer_final_locals'.dart(included_file_warning)

Expected results
The expected results is that I should be able to include: package:nv_analysis/analysis_options.yaml and not receive conflicts from the all_lint_rules.yaml file since they have been resolved using overrides and even supposedly silenced using included_file_warning: ignore.
Actual results
My best guess of what is actually happening is for some reason the included_file_warning: ignore is not being applied to subsequent inclusions in yaml files. This is resulting in linter rules showing up as conflicts. Interestingly this is only reproducible when importing as a package.
Code sample
Attempt to import this analysis package in your projects analysis_options.yaml:
include: package:nv_analysis/analysis_options.yaml

Screenshots or Video
No response
Logs
No response
Flutter Doctor output
Doctor output
[✓] Flutter (Channel beta, 3.23.0-0.1.pre, on macOS 14.5 23F79 darwin-arm64, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 15.4)
[✗] Chrome - develop for the web (Cannot find Chrome executable at /Applications/Google Chrome.app/Contents/MacOS/Google
    Chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.
[✓] Android Studio (version 2023.1)
[✓] VS Code (version 1.90.0)
[✓] Connected device (4 available)
    ! Error: Browsing on the local area network for iPhone. Ensure the device is unlocked and attached with a cable
      or associated with the same local area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code -27)
[✓] Network resources

! Doctor found issues in 1 category.

Originally posted by @cabaucom376 in https://github.com/flutter/flutter/issues/149981

I experience similar behavior in my project. In this monorepo, there is a package www_analysis dedicated to configuring analyzer, which only contains lib/analysis_options.yaml file with the following content:
analyzer:
  exclude:
    - lib/**.g.dart
    - lib/**.freezed.dart
    - lib/**.i69n.dart
    - lib/**.config.dart

  errors:
    missing_required_param: error
    missing_return: error
    invalid_assignment: warning
    invalid_annotation_target: ignore

This package is referenced by path by every other package, and their analysis_options.yaml file contains:
include: package:www_analysis/analysis_options.yaml

With this configuration, the project used to have no analyzer warnings in generated files, and also did not have invalid_annotation_target warnings because it was instructed to ignore those.
However, after I switched from stable channel Flutter 3.22.2 and Dart 3.4.3 to beta Flutter 3.23.0-0.1.pre and Dart 3.5.0-180.3.beta, this configuration provided with include seems to be ignored as there are now invalid_annotation_target warnings everywhere.
If I copy the content of www_analysis/lib/analysis_options.yaml file to analysis_options.yaml of other packages, warnings in those packages disappear.

There is another possible reason for the behavior being reported here: it's possible that the interpretation of relative paths changed. If the relative path is now interpreted relative to the analysis_options.yaml file in www_analysis and was previously interpreted relative to the including analysis_options.yaml file, that would account for the difference.
@pq

Still occurs in Flutter 3.24.0-0.1.pre

Fixed via this commit.

authors: bwilkerson cabaucom376 foxanna utamori


text:
Fix typo in StreamSink.close documentation

provding -> providing.

Thanks!

authors: creisman floitschG


text:
Game: Golden Axe - The dual (jap) doesn't work.

BlueRetro firmware version
v24.10_hw1
BlueRetro firmware specification
HW1
BlueRetro firmware variant
System specific
BlueRetro hardware type
External adapter dongle (1 port only)
Manufacturer
humble bazooka
System used
SEGA Saturn
Bluetooth controller brand & name
8bitdo, Saturn DIY board M30
What is problem? (only list ONE problem per report)
Game: Golden Axe - The dual (jap), game will be automatically restart. Select modes: game pad: DISC or Saroo ODE or Satiator will reboot again.
Select modes: gamepadalt. Game can start, but controller doesn't work.
So, I change back to my original controllers
The 6B pad original: work.
The NiGHT pad: if in 3D: will start the game, but contoller doesn't work.
Then, I change to Dpad. game reboot.
So, that means the blueretro gamepad=3D pad. And always in NiGHT controller, and start with Dpad model. Alt=NiGHT controller, but in 3D pad model. Hope you can understand.
What did you expect to happen?
Should be work.
Attach files like logs or Bluetooth traces here
No response

https://github.com/darthcloud/BlueRetro/issues/995

authors: DarthMotzkus mhmetalheart

repo: darthcloud/BlueRetro


text:
tls: introduce Store instead and NewConfig/WithStore helper

Summary by CodeRabbit

New Features

Introduced type aliases for easier reference to TLS certificate and configuration types.
Added a Store interface for managing TLS settings, including methods for retrieving certificates and CA pools.
Implemented functions to bind a Store instance to TLS configurations and create new TLS configurations with predefined settings.

@CodiumAI-Agent /review

PR Reviewer Guide 🔍
Here are some key observations to aid the review process:

⏱ Estimated effort to review: 2 🔵🔵⚪⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review
Error HandlingThe function WithStore only returns core.ErrInvalid without differentiating between various potential error scenarios, which might be important for debugging and error handling.

rebased

Persistent review updated to latest commit https://github.com/darvaza-proxy/x/commit/48a0a44d2547f5ed10e6cefe400a18c3e3920273

authors: CodiumAI-Agent amery

repo: darvaza-proxy/x


text:
tls: introduce SplitClientHelloInfo()

to bridge Store.GetCertificate() and StoreReader.Get()

Summary by CodeRabbit

New Features

Introduced a function to enhance TLS connection handling by extracting context and server name from client information.

Bug Fixes

Improved error handling for nil client information, ensuring robust connection management.

100-107: Consider validating the server name format
While the implementation is correct, consider adding validation for the server name format, especially when using the IP fallback, to ensure it meets TLS requirements.
 	serverName = chi.ServerName
 	if serverName == "" {
 		host, _, _ := core.SplitHostPort(chi.Conn.LocalAddr().String())
 		if host != "" {
+			// Ensure the host is a valid IP address
+			if ip := net.ParseIP(host); ip != nil {
 				serverName = fmt.Sprintf("[%s]", host)
+			}
 		}
 	}

📜 Review details

core.SplitHostPort() returns validated addresses


text:
Use PInvoke package for native functions

Package: https://www.nuget.org/packages/PInvoke.AdvApi32
Repository: https://github.com/AArnott/pinvoke/

@NN--- is there an exact improvement you are suggesting here?
The intent was to keep dependencies and API surface to the minimum. Also, they target desktop frameworks and thus cannot be used on platforms without netfx asset target framework compatibility (<ns2.0)

Closing due to discussion not being followed up.

authors: NN--- dasMulli


text:
MSVC CE, linking cbsdk.dll, #include "cbhwlib.h" requires NO_AFX to be defined.

I wrote an application that links to cbsdk and uses some of the types declared in cbhwlib.h. In MacOS it worked fine. In Windows it failed because it could not find some types used in function arguments defined in cbhwlib.h. This is because these types are only defined for non-Windows (here) or via #include <windows.h> if NO_AFX is defined (here).
I will create a stub in the Wiki for "How to use cbsdk" and put in this little bit of information for now, but I think a better solution is needed.

The STL has replacements for all the offending ALLCAPS types (e.g., UINT16 -> uint16_t).
In the provided .sln files, NO_AFX is defined by default, and it was defined in the CMakeLists.txt too (I wonder why @FlorianFranzen removed this in his fork?). Maybe <windows.h> should be included by default in Windows builds and not require a compiler definition.
As much as possible, it would be good to decouple cbsdk.h from cbhwlib.h so cbhwlib.h is no longer required.

cbSdkCCFEvent needs cbStateCCF from cbhwlib.h. This is just an enum and can be moved easily.
cbSdkCCF needs cbCCF. This is a complicated dependency to work around and any attempt to do so would need your guidance.

Yes NO_AFX should be defined, to avoid bringing in some MFC stuff, from what I remember. This is because Blackrock's code uses same headers and it is using MFC.
Those CCF structs would be difficult to wrap, because they are something like filed generated by protocol buffer with lots of fields. Can #ifdef them out for now, I am not sure if anyone uses that XML file (I wish I had not added XML, anything else is better!).

Closed with #66

authors: cboulay dashesy

repo: dashesy/CereLink


text:
fix: Ws.waitForVout & clear ping timeout

Fix browser bug with missing waitForVout and setTimeout not being cleared.
It happens at this point in my stream https://youtu.be/Hik0sLqudYg?t=3108 for waitForVout & https://youtu.be/Hik0sLqudYg?t=3805 for the setTimeout issue, after fixing https://github.com/dashhive/dashsight.js/pull/17

Why was this closed with unmerged commits.
Let's make a habit of commenting with the reason(s) in these cases.

@jojobyte

@riongull the commits were included in about her branch.

authors: coolaj86 jojobyte riongull


text:
fix: spent asset lock estimated fees, and misc

Issue being fixed or feature implemented
Small update to estimated fees of spent asset locks, and misc total credits in system
What was done?

How Has This Been Tested?

Breaking Changes

Checklist:

[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have added or updated relevant unit/integration/functional/e2e tests
[X] I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
[X] I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

[ ] I have assigned this pull request to a milestone

I hope you know what you are doing. utACK

authors: QuantumExplorer shumkov

repo: dashpay/platform


text:
[WIP] Add gpu tests for string functions

Adds gpu tests for string functions in dask-sql

Codecov Report

Merging #256 (c378b17) into main (ebdf4d5) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #256      +/-   ##
==========================================
- Coverage   95.89%   95.89%   -0.01%
==========================================
  Files          64       64
  Lines        2730     2728       -2
  Branches      408      408
==========================================
- Hits         2618     2616       -2
  Misses         72       72
  Partials       40       40

Impacted Files
Coverage Δ

dask_sql/physical/rel/custom/predict.py
95.45% <0.00%> (-0.11%)
:arrow_down:

dask_sql/utils.py
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ebdf4d5...c378b17. Read the comment docs.

authors: ayushdg codecov-commenter

repo: dask-contrib/dask-sql


text:
Switch tests from pd.testing.assert_frame_equal to dd.assert_eq

This should help to generally clean up some of the tests by allowing us to remove a lot of the unnecessary compute and to_pandas calls

Codecov Report

Merging #365 (f669426) into main (b1cea90) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #365   +/-   ##
=======================================
  Coverage   95.57%   95.57%
=======================================
  Files          67       67
  Lines        2935     2935
  Branches      547      547
=======================================
  Hits         2805     2805
  Misses         79       79
  Partials       51       51

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b1cea90...f669426. Read the comment docs.

Something important to note is that by default, assert_eq uses a local, synchronous scheduler to compute input Dask dataframes. In addition to causing the observed independent test clusters above (which arise from trying to compute dataframes with the local scheduler dependent on data stored in the independent cluster), this mean that all assert_eq tests would need to have a conditional kwarg passed through to ensure that the independent cluster is used when it is active.
Because this solution is rather cumbersome, I'm going to explore upstream work to make it so Dask allows assert_eq's scheduler to be controlled through its config module.
cc @ayushdg

Hoping that https://github.com/dask/dask/pull/8811 should unblock this

authors: charlesbluca codecov-commenter


text:
Update README.rst

a small typo

Thanks @SultanOrazbayev !

authors: SultanOrazbayev mrocklin

repo: dask/dask-xgboost


text:
Use absolute paths in read_* functions

In a distributed context the workers may have different working directories than the client.  In this case relative paths may be confusing.  Should we consider converting all paths on the posix file systems to absolute paths?

No strong opinion: is this a problem now? It would be easy to implement in LocalFileSystem._trim_filename.

I run into it from time to time.  Users do as well.  It's a common problem
in tutorials.
However it's also very easy to avoid if you understand what's going on, so
not a very high priority, mostly just a question at this point.
On Tue, Apr 25, 2017 at 3:41 PM, Martin Durant notifications@github.com
wrote:

No strong opinion: is this a problem now? It would be easy to implement in
LocalFileSystem._trim_filename.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/2256#issuecomment-297142486, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AASszDL1bO4OpV5VC1VSgCPExhDoWOZZks5rzkxfgaJpZM4NHvGc
.

authors: martindurant mrocklin

repo: dask/dask


text:
DataFrame.to_parquet(engine='fastparquet') not amenable to out-of-core workflows

Summary: the fact that df.to_parquet returns a single delayed object which depends on all of the chunks being written prevents memory from being freed and makes it difficult (impossible?) to use it for out-of-core analyses.
Example: let's say we want to perform some dataframe operation and save the results. With to_csv it's easy to write a chunk at a time and garbage collect the inputs as we go:
import distributed, dask.dataframe as dd
client = distributed.Client()
ddf = dd.from_pandas(pd.util.testing.makeCustomDataframe(100, 3), chunksize=5)
def f(_df):
    import numpy as np
    import time
    time.sleep(np.random.randint(1, 20))
    return _df
output = ddf.map_partitions(f).to_csv('/tmp/output_*.csv', compute=False)
#output = ddf.map_partitions(f).to_parquet('/tmp/output', compute=False)
ac = distributed.as_completed(distributed.futures_of(client.persist(output)))
for _ in ac:
    # as each chunk is written, the future is deleted and the scheduler can forget about it
    # this is obvious on the scheduler bokeh diagnostic but I'm not sure how else to show it
    pass

to_parquet on the other hand returns a single Delayed() object which depends on all of the intermediate partitions, so everything has to remain in memory until the entire write is completed.
The offending _write_fastparquet code is:
    write = delayed(_write_partition_fastparquet, pure=False)
    writes = [write(part, fs, path, filename, fmd, compression, partition_on)
              for filename, part in zip(filenames, df.to_delayed())]

    return delayed(_write_metadata)(writes, filenames, fmd, path, fs, sep)

Would extracting the necessary metadata from each partition as an intermediate task be enough to allow the inputs to be cleared from memory? I'm interested in taking a stab at this if it seems like a reasonable solution. cc @martindurant since I believe this is fastparquet-specific.

Have you observer the behaviour (holding on to memory) in practice? The writes above evaluate to pieces of parquet metadata, not the original data that was written to disc. Although these also take up some memory, there is no reason it should be a bottleneck or constraint in the typical scenario of many rows/few columns per partition.
Worth mentioning that pyarrow is in the process of being able to pass parquet metadata around for writing to a common metadata file in this manner, so will have very much the same execution pattern.

I have* observed this behavior; in particular the reason I'm interested in changing this is that my workers are running out of memory and being evicted (this is on Kubernetes). The problem actually sort of compounds itself because tasks for files that were already written are still being held by the scheduler, so when the worker responsible for that task gets killed the scheduler thinks that the task needs to be retried even though the desired side effect already occurred. Maybe this is related to read/writing tasks getting fused together by the graph optimizer?

I've also seen pretty substantial memory leaks from pandas in the same kinds of situations, so maybe I'm conflating the two here?

I've also seen pretty substantial memory leaks from pandas

we have come across such things where many allocations and releases are happening, but I thought this was much better in pandas 24 and whatever numpy did.

even though the desired side effect already occurred

Can you tell what a worker is doing at the time of death? If is any worker, or specifically the one expecting to do the finalisation task? You can use the client.nbytes method to find out how much memory the partition-writing results are actually taking up.
I should mention that the version of fastparquet that will eventually be released for python-3 only will include an option not to collect statistical data about columns, which will help the parquet metadata results pieces' size a bit.
What is your typical number of rows per partition, number of columns and number of partitions?

(I should mention, in reference to my comment about pyarrow, that the same refactor will allow skipping of the finalisation step, in cases where the global metadata file is not useful, for both pyarrow and fastparquet)

I think https://github.com/dask/dask/issues/4410 is related.

to_parquet no longer produces a _metadata file by default, so the memory taken by metadata aggregation is no longer required by default. If the user sets write_metadata_file=True, only the metadata is collected and merged in a single aggregation task, the original data is not held in memory and can be released. Closing.

authors: birdsarah bnaul jcrist martindurant