New Dart:io hotness!

It's been a very long time since my last post for which I apologize. I hope to get back into Dart blogging again soon. A recent announcement on the dartlang mailing list got me excited. BREAKING CHANGE: New version of dart:io. I've been waiting for this to finally land in bleeding_edge. As a lot of my work is with command line applications. It's great seeing dart:io finally getting some love.

Now there were a few surprises that cropped up with the new version of the library. I'm going to note a couple of them I've come across so far that I've noticed. I won't get into details about ones covered in the mailing list announcement. There are a number of others that were too small to be covered there. One big thing I noticed was the removal of HttpServer.addRequestHandler as that was a quick and dirty way of setting up the basics of routing in the server. Now all requests are sent to HttpServer.listen. Similarly, server isn't started by creating a new HttpServer instance and then running listen on it, rather use a static method, HttpServer.bind on the HttpServer class which returns a Future which provides the server instance.

All of this is because the dart:io is being converted to Futures and Streams. And it is a change for the best, making the libraries consistent across libraries and API's. This has also made for some changes to some of the other classes in dart:io and just some clean up which makes sense as well.

Lets start with our eventHandler. In the past adding a RequestHandler to the HttpServer would take two arguments. An HttpRequest and an HttpResponse. The first being the request to the server and the latter being the response back from the server to the client. However, I cannot think of a situation where these two objects would not be intertwined. Apparently the dart developers felt the same way. Now, the new version of a requestHandler (see above), only accepts an HttpRequest. The corresponding HttpResponse object is a property of the HttpRequest, and can be accessed like so: HttpResponse res = httpRequest.response;

Also in HttpRequest, the uri property is no longer a string but returns a URI object. As such, the path property of HttpRequest has been removed in favour of: httpRequest.uri.path. Similarly, session is no longer a method but rather returns a full session object directly. This means that it no longer accepts an init callback to preform a specialized initialization of the session but I'm not aware of that functionality being used very frequently.

[Edit:]
One aspect that I neglected to mention earlier is that writing to the HttpResponse stream is a little easier now as well. In the past we would need to use httpResponse.outputStream.write(...) whereas now, we write directly to the httpResponse itself. For example:

var res = httpRequest.response;
res.addString(...);
// Alternatively we can also use add(List data)
// or addStream(Stream> data).

Check out the API for HttpResponse.[/Edit]

As an experiment with the new library, in particular with the HttpServer and related functionality, I created a very basic webserver example. This sample is not production usable, or even complete in any way. But I think it does provide a good introduction into how the new libraries are used and how extend the Stream interfaces to implement a very basic routing mechanism into the server. The source is available on github: sample_server. This is the basic premise that I'm now implementing in a project that I'm working on at the moment. With any luck I'll be able to extend the functionality of the server and abstract it away from the core logic I'm working on to be able to release the library for others if they are interested. In the mean time the sample_server should help you to get up and running.

One thing I do have to mention, is it was extremely easy to implement my own stream with the route by extending Stream, and just using a StreamController to provide most of the functionality. Only needed to implement the listen() method which in itself passes it on to the controller anyways. Love it!

Note: Currently this requires a bleeding_edge version, as these changes have not yet been added to the stable build. They were written with version: 0.1.2_r18836 and tested with version: 0.1.2_r18968. Details may change prior to stable release.The latest stable version of the Dart SDK has just been released and supports this API. It can be found in version: 0.4.0_r18915.

Dart Koans

The next week or so, I'm going to be limited in the amount of time I will have for some programming. I will hopefully still get some programming in but I will be limited in how much time and frequency I will have for it. Because of that, and the fact that I'm a little impatient, I've decided to share some information on my current project.

The project is Dart Koans. It is inspired, though not based on, a ruby project of a similar name: Ruby Koans. I completed the Ruby Koans when I was first learning Ruby, having come from other similar languages like Python as well as from JavaScript. The Koans helped a lot because I learn really well from hands-on coding. Additionally, while covering the basics, it does dive right in.

I felt that a similar approach to learning Dart would be a great contribution to the community. There are many programmers coming in from other languages who are comfortable with the basic concepts and don't need some of the background or theory involved with traditional tutorials. They're familiar with what a variable is, and just want to know how they're used in Dart. They're itching to write some code in Dart to see how it feels.

The Dart Koans are for people new to Dart, and comfortable on the CLI (currently it's not recommended to run from the Dart editor, as it's blocked by a couple of bugs.
1) Issue 4654 (Dart Editor should handle ANSI color output).
or
2) Issue 2789 (Provide a way to find out if stdout is connected to a terminal).

The idea behind Dart Koans is that you achieve enlightenment through failure. You start with many failing tests. And individually correct each test and re-run the program. With each run of the application you should get closer and closer to resolving all tests. Each test introduces a new concept of the Dart language or libraries. At the moment it is still very very early and only a small portion of the total tests are completed. Currently there are 55 tests. By the time this is completed I expect well over 300 or more. As each test fails it will provide the error, line and file to look at to correct the issue. Each test (using the unittest library) is accompanied by several comments which will provide information about the concept being introduced.

Due to the early development stage, the tutorial is currently very much in the preview stage and far from its completed form. However I intend to add more tests and areas as much as I can. I'm interested in any feedback or comments or concerns but please keep in mind things are very much subject to change. Current output is primarily for demonstration purposes and is most likely not the final result.

Because I will be updating very frequently I will not be making many blog posts about the projecct unless its regarding a significant milestone or involves any major changes to the project.

Resort to sort

So the past few days I've been playing around with some simple algorithms. I'm not 'professionally' trained, and most of my experience has been with what I've seen in code or have implemented myself. Does that make me less of a developer for not being classically trained? Maybe, maybe not.

In particular I've been playing around with some of the sorting algorithms. Stuff like Bubble sort, Selection sort, Insertion sort, and of course Quicksort.

My first task as been to study the algorithm and look at whatever pseudo-code or explanation is presented for the algorithm. Study and understand it. Then is to walk away from any computer or anything, take a little break. After a short time I then pull out a pen and paper and write down a Dart version of the code. I write it out in front of me without referring to APIs, or without referencing the material.

I later then enter that code (or re-write it) into the Dart editor in a simple test file I have. I run it, fix my bugs, and run it again. My test file contains all of the various sorts as I learn them, it then prints out the sorted list and the time it took to complete (using a Stopwatch). I also have a function to create a list of X size filed with values from Random.nextInt.

Being able to easily create a random list of a determined size is nice, as it allows me to easily increment the list size as I choose and see the differences in performance. For instance it took a list of almost 5000 items for Quicksort with the two isolates to be faster than the main-thread version of Quicksort. (See Edit note below)

Many of the algorithms I've implemented are without performance improvements and are far from the most efficient versions available. One thing I've noticed though is List.sort((a, b) => a - b); has generally been one of the best performing algorithms, in lists of up to 10,000 items.

However as I mentioned none of the algorithms has been tuned for best performance or memory usage and are just the 'simple' versions of the algorithms just for my own learning purposes and less for actual performance comparisons. The performance comparisons are more of a visual reference to the Big O Notation for myself.

[Edit:]So I was wrong. I had poorly implemented my Quicksort with Isolates. Very poorly. It was a hodgepodge of Futures and a custom callback. I went through and cleaned it up and changed it so it returned a Future instead of calling a callback. Once I did that I saw an over 10x speed increase in the Quicksort with Isolates version and it and was about the same speed as the Main-threaded Quicksort for lists below 500 items. And faster for lists greater than 500 items. This has more to do with my unfamiliarity with Isolates than with the algorithms themselves.[/Edit]

For those who may be interested, you can the current version of the file here: https://github.com/butlermatt/sorting_dart. As time goes by, I will be adding more algorithms (with comments) as I learn them myself. Again please recall these are not optimized in any way and are only presented as-is, as proof of concept.
In time I may add some optimized versions of algorithms myself as I progress. Keep in mind however this is primarily a learning project and not designed for use. They may be (and are) buggy.

Contributed Contributions

So it has been quite some time since my last post. Today will be a relatively short one, but I think I'm going to try and get into the habit of writing a blog post now and then.

Today I wanted to mention a little about contributing back to Dart. This is something very easy for anyone to do, on a variety of different levels. First and foremost, I've been contributing in small ways in the past just by using Dart. And in particular by using Dart and filing bug reports when you run into something. Currently I have 15 bug reports that I have reported and are still open. And many more which have been fixed for a long time.

You can submit bug reports for not only code that isn't working correctly, but also for documentation which may need to be updated or corrected; for updates to the website; or even just style recommendations (particularly those which may apply to the Style Guide).

Bug reports are a great way to contribute as the more bugs that are found and squashed the more stable and attractive Dart becomes.

Eventually you may start feeling comfortable enough to provide solutions to the bugs you provide. Either pasting in a suggestion into the bug report, or by submitting a patch.

Note: I will mention this here ahead of time. Before Google can integrate any code you provide them, you must sign the Contributor License Agreement (CLA).

I have personally submitted patches to a number of areas of the Dart project. My first was to the dartlang.org website. I found a typo in the language tour. So I went to GitHub site. Found the Dartlang/dartlang.org repository and forked it. I made the edits that I saw needed to be corrected and issued a pull request.

One handy tip I received, was to use a rebase workflow when dealing with edits to the github repositories. After doing a bit of searching around, a very good article I found was A Git Workflow for Agile Teams. This shows a very straight forward method of using rebase to create nice clean commits when pushing upstream. I still refer to it when working on patch for the sites.

After submitting a couple of corrections to the dartlang.org site(s) I began to feel comfortable enough with submitting code to the dart source code. This process is significantly different than just forking a github repository. First instead of using github, its best to follow the steps here for getting the source. Make sure you can build before trying to edit any code.

Once you've verified you can build after getting the source code for the first time. You can go ahead and make your changes. After making your changes, make sure you once again build. Then also make sure you can pass the tests. If possible run as many tests as you can, not just specific to one area as you never know what else might rely on behaviour you didn't expect (I found this out the hard way myself).

If everything looks good with the test. Submit your patch. I'll give you a hint now as well. Once the patch is uploaded, it will display a chromium code review site. Similar to: https://chromiumcodereview.appspot.com/10918056/ Be sure to go to that site. Edit the issue and add a reviewer (if you're not sure who should review ask in either the bug report that you're working on or from the mailing list). Update the issue once you've added a reviewer. Then click on 'Publish+Mail Comments'. If you don't do this, no one will know that your patch is waiting for review!!! (Mine waited over a week because I didn't do this haha).

Once your patch is looked at, you will usually get a 'lgtm' (Looks good to me) and possibly some suggestions on small typos to fix. If you get line comments on things to fix, then fix them in your code, then re-upload a patch (using the same method as before). It will automatically associate it with your previous patch (as long as you're using the same git branch!). Then go to the comments in the source that were left for you, click on each. Then click on the 'Done' link. That will signal to the reviewer that you looked at each comment and addressed the issue. Once you've marked each comment as 'Done', then 'Publish+Mail Comments' again.

Usually by this point the reviewer will commit your patch for you into the source. They will usually link another patch ID, and on that patch ID will be a revision id such as https://code.google.com/p/dart/source/detail?r=12278. Once you have that you can also watch the buildbot progress for your patch to see if you end up breaking anything ;)

So that's a summary of how I have, and you can, contribute to Dart. Now get out there and enjoy it!

Abstraction? Encapsulation? Integration?

So, I'm having a bit of a design dilemma with one of my projects. I have a class that represents a switch (physical switch that is). It contains information about the switch such as system description, uptime, firmware versions, etc.
I want to have a list of these switches represented by a number of divs. When programming in PHP, I would make a for loop and just loop through the list of the switches pulling the data into a template-esque string which would be echoed out.
That method isn't very dart-y. I could do it that way but it doesn't feel like the dart way. I would also rather input into the dom and add event handlers more dynamically. However my current solution adds a 'DivElement' to the switch class. I can then template the innerHTML for the div, and add an onClick event handler right into the constructor. Then as my 'manager' class loads the switches it can then append them to the dom with insertAdjacentElement('beforeend', aSwitch.element); to the correct spot.
I like this method for the most part as it allows me to provide the default display information directly in each object. But my problem is that having done at least a little ruby on rails (and other ruby mvc framework programming) I know having my model and my view coupled together like this is a big no no.
But for the small project I have I'm not sure if I really need to worry about adhering too strictly to that methodology.
So I'm at conflict with myself.

Long Overdue

Okay wow..... Uhm.. yeah. What can I say? I've been extremely lax in keeping content on here. For a period of time I got pulled into other projects. However recently I was able to work on a project which I was able to use dart, and not just my usual server side work, or internal server but something that would be customer facing. Albeit something very minimal and not actually 'interactive' for the customers who would see it. But still it was a great chance for me to make use of dart and it was nice doing something publicly visible. However due to the nature of it I was unable to share the code for it.

I've also pushed out the source to DartMud as I've not worked on that in some time. I may be able to get some more commenting and eventually some additional work on it, however at the time being it will probably be pretty stagnant for the next little while at least. If you're interested you can check out my git repository.

There have been many many chances to the dart editor, dart vm, et al. that I have no real possibility of listing them all here now. However work is progressing rapidly in all areas and the integrated build is seeing updates almost weekly. It's very exciting to see the changes and additions being added so frequently. And so far only the rare 'breaking change' has come through which requires significant updating to any code. One such change was an update to the way callbacks are assigned on sockets. But it was a minor effort to update DartMud to reflect those changes.

At the moment, my current tests have me playing with the webserving capabilities of Dart. I have just recently begun to play with writing my own server. For those looking to get into it a little faster however, there are a couple of nice projects already in place including an Apache mod_dart, to run dart server side scripts as you would run a PHP script right inside of Apache. Additionally there is Dart Start, which is a (Ruby) Sinatra inspired dart server. In particular Start allows for simple routing and parameter passing as popularized by Ruby On Rails. So by all means check them out! In the mean time I'll continue playing with my server and let you know as things progress.

Darting here and there

So another Dart Editor update, now at Build 5104, get it here!. I love how quickly the dart integrated builds have been coming lately. This new version does away with the old 'Libraries' view panel on the left side (by default) and instead implements a Files view. Instead of opening a project you now open the folder containing your project. All of your .dart files are loaded into that. I wasn't sure about it at first, as it is a changes in how it would work previously but already I'm seeing the benefits of it. It does help to encourage a Good folder/subfolder layout, which I was already comfortable with anyways.

I've seen a few people report some difficulties loading their existing projects, however I can't really comment on that as I have not encountered those issues myself. This version did correct the mass of errors I was receiving in the previous version regarding variables hiding other variables or methods. However it did introduce a couple of new ones.

First, this version introduced the changes to the dart:io library, changing all eventHandlers over to be in the form of onEvent, and one-shot methods (such as File.exists) now take the callback function as an argument, as opposed to having to specify an 'existsHandler'. As such I had to go through my code and made updates to the Sockets and Files to properly reflect the changes to the library.

Secondly, I ran into an issue where any print statements, within a class, would generate an error or warning that "print" is not a method in , where ClassName is whatever class happened to contain the print statement. This post in the Dart Group provided an easy, temporary fix, that is to simply import 'dart:builtin' where required. A simple fix and helped to clean up the errors there so I could focus on my own errors that I had to worry about.

I notice that while the IDE and SDK were updated to Build 5104, the Dartium Build remains at 5070. At this time I am still unable to get the Dartium builds to run on my machine due to a version problem with the shared libraries. I receive the following error:

error while loading shared libraries: libgconf-2.so.4: wrong ELF class: ELFCLASS64

I believe this error is related to the fact that I'm running a 64-bit OS, but it's trying to load 32-bit build. This may also have something to do with my early ventures in trying to build DartVM, IDE, and Dartium myself and installing the extra libraries, etc, which may have conflicted with what Dartium is trying to load. In fact, now that I think of it, I should run a good apt-get autoclean and autoremove regardless. I don't believe it will fix it, but certainly clean up my system a little at least. Now I've not been too worried about this as my current project doesn't use or require any client-side work, but eventually it might be interesting to have a working copy of Dartium for when I start working on some client side projects. Hopefully the 64-Bit builds of Dartium will be available by then.