I have written a summary of Mono's progress in the year 2011, but I want to complement my post with stories from the community.
Did you use Mono in an interesting setup during 2011? Please post a comment on this post, or email me the story and tell me a little bit about it.
We are traveling to Porto Alegre in Brazil today and will be staying in Brazil until January 4th.
Ping me by email (miguel at gnome dot org) if you would like to meet in Porto Alegre to talk hacking, Mono, Linux, open source, iPhone or if you want to enlighten me about the role of scrum masters as actors of social change.
Happy holidays!
It seems that part of Steve Jobs' legacy was to give Larry Page some advise: focus. This according to Steve Jobs' recently published biography.
So Larry Page took the advise seriously and decided to focus. His brand of focus is to kill projects that were distracting to their goals. One of them, -and the one I cared the most about- was CodeSearch..
The CodeSearch service was a unique tool as it indexed open source code in the wild.
Codesearch is one of the most valuable tools in existence for all software developers, specifically:
It is a shame that Google is turning their back on their officially stated mission "To organize the worldâs information and make it universally accessible and useful". It is a shame that this noble goal is not as important as competing with Apple, Facebook, Microsoft, Twitter and Yelp.
While writing this blog entry, I fondly remembered how Codesearch helped me understand the horrible Security framework that ships with iOS. Nobody informed the Apple engineers that "Security through obscurity" was not intended for their developer documentation.
In this particular case, I was trying to understand the semantics of kSecReturnData. How to use this constant and how it interacts with the keyring system is both tricky, and poorly specified in Apple's docs. Sometimes things fail without any indication of what went wrong, other than "error". So I used CodeSearch to figure this out (along with some other 30 constants and APIs in that library that are just as poorly documented).
These are the results of looking for this value in three search engines as of this morning.
GrepCode shows absolutely nothing relevant. But shows a bunch of Java packages with no context, no code snippets and if you make the mistake of drilling down, you wont find anything:
Not useful.
Codase is indexing 250 million lines of code, usually it takes minutes to get this page:
Maybe the server will come back up.
Koders is part of Black Duck, and searching for the term renders a bunch of matches. Not a single one of the results displayed actually contain a single use of the kSecReturnData constant. And not a single one of the snippets actually show the kSecReturnData constant. It is as useful as configuring your browser to use StumbleUpon as your search engine:
Not useful.
And this is what Codesearch shows:
The big innovation on Google's search engine is that it actually works and shows real matches for the text being searched, with a relevant snippet of the information you are looking for.
We are going to be entering the dark ages of software research in the next few months.
Running a service like Codesearch is going to take a tremendous amount of resources. There are major engineering challenges involved and hosting a service like this can not be cheap. It is probably not even profitable.
Larry Page's Google has already dropped the project. We can only hope that in a few years Sergey Brin's Google or Eric Schmidt's Google will bring this service back.
Microsoft is too busy catching up to Google and wont have any spare resources to provide a Bing for code search. And if they did, they would limit the search to Win32 APIs.
I should thank Google for funding that project for as long as they did as well as the Google engineers that worked on it as long as they could. Over the years, it helped me fix problems in a fraction of the time and helped me understand complicated problems in minutes.
The Google engineers whose projects just got shutdown for in the name of strategy and focus are probably as sad as all of us are.
On the plus side, I get to share this rant on Google Plus with a dozen of my friends!
Jeremie Laval has upgraded our Web-based documentation engine over at docs.go-mono.com. This upgrade brings a few features:
New Look: Base on Jonathan Pobst's redesign, this is what our documentation looks like now:
Better Links: Links to pages on the site will now properly open the left-side tree to the documentation you linked to. This has been an open request for about six years, and it got finally implemented.
Search: the search box on the web site uses
Lucene to search the text on the server side, and
shows you the matching results as you type:
Easier to Plug: MonoDoc/Web now easily supports loading documentation from alternate directories, it is no longer limited to loading the system-configured documentation.
No more frames: For years we used frames for the documentation pages. They had a poor experience and made the code uglier. They are now gone.
Powered by Mono's SGen: We have reduced the memory consumption of our web documentation by switching to Mono's Generational GC from Boehm's. The load on the server is lower, responses are faster and we scale better.
The source code changes are now on GitHub in the webdoc module.
We have also added Google Analytics support to our web site to help us determine which bits of documentation are more useful to you.
As Mono grows on servers, mobile and desktop platforms, we are looking to hire programmers to join our Mono Runtime team.
The Mono Runtime team owns the code generator, the just-in-time and ahead-of-time compilers, the garbage collector, the threadpool and async layers in the runtime and mostly works in the C-side of the house.
If you are a developer with low-level experience with virtual machines, just in time compilers or love garbage collection, real time processing, or you read every new research paper on incremental garbage collection, hardware acceleration, register allocation and you are interested in joining our young, self-funded and profitable startup, we want to hear from you.
Send your resumes to jobs@xamarin.com
We have historically made stable releases of Mono that get branched and maintained for long periods of time. During these long periods of time, we evolve our master release for some four to five months while we do major work on the branch.
Historically, we have had done some of these large changes since we have rewritten or re-architected large parts of our JIT, or our garbage collector, or our compilers.
There were points in the project history where it took us some 9 months to release: seven months of new development followed by two months of beta testing and fixing regressions. With Mono 2.6 we tried to change this, we tried to close the release time to at most six months, and we were relatively good at doing this with 2.8 and 2.10.
We were on track to do a quick Mono 2.12 release roughly around May, but with the April bump in the road, this derailed our plans.
Since 2.10.0 was released two things happened:
Now that things have settled at Xamarin and that we are getting Mono back into continuous integration builds we are going to release our first public beta of the upcoming Mono, it will be called Mono 2.11.1. We will keep it under QA until we are happy with the results and we will then release Mono 2.12 based on this.
But after Mono 2.12, we want to move to a new development model where we keep our master branch always in a very stable state. This means that new experimental features will be developed in branches and only landed to the master branch once they have been completed.
Our goal is to more quickly bring the features that we are developing to our users instead of having everyone wait for very long periods of time to get their new features.
These are some of the new features availalable in Mono 2.11:
Today Joseph mentioned to me that some of our users got the impression from my previous post on WinRT that we would be implementing WinRT for Linux. We are not working on a WinRT UI stack for Linux, and do not have plans to.
WinRT is a fabulous opportunity for Mono, because Microsoft is sending a strong message: if you want your code to run in multiple scenarios (server, desktops, sandboxed environments), you want to split your UI code from your backend code.
This is great because it encourages developers to think in terms of having multiple facades for the same code base and the direction that we have been taking Mono on in the last few years.
Use the native toolkit on each platform to produce an immersive user experience, and one that leverages the native platform in the best possible way.
These are the APIs that we envision .NET developers using on each platform:
Even if a lot of code could be reused from Moonlight, WinRT is a moving target. It is not clear that the Linux desktop, as we know it today, is keeping up with the growth of other consumer environments. I talked to Tim about this at Build.
There are some GUI-less components of WinRT that *do* make sense to bring to Mono platforms. There is already an implementation of some bits of the headless WinRT components being done by Eric.
The above effort will enable more code sharing to take place between regular .NET 4 apps, WP7 apps, Mono apps and WinRT apps.
Windows 8 as introduced at Build is an exciting release as it has important updates to how Microsoft envisions users will interact with their computers, to a fresh new user interface to a new programming model and a lot more.
If you build software for end-users, you should watch Jensen Harris discuss the Metro principles in Windows 8. I find myself wanting to spend time using Windows 8.
But the purpose of this post is to share what I learned at the conference specifically about WinRT and .NET.
Microsoft is using the launch of Windows 8 as an opportunity to fix long-standing problems with Windows, bring a new user interface, and enable a safe AppStore model for Windows.
To do this, they have created a third implementation of the XAML-based UI system. Unlike WPF which was exposed only to the .NET world and Silverlight which was only exposed to the browser, this new implementation is available to C++ developers, HTML/Javascript developers and also .NET developers.
.NET developers are very familiar with P/Invoke and COM Interop. Those are two technologies that allow a .NET developer to consume an external component, for example, this is how you would use the libc "system (const char *)" API from C#:
[DllImport ("libc")]
void system (string command);
[...]
system ("ls -l /");
We have used P/Invoke extensively in the Mono world to create bindings to native libraries. Gtk# binds the Gtk+ API, MonoMac binds the Cocoa API, Qyoto binds the Qt API and hundred other bindings wrap other libraries that are exposed to C# as object-oriented libraries.
COM Interop allows using C or C++ APIs directly from C# by importing the COM type libraries and having the runtime provide the necessary glue. This is how Mono talked with OpenOffice (which is based on COM), or how Mono talks to VirtualBox (which has an XPCOM based API).
There are many ways of creating bindings for a native library, but doing it by hand is bound to be both tedious and error prone. So everyone has adopted some form of "contract" that states what the API is, and the binding author uses this contract to create their language binding.
WinRT is a new set of APIs that have the following properties:
WinRT wraps both the new UI system as well as old Win32 APIs and it happens that this implementation is based on top of COM.
What we call "bindings" Microsoft now calls "projections". Projections are the process of exposing APIs to three environments: Native (C and C++), HTML/Javascript and .NET.
Even in C++ you are not exposed to COM. The use of COM is hidden behind the C++ projection tools. You use what looks and feels like a C++ object oriented API.
To support the various constructs of WinRT, the underlying platform defines a basic set of types and their mappings to various environment. In particular, collection objects in WinRT are mapped to constructs that are native to each environment.
Microsoft feels that when a developer is given the choice of a synchronous and an asynchronous API, developers will choose the simplicity of a synchronous API. The result usually works fine on the developer system, but is terrible when used in the wild.
With WinRT, Microsoft has followed a simple rule: if an API is expected to take more than 50 milliseconds to run, the API is asynchronous.
The idea of course is to ensure that every Metro application is designed to always respond to user input and to not hang, block or provide a poor user experience.
Async programming has historically been a cumbersome process as callbacks and state must be cascaded over dozens of places and error handling (usually poor error handling) is sprinkled across multiple layers of code.
To simplify this process, C# and VB have been extended to support the F#-inspired await/async pattern, turning async programming into a joy. C++ got a setup that is as good as you can get with C++ lambdas and Javascript uses promises and "then ()".
Some developers are confused as to whether .NET is there or not in the first place, as not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT.
When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8.
And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed.
Now, you notice that I said "exposed" and not "gone".
What they did was that they only exposed to the compiler a set of APIs when you target the Metro profile. So your application will not accidentally call File.Create for example. At runtime though, the CLR will load the full class library, the very one that contains File.Create, so internally, the CLR could call something like File.Create, it is just you that will have no access to it.
This split is similar to what has been done in the past with Silverlight, where not every API was exposed, and where mscorlib was given rights that your application did not have to ensure the system safety.
You might be thinking that you can use some trick (referencing the GAC library instead of the compiler reference or using reflection to get to private APIs, or P/Invoking into Win32). But all of those uses will be caught by AppStore review application and you wont be able to publish your app through Microsoft's store.
You can still do whatever ugly hack you please on your system. It just wont be possible to publish that through the AppStore.
Finally, the .NET team has taken this opportunity to do some spring cleaning. mscorlib.dll and System.dll have been split in various libraries and they have moved some types around.
Microsoft demoed creating new WinRT components on both C++ and .NET.
In the .NET case, creating a WinRT component has been drastically simplified. The following is the full source code for a component that adds 2:
public sealed class AddTwo {
public int Add (int a, int b)
{
return a + b;
}
public async IAsyncOperation SubAsync (int a, int b)
{
return a - await (CountEveryBitByHand (b));
}
}
You will notice that there are no COM declarations of any kind. The only restriction is that your class must be sealed (unless you are creating a XAML UI component, in that case the restriction is lifted).
There are also some limitations, you can not have private fields on structures, and there is not Task<T> for asynchronous APIs, instead you use the IAsyncOperation interface. Update to clarify: the no private fields rule is only limited to structs exposed to WinRT, and it does not apply to classes.
When it comes to your UI selection, you can either use HTML with CSS to style your app or you can use XAML UI.
To make it easy for HTML apps to adhere to the Metro UI style and interaction model, Microsoft distributes Javascript and CSS files that you can consume from your project. Notice that this wont work on the public web. As soon as you use any WinRT APIs, your application is a Windows app, and wont run in a standalone web browser.
.NET and C++ developers get to use XAML instead.
There is clearly a gap to be filled in the story. It should be possible to use Microsoft's Razor formatting engine to style applications using HTML/CSS while using C#. Specially since they have shown the CLR running on their HTML/JS Metro engine.
Right now HTML and CSS is limited to the Javascript use.
Microsoft has created a cool new UI library called WinRT and they have made it easy to consume from .NET, Javascript and C++ and if you adhere by their guidelines, they will publish the app on their appstore.
If you are at build, come join us tonight at 6:30 at the Sheraton Park hotel, just after Meet the Experts. Come talk about Mono, Xamarin, MonoTouch, MonoDroid and MonoMac and discuss the finer points of this blog over an open bar.
There is a long list of comments in the moderation queue that are not directly related to WinRT, or bigger questions that are not directly related to WinRT, .NET and this post's topic, so I wont be approving those comments to keep things on focus. There are better forums to have discussions on Metro.
Continuing our tradition of getting together with Mono users at Microsoft conferences, we are going to be hosting an event at the Sheraton Hotel next to the conference on Thursday at 6:30pm (just after Ask the Experts).
Come join us with your iOS, Android, Mac and Linux questions.
Lluis just released the final version of MonoDevelop 2.6.
This release packs a lot of new features, some of my favorite features in this release are:
The above is just a taste of the new features in MonoDevelop 2.6. There are many more nominate your own!
Congratulations to the MonoDevelop team on the great job they did!
And I want to thank everyone that contributed code to MonoDevelop, directly or indirectly to make this happen.
As I meet new Unix hackers using Linux or Mac, sometimes I am surprised at how few Unix tricks they know. It is sometimes painful to watch developers perform manual tasks on the shell.
What follows are my recommendations on how to improve your Unix skills, with a little introduction as to why you should get each book. I have linked to each one of those books with my Amazon afiliates link, so feel free to click on those links liberally.
Here is the list of books that programmers using Unix should read. It will only take you a couple of days to read them, but you will easily increase your productivity by a whole order of magnitude.
The Unix Programming Environment by Kernighan and Pike is a must-read. Although this is a very old book and it does not cover the fancy new features in modern versions of Unix, no other book covers in such beauty the explanation of the shell quoting rules, expansion rules, shell functions and the redirection rules.
Every single thing you do in Unix will use the above in some form or shape, and until you commit those to memory you will be a tourist, and not a resident.
Then you will learn sed and basic awk, both tools that you will use on a daily basis once you become proficient. You do not have to ever be scared of sed or regular expressions anymore.
Save yourself the embarrassment, and avoid posting on the comments section jwz's quote on regular expressions. You are not jwz.
It will take you about a week of commuting by bus to read it. You do not have to finish the book, you can skip over the second part.
While Kernighan's book is basic literacy, you need to develop your muscles and you need to do this fast and not buy a book so thick and so packed with ridiculous screenshots that you will never get past page 20.
Get UNIX for the Impatient. This book is fun, compact and is packed with goodies that will make you enjoy every minute in Unix.
Emacs has had a strong influence in Unix over the years. If you learn to use Emacs, you will automatically learn the hotkeys and keybindings in hundreds of applications in Unix.
The best place to learn Emacs is to launch Emacs and then press Control-h and then t. This is the online tutorial and it will take you about two hours to complete.
The knowledge that you will gain from Emacs will be useful for years to come. You will thank me. And you will offer to buy me a beer, which I will refuse because I rather have you buy me a freshly squeezed orange juice.
Learn to use the Midnight Commander.
The Midnight Commander blends the best of both worlds: GUI-esque file management with full access to the Unix console.
The Midnight Commander is a console application that shows 2 panels listing two different directories side-by-side and provides a command line that is fed directly to the Unix shell.
The basics are simple: use the arrow keys to move around, Control-S to do incremental searches over filenames, Control-t to tag or untag files and the F keys to perform copy, move or delete operations. Copy and Move default to copy to the other panel (which you can conveniently switch to by pressing the tab key).
There is no better way of keeping your file system organized than using my file manager.
If you can not quench your thirst for knowledge there is one last book that I will recommend. This is the atomic bomb of Unix knowledge.
Unix Power Tools is a compilation of tricks by some of the best Unix users that got compiled into a huge volume. This is a book of individual tricks, each about a page long, ideal to keep either on your bedside or in the restoom to pick a new trick every day.
At this point you might be thinking "I am awesome", "the world is my oyster" and "Avatar 3D was not such a bad movie".
But unless you touch-type, you are neither awesome, nor you are in a position to judge the qualities of the world as an oyster or any James Cameron movies.
You have to face the fact that not only you are a slow typist, you do look a little bit ridiculous. You are typing with two maybe three fingers on each hand and you move your head like a chicken as you alternate looking at your keyboard and looking at your screen.
Do humanity a favor and learn to touch type.
You can learn to touch type in about three weeks if you spend some two to three hours per day using Mavis Beacon Teaches Typing.
Mavis Beacon costs seventeen dollars ($17). Those seventeen dollars and the sixty three hours you will spend using it will do more to advance your carreer than the same sixty three hours spend reading editorials on Hacker News.
All of the books I list here have stood the test of time. They were written at a time when books were designed to last a lifetime.
Unlike most modern computer books, all of these were a pleasure to read.
This is Xamarin's first official Mono release.
This is a major bug fix release that addresses many of the problems that were reported since our last release back on April 25th.
The detailed release notes have all the details, but the highlights of this release include:
Major features continue to be developed in the main branch. Currently we are just waiting for the C# 5.0 Asynchronous Language support to be completed to release that version.
Mono 2.10.3 also serves as the foundation for the upcoming Mono for Android 1.0.3 and MonoTouch 4.1.
You can get it from Mono's Download Site.
Currently we offer source code, Windows and MacOS packages. We will publish Linux packages as soon as we are done mirroring the contents of the old site that contains the Linux repositories.
Our new compiler, as you might know, has been rewritten to support two backends: a System.Reflection.Emit backend, and the brilliant IKVM.Reflection backend.
The C# 5.0 support as found on master contains the C# 5.0 support as shipped by Microsoft on their latest public release.
To try it out, use -langversion:future when invoking the compiler. You can try some of our samples in mono/mcs/tests/test-async*.cs
We here at Xamarin are as excited as you are about the release of Lion. But unfortunately we're not quite ready to support you on Lion yet, and MonoDevelop doesn't work quite right. We're working around the clock to make MonoDevelop work perfectly on Lion, and we'll let you know as soon as it's ready.
Update on July 29th: We have most of the fixes in place for Mono and will issue a build for testing on the Alpha channel soon.
I have great news to share with the Mono community.
Today together with SUSE, an Attachmate Business Unit, we announced:
We are a young company, but we are completely dedicated to these mobile products and we can not wait to bring smiles to every one of our customers.
Our immediate plans for both MonoTouch and Mono for Android is to make sure that your critical and major bugs are fixed. We have been listening to the needs of the community and we are working to improve these products to meet your needs. You can expect updates to the products in the next week.
In the past couple of months, we have met with some of our users and we have learned a lot about what you wanted. We incorporated your feature requests into our products roadmaps for both the MonoTouch and the Mono for Android products.
Another thing we learned is that many companies need to have a priority support offering for this class of products, so we have introduced this. It can be either be purchased when you first order MonoTouch or Mono for Android, or you get an upgrade to get the priority support.
Our goals are to delight software developers by giving them the most enjoyable environment, languages and tools to build mobile applications.
We are thankful to everyone that provided feedback to us in our online form that we published a month ago. Please keep your feedback coming, you can reach us at contact@xamarin.com. We are reading every email that you send us and you can use my new miguel at new company dot com email address to reach me.
We will be at the Monospace conference this weekend at the Microsoft NERD Center, hope to see you there!
Remember to purchase early and often so we have the resources to bring you the best developer tools on the planet.
I have a posted an update on Mono and the upcoming release of Mono 2.12.
