Tech Blogs

The video quality is a little bit bad, but is the best I can do with my phone. I’m waiting for some OpenMoko community videos

I’ve been pretty swamped these past few weeks helping to care for our newborn son, who arrived on August 8, 2008. That’s 08/08/08 for the numerophiles out there! We’re pretty excited by him, but we’re also experiencing the typical exhaustion that comes along with a new baby.

Finally got around to recording another episode of Core Intuition, which is now live and ready for download. In this episode we talk a bit about promotion and how small developers such as ourselves should approach it, and also rap about a few other issues such as how I’m being drawn toward the “baby oriented software” market.

Give it a listen, hope you enjoy!

The following screenshots shows Visual Studio debugging a remote Mono process running on a Linux box.

Breakpoints, current line, and stack traces.

The setup works like this: you run a debugging server on Linux. On Windows you install a Visual Studio extension that provides a Debugging Engine and the configuration tools to start your application.

Then you start your application from Visual Studio (Tools/Launch with Mono) which will send the binaries and debug information over to Linux and execute it.

Showing the disassembled code generated by Mono's JIT

The core of the above work is to get the Windows to Linux debugging functionality enabled. We will have more news when the debugging experience is more complete and we are approaching the time to test drive it.

If you are interested in trying it out, sign up for our preview on our web site. Debugging Support

Mono 2.0 will for the first time include a debugger, the command line mdb command.

Beyond this, we want to offer GUI debugging. The native solution is being built on top of MonoDevelop and will be available when we release MonoDevelop 2.0. It will work on both Linux and MacOS hosts.

The second GUI engine will be the above Visual Studio plugin for developers that use Windows as their main OS and Visual Studio as their IDE. More Visual Studio Integration

In addition to this work to integrate Visual Studio with Mono for remote debugging, thanks to the Summer of Code (Ed Ropple) and Jonathan Pobst's work in this hack week we got some support to run applications on Mono/Windows and run our Mono Migration Analysis tool.

Jonathan's work is available today as an MSI, check out his post for more details.

You can also check Ed's summer of code report on CloverLeaf.

Here some news from the Smuxi front. As you might already know Smuxi 0.6.2 was released. With the 0.6.2 release we have now German translation and Smuxi packages in Debian (Unstable) (as promised), Ubuntu (intrepid) and ArchLinux (AUR)! Now just OpenSUSE, Foresight Linux, Gentoo and Fedora are missing for world domination^W^Wconvering the major Linux distributions.

The upcoming 0.6.3 release will contain Spanish (thanks to Juan Miguel Carrero), French (thanks to Clement BOURGEOIS) and British English (thanks to Ryan Smith-Evans) translations. Besides bugfixes this release will contain the famous tray icon support and some other goodies! The release should be ready by this weekend... stay tuned.

There has been a wonderful Google Summer of Code for me, and for Openmoko Inc. I still remember the ‘Congratulations!’ email received from Google that announced me that Openmoko selected me for the accelerometer-based gestures project (out of the 13 people that applied for this project).

It seems like I’ve passed the final term evaluation, otherwise I couldn’t have uploaded my code to http://code.google.com/p/google-summer-of-code-2008-openmoko/; follow this link to see, and download what the other nine students created for Openmoko’s Neo Freerunner. That means I’ve been a successful participant…

Regarding the accelerometer-based gestures project, I’ll continue working on it whenever I’ll have some free time; on that matter, I’ve bought two domain names, namely accelsense.org, and accelsense.com dedicated to my work. Don’t bother clicking on the links, there’s nothing there yet, but I’m hoping it will be ready by the end of October.

Thanks to my mentor, Daniel Willmann, and to the entire Openmoko community for helping me.

Have fun! There’s going to be an in depth look of Neo Freerunner’s accelerometers post really soon!

Barcelona is holding the Mozilla Camp 2008 Europe during the 25th and 26th of October 2008. The event will be hosted at Citilab building. The meeting targets development, quality assurance and localization contributor's around the Mozilla projects. The organizers are expecting around 150 participants.I will be definitely attending to the localization sessions.

More information at William's weblog.

Last week was my second Hack Week at Novell. Massi and I had been intending to hack on a demo for embedding Mono in games, but realised that the overhead of bootstrapping a stable working environment would most likely frustrate our efforts to get something within the week.

Instead, I decided to package some game libraries for Mono on the openSUSE Build Service. I planned to package Axiom, OpenTK and OGRE.NET, and write some MonoDevelop templates for them, but got rather tied up in the details of packaging OGRE.NET and its unmanaged dependencies (I now know far more about packaging SONAMEd libraries than I wanted to!). As a result, I only completed the packaging for OGRE.NET, though I will get around to packaging the others sometime.

You can now install my OGRE.NET and OGRE packages for OpenSUSE 11, reference OgreDotNet and Math3D from MonoDevelop, and start writing code without having to worry about unmanaged libraries, etc.:

Massi did an alternate Mono game embedding demo, and investigated how we could optimise SWIG (or some other binding generator such as DoxyBind) to generate better Mono bindings for C++ code.

read more

Hack week fun with Mono on games!

This hack week I wanted to demo the use of Mono to program the logic of a game.
This is an area where Mono can be really useful, and we want to increase its adoption even more (we also had a booth at the GDC last year), so a good technical demo can be useful.

First of all I had to select a game to work on. There were a few prerequisites I had:

• The game has to be freely redistributable, so that anybody can see the demo without needing to buy the game. So, being Free Software and multiplatform are good things in this sense.
• It must be a "real world" example, not just a toy, ideally a real commercial game: we'd like to show that Mono is useful in these kinds of projects.
• Doing the work must be feasible in one week, or anyway doable with reasonable effort: it is a demo I want to do, not spend one year working on a game.
• Comparing Mono to a different mainstream game scripting engine in the same context would also be nice.

As you can see, many prerequisites conflict with each other. One way to reconcile the "real world" thing and the "redistributable" one would be to choose commercial games that have been released as Free Software, like many ID Software ones.
In this sense, any of the Quake 3 derivatives would be really nice. They also are conceived for being "modded", so doing some extension in C# is definitely doable. Unfortunately, the amount of work required to do (or port) a game mod to C# is (IMHO) too much. They tend to weight in at 100k lines of code, which is a bit too much for the demo I had in mind. Also the AI of a single bot (fighter) can easily exceed 20k lines of code, and what's worse is that there's no clear interface for that in the game, so drawing the line between Mono and the rest of the engine would be an additional work.

In the end I selected the TORCS racing simulator.
It is not a commercial game, but its level of realism is adequate for the demo: the drivers must take into account all sort of parameters to race effectively, including basic aerodynamics, ground effect, spoiler angles, tire friction and temperature, engine response, fuel load...
Moreover, there is a clear API to write the AI of drivers as plugins in separated loadable modules.

So, this is what I did: I took the TORCS driver API, wrote a SWIG interface file for it, and used it to produce a C# wrapper. I then selected the best of the TORCS drivers, which seemed to be one of the "berniew" ones by Bernhard Wymann, with the intention to port it to C#. However, it was "too good", with 2700 real lines of fairly complex c++ code (reported by sloccount), so I selected the "next good" driver seeing how well the others raced against berniew. It seemed to me that "inferno" (apparently an evolution of "tanhoj") was a very good one, so I decided to port that: with only 800 lines of code it raced almost as well as berniew.

The porting was easy, and now I have a working TORCS driver implemented in C#.
I then sow a subtle error, similar to a difference of precision in the calculations (but likely just a porting bug), which causes stupid driving mistakes in the bot, I'm going to debug that soon.

The next planned steps were to reimplement the same driver in Lua, and benchmark that comparing it with the C# and C++ implementations, measuring both execution time and memory usage, and also to comment on the "implementation experience" (C# vs Lua).

However, in the process I found out that SWIG, as a tool for interfacing C# with native code, does the job but has serious deficiencies.
One is that it does not work with arrays (at least the version I have, 1.3.35).
Another one is that it produces lots of native code, and invokes it practically for everything, so even a simple field access becomes a call to a native C function (which involves a managed-umnanaged transition and all). I really believe that a wrapper generator tailored specifically for the .NET world could use the CIL much more effectively (the SWIG C# backend is almost a copy of the Java one...).
Finally, SWIG encourages the use of "interface files" distinct from the native C header files of the API it is working on. While this is understandable, I think a more direct approach would be more practical.

My impression is that the Windows crowd does not feel the pain because when they need to interoperate with native code they have managed c++. At first I just dismissed it as a "language abomination", something taking the already complex C++ and adding all sort of quirks and different ways of doing things on top of it. But now, thinking better, it is the perfect tool to interoperate managed and unmanaged code, and in the free software world we lack something with that power.

I am not advocating that we implement managed C++ right away... I'm only saying that we are still using primitive tools to do this kind of job, and quite often we just say that "doing wrappers by hand is the best approach, anyway it's easy", because none of the tools we have is good enough.

But this (and the rest of my activity on TORCS, and Mono inside games) could be the subject of my next blog post :-)

…but we knew that anyway. Not a lot to say here, aside from offering a link to C.J. Adams-Collier’s blog. These guys, they are nuts. I don’t much like Linux Hater’s term “freetard,” but boy, is it a tempting one…

But don’t take my word for it. The folks on their IRC channel have put it pretty plainly themselves. They’re not interested in offering solutions to problems, they instead seem interested in bemoaning their lot in life for fun and profit. — Log opened Wed Sep 03 23:06:26 2008 23:06 -!- Irssi: #boycottnovell: Total of [...]

Cool new features "Generation of OO based LDTP code" and "Generation of * in window title" by Shreyank Gupta. Both the features were implemented in LDTP Editor code base. Thanks for his contribution.

Other interesting things to share about this release:
* Ubuntu QA team has adopted LDTP as their testing tool. Thanks to Ara and his team members, supporting LDTP, with good number of bug reports and feature suggestions :)
* VMware Workstation and Player automation are done using LDTP ! Thanks to Shang Wang, Gaurav Sharma, Ranjith Murugan for their contributions
* From IBM, Germany, Philipp Wagner has filed couple of intersting bugs, which were very critical. With his reports, he was able to automate Thunderbird, Gantt chart using LDTP.

Thanks to Kartik Mistry for updating the Debian packages, Ara Pulido and his team for updating Ubuntu packages, Navtej Singh for updating Gentoo packages.

You can download binary / source code from here

Supported binaries: RHEL5.x - CentOS 5.x - Ubuntu 7.04/7.10/8.04 - OpenSuSE 10.2/10.3/11.0/Factory - SLE10 - Fedora 8/9 - Madriva 2007/2008 - Debian Etch. Credit goes to OpenSuSE build service team !!!

I spent the day today using Google Chrome as my browser and I have to say I'm very impressed with it. I like the UI and its so fast! I've always heard that web kit was fast but never tried it so maybe its web kit that should get the credit since Chrome is based on web  kit.

When I first tried mojoPortal this morning using Chrome, the FCKeditor wasn't enabled and it was degrading to a plain text area. This turned out to be just a configuration issue in .NET code I had FCKeditor disabled for Safari. FCKeditor has claimed support for Safari for a while now but when I tested it after their initial support announcement it didn't work for me so I disabled it in mojoPortal. Then I kind of forgot about it for a while since I don't use Safari on a regular basis. Its been several upgrades of FCKeditor since I had tested so I tried enableing it again and it worked fine both in Safari and in Chrome.

So then with more poking around testing things in mojoPortal I found a couple of other things that didn't work like my friendly url suggest feature. It turned out that this was easily fixed by upgrading to the new version of Sarissa. Sarissa is a javascript library I use in a few features in mojoPortal and I had not upgraded it in a long time.

My fixes for these things will be in the mojoPortal svn trunk sometime later tonight and I'll be making a new release soon.

I feel a little worried for Mozilla and Firefox. I've been using Firefox for a long time as my main browser but I have to admit Chrome is very appealing and I may not go back to Firefox as my main browser. Of course I'll continue testing in all the major browsers. Some people are complaining that we now have one more browser to test but so far the rendering of mojoPortal has seemed really good so I'm not too concerned about that. I subscribe to the GAWDS (Guild of Accessible Web Designers) mailing list and there was a lot of talk in the last 2 days about accessibility problems with Chrome particulary for assistive technology like screen readers, but word is there will be improvement on that, after all its just a beta. 

I'm sure they will be adding more polish to Chrome, but I would say this beta is a great start. The EULA gives me pause and I hope they change that based on feedback but I give them kudos for the first release. My only other concern is whether use of Chrome is making any more information about me available to google than if I use another browser. If using Chrome meeans sacrificing more privacy than other browsers it won't become my main browser. I also hope that since Silverlight works in Safari, it will also work in Chrome.

I made this post in my blog using Chrome.

Joe Audette  ...

How many lines to host a torrent server?

Any ideas?

Guess!

Check it out yourself

Earlier I thought I'd be clever and use the pretty GNOME System Monitor to, I don't know, monitor some CPU usage. I should have known better.

Hopefully this can be addressed.... Until then, I'm going back to top.

If you are developing a project in MonoDevelop and your solutions/projects are in the old MonoDevelop 1.0 format (mds/mdp files), you'll probably want to convert them at some point to the new VisualStudio 2005/2008 formats that will be the default format in upcoming versions of MonoDevelop (2.0).

They are well supported in at least MonoDevelop trunk right now, and switching your MonoDevelop 1.0 project layout to VisualStudio's layout means you can more easily develop on both Linux and Windows. This is a good thing for us working on Banshee (hint, hint).

MonoDevelop makes the conversion part fairly straight forward. Select your top level solution, right click it, and then Tools->Export. Select either VisualStudio 2005 or 2008. We're sticking with 2005 for now in Banshee since we only care about C# 2.0 at the moment. Choose an export directory, it'll be temporary.

Unfortunately, it gets a little hairy here, and I wish MonoDevelop had some sort of "convert in place" option (hint, hint, MD team). Open a terminal, change to the directory MonoDevelop exported the project hierarchy to, and run this:

PRJ_DIR=$HOME/svn/banshee; for x in $(find . -iregex '.*cs?proj$' \ -o -name '*.sln'); do cp $x $PRJ_DIR/$(dirname $x); done;

Set PRJ_DIR to the directory of your project containing the project or solution file you originally exported.

This will ensure the new VisualStudio project/solution files are overlayed properly. Now you'll have to add them to your version control and remove the old mdp/mds files.

$ find . -iregex .*.cs?proj$ -o -iregex .*.sln$ | xargs svn add $ find . -iregex .*.mds$ -o -iregex .*.mdp$ | xargs svn delete

Hurray for having both runtime and build time environments cross platform! We're looking forward to having contributors from both camps in the near future. More on this to come!

Update: Lluis points out that MD can in fact convert in place if you set the output directory to be the original directory. This seems too obvious :-).

So, after ~3 months of hacking while travelling up the east coast of Austrlia, what exactly have I managed to accomplish in this years SoC? Well, quite a lot :) Here's a list of new stuff and upcoming stuff in no real order:


DHTDHT support is available in SVN. It's pretty much complete, but lacks some real world testing. There are currently about 35 NUnit tests covering all important modules in the code. I need to give this a week or two of solid testing and then I'll be enabling it by default. A few updates will need to be applied to MonoTorrent so that the 'private' flag will be obeyed now that we have DHT support. IP Address BanningAwesome support for this has been added to SVN using a combination of my own code and code written by The Great Bocky. It uses an extremely efficient way of storing IP Address ranges so that they can be represented by two integers plus a little overhead. There is a parser which supports all the main ban lists and users can parse other formats manually and add the addresses in that way. Extended Messaging Protocol Support for the LibTorrent extension protocol is complete. This allows custom messages to be sendable to remote peers over the standard bittorrent protocol. So if you require the ability to send arbitrary data to a remote peer and have them react in a special way, you can! Http Seeding (Web Seeding)Support for the getright style Http Seeding is complete. This (better) specification allows a standard HTTP server act as a seed with no special software required. If MonoTorrent decides that there aren't enough peers available in the swarm to allow the torrent to complete, it will automatically start downloading the necessary chunks from the server. Peer ExchangeSupport for this has been completed by Olivier Dufour. This pretty cool idea allows peers you are connected to to send you details about other peers which are active in the swarm. This way you gain information about more peers even if the tracker goes offline. MiscFaster SHA1Due to both an algorithm change and architecture changes, hashing performance has nearly doubled. This means that hashing a file takes less than 1/2 the time it used to *and* that CPU usage while downloading is reduced. Better EncryptionThere was a bug in header-only encryption that prevented it from working correctly before. As MonoTorrent always defaulted to Full Encryption, this wasn't such a huge issue before. Along with this bugfix, encryption is now more performant than before - using less CPU and less memory. The code also shrunk considerably in size and is much more maintainable than before. Deadlock FreeIt's now impossible to deadlock the library. This isn't so important for the end-user, but for anyone programming with MonoTorrent it's great news. If you are extending the library to add extra functionality internally, it's now easy to ensure that you do everything in a thread-safe and non-deadlocking manner. Abort long connection attemptsSometimes an operating system might wait an incredibly long time before aborting a connection attempt. This meant that if MonoTorrent tried to connect to a peer that was no longer available, sometimes the OS would take up to 150 seconds to abort the attempt. Worst case scenario is that the first 5 peers you connect to all take 150 seconds to abort and it looks like MonoTorrent is doing nothing. Now MonoTorrent hard-aborts a connection attempt if it takes more than 10 seconds. Streaming torrents ahoy!Two guys Karthik Kailish and David Sanghera have created a new way to download a torrent with MonoTorrent. Generally speaking, the rarest piece of a torrent is downloaded first, then the second rarest and so on. This new code allows you to specify a range of bytes which is High, Medium or Low priority. Then, from within these ranges the rarest first algorithm is active. For example if you are a video player and you want to start playback from byte 1000, you can tell MonoTorrent that the range from 1000 -> 5000 is important so those bytes are downloaded first, which allows you to start playback as soon as enough of that high-priority data has arrived. Unit TestsThe number of tests covering MonoTorrent has doubled over the summer, from 55 up to 111. Every test makes the liklehood of accidently introducing a bug less and less. I like tests ;) Banshee PluginFinally, while not quite related to MonoTorrent itself - A plugin for banshee has been created which allows the downloading of torrent based podcasts. It's still a work in progress, but hopefully that can be cleaned up and completed pretty soon. So with all these changes and features, i'm hoping to push out the next release of MonoTorrent by the end of september. This release is unlikely to include DHT, but I hope to have a second release shortly afterwards which will include DHT. Anyway, I'm off to pack my bags now so I'm ready to head to Ha Long City at 7am in the morning. I'm enjoying my last week in Viet Nam at the moment. It's been a blast, though sometimes i wonder if they deliberately decide to not understand what I say just because I'm mispronouncing it slightly. 'Ho Chi Minh' isn't *that* hard to understand, is it?

So I don’t rave about hardware often, but I’ve had this x300 thinkpad for about a month now. I would like to mention how awesome it is to have working suspend in Linux that is damn near flawless. Oh, 802.11n, gig-e, usb2, 4 hours battery with lightweight 6 cell, dvd-rw, solid state disk, [...]

As part of this year's Google Summer of Code, there were two projects that got chosen that were on my personal 'to-do' list. I was happy these projects got chosen because frankly, my to-do list is not getting shorter nor are the days getting longer.

One of these is Ed Ropple's "Cloverleaf", which is an add-in to Visual Studio designed to facilitate writing and testing applications in Mono. We decided on the following features:

- Test in Mono: Clicking this would run the current solution/project on the Mono runtime on Windows.
- Scan with MoMA/Gendarme: Clicking this would run MoMA or Gendarme (which can run MoMA) on the solution/project.
- Test on Linux: Clicking this would take the solution/project output and copy it to a Linux machine or virtual machine, and automatically start it.

Ed did some great work over the summer, so for my Hack Week project I started polishing and packaging his code so we could get it into people's hands. Unfortunately, I only got "Test in Mono" done. I already use this a lot, but I think "Test on Linux" will be the one most helpful to me.

Currently, these tools are implemented as external tools, which will allow them to run in all versions of Visual Studio 2005 and 2008. In the future, we will also be making an add-in to provide additional functionality for people with the Professional editions of Visual Studio (the Express versions cannot run add-ins).

Running the project normally with the .Net runtime:


External tool options in the Tools menu:


Application launched running on Mono:


I created a .msi installer that will install the code and add the tools to the Visual Studio menu. Note that it does not remove them from the menu on uninstall yet, you will have to do that manually from the Tools->External Tools dialog. Feel free to test it out and let me know if it doesn't work for you, since it only got tested on my machine. Hopefully this will be the start of top-notch support for Mono in Visual Studio! :)

Download Install File

Prerequisites:
- Visual Studio 2005 or 2008.
- Mono for Windows installed.

Last week was the third edition of Novell's Hack Week. During the week I used Ohloh to describe all the changes I made to Gendarme, almost in real-time. Still a quick recap can be easier to read...

Framework Enhancements

• New Severity.Audit for rules that will always trigger but are still useful from time to time (see new rules);
• New IRule and IRunner TearDown methods were added to allow late reporting (of defects) and any specific rule clean up;
• New filtering options for defects (see runners) to get shorter, more accurate, reports;
• New [FxCopCompatibility] attribute to help map between Gendarme and FxCop rules. This will allow us to support the .NET framework [SuppressMessage] attribute.
• New "engines" support. Engines are building additional data, on top of what Cecil provides, for the rules to consume. The runners ensure of the engine data availability before any rules that requires them start their analysis (i.e. the Check* methods). This part is not yet committed (but should be soon) and will be a moving target until 2.2 is released. Expect a few blog entries on them (there are two engines right now) later this month.

Runners Enhancements

• The console runner has been updated to expose the new framework features, like:
  • --limit=N can be used to limit the number of defects reported during analysis;
  • --severity=... can be used to filter only some severity level (e.g. ignoring audits);
  • --confidence=... can be used to filter results more likely to be false positives.
• A new step has been added to the wizard runner to set some options before the analysis.
  • Limit the number of defects reported;
  • Set a minimum severity level on defects;
  • Set a minimum confidence level on defects;
  • Select visibility, which allow rules to work only on visible, non-visible or all your code.

Rules

• Quite a lot of moving, renaming and a few optimizations. Expect a bit more of this before 2.2 gets released. New assemblies were created for Code Access Security rules (Gendarme.Rules.Security.Cas) and for generic related rules (Gendarme.Rules.Design.Generic).
• New ReviewSuppressUnmanagedCodeSecurityUsageRule to show the new Audit severity. This is a good example about something that can't be fixed (for once and for all) but where it's useful, from time to time, to know where they hide.
• New UseGenericEventHandlerRule to promote the use of EventHandler<TEventArgs> over the creation of delegates.

Except for some rules fixes and optimizations that were backported (to 2.0) all this new stuff will be released with Gendarme 2.2 (i.e. with Mono 2.2, not 2.0). More news soon!

For Novell Hack week, instead of hacking on exert as I did in the past, I chose to spend some time on a MonoDevelop Gtk designer restructuring project I've been considering: one widget per design file.

The current designer architecture is based on project-level design files, saved in a special hidden directory along with generated source files needed to compile the designs. This design decision builds upon the existing stetic project-based file format. It complicates several common operations, however, some of which have open bug reports.

One problem is the ability to either copy or move widgets between projects. Another, is the ability to add existing widgets to new projects as "external files" so that a single design can be reused by multiple projects. When the design of the widget is saved as a child element of a project-level xml document, all of the above operations are considerably more complicated than if the widget design is contained in a standalone file.

I'm implementing this redesign as a new addin in MonoDevelop, so that I won't have to pay as much attention to feature parity with the existing designer. The hope is that at some point we can just switch the default designer to the new addin, once it reaches maturity. Based on the amount of work remaining, this will clearly be post-2.0.

Thus far, I've ported the existing addin extension code and begun the rework of the stetic WidgetDesigner. Currently supported features include:

• SolutionPad display bindings and extensions
• Grouping of related source, design, and codebehind files.
• A CodeDom based project template to create Application projects in mulitple languages.
• Project Compilation extensions to generate codebehind files, capable of compiling template projects.
• CodeDom templates for ActionGroups, Dialogs, Widgets, and Windows.
• Toolbox provider and loader.
  
• WidgetEditor built on existing stetic wrappers and class descriptions, currently view-only.

Here's a screenshot of a template project in C#. The template also compiles already in VB.net.



Once I get the widget editor working, I'll probably go ahead and check in the addin for people to play around with. No current estimates on when that might be other than, "when it's ready."