I'm now officially into the third week of my internship at Novell. Tis interesting stuff. I've managed to put faces to a lot of names and learning a lot of interesting things! Since i've gotten here, i've been working a bit on moonlight. I wasn't quite part of the hack-a-thon as i have zero knowledge of C++, but i did get the fun job of excerising the API and pointing bugs over and over until people went insane ;)

As you may or may not know, it's Hack Week at Novell. What this means is that every novell employee gets to work on whatever project they want for this week.

While my appointed task for the summer is a Silverlight Designer, i'm also doing that for hackweek as it's great fun! The idea is to end up with a visual designer for silverlight which can run from a WinForms GUI, a GTK# GUI or just from your browser! At the moment i'm implementing it with GTK# as it makes my life easy, but sticking a new frontend (i.e. web based frontend) should be relatively simple.

So, you might be wondering what the designer can do at the moment. The short answer: nothing useful. The long answer: lots of stuff!

At the moment you can draw any of the basic shapes: Squares, Rectangles, Ellipses, Circles, Lines and Pencil. There's support for undo/redo. There's support for converting your amazing drawing into XAML (there will soon be support for allowing you to hand edit the xaml and load those changes back into the drawing surface).

So all in all, nothing useful, but it still does a lot ;)

Miguel was nice enough to upload my screencast to youtube which demonstrates the amazing awesomeness of the designer! By the end of the summer i'd hope to be able to record animations in the designer so you can easily create that stunning animation to incorporate into your website/desktop application/whatever.




In other news, MonoTorrent has gone through an extensive bug-fixing phase which fixed a lot of those annoying bugs which i'd never managed to track down before. The incentive to keep me hunting for these elusive bugs was due to Andy Henderson. Thanks a lot for all those charts, graphs, explanations and reports andy! I couldn't have done it without you.

Here's a partial list of recent changes/fixes:
* Allocating less byte[], but making them larger. This results in less objects being pinned, less heap fragmentation and (hopefully) slightly better performance
* Fixed crash when trying to parse UDP trackers
* Fixed bug where threads wouldn't stop correctly when calling Dispose on the engine
* Incoming encrypted connections being received correctly - thank you azureus for hiding this from me
* Individual files now containing their % completion
* Fixed potential threading issue in encryption code
* Rewrote the public API
* Fix to make sure that both global and per-torrent connection limits are obeyed
* Fixed typo in ratelimiting which meant i was getting slightly less stable rate limiting than i should be
* Starting a torrent manager which has not been hashed and doesn't have fast resume data now works correctly.
* Added option to enable/disable have message suppression - Recommended value is to Disable have supression.
* Fixed several critical issues in piece picking code
---- Reduced CPU usage hugely
---- Reduced memory usage noticeably in certain scenarios
---- Rarest first algorithm now chooses rarest pieces as opposed to most common pieces (doh!)
---- Rarest first algorithm falls back to trying to choose less rare pieces if all the rarest pieces are already downloading
* Now handling older clients which request 32kB pieces correctly.
* Correctly dropping incoming connections when the TorrentManager is not running
* All download/upload speeds and amounts are given in kB/sec and kB respectively
* Fixed bug where large single-file torrents wouldn't load correctly - multi-file torrents were unaffected
* MessageTransferred event firing for incoming messages.
* Updated the PeerID code to make it *much* easier to use
* Fixed bug where an array out of bounds exception would be thrown when trying to request the last piece of a torrent whose number of pieces was an exact multiple of 32 (that was a fun one to debug ;) )

So these changes basically mean you have a *much* faster, more stable, better monotorrent! I have a few more ideas on reducing memory usage and CPU usage which shouldn't take too much effort to implement. I just have to find the time ;)