by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 07 2019 18:54
    @timsneath banned @hpoit
Terrain2
@Terrain2
I previously got the error Error: A library can't opt out of null safety by default, when using sound null safety. before upgrading dart to the latest version, so the issue seems to be related
Terrain2
@Terrain2
alright solved it, the issue was just some weird dependencies of nyxx using null safety and dependencies not fully supporting it, dart --enable-experiment=non-nullable --no-null-safety .\bin\main.dart will supress the issues in libraries, but for whatever reason only works on dart 2.9 or lower, 2.10 doesn't support this feature??
Simon Binder
@simolus3
@Terrain2 The --no-null-safety flag has been renamed to --no-sound-null-safety in Dart 2.10
Oliver Damm
@Blimster

Today I released the first version of my package babylon_dart. It contains bindings to BabylonJS for the Dart language.

It is work in progress. Issues for feature request are welcome. Pull request even more.

Graciliano Monteiro Passos
@gmpassos
@Blimster nice work! Will be interesting to see a live demo, using your package in Dart, and not only the JS demo. Best regards.
I use Github pages to show a live demo at /example directory of the package chart_engine https://pub.dev/packages/chart_engine
Where you can see the supported charts rendered at the same tome with ApexCharts and ChartJS
bpilot
@bpilot
@Blimster Very nice.
Bouke Versteegh
@boukeversteegh

Hi all!

I have a dart performance design/architecture question, which I realize may not have a simple answer.

I'm working on a Git implementation in Dart, that needs to be fast, as I'm going to use it to run a database stored as a git repository.
Most of the IO load will be thousands of small read operations across one or more files.
CPU load will consist of decompressing the data, and concatenating small chunks into larger UInt8Lists (still mostly less than 1KByte)

Some of these operations may be parallellizable (decompression, processing of unrelated objects).
Some processing could happen while waiting for IO.

My dilemma is as follows..
Should I implement "everything" (including all low level IO operations, and cpu limited operations) with async/await?
Will this give me a performance boost or make it easier to parallelize things in the future?
Or will there be a significant overhead cost, and should I rather make most low-level operations Synchronous, and parallelize on a high level with Isolates where possible?

I noticed as many people point out that 'async' is contagious, and slowly all my functions now have 'async' in the name, so it will be costly to make everything sync again later.
Thats why I want to make an informed decision at this point.

Any thoughts?

Jonathan Rezende
@jodinathan
interesting question.
I think you should create a SO question with just copy and paste what you wrote above
so we can answer and follow answers
bpilot @bpilot thinks about what Linus Torvalds would think of implementing git in a high-level object oriented language and smirks.
bpilot
@bpilot
@boukeversteegh Very interesting question though for sure, definitely ask on Stack Overflow. I wonder if writing a benchmark could answer part of this question. The decompression (using https://api.dart.dev/stable/2.9.3/dart-io/ZLibCodec-class.html because git uses zlib I am pretty sure) would require use of isolates to get good performance, I would think.
Bouke Versteegh
@boukeversteegh

thanks for your reactions and suggestions. if the question is clear enough and 'answerable' in its current form, then i could post it on SO indeed. I wasn't sure that it was.

@bpilot yes, git uses Zlib, and I'm currently using the dart:convert library to decode the streams.

Bouke Versteegh
@boukeversteegh
@bpilot a benchmark could help yes, but I'm concerned that to write a proper benchmark I basically need to have finished the whole implementation, and then to compare it, I'd need to reimplement it in sync. Maybe reimplementing it is less work than I imagine though, and I should just do it and get a definite answer.
But I thought I could avoid doing that if some more experienced folks could point me in the right direction earlier on
bpilot
@bpilot
Your decompression will max out spinning on only one core unless you use isolates, or maybe drop into C++ and use pthread (I don't know if that plays well with Dart VM though).
István Soós
@isoos
@boukeversteegh: using sync operations will block any other pending call in the async loop, including requests that could be served concurrently. Because of that, there is a slight performance benefit of using sync file operations (after all the VM doesn't need to check what's there to run), but that is only noticeable in benchmarks and in isolated programs. Side note: the FS-related "overhead" is usually done off-isolate-thread, that's why you'll see 105-140% CPU use even if you are using a single isolate for a disk-heavy program.
Considering all of that, you are not worse off to implement it with async, and it is more reuse- and future-friendly, especially if the app wanted to serve many requests.
Bouke Versteegh
@boukeversteegh
@bpilot yes I thought so too, I may in the end move some of the work to a lower level language, but until then it would be great to have decent performance in Dart
@isoos thank you for your insights!
sounds like async is the way to go then. for very small operations like reading a single byte, i could go sync, which would be a trivial code change, and even that I can postpone until a benchmark shows that its a bottle neck.
István Soós
@isoos
If you are reading bytes from stream, take a look at package:buffer, it may help you to write the parsing logic in a sane way (I've used it to build and parse Cassandra frames).
Bouke Versteegh
@boukeversteegh
interesting, thanks @isoos , looks like something that might help.
one of the hurdles was indeed that i sometimes need to advance byte for byte, but i don't want to access disk byte for byte, and it seems this package can do that
ah, I see you're the maintainer of it! :-D
for this package to be more accessible, I would recommend to provide some small example code, so its easy to see what functionality the package provides
Bouke Versteegh
@boukeversteegh
i might make a PR :-P
István Soós
@isoos
PRs are welcome :)
Also, if you need a bit more helper method, or a utility here and there, I'm happy to accept those too
Bouke Versteegh
@boukeversteegh
that's nice, thanks :-D
Fernando Rodriguez Romero
@frr149
I noticed a lot of boilerplate involved in overwriting Object 's interface, such as toString , operator== and hashCode. Is there any better way? I was thinking of something along the lines of Data Classes in Kotlin: https://kotlinlang.org/docs/reference/data-classes.html
OTOH, are there plans to include weak references in Dart?
Simon Binder
@simolus3
You can use an Expando for weak references. IIRC the Dart team is working on data classes, until then you could use something like built_value.
Bouke Versteegh
@boukeversteegh
Does anyone know how I can await inside a function that returns a Stream?
If i make the function async, it expects to return Future. If I make the function async* it cannot return the stream I prepared in the method (I have to use yield)
  Stream<int> getStream() async {
    final object = await getObject();
    return object.dataStream;
  }
// functions marked async must return Future
Bouke Versteegh
@boukeversteegh
I came up with this solution, but it feels rather awkward..
Stream<int> getStream() async* {
    final object = await getObject(); 
    await for (final e in object.dataStream) {
      yield e;
    }
  }
especially because I have a Stream available, and i want to return a stream also.
the only reason i can't do that is that I need to await :-S
Graciliano Monteiro Passos
@gmpassos
New release: chart_engine 1.1.7
https://pub.dev/packages/chart_engine
Simon Binder
@simolus3

@boukeversteegh You can use yield*, which is easier to read (and more efficient I think):

Stream<int> getStream() async* {
    final object = await getObject();
    yield* object.dataStream;
  }

If you want to avoid the overhead of async* entirely, you could also use

Stream<int> getStream() {
  return Stream.fromFuture(getObject()).asyncExpand((obj) => obj.dataStream);
}
Nate Bosch
@natebosch
@boukeversteegh There is an API for exactly this purpose in package:async. https://pub.dev/documentation/async/latest/async/StreamCompleter/fromFuture.html
Future<String<int>> _someData() async {
  final object = await someObject();
  return object.dataStream;
}

Stream<int> someData() => StreamCompleter.fromFuture(_someData());
Bouke Versteegh
@boukeversteegh
oh, great! those are very good solutions, thank you very much @simolus3 & @natebosch
Jermaine Oppong
@graphicbeacon

Hello friends, I created a cli to help manage dependencies in a Dart/Flutter project. I'm keen to get some thoughts on this one :)

Here's the jist of how the tool works:

$ crawl init # launch pubspec.yaml creation wizard
$ crawl install -p <pkg> # add a package to dependencies section
$ crawl install -p <pkg> -d # add a package to dev_dependencies section

More details here: https://pub.dev/packages/crawl

4 replies
Bouke Versteegh
@boukeversteegh
:) first thought, "doesn't pub already offer this?", second thought.. "oh wait, it doesn't".
have you considered making this as a PR on the dart-sdk so it could be part of pub?
Graciliano Monteiro Passos
@gmpassos
Take a look in one with other similar operations:
https://pub.dev/packages/dependency_scanner
Simon Binder
@simolus3
It seems like we'll also have pub add soon.
Jermaine Oppong
@graphicbeacon

@gmpassos My first impressions: dependency_scanner looks similar although its concern is Dart projects while I'm focused on Dart packages.

@simolus3 Looks good, can't wait to have pub add and pub remove. Meanwhile crawl is ok for use now and will be adding a couple more commands so that it's not just adding and removing packages.

@boukeversteegh Hadn't thought of that 🤔 Now that I know pub uses args package I'll consider it.

Graciliano Monteiro Passos
@gmpassos
It works for packages too, actually I use for my packages
Jermaine Oppong
@graphicbeacon
Ok that's good to know
Bouke Versteegh
@boukeversteegh
Does anyone know if its possible to get coverage to also report line hits on external packages?
I'm using Intelli-J and only see coverage for my main project, not for referenced libraries
hmm, solved it :-)
adding the library as content-root in the IDE made the coverage show up!
except only on file level :-/