[dart-misc] MDGA

[kc]

Any news on:

Flutter
Fuchsia
Dart 2.0
Kernel Lang
Strong Mode and types

And how they fit together.

K.

[Filipe Morgado]

+1

[Ahmet A. Akın]

Also a recent addition "Fasta"

Post by kc
Flutter
Fuchsia
Dart 2.0
Kernel Lang
Strong Mode and types
And how they fit together.
K.

['Bob Nystrom' via Dart Misc]

Post by Ahmet A. Akın
Also a recent addition "Fasta"

+Peter.

– bob

['Peter Ahé' via Dart Misc]

I gave a presentation about Fasta recently and we recorded the video:

Post by Ahmet A. Akın
Also a recent addition "Fasta"
+Peter.
– bob

[Benjamin Strauß]

Thanks for that. It would be great if there was a page on dartlang where
all presentations would be linked. If you had not posted this here I would
have missed that video.

Post by 'Peter Ahé' via Dart Misc
http://youtu.be/p1NTzpaS4GU

Post by 'Bob Nystrom' via Dart Misc

Post by Ahmet A. Akın
Also a recent addition "Fasta"

+Peter.
– bob

['Bob Nystrom' via Dart Misc]

Post by kc
Flutter

As always, we're working really closely with the Flutter folks, but we
aren't the best people to ask for their status. I'd ask them if I were you.
:)

Post by kc
Fuchsia

Likewise.

Post by kc
Dart 2.0

Nothing concrete to report yet around 2.0.

Post by kc
Kernel Lang

This is going well, though I don't know many of the details of it. Adding
Asger and Siggy to the thread in case they want to provide some details.

Post by kc
Strong Mode and types

Strong mode is going *great*. An ever-increasing fraction of Dart code
internal to Google is strong mode clean. If you look at the CHANGELOG
<https://github.com/dart-lang/sdk/blob/master/CHANGELOG.md>, you can see we
recently shipped a bunch of minor tweaks and improvements to the type
system:

- The Null type has been moved to the bottom of the type hierarchy.

- Change instantiate-to-bounds rules for generic type parameters when
running in strong mode.

- Define FutureOr<T> for code that works with either a future or an
immediate value of some type.

- Real generic method syntax is now handled by all of the various Dart
implementations. The VM and dart2js do not yet implement the runtime
semantics around generic methods, but they will gracefully ignore the
syntax.

The changelog has lots of details on each of those.

As you probably know, I'm currently doing some investigation
<https://groups.google.com/a/dartlang.org/forum/#!topic/core-dev/nibahmEeiXE>
on non-nullable types. It's still pretty early, but so far it looks really
promising. If we can pull it off for Dart 2.0, I think it will go a long
way towards giving users confidence in the safety of their code.

Sorry we've been kind of quiet lately. Much of the team has been really
heads down focused on getting our giant internal corpus of Dart code
working under strong mode, enhancing the type system to make that go
smoother, and ramping up dev_compiler for real-world usage. As that stuff
stabilizes, we should become more externally visible again.

Cheers!

– bob

['Yegor Jbanov' via Dart Misc]

Much of the team has been really heads down focused on getting our giant
internal corpus of Dart code working under strong mode

If you are wondering what Bob means by this, here's a great write-up
<https://medium.freecodecamp.com/how-google-builds-a-web-framework-5eeddd691dea#.2ytoxycsz>
about how software is developed at Google. The tl;dr is if you are
introducing changes for your users (e.g. strong mode), you suffer the pain
(and advantages!) of the change yourself first.

[kc]

There's a bit of a catch22. Devs outside of Google won't get involved until a big picture is outlined. Thus Google then doesn't get useful dev feedback.

K.

[tatumizer-v0.2]

@Peter: after watching your presentation: you expect speedup after
tokenization, which fails to materialize.
There's a simple explanation for that: hashmap lookups dominate in all
subsequent phases, and hashmaps are very slow in dart.

E.g, whenever you look up anything (e.g. the type of foo in x.foo), hashmap
performance is proportionate to the LENGTH of identifier ("foo")
so the expected performance depends on the original length - the fact that
you (programmer) view it one token is irrelevant.
(This length comes into play in both hash code calculation and string
comparison).

However, there can be a cure for this - there are processor instructions
that can help with string operations (some conditions apply),
so you can compute hash code in a couple of cycles, compare strings in a
couple of cycles etc. It's just dart doesn't utilize these instructions.

Also, there can be some optimizations for small hash maps - we discussed it
before.

Anyway, hash maps in dart are very slow compared with java.

I have some data from my old microbenchmarks: insertion of 8-char key into
hash map takes 7.5 nanoseconds PER CHARACTER - that is, 46 nanoseconds in
total on a relatively good comp.
That's why you have slowdown instead of speedup.

Is Slava still around? Why can't he roll up his sleeves and finally do
something about it?
If you squeeze 50% of possible performance from processor in just one place
(hash map), I bet you will see dramatic speedup.

AK

['Bob Nystrom' via Dart Misc]

Post by kc
There's a bit of a catch22. Devs outside of Google won't get involved
until a big picture is outlined. Thus Google then doesn't get useful dev
feedback.

Yes, this is a real and entirely valid concern.

We do get a *lot* of very useful dev feedback from our internal users in
Google. But they are different from external users in many important ways,
and it's important to listen to outside users too.

We are doing an OK job of this for some things, I think:

- Strong mode is out there, we've given talks on it, and lots of
external users are using it and giving us feedback.

- The language changes we've shipped in the past couple of versions have
all had public tracking issues
<https://github.com/dart-lang/sdk/issues?q=is%3Aissue+label%3Aarea-language+milestone%3A1.22+is%3Aclosed>
while they were being worked on. Those are a great place for feedback to
come in.

- In general, the issue tracker for language issues
<https://github.com/dart-lang/sdk/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3Aarea-language>
is a great way to see what's being worked on and to let us know what you
think.

- The prototyping on non-nullable types is in a visible branch
<https://github.com/dart-lang/sdk/tree/prototype-nnbd> and I'm sending
out status updates. (I need to get another one out soon.)

But, beyond that, yes, I think we can and should do a better job of
involving you all.

Cheers!

– bob

[Danny Tuppeny]

Post by 'Bob Nystrom' via Dart Misc
- The prototyping on non-nullable types is in a visible branch
<https://github.com/dart-lang/sdk/tree/prototype-nnbd> and I'm sending
out status updates. (I need to get another one out soon.)

For significant features that are like to be in dev for a while on a
branch, is there any possibility of having SDK builds (like the dev
releases)? I did try to get the SDK building on my machine a while back but
kept hitting issues and gave up! ;(

['Bob Nystrom' via Dart Misc]

Post by Danny Tuppeny
For significant features that are like to be in dev for a while on a
branch, is there any possibility of having SDK builds (like the dev
releases)?

Oof, that's probably too much of a productivity tax for us on the team. :(

Post by Danny Tuppeny
I did try to get the SDK building on my machine a while back but kept
hitting issues and gave up! ;(

Do you have any details? It's important for us to smooth this onramp as
much as possible, and doing so benefits everyone.

– bob

[Danny Tuppeny]

Post by Danny Tuppeny
For significant features that are like to be in dev for a while on a
branch, is there any possibility of having SDK builds (like the dev
releases)?
Oof, that's probably too much of a productivity tax for us on the team. :(

No worries; I don't really know what's involved so thought I'd ask. If it's
not as simple as stashing the output from some CI build somewhere, I agree
it's probably not a good use of time :-)

Post by Danny Tuppeny
I did try to get the SDK building on my machine a while back but kept
hitting issues and gave up! ;(
Do you have any details? It's important for us to smooth this onramp as
much as possible, and doing so benefits everyone.

I did mention some of these issues but can't remember where (might've been
GH, or even here). It was a while ago and it was specifically the analysis
server I was trying to get working but IIRC some of the issues were:

- Build scripts in Python but didn't work in Python 3 (why not Dart?! :))
- Had to make changes to all pubspecs to point at local (in-repo) paths so
packages weren't pulled from Pub (which I think was causing version
constraint issues)
- Many tests failed before even making any changes (this happened in the
release SDKs, so I couldn't figure out if it was exepcted or some
dependency or something missing)

(There may have been others, or I may be remembering some of these wrong; I
appreciate that's not particularly useful but I don't have time to try
again just now!)

I probably would've got there if I kept trying, but I spent many hours over
many days unable to get things working and for what I was trying to do it
seems like too much effort.

HTH!

Danny

['Bob Nystrom' via Dart Misc]

Post by Danny Tuppeny
- Build scripts in Python but didn't work in Python 3 (why not Dart?! :))

Filed a bug about Python 3: https://github.com/dart-lang/sdk/issues/28793

"Why not Dart is a great question." :)

We do use Dart for many of our internal tools. The remaining Python scripts
are either:

1. So old that they exist from a time before you *could* write an
equivalent script in Dart, and we've never gotten around to rewriting.

2. Used during the build process for Dart when an existing VM might not
be able to run the script yet. We could write these in Dart and rely on a
bootstrap <https://en.wikipedia.org/wiki/Bootstrapping_(compilers)>
executable (that's what we do for test.dart), but that adds a good bit of
complexity, and it's not clear if it's really worth it.

I find bootstrapping appealing on programming language nerd "let's see
how meta we can go" grounds, but in practice it is kind of a pain in the
ass and it doesn't buy you that much. We *do* use Dart for most of our
big internal tools like dart2js, analyzer, etc, so we aren't missing much
by using a few hundred lines of Python here and there for little build
scripts.

3. Old scripts that are no longer even used and we just haven't deleted
them. You probably didn't run into these, but they are certainly in there.
:)

- Had to make changes to all pubspecs to point at local (in-repo) paths so

Post by Danny Tuppeny
packages weren't pulled from Pub (which I think was causing version
constraint issues)

Strange. You shouldn't *have* to do that, but maybe something is or was in
a weird state. Now that we have ".packages" files, that may be better. If
you can give us more details on this, I can take a look.

Post by Danny Tuppeny
- Many tests failed before even making any changes (this happened in the
release SDKs, so I couldn't figure out if it was exepcted or some
dependency or something missing)

:(

That definitely *shouldn't* happen, but:

- Our test runner is old and poorly documented and it's not clear even
to people on the Dart team what test suites there are, which configurations
are meaningful, and how to run them.

- We do seem to have an increasing number of flaky tests. We have
acquired some technical debt around our tests that we are slowly
starting to pay off
<https://github.com/dart-lang/sdk/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Agardening%20>
.

Post by Danny Tuppeny
(There may have been others, or I may be remembering some of these wrong;
I appreciate that's not particularly useful but I don't have time to try
again just now!)

Yeah, I totally understand if you got burned and don't want to sink more
time into it.

Cheers!

– bob

[Danny Tuppeny]

Post by 'Bob Nystrom' via Dart Misc
Filed a bug about Python 3: https://github.com/dart-lang/sdk/issues/28793

Ta!

Post by 'Bob Nystrom' via Dart Misc
1. I find bootstrapping appealing on programming language nerd "let's
see how meta we can go" grounds, but in practice it is kind of a pain in
the ass and it doesn't buy you that much. We *do* use Dart for most of
our big internal tools like dart2js, analyzer, etc, so we aren't missing
much by using a few hundred lines of Python here and there for little build
scripts.

That's valid; though I don't think getting a Dart SDK in the build
environment is complicated (apt-get, chocolatey, download and unzip) and
the PITA that is Python 2v3 might make it worth it! :D


- Had to make changes to all pubspecs to point at local (in-repo) paths so

Post by 'Bob Nystrom' via Dart Misc
packages weren't pulled from Pub (which I think was causing version
constraint issues)
Strange. You shouldn't *have* to do that, but maybe something is or was
in a weird state. Now that we have ".packages" files, that may be better.
If you can give us more details on this, I can take a look.

I can't find the details now (I can't remember where I mentioned it), but
it was something along the lines of packages in the SDK relying on each
other but pubspecs had no paths, so running "pub get" would result in
pulling packages from pub when they needed to be built from all the local
code.

I was specifically trying to build the analyzer snapshot, so maybe it was
more involved then generally building the SDK. I should try and find some
time to try it all again; it's been a while!

Post by 'Bob Nystrom' via Dart Misc
- Many tests failed before even making any changes (this happened in the
release SDKs, so I couldn't figure out if it was exepcted or some
dependency or something missing)
:(
- Our test runner is old and poorly documented and it's not clear even
to people on the Dart team what test suites there are, which configurations
are meaningful, and how to run them.
- We do seem to have an increasing number of flaky tests. We have
acquired some technical debt around our tests that we are slowly
starting to pay off
<https://github.com/dart-lang/sdk/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Agardening%20>
.

I found this thread I posted when I hit this:

https://groups.google.com/a/dartlang.org/forum/#!topic/analyzer-discuss/IqvtQ-KtRD0

I think I tried running the analyzer tests from the next release SDK and
they also failed there, so I gave up. I'd been hoping to try and implement
something in the analysis server but it seemed like building that from
bleeding_edge needed to build a whole SDK, and then I needed Python 2, a
C++ compiler, etc.; and it all started to look like a lot of effort to
tweak some Dart scripts ;(

['Brian Wilkerson' via Dart Misc]

Danny,

I can't find the details now (I can't remember where I mentioned it), but

Post by Danny Tuppeny
it was something along the lines of packages in the SDK relying on each
other but pubspecs had no paths, so running "pub get" would result in
pulling packages from pub when they needed to be built from all the local
code.

Correct. The simple answer is: don't run pub when developing code in the
SDK. If you have previously done so, then delete every `.packages` file
(and `packages` directory) in your SDK checkout *except* the `.packages`
file at the root of the checkout. That's the file that specifies the
package map used while developing in the SDK (and that file is committed
and hence maintained automatically).

I was specifically trying to build the analyzer snapshot, so maybe it was

Post by Danny Tuppeny
more involved then generally building the SDK. I should try and find some
time to try it all again; it's been a while!

No, building the SDK will build all of the snapshots that are shipped with
the SDK, including both the command-line analyzer and analysis server
snapshots.

Post by Danny Tuppeny
https://groups.google.com/a/dartlang.org/forum/#!topic/analyzer-discuss/IqvtQ-KtRD0

Yeah, things have changed since then. We didn't use to have the `.packages`
files, so we didn't have one checked in and you did used to need to run
pub, but that's no longer the case.

I think I tried running the analyzer tests from the next release SDK and

Post by Danny Tuppeny
they also failed there, so I gave up. I'd been hoping to try and implement
something in the analysis server but it seemed like building that from
bleeding_edge needed to build a whole SDK, and then I needed Python 2, a
C++ compiler, etc.; and it all started to look like a lot of effort to
tweak some Dart scripts ;(

You should be able to run all of the analyzer-related tests without
building an SDK. There is a file at the root of both the analyzer's and
analysis server's `test` directories (named `testAll.dart`) that you can
execute (as a normal dart application) that will execute all of the tests.
The only time you'd need to build an SDK is when you go to test the new
functionality in the IDE.

Brian

Post by Danny Tuppeny
On Thu, 16 Feb 2017 at 18:41 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
Filed a bug about Python 3: https://github.com/dart-lang/sdk/issues/28793

Ta!

Post by 'Bob Nystrom' via Dart Misc
1. I find bootstrapping appealing on programming language nerd "let's
see how meta we can go" grounds, but in practice it is kind of a pain in
the ass and it doesn't buy you that much. We *do* use Dart for most
of our big internal tools like dart2js, analyzer, etc, so we aren't missing
much by using a few hundred lines of Python here and there for little build
scripts.

That's valid; though I don't think getting a Dart SDK in the build
environment is complicated (apt-get, chocolatey, download and unzip) and
the PITA that is Python 2v3 might make it worth it! :D
- Had to make changes to all pubspecs to point at local (in-repo) paths so

Post by 'Bob Nystrom' via Dart Misc
packages weren't pulled from Pub (which I think was causing version
constraint issues)
Strange. You shouldn't *have* to do that, but maybe something is or was
in a weird state. Now that we have ".packages" files, that may be better.
If you can give us more details on this, I can take a look.

I can't find the details now (I can't remember where I mentioned it), but
it was something along the lines of packages in the SDK relying on each
other but pubspecs had no paths, so running "pub get" would result in
pulling packages from pub when they needed to be built from all the local
code.
I was specifically trying to build the analyzer snapshot, so maybe it was
more involved then generally building the SDK. I should try and find some
time to try it all again; it's been a while!

Post by 'Bob Nystrom' via Dart Misc
- Many tests failed before even making any changes (this happened in the
release SDKs, so I couldn't figure out if it was exepcted or some
dependency or something missing)
:(
- Our test runner is old and poorly documented and it's not clear
even to people on the Dart team what test suites there are, which
configurations are meaningful, and how to run them.
- We do seem to have an increasing number of flaky tests. We have
acquired some technical debt around our tests that we are slowly
starting to pay off
<https://github.com/dart-lang/sdk/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Agardening%20>
.

https://groups.google.com/a/dartlang.org/forum/#!topic/
analyzer-discuss/IqvtQ-KtRD0
I think I tried running the analyzer tests from the next release SDK and
they also failed there, so I gave up. I'd been hoping to try and implement
something in the analysis server but it seemed like building that from
bleeding_edge needed to build a whole SDK, and then I needed Python 2, a
C++ compiler, etc.; and it all started to look like a lot of effort to
tweak some Dart scripts ;(
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Danny Tuppeny]

On Sat, 25 Feb 2017 at 15:43 'Brian Wilkerson' via Dart Misc <

Post by Danny Tuppeny
https://groups.google.com/a/dartlang.org/forum/#!topic/analyzer-discuss/IqvtQ-KtRD0
Yeah, things have changed since then. We didn't use to have the
`.packages` files, so we didn't have one checked in and you did used to
need to run pub, but that's no longer the case.

Aha, that explains that then. Sounds like it should be easier now!

Post by Danny Tuppeny
You should be able to run all of the analyzer-related tests without
building an SDK. There is a file at the root of both the analyzer's and
analysis server's `test` directories (named `testAll.dart`) that you can
execute (as a normal dart application) that will execute all of the tests.
The only time you'd need to build an SDK is when you go to test the new
functionality in the IDE.

Even better! I'll try and find time to give this another go then. Thanks!
:-)

[kc]

Post by 'Bob Nystrom' via Dart Misc
But, beyond that, yes, I think we can and should do a better job of
involving you all.

Definitely. The lack of a big picture make it very difficult for any
rational developer to make an investment of time or effort.

K.

Post by 'Bob Nystrom' via Dart Misc
Cheers!
– bob