Skip to main content


Showing posts from February, 2012

Dart buildbot now publicly available

Posted by Rico Wind The Dart buildbot is now publicly available at . You can see the build status of projects like the VM, Editor, and Dartium. Enjoy!

Static variable initialization opened up to any expression

Posted by Gilad Bracha (Follow along with the original thread titled Lazy initialization of statics from the mailing list.) In Dart static variables may only be initialized with compile-time constants (hereafter referred to as just constants in the interest of brevity).  Static variables include all top-level variables as well as static variables of classes. The motivation is our desire to avoid costly initialization (and attendant slowness) at program startup. However, the requirement to use constants is quite restrictive. We plan on relaxing the restrictions on initialization of statics while still avoiding high latency at startup by making the initialization lazy. We can evaluate the initializer at first use rather than at library or class load time. We are aware that the interaction of laziness and imperative programming is problematic, because results are timing dependent. Currently this is a non-issue because the initializers evaluate constants, which are timing-indepe

Upcoming changes to the isolate API

Posted by Sigmund Cherem We are actively working on improving the isolate APIs. If you have code that uses isolates today, some of our upcoming changes will likely break your code. Here are a few of the changes coming up: We are moving the isolates code out of corelib into a standalone ' dart:isolate ' library. We are making any top-level static function a valid entrypoint for an isolate, so you'll no longer have to create a class to define an isolate's entrypoint. We want to simplify other parts of the API too, like how to obtain a port after spawning an isolate. Later on, we plan to support spawning an isolate given a URL to its code. For example, this code written with today's API: // soon to be deprecated! class MyIsolate extends Isolate {   MyIsolate() : super.heavy();   main() {     port.receive((msg, reply) => reply.send("re: $msg"));   } } main() {   MyIsolate myIsolate = new MyIsolate();   myIsolate.spawn().then((SendPort

New Dart Editor now bundles and launches Dartium

Posted by Eric Clayberg A new Dart Editor build is available, download it now to get started.   Highlights for build 4577 include: SDK and Dartium bundled with Editor Editor launches apps in Dartium by default Always use Frog to generate JavaScript JavaScript generated only when launching non-Dartium browser General fixes and performance improvements Omnibox opens search view when return pressed Add hyperlinking support to stacktraces that display in the console  view Enhanced welcome page   For more information, please read the change log . Check out the Dart Editor tutorial to get started.

Dart Team's Weekly Digest

Posted by Anders Sandholm Quick update on what happened in Dart-land this week. While we’ve seen the first steps taken in local inspection in the debugger in Dartium, the VM is implementing debugger stepping. The VM is also adding support for object groups to enable proper GC in Dartium and we’ve seen the first few code reviews, commits and build breaks by the new compiler infrastructure. Finally, the VM team has been fixing overly aggressive type checks which should only be static type warnings. In the editor, we only generate JS when launching a Dart app in a non-Dartium browser, we introduced a switch to always use Frog for JS code generation and cleaned up the welcome page. Finally, a few omnibox search improvements were landed along with analysis performance improvements and general fixes. Wrapper-less HTML generator was checked in and we had lots of infrastructure work - getting rid of instability in buildbots, testing frog hosted in browser (with frogpad). In the dart:io

Enabling type checks

Posted by Seth Ladd Adding types to your Dart program helps express your intent more clearly to your fellow developers. The Dart platform can also use those type annotations to catch errors and warn you of problems from mismatches or bugs from incorrect types. Turning on "checked mode" will enable these type checks, catching your bugs early and providing valuable feedback during development. The Dart VM can run in two modes: checked and production. Checked mode turns on type assertions, and reports on type mismatches and bugs. Production mode runs with the type assertions turned off, which may result in a speed boost. We highly encourage you to run in checked mode during any and all development. In checked mode, you will see errors like " type 'OneByteString' is not assignable to type 'num' of 'a' " if there are type mismatches: To enabled checked mode, use these methods: for the VM: --enable_type_checks --enable_asserts

Method Cascades in Dart

Posted by Gilad Bracha (UPDATE: Method cascades are now implemented.) The idea of a cascaded method invocation originates in Smalltalk, and has been proposed for Dart.  The motivation is to make it easier to write more fluent interfaces.  Usually, fluent interfaces rely on method chaining. Say you want to add a large number of elements to a table: myTokenTable.add("aToken"); myTokenTable.add("anotherToken"); // many lines elided here // and here  // and on and on myTokenTable.add("theUmpteenthToken"); You might want to write this as myTokenTable.add("aToken")             .add("anotherToken").                // many lines elided here             // and here              // and on and on             .add("theUmpteenthToken"); but this requires that  add()  return the receiver,  myTokenTable , instead of the element you just added. The API designer has to plan for this, and it may c