New Mono Log Profiler

by Miguel de Icaza

Paolo has checked into Mono's GIT repository our brand-new profiler for Mono applications.

The new profiler is documented in detail here, and is available with Mono 2.9+ (this means: it is available if you build Mono from GIT, and will be part of the upcoming 2.10 release).

We would love to hear your feedback on it, and we hope to have a UI integrated into MonoDevelop soon.

Update: This is what one of the reports of the new profiler can produce, this is taken from running an ASP.NET application (a question that came up a few days ago on IRC):

       Heap shot 5 at 14.518 secs: size: 43684432, object count: 562907, class count: 543
            Bytes      Count  Average Class name
         10506984      87373      120 System.Collections.Hashtable.Slot[] (bytes: +1939272, count: +16161)
               87346 references from: System.Collections.Hashtable
          8130304      87486       92 System.Int32[] (bytes: +1706912, count: +16164)
               87346 references from: System.Collections.Hashtable
               40 references from: System.Collections.Generic.Dictionary
               30 references from: System.Globalization.NumberFormatInfo
          6846000      57050      120 System.Web.Caching.CacheItem (bytes: +1232880, count: +10274)
          4891432      87347       56 System.Collections.Hashtable (bytes: +904176, count: +16146)
               28526 references from: System.Web.HttpStaticObjectsCollection
               28525 references from: System.Threading.ReaderWriterLock
               28524 references from: System.Web.SessionState.SessionStateItemCollection
          1597344      28524       56 System.Web.SessionState.InProcSessionItem (bytes: +287672, count: +5137)
               28524 references from: System.Web.Caching.CacheItem
          1597344      28524       56 System.Web.SessionState.SessionStateItemCollection (bytes: +287616, count: +5136)
               28524 references from: System.Web.SessionState.InProcSessionItem

	This heapshot was taken 14.518 seconds after application startup, at the
	time there were 562907 objects in the heap, of 543 different types,
	using about 43 MB of memory.

Posted on 11 Nov 2010

F# Goes Open Source

by Miguel de Icaza

Last week, Don Syme announced that Microsoft has open sourced the F# compiler and the F# core libraries under the Apache 2 license.

In addition, on Tuesday, Don also announced a new release that fixes a handful of bugs specifically for users targeting Mono.

F# is a fascinating language, but I had not really spent much time with it as we could not really distribute it as an open source compiler limiting its usefulness in the Linux and Mac worlds. Now F# can become just another language that developers can use.

F# supports asynchronous programming today, and it was the inspiration for C# 5.0's async support. There is no need to wait for C# 5 to come out, you can start using async workflows today with F# everywhere.

MonoDevelop plugin

At the F# in Education workshop Tomas Petricek announced his MonoDevelop add-in for F#. Although he has not released a binary add-in, the source code to his plugin is available here. It provides intellisense, parameter documentation, on-the-flight error underlying and support for the F# interactive shell from the IDE.

Distributing F#

Our plan is to distribute F# as part of Mono for both OSX and Linux. This will take some time, in the meantime, check for instructions on how to get started with F# on MacOS and Linux.

It will likely run out of the box on Mono/Android and Mono/Wii. Since F# uses generics extensively, we do not know if it can be used to target the iPhone or the PS3 as both require Mono's full static compiler. We will be evaluating this in the coming weeks.

Don, minutes after open sourcing F# enjoying a tasty meal.

F# Resources

These resources are straight from Don's blog:

Posted on 11 Nov 2010

Visiting Redmond and PDC

by Miguel de Icaza

If you are attending PDC or at Microsoft and love Mono, .NET, Open Source, Linux, MacOS, iPhone, Silverlight, Android or WP7 and want to hang out, discuss, or debate the finer points of trollcats in contemporary society, drop me an email at

Alternatively, we can also indulge in some Java-driven schadenfreude or debate whether chubby pixels are worth staring at.

I will be in Redmond from Tuesday afternoon until Friday night.

Posted on 26 Oct 2010

IronRuby and IronPython Opportunities

by Miguel de Icaza

Yesterday, Jason Zander announced that the maintenance and future development of IronRuby and IronPython languages was being turned over to the Iron* communities.

Microsoft reached out to some of the users of the Iron languages to take over the coordination for these projects. Together with JB Evain, Michael Foord, Jeff Hardy and Jimmy Schementi I agreed to help coordinate the future development of these languages. The Iron* community reaction to the opening of the process has been very supportive judging by the emails on the mailing list and the twitter responses.

There are four pieces of code involved, all licensed under the Apache 2.0 license:

Both IronPython and IronRuby will be developed like other open source projects without any of the limitations that previously existed. In particular, from my very Unix-centric view, we will be able to get the proper fixes into the Iron* languages to make them work out of the box on Linux and MacOS.

Our Contributions

Although we will help with the coordination efforts in the Iron languages as the community grows and evolves, we have some concrete tasks that we will be working towards right away:

  • Ensure that the Iron* languages build and work out of the box on Linux, MacOS and Unix.
  • Use Mono's Continuous build system to keep an eye on any regressions on IronRuby and IronPython.
  • Package the latest IronRuby and IronPython for Linux and MacOS.


Ruby and Python make programmers happy. They bring joy and smiles to programmers everywhere in the Unix world. Both have strong user bases on Linux and MacOS and there is a strong ecosystem of independent implementations for both Ruby and Python, each with their unique features.

In Iron's case the major feature is being able to use your scripting language of choice while having access to all Mono APIs for building standalone applications or for extending existing applications like MonoDevelop, F-Spot, Banshee, SparkleShare and Tomboy.

From my Unix-biased standpoint, this means that all of the libraries that we have been working on over the years from Gtk# for building desktop Gnome apps, to MonoMac for creating native Mac applications with the entire universe of .NET libraries at your disposal.

The Iron* languages, combined with our MonoMac will make an appealing platform for building apps for the Mac AppStore.

Another fascinating project is the Pyjama Educational Project. Pyjama is written in IronPython, Gtk#, and GtkSourceView and currently supports 5 DLR languages.


As the announcement came out last night, Geoff Norton cooked this simple teaser of IronRuby on the iPhone.

Check it out here.

Posted on 22 Oct 2010

Missed Opportunities at Microsoft and Ray Ozzie Departure

by Miguel de Icaza

Microsoft has three big tasks ahead of itself: (a) make Azure successful; (b) make Windows Phone 7 successful; (c) keep the existing Windows and Office businesses printing money.

There is probably not a lot of political support at this point to embark on more large-scale innovations at Microsoft while there are probably hundreds of smaller innovations that are waiting under all of their product groups.

Ray Ozzie incubated a number of projects like Azure and Mesh at Microsoft that once they reached a level of usefulness were transferred to the product groups.

He is probably leaving his position as Chief Architect at Microsoft as he transfers the Azure assets to the product group and he is once again left as a general without an Army. Starting new project and recruiting teams from scratch for new products has probably taken a toll on him and he is ready to move on.

Missed Opportunities

Back in June I blogged about what I would do if I was in charge of Windows 8: among other things, I would have created a Windows AppStore.

This AppStore would have helped independent ISVs tremendously by opening the entire Windows user base as potential customer for Microsoft's products. It would have helped Microsoft make Windows even more relevant, and it would have done more to push native applications on Windows than anything else they have tried in the past.

The Windows PC market is a market that is many times larger than today's iPhone market. It would have been a gold mine, and there would have been a renewed gold rush to ship "Windows AppStore-ready" applications for Windows.

Hundreds of people at Microsoft must have had this idea, the question is why it never bubbled up to the top?

Short of a Microsoft-powered AppStore, Intel has announced that their Windows Appstore will now include .NET software.

On the one hand, Intel has now given up any attempts to make their AppStore be a cross-platform app-store, which I felt was a gracious thing for them to do, as it would have helped Linux.

Financially, having a strong Windows-based appstore was probably the right thing to do for Intel. There was really no point in Intel undermining his own efforts by forcing people to use cross platform tools in the first place.

If Microsoft was the one providing the AppStore, they would be reaching a much bigger market than what Intel hopes to reach.

This could have been a great Ray-Ozzie level hack to pull at Microsoft. In the meantime, Apple today announced an AppStore, and they are going to get a bucket of apps and a bucket of developers to push software on their platform.

Live Mesh

Live Mesh had a lot of promise, but sadly, the groups working on it refused to open up the specs on time, and the product became fairly uninteresting over time.

If you are going to open something for the world to see, you should be ready to let the world interoperate with it from the start. Otherwise you merely give your competitors the good ideas, and they throw away your bad ideas and avoid paying any of your strategy taxes.

Posted on 20 Oct 2010

Shipping Smiles on the AppStore

by Miguel de Icaza

Happy days at Mono Central. Just a few months ago we decided that we should apply the lessons learned from MonoTouch to Mono on the Mac and we built a new set of .NET APIs for developing native Mac applications. We called this MonoMac.

We recently brought tears of joy to developers by shipping it.

MonoMac will be a great tool to build native Mac application using your favorite .NET programming language.

We clearly have to take this to the next step as MonoMac is merely a binding to .NET. We are going to have to extend MonoDevelop to create fully self-contained applications that embed both your application, any library dependencies that it needs as well as the Mono runtime.

The above really had not been my priority, as far as I was concerned "Download Mono and Install it" was a perfectly suitable solution. So you have Apple to thank for my change of heart.

Hopefully we will have an experience as smooth as the MonoTouch experience has been.

Posted on 20 Oct 2010

Bringing Smiles to the Faces of MacOS developers

by Miguel de Icaza

As part of our efforts to bring a superb developer experience to every platform in the world, we have made a new release of our bindings to the MacOS X APIs: MonoMac.

We know that Mac users like to have a smooth installation experience, and we have worked hard to make this as simple as possible. Currently MonoMac is still not a 1.0 product, this is what developers need to do:

The result is a .app that you can distribute to your users.

The MonoMac API design is inspired by work that we did for MonoTouch.

We have achieved a beautiful blend between C# and MacOS that will turn Mac developer's tears of pain into tears of joy.


Update: to get started with MonoMac, you can join other MonoMac-ers on the IRC channel #monomac on server

We use the mono-osx mailing list to discuss the binding.


If you want to get your hands on the source code for MonoMac, head over to GitHub and download both monomac and maccore. The former contains the MacOS-specific bindings, while the latter contains the shared code between MonoMac and MonoTouch.

The introductory post to MonoMac still contains many useful links and design details, you might want to read that if you want to hack on MonoMac.


Our API coverage right now is very complete. We will certainly add more C# features to the binding as we learn how developers are using the API, but that is a bit of an organic process.

One area that we need help to improve the developer experience is to fill-in all the "summary" sections in our documentation. This information is shown during auto-complete/intellisense for the developer for classes, methods, enumeration values and properties.

Details on how you can contribute to this are on this post of mine.

Posted on 12 Oct 2010

A Mono Success Story of Biblical Proportions

by Miguel de Icaza

Read David Mitchell's experience in using Mono to reuse code between the Windows and Mac platforms.

Posted on 07 Oct 2010

Mono 2.8 is out

by Miguel de Icaza

We have just released Mono 2.8 a major upgrade to the Mono developer platform. This release contains ten months worth of new features, stability fixes, performance work and bug fixes.

The highlights of this release include:

  • C# 4.0
  • Defaults to the 4.0 profile
  • New Generational Garbage Collector
    • Use mono --gc=sgen or mono-sgen to use Mono with the new GC
  • New Frameworks from Mono MIT X11 and Microsoft MS-PL/Apache2:
    • ASP.NET 4.0
    • Parallel Framework: including PLINQ.
    • System.XAML
    • System.Dynamic
    • Managed Extensibility Framework
    • ASP.NET MVC 2
    • System.Data.Services.Client (OData client framework)
    • WCF Routing
    • .NET 4.0's CodeContracts
  • Performance:
    • Large performance improvements
    • LLVM support has graduated to stable
      • Use mono-llvm command to run your server loads with the LLVM backend
  • Version 2.0 of the embedding API
  • Removed the 1.1 profile and various deprecated libraries.
  • OpenBSD support integrated
  • Mono no longer depends on GLIB
  • Threadpool exception behavior .NET 2.0

For the full details, check our detailed Mono 2.8 Release Notes

Posted on 06 Oct 2010

The Mystery Behind the Hacking the Boston Museum of Fine Arts

by Miguel de Icaza

A decade ago some hackers went into the Boston Museum of Fine Arts and replaced the guided tour audio with their own content. The identity of the hackers remains a close guarded secret and one of Boston's biggest unsolved mystery's. Investigators could only agree on one thing: that the voice in the tape did not belong to Lev Davidovich Bronstein.

I got my hands on the audio file back in 1999 and during one of my visits to MIT that year I saw the news paper coverage of the event. I vaguely remember the news article, but it described the reactions of the visitors and featured interviewed with shocked citizens.

This is the recording.

Update: Dylan tells me that the cat is out of the bag. Read the interview with BJ Novak here.

Posted on 29 Sep 2010

« Newer entries | Older entries »