Dart heads into beta phase

With the latest release, Dart is now in beta.  As a "toolable language", one of the big highlights is a much faster Dart analyzer, for both the Dart Editor and the command line SDK.  The Dart editor is now really usable, and with its many refactoring tools, it helps you to build complex applications, with type and typo checking as you go.

Other highlights include a dart2js tool that produces 3.7x smaller JavaScript output, improved VM performance, and a pub deploy tool to create a deployable version for your website.

Well done to all everyone involved!

Announcement: http://googledevelopers.blogspot.co.uk/2013/06/dart-faster-editor-and-more.html
Release notes: http://news.dartlang.org/2013/06/release-notes-for-darts-beta-release.html

Win-win for developers and users: Dart @ Google I/O 2013

Google I/O 2013 is now over, and Dart had a pretty good showing, with three Dart talks and a codelab.
Performance was a big theme throughout Google I/O, especially with Chrome and Mobile in mind. Mobile apps running with a touch screen need to be more responsive than ever to create a good user experience (when you're physically touching a widget, you expect it to respond immediately to your touch), and there was lots of discussion about the target 60 fps refresh rate on mobile.

Win 1: Great performance for users.

Lars Bak and Kasper Lund's talk on VM Performance highlighted some of the problems that they face when designing a VM. They've designed VMs in the past (including Hotspot VM and Chrome's V8), and although V8 made great leaps initially (an initial benchmark in Firefox ran at "100" when V8 was being invented. Now, the same benchmark runs at around "~16,000"), the rate of improvement is slow. In order to get the next "leap" in performance, they need to address some of the problems with the actual language (JavaScript). An example given in their talk is that V8 optimizes based upon known executions of a block of code up to that point. If, however, that code changes (such as inserting a new property into the prototype), the optimizer has to back-out the optimizations until it's ready to optimize again. All this has an overhead.

By designing a language that is designed to make it easy to optimize a VM for, Dart's is already ahead of V8 in terms of performance (after only about 2 years of development, compared to 7 years of V8).

Image courtesy Stephen Shankland / cnet

There are (currently broken) instructions on the Dart wiki about building a VM on ARM, and it has to be thought that a long-term goal must be to get the Dart VM (integrated with chrome?) running on Android. This has twin benefits for users: better application performance, and longer battery life (as there is less work done).

By making use of advance chip technologies, such as SIMD (Single Instruction, Multiple Data) the Dart VM is able to leverage the maximum power available. A great demo of this was the 3d demo of monsters - only around 35 were visible with SIMD turned off in the VM (at 60fps), but when SIMD turned on, 60fps was maintained with ~120 monsters.

Image courtesy Stephen Shankland / cnet

Win 2: Great experience for developers.

I also spent some time on the Dart stand in the sandbox talking to web developers about Dart, and went to the Dart codelab. As a developer, it's awesome to be able to leverage Web Components combined with Dart's well known language features (libraries, functional, unsurprising and familiar classes, optional typing), all wrapped up with with great tools such as package management, IDE, Debugger and type checker. Developers that I was talking to at the Dart stand seemed suitably impressed with what Dart currently had to offer (especially as many hadn't looked at it since its initial release).

"It can't really be this easy?"

In the Codelab, which used Web Components to build a multi-file, offline document editor, the other developers sat around me had positive views, with one even saying "It can't really be this easy? - It almost feels like cheating." - Yes, Dart really is productive. Give the codelab a try and see for yourself.

That quote summed up the current state of Dart for me, when I go around doing talks on Dart, and showing Dart to fellow developers, they are often surprised to see the great developer story and productivity gains. When combined with the improved performance of apps with the Dart VM, they start to see how it can help to move web applications on to the next level.

On JavaScript future.

Because Dart also targets JavaScript, any advances made in JavaScript to allow better JavaScript optimizations will also benefit developers and users. Developers still get the same great Dart development story, and users will benefit from increased performance of their JavaScript version of the Dart app. Of course, browsers that contain the Dart VM will likely to continue to remain faster running native Dart than the equivalent JavaScript.

The Sessions from I/O

• Codelab: Mobile web apps with Dart and Web Components
• Dart: The Future of HTML
• What's new in Dart: Your First Class Upgrade to Web Development
• Web Languages and VMs: Fast code is always in fashion

Images from cnet article "Dart will rescue browsers from JavaScript"

Lots of new ways to keep up with #dartlang changes

The Dartisans community has grown, with currently >2000 members on the +Dartisans group, and >1500 subscribers to the Dart Weekly newsletter.  Keeping up with the latest changes can be tricky.

Google's Andrei Mouravski has just posted this on the mailing lists:

tl;dr: We have some new discussion groups. Sign up for announce@dartlang.org.

For a quick summary, read the Guidelines section below.

Hello Dartisans!

As our community has grown, so has discussion around Dart, so we have created four new discussion groups, and updated a few others.

New Groups:

announce@dartlang.org : Dart Announcements

This group is for official announcement for the Dart project. This will be product releases, breaking changes, major events, press briefs, and other important messages for the entire Dart community. For now, the group will remain limited to a select group of individuals who manage specific parts of the Dart project.

I recommend signing up for this group today, as it is a low volume way to stay up to date with Dart on a day-to-day level.

---

Note: Replies to announcements in this group should go to dart...@dartlang.org to keep the announce list noise-free, but still provide a forum for discussion.

For the time being, posts to anno...@dartlang.org will be forwarded to mi...@dartlang.org.

In a few weeks we will remove the forward to misc@dartlang.org to prevent unnecessary duplicate e-mails, so sign up now!

dart-dev@dartlang.org : Dart Core Project and Libraries Development

This is the list to go to if you want to discuss the development of the Dart open source project. As the project continues to grow, it’s important to be able to stay connected with state of the core of Dart itself.

This is a good place to talk about core library APIs, discuss breaking changes, and interact with the Dart engineering team. If you’re thinking of contributing to the Dart project, let us know in this group!

This list will be more technical than some of the other lists, so keep that in mind when subscribing. You should subscribe to this list if you’re interested in keeping up with day to day Dart development and engineering.

---

Note: If your discussion is about a project you’ve created, broad feature requests such as other languages’ features you’d like to see in Dart, the state of the web/JavaScript/html5/etc., news, links, or events, then please post to misc@dartlang.org. See the guidelines below.

html-dev@dartlang.org : Dart DOM/HTML Libraries Development

If you want to keep up with the latest developments to the HTML/DOM libraries, here’s where to go! The libraries in question are: dart:html, dart:svg, dart:web_audio, dart:web_gl, dart:indexed_db, dart:web_sql, and dart:chrome, but it’s possible there will be more. This is the group to follow to hear about changes to DOM bindings.

I recommend signing up for this group, as it is a medium volume way to stay up to date with anything changing in the main DOM libraries. If you build client applications, or just care about the modern web, stay tuned!

editor@dartlang.org : Dart Editor and Plugin Development and Discussion

If you use the Dart Editor to write Dart code, or debug Dart applications, or for any reason at all, this is the group for you. The Editor team loves, probably more than any other team, receiving feedback. This list is a great place to talk about what you want to see in the Editor, and discuss the state of the Dart IDE.

---

Other groups:

Just a reminder about the other groups we have:

misc@dartlang.org : Miscellaneous Discussion

vm-dev@dartlang.org : Dart VM Development

compiler-dev@dartlang.org : dart2js Development

web-ui@dartlang.org : Dart Web UI Package Discussion

The following groups are read-only, as their posts are auto-generated:

commits@dartlang.org : Commits to the Dart Repository

bugs@dartlang.org : Dart Issue Tracker Updates

reviews@dartlang.org : Dart Code Review Updates

---

And just to be clear, here are guidelines for posting to any of the groups:

Guidelines

• For HOWTO questions, consider asking on StackOverflow.
• If you can phrase your question as "how do I do X?" then StackOverflow is the place for you.
• For bug reports and feature requests, file a new issue at www.dartbug.com/new.
• For Web UI questions, see the web-ui@dartlang.org group, which has links and resources in its welcome message.
• If your question is about how to use the Web UI package, try StackOverflow first.
• For Dart Editor questions, use the editor@dartlang.org group.
• If you are reporting a bug or a crash, use the "SEND FEEDBACK" button in the Editor itself, or use www.dartbug.com/new.
• For questions about dart:html development, use the html-dev@dartlang.org group.
• For questions about VM development, use the vm-dev@dartlang.org group.
• For questions about dart2js development, use the compiler-dev@dartlang.org group.
• For all other discussions about code Dart development, use the dart-dev@dartlang.org group.
• For everything else that doesn’t fit any of the above, use the misc@dartlang.org group.

Campaign to use real logging (instead of print) in your libraries and apps

Summary of "Campaign to use real logging in Dart" (via tldr.io)

• Using print() statements for debugging in your libraries means that everyone gets your print() output.
• The Dart SDK has a "logging" package built in (that lets you write into a logging framework), but nothing to output those log messages.
• The "logging_handlers" package adds those missing handlers, letting you output to the console (like print), filesystem (server side), and a webui component.
• Now you (and I) can control the logging output from different libraries by varying the logging level different libraries.

Stop Using print(msg) start using info(msg)

When you use print(), other users of your code have to see all your internal debug logging (I know I'm guilty of this, too).

The logging_handlers package lets you use proper logging in your client-side or server side Dart application.

Why?

When I use your library (or when you use my library), I want to control the amount of logging output from your debug messages (and, I hope, you want to do the same for my debug messages). By using the Dart logging framework, we can both be happy.

There are two parts involved in logging:

1. Sending log messages into a logging framework
2. Outputting the log messages somewhere (eg, to the stdout, a file, the browser).

Dart's print() sort of covers both of these use cases, and the quick'n'dirty alternative described below also does the same thing. It's not the best way, but at least it means that log messages can be output somewhere other than the console (such as a file).

First, some background about logging

Dart's logging pub package, that forms part of the Dart SDK, covers use-case 1, in other words, it lets you send log messages into a logging framework.
This framework lets you attach handlers to that framework that can listen to the stream of log messages.

This package, logging_handlers provides some default handlers that lets you output messages to a variety of locations, in a variety of formats.

At the moment, you can output a log message as a tab delimited String or a JSONableMap, and you can output a log message to the console similar to print(), to a server-side file, or to a client-side web-ui component (or a mixture).

The quickest (and dirtiest) way to replace print()

This is not the best way, but it's certainly better than print().

1. Add logging_handlers package to pubspec.yaml
2. import 'package:logging_handlers/logging_handlers_shared.dart';
3. Use debug(msg), info(msg), warn(msg), error(msg) as appropriate.
4. Somewhere in your initialization code (start of your unit tests, main() or other initialization code), call startQuickLogging()

For example:

import 'package:logging_handlers/logging_handlers_shared.dart';

main() {
    startQuickLogging();
    info("Hello World");
}

will output to the console:

2013-05-06 16:42:42.593     [INFO]: Quick'n'Dirty logging is enabled.  It's better to do it properly, though.
2013-05-06 16:42:42.604     [INFO]: Hello World

Note: Dart's logging has more fine grained logging levels - the top-level functions above are shorthand for some of these:

             FINEST // highly detailed tracing
             FINER // fairly detailed tracing 
debug(msg) = FINE // tracing information
             CONFIG // static configuration messages
info(msg)  = INFO // informational messages
warn(msg)  = WARNING // potential problems
error(msg) = SEVERE // serious failures
             SHOUT // extra debugging loudness

But see below for better ways that allow users of your code more control over what actually gets output, and let you have finer-grained control over logging.

The a slightly better way (but still a bit quick'n'dirty) to replace print()

Let users of your code filter out your specific log messages by giving your log messages a name. The best name is the name of your library. for example:

library my_library; 
import 'package:logging_handlers/logging_handlers_shared.dart';

class Foo() {
  Foo() {
    debug("Foo is created", "my_library"); // calls debug with your library name
  }
}

main() {
  startQuickLogging();
  new Foo(); 
}

this outputs:

2013-05-06 16:42:42.593     [INFO]: Quick'n'Dirty logging is enabled.  It's better to do it properly, though.
2013-05-06 16:42:42.604 my_library      [FINE]: Foo is created

When you include your library name in your log messages, other users of your code can filter your log messages out (more on that later).

The best way to implement logging in your libraries

Create a Logger instance in your library, and give it the name of your library:

library my_library;
import 'package:logging_handlers/logging_handlers_shared.dart';

final _logger = new Logger("my_library");

class MyClass {
    MyClass() {
       _logger.fine("MyClass created");
    }

    foo() {
      _logger.error("Something bad has happened");
    }
}

You can have as many loggers as you need, and they can be hierarchical (using a . to separate). For example, you might have a top-level logger, and individual loggers for specific classes:

library my_library;
import 'package:logging_handlers/logging_handlers_shared.dart';

final _libraryLogger = new Logger("my_library"); // top level logger

class MyClass {

  // MyClass logger is a child of my_library logger
  static final _logger = new Logger("my_library.MyClass");

  MyClass() {
     MyClass._logger.fine("MyClass created"); // using class logger
  }

  foo() {
    _libraryLogger.error("Something bad has happened"); // using top-level logger
  }
}

When you use hierarchical logging, you (and your code's users) can start to take control over what actually gets output, and to where (such as outputting ALL logging for MyClass, but only WARNING, SEVERE and SHOUT logging for the library).

Now that you've seen how to emit log messages into a framework, let's take a look at how to control where those messages go

Controlling log message output

The code in your classes and libraries don't actually run until you pull them into a Dart application (or unit test) via the top-level main() function.

In the main() function, you need to initialize the logging framework with a logging handler. The simplest version of this is the PrintHandler, which outputs log messages to the console in the same way that print() does.

Let's assume that you've implemented logging using "the best way" which contains your logger name.

// the SDK logging framework
import 'package:logging/logging.dart'; 
// Handlers that are shared between client and server
import 'package:logging_handlers/logging_handlers_shared.dart'; 
// your library, from above...
import 'my_library';

main() {
  Logger.root.onRecord.listen(new PrintHandler()); // default PrintHandler
  var myclass = new MyClass(); // from above - outputs log message
}

If you're on the server-side, and you want to log to a file, the logging_handlers package includes a very simple (synchronous) filesystem log file handler: SyncFileLoggingHandler.

// the SDK logging framework
import 'package:logging/logging.dart'; 
// Handlers that run server-side
import 'package:logging_handlers/server_logging_handlers.dart'; 
// your library, from above...
import 'my_library';

main() {
  Logger.root.onRecord.listen(new SyncFileLoggingHandler("myLogFile.txt")); 
  var myclass = new MyClass(); // from above - outputs log message
}

And if you're on the client side, there's a handy (and incredibly basic) web component<x-loggerui> to output log messages on screen.

In your Web UI enabled application, your HTML will look something like this:

<html>
  <head>
    <!-- import the loggerui component -->
    <link rel="import" href="package:logging_handlers/src/client/loggerui.html">
  </head>

  <body>   
    <!-- other content... -->

    <x-loggerui></x-loggerui>  <!-- Logger widget -->

    <!-- standard app scripts -->
    <script type="application/dart" src="test.dart"></script>
    <script src="packages/browser/dart.js"></script>
  </body>
</html>

And in your app's main() function, you call attachXLoggerUi() like this:

import 'package:logging_handlers/browser_logging_handlers.dart';

main() {
  attachXLoggerUi(); // lives in the browser_logging_handlers library
}

The attachXLoggerUi function runs in the next event loop iteration after main (usingTimer.run), so any startup logging won't appear. This is because the web component's themselves aren't available until the next event loop.

Here is a running example:

Attaching multiple handlers

Sometimes, you want to attach multiple handlers. That's fine, because the logging framework uses Streams, so you just need to use asBroadcastStream():

main() {
  var loggerStream = Logger.root.onRecord.asBroadcastStream();
  // attach the PrintHandler and the File logging handler
  loggerStream.listen(new PrintHandler()); 
  loggerStream.listen(new SyncFileLoggingHandler("myLogFile.txt"));       
}

Note At present, the implementations of the client and server handlers are fairly basic, but given time (and your help?), they should get greater functionality. Ideas include: Allowing the x-loggerui to filter based on level.
or creating an async version of the server side logger.

Getting more control over the output

Now you have seen what can be output, let's take a look at how you customize that.

Each of the handlers (LoggerUi, SyncFileLoggingHandler and PrintHandler) implement aBaseLoggingHandler interface. These have a LogRecordTransformer instance, that transforms an SDK LogRecord into some other format.

The logging_handlers package contains two transformers that implementLogRecordTransformer: StringTransformer and MapTransformer. All three handlers use a default implementation of a StringTransformer, but you can pass an alternative transformer into the constructor of both the PrintHandler or SyncFileLoggingHandler.

StringTransformer

The StringTransformer lets you control the fields that get output, for example:

main() {
  var fileHandler = 
      new SyncFileLoggingHandler("logfile.txt", transformer: new StringTransformer("%m"));
  Logger.root.onRecord.listen(fileHandler); // default 
  var myclass = new MyClass(); // from above - outputs log message
}

The StringTransformer allows formatting strings to specify the output. %m is just the message without all the other information, and replicates the print command.

The full list of formatting strings is shown below:

%p = Outputs LogRecord.level
%m = Outputs LogRecord.message
%n = Outputs the Logger.name
%t = Outputs the timestamp according to the Date Time Format specified
%s = Outputs the logger sequence 
%x = Outputs the exception
%e = Outputs the exception message

The default formatting strings are shown below (with \t for tab separation):

DEFAULT_MESSAGE_FORMAT = "%t\t%n\t[%p]:\t%m";
DEFAULT_EXCEPTION_FORMAT = "\n%e\n%x";
DEFAULT_DATE_TIME_FORMAT = "yyyy.mm.dd HH:mm:ss.SSS Z";

You can customize all of these when you create a logger handler.

Replacing the print() command

Now that you have seen some of the formatting available, let's see how you can actually replace the print() command:

main() {
  // simulate existing print command by only outputting the message
  Logger.root.onRecord.listen(new PrintHandler(messageFormat:"%m")); 
}

Taking control: Logging levels and heirarchical loggers

Let's suppose that you are using my library.

We have your_library and my_library

You don't want to see my logging when you test your library.
How can you control it?

Let's look at some code that outputs logging from your_library but not my_library:

import 'package:my_library/my_library.dart'; // don't want to see logging here
import 'your_library.dart';  // Show logging from this library please :)

import 'package:logging/logging.dart'; 
import 'package:logging_handlers/logging_handlers_shared.dart';

main() {
  hierarchicalLoggingEnabled = true; // set this to true - its part of Logging SDK

  // now control the logging.
  // Turn off all logging first
  Logger.root.level = Level.OFF;
  Logger.root.onRecord.listen(new PrintHandler());

  // create a logger for your library 
  // (there will be a single instance for each logger with the same name)
  // and set the level to ALL
  new Logger("your_library")..level = Level.ALL;

  doSomethingInYourLibrary(); // logging is output to console
  doSomethingInMyLibrary(); // logging is not be output      
}

Now let's use the hierarchy to use different logging for a specific class (assuming that you have a class logger created for your_library.YourClass):

main() {
  hierarchicalLoggingEnabled = true; // set this to true - its part of Logging SDK

  // now control the logging.
  // Turn off all logging first
  Logger.root.level = Level.OFF;
  Logger.root.onRecord.listen(new PrintHandler());

  // create a logger for your library 
  // (there is only a single instance for each logger with the same name)
  // and set the level to ALL
  new Logger("your_library")..level = Level.INFO;
  new Logger("your_library.YourClass")..level = Level.ALL;

  doSomethingInYourLibrary(); // Only INFO logging is output to console
  new YourClass(); // All logging output to the console
  doSomethingInMyLibrary(); // logging is not be output      
}

Quick Reference

Logging best practice

1. Add logging and logging_handlers to pubspec
2. Import the logging SDK where you want to write log messages
   import 'package:logging/logging.dart';
3. Create a logger (or loggers), and use them
   ``` final _libraryLogger = new Logger("my_library");
   doSomething() { _libraryLogger.info("Something is done") }
   class MyClass { final _classLogger = new Logger("my_library.MyClass")
   MyClass() { _classLogger.fine("MyClass is constructed"); } } ```
4. When you use your library / class, and want to output some logging, create an instance of a LoggingHandler and attach it to the root logger
   ``` import 'package:logging_handlers/logging_handlers_shared.dart'; import 'your_library';
   main() { Logger.root.onRecord.listen(new PrintHandler()); } ```
5. When you want finer control over what get's output, use hierarchical loggin and set levels
   ``` import 'package:logging_handlers/logging_handlers_shared.dart'; import 'your_library'; import 'package:my_library/my_library.dart';
   main() { Logger.root.onRecord.listen(new PrintHandler()); Logger.root.level = Level.OFF; // log nothing by default new Logger("your_library")..level = Level.ALL; // log all in your library
   } ```

Server handlers are found here:

import 'package:logging_handlers/server_logging_handlers.dart';

Client logging handlers are found here:

import 'package:logging_handlers/browser_logging_handlers.dart';

Web UI component is here:

<link rel="import" href="package:logging_handlers/src/client/loggerui.html">
...
<x-loggerui></x-loggerui>

... 
// and in your script, call:
import 'package:logging/logging.dart'; 
import 'package:logging_handlers/browser_logging_handlers.dart';

main() {
  hierarchicalLoggingEnabled = true;
  attachXLoggerUi();
}

Caveats

The Logger framework (as at M4), has a TODO about logging exceptions. At the moment it doesn't. If you want to log exceptions, add the exception text to the log message.

If you find any problems or errors, then please let me know. This was current as at r21823