Tomas has also created an organization for F#, it currently hosts the MonoDevelop F# Add-In, and we are going to maintain there F#'s changes that we make in the open source world to get it tuned for Linux and OSX.
Posted on 17 Nov 2010
The add-in provides intellisense for MonoDevelop, inline documentation and access to the F# interactive shell. Most of the heavy lifting is done by the F# compiler itself which is used directly by the Add-In as a service:
His blog also has screencasts on getting F# and the F# add-in installed on Linux and also shows how to create Gtk# applications with F#:
Check his blog for more details.
Posted on 16 Nov 2010
Ruben is organizing the talks, if you want to present, please submit a proposal for a presentation.
There are plenty of topics to discuss: Gtk# and the Gnome desktop; MonoDevelop and MonoDevelop add-ins; Mono Runtime; Languages: Iron*, UnityScript, C# 4, F#; Server programming with Manos or ASP.NET.
Posted on 15 Nov 2010
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
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.
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.
Our plan is to distribute F# as part of Mono for both OSX and Linux. This will take some time, in the meantime, check fsxplat.codeplex.com 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.
These resources are straight from Don's blog:
Posted on 11 Nov 2010
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 email@example.com.
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
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.
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:
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
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.
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 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
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
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.
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 irc.gnome.org.
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