Categories

Recent comments

Who's online

There are currently 0 users and 5 guests online.

Twitter

more

R. Tyler's Last.fm

more

You are herenews aggregator / sources / Monologue

Monologue

Syndicate content
The voices of Mono
URL: http://www.go-mono.com/monologue/
Updated: 1 hour 19 min ago

Ivan N. Zlatev: Take this Apple fanboys (or how sad this world is)

13 hours 59 min ago

I stumbled upon an exciting news from the Apple camp today. Apple has added a new copyright protection mechanism to iTunes which blocks you (Apple users) from watching your movies (copyright protected) on your own TV (or any other external display). Enjoy!

Apple iTunes External Display Copyright Protection

Source: Wired Blog Post

Categories: Tech Blogs

Michael Hutchinson: Completing ASP.NET Collection Properties

November 19, 2008 - 1:07pm

I've recently been tweaking the ASP.NET completion, adding support for resolving valid children for a control. These can be properties, a property, or controls. More difficult was resolving the valid children for properties, but this is now done:

Unfortunately, there aren't actually any designer or parser attributes for limiting the children of a property, so in order to resolve the children, I assume it's a collection, and look for an Add method with a single parameter derived from Control. If this exists, I use its parameter to filter the types in the control completion list. It's an ugly hack, but it works perfectly for tables and wizards. In the worst case, MonoDevelop falls back to showing all controls.

With this done, the ASP.NET completion is essentially feature-complete.
<!--break-->

Categories: Tech Blogs

Jeroen Frijters: Multi Target Support

November 18, 2008 - 5:46pm

I've now enabled "multi target" support. This means that you can compile multiple assemblies at once. One of the advantages this has is that it makes dealing with circular dependencies much easier, but even if there aren't any circular dependencies, it can make building much easier because you don't have to do any dependency analysis.

As an example I compiled the jars from the JBoss lib directory:

ikvmc -target:library { commons-codec.jar } { commons-httpclient.jar } { commons-logging.jar } { concurrent.jar } { getopt.jar } { jboss-common.jar } { jboss-jmx.jar } { jboss-system.jar } { jboss-xml-binding.jar } { log4j-boot.jar }

The curly braces define the targets. This is all it takes to compile these jars into seperate assemblies that automatically reference eachother, as required.

Using NDepend (which Patrick Smacchia kindly gave me a free copy of) you can easily graph the dependencies of the resulting assemblies:

In this case there aren't any cycles, but had there been, it would have made no differences.

The multi target feature is by no means done. I want to add a -sharedclassloader option to enable multiple assemblies to share a single Java class loader. I'm also considering some options to select which classes/packages go in which assembly. This would be helpful for splitting the core class library into multiple assemblies.

Changes:

  • Added support to ikvmstub for automatically exporting non-vector array types.
  • Implemented/fixed support for pointers, by ref and non-vector arrays in IKVM.Reflection.Emit.
  • Fixed pointer detection to work for types with multiple indirection levels.
  • Changed proxy stub name mangling to work around ildasm bug.
  • Fixed IKVM.Reflection.Emit to not write token of FAULT pseudo exception that is used as a marker for fault blocks.
  • Fixed class loading to take ClassLoader lock.
  • Changed ikvmc not to generate warning when it loads ikvmstub generated classes.
  • Removed our version of System.Runtime.CompilerServices.ExtensionAttribute and instead add System.Core.jar to the compilation, this will allow us to reference the real ExtensionAttribute when it is available and yet the build will still work (albeit with a warning and without the ExtensionAttribute) when it is not available (i.e. when building on .NET 2.0).
  • Did some clean up and restructuring in IKVM.Reflection.Emit.
  • Fixed sorting of InterfaceImpl table in IKVM.Reflection.Emit.
  • Removed hard coded public keys from JniInterface.cs and Configuration.java.
  • Changed build process so that version number for all assemblies only has to be specified in CommonAssemblyInfo.cs.
  • Enabled multi target support.
  • Fixed typo in IKVM.Reflection.Emit that caused assembly minor version to be set to major version.
  • Added assembly version to ikvmstub.

As always with a development snapshot, don't use this in production, but please do try it out and let me know about it. The sources are available in cvs and the binaries here: ikvmbin-0.39.3245.zip

Categories: Tech Blogs

Chris Howie: Development on hold

November 18, 2008 - 7:28am

Well, this morning while I was packing up my laptop it kind of slipped, and… well… Yeah, so don’t expect Banshee.OpenVP to be ready for a while.

Categories: Tech Blogs

Ben Maurer: Amazon's CloudFront CDN: disappointing

November 18, 2008 - 5:02am

I took a look at CloudFront today. They have really good intentions. The CDN space is quite a mess -- it could easily be a pay-as-you-go, self-service industry. However, players such as Akamai try to make a large profit. The CDN space is especially hard for small sites -- you can't get any reasonable pricing unless you are doing high levels of traffic.

Amazon wants to change all of that. However, I think they made a number of missteps in their initial offering.

  • They aren't using it on amazon.com. They use Level(3)'s CDN! Why should anybody consider using a service Amazon isn't using themselves. This is a chance to prove your CDN in real life.
  • Tiered pricing. In a self-service model, it doesn't make sense to offer different prices for different bandwidth usages. One customer with 100 TB of traffic is the same as 10 customers with 10 TB of traffic.
  • Pay per request. For S3, this made sense. Every request was one disk seek on the servers, and people need to pay for that. However, in a CDN, you are expected to serve from memory. The 1 cent per 10,000 requests effectively adds 6 KB of data to every file. So if you serve a 1 KB file, this increases your cost by 6x. At the very least, the fixed cost per request should be less than that with s3 to account for the lack of disk seeks
  • Lack of peering. Doing a traceroute to cloudfront from a few locations (Carnegie Mellon, colos in New York and LA), it appeared that all of my traffic was going over transit links. In contrast, traffic to amazon.com went over fast and cheap peering links.

I do hope that Amazon fixes up CloudFront. It's a fantastic concept. They have the power to force reason into the market.

Categories: Tech Blogs

Aaron Bockover: A couple of ideas for contributing to Banshee

November 17, 2008 - 10:42am

Jono's blog post about Banshee Kickin' it has some interesting comments that I'd like to address, specifically regarding the new track editor and Internet Radio in the recently released Banshee 1.4.

The Track Editor

The new track editor is fully extensible. This means you can add your own pages to the dialog and get full first class editing support. All of the current pages are implemented in the exact same way you would need to write an extension page.

What I would like to see are a few pages contributed at least initially by the community:

  • Creative Commons metadata/license support
    A lot of work on this in the past had been done in the past, but never to a quality or completeness I was comfortable with for including in core. This support could either be an extension page to the editor, or an extension that interacts with existing pages/fields, like the copyright field.

    Additionally, the extension could make a track column and query field available, so you could easily search for and view Creative Commons music. This was a pain to do in legacy Banshee, but it's a few lines of code in 1.x.

  • Music Brainz
    A page that allows for figuring out missing metadata, and also submitting track information back to MusicBrainz. Maybe it could also generate PUIDs. We have a complete C# implementation of the MusicBrainz web API (no native library needed) thanks to Scott Peterson, and it's used in other areas in Banshee. This really should not be that complicated to do.

I wrote a quick example today on how to extend the track editor. The example implements a History Page which allows you to change the play count, skip count, and last played date to arbitrary values. More could be done here, and in fact I'd like to make this a core page anyway.

  • Download the example
  • Extract, change directories, and make run
  • Play with the code!
  • You need Banshee 1.4 and Mono 1.9 or better (I opted to use C# 3.0 in the example)
Internet Radio

We made a decision early on in the 1.x series to provide very strong Last.FM support. We're fairly resource constrained, so this meant making traditional Internet Radio something of a second class citizen. In fact, I made a choice to not ship any default radio stations because really I should not be the one picking stations, and so many of them fall offline in the life cycle of a distribution iteration that supporting this is silly.

However, I made sure all the underlying pieces for good Internet Radio support were in place. We have a station editor, stream metadata is reflected in the UI so when playing a stream you can see "track changes" which in turn can trigger cover art, and the RadioTrackInfo object even handles fetching and parsing of remote station playlsits. We support M3U, PLS, ASX, and XSPF formats, and possibly some others I am forgetting.

The Radio source that ships by default is a bit bare in terms of UI, but this was intentional. You can add new stations and manage them, but we really need something like StreamTuner or Shoutcast, like Jono says, that builds on the Internet Radio core features. Implementing new sources is fairly straightforward. You can even extend the existing Radio source to build on it.

Implementing this would be a great standalone extension that I would love to ultimately roll back into core, maybe for 1.6 if an enthusiastic contributor steps up to the plate.

So what are you waiting for?

Join the community of enthusiastic Banshee contributors and write something great today. We have a large and functional API, lots of features to build on, and everything is designed around extensibility.

Such a large API can be daunting to learn, yes, but Banshee is also organized very well. We also have API documentation for Monodoc, and probably the best way to learn about Banshee's internals is to just read the source to the extensions we ship in core. All the great features in Banshee are just extensions!

Lastly, don't hesitate to stop by on the IRC channel asking for help!

Categories: Tech Blogs

Michael Hutchinson: HTML Completion

November 17, 2008 - 8:09am

The main thing I've been working on for the upcoming MonoDevelop 2.0 release is ASP.NET code completion, and I'm pretty happy with its current state. Recently I've been "downporting" this code into base classes to make it easier to write XML completion and HTML completion editor extensions. A while back I wrote a hybrid XML/ASP.NET/HTML parser, which I've been using in MonoDevelop for triggering ASP.NET code completion. The aims of this parser were to be extensible and to have good error recovery. This makes sharing code between XML-like completion extensions very easy — the completion triggering code and the path bar code are entirely shared between the editors.

After moving the HTML code down to a common base class, I decided to expose this functionality for actual HTML files, rather than just ASP.NET, and wrote an HTML text editor extension to handle this.
<!--break-->
As well as parsing a path, for code completion, the parser can also parse a complete document into a tree. This is useful for code folding, error underlining, and the document outline. The ASP.NET extension does not yet use it in this mode, instead using the older and better-tested Mono ASP.NET parser, so the first time this saw use was in XAML completion (about which I still need to blog). I recently (and trivially) "crossported" this code over to the HTML text editor.

The final piece of the puzzle was to write an HTML tag state for the parser to enable it to recognise and implicitly close tags when appropriate. Putting this all together, we get to the most important thing: the screenshot.

The blue underlines are warnings, when a tag has been implicitly closed. Note that the document outline is still correctly formed. The red underline is of course an error, and the parser has recovered from that too.

Categories: Tech Blogs

Gendarme: Gendarme News Week #46, 2008

November 17, 2008 - 5:05am

at 11/13/2008 7:52:00 AM poupou said...

Late last night I uploaded the first preview (binaries and Win32 installer) for Gendarme 2.2. Documentation on Mono wiki has also been updated (and I need to look at automating this step). Benchmarking is next (while waiting for feedback) but I got quite a bit of patch to apply to HEAD first!

at 11/10/2008 10:52:24 PM poupou said...

Mono 2-2 branch was made earlier today. Setup is complete and Gendarme builds and test ok from the branch. I'll be moving my build-n-test activities to Windows and, once ready (the Makefile/MD/VS integration is still untested on Windows), build a preview of the 2.2 win32 installer.

Read older news...

Categories: Tech Blogs

Aaron Bockover: Banshee 1.4 hits the streets, packed with Awesome

November 17, 2008 - 4:56am

After three months of hard work on feature additions, a slew of bug fixes, stability and performance improvements, and a small tangent on porting to Mac OS X, we have released Banshee 1.4 -- the new stable series!

HTC G1/Android Support Out-of-the-box

Got a G1? Get a Banshee! Banshee is the first media player to offer a customized experience for the Android/G1 phone.

  • Synchronize or manually manage your media collection on your G1 phone
  • Cover art is fully supported on the G1
  • Import music you purchased through the Amazon MP3 store on the G1 in one quick pass

Additionally, if you try to delete music you purchased on the Amazon MP3 store without actually being in the special "Purchased Music" source, Banshee will not comply. This prevents accidental deletion of music you may not yet have backed up to your desktop computer. To remove purchased music from the device, do so from the "Purchased Music" source.

With the G1 + Banshee, an experience similar to what iPhone users enjoy is available.

A final note on the G1 support: because the Android platform is open source, I was able to easily figure out optimal ways of implementing Android/G1 support. For instance, I was unsure what the maximum cover art size should be on the device, so I just read the source. It was a nice for once to not have to reverse engineer or guess!

Banshee on Mac OS X

I wrote a bit about this already, but 1.4 ushers in a new era for Banshee! From now on, Banshee will always be officially released and maintained for Mac OS X, 10.4 and newer currently.

Because this is the first release of Banshee on Mac OS X, we are calling it a beta quality technology preview. This means that there are some known stability issues, and certainly some missing features, but it's good enough that we really encourage people to start trying it and filing bugs.

Some of the missing features for OS X (also known as "places where we are eagerly looking for new contributors"):

  • Hardware Backend
    Without a backend implementing interfaces in the Banshee.Hardware namespace, the OS X release does not feature any device support (no audio CDs, no digital audio players, no CD burning). For ambitious developers familiar with hardware APIs in OS X, following the HAL backend for Linux/FreeBSD is a great place to start!

  • Embedded Video
    Currently the Quartz video backend in GStreamer does not implement GstXOverlay. Work needs to be done to make this happen (even though obviously Quartz is not X11), or specific embedding can be done in Banshee itself. I'd prefer to see native GstXOverlay support however.

  • Screensaver/Power Management Inhibit
    In GNOME, this is implemented to prevent the system from sleeping or starting the screensaver when Banshee is in full screen mode (i.e. playing a movie).

  • Support for the Front Row/Apple TV remote
    This would just be a fun thing to write. Someone step up!

Finally, I have to give Eoin Hennessy a huge thanks for his work here again. Also to thank are the Songbird guys who have invested in making GStreamer usable on the Mac. We are looking forward to contributing in this space and working with Songbird, now that we are off the ground. What they have accomplished here is no small feat, not to be overlooked!

New API for customized mass storage device support

Implementing G1 support was done through the newly extensible mass storage device extension. That's right, extensions extending extensions. With this new API, it is now possible to add "polished" support for certain classes of mass storage media players, like the G1 or BlackBerry devices.

For instance, here's how the G1 is implemented:

Since this is just another Mono.Addin extension, new device support like this can be added outside of Banshee itself. I should note that this augments the portable_audio_player HAL specification. It's to be used when more than the generic mass storage functionality is desired for a device.

The Release Notes Speak

For a more in-depth overview of what Banshee 1.4 has to offer, please read the release notes. Here's a quick overview on what they cover:

  • Media player devices now support playlists (iPod, MTP/PlaysForSure included)
  • You can now have your device automatically sync with your library, or continue to manage it manually
  • I've implemented a brand new track editor that is fully extensible. It's very easy to add new pages!
  • Shiny new UI for now playing makes for a more entertaining "background" or "party" mode
  • There's now a tool that can rescan your library, adding new items or removing stale ones
  • File names/paths can now be automatically updated when metadata changes
  • Lots of minor UI improvements and polish
  • Stability and performance improvements
Try it already!

Banshee 1.4 is hands-down the best Banshee ever! Period! Packages should be available soon for your favorite Linux distribution, if they are not already (openSUSE and Ubuntu packages are at least ready now). And of course we have a shiny new Mac OS X .dmg!

Enjoy!

Update: Ryan wrote a great article about 1.4 over at Ars Technica. The comments are interesting. Is there anyone out there who has tried running Banshee on OpenSolaris? It works on FreeBSD...

This post powered by the "Similar to Eric Clapton" Last.FM radio station in Banshee 1.4.

Digg It!

var digg_url = "http://banshee-project.org/download/archives/1.4.1/";

Categories: Tech Blogs

Alexandre Gomes: ASP.Net State Management And Why You Shouldn?t Use Session Directly

November 16, 2008 - 11:46pm

ASP.Net provides out-the-box several nice (although not new) features to manage your application’s state, the Session and Application objects. The Session and Application objects are also among the first things learned by students of almost any web programming framework but while they are true in their usefulness it doesn’t mean you should use them directly, [...]

Categories: Tech Blogs

Joe Audette: mojoPortal 2.2.7.8 Released

November 16, 2008 - 11:04pm

I'm happy to announce the release of mojoPortal 2.2.7.8, available now on the download page.

Important Upgrade Notes

We added a feature to combine and minify the CSS files in the skins. Those using custom skins should modify their skins as described here after upgrading.

This release also contains Oomph, as described in my previous post.

We have a new Croatian language translation thanks to Slaven Brumec.

Other than the above and a few bug fixes and feature tweaks as discussed in the forums since the last release, the main focus of this release is changes to make developers happy as discussed below.

Source Code Project Re-Organization

All of the content features like Blog, forum, Gallery, Maps, etc, have been moved out of the core mojoPortal projects into the mojoPortal.Features.* projects. This makes it possible to build and package a leaner version of mojoPortal without any features except Html Content. I will still continue to make the official mojoPortal releases with all the features, I have no plans to package separate mojoPortal lite packages myself, but the idea is that developers can package their own application with mojoPortal without having to include all the features we have. If you work with the mojoportal-core.sln Visual Studio Solution, it will build without any of the extra features and you can package it with UnLeashIt. If you build the mojoportal-complete.sln solution, post build events will copy the extra features up to the core Web project, so you don't want to do that if you plan to package without those features. Once they are copied up to the Web project UnLeashIt will include them, so you need to keep it clean by not building that solution if you want to package without those features.

As a result of this, features are now basically self contained within folders, like the Blog is in the siteroot/Blog folder and forums are in the siteroot/Forums folder and so on. For backward compatibility I created pages with the old names that will do a 301 redirect to the new pages. I also was careful to make sure friendly urls for existing blog posts would continue to work correctly.

The only thing site owners need to change is if they previously submitted a blog site map to google using siteroot/BlogSiteMap.ashx, you need to change that to siteroot/Blog/BlogSiteMap.ashx

When Should We Target .NET 3.5?

I'd like to gather input and opinions about when we should change the target platform to .NET 3.5. I'm eager to start playing with Silverlight in mojoPortal and it seems to need the 3.5 versions of ScriptManager to host the <asp:Silverlight control

The issues I see are:

  • We need to be careful to keep compatibility with Mono. I think we can move forward with using .NET 3.5 on Windows and continue to build for .NET 2.0 for the MonoDevelop solution. We really won't add non-supported features in the core projects but we need to be able to specify 3.5 settings in Web.config of the core Web project. We already maintain a different Web.config file for Mono packages so this should not be a problem. We can put 3.5 functionality like Silverlight into separate projects and use post build events to deploy them into the main web for runtime as we do with most features. So these projects can be left out of the MonoDevelop Solution until they are supported. In summary I think we can workaround all issues relating to Mono and should be able to move forward while still maintaining Mono compatibility.
  • Hosting - This is the issue I'm not entirely sure of and would appreciate any input. If the next release of mojoPortal for Windows targets the 3.5 runtime is that available at your hosting or will it pose a barrier to upgrade? It seems like most of the big name hosts have .NET 3.5, they don't like to be left behind by the competition.
  • Visual Studio 2005 Issues? - As far as I know VS 2005 can target 3.5 without problems except maybe for Windows Workflow development and it doesn't have some of the built in project templates for 3.5 .NET projects. We already maintain separate VS 2005 solution files so we could leave out any projects if they don't work.
UPDATE:

Forgot to mention that I updated the project road map yesterday.



Joe Audette  ...

Categories: Tech Blogs

Joe Audette: mojoPortal 2.2.7.8 Released

November 16, 2008 - 11:04pm

I'm happy to announce the release of mojoPortal 2.2.7.8, available now on the download page.

Important Upgrade Notes

We added a feature to combine and minify the CSS files in the skins. Those using custom skins should modify their skins as described here after upgrading.

This release also contains Oomph, as described in my previous post.

We have a new Croatian language translation thanks to Slaven Brumec.

Other than the above and a few bug fixes and feature tweaks as discussed in the forums since the last release, the main focus of this release is changes to make developers happy as discussed below.

Source Code Project Re-Organization

All of the content features like Blog, forum, Gallery, Maps, etc, have been moved out of the core mojoPortal projects into the mojoPortal.Features.* projects. This makes it possible to build and package a leaner version of mojoPortal without any features except Html Content. I will still continue to make the official mojoPortal releases with all the features, I have no plans to package separate mojoPortal lite packages myself, but the idea is that developers can package their own application with mojoPortal without having to include all the features we have. If you work with the mojoportal-core.sln Visual Studio Solution, it will build without any of the extra features and you can package it with UnLeashIt. If you build the mojoportal-complete.sln solution, post build events will copy the extra features up to the core Web project, so you don't want to do that if you plan to package without those features. Once they are copied up to the Web project UnLeashIt will include them, so you need to keep it clean by not building that solution if you want to package without those features.

As a result of this, features are now basically self contained within folders, like the Blog is in the siteroot/Blog folder and forums are in the siteroot/Forums folder and so on. For backward compatibility I created pages with the old names that will do a 301 redirect to the new pages. I also was careful to make sure friendly urls for existing blog posts would continue to work correctly.

The only thing site owners need to change is if they previously submitted a blog site map to google using siteroot/BlogSiteMap.ashx, you need to change that to siteroot/Blog/BlogSiteMap.ashx

When Should We Target .NET 3.5?

I'd like to gather input and opinions about when we should change the target platform to .NET 3.5. I'm eager to start playing with Silverlight in mojoPortal and it seems to need the 3.5 versions of ScriptManager to host the <asp:Silverlight control

The issues I see are:

  • We need to be careful to keep compatibility with Mono. I think we can move forward with using .NET 3.5 on Windows and continue to build for .NET 2.0 for the MonoDevelop solution. We really won't add non-supported features in the core projects but we need to be able to specify 3.5 settings in Web.config of the core Web project. We already maintain a different Web.config file for Mono packages so this should not be a problem. We can put 3.5 functionality like Silverlight into separate projects and use post build events to deploy them into the main web for runtime as we do with most features. So these projects can be left out of the MonoDevelop Solution until they are supported. In summary I think we can workaround all issues relating to Mono and should be able to move forward while still maintaining Mono compatibility.
  • Hosting - This is the issue I'm not entirely sure of and would appreciate any input. If the next release of mojoPortal for Windows targets the 3.5 runtime is that available at your hosting or will it pose a barrier to upgrade? It seems like most of the big name hosts have .NET 3.5, they don't like to be left behind by the competition.
  • Visual Studio 2005 Issues? - As far as I know VS 2005 can target 3.5 without problems except maybe for Windows Workflow development and it doesn't have some of the built in project templates for 3.5 .NET projects. We already maintain separate VS 2005 solution files so we could leave out any projects if they don't work.
UPDATE:

Forgot to mention that I updated the project road map yesterday.



Joe Audette  ...

Categories: Tech Blogs

Jeroen Frijters: .NET Array Weirdness

November 16, 2008 - 5:08pm

One of the lesser known features of the .NET runtime is the support for multidimensional and/or non-zero-based arrays. The typical arrays that you use (and that are the same as the arrays in Java) are called vectors in the CLI specification, but unfortunately the non-vector arrays don't have a specific name (they are simply called arrays in the CLI specification).

In C# you can easily create a non-vector array:

int[,] arr1 = new int[4, 4]

This creates a two dimensional array of integers with 16 elements. This array is zero based. If you want to create a non-zero-based array, you have to use the API, because C# doesn't directly support that:

int[,] arr2 = (int[,])Array.CreateInstance(typeof(int), new[] { 4, 4 }, new[] { 1, 1 });

This also creates a two dimensional array of integers with 16 elements, but in this case the indexes run from 1 through 5.

So far, so good. Now let's look at how things look at the IL level. If you use ildasm to look at the first C# based instantation you'll see:

ldc.i4.1
ldc.i4.1
newobj instance void int32[0...,0...]::.ctor(int32, int32)

Most of this looks straightforward if you're familiar with IL, except for the [0...,0...] part. It looks like the lower bounds are part of the type, but a simple experiment shows that this is not the case:

Console.WriteLine(arr1.GetType() == arr2.GetType());

This prints out True. This implies that the lower bounds are not part of the type (and the CLI specification confirms this). So why are they part of the signature? I don't know for sure, but it does have an interesting consequence. You can overload methods based on this:

.assembly extern mscorlib { }
.assembly Test { }
.module Test.exe

.class public Program
{
  .method public static void Foo(int32[0...,0...] foo)
  {
    ret
  }

  .method public static void Foo(int32[1...,1...] foo)
  {
    ret
  }

  .method private static void Main()
  {
    .entrypoint
    ldc.i4.1
    ldc.i4.1
    newobj instance void int32[0...,0...]::.ctor(int32, int32)
    call void Program::Foo(int32[0...,0...])
    ret
  }
}

This is a valid and verifiable application. Unfortunately, using the  .NET reflection API it is impossible to see the difference in signatures between the two Foo methods.

This limitation in reflection means that code compiled with the new IKVM.Reflection.Emit based ikvmc won't be able to call methods that have non-zero-based array parameters. It is also impossible to override these methods, but that was already the case with the previous System.Reflection.Emit based implementation as well.

Finally, in the above text I talk about the lower bounds, but the same thing applies to the upper bounds of the array.

Categories: Tech Blogs

Sebastien Pouliot: Gendarme 2.2 Performance

November 16, 2008 - 8:10am

Like the previous 2.0 release I wanted to invest some time to track where time and memory goes - and make sure Gendarme stays fast. My (personal) performance goal for Gendarme 2.2 was that time/memory increases (percentages) should be lower than the added new features (i.e. rules).

Now be warned that this benchmark (like most of them ;-) is not fair. Why ? because I want to compare performance between Gendarme 2.0 and 2.2. This is not the same as comparing Gendarme 2.0 on Mono 2.0 versus Gendarme 2.2 on Mono 2.2 - even if this is what most people will end up doing. E.g. The newer JIT in Mono 2.2 is a lot better, thanks to some pretty cool hackers - but I'll let them (or others) show you how much better it is ;-). So in the following tests both versions of Gendarme are being executed on the Mono 2.2 JIT. Also the older 2.0 was modified to report the initialization time (between a tenth and half of a second) to be similar to what 2.2 does. This is important because the new engines, present in 2.2, spend their time in initialization (from a few to several seconds). So timing this step became critical in 2.2. In other words you should see even better performance than the current numbers shows.

Gendarmeversion2.02.2 preview 1change (%) Rules#151183121.19%[1] Applications# assembliestime (sec)time (sec)change (%) Banshee 1.2 14 6.55 7.58 115.70%[2] Beagle 20 10.52 11.32 107.59% F-Spot 22 676.01 586.33 86.73%[3] Giver 1 1.44 1.41 98.15% Gnome-Do 0.6.1 3 1.82 1.87 102.45% Monodoc 12 2.15 2.44 113.73% Monsoon 4 5.93 6.75 113.83% Tasque 2 2.12 2.33 109.54% Tomboy 4 3.65 4.05 110.84% Mono 2.2 (2.0 profile) default [4] 85 70.74 154.15 217.92%[5] all rules 85 697.14 819.39 117.54%[6] Total1,478.081,597.62108.09%

Notes:

  1. The "real" percentage should be a bit higher since we merged two rules and other got more features/checks.
  2. Don't worry I updated to Banshee 1.4, but that was after I got those numbers :-)
  3. Most of the time still comes from Tao.OpenGl.dll, the net gain too. Nestor is working on the main culprit so it will be even faster in 2.4
  4. The "default" rule set includes every rules except the Smells
  5. That was quite unexpected. Even more since 2.1 was more performent than 2.0 up to 175 rules.
  6. Fixing #5 will help for the final 2.2 but even more important will be the fix for #3 (but that 2.4 stuff ;-)

The final index (108%) is under the rules increase (121%) but the time required to fully analyze Mono 2.2 (2.0 profile) assemblies shows a (or some) bottleneck(s) that needs further work. Analysis (and fixes) have already started this weekend. Expect an updated table for the next preview (or RC).

Categories: Tech Blogs

Jeroen Frijters: Introducing IKVM.Reflection.Emit

November 13, 2008 - 8:01pm

Over the past two months I've been working on reimplementing a large portion of the Reflection.Emit API from scratch. After finally growing tired of the System.Reflection.Emit bugs and limitations and not finding Mono.Cecil satisfactory either, I decided to build my own implementation.

I started out with these design goals:

  • API compatible with System.Reflection.Emit (as much as possible).
  • Implement only the Emit part and be compatible with System.Reflection.
  • Only implement functionality required by ikvmc, but not implemented functionality shouldn't silently fail (i.e. it should throw a NotSupportedException or NotImplementedException). This also means that the API is mostly write-only.
  • Efficient implementation, optimized for ikvmc specific scenarios.

I think I've met or exceeded all of the design goals. Without doing any significant performance work on my Ref.Emit implementation (other than the design), ikvmc became so much faster that it is rather emberassing for the Microsoft System.Reflection.Emit implementation.

I've only had to make a couple of minor changes to the ikvmc sources (apart from changing using System.Reflection.Emit; to using IKVM.Reflection.Emit; in every file) to account for the fact that IKVM.Reflection.Emit.ModuleBuilder and IKVM.Reflection.Emit.AssemblyBuilder unfortunately cannot extend System.Reflection.Module and System.Reflection.Assembly. However, it looks like this is fixed in the .NET 4.0 CTP.

Here are some random statistics about compiling IKVM.OpenJDK.ClassLibrary.dll on .NET 2.0 SP2 x64:

  System.Reflection.Emit     IKVM.Reflection.Emit   File size 31,645,696 30,480,896   bytes CPU time used 272 35   seconds Peak virtual memory 1,433,399,296 1,035,018,240   bytes Generation 0 GCs 770 896   Generation 1 GCs 201 240   Generation 2 GCs 11 8  

(The huge memory usage is not because it actually needs that much memory, but simply the result of the fact that garbage collection is more efficient if you have more memory available and that my system had about 1.5GB of free memory while running these tests.)

The smaller file size is because System.Reflection.Emit always uses fat method headers and IKVM.Reflection.Emit uses tiny method headers whenever possible.

There is still some work left to do, I've only spent limited time on debugging support and there is no support for Mono's .mdb format yet. I also haven't done any testing on Mono yet.

BTW, thanks to Sebastien Pouliot for code I lifted from Mono to parse strong name CAPI key blobs.

Other changes in this snapshot:

  • Dropped support for Visual Studio 2005.
  • Added error message when map.xml references non-existing constructor.
  • Added more statistics to ikvmc -time option output.

As always with a development snapshot, don't use this in production, but please do try it out and let me know about it. The sources are available in cvs and the binaries here: ikvmbin-0.39.3240.zip

Categories: Tech Blogs

Miguel de Icaza: Unity on Linux, First Screenshots

November 13, 2008 - 6:12pm

The first Unity3D on Linux screenshot:

The above program was built on MacOS, the result copied to Linux and then executed using the LinuxPlayer. This is still very basic, the port is yet far from done.

I followed Joachim's advise and added a tiny script to update the cube on the screen. See the video of the cubes in action: ogg and wmv.

Categories: Tech Blogs

Everaldo Canuto: Mono 2.0.1 for Nokia devices

November 13, 2008 - 3:57pm

Last weeks lots of people contact me to ask about Mono 2.0 packages for Maemo, I have been working to get it done and I finished it some moments ago (03:02am now). So, instead of I big post what I did is updated the documentation on Mono's website.

For more information about how to get it working check:


you could be also interested to get more information about scratchbox:


And the mandatory screenshots:



Tomboy running on N810 (Mono 2.0.1)


PEditGtkSharp running on N810 (Mono 2.0.1)


Package Manager showing Mono 2.0.1 runtime package

Let me know if you found some problems.

Categories: Tech Blogs

Miguel de Icaza: Framework Design Guidelines, 2nd Edition

November 13, 2008 - 12:07pm

A couple of years ago I wrote an enthusiastic review of Brad Abrams and Krzysztof Cwalina's Framework Design Guidelines, a book that I absolutely love.

The book is a great compendium of best-practices for building software, traps and pitfalls to avoid.

But most importantly, it is the best source to learn the idioms and patterns used in the .NET Frameworks. Learning these idioms will have you writing code like the native C# speakers in no time.

I was incredibly honored when Brad asked me earlier this year to write the foreword for the second edition of the Framework Design Guidelines.

The second edition tracks the evolution of .NET and they apply as well to Mono. For instance, it now contains LINQ design patterns, extension methods patterns and DependencyProperties (used in WPF and Silverlight).

Categories: Tech Blogs

Christian Hergert: GTask

November 13, 2008 - 8:24am

Categories: Tech Blogs

Sebastien Pouliot: Gendarme 2.2

November 13, 2008 - 7:18am

Mono branched for 2.2 earlier this week and Gendarme follow its wave. A first preview, binaries and win32 installer, are now available on Ohloh. Linux packages (inside mono-tools) for the first preview should be available soon.

This Gendarme release includes the development results of the last four months, including some major events like the Novell Hack Week 3 and the second half of GSoC 2008 work done by Nestor Salceda. Major highlights includes:

  • Improvement to the framework by the addition of engines that can build extra information to extend the model Cecil gives us to work with.
  • New [FxCopCompatibility] attribute to match between Gendarme and FxCop rules. This will be used to support [SuppressMessage] inside assemblies in a future release.
  • New TearDown capability on rules and runners allow rules to defer the reporting of defects until the analysis is completed.
  • New "Audit" severity. This is used to denotate defects that, too often, can't be fixed (i.e. will always be reported) but needs to be audited (e.g. security items).
  • By default the console runner now reports only when both Severity > Low, i.e. skipping Low and Audit severity defects, and Confidence > Low, i.e. skipping Low confidence defects.
    This is to help reduce false positives and get smaller reports with the most important defects. You can override both option, with lower or higher values, with new command switches.
  • The wizard runner is now, by default, limited to 1000 defects on the visible API and will, like the console runner, report only defects when both Severity > Low and Confidence > Low. A new step in the wizard allow users to change those settings before the analysis (defaults can be modified and saved).
  • You can now save your rule selection as the new default in the wizard. The same set will be enable next time you restart the wizard.

32 new rules including:


Gendarme.Rules.BadPractice
Gendarme.Rules.Concurrency
Gendarme.Rules.Correctness
Gendarme.Rules.Design
Gendarme.Rules.Design.Generic
Gendarme.Rules.Design.Linq
Gendarme.Rules.Exceptions
Gendarme.Rules.Interoperability
Gendarme.Rules.Naming
Gendarme.Rules.Performance
Gendarme.Rules.Security.Cas
Gendarme.Rules.Serialization
Gendarme.Rules.Smells

Lots of rules have been updated and, in a few cases, renamed or moved, to provide extended functionalities. Biggest move/merge changes are:

  • CAS-related Security rules were moved into Security.Cas
  • DisposableFieldsShouldBeDisposedRule was moved from Design into Correctness
  • EnumNotEndsWithEnumOrFlagsSuffixRule was merged with UseCorrectSuffixRule (Naming)
  • FinalizersShouldCallBaseClassFinalizerRule was moved from Design into Correctness
  • ImplementGenericCollectionInterfacesRule was moved from Design into Design.Generic

Contributors for this release are: Peter Johanson, Nestor Salceda, Cedric Vivier, Jesse Jones, Alan McGovern and me :-)

Categories: Tech Blogs