Thursday, August 30, 2012

New try/catch syntax ready to use

Posted by Kasper Lund


We're very close to being able to turn off the support for the old
try-catch syntax. Early next week attempts to use the old syntax will
lead to compile-time errors. The new syntax already works today so now
would be a fantastic time to update your code.

The old syntax like:

   try { ... } catch (var e) { ... }
   try { ... } catch (final e) { ... }
   try { ... } catch (T e) { ... }
   try { ... } catch (final T e) { ... }

translates to new syntax like this:

   try { ... } catch (e) { ... }
   try { ... } catch (e) { ... }
   try { ... } on T catch (e) { ... }
   try { ... } on T catch (e) { ... }


and the local variable introduced to hold the reference to the caught
exception (e) is implicitly final in all cases.

Why did we make this change? The M1 Updates article explains it best.

Dart API docs get 83% more awesome

Posted by Seth Ladd

There are a lot of classes in the Dart API, and it's now much easier to find what you're looking for thanks to a new "find as you type" search feature on api.dartlang.org.


Thanks to Johnni Winther for building this feature. Enjoy!

As always, we appreciate your feedback and comments. Please join us on the Dart mailing list and Stack Overflow.

Wednesday, August 29, 2012

Notes from weekly Dart language review

Posted by Bob Nystrom


Here's my notes from this week's meeting. As usual, the meetings are fairly low key as we move towards M1.

Instantiating abstract classes

We're starting to move code from interfaces to abstract classes. We noticed a nasty pattern some people were doing where they made a private factory constructor just to get rid of the default constructor so that a class couldn't be constructed.

We don't want people doing that. So, instead, we'll make it a dynamic error to instantiate an abstract class. (Abstract class meaning a class that defines an abstract method or is explicitly marked "abstract".)

This is already a static warning in the editor, but we will make it an outright error at runtime. If you relied on this behavior, now you'll just override any abstract methods with empty bodies or throws or something.

Kasper pointed out that we can always loosen this up later if the above proves to be problematic.

Markdown doc comments

We've generated a histogram of which markdown features are currently being used in doc comments in the repository. Markdown is so rich that we don't think we can specify everything, so we want to pick just the subset we use.

The plan is that this will be an appendix to the language spec. Specifying this means the Editor can parse doc comments and style them appropriately.

I pointed out that most of the docs in the repo were written before any markdown was supported, so they may not be a representative set. I asked that we also take a look at some of the newer Dart stuff on github, in particular dartlib and the web components stuff.

Cheers!

#resource is going away, update your code

Posted by Seth Ladd


Today, Dart team member Kasper Lund notified us of a breaking change. The #resource directive is being removed from the spec and implementations. From the email:


We've decided to remove support for the #resource directive and
instead rely on metadata annotations for associating external
resources with Dart programs. I've submitted a change that removes the
support for #resource from dart2js in r11489 and the other
implementations (the VM and the analyzer) will also stop supporting
the tag in the near future.

Now is the time to remove any uses of #resource. Please drop by the mailing list if you have any questions. Thanks for trying Dart!

Tuesday, August 28, 2012

Dart Editor cleans up your code for M1

Posted by Devon Carew

A new Dart Editor build is available at www.dartlang.org/editorChanges include:
  • Wondering about M1 language changes? Worried about having to update your code? Worry no more! We have a new M1 language migration wizard which'll do that work for you! Right click on your project and choose 'Clean up...'. We've implemented cleanups for catch blocks, the new getter syntax, operator equals, and library/import/source changes. Please note, the last two changes are not yet supported across all platforms.



  • We've added the ability to write hooks into the Editor's build system. If a build.dart script exists in a project, we'll invoke it as part of the Editor's build process. This allows for custom processing of changed resources, like for templating systems, generating Dart code, or scss --> css processing. There are sample scripts available at dart/samples/buildhook1 and dart/samples/buildhook2, as well as online at https://github.com/dart-lang/dart-web-components/blob/master/build.dart.
  • Our type inference engine has been enhanced to add support for inferring types from dart:html select().
  • The type inference engine now handles the case where a variable is assigned different types at different times, and will show you the intersection of legal method and field references. In addition we now infer the type of List and Map literals.
  • Added basic scss (http://sass-lang.com/) syntax highlighting.
  • dart:mirrors has been added to the SDK; the editor can now resolve the mirrors library and the types within it.
  • Added warnings for use of obsolete getter and catch syntaxes.
  • We now highlight single line /// dartdoc comments.
  • We now do a better job of displaying when the debugger halts at an uncaught exception.
  • Fixed an issue with stepping into user libraries in the Dartium debugger.
  • Semantic highlighting tweaks and fixes.
  • General fixes and enhancements to the rename refactoring, code completion, the extract variable refactoring, hyperlinking, searchbox UX, and the debugger UX.
As always, view the changelog for the full list of changes, and to get started with the Editor see our tutorial.

Friday, August 24, 2012

Dart project welcomes new external committer

Posted by Seth Ladd

Welcome to our first external committer!


Please help us welcome Alexander Aprelev as our first external committer to Dart. Alexander has been working on dart2js, and helping us get ready for M1.

Interested in how to contribute to Dart? We're open source, and we encourage patches. Read more at our Contributing to Dart guide.

Other Dart projects, like the code for www.dartlang.org and Dart + Web Components, are also open source. Lots of ways to get involved!

Thursday, August 23, 2012

Ask the dart2js team

Posted by Seth Ladd




This time, we're taking the Dartisans show on the road! We'll be in Denmark next week to chat with members of the dart2js team. Here's your chance to ask and vote for questions about how the Dart project compiles Dart to JavaScript.

Past episodes of Dartisans have covered the Dart VM, the Dart community, and more. We look forward to hearing from you!

What do you want to ask the dart2js team?

Wednesday, August 22, 2012

Dart Lang meeting: All objects hashable, and more

Posted by Bob Nystrom


Here's my notes from this week's Dart language meeting:


Getters and implicit "abstract"

Peter raised an interesting corner case with the new getter syntax and the
optional "abstract" keyword. Given this:

  class Foo {
    get bar;
  }

Does it define an abstract getter "bar" whose type is Dynamic, or a field "bar" whose type is "get"?

Gilad says the grammar isn't actually ambiguous here, so there's no problem. (get bar always defines an abstract getter because the spec disallows "get" as a type name.)

We discussed whether "abstract" should be optional or simply removed. Gilad says we should leave it optional in case people want to use it for emphasis. He also wonders if there's a case we aren't thinking of (maybe like the above?) where having it would be helpful to make something clear.

All objects hashable

This is coming in M1. (Woo!) It's just a matter of implementation. We want this in particular so that closures are hashable.

Doc comments

Lars wants to have the language specify the doc comment syntax so that things like the Editor can parse it. The plan is to go through our existing comments and see what subset of markdown we are actually using in practice and then specify that.

We also would like a doc comment form that works for single-line docs. With lots of short members, it's annoying to have to do:

  /**
   * Tiny comment.
   */
  void tinyMember() => 'blah';

I pointed out that I already borrowed "///" from C# and added support for it in Dartdoc, so they said we'll go with that.

Streaming string interpolation

Lars brought up an issue that he wonders if we'll want language support for at some point. The problem comes when you're getting some recursive structure and stringifying it to a stream. If you use interpolation in that, you can end up back at n^2 complexity.

Should we look into some kind of streaming support for string interpolation? No resolution yet.

Cheers!

Easy regex to update to new getter syntax

Posted by Seth Ladd


Just spotted this gem from the Dart mailing list. Community member Kevin Moore offers this bit of advice for handling the syntax change for getters:

"""

This saved me a lot of code spelunking, so I wanted to share.

Find: (get\s+[_a-zA-Z0-9]+)(\(\))(\s+(=>|\{))
Replace: $1$3

Make sure you have regex search on.
Works great in Sublime. I think the same syntax works in Textmate and likely other editors.

Nice results: https://github.com/kevmoo/dartlib/commit/3f2e3466091b71277967038cb686a5595639b5e5
"""

With this tip, you'll change (old code):


TInput get input() => _input;

to (new code):

TInput get input => _input;

As of 11156 the VM runs the new syntax and dart2js warns if you're NOT using it. So now is a good time to update.


Thanks Kevin!

Monday, August 20, 2012

Dart Editor speed ups and fixes

Posted by Devon Carew


A new Dart Editor build is available at www.dartlang.org/editorChanges include:
  • 17 analysis issues fixed, as well as ongoing changes to support the M1 language.
  • We added a fix to not show errors or warnings for libraries in pub's packages directory.
  • The mark occurrences feature is now on by default. In addition, we also now warn about issues for inferred types by default.
  • UX improvements around quick fixes.
  • Improvements to the inline method refactoring, the extract local refactoring, and the create method refactoring.
  • Several Dartium and command-line launching fixes.
  • The Editor workspace location has changed. The workspace is where we store information about your open files and folders. We had stored this in a 'workspace' directory co-located with the Editor application. We now always locate it in the user's home directory. The first time you run this new build you'll have to re-open the folders you had been working on. For more info, see http://www.dartlang.org/docs/editor/#settings.
  • Several libraries have moved from dart-sdk/lib to dart-sdk/pkg. This means that they will not show up in the Files view and will no longer be accessible (erroneously) as a dart: import. You'll want to use pub to access these pkg libraries.
As always, view the changelog for the full list of changes, and to get started with the Editor see our tutorial.

Friday, August 17, 2012

Dart's modest proposal for Mixins

Posted by Gilad Bracha

(Editor's note: mixins is a work in progress, and is not slated for the M1 release. You can track the bug for this feature, and star it to be notified of changes. Please direct discussion to the Dart mailing list.)


Mixins in Dart

This document a minimalist proposal for introducing mixins in Dart. It is deliberately restricted in several ways, so as to minimize disruption to our existing implementations, while allowing future evolution toward a full fledged mixin implementation. The hope is that this restricted version already provides considerable value.

The intent is that something very much like this would be incorporated into Dart at some time after M1.

Basic Concepts


If you are familiar with the academic literature on mixins you can probably skip this section.
Otherwise, please do read it, as it defines important concepts and notation.


In a language supporting classes and inheritance, a class implicitly defines a mixin. The mixin is usually implicit - it is defined by the class body, and constitutes the delta between the class and its superclass. The class is in fact a mixin application - the result of applying its implicitly defined mixin to its superclass.

The term mixin application comes from a close analogy with function application. Mathematically, a mixin M can be seen as a function from superclass to subclass: feed M a superclass S, and a new subclass of S is returned. This is often written as M |> S in the research literature.

Functions are useful because they can be applied to different arguments. Likewise mixins. The mixin implicitly defined by a class is usually applied only once, to the superclass given in the class declaration.  To allow mixins to be applied to different superclasses, we need to be able to either declare mixins independently of any particular superclass, or alternately, to extricate the implicit mixin of a class and reuse it outside its original declaration. That is what we propose to do below.

A Modest Proposal


We propose that mixins be defined via ordinary class declarations.  In principle, every class defines a mixin that can be extracted from it. However, in this proposal, a mixin may only be extracted from a class that obeys the following restrictions:

  1. The class has no fields.
  2. The class has no declared constructors.
  3. The class’ superclass is Object.
  4. The class contains no super calls.


Restrictions (1) & (2) avoid complications that arise due to the need to pass constructor parameters up the inheritance chain.  Under those circumstances, restriction (3) encourages mixins to be declared explicitly. Restriction (4) means that implementations can continue to statically bind super calls rather than either rebinding them upon mixin application, or binding them dynamically.


Example:

class Collection<E> {
  abstract Collection<E> newInstance();
  Collection<E> map(f) {
    result = newInstance();
    this.forEach((E e){result.add(f(e));})
    return result;
 }
}

class DOMElementList<E> mixin Collection<E> extends DOMList {
  DOMElementList<E> newInstance() => new DOMElementList();
  ...
}

class DOMElementSet<E> mixin Collection<E> extends DOMSet {
  DOMElementSet<E> newInstance() => new DOMElementSet();
  ...
}


… 28 more variants


Here, Collection<E> is a normal class that is used to declare a mixin.  Both the classes DOMElementList and DOMElementSet inherit from mixin applications.

In the above, the superclass of DOMElementList is Collection mixin |> DOMList, while the superclass of DOMElementList is Collection mixin |> DOMSet.

The benefit here is that the code in class Collection can be shared in multiple class hierarchies. We list two such hierarchies above - one rooted in DOMList and one rooted in DOMSet. One need not repeat/copy the code in Collection, and every change made to Collection will propagate to both hierarchies greatly easing maintenance of the code. This particular example is loosely based on a real and very acute case in the Dart libraries.

How do the above examples work if DOMList or DOMSet have non-trivial constructors?

class DOMElementList<E> mixin Collection<E> extends DOMList {
  DOMElementList<E> newInstance() => new DOMElementList(0);
  DOMElementList(int size): super(size); // super size me
}


This looks good, but notice that:

  1. The superconstructor call invokes a non-trivial superconstructor.
  2. Collection has no non-trivial constructor.
  3. Constructors are not inherited.
  4. The superclass is the mixin application Collection |> DOMList, which by the above, has no non-trivial constructor, and so the code would appear to be erroneous.


To deal with this problem, I propose that each element of the mixin list has its constructor called independently. Each mixin has its own constructor called, and so does the superclass.  Since a mixin constructor does nothing at all, the call to it can be elided in both the syntax and the underlying implementation.  

Note however, that the generic type arguments must be set somehow. Usually, this would be set up by the constructors.

This rule ensures that these examples run smoothly and also generalize cleanly once one lifts restrictions (1) & (2).


A second example illustrates the limitations of the proposal, Suppose we want to create a Person who is Demented, Aggressive and Musical.

class Person {
 String name;
 Person(this.name);
}

class Maestro  mixin Demented, Aggressive, Musical extends Person {
 Maestro(name):super(name);
}


Here, the superclass is the mixin application

Demented mixin |> Aggressive mixin |> Musical mixin |> Person

we assume that only Person has a constructor with arguments. Hence Musical mixin |> Person inherits Person’s constructors, and so on until the actual superclass of Maestro, which is formed by a series of mixin applications.

However, in reality in this example we’d expect that Demented, Aggressive and Musical actually have interesting properties that are likely to require state. If they don’t, they are liable to be simply marker interfaces, in which case we did not need mixins at all.

Later on we will discuss how the restrictions might be lifted to accommodate such cases.

There remain many details to attend to.  This proposal is not yet at the stage of a full specification, but we can anticipate issues in the following areas:

  • Privacy
  • Statics
  • Types

these are discussed in the next few sections.

Privacy


A mixin application may well be declared outside the library that declared the original class. Should this have any effect on who can access members of a mixin application instance? I would hope not. Access to members would be determined based on the library where they were originally declared, exactly as with ordinary inheritance. Strictly speaking, I need not even bring this up, as it follows from the semantics of mixin application, which are determined by the semantics of inheritance in the underlying language.

Statics


Can one use the statics of the original class via the mixin application or not.  Again, the answer follows from the semantics of inheritance. Statics are not inherited in Dart.

Types


What is the type of a mixin application instance? In general, it is a subtype of its superclass, and also supports the methods defined on the mixin.  The mixin name itself however denotes the type of the original class, which has its own superclass and may not be compatible with a particular mixin application.

This would argue for defining mixins as distinct constructs, so that the mixin name would denote a stable type. However, this requires pre-planning. Instead, we might choose to denote the type of the mixin of a class C by a special type expression such as C.mixin.  Since this precludes the use of the word mixin as a member, I suggest instead that we provide a special notation such as C mixin.

Examples: x is C mixin or List<C mixin>.

What about the interfaces a class supports? Does its mixin support them? In general, no, since interface support may rely on inherited functionality. This implies that a mixin application must declare what interfaces it implements explicitly.

Generics are also an issue. If a class has type parameters, its mixin necessarily has identical type parameters. The first example illustrated this point and it raises no syntactic issues, but it does raise constructor-related issues for the implementation, even under our current restrictions.



Extensions


A key question is whether this proposal can be cleanly extended when we relax its restrictions. Restriction (3) by itself is of minor significance and can be dropped easily.  Restriction (4) requires more sophistication in the implementation: super calls must appear to bind dynamically to the actual superclass.  

Restrictions (1) and (2) are more complex.  An mixin clause with multiple identifiers is analogous to Scala’s with clause, which has no such restrictions. However, because of Dart syntax, there is no way to pass the constructor arguments up the inheritance chain.

One approach to addressing the issue is  illustrated below via an variation on our mad maestro example.

class Musical{
  final Instrument instrument;
  Musical(this.instrument);
}

class Aggressive {
 final String aggressionLevel;
 Aggressive(this.aggressionLevel);
}

class Demented {
final disorder;
Demented(this.disorder);)
}

class Maestro  mixin  Demented, Aggressive, Musical extends Person {
 Maestro(name, disorder, degree, instrument) :
    Demented(disorder), Aggressive(degree), Musical(instrument), super(name);
}


The constructor for Maestro explicitly channels the various parameters to the various mixins that are used to define its superclasses.  

The rules given in the restricted proposal still apply: each mixin has its constructor called independently, as does the superclass.  Only the part of the constructor that operates on the mixin itself is called. If the mixin had a superclass, that superconstructor is not run.

If calls to mixin constructors are absent, a default call of the form M(), where M is the name of the mixin, should be inserted by the implementation. This will ensure nulling out any of the mixin’s fields and calling of its default constructor if it exists. Of course, these calls may be optimized away if the mixin has no fields or constructors. Hence, both the behavior and performance of the restricted proposal are preserved.

Finally


There is one aspect of this proposal that is rather irregular:  mixin applications are defined via the mixin clause and always result in anonymous superclasses.

We could introduce a second form of mixin application written as a special kind of class declaration. It has its own name, type parameters, superclass and superinterfaces just like a normal class. Instead of a class body, it specifies a class whose mixin is used, followed by a comma- separated list of constructors, terminated with a semicolon.  

That form can be used to define a class that specifies constructors with appropriate plumbing - providing both the mixin and the superclass with the desired parameters.  We could support this in a simple form with a single class specifying the mixin.

Originally, the constructors were given inside curly braces, but this confused people who thought it was a regular class body.

This syntax closely matches the semantic structure. A mixin application creates a new class, and so is written very much like a class declaration, including its type parameters (if any) extends and implements clauses. The difference is only in the mixin of the new class. In a normal class the class body implicitly defines the class’ mixin. In a mixin application, the class body is replaced by an alternative way of specifying a mixin. The new syntax specifies the class whose mixin will be applied in this case. If necessary, its specifies what type arguments should be passed to the mixin. Optionally, a list of constructors for the mixin application is given.

Here is a variant of the malign musician example that illustrates the above

class Musician  mixin Musical extends Person:
 Musician(name, instrument): Musical(instrument), super(name) ;

class ViolentViolinist extends Musician mixin Aggressive:
 ViolentViolinist(name, instrument): Aggressive(‘very’), super(name, new Violin());


It is not yet clear that this additional form is useful enough to be justified.

Thursday, August 16, 2012

Breaking Change: XMLHttpRequest becomes HttpRequest

Posted by Emily Fortuna


Hello Dartisans,

When is the last time you fetched XML data with XMLHttpRequest? Exactly. :)

In the near future I will be landing a change that renames XMLHttpRequest (and the associated names like XMLHttpRequestException) to HttpRequest.

You can review the change list, which resolves dartbug.com/912 (a highly starred request, thanks for the feedback!)  In fact, we recommend that you star the bug so you'll be notified when the change takes effect.

So in the future, when you want to make an XHR request in Dart, you only need to use the shortened HttpRequest name. This is part of our continued efforts to build an easier to use interface for modern web programming.

Dart Team Updates and Notes

Posted by Seth Ladd


Summary

  • Summer vacations are wrapping up, back to work! The Dart project ramps up for the M1 release, which delivers a more stable language and implementations.

Details

Dart language specification:

  • Version 0.11 is almost ready - this is pretty much the M1 version.
  • Mixin proposal to be published.

Dart libraries [core, unittest, i18n, etc]:
  • Ability to make temporal assertions with the mocking library
  • Work in progress on sharing the source for the dart: library implementations across VM and dart2js.

Dart VM:
  • New language features implemented: “non-constant initializers for fields” (bug 3848), “static methods are compile-time constants” (bug 3406), “operator syntax” (bug 3767), “getter syntax” (bug 3608), “on-catch support” (bug 3757).
  • Switched to using SSA-based optimizing compiler both on ia32 and x64.
  • Using type propagation to eliminate assignability checks to improve checked mode speed.
  • Added support for external and patch to enable shared core library sources.
  • 20% decrease in initial heap size for new isolates.

Dart to JavaScript Compiler:
  • Improved noSuchMethod handling to limit the explosion in code size that used to arise from using the feature anywhere in the code base.
  • Started propagating type information through parameters to generate smaller and faster output.
  • Introduced basic framework for providing type information to the compiler backend, which will be used to experiment with global concrete type inferencing.

  • Added primitive support for external and patch to enable shared core library sources.

dart2dart:
  • Close to be able to bundle the whole dart2js into a monolithic Dart file

Dart Editor:
  • An initial implementation of a 'Create Method' quick fix. This will create a method definition to satisfy a reference to a non-existent method. You can access this functionality through the ctrl/command-1 keystroke; currently only top-level functions are supported.
  • Several analysis fixes and various updates to our analysis code for M1 language support.
  • We now include optional parameters in completion proposals.
  • There is a new Breakpoints view to view your debugger breakpoints.
  • Enhanced ‘Open Folder...’ to better support opening very large applications.
  • Fixes to the Apps view and enhancements to our Welcome page.

Dart UI [dart:html, web components]:

Dart SDK and build:
  • /lib being split into /lib and /pkg well underway.

Pub:
  • Read-only site for pub.dartlang.org (not live yet).
  • Support for installing packages from a package hosting site (like pub.dartlang.org when it’s up).
  • Windows support for Pub is coming along.
  • New documentation with more coming.

Dart Server [dart:io, etc.]:
  • Work in progress on HTTPS support.

Dart Dev Rel:
  • Auto-publish API docs on successful build.
  • Added a page on Dart books
  • More episodes of Dartisans

Follow along with a Dart port of minesweeper

Posted by Seth Ladd


Dart community member and contributor Kevin Moore is building a minesweeper clone in Dart. Lucky for us, he's writing a "developer diary" to chronicle his progress. Follow along as he builds a fun simple game for mobile and desktop with the Dart project.



From his first journal entry:

tl;dr: I'm building a version of Minesweeper in Dart as an example of something straight-forward and fun. I hope to show how to build Dart apps and demonstrate why Dart is a great tool for building web experiences. Play it here. Check out the code on Github. Watch my blog for updates in the next few weeks.

Follow his blog to learn how the game is built. We're looking forward to what Kevin makes with Dart!

Monday, August 13, 2012

Dart plugin for Eclipse is Ready for Preview

UPDATE: Eclipse plugin for Dart is now stable and ready to use. Learn more https://www.dartlang.org/tools/eclipse-plugin/

Greetings Dartisans,

We're happy to announce that the Dart Editor Plugin for Eclipse is ready for preview. There are still some rough edges and we don't have feature parity with the standalone Dart Editor but there's enough in place that interested folks may want to check it out.

If you want to kick the tires, add the following URL to the list of available software sites in your Eclipse installation (Window > Preferences > Install/Update > Available Software Sites):

http://www.dartlang.org/eclipse/update/

Important note: on initial install, a secondary download of the dart SDK will occur. The download should only take a few seconds and will happen in the background with progress displayed in the status line. When it's done, you'll need to restart eclipse (again). (For the curious, this second restart is required to get the SDK properly recognized and is only a short-term work-around -- but hey it's an alpha!)

As always, your feedback is greatly appreciated. (And we're counting on it! :)) For general issues and feedback, feel free to chime in on issue 702, or open a new one on dartbug.com.

Thanks!

Posted by Phil Quitslund

Dart Editor adds Create Method quick fix

Posted by Devon Carew




A new Dart Editor build is available at www.dartlang.org/editorChanges include:
  • An initial implementation of a 'Create Method' quick fix. This will create a method definition to satisfy a reference to a non-existent method. You can access this functionality through the ctrl/command-1 keystroke; currently only top-level functions are supported.
  • Several analysis fixes and various updates to our analysis code for M1 language support.
  • We now include optional parameters in completion proposals.
  • There is a new Breakpoints view to view your debugger breakpoints.
  • Enhancements to our open folder code to better support opening very large applications.
  • Fixes to the Apps view and enhancements to our Welcome page.
As always, view the changelog for the full list of changes, and to get started with the Editor see our tutorial.

Friday, August 10, 2012

9 ways to follow along with Dart

Posted by Seth Ladd


"How do I keep up with all the news and info about Dart?" was a great question posted to our mailing list. This post summarizes how you, the busy developer, can keep up with Dart.

  1. Subscribe to news.dartlang.org for postings on upcoming language changes, announcements, and news.
  2. Circle +Dart on Google+ for news and community projects.
  3. Follow #dartlang on Twitter and #dartlang on G+ to get an overview of all Dart activity.
  4. Ask and answer questions about Dart on Stack Overflow.
  5. Community news is posted to blog.dartwatch.com.
  6. Blog posts about Dart are collected at dartosphere.org.
  7. Star issues at dartbug.com to get email updates. Try searching for M1 milestone issues.
  8. Watch the Dartisans show (video and podcast) for interviews and discussions.
  9. If you like discussing language design, join the Dart discussion mailing list.
Hope that helps!