Monday, October 29, 2012

Breaking Change: More methods turn to getters

The Dart libraries continue to evolve, with a new round of methods turning into getters. Florian Loitsch posted this notice to the Dart mailing list:

As of r14094 Map.getKeys() has been changed to Map.keys, Map.getValues() to Map.values, and Match.start()/end()/groupCount() have been made getters.


Examples:
myMap.getKeys() is now myMap.keys.
myRegExp.firstMatch("foo").start() is now myRegExp.firstMatch("foo").start.

As always, the Dart encourages you to join the conversation on the Dart mailing list, ask questions on Stack Overflow, and file feature requests and bugs on dartbug.com.

3 New Code Cleanups from Dart Editor

Dart Editor has added three new code clean ups to its growing list:
  • Replace some methods with getters
  • Renaming some types
  • Removing abstract keyword for methods without a body

Other new features include:
  • New “Organize Imports” action
  • New migration Clean Ups -  replacing some methods with getters; renaming some types; removing “abstract” keyword for methods without body.
  • Enhanced “Extract Method” refactoring to allow changing parameter types
  • In the command-line debugger, we added the ability to pause a running isolate.
  • Improved how we display null value objects in the debugger.
  • Updated samples based on language and pub changes
  • Fixes for inline method and local
  • Fixes for syntax highlighting
  • Fix to automatically refresh out-of-sync resources
  • Fixes to better handle package symlinks in search and the files view.
And as always, view the changelog for the full list of changes, and to get started with the Editor see our tutorial.

The editor auto-updates now, so you should have these new features when you restart. You can check by opening Preferences and displaying Updates.

As always, the Dart encourages you to join the conversation on the Dart mailing list, ask questions on Stack Overflow, and file feature requests and bugs on dartbug.com.

Thursday, October 25, 2012

Use Web Components Today with Dart

In a new article posted to the Dart homepage, engineer Siggi Cherem shows you how to build with Web Components using Dart. Web Components are ushering in the "declarative renaissance" for modern web app development, providing encapsulation of structure, styles, and behavior.

"But it'll be years before I can use Web Components!?!" you exclaim. Not true! Thanks to Dart you can compile Web Components into today's HTML and JavaScript.


In the article, Siggi writes:


Dart web components provide templates, data binding, and encapsulation, to help you write web applications at scale. An early version is available in the dart-web-components project. 
Many UI frameworks exist for writing web apps in JavaScript—for example Backbone.jsEmber.js, and AngularJS. Recently, the web community has been pushing to include some of the common ideas of these frameworks directly into the browser platform. As a result, browsers have added features like shadow DOM and web components, and other experimental and cool ideas have been proposed, such as model-driven views (MDV). 
Dart web components combine the ideas of web components and MDV, adapting them to work well with Dart. Dart web components take advantage of advanced browser features when possible, emulating missing features when necessary.

There's more work to be done, with support for Web Components in Dart just getting started. Now is a good time to try out the project and talk to us in the Dart mailing list or ask questions on Stack Overflow.

3 Tips for Benchmarking Dart Applications

John McCutchan shares three tips for benchmarking your Dart application. Benchmarking is the act of measuring how much memory or CPU time your application takes to execute. The article focuses on CPU benchmarking and explains how to correctly set up a Dart benchmark.

Make your code faster (Photo by Slooby)
The article covers these three important steps when benchmarking your Dart application:
  1. Perform a warm-up before measuring code performance.
  2. Ensure the code does not raise any errors when run in checked mode.
  3. Run your benchmark in production mode with debugging disabled.
As always, the Dart team is interested in your feedback. Please join the Dart mailing list, ask questions on Stack Overflow, and file feature and bugs on dartbug.com.

Tuesday, October 23, 2012

Coreimpl finally waves goodbye, and more breaking changes

Looks like the work on Dart libraries is really picking up. It was announced that dart:coreimpl is being removed, and some methods on numbers are now more simple getters.

dart:coreimpl will be removed

Anders Johnsen wrote to the Dart mailing list:

I've already started moving implementation classes out of dart:coreimpl and making them a private member of dart:core. I'll continue to move the rest over the week. 
Once the move is done, we intent to re-expose some of the same functionality in other libraries. 
If you are currently using any of the classes in dart:coreimpl, you can make a local copy for your program to use, and file a bug for a feature request in the library area on http://dartbug.com/new.
isNaN and friends are now getters

Florian Loitsch also wrote:

Starting with r13974, you'll find that isNaN, isInfinite, isEven, isOdd, isNegative on numbers are now getters. In the same CL I updated the fixnum pkg where I also change isZero, isMaxValue and isMinValue. 
https://codereview.chromium.org/11227042/diff/2001/lib/core/num.dart 
https://codereview.chromium.org/11227042/diff/2001/pkg/fixnum/intx.dart 

In general the fix should be easy:
d.isNaN() -> d.isNaN, ...

We suspect this is only the beginning. Stay tuned on the Dart mailing list or ask questions on Stack Overflow.

Dart syntax changes landing soon, update your code

With the release of M1, the Dart team is preparing to remove some of the old syntax that was deprecated. Kasper Lund, engineer on Dart, writes about the upcoming changes and how you can migrate your code.

Note: Dart Editor has a nice Clean Up feature that can automatically update your code for many situations.



Kasper writes:

We're ready to start removing the syntax we deprecated in M1. The
annoying thing is that you may have to update your code. The good
thing is that the replacement syntax is already in place and you can
use it today. Here's a brief list of the deprecated syntax that we
will be removing shortly.


Remove old getter syntax

We're getting rid of the old getter syntax so going forward you will
no longer be allowed to have parentheses after your getters. If you
use:

   get length() => 42;

you'll need to change that to:

   get length => 42;


Remove member/constructor conflict support

Your named constructors can no longer have the same name as a member
of your class. They share a namespace. If you have code like this:

   class C {
     C.named();
     named();
   }

then you'll need to rename one of them.


Remove old optional parameter syntax

You will no longer be able to pass optional parameters that are put in
[brackets] by name; they can only be passed positional. If you want to
have named optional parameters you need to put them in {braces} in
your method declaration. Be aware that the parameter names become part
of you API so try to spend as much time on picking good names for your
optional named parameters as you spend on picking good method names.
See Régis' write up for more info.



Remove abstract modifier on methods

Methods are abstract if they do not have an implementation (does not
apply to constructors). You should be able to just remove the abstract
keyword in front of your methods.


Remove interface declarations

The support for explicit interfaces has been replaced by implied
interfaces -- usually of abstract classes. If you have an interface in
your code like this:

   interface I {
     foo();
     bar();
   }

you should be able to replace that with an abstract class (its
interface will still be implementable):

   abstract class I {
     foo();
     bar();
   }


Remove old library/import/source syntax

The old #library, #import, and #source directives have been replaced
by library, import, and part. Additionally, you'll need to mark your
part files as parts using the 'part of' syntax. If you had something
like this before:

   #library('whatnot');
   #import('other.dart', prefix: 'other');
   #source('src.dart');

you will have to change it to:

   library whatnot;
   import 'other.dart' as other;
   part 'src.dart';

and you'll have to add a line to the beginning of src.dart:

   part of whatnot;
   ...


Remove ===

The support for === and !== is about to go away. If you have an expression like:

   (a === b) && (c !== d)

you can change it to:

   identical(a, b) && !identical(c, d)

The identical function is defined in the dart:core library which is
automatically imported everywhere. We usually prefer using the ==
operator instead of calling the identical function, so unless you're
really going for an identity check you may want to translate uses of
=== to ==.


Remove Dynamic

The special Dynamic type has been renamed to dynamic.

You can read more about these and other M1 language changes. As always, we encourage you to join our mailing list, ask questions on Stack Overflow, and file feature requests and bug reports.

Build HTML5 games with Dart



Learn how to build HTML5 games with Dart in this video from Kevin Moore. Kevin walks you through his open-source Pop Pop Win! game.


Kevin used HTML5 canvas, Web Audio API, and more. He also uses his BOT pub package, which is a collection "of (mostly) general libraries to make working with Dart more productive." You can see all the code to Pop Pop Win! on Github. The game even works on desktop and mobile!

Monday, October 22, 2012

Dart's JavaScript compiler's optimization techniques

Dart engineer Florian Loitsch presented "JavaScript as a compilation target - Making it fast" at JSConf.EU. The video is now up:


Florian discusses how dart2js, Dart's compiler to JavaScript, works and goes over some of its features. For example, dart2js performs "tree shaking", a technique to eliminate dead code from the compiled output code.

Enjoy!

Friday, October 19, 2012

Update your optional params syntax now, Dart VM and dart2js

Régis Crelier, engineer on the Dart team, posted the notice that both the Dart VM and dart2js will start to enforce the new optional parameter rules. From his mail:


On Monday, we will submit a change to bleeding-edge enforcing the new optional parameter syntax and semantics, as described in the spec.
Until now, both the vm and dart2js have been running in a backward compatible mode, where named arguments could still be passed to optional positional formal parameters, which is not allowed under the new rules. 
If you want to check before Monday whether your code is going to break, please use the flag --reject_named_argument_as_positional for both the vm and dart2js.

To learn more about these changes, read about how named optional params and positional optional params are specified differently.

As always, we encourage you to join the Dart mailing list, ask questions on Stack Overflow, and file feature requests and bugs at dartbug.com. Thanks!

More Dart libraries ready for use, thanks to Pub



One of the big features of the Dart M1 release is our package manager, pub. You can discover, install, and manage 3rd party Dart libraries with pub. Pub is a command-line app with Dart Editor integration, as well as a hosting service for Dart packages. We've been uploading select packages, but soon you'll be able to upload your own packages to pub.

I sat down with two of the pub engineers, Bob Nystrom and Nathan Weizenbaum, to learn more about pub and what's on the roadmap.


Q) What exactly is a package?

Bob: It’s a directory containing Dart code and all of the other stuff that goes along with it: tests, docs, examples, resources. It also has metadata that describes the package and its dependencies–the other packages it relies on.

Nathan: It’s important to note that Dart applications can be packages even if they don’t export any libraries and they’re not going to be re-used anywhere. As long as it declares its dependencies in a pubspec, pub considers it a package.



Q) I see some import statements like 'package:foo/foo.dart'. What is the package: there for?

B: At some point, I’ll write down the full explanation for why that’s needed. The short answer is that it “flattens” your import paths so that imports across transitive dependencies work. The simple answer is “it’s how you import code that’s in a package.”

N: “package:” is the magic that lets pub do its work. It tells Dart to look for imports in the “packages” directory, rather than just looking relative to the importing file. Pub generates this directory and fills it with your dependencies, allowing them to be imported.



Q) What happens when I run 'pub install' ?

B: In short, it makes sure all of your package’s dependencies are installed and wired up so that you can use them. I wrote up a more detailed description of what happens from pub install.

N: If a “pubspec.lock” file exists, “pub install” will install the locked versions of all the packages. This is very useful for application packages, since they can make sure that all their developers -- and more importantly, the deployment servers -- are using exactly the same versions of all their dependencies. This helps prevent unexpected breakages.



Q) What package managers did you study when you designed pub?

Bob: For the pub app, the main ones I looked at were RubyGems, bundler, and npm. I also did a bit of reading on maven, apt-get, easy_install and probably a couple of others I’m forgetting. I briefly checked out LuaRocks, Chicken Scheme’s package management system and a bunch of other random ones too.

For pub.dartlang.org, I continually had rubygems.org, npmjs.org, pypi.python.org, and cpan.org open in other tabs for design ideas.

Nathan: The biggest inspiration for pub’s installation model was definitely Bundler, from which we picked up the install/update dichotomy. The version constraints follow in the footsteps of many major package systems for other languages, and make use of the semantic versioning spec.



Q) How can someone publish a package to pub.dartlang.org?

B: Right now, there’s no way to upload your own package. We’re building out a user experience to do that now and should have that in place relatively soon. In the meantime, file a bug with the title “Request to host package - <your package name>” and we’ll upload it for you. Make sure to include a path to a repository (usually github) where we can download it.

N: Once user uploading is allowed, it’ll be very easy to publish a package. You’ll just need to run a single command, either through the Dart editor or from the command line, and pub will make sure your package is in good shape and then push it up to pub.dartlang.org.



Q) What do you have planned for pub?

B: The next big thing will be letting you upload your own package and getting us out of that loop. After that, there’s a long list of features we want to add. For pub itself, we want commands for linting your package to see if it’s following our guidelines, building and compiling your package to something deployable, running your tests, and other stuff.

For the site, there’s a bunch of discovery things we want to do now that we’re starting to get some data. Stuff like “here’s the most downloaded packages”, “here are the packages that are the most depended on”. We want to make the site automatically show you which packages are the most prominent and loved in the community.

Also, there’s a bunch of stuff we can do to make your life as a package author better: things like automatically running your tests, generating reference docs from your code and showing it on the site, displaying your README, etc.

N: In the more distant future, we’re planning to make pub work really well for deploying applications, especially to browsers. We want to have a single command that will grab all your Dart libraries and their dependencies, compile them to Javascript, throw away any unused code and merge the rest into a single minified JS file that’s ready to be served.



Q) What advice do you have for new package authors?

B: Follow the guidelines but don’t feel your package needs to be “done” before you put it out there. Everything is versioned specifically to enable things to grow and evolve over time.

N: Make use of other packages! Pub makes it so easy to depend on other packages, there’s no reason not to use them if they provide useful functionality.



Q) I have a good idea for pub. How can I send feedback?

B: Bring it up on the mailing list or file a bug. Filing a bug will make sure we look at, bringing it up on the list will solicit more discussion from the entire community.

N: Keep in mind that there are a lot of features we want to add to Pub, and only two of us working on it. If we don’t immediately address your suggestion, don’t despair; we’ve seen it, and we’ll keep it in mind.



Q) How can I learn more about pub?

B: Read the docs! We have lots.

N: If the docs don’t fully answer your questions, feel free to ask them on the mailing list. If we don’t answer it, one of the other community members will.


Thanks to Bob and Nathan, and thanks to all our Dart library authors that are already getting their code ready for pub.

Thursday, October 18, 2012

Speed Matters, says Dart co-founder Lars Bak

Lars Bak, engineer on HotSpot, V8, and now co-founder of Dart, presents a bit of history that lead to Dart and why performance is key for the web.

Lars Bak from Stange Loop conference


The video and slides from his presentation "Pushing the Limits of Web Browsers" from Strange Loop in September 2012 are now available. In the presentation, he covers lessons learned from building Java VMs, Smalltalk VMs, JavaScript engines, and how those lessons impacted the design of Dart.

Slide from Strange Loop presentation

Tuesday, October 16, 2012

Celebrating Dart’s birthday with the first release of the Dart SDK

A year ago we released a technology preview of Dart, a project that includes a modern language, libraries and tools for building complex web applications. Today, after plowing through thousands of bug reports and feature requests from the web community, a new, more stable and comprehensive version of Dart is now available and ready to use.




With this version of the Dart SDK, we’ve made several improvements and added many features:




Over the following months, we will continue to work hard to evolve the SDK, improve Dart’s robustness and performance, and fine-tune the language while maintaining backwards compatibility.

You can download the Dart Editor from dartlang.org. It comes with a copy of the open-source SDK and Dartium. Thanks again for all your feedback - keep it coming.


(Cross posted from Chromium blog)

Thursday, October 11, 2012

Notes from October 8 language design meeting

Dart engineer Bob Nystrom has posted the notes from the October 8 language design meeting. He writes:


Making throw an expression

Lars wondered what the motivation behind adding to the spec was. My recollection was that it was so you could use it in lambda-body methods:

  class ImmutableList implements List {
    void add(item) => throw new NotSupportedException();
  }

Kasper looked at the code to parse throw as an expression and found out it's hideous because of rethrows.

Lars wants to know more about the impact of this. How tightly does it bind when embedded in an expression? Do we want to allow it in a ternary operator? He wants to know more about the original motivation behind this.

Mixins

Lars suggested we could do the general purpose solution and allow constructors but he would prefer something stepwise where we don't allow constructors at first. You could still have fields but they would need initializers at the declaration. We can get some experience with the feature and this will probably solve more use cases.

Gilad is all for it and asked about the timeline.

I asked if we'd be able to make changes to corelib to take advantage of mixins once they are supported even if those happen to be breaking changes. The answer is yes, but we of course want to minimize breakage.

Library tags

I asked about the intent behind library tags. I thought you only needed them if you use part, but the spec says the only place you can omit them is scripts which have a main() method.

Kasper says we want to encourage people to name their libraries because you get nice benefits like it can tell you if you accidentally import the same library from two different paths, which would be confusing because you'll get two copies of your statics.

Right now, the spec is maybe stricter than our original intent, but its easier to loosen it over time than go the other way, so lets leave it as it is.

Cheers!

Tuesday, October 9, 2012

Show type hierarchy in-line with new Dart Editor

A new Dart Editor build is available at www.dartlang.org/editor. Changes include:
  • We now support showing an in-line type hierarchy view (Command-T on the Mac and Ctrl-T for Linux and Windows).



  • We have a new Quick Fix to import or create a type when it is used as invocation target.
  • General work to the Eclipse plugins including:
    • cleaning up some spurious menu contributions,
    • adding menu items to invoke dart2js and dartdoc
    • and adding the ability to open Dart files in non-Dart projects
  • Several code completion enhancements, including:
    • support for both named and optional parameters
    • showing proposals for function parameter names following unary-?
    • improved proposals for cascades
  • Web components support is now enabled on Dartium launches by default.
  • The .project metadata file has been moved out of the user's source directory.
  • The html and css editors now use a default indent of two spaces.
  • 6 analysis fixes, as well as fixes to the debugger, Outline view, feedback dialog, auto-update, and our analyze-as-you-type feature.
And as always, view the changelog for the full list of changes, and to get started with the Editor see our tutorial.

Monday, October 8, 2012

Debunking Dart Myths

Today, Seth Ladd, Developer Advocate for Dart, was interviewed by Addy Osmani, Developer Programs Engineer for Chrome and Tools. Addy asked the tough questions that many web developers have about Dart, and Seth debunked (you might say busted) some of the most common myths.

Watch the video to see questions answered like "Is Dart out to replace JavaScript?" (spoiler: nope!), "Does Dart work with JavaScript code?" (spoiler: you bet!), and "Isn't Dart's compiled output to JavaScript really big?" (spoiler: not any more!)

If reading is more your thing, Seth also wrote up 9 Dart myths debunked.

As always, the Dart team wants to hear what you have to say. Join the discussion in the Dart mailing list, ask questions on Stack Overflow, or file bugs and feature requests on dartbug.com. Thanks for trying Dart!

Wednesday, October 3, 2012

The Dart Team Welcomes TypeScript

It must be something in the water. Gilad Bracha and Lars Bak announced Dart in Aarhus, Denmark about a year ago as a “new programming language for structured web programming”. Yesterday, Anders Hejlsberg, once again in Aarhus, Denmark, announced Microsoft’s new programming language, TypeScript, “a language for application-scale JavaScript development”. Obviously, there’s something about the water in Aarhus that causes language designers to want to tackle the problem of large scale web development. Perhaps that’s why we chose to put the dart2js team in Aarhus full time!

Now that we’ve had a chance to take a look at TypeScript, the Dart team would like to welcome the TypeScript team to the neighborhood. If you already have a large JavaScript codebase, and if you already use Visual Studio, we think that TypeScript could be a great addition to your project.

A year ago, JavaScript programmers would frequently ask us why we needed a new programming language for the web. We argued that developing large web applications was hard, and that optional static type annotations could help. We also argued that the web needed better tooling support. We think that TypeScript has validated both of these statements. Going forward, I think the Dart project and TypeScript will learn a lot from each other.

A lot of people have been wondering what this means for Dart. The fact is, we’re more excited than ever! By making a break from certain parts of JavaScript’s syntax and semantics, we’ve eradicated large classes of bugs caused by various JavaScript gotchas. Nonetheless, last week, the Dart team released its own approach to using JavaScript in Dart apps, and our ongoing work with Web Components and isolates is finally delivering on the long hoped-for dream of encapsulation in the browser.

We’re even more enthusiastic about our plans to go beyond what JavaScript can do natively. Even though Dart can be compiled to JavaScript, Dart’s virtual machine opens up entirely new possibilities. For instance, our early testing with a feature called snapshotting allows Dart apps to start up 10 times faster than normal JavaScript. We also think that Dart is going to be a great fit for mobile. Finally, although V8 performs amazingly well in various JavaScript benchmarks, the Dart VM is already beating it in some of our internal benchmarks.

So once again, we’d like to welcome TypeScript. We think the web has suffered from too little choice for too long, and we think that the future of large-scale web development is looking brighter than ever!

Monday, October 1, 2012

Dart Editor now analyzes as you type

A new Dart Editor build is available at www.dartlang.org/editor. Changes include:


  • We now have analysis as you type! You're now alerted about errors as you type without first having to save the file.



  • Debugger expression evaluation - when paused at a breakpoint in Dartium it's now possible to evaluate expressions. You can access this feature from the 'Show Expressions' toolbar button in the Debugger view. This is a Dartium only feature currently; support for the command-line debugger is forthcoming.
  • We have two new quick fixes; one for creating a class and one for creating a constructor.
  • Fixes for debugging command-line and Dartium apps when used with Pub and the packages directory.
  • Tweaks to the @deprecated and @override presentation.
  • And fixes to the cleanups, to our auto-update, for a debugger crash with Dartium, as well as 11 analysis fixes.
In addition, if you're running MacOS 10.8 (Mountain Lion), it will complain that our 64-bit distribution is corrupted. The net-net is that we need to sign our binary, but in the meantime two workarounds are to download our 32-bit build instead, or to change your security settings to let you run applications downloaded from anywhere.

And as always, view the changelog for the full list of changes, and to get started with the Editor see our tutorial.