Yes, you read it right, Npgsql wasn't using connection pool when running under Mono!!

The problem seemed to be that Npgsql was using one key to get a connection to pool and another one to return it back.
The issue is that although it is wrong, those two values were supposed to be the same.
You can see here and here bug reports about it.

As a .NET developer, you should avoid using the newly released Managed Extensibility Framework as its license prevents its use beyond the Windows platform. This will prevent your .NET software from running on Linux or MacOS in the future.

Luckily, there is a cross platform solution available today that has no platform limitations: Mono.Addins, a technology inspired by Eclipse's own plugin system. We have tutorials, reference manuals, API docs, our FAQ our public groups and multiple large applications with source code available that you can learn from (MonoDevelop, Banshee, F-Spot and Gnome-Do).

The rule obviously applies to any new APIs that are built for .NET as they are not immediately available for Mono. But unlike the binary-only APIs, these half-open source code releases pose additional problems for the open source CLI:

• More people are exposed to the source code, preventing them from working on a fully open source implementation of it.
• There is a smaller desire from the community to reimplement the code, as it is relatively easy to just use the existing implementation or ignore the issue for the time being.
• Some folks might not care about the license restriction, and ignore it altogether. A practice I do not endorse.

There are two additional issues that are worth pointing out. Should non-open source libraries be hosted on CodePlex to begin with? CodePlex is branded as the "Open Source Project Hosting" from Microsoft, yet, this license is clearly not open source and does not qualify as open source according to the definition and is a clear violation of Codeplex.Com's requirements:

The above link points to http://en.wikipedia.org/wiki/Open_source_licenses.

MEF should be pulled out of the CodePlex site along with all other platform-limiting software, like ASP.NET MVC (h/t to gblock for pointing out that MVC is also violating the terms). Unless CodePlex cooks up a special exception that some software and restrictions are more equal than others.

The second point that is worth making is that picking licenses like the MS-LPL for .NET software is shooting the .NET community in the foot. The LPL license is obviously an effort to tie things into the Windows platform, putting company first, community and developers second.

The MS-LPL is a poisonous license, do not use it (do not confuse with the MS-PL which is a decent license, the extra "L" makes a big difference).

Update: gblock points out that CodePlex technically only requires a "license" to be picked, but does not require it to be OSI compliant. But even if the wording on the FAQ does allow for that interpretation, it is misleading as there is a link to OSI licenses next to it, and the main page clearly states that Codeplex is an "Open Source Project Hosting" site. Capital "O" and capital "S".

The "CodePlex Basics: Getting Started" page also points to the Open Source License Definition, there are no words about custom licenses or about hosting proprietary code with source code available.

I'm going to give a brief summary of what I've done in the past weeks (and specially previous week (last one in August), sponsored by Novell as The Hackweek - a form of ITO, in which you can hack at working hours and not only spare time!

I was not so lucky as most of my teammates, who spent the week on the wonderful offices (as they say) of Novell Utah. Maybe if I was in the states already... but well, I had recently an interview in the US Embassy which was the last step of my visa process, so I hope that at least I can make it for the Gnome Boston Summit!

So, firstly I thought of dedicating my week to this task that I submitted to the ideas website, but in the end realized it would be a ton of work to complete without help, and nobody joined me so I decided to learn to use OpenSuseBuildService in order to package Bugzilla, a pretty complex server side software.

Fortunately, I've learnt a lot this week, especially thanks to all the people in irc://irc.freenode.net/#openSUSE-buildservice (above all, darix) and some people from my team (Ray Wang and Stephen Shaw). I could also contact the author of the RPM file for Fedora (who was formerly working for Red Hat), and he's willing to help on joining efforts, as OBS is cross-distribution.

Unfortunately, packaging is a complex task and I didn't finish the package. The documentation is a bit incomplete and having past experience in packaging is a plus that I didn't have. It's awesome that inside our UIA Team we have exclusive resources dedicate to this, because it would be impossible to do from just the developer side.

One of the difficulties I found is finding packages I needed. I could find some of them (BTW, using Webpin is cool for searching on SUSE software repositories, including Packman; except for the fact that doesn't enhance one-click-install) but not all so then I'll have to help on providing packages for some CPAN Perl modules, contributing to the devel:languages:perl official repo.

On the way of learning OBS, I also filed bugs and feature requests (not only to OBS, but also to Banshee! as I have been using it a lot lately at the same time I hack and I even cooked some small patches):

OBS:
Usability issues in project creation page
Link to "My projects" fails if no home:login project has been created yet
New option for uploading the tarball
ChangeLogs parsing is too strict: lines beginning with tab are not recognized, only one date format is accepted
OBS should not allow to create a package named "packageand"
The spec parser should detect the use of a miscplaced packageand(_:_) keyword

Banshee:
No such file or directory errors while importing
Cannot empty some ID3 tag fields
Importing songs without album metadata breaks artist navigation on the iPod
Banshee inserts deduced fictional text on metadata
Should try to locate correct album (and download its cover) in case no album is supplied on metadata


The patches are quite simple so I hope they get committed soon! Clearly Banshee devs and contributors are doing an amazing work, I'm specially amazed by the Moonlight effects, the Muinshee front-end and the effort that it seems is being dedicated to bring Library Sync & Refresh for 1.4. I wish them all the best success.

So let's get back to packaging. Firstly I thought I had found some limitations in OBS or rpm systems because the lack of proper "dual dependency" support. In the past when I installed Bugzilla manually (and updated it to newer versions) I found it a bit hard to do it, specially to deal with DB creation and upgrade. I wanted to make this process easier for the potential rpm user, but without limiting the choice of the DB engine used (as now Bugzilla supports MySQL, PostgreSQL, and Oracle, although the latter was not on my scope). It turns out that it's really hard to apply virtual-provides rules for these cases, as we should stablish more sub-dependencies depending on the db engine you choose, such as perl-DBD-mysql or perl-DBD-Pg, and because it would cause inconsistent situations in case someone in the future replaces his DB-engine with the alternative one (as in theory it should work at the dependencies-level without warning). For references, you may be interested in reading the whole thread about it in the BuildService mailing-list, whose last message includes a possible hack to workaround these problems using patterns (although I don't like to use patterns for solving something like this).

Even discarding the dream about solving this at a package level, it's difficult to solve it at an app level that wouldn't involve reading manuals. My idea was to modify Bugzilla upstream in order to avoid running manually a local script for its initialization, and replace it with a nice web front-end (even if it's only allowed to be run locally). That would cause problems because normally the webserver user doesn't have enough permissions to create files and the database tables and initial data (I'm sure there's always a solution that also doesn't expose security problems, but it's hard to find it as it's noticed in this thread in bugzilla devel newsgroup; so, help is truly welcome).

Maybe the easier and fastest solution is a mixture of both worlds, that is, having a web front-end that asks you the initial configuration, and the form submission process just writes it in a local XML and tells the admin to open a console and run a script as root to finish the process. But even with this solution I guess we should need something to detect at runtime (which should be cross distribution) if some package is installed (which also checks the version). I guess there's already some of that capabilities used in the bugzilla's script checksetup.pl, so I would reuse them. However, in case it finds a problem, there's no way for the application to request installation of a package directly to your OS (but I've attended to a PackageKit conference in last Guadec in which I heard something about this possibility in the future!).

Life is pretty hectic these days with the start of a new school semester and the assorted things like seeing back friends, integrating the new students and resuming work in student clubs. As a result the ParallelFx SVN log has been pretty silent (which worried some people). In fact code for MCas and STM is coming along nicely, though not ready for their prime, which is why I keep it in my local branches for the moment. Free hacking time should gradually returns as life settles back to normal. Also, I'm going to update soon the test packages with the latest bits as part of providing code samples to Google.

So Mono 2.0 RC1 was tagged this week and, like I did before, I ran my benchmark on Gendarme (results on preview #1, preview #2). No big surprise this time. Since the performance difference is less than 0.5% wrt preview #2 it didn't seem wise to disturb some many electrons for an updated table. So let's create a new one to answer "But just how much time does it take ?".

We already know how much time it takes for Mono, but a lot of people work on smaller projects (or subset of large projects). This new table shows how much time Gendarme needs to analyze (using all rules, including smells) some Mono-based OSS projects that I have installed, from repositories*, on my openSUSE11 laptop.

Projects	assemblies (#)	Time (seconds)
banshee (1.2)	14	6.50963
beagle	20	10.84114
f-spot	21	743.364386**
giver	1	1.137288
gnome-do	3	1.500372
monodoc	12	1.909368
monsoon	4	6.459559
tasque	2	1.898578
tomboy	4	3.549324

So next time you have a few seconds give Gendarme a try on your own projects ;-)

* caveat: no debugging symbols - either because most projects dont ship them, or because mono 2.0 MDB format is newer (and incompatible) with the one shipped in openSUSE 11 (mono 1.9.1).

** including 734 seconds inside the quite big Tao.OpenGl.dll. Since I don't suppose f-spot developer's make many changes inside it, I guess it could be removed from the analysis.

With the release of the WebKit-based Chrome browser, Google also introduced a handful of new backends for the browser engine including a new HTTP stack and the Skia graphics library. Google’s Android WebKit code drops have previously featured Skia for rendering, though this is the first time the sources have been made freely available. The [...]

Since my girlfriend wants to learn English and I'll probably have to attend a meeting in Boston, we decided to put it all together and we are planning to stay a couple of months in Boston, from end October to end December. After 5 years working alone at home, it will be refreshing to work in an office together with non-virtual coworkers. It also comes at a good timing because we are planning to release MonoDevelop 2.0 around the end of the year.

This is going to be an interesting end of year.

BTW, I'm currently looking for a small apartment (or big room) to rent, ideally around Cambridge. Unfortunately I'm not having much success, since apartments I found are either too expensive, or not available for those two months. So if you know about some good place, information will he highly appreciated! (mail lluis at novell dot com).

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.

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 :-)

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:

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."

Huge Thanks! to everyone that nominated us.

mojoPortal is a finalist again in the Best Other CMS category in this years CMS Awards sponsored by Packt Publishing ("other" means not based on PHP).

Last year we won this category but we were the only project based on ASP.NET in the group of contenders. This year there are 2 other .NET projects in the finalists including the dominant and much better known DotNetNuke project. I think last year this award was not really on their radar, but since Packt published a book on DotNetNuke skinning I'm sure their project team is paying attention this year. If they rally their community they will trounce us in terms of votes. DotNetNuke is also a finalist in the Best Overall category and to some extent that indicates they have already beat us.

To the extent that the award is based on current popularity it seems not very likely that we can win this year, though we did beat out Plone last year and they are also much better known than mojoPortal. Our best hope is to do as much as we can to get a lot of votes and to do well in the phase of the contest where we will be evaluated by a panel of judges.

So you may ask why is DotNetNuke so well known and so dominant? The answer is they had a 2 year head start and they got a lot of help and continue to get a lot of help from Microsoft. They have their forum integrated into the hugely popular Microsoft ASP.NET site which I'm sure drives a huge amount of traffic to their site and has been very helpful for them in building their brand. Microsoft has also recognized many of their core developers with MVP awards.

I certainly don't begrudge them their success or the support they get from Microsoft. I just want people to consider that popularity doesn't neccessarily mean you have a better product. You can have a better product and still fail to get your message out there, especially if you can't get access to the same valuable promotional mechanisms and support that your competitors have available to them. I hope one day to emulate their success and am glad we made it to the finalist stage again this year. One irony may turn out to be that if DotNetNuke brings a lot of attention to this years award, it may actually help us because some of the people who go to vote for them may read about the other finalists and this may help raise awareness of mojoPortal in the .NET community.

mojoPortal has grown its community organically in spite of not having any love from Microsoft (though we wish we would get some support from them). When I inquired about getting a mojoPortal forum on the ASP.NET site I pretty much got the brush off. Its very difficult for .NET developers to find out about mojoPortal and though we have a growing and supportive community, only a small percent of the huge ASP.NET community has ever even heard of mojoPortal.

I said it last year, and I'll say it again this year, we are the underdog going into this competition. Its going to be very difficult to win and every vote will matter so please vote for us and help us spread the word about mojoPortal!

If you like you can also nominate me for the CMS MVP Award.

Joe Audette  ...

At the beginning, Cecil was written to be an assembly manipulation library. The initial goal was to be able to read assemblies without loading them in an AppDomain, and also, to expose more that what .net 1.1 provided.

I implemented the writing parts of Cecil during my first Summer of Code, and barely touched it after, at it turns out it was working.

But this summer, two great hackers, Jeroen, author or IKVM, and Rolf, our VB 8 compiler author, decided that they gave enough blood and sweat to work around System.Reflection.Emit issues, and prototyped a version of their project based on Cecil instead.

If Rolf decided to go the full Cecil way, and replaced the usage of System.Reflection and System.Reflection.Emit (his branch is available), Jeroen decided to write a layer on top of Cecil that mimics the System.Reflection.Emit API.

Both wrote a sum-up about their findings, here for Jeroen, and there for Rolf. And both came to the conclusion that Cecil performs a lot less well that System.Reflection.Emit, both in terms of speed and memory consumption.

Rolf also uses the delay loading branch of Cecil, created by Mainsoft for their CIL to Java bytecode translator.

So the point is that Cecil uses too much memory, and is not fast enough in those scenarios, while it performs better in the reading only or reading + manipulating.

The good news is that, thanks to those hackers, we have now two amazing test cases to work on and to optimize. I’ve also started a few weeks ago, as a night hack, a refactoring of Cecil, that removes the intermediate structures that the current version of Cecil uses to read and write assemblies. If that makes reading and writing a little bit more complicated, it should also save a lot of memory.

And who knows, maybe one day, when Cecil will be optimized properly, and that the SRE on top of Cecil layer will be sufficient, it will require only a couple of changes to base mcs on Cecil.

Anyway, kudos to those hackers, let see what I can do to catch up.

We’ll let you know!

To blob or not to blob... good question!

I guess if you develop data intensive applications dealing with large files at some point, you've thought about it at least once: should I put my data files inside the database or should I write them directly to disk?

There are a number of interesting links to consider:

Use FILESTREAM to store blobs in SQL Server 2008

Storing blobs in database vs filesystem

Storing BLOBs in database or filesystem?

Should I store images in the database or the filesystem?

Just google it and you'll get a big number of entries.

Ok, so here's my point:

storing files in Firebird is faster than writing the same files on the filesystem!

Which is pretty good for all the structured storage true believers, I think.

Ok, let's take a look at the figures, here's my program which is able to recursively take the files in a directory, split them in 4Mb chunks and write them to another directory or a firebird database.

For my test I used a tree with:

3659 files

468 directories

343 Mb in total

And here's the output, first writing to Firebird and then to a filesystem.

>writedir d:\testcode d:\repodata fb
Total time 27669 ms

>writedir d:\testcode d:\repodata
Total time 40378 ms

A hash is calculated for each file chunk which also takes some time.

What I believe is pretty interesting is how writing to a Firebird database (which stores small files saving disk space since it only uses one single file!) is actually faster than dumping the same content to disk!!

Of course, there are a number of situations where high-perf software (including SCM) can benefit from using a FS instead of a database, but blob storage (with Firebird :-P) is not one of them...

You can find the full source code here.


Enjoy!

Side notes

I'm using Firebird embedded on windows

Don't try with SQL Server... it can't handle blob storage at the same speed... at least not without the latest 2008 improvements

at 8/30/2008 5:10:06 PM poupou said... Technically Hack Week 3 is over - but the weekend is not (and it's a long weekend in Canada, like the US). So here's a new rule for Gendarme: UseGenericEventHandlerRule. This will help populate the new Gendarme.Rules.Design.Generic assembly :-)

---

at 8/29/2008 7:51:24 PM poupou said... While engine-ing some Gendarme rule I simply could not resist and took some time to remove allocations from AvoidUnnecessarySpecializationRule. That cut another 2.5MB of memory to analyze all Mono 2.0 class libraries. Other smaller fixes were also backported to the 2.0 branch.

---

at 8/29/2008 2:18:55 PM poupou said... Started on the second engine today. It's larger than the first, so it's not yet complete, but I already modified a rule to use it. Sadly performance analysis will be complex until more rules use the engines to share the overhead cost. Anyway I did not intend to publish benchmarks against Gendarme 2.0 until 2.2 beta are out ;-)

---

at 8/28/2008 12:11:58 PM poupou said... I made some modification to the Gendarme engine-concept after a chat with nestor and @mhutch last night. The dependency between a rule and engines is now described using attributes. It looks much better this way and it also opens the door to other, longer term, stuff. I'm still playing with some ideas (i.e. not in SVN yet) but some stuff, like the OpCodeBitmask, has been committed this morning.

---

at 8/27/2008 10:48:06 PM poupou said... A bit of dog-fooding tonight made me realize (thanks to cedricv AvoidUnnecessarySpecializationRule) that Gendarme duplicated the HasAttribute rock way too much time (4) instead of a single implementation extending ICustomAttributeProvider.

---

at 8/27/2008 4:39:15 PM poupou said... I got my first engine running this morning. Pretty happy - but still it's a bunch of new code so I need some time to figure out if it's the "best" way to handle them (or not). While pondering the issue I took the afternoon to update the Gendarme wizard with a new step, offering similar filtering options now available in the console runner.

---

at 8/26/2008 6:02:30 PM poupou said... I was not planning on touching Gendarme 2.0 branch this week but I could not resist a few optimization candidates I found during hacking more "serious" stuff in the framework. The nicest, to date, is to avoid computing CC inside AvoidComplexMethodsRule if the number of IL instructions is below it's success threshold (default 25). Since most methods are small this should make it a lot quicker :-)

---

at 8/26/2008 9:25:50 AM poupou said... New filtering options are now available in Gendarme. First a "defect limit" will limit the number of defects reported (e.g. 100). More filtering can be done based on the severity and confidence level of each defects. In fact the console runner, by default, now report only defects with a severity of medium (or higher), i.e. no low or audit, and a confidence of normal (or higher), no low again.

---

at 8/25/2008 6:03:37 PM poupou said... Added TearDown methods to both IRule and IRunner inside the Gendarme framework. Default implementations in abstract Rule and Runner exists so every existing rule/runner will compile fine. This will let new rules delay until then end of the analysis to report defects. This is useful in some special cases, e.g. where a rule needs to walk across types, or even assemblies, itself.

---

at 8/25/2008 4:05:31 PM poupou said... Speaking of the "new" Gendarme.Rules.Security.Cas a lot (7) of the "old" security rules have been moved there too, many renamed to be easier to figure out what to do with them. This move will make it cleaner to start adding Moonlight specific rules in the future (not this week, but foundation are coming in).

---

at 8/25/2008 2:58:24 PM poupou said... Added Severity.Audit to allow (at last) another type of rules. This type of rules was not very attractive in the past because Gendarme lacked ways to ignore them. Well no more, ignore files has been available since Mono 1.9 (Gendarme 0.5) and new options are coming in :-) First rule to use Audit is ReviewSuppressUnmanagedCodeSecurityUsageRule (inside the new Gendarme.Rules.Security.Cas.dll)

---

at 8/25/2008 2:09:46 PM poupou said... Novell Hack Week 3 is started! This morning I added a new [FxCopCompatibility] attribute to the Gendarme framework. This will make it easier to ignore 'known' defects, like when [SuppressMessage] attributes are used inside analyzed applications.

---

Read older news...

Here we have gbrainy 1.00, almost three months after the previous version.

gbrainy is a brain teaser game and trainer to have fun and to keep your brain trained. It provides the following types of games:

• Logic puzzles. Games designed to challenge your reasoning and thinking skills.
• Mental calculation. Games based on arithmetical operations designed to prove your mental calculation skills.
• Memory trainers. Games designed to challenge your short term memory.

What is new in version 1.0 from the NEWS file:

    Version 1.00
    * 1 new logic puzzle, 1 new memory puzzle
    * Better look and feel (new background)
    * Switch font drawing to Pango
    * Better I18N support
    * Bug fixes

gbrainy 1.00 is available for download in source code from:

* http://www.softcatala.org/~jmas/gbrainy/gbrainy-1.00.tar.gz
      (md5sum adff790db643e846cb15c6142f2411ae)

and additional for your favorite Linux distribution and Windows at the project's page.

How can you help gbrainy?

This is a common question that I get. Let me point out some areas where you can help:

• Play the game and provide feedback about the application.
• Translation to different languages. Check the current status of gbrainy translations.
• Any development aid, including fixes or new Puzzles for the current system (see the development section).
• Ideas for new logic puzzles, memory or calculation trainers.

If you like gbrainy, blog about it and tell your friends!.

Help also digging gbrainy 1.0!

Lots of cleanup and restructuring. Removed most .NET reflection (almost everything is now based on DynamicMethod) and improved support for running in partial trust.

Changes since previous development snapshot:

• Switched almost all code to using generic collections.
• Removed our own tracking of LocalBuilders, because on .NET 2.0 LocalBuilder has a LocalIndex property.
• Added multi target support to ikvmc (although it is currently disabled, because of a showstopper .NET Ref.Emit bug).
• Replaced usage of BootstrapClassLoader with actual class loader in static compiler.
• Moved generated exception mapping code from ExceptionHelper to Throwable and made it slightly less hacky.
• Replaced mapxml Hashtable with three statically typed Dictionaries.
• Eleminated some (CompilerClassLoader) downcasts by making the type of the DynamicTypeWrapper.classLoader field depend on whether we're compiling the runtime or ikvmc.
• Removed unused per-type class caching.
• Added helper methods to no longer require reflection to instantiate DirectByteBuffer from JNI.
• Bug fix: dynamic (for unloadable classes) getfield/getstatic/invoke* bytecode compilation couldn't handle ghost types.
• Changed dynamic (for unloadable classes) bytecode handling to use Java reflection.
• Changed JNI reflection to be based on Java reflection (where possible).
• Removed "slow" reflection.
• Removed MethodWrapper.Invoke().
• Removed FieldWrapper.GetValue()/SetValue().
• Added ICustomInvoke for the few MethodWrappers that still require custom reflection invocation.
• Removed class init workaround that is no longer required since .NET 2.0 SP1.
• Removed GNU Classpath specific code that I missed.
• Switched from obsolete ConfigurationSettings.AppSettings to new ConfigurationManager.AppSettings.
• Fixed VFS root directory entry.
• Removed no longer needed VM.isBooted() check (VM.isBooted() always returns true now on IKVM).
• Forked java/nio/Bits.java to remove unsafe code from static initializer.
• Moved all creations of DynamicMethod to util method that uniformly handles the fallback to the new .NET 2.0 SP1 constructor that support partial trust.

WARNING: THIS IS A DEVELOPMENT SNAPSHOT, NOT AN OFFICIAL RELEASE.

Development snapshots are intended for evaluating and keeping track of where the project is going, not for production usage. The binaries have not been extensively tested and are not strong named.

This version supports .NET 2.0 SP1 and Mono 2.0.

Binaries available here: ikvmbin-0.37.3166.zip

During this summer, I've been working hard on Galaxium messenger, not only big and fancy features but also a lot of bug squashing.

The upcoming 0.8 release will contain all these goodies, so let's recap ...

• IRC Support:
  IRC will be one of several protocols that will be supported by default in Galaxium 0.8. The others are MSN, XMPP (Jabber), Aim and basic GaduGadu support
  
  
• Fast file transfers:
  If supported by the protocol, Galaxium 0.8 will be able to transfer files directly. By using Mono.Nat Galaxium is able to automatically map ports on your router and negotiate file transfers even when you are behind a router.
  
  
• Gnome integration:
  For now, only the simplest form of integration is available, namely automatic detection of GNOME proxy settings.
  
  
• Now playing:
  MSN Messenger on Windows added this feature years ago and Pidgin only supports it with additional plugins. Galaxium now supports it by default (Amarok, Audacious, BMPx, Banshee, Exaile and Rhythmbox). Other players can be supported by writing simple add-ons.
  
  
• Hello world add-on:
  One of our goals is to open up the development to other people. All information required to develop add-ons will be added to http://code.google.com/p/galaxium/wiki/Development
  Because our documentation effort has only started recently, it's mostly on a per-request base. If you want to develop a specific add-on, drop us a mail or ask us on IRC, we will gladly write a tutorial to point you (and others) to the right direction.
  
  
• Packaging:
  One of the things that turned up really great imho, are our precompiled packages. The list of supported distributions will certainly grow in the future, but the popular ones already have easy to follow instructions that you can find here.
  
  
• Audio / video conversations:
  One of my goals of this summer was MSN audio/video support, but since Paul (one of the other main developers of Galaxium) started working on this in June/July, I had to find another goal to fill the last couple of weeks, so I switched to libjingle (Jabber/XMPP audio conversations). Since I had no prior experience with Jabber, it involved a lot of research. Both of the protocol itself and of libjingle. The fruits of my research will be available on the SVN server late September, and hopefully stable enough to be included in 0.8

The next thing on my list is to enjoy myself for the rest of my vacation, so I'm well rested and ready to start working on our endless list of feature requests in a couple of weeks :)

The 2008 Utah Open Source Conference was amazing.  It was quite literally too legitimate to quitimate.  Last year was great but everything this year was double that.  Twice as professional, twice as engaging, twice as many high profile keynote speakers, and more than twice the attendance (an undisclosed number >= 500). Paul Frields, Fedora Project Leader [...]

It’s been another exciting and worth while Hack Week.  Sadly I had a number of high priority Mono updates to push to SuSE so I probably spent only about half of Monday through Wednesday hacking.  Thursday through Saturday were spent at the Utah Open Source Conference (more on that soon).  The real highlight for me [...]

For our hack week here at Novell I continued hacking on making vbnc work with Cecil, and yesterday I reached the point where vbnc is able to compile itself using only Cecil (in my previous post I also said vbnc was able to bootstrap, but back then vbnc was still using SRE to do all the hard work, and Cecil just to write the final assembly to disk).

The initial performance problems are mostly gone, it's still not quite as fast as before, but there are also quite a few low-hanging fruit yet in that area. The first successful bootstrap yesterday took 40 seconds (compared to 12 seconds for the normal vbnc), and after a few optimizations I'm now down at 24 seconds. Almost all of that time was gained by allocating less strings, the first non-optimized version allocated ~1.4 GB of strings, and it's now down to 119 MB.

I'm also using a delay-loading mechanism to load data from referenced assemblies on-demand, this is not that visible when you compile a lot of code in one go, but it sure make a difference when compiling thousands of 15-20 line tests one by one.

I'm pretty confident I can get compilation time down to the 12 seconds I had before, especially given that Cecil hasn't been much optimized [1] (not actually used by compilers) before, while Mono's SRE implementation is known to be quite fast.

As a sidenote the actual amount of code in the compiler has decreased, from ~75k lines with the normal vbnc to ~68k for the cecil version.

[1] Sébastien Pouliot corrected me, cecil is used by some know compilers, and probably some unknown too. Some parts of Cecil has also been optimized already.

I have just realized that Mono supports a reduced set of locales compared to Unix systems.

Mono uses a set of hardcoded locales in the runtime to provide the .Net framework locale support. Mono reads the user's locale and sets the default framework locale to the corresponding internal Mono locale. The problem is that the locales supported officially by .Net and by the Mono runtime and are smaller set compared to the ones that Unix systems support (actually Mono supports less locales that Microsoft .Net runtime).

For example, languages like Occitan, Bosnian or Breton have no locale in Mono. Neither combinations of supported languages in other regions, for example Catalan language in Andorra (ca_AD), that is actually the official language there. The list of non-supported locales is long compared to any standard Unix system.

In Unix machines, Mono applications run under these not supported locales are not respectfully with the user's locale. I noticed this because some users were complaining that gbrainy did not show the numbers properly formatted for their locales. The issue affects actually all Mono applications.

For example, if you run Banshee, F-Spot or Tomboy under a non supported locale they always show the dates and numbers formated for the invariant locale instead of using the user locale. As example, Occitan (French) and Catalan (Andorra) locales use European date formatting but you get the American date formatting. Same for number formatting. This really breaks the locale support at application level for many users.

I have filled up bug report (#420468) in the Mono's project bug tracking system. Meanwhile, I have put together a patch for gbrainy that reads the user's locale information and sets it in the default locale when user's locale has not been identified by Mono. As result, the number formatting is now shown properly. If you can think of a more elegant fix, please let me know.

Since Npgsql RC1, we started to receive some error reports about problems when closing connections. The typical stack trace looked like this:

System.NotSupportedException : This stream does not support seek operations.

at System.Net.Sockets.NetworkStream.Seek(Int64 offset, SeekOrigin origin)

at System.IO.BufferedStream.FlushRead()
at System.IO.BufferedStream.WriteByte(Byte value)
−
at Npgsql.NpgsqlQuery.WriteToStream(Stream outputStream) in C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlQuery.cs:line 62
−
at Npgsql.NpgsqlReadyState.QueryEnum(NpgsqlConnector context, NpgsqlCommand command) in
C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlReadyState.cs:line 64
−
at Npgsql.NpgsqlConnector.ReleasePlansPortals() in C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlConnector.cs:line 373
−
at Npgsql.NpgsqlConnectorPool.UngetPooledConnector(NpgsqlConnection Connection, NpgsqlConnector Connector)
in C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line 541
−
at Npgsql.NpgsqlConnectorPool.ReleasePooledConnector(NpgsqlConnection Connection, NpgsqlConnector Connector) in
C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlConnectorPool.cs:line 284
−
at Npgsql.NpgsqlConnection.Close() in C:\Npgsql\Npgsql2\src\Npgsql\NpgsqlConnection.cs:line 584
−

Aaron has been complaining lately that writing fancy graphics hacks for Banshee by hand using low-level Cairo calls is too "hard" and too tiresome to do.

Wimp.

For Hack Week, this week, I've been fixing up the GtkSharp Moonlight widget (aka GtkSilver) to work again so that The Great Bocky can write fancy graphics hacks using XAML instead.

One area that Aaron has mentioned that he'd love to do fancier animations in is the "Now Playing" view which currently is limited to a fade-in and a fade-out of the current track info (album cover w/ a reflection), track title, artist, and album name.

It took him far too long to write the code that displays that view (+ time spent optimizing it to get better than 11 FPS) and if he ever gets around to implementing anything fancier, he'll be popping those Excedrin pills like candy.

Lucky for him, I mocked up a slightly improved version of his "Now Playing" view in XAML (no code required except to update the text, album art, and to invoke the animations). All animations and graphics are represented in just 70 lines of XAML.

The great thing about designing this view in XAML is that it is easy to change the layout or adjust the animations without having to write any new code. Users can customize their "Now Playing" screens in any way they want to, all they have to do is keep the names of the controls and animations consistent with what the application expects. It's a lot like Glade XML files, only it allows the user to do fancy things like animations as well.

The demo I hacked up uses the following XAML:

<Canvas xmlns="http://schemas.microsoft.com/client/2007"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Background="Black" Width="700" Height="550">
  <Canvas x:Name="Display">
    <TextBlock Canvas.Left="10" Canvas.Top="200" x:Name="TrackInfo" Width="280"
               FontFamily="Sans" FontSize="14" TextAlignment="Right" Foreground="White">
      <Run x:Name="Title" FontSize="24">Wonderboy</Run><LineBreak/>
      <Run x:Name="By" FontSize="12" Foreground="Gray">by</Run>
      <Run x:Name="Artist">Tenacious D</Run><LineBreak/>
      <Run x:Name="From" FontSize="12" Foreground="Gray">from</Run>
      <Run x:Name="Album">Tenacious D</Run>
    </TextBlock>
    <Rectangle x:Name="AlbumArt" Canvas.Left="300" Canvas.Top="50" Width="300" Height="300">
      <Rectangle.Fill>
        <ImageBrush x:Name="AlbumArtBrush" Stretch="Fill" ImageSource="tenaciousd.jpg"/>
      </Rectangle.Fill>
    </Rectangle>
    <Rectangle x:Name="AlbumArtReflection" Canvas.Left="300" Canvas.Top="50" Width="300" Height="300"
               RenderTransformOrigin="0,1">
      <Rectangle.Fill>
        <ImageBrush x:Name="AlbumArtReflectionBrush" Stretch="Fill" ImageSource="tenaciousd.jpg"/>
      </Rectangle.Fill>
      <Rectangle.OpacityMask>
        <LinearGradientBrush StartPoint="0,1" EndPoint="0,0">
          <LinearGradientBrush.GradientStops>
            <GradientStop Color="#8f8f8f8f" Offset="0"/>
            <GradientStop Color="#00000000" Offset="0.75"/>
            <GradientStop Color="#00000000" Offset="1"/>
          </LinearGradientBrush.GradientStops>
        </LinearGradientBrush>
      </Rectangle.OpacityMask>
      <Rectangle.RenderTransform>
        <TransformGroup>
          <ScaleTransform ScaleX="1" ScaleY="-0.35"/>
          <SkewTransform x:Name="SkewTransform" AngleX="45" AngleY="0"/>
        </TransformGroup>
      </Rectangle.RenderTransform>
    </Rectangle>
    <Canvas.Resources>
      <Storyboard x:Name="ReflectionAnimation">
        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="AlbumArtReflection"
         Storyboard.TargetProperty="(UIElement.RenderTransform).(TransformGroup.Children)[1].(SkewTransform.AngleX)">
          <SplineDoubleKeyFrame KeyTime="00:00:00" Value="-45" KeySpline="0.25,0.00 0.75,0.75"/>
          <SplineDoubleKeyFrame KeyTime="00:00:02" Value="45" KeySpline="0.25,0.75 0.75,1.0"/>
        </DoubleAnimationUsingKeyFrames>
      </Storyboard>
      <Storyboard x:Name="FadeIn">
        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="Display"
         Storyboard.TargetProperty="Opacity">
          <SplineDoubleKeyFrame KeyTime="00:00:00" Value="0"/>
          <SplineDoubleKeyFrame KeyTime="00:00:01" Value="1"/>
        </DoubleAnimationUsingKeyFrames>
      </Storyboard>
      <Storyboard x:Name="FadeOut">
        <DoubleAnimationUsingKeyFrames BeginTime="00:00:00" Storyboard.TargetName="Display"
         Storyboard.TargetProperty="Opacity">
          <SplineDoubleKeyFrame KeyTime="00:00:00" Value="1"/>
          <SplineDoubleKeyFrame KeyTime="00:00:01" Value="0"/>
        </DoubleAnimationUsingKeyFrames>
      </Storyboard>
    </Canvas.Resources>
  </Canvas>
</Canvas>

To see this in action, you'll need to grab Moonlight out of SVN (I ended up using some Silverlight 2.0 TextBlock features like TextAlignment="Right" so that no code was needed to align the text like what Aaron has to calculate manually in the current code). Once you have that installed, you should be able to view my Banshee "Now Playing" mockup in the iframe below. Mousing over the iframe should cause the fade-in effect to start and mousing out of the iframe area should cause the fade-out to take effect.

Oh, XAML, what is the secret of your power? Won't you take me far away from the mucky-muck man?

Update: It has been pointed out that the above iframe could have been done in pure XAML using EventTriggers for MouseEnter/Leave events to trigger the animations, however I designed the XAML to be used by Banshee where Aaron will likely want to be able to control when the animations start/stop programatically and not based on mouse hover events ;-)

Update: The XAML should now work with Silverlight (apparently it didn't like my LineStackingStrategy or LineHeight property on the TextBlock).

Tomboy on Windows Where It Belongs

As you all know, my job here at Novell is to migrate all worthwhile desktop Linux applications off of that ridiculous platform and onto Windows so that we can do away with this nasty open source stuff. Unfortunately I haven't yet gotten the paper work to close up my code for the latest victim of this effort, so for now dirty open source hippies can get it here:

http://svn.gnome.org/svn/tomboy/branches/tomboy-portable2/

Somebody even impersonated me and posted instructions and current limitations on our mailing list (soon to be replaced with a 1-900 number offering support for a reasonable fee).

And here's an image of what it looks like. Windows has a really awesome feature where you can press your "Print Screen" button, and then you dig around in the menus to find the excellent Microsoft Paint application, at which point you recall that you can produce a "screen shot" by "pasting". Then you save in one of a myriad of excellent file formats, and you have an image of what you were doing on your computer! You can then share it with your friends like so:



What do you think? Excited to end the Linux charade and switch to a solid and hip platform like Vista? Woo!

I feel very silly today.

Utah Open Source Conference

I was fortunate enough to get to join my friends and coworkers in Provo for this Hack Week. I normally work from my home office, so I'm having a blast seeing everybody. Today we're working at Salt Lake Community College as part of the Utah Open Source Conference. I'm actually talking with my buddy Brian Merrell about the efforts of the Mono a11y team (you know, my actual job). It should be fun, we've got some neat slides and we are both cool people so I don't really see what could go wrong. The UTOSC team has done a ridiculously awesome job setting up this conference, so I'm really excited to see everything come to fruition. We had a sweet speaker dinner last night but moron that I am I forgot my camera so you just have to take my word for it!

This Tomboy stuff still needs a bit of work so off I go. Hopefully having Tomboy run on more platforms will help us attract more users and developers. I know it's a popular request so I'm pretty serious about getting it supported in trunk. Later guys!

I'm enjoying being in Provo, Utah this week at the beautiful Novell campus, with coworkers from all over, hacking away on projects of our choosing. I'm grateful to Novell for having the foresight to give us Hack Week, a time to explore and experiment - above and beyond our weekly ITO and official responsibilities.

The amazing Brad Taylor, who just joined Novell last week, joined me in creating a Muine-like interface for Banshee. People love Muine's simple interface for queueing and playing songs. Our goal is to replicate that experience leveraging Banshee. In a day's work, we got things working well.