MonoSpace Conference Announced
Scott Bellware has announced the MonoSpace Conference in Austin Texas on October 27-30th.
Scott has made a Call for Speakers:
The Monospace Conference is looking for teachers to give tutorials on the Mono framework, tools, languages, and platforms supported by Mono.Some tutorials are aimed at .NET developers with little experience with operating systems other than Windows, and others are geared to experienced Mono developers with exposure to the various Mono platforms.
The tutorials are two hour to three hour interactive sessions that can be any combination of follow-along examples, labs, and lecture.
We're looking for tutorials on subjects such as Linux, Mac, Windows, web, desktop, servers, message queues, databases, iPhone, Android, Amazon's EC2, among others.
You can track the progress of the conference at the MonoSpace Conf Blog.
You can also follow the progress on twitter.
Scott was one of the founders of the Alt.Net series of conferences.
Some Cool Mono Announcements
Yesterday we shipped Mono 2.4.2, our long-term supported version of Mono. It ships Microsoft's opensourced ASP.NET MVC stack for the first time (you could get it before on your own, but now it is integrated) and fixes over 150 reported bugs.
Chris Toshok announced M/Invoke a tool to port applications that use P/Invokes on Win32 to Linux and MacOS.
What Chris does not talk about on his post is that he was trying to use some .NET software that interfaces via USB to his glucose meter and was trying to get this to run on Linux. The tool is mostly .NET with the usual handful of P/Invokes to Win32. And this is how M/Invoke was born: a tool to retarget P/Invoke happy applications into becoming pure managed applications.
This opens new doors to forcefully port more apps to Linux.
Alan McGovern released a new version of Mono.Nat one of the libraries used by MonoTorrent.
Jordi Mas released a new version of Mistelix a DVD authoring tool for Linux:
Jordi's GBrainy brain teaser game was picked up by MoLinux, a regional Linux distribution, and shipped it translated to Spanish:
Joe Audette's mojoPortal was being installed four times as much when it got included in in Microsoft's Web Platform Installer site (more stats here).
For years I have loved the Joel on Software rules for software engineering. And one of those rules is "Build in one step". We have not always succeeded, but we have always tried. Lluis delivers the one step to build and run for MonoDevelop on Windows: Load solution, Hit F5, up and running.
Google Chrome really lead the way here, and I want very badly to have all of Mono building in Visual Studio with one keystroke, but we are not there yet.
Stephane reports on some nice startup performance improvements for F-Spot. Loading time for 10 images from Stephane's own image collection went from 1.2 seconds to .5 seconds.
MonoDevelop got some enhanced support for autoconf integration.
Jeremy Laval released another version of ZenComic a desktop Comic reader:
David Siegel announced a new release of Gnome Do on behalf of the Gnome Do team. In particular, it is now easier to write "Docklets" for the Gnome Do panel and for those of us that like the Emacs keybindings, it is now possible to use C-N and C-P for navigation
And of course the Google Summer of Code is in full swing:
And we have various very exciting projects brewing.
Jonathan Pobst has been exploring integration points for Mono and Visual Studio 2010:
Guadec: I will sadly not be attending the Guadec/Akademy conference in Canaria next week. This is going to be a busy summer for us as we are shipping a lot of code in the next few months: Moonlight 2.0, Mono for Visual Studio, MonoTouch 1.0 and Mono 2.6.
PhyreEngine, Mono, cool Mono uses in Gaming, and more.
Last week there was a little Mono surprise. It can be found on this Novell-hosted web page web page (scroll a little bit).
It has been a few very busy weeks at Novell's Eastern Research and Development Facility (Novell NERD Facility) here in Cambridge and we have been incredibly busy polishing some nice toys.
A few weeks ago we learned about Sony's developer event in the West Coast. Michael, Zoltan and myself worked very hard to put together a demo to show the virtues of C# and the CIL to developers. So we cranked on some record time some code:
- PhyreEngine#
- Static compiler for PowerPC for Mono on PS3
- A yield-based co-routine framework.
We picked Sony's PhyreEngine to demostrate how to use Mono to write the high-level code for a game using Sony's finely tuned engine. We figured this was better than showing a for loop printing the numbers 1 to 10 on the screen.
PhyreEngine# wraps PhyreEngine using the same techniques that we used in Gtk# and Moonlight. The resulting API is glorious and by letting PhyreEngine do all the heavy lifting while driving all the high-level from C# there is no way of telling that the driving force is not C++. All you get is pure unadultered productivity.
To make our demos a little more interesting, Michael wrote a minimalistic yield-based co-routine framework inspired by some of the ideas that our friend Lucas gave us. It is a tiny toy, but we used it to illustrate the concept of using C# iterators as the foundation for game logic development and how a cooperative scheduler would work (Unity game logic works just like this).
We were also working on completing Mono's port to the PlayStation 3's native operating system (this is different than running Mono on Linux on the PS3: that already works, and it was used for developing CellDotNet, a JIT for the PS3's SPUs). Zoltan developed the static compiler for PowerPC and I did the platform support.
Mono can now run "Hello World" on the PS3 native OS. There are still lots of ins, lots of outs and lots of whathaveyous that need to be tied up before this fully works and before we are able to run PhyreEngine# on the PS3.
Developing Cross Platform application with MonoDevelop
Yesterday Lluis announced the last missing piece from our strategy to make MonoDevelop a full cross-platform IDE: MonoDevelop now runs on Windows as well:
When we started the planning for MonoDevelop 2.2, the major goal of that release was to get feature parity on Linux, MacOS and Windows.
We want to grow the community of developers that contribute to MonoDevelop and we wanted to attract add-in developers that wanted to bring their IDE extensions to all three platforms.
MonoDevelop has recently been getting some nice community contributed plugins like Flash/Flex development support, Vala language support, Mono debugger for OSX (thanks to the nice folks at Unity for this!), VI editing mode and of course our own Silverlight and ASP.NET MVC add-ins.
My theory is that supporting MonoDevelop on all the three major operating systems will have a multiplication effect in terms of contributions to MonoDevelop: it will help both users and will enable developers that extend MonoDevelop with add-ins to reach more users.
I secretly want Unity to adopt MonoDevelop as the code editor for Unity; for the FlashDevelop guys on Windows to adopt MonoDevelop as their cross-platform foundation (their users want a cross platform Flashdevelop); for Flashbang to bring their UnityScript framework to MonoDevelop
Developing an add-in for MonoDevelop now brings your enhancements to a much larger community.
Look and Feel
Although the IDE is built using Gtk#, but we are aware that developers want to get things integrated with their operating system as much as possible. This is why we have invested in properly integrating MonoDevelop with the Mac and Windows.
The Look of MonoDevelop still has a heavy feel of the Linux Gtk+, but we are bluring the lines by making the theme and style match the operating system. Development in Gtk native themes will also continue to improve things.
Feel wise, we make MonoDevelop follow the conventions of the host platform. For example, on the Mac, MonoDevelop uses the Mac system menu, it uses an entirely different keybinding style that follows what every Mac developer expects (Command-KEY operations that match X-Code for example) and even text selection in the editor behaves differently:
More work will come, because we want MonoDevelop to feel native on each platform.
On Windows for example, MonoDevelop runs on top of the .NET Framework and uses the .NET managed debugger instead of using Mono's runtime and Mono's debugger, so there is no dependency on Mono to be installed on the system.
Moonlight 2 Preview 3
Another week of excellent work on the Moonlight universe and we bring you our Preview 3 release of Moonlight. Alan McGovern said it best though.
This week stats:
This is what the Silverlight Toolkit Sample page looked with Preview 2:
Moonlight 2 Preview 2
This is what the Silverlight Toolkit page looks with Preview 3:
Moonlight 2 Preview 3
You should be able to update directly from Firefox, or if you are trying it for the first time, go to our http://go-mono.com/moonlight-preview/ page.
Now, although Preview 2 was able to run the IronPython mini-Web IDE I am still going to try to pass that as a new feature.
And now you can try the IronPython mini-Web IDE!
Three Melon's Quest for R2-D2
I had the honor to meet the Three Melon developers at Unity's party this year at the Game Developer Conference. Three Melons is an Argentinian-based company that builds online games, and most recently they have been using Unity to build their new online games.
Today they just announced that their latest online game powered by Unity and Mono. "Quest for R2-D2" is now live at Lego.com:
Pato Jutard, co-founder of Three Meleons announced the launch and posted the Making of Lego Star Wars game by Three Melons:
Congratulations to the Three Melon developers for their launch!
You can follow them on twitter.
Moonlight 2 Preview 2
As we promised last week (threatened?) now that the
foundation for Moonlight 2 is in place, we will be doing
weekly releases for folks to try out, and to increase the
feedback that we have received.
Thanks to everyone that provided bug reports and contacted us about the problems with last week's preview. In particular the issue affecting Ubuntu and SLED 10 users has been fixed and the plugin should work.
If you installed Moonlight already, you can update either by restarting Firefox or by following these steps:
If you have not installed Moonlight yet and want to try it out, go to http://www.go-mono.com/moonlight-preview.
This release fixes various rendering problems, more sites should be working and the performance was increased in multiple hot spots.
Micro Focus Video
My friend Stephen sent me an interesting video they just cooked up at Micro Focus giving some hints as to what is coming up on the keynote of Micro Focus Live.
They recently bought Borland.
Developing Silverlight Apps on Linux and MacOS with Moonlight
Earlier this week I promised I would blog about how to build Silverlight apps in Linux. Michael beat me to this and did a couple of screencasts.
In Moonlight Development in Linux with MonoDevelop he walks us through the steps necessary to install the Moonlight SDK on top of Mono 2.4 and using MonoDevelop to create your app. Once you get these installed, here is how you get started with development:
MonoDevelop will provide auto-complete for the Silverlight APIs and also provide auto-complete in XAML files.
In addition to Linux, you can also use MonoDevelop on OSX to do the same thing. We shipped Moonlight's SDK as part of the MonoDevelop/OSX release, the result runs with Microsoft's Silverlight.
Michael again talks about it and produced a nice screencast:
I, for one, welcome our new SH4 embedded overlords.
ST Microelectronics, the maintainers of GCC-CIL (the GCC code generator backend that produces ECMA CIL bytecodes for Mono/.NET) have announced their port of Mono to the SH4 platform.
The code is currently available from http://code.google.com/p/mono-sh4/.
In addition to the MIPS64 port that I mentioned last week from SiCortex/nIX is now being merged into Mono's repository.
MIPS apparently is not only used in super computers, but apparently is also powering $169 dollar netbooks.
Innovation
Dana Blankenhorn comments on the the Moonlight 2.0 release and says:
It's the kind of open source success story Microsoft wants publicized. Microsoft innovates, open source copies.It's not the kind of open source story open source needs, however.
What open source needs is real innovation, created by teams who may or may not represent Microsoft's fierce competitors. This can be hard to deliver, and Microsoft would like us all to know resistance in this case is futile.
A few points.
First: Moonlight's core is designed to ensure that Linux users get access to content that is produced for Silverlight on the web.
This is about making sure that Linux (and for that matter any other system where Moonlight can be compiled) does not become a second class citizen on the web.
Folks will argue all day whether the Silverlight model is the right one; whether it is gaining adoption; whether it is necessary; whether it is part of the open web.
But none of that matters when trying to access content on Linux: it is either possible to use it, or not. And having a working relationship with Microsoft allows us to bring it to Linux.
Second: Dana is looking in all the wrong places for innovation. If he wants to see my team's work that deviates from the set of APIs that Microsoft has created, he could look at our work on SIMD; our interactive C#; Static compilation technology to support things like the iPhone; our cross platform MonoDevelop (Linux, OSX, Windows); Our Gtk# API for building the above; He could look at all of our Mono.* classes, or all of the libraries and APIs produced by our community (Mono.Addins, Mono.Nat, Mono.ZeroConf, BitSharp, Cecil, CocoaSharp, MonoObjc, Crimson, and some forty others; I just got tired of going through the list here and here).
All of these created to solve a particular problem with the tools that we had on the platform we used.
Or for that matter, even reading the announcements on my blog.
Or he could look elsewhere in the vast universe of open source projects for ideas that match his definition of innovation. Not everything that is built in the open source world has to be about innovating in a completely new direction.
Third, and most important one: The definition of Innovation.
Innovation
Most people that discuss innovation have not even bothered to actually think about what this means in the first place. And I am particularly bothered when people claim that open source does not innovate, but can only copy.
Google's define:innovation is a good starting point.
Are Ideas Innovations? Everyone has ideas, even great ideas. Every day you go to lunch, every day you are taking a shower, every day you are walking alone and thinking you are having new ideas.
You can have a million ideas, and these might be innovative, but if they do not reach the world, did they matter?
For an idea or an innovation to have a practical effect, they need to go beyond the discussion at the lunch table with your friends and become a reality.
Bringing an Idea to Life Once I sit down and turn my idea into an actual tangible result there are a number of hurdles in my path.
The idea must be good enough for people to try out, I must get it distributed, and I must get people to use it.
Being first versus being to market first: It does not matter that many great ideas originate in the open source world or at the lunch table with your friends. You must bring the ideas to the public and the public must be in a position to adopt it.
For instance, Compaq/Digital were showing portable MP3 players based on Linux years before the iPod took the world by storm. Yet, nobody remembers these devices anymore and Apple gets the credit for bringing digital audio to the masses.
Or tagging and searching your email. GMail uses it today, but few people remember that the idea had been implemented before in Digital's Pachyderm.
Many ideas might originate as personal prototypes or even open source prototypes, but without a distribution channel and an ecosystem that would sustain the innovation many of those ideas exist merely to be replaced by folks in a better position to market/distribute it.
Claiming "I had the idea first" or "we were the first ones" is of little consolation if someone out-executes and out-markets you.
Definitions of Innovation: Wikipedia (as of 10 seconds ago) defines Innovation as:
The term innovation means a new way of doing something. It may refer to incremental, radical, and revolutionary changes in thinking, products, processes, or organizations. A distinction is typically made between invention, an idea made manifest, and innovation, ideas applied successfully.
I also like this one (from Google's define: too):
Innovation is the process that translates knowledge into economic growth and social well-being. It encompasses a series of scientific, technological, organizational, financial and commercial activities.
I think that Moonlight fits this definition perfectly well in that case.
Moonlight and Innovation
Sure, we do follow the APIs that Microsoft set for Silverlight.
But we have innovated in a number of ways:
- We innovate in the development process: we
are an open source project, taking contributions and
consuming other open source components.
We dogfood other FOSS components, and we iterate to improve them.
In 1999, the MIT Technology Review magazine named me the innovator of the year. In the award ceremony, Bob Metcalfe said that I was receiving the award for the work on Gnome, not because Gnome was a ground-breaking system, but because the goals and processes of Gnome were.
- We innovate in our cross-platform stance: Moonlight runs on more platforms (although admittedly, with a smaller market share than Windows and MacOS).
- We had out-of-browser support before Silverlight did: Sure it was trivial, but we had it before (see above note on futility of claiming "we were here first").
- Working with Microsoft: Ok, this is a bit of a stretch to claim as innovation, but here it goes: I am very proud that we are finding ways of working with a company that for many years resisted Linux and open source as well as helping Microsoft with all of its inertia become more open source friendly.
- Update: Mats on the comments points out something that I wish I had thought of when I wrote this: "Innovation is also, and I'd say mostly if history teaches us anything, about building and improving upon ideas - not just making new ones from scratch."
We (the Mono/Moonlight team) are not Dana's beacon of revolutionary change. But it is no secret that we are fans of the CLI virtual machine, and we believe that giving developers this platform will help them turn their ideas into innovations by giving them the best technologies available.
Users of Mono and Moonlight have already demonstrated that they have way better ideas than I have ever had. And they already have used Mono in brilliant ways. Dana might want to check my blog more periodically to take note of those innovations.
Mono talk at the Beantown.NET Users Group
Tomorrow, Joseph, Michael, Gonzalo and myself will be talking at the Beantown.NET Users Group about Mono, Moonlight and MonoDevelop at 6pm.
If you are in the Boston area, come join us for these open source festivities at Microsoft NERD center in Cambridge.
MonoDevelop on MacOS X
Good news for all OSX users, a build of MonoDevelop that integrates with OSX is now available:
MonoDevelop OSX-ified.
For the impatient among you, click and run MonoDevelop.app.zip.
It requires Mono 2.4 for OSX, on the upside, you can use this to develop ASP.NET MVC apps on the Mac.
Some Background
Back in February I showed a screenshot of MonoDevelop 2.0 for the Mac, it looked like this:
Super-Alpha-Preview of MonoDevelop on OSX.
It was basically the Gtk# based MonoDevelop IDE binary executing on the Mac. There was no porting involved, just the same executable running under Mono/OSX. The code works, but it did not feel like a Mac app:
- The Menu bar was embedded in the window.
- The keyboard accelerators were the Linux ones. They felt unnatural for OSX users, and also did not take advantage of the spare key (Command) to liberate the control key for other uses.
- The editor behaved like a Linux editor.
There is a vibrant Mono on OSX community out there, and it will only grow larger. We wanted to make sure that all of the work that is going into creating a great IDE is available for folks on the Mac in a way that is actually comfortable to use.
So working with folks in the Mac Community and with folks at Unity Michael has been working on tuning up MonoDevelop on the Mac to become an editor that does not get in the way of Mac users and developers and integrates better from the "feel" perspective with other tools in the OS.
For instance, not only does the new MonoDevelop for MacOS use the Mac menu bar, and the Mac accelerators (a combination of XCode and Textmate accelerators), but even the text editor has been altered to support the way selection and navigation works on the Mac.
I figured that for every 100 users of MonoDevelop one of them will contribute patches back to the effort. If you happen to be that 1% hacker that will contribute back, you might want to look at a list of ideas to improve MonoDevelop on the Mac.
MonoDevelop on Windows.
MonoDevelop on Windows is on a similar boat: the 2.0 release works "out of the box" on Windows, but again, it is a GNOME IDE in a Windows land.
Stay tuned for news from the MonoDevelop community as to what will happen there.
Update: Lluis posted an update on the progress of MonoDevelop on Windows.
Smooth Streaming with Moonlight
I never tested Smooth Streaming before, just the more basic media tests, but the Smooth Streaming stack is running with our Moonlight preview:
You can see a few rendering glitches for the controls on the screen. But this is really good news for our new media pipeline.
First Moonlight 2.0 Preview is Out
After a loving incubation period, the Moonlight
2.0 preview, an open source implementation
of Microsoft's
Silverlight for Linux has been released:
- source code (tar.bz)
- Firefox/Linux binaries for x86 and x86/64
- Release Notes
- Sites that we are tracking.
- Chris Toshok's blog with more details (Chris is the Moonlight team lead).
This is really the release I have been looking for since Microsoft first introduced Silverlight 1.1 and ever since our 21-day hack-a-thon to bring Silverlight to Linux.
This is the ECMA VM running inside the browser and powering C# and any other CIL-compatible languages like Ruby, Python and Boo. You can use Moonlight/Silverlight as a GUI (this is what most folks do) or you can use it as the engine to power your Python/Ruby scripting in the browser.
Installing Moonlight 1.9
Go to our preview page, select the platform and hit the download icon.
That will download and install the plugin in your Firefox installation. You can then restart the browser, and you should see this:
Then you can try out some of the test web sites we have been working on. This is CNN's The Moment that uses Silverlight/Photosynth:
If instead of binaries you want to build Moonlight in the comfort of your own living room while sipping margaritas, fetch the source code for mono, mcs, mono-basic and moon from the branch and build them in this order: mono, mono-basic and moon.
While one hand holds your margarita, use the other one to follow the instructions on how to compile Mono from SVN.
Some Notes on this Release
Now some qualifications to this release:
This is a preview release. By this we mean that we are not yet feature complete with Silverlight 2.0 feature-to-feature but we are relatively close. For example, we do not yet pass the entire Silverlight GUI 2.0 test suite that was provided to us by Microsoft and you can spot glitches in various web sites.
Security Sandbox: One of the reasons we delayed the first preview of Moonlight for public consumption was that we did not want to release Moonlight without the security sandbox. In the pre-Moonlight days there was no reason for Mono to implement a security sandbox, so we never had it. With Moonlight a security sandbox is mandatory so we implemented it.
Moonlight 2.0 ships with the new CoreCLR Sandbox that was introduced in Silverlight 2.0. This security system is very easy to understand, it is pretty straightforward and is a lot easier to secure and audit than something like CAS. I will blog about the security stack in another post.
But even if we now have a security sandbox , we have not completed the security audit.
Weekly Releases: Our current plan is to update the plugin once a week during this preview/alpha period hoping that we can get good bug reports and to ensure that we work in as many Linux distributions as possible.
Debug Builds: During the preview/alpha cycle we are shipping our code with debugging symbols hoping that this will improve the quality of the bug reports that we receive. This means that the plugin size instead of being 3.9 megs is 8.8 megs on average. This will change when we do the final release.
The Cool Toys
There are a number of cool toys on this release, the foundation for many things to come. Here are some:
Silverlight Unix SDK: If you install Mono 2.4 and Moonlight SDK (not the browser plugin, but the -devel package) you can now develop Silverlight applications entirely in Unix.
In fact when you install Eclipse4SL (a Microsoft sponsored project) you need Mono 2.4 to build Silverlight apps. With the Moonlight SDK you can skip an entire step by having the SDK assemblies present at installation time.
I will do another blog on how to build Silverlight apps from the ground up on Unix using the Moonlight SDK.
Microsoft MS-PL Controls: Instead of reimplementing the high-level controls (buttons, Checkboxes, listboxes, containers, calendars, datepickers, sliders) or the very advanced controls (like a full database bound datagrid) Moonlight reuses Microsoft's open sourced Silverlight controls.
Iron* Languages: In addition to C# you can run code written in a variety of programming languages that target the ECMA CLI. In particular dynamic languages.
IronRuby and IronPython are open source implementations of Ruby and Python done by Microsoft that can be used in Silverlight but you can also use a variety of other languages in the browser like Visual Basic or PHP (Phalanger).
Visual Basic Runtime: This is just a plug for the work that Mainsoft did a few years ago. One of the things that Silverlight ships with is a Visual Basic class library for all the VB helper functions.
Mainsoft contributed a few years ago a VB runtime written entirely in VB
We ship a "tuned" version of their assemblies as part of the Moonlight release.
Adaptive Streaming: This also deserves a blog entry of its own. In addition to the support for HTTP-Streaming (to support seeking and stream quality selection) Silverlight allows developers to create their own transports to fetch media and not be limited by HTTP.
For instance, a developer could write a transport that fetches different bits of the media from different servers. Or use bittorrent to fetch the media instead of depending on a single server. More in an upcoming blog entry.
DeepZoom: with all of the bells and whistles that you expect.
Hard Rock Memorabilia on Moonlight/Linux.
Silverlight 3.0 APIs: As we were implementing the 2.0 APIs a handful of features from 3.0 fit naturally into our design. So instead of going the extra mile to limit things in 2.0, we just expose the 3.0 APIs in a forward-compatible fashion.
This Moonlight preview includes a few 3.0 features:
- Out-of-browser support (although this is currently a manual process, not yet automated, and without a GUI).
- WritableBitmap class.
- 3.0 pluggable media pipeline.
- SaveDialog support.
There are more details see Chris Toshok's blog entry.
The pluggable media framework is very exciting to us, because it means that developers can author their own codecs without waiting for Silverlight or Moonlight to add support for it.
We have developed a handful of open source codecs for Dirac, Vorbis and ADPCM that can be used with Silverlight 3/Moonlight Preview based on existing C# and Java implementations. Hopefully someone will help us fill in the blanks with more codecs (like Theora).
For up-to-date news check out our README file.
In the words of Paris Jobs, this release is nothing short of hawt.
Moonlight Twitteristas
If you want to follow the progress of various Moonlight activities on Twitter, you can follow these folks:
- moonproject: the twitter account for project news.
- kumpera: in charge of the Mono metadata and IL verifier and creator of Mono.SIMD.
- spouliot: Mono's security and cryptography Czar and graphics hacker.
- lewing: Moonlight core hacker, in charge of Moonlight's layout and performance and also the creator of the Linux logo and co-developer of F-Spot.
- toshok: Moonlight team leader and maintainer of the core of Moonlight. ex-Winforms team lead.
- jbevain: In charge of the Silverlight 2.1 API, Mono's Linker and Cecil.
- kangamono: Codec hacker, hard-problem solver, iPhone support, Mono on Mac.
- atsushi_eno: XML, LINQ to XML, WCF and pluggable codec author.
- sh4na: Recovering winformista, in charge of the new toggle ref implementation and the Moonlight/Javascript bridge.
- rolfkvinge: media pipeline, visual basic runtime, vbnc compiler (Mono's VB compiler written in VB).
- jstedfast: text layout engine, and ex-Evolution hacker.
- jacksonh: All things XAML, a recovering Winformista/Ilasm-ista. A must-follow twitterista, considering that even Aimee_b_loved follows him.
- rustyhowell: release engineering.
Some of the team members are not twitteristas yet.
Alternatively, if you are not really into twitter, you can always check our aggregated blogs at monologue.
Interactive C# Code Completion
Last month I introduced code completion in Mono's Interactive C# shell. You can use the TAB key to auto-complete at the current cursor position. Pressing the TAB key twice will list all possible completions.
This should make the csharp more pleasurable
to use and for bash junkies like me a more natural fit.
This is particularly useful to explore an API like Gtk#:
csharp> LoadPackage ("gtk-sharp-2.0");
csharp> using Gtk;
csharp> Application.Init ();
csharp> var w = new Window ("Hello");
csharp> w.SetF[tab]
SetFlag SetFocus SetFrameDimensions
csharp> w.SetFo[tab]
csharp> w.SetFocus ();
This comes in quite handy for completing namespaces, types and valid methods. It works with the C# 3.0 initializer syntax as well, that one is useful in Silverlight for those of us that can not stand to type XAML instead of C#:
csharp> new TextBlock () { Bac[tab]
Does the nice:
csharp> new TextBlock () { Background
Bonus points: another tab at that point inserts the equal sign to assign the value.
This was done by extending the Mono.CSharp.Evaluator API to provide code completion.
The API is fairly simple:
public static string [] GetCompletions (string input, out string prefix)
This will provide possible completions (methods, properties, fields) that are valid at that point in the string.
A discussion that details the implementation of how the compiler supports code completion is in the mailing list and our compiler documentation has been updated to include a tutorial on expanding code completion.
The next step is to implement this for the interactive GUI shell.
Gtk# 2.12.8 Installer for Windows
Mike Kestner yesterday announced the availability of the new Gtk# installer for Windows.
A few good news: the entire stack (Gtk+, Cairo and Gtk#) comes in a nice 8 meg download, it is packaged as an MSI and it is now signed by Novell's certificate, so you no longer get a scary "Unknown Publisher" dingus on the screen.
This is the equivalent of the greek god Prometheus giving fire to humans.
We are giving Windows developers a nice cross-platform toolkit that is nicely integrated into Visual Studio. To try a sample application using it, you can download Tomboy, load the Tomboy.sln solution, hit F5 and enjoy.
PseudoTerminal class
As a follow up to yesterday's post I did the "hard work" of cut-and-pasting the VTE pseudo-terminal support+gnome-pty-helper into an independent module and wrote a managed binding for the code, autoconf-ified it and put it on SVN.
Code lives in the pty-sharp module, or you can get a tarball.
Now someone needs to do the trivial hack of writing the Mono terminal emulator.
Pseudo Terminals and Terminal Emulators
There was a discussion about how to host REPLs in applications like MonoDevelop recently and some of the discussion was centered around how to host something like a shell into a program like MD.
Since I have been thinking about building a Silverlight-based version of the Midnight Commander (OH NOES!) I figured I should share some thoughts that I had on this matter.
Widgets like ZVT and VTE today bundle a number of things in a single widget:
- A Unix Pseudo terminal with login/logout support (Unix flavor-specific).
- A terminal emulator that turns escape sequences generated by a stream into rendering commands.
- A binding to the Gtk+ toolkit to send input events to the child process and render the terminal results.
I would like to see some nice C# libraries for doing each one of those tasks independently of each other. Think of it as the MVC of terminal widgets. Like this:
Reusable Blocks for Terminal Emulation.
Pseudo-terminal support: the functionality to create pseudo terminals is very OS-specific, it is hard to get right and getting the more advanced features like registering your session is even harder. Very few applications get this right (mc, zvt and vte all use the same code that took me years to fine tune but has never been made reusable for other applications).
This can be used beyond terminal emulators, it can be used to script or control programs expect a real terminal to run. These are typically interactive Unix console applications.
Those applications either break or refuse to run when their standard input or standard output are redirected. Expect is a system built on top of this functionality
Terminal Emulation: A terminal emulator class that supports the vt100/xterm command set and render it into some internal buffer; can take high-level keystrokes and encode them as byte streams (for example turning Alt-X into ESC-x) and supports terminal resizing.
This terminal emulator should not be bound to Gtk+ it should merely render into a text buffer.
Gtk#, Silverlight and Curses Bindings: Once the underlying terminal emulator exists we will need to write a handful of bindings to the terminal emulator.
The Gtk# is an obvious choice for embedding terminal emulators inside things like MonoDevelop.
The Silverlight binding would allow people to create full fledged SSH clients on the web.
The curses binding could be used to implement an application like GNU Screen or it could be used in an application like the Midnight Commander (the Midnight Commander plays some Unix tricks to avoid having to emulate a terminal, and this has been a small weakness).
Banshee and Tomboy over the weekend
Over the weekend a couple of interesting post were made:
In "Fitting the Kitchen Sink into a CD" Jo from the the Debian/Ubuntu Mono developers and describes how the way they have split Mono on Debian/Ubuntu makes it so that replacing Rhytmbox with Banshee Media Player ends up consuming less space on Ubuntu's LiveCD (6 megs) and brings more features.
Nice to see that using managed code consumes less space and delivers more features. There is a heated debate on the comments as well.
Sandy Armstrong also posted an update on the desktop note-taking application Tomboy that now runs on Windows and MacOS X.
Sandy was just saying a few weeks ago that porting Tomboy to Windows brought new developers to the project. Although some people have historically been against the idea of making Linux software available on other platforms, it is nice to see day-to-day validation that by expanding the scope of our open source software to other platforms it directly improves the software in our own platform (as many predicted).
Common Compiler Infrastructure and Cecil.
Last week at Lang.NET 2009 conference the Common Compiler Infrastructure was open sourced under the terms of the MS-PL license.
This library was developed used internally at Microsoft some years ago to support some internal projects. This provides a set of services similar to our own Cecil library. Despite this, it is nice to see Microsoft open source more code.
Cecil, in addition to the low-level APIs for reading and writing ECMA CIL files has a few niceties layered on top of it like a Flowanalysis engine (it is used to decompile byte codes into ASTs) and a full fledged decompiler.
Additionally, Marek is currently replacing the backend in
our C# compiler to move away
from System.Reflection.Emit into using Cecil so
that we can bring our C# REPL to Windows developers.
Mono's C# REPL currently works in a very limited mode in
.NET (no generics, no LINQ) because
.NET's System.Reflection has several limitations
for building full-fleged compilers. To work around this issue
Mono has over the years extended the Reflection stack to
provide the features that were missing. We were never quite
happy with this and we are now dropping it in exchange for
Cecil.
JB, the creator of Cecil shares with us his take on Cecil and the CCI.
Job Posting: Mono Hacker Looking for a Job
A good friend of mine that has extensive experience with C# and has written significant portions of the Banshee media player, has contributed to our C# 3.0 and C# 4.0 support and to our runtime is looking for a programming job.
If you want to hire him, drop me an email and I will get you in touch with him.
Continuations in Mono: Embrace and Extending.NET, Part 3
Update: I accidentally published an incomplete version of this blog entry the other day before the actual content and samples were ready.
As part of our ongoing Embrace and Extend.NET series (SIMD, supercomputing), today I wanted to talk about the Mono.Tasklets library that has just landed on Mono's repository.
This library will become part of the Mono 2.6 release.
Mono.Tasklets is the Mono-team supported mechanism for doing continuations, microthreading and coroutines in the ISO CLI. It is based on Tomi Valkeinen's excellent work on co-routines for Mono.
Unlike the work that we typically do in Mono which is pure C# and will work out of the box in .NET (even our Mono.SIMD code will work on .NET, it will just run a lot slower) Mono.Tasklets requires changes to the VM that are not portable to other ISO CLI implementations.
History
Unity Early Experiments
Back in 2004 when Unity first started to explore Mono, Joachim Ante brought up the topic of coroutines in Mono. On an email posted to the mono-devel-list he stated:
I want to be able to write scripts like this:void Update () { Console.WriteLine ("Starting up"); //Yields for 20 seconds, then continues WaitFor (20.F); Console.WriteLine ("20 seconds later"); }The WaitFor function would yield back to unmanaged code. The unmanaged code would then simply go on, possibly calling other C# methods in the same class/instance. After 20 seconds, the engine would resume the Update method.
The idea here is to have multiple execution paths running on a single thread using a sort of cooperative multitasking. GUI programmers are already used to this sort of work by using callbacks: event callbacks, timer callbacks and idle callbacks. In Gnome using C or C# 1.0 you use something like:
void do_work ()
{
printf ("Starting up\n");
g_timeout_add (20 * msec, do_work_2, NULL);
}
void do_work_2 ()
{
printf ("20 seconds later\n");
}
Although lambdas help a little bit in C# 2.0 if the core of your application needs to chain many of these operations the style becomes annoying:
DoWork ()
{
Console.WriteLine ("starting up");
Timeout.Add (20 * msesc, delegate {
Console.WriteLine ("20 seconds later");
});
}
In event-based programming everything becomes a callback that is invoked by the main loop. The developer registers functions to be called back later in response to a timeout or an event.
Another alternative is to build a state machine into the callbacks to put all of the code in a single method. The resulting code looks like this:
void do_work (void *state)
{
MyState *ms = (MyState *) state;
switch (ms->state){
case 0:
printf ("starting up\n");
ms->state = 1;
g_timeout_add (20 * msec, do_work, state);
break;
case 1:
printf ("20 seconds later");
}
}
It is worth pointing out that Joachim and in general the gaming world were ahead of our time when they requested these features. This style of threading is commonly referred as microthreading or coroutines.
At the time, without runtime support, Rodrigo suggested that a framework based on a compiler-supported generator-based system using the yield instruction would satisfy Joe's needs for coroutines in the gaming space.
This is what Unity uses to this day.
C# Yield Statement in Mono
The yield statement in C# works by building a state machine into your method. When you write code like this:
IEnumerable DoWork ()
{
Console.WriteLine ("Starting up");
yield return new WaitFor (20 * msec);
Console.WriteLine ("After resuming execution");
}
The compiler generates a state machine for you. In the above example there are two states: the initial state that starts execution at the beginning of the function and the second state that resumes execution after the yield statement.
A year later we used a variation of the above by employing nested yield statements in C# to implement Mono's HttpRuntime pipeline stack.
Cute screenshot from my blog at the time:
Yield statements can be used to solve this class of problems, but they become annoying to use when every method participating in suspending execution needs to become an iterator. If any part of the pipeline is not built with explicit support for yield, the system stops working. Consider this:
void Attack()
{
DoTenThings ();
}
void DoTenThings()
{
for (int i=0; i < 10; i++){
C();
}
}
IEnumerable C()
{
yield WaitForIncomingMessageFromNetwork();
}
Here, even if the WaitForIncomingMessageFromNetwork uses yield the callers (DoTenThings and Attack) are not participating, they merely discard the return from yield, so the execution does not return to the main loop.
Using a yield-based framework is not much of a problem if you only need to use this every once in a while. For example we use this in our ASP.NET engine but it is only used in a handful of places.
Unity used an approach built on top of the yield framework to suspend and resume execution. For example this is invoked by the Update() function on an enemy script:
function Patrol() {
while(true) {
if (LowHealth ())
RunAway();
else if (EnemyNear ())
Attack();
else
MoveSomewhere();
yield; // done for this update loop!
}
}
function Attack () {
while (!LowHealth () && EnemyNear ()) {
DoTheAttack ();
// done with this update, and wait a bit
yield WaitForSeconds (attackRate);
}
// return to whatever invoked us
}
The same can be done in Unity with C#, but your functions should be declared as returning an IEnumerable.
Microthreading in SecondLife
In 2006, Jim from LindenLabs introduced the work that they had done in SecondLife to support microthreading.
Jim's work was a lot more ambitious than what both Joe had requested. SecondLife required that code be suspended at any point in time and that its entire state be serializable into a format suitable for storage into a database. Serialized state could then be restored at a different point in time or on a different computer (for example while moving from node to node).
For this to work, they needed a system that would track precisely the entire call stack chain, local variables and parameters as well as being able to suspend the code at any point.
Jim did this by using a CIL rewriting engine that injected the state serialization and reincarnation into an existing CIL instructions stream. He covered the technology in detail in his Lang.NET talk in 2006.
The technology went in production in 2008 and today this continuation framework powers 10 million Mono scripts on SecondLife.
Tomi's Microthreading Library
That same year Tomi posted a prototype of coroutines for Mono called MonoCo, inspired by the use of Stackless Python for EVE Online.
The Stackless Python on EVE presentation goes through the concepts that Tomi adopted for his Mono.Microthread library.
Tomi's approach was to modify the Mono runtime to support a basic construct called a Continuation. The continuation is able to capture the current stack contents (call stack, local variables and paramters) and later restore this state.
This extension to the runtime allowed athe entire range of operations described in the Stackless Python on Eve presentation to be implemented. It also addresses the needs of developers like Joachim, but is not able to support the SecondLife scenarios.
Mono.Tasklet.Continuation
The Mono.Tasklet.Continuation is based on Tomi's Microthreading library, but it only provides the core primitive: the continuation. None of the high-level features from Tomi's library are included.
This is the API:
public class Continuation {
public Continuation ();
public void Mark ();
public int Store (int state);
public void Restore (int state);
}
When you call Store the current state of execution is recorded and it is possible to go back to this state by invoking Restore. The caller to Store tells whether it is the initial store or a restore point based on the result from Store:
var c = new Continuation ();
...
switch (c.Store (0)){
case 0:
// First invocation
case 1:
// Restored from the point ahead.
}
...
// Jump back to the switch statement.
c.Restore (1);
Tomi implemented a Microthreading library on top of this abstraction. I ported Tomi's Microthreading library to Mono.Tasklet framework to test things out and I am happy to report that it works very nicely.
Tomi's patch and library were adopted by various people, in particular in the gaming space and we have heard from many people that they were happy with it. Not only they were happy with it but also Paolo, Mono's VM curator, liked the approach.
Frameworks
Speaking with Lucas, one of the advocates of Tomi's VM extensions, at the Unite conference it became clear that although the Mono.Microthreads work from Tomi was very useful, it was designed with the EVE scenario in mind.
Lucas was actually not using Mono.Tasklets on the client code but on the server side. And when used in his game the Stackless-like primitives were getting on his way. So he used the basic Continuation framework to create a model that suited his game. He uses this on his server-side software to have his server micro-threads wait for network events from multiple players. The Tomi framework was getting in Lucas' way so he created a framework on top of the Continuations framework that suited his needs. He says:
I found however, that what system you build on top of the core continuations tech, really depends on what kind of application you're building. For instance, I have a system where I send serialized "class ProtocolMessage" 's over the network. they have a questionID and an answerID, which are guids.in my code I can say:
// automatically gets questionID guid set. var msg = new RequestLevelDescriptionMessage(); someConnection.SendMessageAndWaitForAnswer (msg);the last call will block, and return once a message with the expected type, and matching answerID has been received. This is made to work because the SendMessageAndWaitForAnswer<T>() call adds itself to a dictionary<GUID,MicroThread> that keeps track of what microthreads are waiting for which answer. A separate microthread reads messages of the socket, and reads their answerID. it then looks to see if we have any "microthreads in the fridge" that are waiting for this message, by comparing the guid of the message, to the guid that the microthread said it was waiting for. If this is it, it reschedules the microthreads, and provides the message as the return type for when the microthread wakes up.
This is very specific to my use case, others will have things specific to their use cases.
Going back to the Joachim sample from 2004, using Tomi's code ported to Mono.Tasklets, the code then becomes:
void Update ()
{
Console.WriteLine ("Starting up");
//Yields for 20 seconds, then continues
Microthread.WaitFor (20.F);
Console.WriteLine ("20 seconds later");
}
The MicroThread.WaitFor will suspend execution, save the current stack state --which could be arbitrarily nested-- and transfer control to the scheduler which will pick something else to do, run some other routine or sleep until some event happens. Then, when the scheduler is ready to restart this routine, it will restore the execution just after the WaitFor call.
A sample from the game world could go like this:
prince.WaitForObjectVisible (princess); prince.WalkTo (princess); prince.Kiss (princess);
The code is written in a linear style, not in a callback or state machine style. Each one of those methods WaitForObjectVisible, WalkTo and Kiss might take an arbitrary amount of time to execute. For example the prince character might not kick into gear until the princess is visible and that can take forever. In the meantime, other parts of the game will continue execution on the same thread.
The Continuation framework will allow folks to try out different models. From the Microthread/coroutine approach from Tomi, to Lucas' setup to other systems that we have not envisioned.
Hopefully we will see different scheduling systems for different workloads and we will see libraries that work well with this style of programming, from socket libraries to web libraries to file IO libraries. This is one of the features that Lucas would like to see: Networking, File and other IO classes that take advantage of a Microthreading platform in Mono.
Boston .NET Users Group Presentation
Today both Joseph and myself are doing a presentation on Mono, Moonlight at the Boston .NET Users Group meeting in Waltham.
We will be demoing the Visual Studio integration and remote debugging capabilities of Mono as well as SuseStudio to go from an ASP.NET application into an appliance with a handful of clicks.
Monday Mystery: Poetry Showing up on my Surveys.
Yesterday I was pondering whether I should go to Lang.NET 2009 and unable to make a decision, I ran an online poll and asked people to vote on twitter:
In my survey I listed the pros and cons to give people a feeling of what I was up against.
The first couple of votes were not very helpful, I got 2 votes, one said yes, one said no.
Then another twenty or so votes came and the balance started to shift towards "go". Here is the final result:
And then something very strange happened, the comment section for the online poll started getting people's opinion in the form of poems or Haikus.
I copy pasted some of the poems below:
In my heart you will always be now in heaven i cant wait again to see
When I decided not to roam
I just stayed home
Got a lot done
Enjoyed some time in the sun
Listen to good talks with your friends
Before all the fun ends!
Catch up and learn about Google's V8
--Maybe you'll even get a date!
You should go because it will be a blast
Life is short, so make it last!
a haiku for miguel:
Improve your cv
Boston is lovely right now
Drink with nerdy folks
I can’t make up my mind.
I really am in a bind.
I can go to Lang dot net,
And my day will be set.
Or stay at home and work,
Like a common store clerk.
This choice will be easy.
Lang is where I will be.
Should I stay,
or should I go?
For every con,
there is a pro.
I could see old friends,
and make some new.
Or stay at home,
and get work done too.
I could learn about Second Life,
and Google's V-8.
And actually accruing miles
would really be great.
It would take a whole week.
And delay my work,
But learning something new
Is definitely a perk.
A programmer I am,
and a programmer I will be.
I think this great poem
made my mind up for me.
New friends
Old friends
Learning new things
And when you get back to Boston
You can have some baked beans
destroyer of days seven
bringer of travel expenses
Lang.NET
provider of lectures
connector of colleagues
Lang.NET
delayer of projects
impeder of family time
Lang.NET
programmer of dynamic C#
granter of Second Life
Lang.NET
Why go across the country to have a v8?
Because that's what .NET is 4.
Lang.NET
Kill time
or make new friends?
Lose a little time from work
or catch up with those you've fallen out of touch with?
Work can always wait Miguel
opportunity cannnot.
Another dollar for yet another day,
That is what they all used to say.
For Lang.NET 2009 I pine away
The cost to do it makes me say “Hey!”
Give me Second Life with which to play
If only I could go to the conference that way
I’d program it if C was their programming thang’
Let me help Miguel on what to do.
He's undecided...can't decide between the two.
If he goes to Lang. NET, work at home will pile high.
If he stays home to work, perhaps he'd cry.
He'd miss the chance to learn Second Life,
Or make new friends, maybe even find a wife!
So it costs a few bucks to get to there.
He'd blow it on something else other than air fare!
Make the reservations today and don't delay.
You'll have a good time....that's what I say!
Divided I stand
The opportunity to advance ahead
A week of talks and new friends await me
On my way to Lang.NET 2009.
One week gone,
Trekking across the country.
Putting all tasks aside,
I delay work
On my way to Lang.NET 2009.
In the end,
The journey made
Is better than the journey dreamed.
Oh the choice, to go or to stay
that is Miguel's question of the day!
Should he go, he would have a great time
Should he stay...he might save a dime!
Going he will learn about new things out there
Staying he might...get more work done fair.
The choice looks easy to someone like me
but then again I'm not Miguel....I'm Susie
Once when Miguel was feeling weak,
A conference looked to kill his week.
But opportunity there it seemed was rife:
A chance to master Second Life!
Miguel's Dilemma
Should I stay or should I go
The trip could be for not
But my gut says I should go
Money,work,time and home
Oh, well bye bye I go.....
knowledge is calling me to fill him up
my friends are quite expecting
there are also some guys I don't know that i have to spy on
who cares about work!
who cares if I hitchhike to Lang.Net!
home will always wait
across the country I will enlighten myself
To Lang.NET or not to Lang.NET ... that is the question.
Whether 'tis nobler to learn about great stuff
Like Second Life and dynamic C#,
Or consider it the death of
An entire week away from home,
Thereby missing out on the catching up with old friends.
What value, then, shall be given
This knowledge and friendship?
Is it greater than the cost of transport and per diem?
Only Miguel can truly tell.
Lang.NET
Lang.NET
Oh this decision should not make you fret
Think about the things that are great
Second Life! .NET 4 and Google V8!
These things are worth the week away
your delay in work, and your hit in pay
Think about the old friends you'll greet
And all the new ones that you will meet
The knowledge base you'll gain and learn
will help you back help you back home and what you earn
Lang.NET
Lang.NET
Looks like going is really your best bet.
Haiku:
While traveling sucks
Experience should be worthwhile
Go enjoy Lang.NET
There are times we can't resist
Pondering the things we've missed.
We vow, "Next time I won't be slow.
I'll just pick up myself and go.".
And when we're back, our money spent,
We often think, "I'm glad I went".
Lang.Net
Not a bad gig to get
Sure it's a road trip
And a work skip
A budget breaker
But 'cmon,
Ain't it grand to be a taker?
Lang.Net
Not a bad gig to get
Sure it's a road trip
And a work skip
A budget breaker
But 'cmon,
Ain't it grand to be a taker?
Miguel should fly cross country,
And not worry about the money.
The trip will be great,
You must learn about Google V8.
Leaving home for a week,
Does sound rather bleak,
But you'll chat with old pals,
And may meet some gals.
There is much to learn,
but conferences return.
If you stick to your guns,
keep your money in your pocket,
you'll have more in store
when next year rolls around.
So stand on solid ground!,
and in 2010 launch rocket.
Not quite sure why I got so many replies in the form of poems, and Google surveys do not track the IP address of the submissions, so I have no idea if these were all submitted by the same person or not.
Need to get to the bottom of this mystery.
Supercomputing Mono
Last year we did some work in Mono together with
Luis Ortiz to support 64-bit arrays in the VM.
What was interesting about this work is that even though the ECMA standard allows the index of arrays to be a long .NET on Windows64 does not support this and Java would require modifications to the bytecode format. Altering Mono became the natural choice for those looking to host very large arrays in an advanced and managed VM.
This means that you can continue to use your existing tools
to build applications, but when running under Mono you will
get to use those arrays without that pesky 2,147,483,648 upper
boundary.
Today Ian Dichkovsky (from N-iX)announced on the mailing list their work to bring Mono to the MIPS64 from SiCortex. This is based on the excellent work from Mark Mason that did the MIPS32 port.
SiCortex has an entry-level desktop computer with 72 MIPS processors and if you have the budget you can get modules with 5,832 processors. The MIPS processors helps them stay eco-friendly.
Telerik Announces Support for their ASP.NET controls on Mono!
Telerik is one of the most famous provider of controls for .NET. We have been working for the past few months with Telerik to make sure that their RadControls for ASP.NET AJAX product worked out of the box with Mono:
Today Telerik announced the availability of their product officially for Mono-based customers on Linux systems. From their press release:
Telerik, the leading vendor of development tools and components for the Microsoft .NET platform announced that RadControls for ASP.NET AJAX fully supports the Mono runtime environment, an open source .NET framework sponsored by Novell, tailored for development of Linux applications. The Telerik AJAX UI components is the first major commercial user interface (UI) suite to go cross-platform and allows developers to build rich .NET applications in a Linux environment. “This has been a long-awaited feature, which we have been quietly working on for quite some time. Over the past few months, we have been actively testing the compatibility of our RadControls for ASP.NET AJAX offering with Mono", said Hristo Kosev, Telerik CTO. "We are extremely happy that our joint work with Novell will allow customers to build compelling high-performance ASP.NET AJAX-based applications and run them on Linux using Mono 2.4.” The decision to work with Novell to extend the capabilities of RadControls over other platforms is in direct response to customer feedback and interest in Mono. Telerik and Novell are optimistic about the effect their partnership will have on the industry and the benefits it will bring to .NET developers.
Telerik is a major player in the control space in the .NET world and many developers turn to them for ready to use controls for their applications. Developers that were previously using Telerik products can now host their products on Linux servers.
Special thanks go to Marek Habersack in the Mono team who worked tirelessly to fix Mono's ASP.NET stack. Working with the Telerik folks was a pleasure. Telerik helped us by providing us access to their source code, their test suite and their QA team that made sure that their thousands of tests ran equally well on Mono as they did on Microsoft's .NET.
You can try the Telerik controls running on Mono at http://mono.telerik.com/.
MonoDevelop Support for ASP.NET MVC
Michael Hutchinson blogs about how to use the recently open sourced ASP.NET MVC framework with MonoDevelop. Go from installing MonoDevelop 2.0 to your first ASP.NET MVC application 3 minutes:
There are a few very simple steps:
- Go to Tools/Add-in Manager.
- Click "Install Add-ins".
- In ASP.NET select "ASP.NET MVC".
- Install.
- Select File/New Solution
- Select ASP.NET MVC project.
- Hit F5 (run) to run your first app:
This will give you basic templates and dialog boxes for solutions, views, controllers and master pages. The code uses Michael's recent implementation of the T4 engine.
Check Michael's Blog for a complete step-by-step setup.
The Add-in bundles Microsoft's recently open sourced ASP.NET MVC engine to run on top of Mono 2.4.
Kudos to Michael that created this add-in in his copious spare time. And kudos to the MonoDevelop team that created such a pleasant platform to extend.
Microsoft releases ASP.NET MVC under the MS-PL License
Microsoft's ASP.NET MVC is an extension built on the core of ASP.NET that brings some of the popular practices and ease of development that were popularized by Ruby on Rails and Django to the .NET developers.
Scott Guthrie ---the inventor of ASP.NET--- just announced that Microsoft is open sourcing the ASP.NET MVC stack under the MS-PL license:
I’m excited today to announce that we are also releasing the ASP.NET MVC source code under the Microsoft Public License (MS-PL). MS-PL is an OSI-approved open source license. The MS-PL contains no platform restrictions and provides broad rights to modify and redistribute the source code. You can read the text of the MS-PL at: http://www.opensource.org/licenses/ms-pl.html
These are incredibly good news. Worth dancing for!
I know that a lot of developers inside Microsoft worked to get this important piece of code released under the MS-PL to ensure that the users of ASP.NET could benefit from the code being open source. I know that at least Phil Haack, Scott Guthrie, Scott Hanselman, Dimitry Robsman, Rob Conery and Brian Goldfarb pushed for this.
I am psyched, not only because ASP.NET MVC is usable in Mono and the code is licensed under open source terms, but also because I strongly believe that the same innovation, rapid adoption and experimentation that has happened with the new wave of web stacks will come to ASP.NET MVC across all platforms.
The source code is available for download and we are hoping to integrate this into Mono shortly. Scott Hanselman has a nice blog entry on how ASP.NET MVC went from price-free to open-source free.
In Scott's PDF tutorial he discussed how to build applications with ASP.NET MVC using Visual Studio and how the Rails practices of not repeating yourself and convention over configuration are used by ASP.NET MVC.
We have developed a MonoDevelop add-in that provides a set of templates, dialog boxes and the tooling necessary to take advantage of ASP.NET MVC on Linux and MacOS X as well. Hopefully the experience will be very similar to Visual Studio.
It was only two weeks ago that we were sipping virgin pina coladas at Mix09:
CoreCLR Security Model
Mono is quickly approaching having a complete implementation of the CoreCLR security model for Mono. This is being developed primarily for use in Moonlight.
This new and simplified security model allows Moonlight to download and execute untrusted code and run it inside a sandbox. A full implementation requires Mono to have an executable image verifier (making sure the binary that we download follows all of the rules and does not try some funny business), an IL verifier that ensures that the code does not contain any unsafe operations and the sandbox system that ensures that the downloaded code only calls methods that it has permission to call.
Click for passable illustration of how the sandbox works.
MSDN has a short introduction to the sandbox and I blogged a long list of links to the original blog entries that documented it.
CoreCLR security can be customized using a handful of attributes. Instead of sprinkling our source code with the attributes and a gazillions #ifdefs we are using our Mono Linker and a few tools and configuration files to reshape our libraries to contain the necessary attributes required to secure the sandbox. We use a number of tools to automate this process and a manual auditing process to audit the results.
This is cool because this is a much simpler sandbox system than CAS ever was and our tools make it very simple for third parties embedding Mono into their applications to create their own sandboxes and reshape what is allowed or not allowed by the sandbox based on their specific needs.
The bad news: this sandbox is only available from trunk right now and will not be easily available until Mono 2.6.
Mono 2.4 and MonoDevelop 2.0 released
We just released two big projects we have been working on for quite a while.
Mono 2.4 is a much faster, scalable and tuned version of Mono, like you have never seen before. Major highlights from the previous release are documented in our release notes.
And MonoDevelop 2.0
And a brand new web site
I previously blogged about the list of all the new MonoDevelop 2.0 features. The most visible one is the integrated debugger both for Mono applications and for C-based applications (using GDB).
Dogfooding: In addition to all the nice features in MonoDevelop 2.0, Lluis migrated the web site for MonoDevelop from MediaWiki to the Mono-powered MindTouch Deki content management system.
Game Developers Conference
I am heading out to the Game Developers
Conference in San Francisco as an attendee after some
strong endorsments from some friends on tweeter.
If you are at the GDC or in San Francisco and would like to get together at some point drop me an email (miguel at gnome dot org). Or if there are any great hacker get-togethers for game developers, I would love to hang out with them.
I would not want to dissapoint, and as a one trick pony kind of person, I will likely be talking about Mono, Moonlight and the virtues of managed code to anyone willing to listen.
Looking forward to see what my friends have been up to. I can not wait to see the C# repl in a Unity/Web app.
Moonlight 1.9 and Ogg
As I mentioned on a previous post Silverlight 3 opens the doors for developers to plug their own Codecs into the Silverlight media pipeline.
Only a few hours later I read on twitter that Atsushi and Rolf has implemented not only the Ogg/Vorbis Codec for Silverlight 3, but also implemented the Silverlight 3 API in Moonlight:
This means that you can now use your Silverlight-based players to playback Ogg/Vorbis content. Theora and Dirac are still missing, but with the sample code that we now have, it is going to be merely a weekend hack to get it done. Fluendo has a nice implementation of both already in Java.
Update on May 6th, 2009: open source implementations of Dirac, Vorbis and adpcm now live in the mooncodecs module.
Update: link fixed.
You can see the sample in action in Atsushi's test page.
Like Jo said on IRC:
it also works on SL3 though. that's the bit that excites me, since it means we have proper cross-platform playback with Free codecs *today* working in most browsers that matter
In the words of Annie Hall: La de da.
Go Moonlight Go!
Hot Hot Hot: Silverlight 3 Pluggable Codec Architecture (OGG, Theora, Vorbis and Dirac).
Burried in the list of what is new in Silverlight 3 there is this gem:
Extensible media format support: With the new Raw AV pipeline, Silverlight can easily support a wide variety of third-party codecs. Audio and video can be decoded outside the runtime and rendered in Silverlight, extending format support beyond the native codecs.
What the above means is that with Silverlight 3 in addition to the built-in codecs for VC-1 and H.264 and the built-in containers (ASF and MOV) developers can plug an arbitrary audio or video codec and containers into the pipeline to support other formats like Dirac, vorbis, theora and the OGG container.
Both the codecs and the container parsers are authored using C# (or any other .NET supported language).
It would be nice to use Mono.SIMD where appropriate for these codecs. Mono.SIMD works out of the box on .NET, but it is hardware accelerated in Mono.
Atsushi at Novell has done some of the work to get an old C#-based Vorbis codec working with Silverlight 3. We will post more details when we have more information (the fix is on SVN).
Mono and the Google Summer of Code 2009
Once again, the Mono project will be participating in the fabulous Google Summer of Code.
This is a great opportunity for students that want to get involved with open source to contribute, learn and get paid for their work during the summer.
We have been very lucky in recruiting some great students in the past years and these students have taken on some very sophisticated tasks over the years. MonoTorrent, ParallelFX, FastCGI for mod_mono, WinForms designer and theming, Gendarme development, Gtk# widgets and much more.
We have posted some ideas for students to get started, but students that are passionate about Mono should feel free to pitch their own ideas.
We tend to pick students for advanced projects over the milder, simpler tasks.
This year, I am excited about a few special projects:
- Making the Mono VM use LLVM as a code generation backend.
- Porting Mono.SIMD to new architectures.
- ParallelFX updates.
- Using NVidia's VDPAU library to provide a new codec implementation in Moonlight to support VC-1/H.264.
- Managed (C#) implementations of Dirac and Vorbis as Silverlight 3 codecs.
- A Database designer Add-in for MonoDevelop to support DBML editing.
There are many more of course, but the above are the ones that are making me drool.
BareFTP
Christian just pointed me to BareFTP a graphical file transfer client that supports FTP, FTPS, SSH and SFTP protocols to transfer files.
I am a command line kind of person, but many of my friends like to use GUI clients for this.
Moonlight brings Playboy archives to Linux
Since yesterday's announcement that the Playboy archives would be hosted using Silverlight's DeepZoom folks have been hard at work getting the remaining Silverlight 2 features implemented in Moonlight.
Hot Off the Presses: Unity Goes to Windows
Unity has announced that their Unity 2.5 IDE is now cross platform and now works Windows in addition to MacOS.
Unity rebuilt the entire Cocoa-based UI that they had previously with a Unity-powered UI. The entire UI is now built in C# using the Unity built-in APIs (all the controls, views, widgets).
This is a little bit like a compiler compiling itself. This time it is an IDE built using the IDE itself
Lucas integrates csharp REPL into Unity
Lucas Meijer has integrated Mono's C# REPL into Unity.
Visit his post and check out the flash demo of the C# REPL in action.
Voices from Post-Saddam Iraq
My friend Victoria Fontan who works at the UN's University for Peace in Costa Rica just published the book from her research work on Iraq.
The book is Voices from Post-Saddam Iraq: Living with Terrorism, Insurgency, and New Forms of Tyranny. From the editorial reviews:
Even today, most Americans can not understand just why the fighting continues in Iraq, whether our nation should be involved there now, and how we could change our tactics to help establish a lasting peace in the face of what many fear will become a full-fledged civil war. In the book at hand, Victoria Fontan - a professor of peace and conflict studies who lived, worked and researched in Iraq - shares pointed insights into the emotions of Iraq's people, and specifically how democratization has in that country come to be associated with humiliation. Including interviews with common people in Iraq this work makes clear how laudable intentions do not always bring the desired result when it comes to international conflict and cross-cultural psychology. For example, Fontan explains, one might consider the comment of a young Shiite: "The greatest humiliation of all was to see foreigners topple Saddam, not because we loved him, but because we could not do it ourselves." This gripping text is focused on a new and growing area of human psychology - humiliation studies.
Please vote to have the book available on Kindle. I got a hardcopy, but I would love to travel with it instead.
Mono and Qt
The KDE folks have created some brilliant bindings for Mono and .NET called Qyoto.
But there is nothing like a polished application to really test the bindings. This week Eric Butler announced Synapse: an advanced Instant Messaging platform.
This is the first large application built with Qt/Qyoto/Mono and it is a beautiful application:
I had a chance to see Synapse live a couple of weeks ago in Seattle when we met Eric for dinner. Eric has written a very polished application. This is what love does to software.
Congratulations to Eric for the release of his app, to the Qymono crowd for creating these polished applications and Nokia/Trolltech for releasing Qt under the LGPL license.
Developers interested in doing Qyoto development with MonoDevelop can take advantage of the QyotoDevelop add-in that Eric created as well. This add-in generates code from the Qt Designers UI files (click for a screenshot).
Mono's Text Template Transformation Toolkit (T4)
At the ALT.NET Seattle conference I was introduced for the first time to the Text Template Transformation Toolkit. Also known as T4. T4 is built into Visual Studio and developers use TT to generate code from all kinds of data sources. This tutorial covers the basics.
T4 Support in MonoDevelop, with error reporting and document outline.
T4 is very much like ASP.NET in that code is mixed with output code. Additionally TT has access to data on its "host". This allows for some creative data extraction from the environments before it generates output.
To my surprise T4 thing is wildly used by lots of people. Daniel Cazzulino's company has a product just to improve Visual Studio's support for editing .tt files.
What really got me interested in T4 were the templates that Damien wrote to convert from DBML files into C# code that is suitable for use with Linq. A nice replacement for the SQLMetal tool.
I mentioned this -in passing- to Michael Hutchinson as he had been working on ASP.NET MVC support for MonoDevelop and there are some nice ASP.NET MVC T4 files out there.
In a week he implemented: the T4 command line tool, the MonoDevelop host (to support ASP.NET MVC) and he even added syntax highlighting to it (see the above screenshot).
We have also started using it to migrate the code that previously used assorted WriteLines to generate RPM files from Visual Studio/MonoDevelop projects into a nice T4 template:
Packaging Template
ALT.NET this weekend
My friend تلة جوزيف (Youssef) and myself will be heading out to Redmond for the ALT.NET Seattle event this weekend.
This will be my first ALT.NET conference and I do not know quite what to expect. Youssef keeps telling me "You should not prepare for this", but I feel like I should at least prepare something exciting to get the juices flowing for discussion.
Thoughts?
CoyoteLinux uses Mono for syadmin tools
Interesting find: Coyote Linux -a firewall in a box- configuration of Linux is using Mono and ASP.NET for its admin tools.
Web Admin
Here is the rationale for the switch to C#:
One of the biggest changes to this release of Coyote Linux is the use of C# as the primary development language used for most of the administration, configuration, and maintenance utilities. Previous implementations of Coyote Linux made heavy use of C, Pascal (namely Delphi), and Bash shell scripting for this purpose. The change is being made to C# after nearly 2 years of working with the language in a cross-platform setting which involved the use of both Red Hat Linux and Windows 2003/2008 servers. The ability to use a single development environment (in my case, Visual Studio 2008) and produce executables that will execute in unmodified form on both Linux and Windows has seriously put the “R” in RAD programming. I am still actively involved in projects that require the development of cross-platform utilities and am already paying for all of the necessary licenses to provide my company with a full array of software and hardware to develop applications that work in a mixed server OS environment.I have spent a great deal of time testing C# applications under Linux using Mono as the executing environment. While this is not necessarily the best choice for small, embedded hardware (486 / ARM class processing power) it works very well for anything using i686 or better technology. Another wonderful advantage of using this technology is the ability to run the same set of executables on both 32 and 64 bit hardware without the need for compatibility libraries to be installed. The installation of Mono dictates the 32/64 bit execution environment, preventing the need to recompile the full Coyote Linux software package.
Traffic
System.Shell.CommandLine does not belong in System.Core
Update: Justin Van Patten at Microsoft clarifies that the System.Shell.CommandLine API that was on the CTP for VS2010 will not be part of the final .NET 4.0. Instead better versions (similar in spirit to Mono.Options) will be made available in CodePlex in the future. Relief.
Update 2: Justin gave me permission to quote from his private email, which I include:
We are not shipping System.Shell.CommandLine in .NET 4. This was based on an intern project from a couple of years back that was mistakenly public in the .NET Framework 4.0 CTP. It wasn't a design that we were happy with and has been removed and will not be present in the next preview release.We have a *much better* command line parsing API, along the lines of Mono.Options, that we're planning to release on CodePlex later this year.
Today I was alarmed by a new API being introduced into .NET 4.0, the System.Shell.CommandLine which is being dumped into System.Core.
An introductory blog post shows a bloated, over-engineered, too rich in the OO, too poor in the taste look at the API. Not only it is a terrible API, it is being dumped right in the core of the framework on the System.Core assembly.
This is the kind of API that you get when the work is commissioned as opposed to be created as an act of love. This is what you get from a culture of process. Some PM figured out "We need command line parsing". And since it does not look like rocket science they assigned this to someone that had absolutely no interest in this task. And clearly nobody involved (the PM, the developer and the tester) fought back. They were forced to do this, and they came up with this aberration, hoping that the sooner they were done with this, the sooner they could move on with their lives.
Compare this with the labor of love from Jonathan Pryor and his Mono.Options library. This API was discussed publicly, it was adopted in a few applications and tried out, it was morphed to support Windows, Unix and GNU style command line options and the result shows what passion and love deliver when it comes to APIs.
Compare and contrast. This is the sample posted for on the blog above:
using System;
using System.Shell.CommandLine;
class Program
{
static void Main()
{
Console.WriteLine("Checks a disk and displays a status report.\n");
CommandLineParser cmd = new CommandLineParser();
cmd.AddParameter(CommandLineParameterType.String, "volume", ParameterRequirement.Required,
ParameterNameRequirement.NotRequired, "Specifies the drive letter.");
cmd.AddParameter(CommandLineParameterType.Boolean, "F", ParameterRequirement.NotRequired,
ParameterNameRequirement.Required, "Fixes errors on the disk.");
cmd.AddParameter(CommandLineParameterType.Int32, "L", ParameterRequirement.NotRequired,
ParameterNameRequirement.Required, "Changes the log file size to the specified number of kilobytes.");
try
{
cmd.Parse();
}
catch (ParameterParsingException ex)
{
Console.WriteLine(cmd.GetHelp());
Console.WriteLine(ex.Message);
return;
}
string volume = cmd.GetStringParameterValue ("volume");
bool fix = cmd.GetBooleanParameterValue("F");
int? logSize = cmd.GetInt32ParameterValue ("L");
Console.WriteLine("Checking volume {0}...", volume);
if (fix)
Console.WriteLine("Fixing errors...");
if (logSize != null)
Console.WriteLine("Changing log size to {0}...", logSize);
else
Console.WriteLine("Current log size: {0}", 1024);
}
}
This is the equivalent in Mono.Options. With Mono.Options you can take advantage of C# 3 features and make the code more succinct. An important style difference is that the policy is not limited by what can be poorly expressed by an enumeration but can be anything that can be expressed with a real language.
What is the point for "ParameterNameRequirement.Required" for example? This is essentially a bool option with a long name. The fundamental problem is not that it looks like someone left a turd on my source code or the fact that it is a glorified bool value. The problem is that enumerations and an OO structure will not give you the flexibility that is required for command line handling. This API would not be able to cope magically with conflicting options (either -a or -b can be used) or with options that are required if another option is set (if -v set, then -log is needed) or with custom parsing required after the basic command line options are parsed (consider a C compiler, -I and -L and -l options can be specified multiple times).
This is the equivalent code in Mono.Options. Notice that the policy can be enforced either outside of the parameter parsing (after the basic parsing has been done) or as each one of the delegates for the options:
using System;
using Mono.Options;
class Program {
static void ShowHelp (string msg, OptionSet p)
{
p.WriteOptionDescriptions (Console.Error);
Console.Error.WriteLine (msg);
}
static void Main (string [] args)
{
Console.WriteLine("Checks a disk and displays a status report.\n");
bool fix = false;
int logSize = 1024;
string volume = null;
OptionSet p = new OptionSet ()
.Add ("volume=", "Specifies the drive letter.", v => volume = v)
.Add ("f|F", "Fixes error on the disk", v => fix = true)
.Add ("l=", "Changes the log file size to the specified number of kilobytes",
v => logSize = int.Parse (v));
try {
p.Parse (args);
}
catch (OptionException)
{
ShowHelp ("Error, usage is:", p);
}
if (volume == null)
ShowHelp ("Error: must specify volume", p);
Console.WriteLine("Checking volume {0}...", volume);
if (fix)
Console.WriteLine("Fixing errors...");
if (logSize != null)
Console.WriteLine("Changing log size to {0}...", logSize);
else
Console.WriteLine("Current log size: {0}", 1024);
}
}
The number of lines is roughly the same, but one is an eye sore and limited. The other is both beautiful and extensible.
Both APIs are capable of more. But System.Shell.CommandLine will merely give you more enumerations with limited functions and you will end up rolling out your own if you want to do anything remotely interesting.
Mono.Options is more of an open ended, future-proof and extensible API. It is implemented as a single C# source file (1,112 lines of code) that you can use in your own projects (and even tune/modify), you can start using today and will work on .NET 2.0 and up, it is nicely documented. More examples: here, here and here.
System.Shell.CommandLine does not belong in System.Core. System.Core is a fundamental assembly that will be everywhere .NET is, and it will soon enough run into the same upgrade and maintenance restrictions that mscorlib has.
This API needs to be moved into CodePlex or be available as an unsupported "PowerOverEngineeredPack.dll".
MonoDevelop 2.0 Beta 1
Earlier this week we released the first beta
of MonoDevelop 2.0.
MonoDevelop 2.0 is a very ambitious release in terms of the new functionality available since the MonoDevelop 1.0 release back in March 2008. It is ambitious, but also very stable, we have had hundreds of people dogfood this new release of MonoDevelop during the entire development cycle.
There are a number of new features since MonoDevelop 2.0 that are worth calling out:
Built-in Debugger
MonoDevelop now has a built-in debugger. The debugger supports both debugging Mono-based applications as well as native applications using GDB.
While hovering over variables, you can explore the values of complex data structures:
Breakpoints and Tooltips
You can debug both at the source code level, or the generated assembly code:
Debugging the Mono Runtime
Auto-complete on the watch window:
Auto-complete in the watch window.
You can also attach to running processes, both native or Mono processes and debug them:
Process selector
For more information see our list of supported features.
Improved ASP.NET support
Our ASP.NET story is getting better. web projects are now compatible with Visual Studio 2008 and Visual Web Developer 2008 SP1.
Our ASP.NET text editor now offers code completion of tag, attributes, attribute values and event handlers is now supported for ASP.NET and various HTML DTDs. For example:
We also now have DOM breadcrumbs in the editor as you edit your file, and a nice DOM/Document outline for navigating your HTML and DOM documents.
The beta does not contain this feature, but we will be publishing an Add-in that will help you get your ASP.NET MVC projects up and running with minimum hassle by the time ASP.NET MVC ships.
New Text Editor
A new text editor, this text editor is written entirely in C# and replaces the GtkSourceView widget. This has allowed us to more easily add features to the editor and bring MonoDevelop to the 21st century. Some of the features in the new text editor include:
- Flagging errors with underlines on the fly.
- Change bars (track what changes are in your buffers).
- Incremental search.
- Code folding: Support for collapsing regions of text (#region), methods, classes.
- Themes for the editor.
- Source code split views.
- Transparent popups. Holding down the Control key when a completion popup is shown will make the popup transparent to make it easier to see the text that is underneath the popup.
- VI-mode support. We understand that some of our users would rather use VI keybindings than Emacs keybindings. VI support is here.
Source Code Editing
Intellisense now works for pretty much every piece of the C# 3 language. I am not supposed to use the word "Intellisense", but I just did.
Also, sagacious readers will have noticed that I sneaked in "3.0" in the above statement. MonoDevelop now understands the C# 3.0 syntax. A great companion to our award-winning C# 3.0 compiler.
Now, technically speaking we have not received any awards for our C# 3.0 compiler, but we should have, because we are awesome. And in fact, I will be arranging a dinner at my place this coming weekend where we will award prizes to the best pieces of technologies and our C# compiler is a nominee.
Notice how it also supports nice automatic generations of methods when you declare an event:
MonoDevelop is also aware of types, so for example, if you type "override" when entering a method, it will offer a list of methods that can be overwritten. O-M-G.
There are other cute features like MonoDevelop can stub out interface methods for you. O-M-G.
There are also a few features that we liked from editors like TextMate that should make it more suitable for managing web projects like the revamped "Go to File" dialog (invoke it with control-alt-o). It is now able to do acronym searches.
New XML Editor
The XML Editor from SharpDevelop has been fully integrated into MonoDevelop and improved. It supports code completion of tags, attributes and attribute values (available for registered XSD schemas). A range of schemas are supplied with MonoDevelop.
XML files can be validated using the built in schemas, and can have XSL transforms applied. in addition, XSD schemas can be generated from XML files.
For instance, it is currently used to allow editing of Silverlight XAML files and have auto-completion of XAML tags that are valid for Silverlight/Moonlight.
Project Improvements
We have switched to msbuild-style project files to increase interoperability with Visual Studio.
Support for opening multiple solutions at once, and support for Workspaces.
We now have cascading project policies. This is useful for example to use different coding styles depending on the project that you are working on.
Cascading Project Policies
Gtk# GUI Designer
You can now make your custom widgets available on the toolbox, by just adding the [ToolboxItem] to your widget.
My favorite one is that now constructed dialogs and windows expose the Gtk.UIManager as a field. It was previously hidden, and not possible to adjust the UI dynamically without much work.
Assembly Browser
There is no better way of learning an API than browsing the data types exposed and their relationships. A new Assembly Browser has now been included.
Assembly Browser
Switching
A cute little window pops-up when you press Control-Tab these days:
Vala Support
Support for the Vala programming language has been integrated:
Vala Support
The Future: MonoDevelop, the Cross Platform IDE.
We are very excited about this release, and there are a few areas in which we would like to improve MonoDevelop for future releases.
We want to bring MonoDevelop to Windows to be able to reach into more users and to help developers doing Gtk# development on Windows.
MonoDevelop on Vista.
We are also currently shipping a preview of MonoDevelop for the Mac, it is not yet ready as there are a few kinks that need to be sorted out on that platform, but we are working to resolve those issues. For example, we want to integrate with the Mac menu system, and to provide bindings that are familiar for Mac users. Here is a preview:
Super-Alpha-Preview of MonoDevelop on OSX.
Unity has stated that they will be making MonoDevelop the standard editor for Unity3D on MacOS.
Mono Runtime Debugging
We now have better integration of GDB with Mono. Information on how to use this is in Debugging with GDB in XDEBUG mode in our wiki.
This will be useful if you are debugging the Mono runtime, or debugging Mono embedded into an application new versions of Mono (for example debugging Moonlight).
This will give you symbols for managed code in stack traces, for example the bold text in this example are the managed frames. These would previously just be rendered as "????????" by gdb.
(gdb) xdb
(gdb) bt
#0 0x0000000040cd707e in Tests:pass_floats_doubles (a=100, b=101, c=102, d=103, e=104, f=105, g=106)
#1 0x0000000040cd6fd8 in Tests:test_721_sparc_float_argument_passing ()
#2 0x0000000040a6228a in (wrapper runtime-invoke) Tests:runtime_invoke_int (param0=0x0, param1=0x7fc05e5b0e00,
param2=0x0, param3=0x40cd6f80)
#3 0x00000000004219f7 in mono_jit_runtime_invoke (method=0x9daa70, obj=0x0, params=0x0, exc=0x0) at mini.c:4253
#4 0x00000000005c1d2c in mono_runtime_invoke (method=0x9daa70, obj=0x0, params=0x0, exc=0x0) at object.c:2399
#5 0x00000000005c39d7 in mono_runtime_invoke_array (method=0x9daa70, obj=0x0, params=0x0, exc=0x0) at object.c:3488
#6 0x00000000005cdc31 in ves_icall_InternalInvoke (method=0x7fc05c371be0, this=0x0, params=0x0, exc=0x7fff66729368)
at icall.c:3038
#7 0x0000000040cd6bee in (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (
this=0x7fc05c371be0, param0=0x0, param1=0x0, param2=0x7fff66729368)
#8 0x0000000040cd690c in System.Reflection.MonoMethod:Invoke (this=0x7fc05c371be0, obj=0x0, invokeAttr=0x0,
binder=0x0, parameters=0x0, culture=0x0)
#9 0x0000000040cd683b in System.Reflection.MethodBase:Invoke (this=0x7fc05c371be0, obj=0x0, parameters=0x0)
#10 0x0000000040a6275c in TestDriver:RunTests (type=0x7fc05e5b6dc8, args=0x0)
#11 0x0000000040a62380 in TestDriver:RunTests (type=0x7fc05e5b6dc8)
#12 0x0000000040a62354 in Tests:Main ()
#13 0x0000000040a6228a in (wrapper runtime-invoke) Tests:runtime_invoke_int (param0=0x0, param1=0x7fc05e5b0e00,
param2=0x0, param3=0x40a62340)
#14 0x00000000004219f7 in mono_jit_runtime_invoke (method=0x9576f0, obj=0x0, params=0x7fff66729600, exc=0x0)
at mini.c:4253
For people running the archer branch of gdb, there is a "mono mode" implemented in python for gdb, which offers additional features: http://anonsvn.mono-project.com/viewvc/trunk/mono/data/gdb/
Mono on Android, update
Koushik Dutta has posted two great updates on his blog about Mono running on the Android powered G1 phone. The code necessary to build Mono on Android is available at the androidmono page.
The first bit is his work to allow Mono code to call Dalvik code as well as the bridge to allow Dalvik/Java to call into .NET code. This is necessary to allow Mono-based applications to call into the phone API and integrate with the existing stack.
The second bit is a cute show of DLR-based IronPython running on the phone.
This of course means that with the bridge in place, any CLR or DLR-based language can access the functionality exposed in Dalvik.
Mono 2.0 - .NET Tool/Add-in of the Year
Jeff just pointed out to me that Mono 2.0 won the ".NET Tool/Add-in of the Year" award from the guys at developer.com.
Sweetness!
Linus does 25 things
Linus Torvalds does 25 things about me.
Moonshine
Now that Moonlight 1.0 is out, I should talk a little bit about Aaron Bockover's amazing Moonshine plugin.
Moonshine's About Box while playing HBO.com
Moonshine is a tiny plugin that registers itself with Firefox to render Windows Media streams and emulates the Windows Media Javascript API by redirecting it to Moonlight.
So when you visit a page that in the past used to embed the Windows Media Player (for example at HBO.com or at C-SPAN), instead you get a Moonlight-based rendering engine and uses Microsoft's Media Pack for doing the video and audio playback.
It is trivial to install it, just go to this page and click on the moonshine that is right for your platform.
Internally we referred to this project as "Pornilus" a homage to the Roman senator and patron of the arts from the 3rd century. And like Pornilus, we want to bring the arts to the people.
Cute fact: Pornilus/Moonshine will pick-up your Gnome theme and theme itself accordingly.
Oddly enough, there is no Wikipedia page for Pornilus yet. Someone needs to correct this.
Moonlight 1.0 goes live
Moonlight, the open source implementation of Silverlight
for Unix systems has officially reached its 1.0 level. We
are feature complete, we pass all the Microsoft regression
test suites and we shipped support for Microsoft's Media Pack
for x86 and x86-64 architectures.
Moonlight is available as a Firefox plugin that can be installed with a single click from the moonlight download page.
What is in Moonlight 1.0
Moonlight 1.0 contains our plugin that can be used in Firefox 2 and 3 on Unix systems using the X11 windowing system.
Moonlight 1.0 (and Silverlight 1.0) both come with a graphics pipeline, video and audio frameworks and a javascript bridge and neither one of them contains an actual execution environment. The execution environment is the browser's own Javascript engine. When developers build 1.0-based plugins they script all of the functionality using the browser's own Javascript engine.
The browser Javascript engine communicates with Silverlight (or Moonlight) through the Javascript API exposed by the plugin.
With Silverlight 2.0 and Moonlight 2.0 in addition to this model where the browser's Javascript drives the interaction a new model is available: the ECMA CLI execution system powers the actual execution of the code and will deliver performance anywhere between 20 to 300 times faster execution speed than even the most modern Javascript implementation if you use a strongly typed language like C# or Boo.
CNN's The Moment on Moonlight.
It is worth pointing out that Moonlight is provided both for 32 bit systems and 64 bit systems on the launch date.
We are also hoping to expand our reach to other Unix variants that use X11 like the various BSD systems and Solaris and make codecs available for those.
How we got here
The development of Moonlight has been a fascinating adventure. It all started at the Mix conference in May 2007 when Scott Guthrie introduced Silverlight 1.1. It was a bold move for Microsoft to embed the ECMA CLI into their Silverlight 1.0 plugin.
In my blog post called "Mix 07, Silverlight, Dynamic Languages Runtime and OpenSource". From that post you can see that I was already excited about the technology, and I could not wait to get this technology to Linux. The talk on the DLR at Mix 07 was also fascinating and got me interested in bringing this to Linux.
A few weeks after the DLR had been announced and open sourced, our team had it working on Linux with Mono and by the end of May I had cooked up enough to render a spinning video on the screen.
IronPython 3D visualization on Moonlight
It was during the dynamic language workshop at Microsoft that I had a chance to have dinner with Jason Zander and Scott Guthrie in an Indian restaurant in downtown Redmond. In this dinner they discussed some of the design tradeoffs in Silverlight and these would become part of our own implementation a few days later.
At Mix 2007 I had the chance to meet Marc Jalabert from Microsoft France. Marc invited me to the Remix event in Paris but did not take the invitation seriously until he offered us to demo Moonlight on Jun 21st.
Other than a spinning video and the DLR we did not really have much code so on May 31st I sent an email to the team and asked them to work on an intense 21-day hackaton to bring Silverlight 1.1 to life on Linux. By Jun 21st we had a demo working and we showed Silverlight 1.1 applications (with the CLR) running on Linux.
A few weeks passed by, and Jeff Jaffe from Novell asked me to present our Moonlight to Bob Muglia as part of the regular Microsoft/Novell interoperability meetings. After struggling with the video projector for what seemed like an eternity the Silverlight Chess and the Silverlight Airlines demo came up on the screen on Linux.
In the meantime, we were in love with our Moonlight engine, and we used to build desktop applications in addition to web applications.
After this meeting, I do not remember exactly how things happened as too much happened too quickly, but Microsoft and Novell agreed to collaborate on bringing Silverlight to Linux. We announced the collaboration on September 5th.
It was early on, at that dinner with Jason and Scott that the issue of how to properly license codecs for MP3, WMV and VC-1 had been discussed. We knew that we could implement the engine, but the question remained: how to get codecs to end-users in a fully licensed way. This and other problems had been already discussed and agreed on the collaboration agreement. Microsoft would develop, distribute and maintain their own Media Pack for Linux users and other Unix operating systems.
The entire media work involved hard work at every level, but it was worth the effort. We now have one of the best open source media pipelines implemented. And it will only get better with all the new features in Silverlight 2 for adaptive streaming.
The Immediate Future
We are now hard at work on Moonlight 2, and those of you interested in trying it out can do so by following the build instructions on our web site.
Silverlight 2.0 was a major upgrade from its original announcement Silverlight 1.1. It is more complete, more polished and has been future-proofed.
Microsoft has continued to help us all along in creating an open source implementation of Silverlight. They have open sourced the Microsoft DLR, the Microsoft MEF framework and the crown jewels: the Microsoft Silverlight Control Library and the Control Toolkit under the OSI-approved MS-PL licenses. Without this it would have taken years for us to catch up.
Up until two weeks ago we could not see much in the screen as a lot of Moonlight had inter-dependencies between various subsystems. But once Larry Ewing's layout system landed in our tree, magically many things started to come together.
You can try out yourself Moonlight with some very hot demos including CNN's The Moment, the Photosynth-based 3D browsing engine for Obama's Inauguration and of course the always amazing DLR demostrations.
Silverlight 3
Silverlight 2 is incredibly exciting, it is delicious and mindblowing. There is a lot of excitement about it, my favorite three sites on Silverlight 2 include:
- Silverlight News on twitter.
- Infragistics Quince: UX Patterns Explorer
- Information Visualization with Descry: a project do visualize information in interesting ways using Silverlight. The project is now open source.
Microsoft will be announcing the details about Silverlight 3 at their Mix conference in March in Las Vegas.
My wish list
I love Silverlight and the use of the CLR for building web applications. That is just how I am wired up.
I still personally wish that Silverlight 2.0 had a JSon interface to XAML, like the prototype that Chris Toshok did, or that Silverlight had a more fluent model for application deployment. I would like the XAP model to be entirely optional or non-existent for IronRuby or IronPython.
It is that time of the Quarter! Traveling to Microsoft.
When Joseph and myself head out to Redmond to meet with some folks at Microsoft about Moonlight.
This is a call for all cool cats at Microsoft that would like to get together and talk shop to drop me an email (miguel at gnome dot org) and we can schedule something.
XBox Division at Microsoft
For about a year I have been trying to find someone in the
XBox360 division at Microsoft that we can talk to about
bringing Mono to the XBox360 to allow C/C++ developers to
script their applications with the high performing C#, Boo or
the Iron* languages as opposed to interpreters.
A year ago Mono could not target the XBox360 as apparently this platform, like the iPhone, does not support JITing. Mono now supports full static compilation of .NET code into native code before deployment and we would very much like to bring this to the XBox360.
If you are a Microsofty and you know how to get a hold of someone on the XBox360 group in the Middleware division and you could hook us up, I would love if you could arrange an introduction.
Linux Outlaws Podcast
Last week the folks at Linux Outlaws interviewed me about Mono.
The idea was that someone on a previous episode apparently did not quite like Mono and they wanted to hear my take. In the end I am not sure that we even talked about their concerns, but it was a fun interview.
IronClad
The guys at Resolver Systems have released IronClad. IronClad is a library that allows IronPython to use any existing compiled CPython extension.
The new version has matured to the point that it is able to use CPython's numpy and pass its test suite.
It is lovely to see third parties start to test their code with Mono in addition to .NET as part of the release process. The code has been tested with Mono, and comes with Unix makefiles.
One Month of Email Gone
If you sent me an email in the last month, and you are waiting for me to reply, please resend your email.
I accidentally deleted all email since December 18th, 2008.
DekiWiki powers WhoRunsGov.Com
Aaron Fulkerson and his team
at Mindtouch have done
it again. This time they landed the Washington Post
new http://whorunsgov.com
project:
WhoRunsGov.com provides a unique look at the world of Washington through its key players and personalities. The site features concise profiles of influential political officials who shape government policy, including members of the new presidential administration, Pentagon officials, lawmakers, senior congressional aides and committee staff. The first several hundred profiles are being crafted by a newly created editorial team at the Washington Post Company, as well as a group of experienced outside contributors. Each profile provides in-depth information on an official’s policy experience, involvement in government decision-making, major policy positions, key associates, political affiliations, voting records, campaign and personal finance information, plus relevant news articles from around the Web.
Their Deki project has gone from the cutest Wiki system to a full collaboration platform.
Their press release has the details.
And as my readers have come to expect, yes, this is also built on top of Mono. Deki is not built with ASP.NET --Microsoft's web platform-- instead the engine is built on top of Mindtouch's Dream framework and the presentation layer is built on top of PHP.
Congraulations to Mindtouch on this important launch!
Cartoon Network's Kid's MMO and Mono.
The amazing Joachim Ante from Unity3D wrote me to tell me that Cartoon Network's new browser-based MMO for kids FusionFall has finally launched to the public.
Fusion Fall takes advantage of many new features in Unity3D for creating large worlds. I live blogged some of the details as Joachim presented them at the Unite Conference.
Unity uses the Mono runtime on both Windows and MacOS and it might become one of the largest deployment vehicles for the Mono VM.
There is an air of coolness in the fact that Mono is being used on Windows instead of .NET. And part of it has to do with the fact that Mono's open source engine allowed Unity to modify it to suit their very specific needs.
As I mentioned at my PDC talk, the .NET engine is fantastic, but up until Mono only Microsoft was in a position to reshape .NET into different forms (Silverlight and Mesh both use a special trimmed-down .NET called CoreCLR). I would love to see a world where people take Mono (or chunks of Mono) tune it and shape it to suit their needs.
Congratulations to the team at Unity for a job well done, and to the team that produced FusionFall. You can see the introduction video:
One thing that stands out in FusionFall is that it shows what a big creative budget can do with Unity.
Go Mono gaming, Go!
Linux and the Inauguration
Not only was the inauguration transmitted using Silverlight, but also on each window for everyone watching the inauguration from pic2009.org the following caption was at the bottom of every page:
Every viewer could see "Linux-compatible Silverlight Player".
Watching the Obama Official Inauguration on Linux with Moonlight.
I just wanted to confirm that you can watch
today's
Barack Obama
Official Inauguration video stream using Moonlight on
Linux/x86 and Linux/x86-64 systems.
All you need to do is to go to the Moonlight Download page, install Moonlight and restart your browser. Then you can visit www.pic2009.org in a few hours and watch the event from Linux.
Microsoft worked late last night to get us access to the code that will be used during the inauguration so we could test it with Moonlight.
Thanks to: Joseph, Larry, Geoff, Rusty and specially Aaron who all worked tirelessly to implement and get everything tested tonight and ready to go on the Novell side. To Brian, Eric, Ben at Microsoft and Mio at IStreamPlanet to make sure that Linux users will be able to watch Obama's inauguration.
Ben Waggoner has posted an update on the Microsoft side..
Aaron's code will also be powering MacOS/PPC streaming.
Now everyone say at once: O-ba-ma! O-ba-ma! O-ba-ma!
Mono's New Code Generation Engine
Three years ago, in November of 2005 we started a project to upgrade Mono's code generation engine as the engine started to age and it became increasingly difficult to improve code generation and extend the JIT engine in meaningful ways.
The new code generation engine is based on a linear intermediate representation as opposed to the tree-based intermediate representation that we had used up to Mono 2.0.
Switching the code generation engine is a pretty significant effort and we did not want to switch it shortly before we had to ship Mono 2.0, so we decided to ship 2.0 with the engine that had been in wide use.
Shortly after we branched Mono's tree for the 2.0 release Zoltan merged his work from the linear branch into the main tree.
We have now shipped all of this as part of Mono 2.2, you can get it here.
Some Benchmarks
Mono's new engine generates much better code than the version found in Mono 2.0.
Speed: The engine will mostly benefit computationally intensive code, usually between 10% and 30% performance increase, with some cases going up as high as being 50% faster.
Code size: the new engine generates slimmer code, typically 12% to 20% smaller code generated.
Check out some of the benchmark results.
Debugging the Transition
Although we had our test suite, and we regularly tested the code against most apps, we were still afraid that something might go wrong. The new code could miss-compile something, and it would be hard in a large project to pin point exactly what went wrong.
For example, the problem might not appear while compiling a small test program like `hello world', but could appear when running a web site under heavy load or when running MonoDevelop.
Zoltan came up with a very interesting solution: for a period of time Mono had two JIT engines built into it, the new and the old one. Here is where the clever trick comes in: an environment variable contained the number of methods that should be compiled with the new JIT engine. After the Nth method had been compiled, the engine would switch code generators.
This was used to bisect regressions and failures.
A couple of months after we had done the switch and both our unit tests and our system tests passed the old JIT engine was eliminated from Mono.
SIMD
Using SIMD for accelerating certain floating point operations had been in the back of our minds for a while. We looked into implementing that in our old engine, but that turned out to be very difficult.
With the new engine, Rodrigo was able to put together a prototype in a weekend (the legend goes that Rodrigo's wife was busy that weekend).
This prototype was later turned into Mono.SIMD an API for accelerating vector operations.
Mono 2.2 is the first release to officially support and distribute it. To learn more about Mono.SIMD support, you can see this blog entry.
Full Generics Sharing
With this release, the generics code sharing engine has been completely debugged and is now enabled not only for code that lives in mscorlib, but for all generics code written by the user.
The Technical Details
We have provided A complete description of Mono's new engine design and the the various code generation stages.
More Mono-based games on the iPhone
Randy Edmonds pointed out in my previous post that FlashBang Studios's RaptorCopter is not the first or the only Unity3D/Mono-based game on the Apple AppStore.
I counted almost 40 apps on the AppStore based on Mono, from the thread here.
These are a few other games available today from the AppStore that are powered by Mono:
- Downhill Bowling (5 stars), (screenshots and video).
- Billiards.
- SpacePig.
- Age of Curling.
- Dusktreaders.
- X-Razer.
- Tapball (video).
- InvinciBall (video).
- SlidePop.
- FuguMaze.
- Monkey Diving (video).
- Ball-X (with the dash in the middle, or you wont find it).
- FuguTilt.
- Pizza Dash (you deliver pizzas in a car).
- Debris (you do controlled demolitions).
- Trash it!
- Rotunda.
- Asteroid Strike.
- Crazy Snowboard (and 2.0).
- Bubble Bang (video).
- iStronaut Willy.
- Bounce Pop.
- Labyrinth 3D.
- FuguBall.
- SpaceRace (video).
- iDrone.
- Mars Explorer.
Word games:
- Christmas spell.
- Alpha Blocks: Brain Freeze.
Not really games, but cool hacks:
- Moobox 3D, cute!
- Widget Monkey.
- Butterflies.
- Dice 3D.
- Night Divine.
- Rainbow Day.
- Zen of Snow and Zen of Snow 2.
- Jingle Bells.
- ArtiFISHal Life (3D Aquarium).
- Leaves.
- iFeathers.
- Bobblehead Santa.
Update:
- Cricket (from SpinFast).
- Rock'em Blocks (video).
- Pelagic Tones.
First Mono-game hits the Apple AppStore
Blurst's Raptor Copter game built using Unity3D and Mono just hit the Apple AppStore.
From the announcement:
Raptor Copter has become our first Unity-made iPhone game to hit the App Store! We’re making it available for a limited-time price of $0.99. The game is a loose follow-up to Off-Road Velociraptor Safari. Instead of a jeep, you have a Chinook helicopter, but the basic game loop is the same: Capture raptors, drop them into factories, and teleport their sweet meats to the future.You can get it for your iPod Touch or iPhone from this Raptor Copter iTunes Link.
Cute video:
Unity3D is using Mono's full static compilation to allow the game to run JIT-less and interpreter-less on the iPhone.
First Mono-based Wii Game on the Shelves
Christian Lassmann from Weltenbauer Software
Entwicklung GmbH, who I had the pleasure of meeting at the
Unite Conference in Denmark in October, just wrote to tell me
that "My Animal
Center", a game built
with Unity3D's
Wii Edition and Mono hit the shelves on December 20th in
Germany.
The game uses C# extensively. It was a joy to hear Christian explain how the various effects were created, I wish he blogged about it.
Cute trailer (text is in German):
The game is coming to a Wii near you in the US soon.
Mono goes Accessible!
Brad Taylor has announced the first release of the Mono Accessibility stack:
UI Automation provides programmatic access to most user interface (UI) elements on the desktop, enabling assistive technology products such as screen readers to provide information about the UI to end users and to manipulate the UI by means other than standard input. UI Automation also allows automated test scripts to interact with the UI.
Mono's Accessibility Framework is an implementation of UI Automation. The same API that is available for WPF and the framework is used by Silverlight and Windows.Forms.
Client Code: The initial launch of Mono Accessibility adds accessibility support to applications built with Windows.Forms to be accessible.
Backend Code: The code has a bridge that talks to the existing ATK framework on Linux.
In the future the Mono Accessibility framework will be used in our own Moonlight 2.0.
Check the release notes, install from source or use OpenSUSE's 1-click install.
Mono Goes to Android
Koushik Dutta got Mono running on the Android-based G1 phone.
He posted a video of the phone compiling "Hello World" (he points out that it is slower due to Mono running from the SD card):
He also posted some performance and memory usage comparisons between Dalvik, Mono and Java/ARM. Short story: Mono does great!
There are some caveats on running Mono on the G1, see the comments on this post. Still, these are encouraging news.
F-Spot Extensions
Today I upgraded my F-Spot, I had not upgraded it since before the PDC.
It is now has a Picassa-like toolbar on the left:
And third-party extensions are starting to come out:
Mono brings Plastic's Windows.Forms UI to Linux and MacOS
Pablo has sent me these two screencasts of their Plastic SCM product running on Linux and MacOS using Mono 2.0's Windows.Forms support:
Plastic on Linux, the GUI toolkit is Windows.Forms with custom widgets and a nice color scheme.
Plastic has a nice graphical diff tool:
A preview of Plastic on MacOS X.
Cute graphs
More screenshots here.
Plastic is one of the finalists for this year's Jolt Awards.
Evolution wish-list: IMAP server built into the client
For a while I wanted to be able to get programmatic access to my email store in Evolution, just like it is possible to have programmatic access to the contacts and calendar through the Evolution Data Server.
The advantages of using IMAP as the protocol to talk to Evolution are simple: I can use any existing IMAP client library, or any other IMAP client to connect to my Evolution store. The protocol is well known, documented and the large ecosystem of IMAP clients makes it a natural feature.
There is also an application that I have in mind for it. I keep all of my email in Evolution, I download all of my email into my local hard disk so I can have all my information with me even when I am disconnected from the net. This means I can always check patches, review comments, discussions even when I am disconnected or with poor network connectivity.
But when I go on vacation, I do not want to bring my laptop or Evolution with me. Instead I end up using internet cafes to read my gmail and all of the other email addresses end up in Novell's server. Novell provides a convenient Web UI that I can use to read my email.
But the problem is that I end up reading emails twice: once in the road with the web UIs, and another time when I get back home and import all my email into Evolution.
By having Evolution expose an IMAP interface, I could use any IMAP client on the road, or ssh into my box and use mutt to read from the same email store that Evolution is keeping track of.
Visiting Microsoft
Joseph, Chris and myself are visiting Microsoft this week to learn more about Silverlight 3.0
If you are in town and have some time to meet to discuss open source, Mono, .NET, the CLI, the DLR or and whatever else you think we might have a fun conversation about, please drop me an email.
Moonlight goes 3D
Argiris Kirtzidi (one of the developers behind Managed OGRE) modified Moonlight to run inside the Ogre3D engine. You can render Moonlight applications or XAML files inside Ogre3D.
The Moonlight Calculator Example.
Your standard XAML tiger.
We are merging his patches to make it simpler for Moonlight to be compiled by Windows users.
Update:For more details about how this was done, and how he modified Cairo to be hardware accelerated check Argiris's post.
Groupwise Calendar to Google Calendar Exporter
I wrote a small tool that exports my Groupwise Calendar to Google Calendar.
This tool only runs on Windows as it is using the Groupwise COM APIs to fetch the calendar data. I would love to have this work on Linux if someone knows how to get to these from Unix.
You will need the Google Calendar assemblies (Google.GData.AccessControl, Google.GData.Calendar, Google.GData.Extenions) and the Groupwise Assemblies (GroupwiseTypeLibrary, GroupWiseCommander) and a text file that contains your passwords (called `passwords').
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Google.GData.Calendar;
using Google.GData.Client;
using Google.GData.Extensions;
using Google.Accounts;
using System.Threading;
using System.IO;
namespace CalendarExporter
{
class Program
{
const string google_email = "YOUR_EMAIL@gmail.com";
const string groupwise_login = "YOURNAME";
static void Main(string[] args)
{
var f = File.OpenRead("passwords");
var reader = new StreamReader(f);
var google_passowrd = reader.ReadLine();
var groupwise_password = reader.ReadLine();
new Thread(delegate() {
Thread.Sleep(1000 * 120);
Console.Error.WriteLine("Timing out");
Environment.Exit(1);
}).Start();
ClientLoginRequest login = new ClientLoginRequest();
login.AccountType = "GOOGLE";
login.Email = google_email;
login.Password = google_password;
login.Service = "cl";
login.Source = "YOURNAMECo-CalendarPush-1";
var token = login.Login();
CalendarService cs = new CalendarService("YOURNAMECo-CalendarPush-1");
cs.SetAuthenticationToken(token.Auth);
CalendarQuery cq = new CalendarQuery();
cq.Uri = new Uri("http://www.google.com/calendar/feeds/default/owncalendars/full");
CalendarFeed resultFeed = cs.Query(cq);
CalendarEntry gw_at_google = null;
foreach (CalendarEntry entry in resultFeed.Entries) {
if (entry.Title.Text == "Groupwise Calendar") {
entry.Delete();
break;
}
}
gw_at_google = new CalendarEntry();
gw_at_google.Title.Text = "Groupwise Calendar";
gw_at_google.Summary.Text = "This is the syncrhonized calendar at Novell's Groupwise server";
gw_at_google.TimeZone = "America/New_York";
gw_at_google.Hidden = false;
gw_at_google.Color = "#2952a3";
gw_at_google.Location = new Where("", "", "Boston");
gw_at_google.Selected = true;
Uri postUri = new Uri("http://www.google.com/calendar/feeds/default/owncalendars/full");
CalendarEntry cal = (CalendarEntry)cs.Insert(postUri, gw_at_google);
string calurl = cal.EditUri.Content;
int p = calurl.LastIndexOf ('/');
string code = calurl.Substring (p);
Uri edit_uri = new Uri ("http://www.google.com/calendar/feeds" + code + "/private/full");
GroupwareTypeLibrary.GWSession2Class gsc = null;
try
{
gsc = new GroupwareTypeLibrary.GWSession2Class();
}
catch
{
Console.WriteLine("Did not regsvr the file c:\novell\groupwise\gwcma1.dll and is this program x86-only?");
return;
}
var account = gsc.Login(groupwise_login, "", groupwise_password, null, null);
var path_to_host = account.PathToHost;
//alendar calendar = new iCalendar();
int count = 0, skipped =0;
foreach (GroupwareTypeLibrary.Message m in account.Calendar.Messages)
{
if (!m.ClassName.StartsWith ("GW.MESSAGE.APPOINTMENT"))
continue;
GroupwareTypeLibrary.Appointment2 app = (GroupwareTypeLibrary.Appointment2) m;
// Ignore appointments that are older than 15 days.
if (app.EndDate < DateTime.Now - TimeSpan.FromDays(7)) {
skipped++;
continue;
}
var ee = new EventEntry();
ee.Title.Text = app.Subject.PlainText;
ee.Content.Content = app.BodyText.PlainText;
ee.Locations.Add (new Where () { ValueString = app.Place });
ee.Times.Add(new When(app.StartDate, app.EndDate));
ee.EventVisibility = app.Private ?
EventEntry.Visibility.PRIVATE : EventEntry.Visibility.PUBLIC;
cs.Insert (edit_uri, ee);
}
Console.WriteLine("Done2");
Environment.Exit(0);
}
}
}
You will also need the Login.cs which is some sample code that I found on the tubes for doing Google Account authentication.
Moonlight 1.0 Beta 1
We have released the first beta of Moonlight 1.0.
This release supports the Microsoft Media Pack for playing back video and audio files. These are the same video and audio decoders that Microsoft uses in Silverlight 2.0.
Check our Moonlight roadmap for details on upcoming versions.
You can try some of the sites tests that we used to test Moonlight.
Here are some Silverlight 1.0 materials:
- How To Videos on Silverlight 1.0
- Essential Silverlight Training.
- Silverlight 1.0 Unleashed. This is my favorite Silverlight 1.0 book, one of the books that we used to get some of the Moonlight team members up to speed.
You can also read the Silvelright's XAML vocabulary description and its XAML Foundation Specification.
Moonlight's Media Stack
As part of the Moonlight Beta release, I wanted to devote a few blog posts to exploring the features in Moonlight and how we implemented those Silverlight features in Moonlight.
Before I get started on today's topic, we would like to get some feedback from our users to find out which platforms they would like us to support with packages and media codecs. Please fill out our completely platform and media codec survey.
Moonlight 1.0 is an implementation of the Silverlight 1.0 API. It is an entirely self-contained plugin written in C++ and does not really provide any built-in scripting capabilities. All the scripting of an embedded Silverlight component is driven by the browser's Javascript engine. This changes with the 2.0 implementation, but that is a topic of a future post.
The Silverlight/Moonlight Developer View.
One of the most important features of the Silverlight/Moonlight web plugin is to support audio and video playback.
Silverlight takes an interesting approach to video and audio playback. In Silverlight the video can be treated like any other visual component (like rectangles, lines) this means that you can apply a number of affine transformations to the video (flip, rotate, scale, skew), have the video be composed with other elements, add a transparency layer to it or add a clipping path to it.
This is the simplest incarnation of a video player in XAML:
<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<MediaElement x:Name="ExampleVideo"
Source="TDS.wmv"
Width="320" Height="240"
AutoPlay="true"/>
</Canvas>
The result looks like this when invoked with when embedded in a web page (or when using the mopen1 command that I am using to take the screenshots):
The MediaElement has a RenderTransform property that we can use to apply a transformation to it, in this case, we are going to skew the video by 45 degrees:
<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<MediaElement x:Name="ExampleVideo" AutoPlay="true" Source="TDS.wmv" Width="320" Height="240">
<MediaElement.RenderTransform>
<SkewTransform CenterX="0" CenterY="0" AngleX="45" AngleY="0" />
</MediaElement.RenderTransform>
</MediaElement>
</Canvas>
The result looks like this:
But in addition to the above samples, MediaElements can be used as brushes to either fill or stroke other objects.
This means that you can "paint" text with video, or use the same video source to render the information in multiple places on the screen at the same time. You do this by referencing the MediaElement by name as a brush when you paint your text.
This shows how we can fill an ellipse with the video brush:
<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<MediaElement x:Name="ExampleVideo" AutoPlay="true" Opacity="0.0" Source="TDS.wmv" Width="320" Height="240"/>
<Ellipse Width="320" Height="240" >
<Ellipse.Fill>
<VideoBrush SourceName="ExampleVideo"/>
</Ellipse.Fill>
</Ellipse>
</Canvas>
This looks like this:
You can also set the stroke for an ellipse. In the following example we use one video for the stroke, and one video for the fill. I set the stroke width to be 30 to make the video more obvious.
<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<MediaElement x:Name="ExampleVideo" AutoPlay="true" Opacity="0.0" Source="TDS.wmv" Width="320" Height="240"/>
<MediaElement x:Name="launch" AutoPlay="true" Opacity="0.0" Source="launch.wmv" Width="320" Height="240"/>
<Ellipse Width="320" Height="240" StrokeThickness="30">
<Ellipse.Fill>
<VideoBrush SourceName="ExampleVideo"/>
</Ellipse.Fill>
<Ellipse.Stroke>
<VideoBrush SourceName="launch"/>
</Ellipse.Stroke>
</Ellipse>
</Canvas>
Notice that in the examples above I have been using AutoPlay="true". Silverlight provides fine control over how the media is played as well as a number of events that you can listen to from Javascript for various events (for example, you get events for buffering, for the media being opened, closed, paused, or when you hit a "marker" on your video stream).
Streaming, Seeking and Playback
Depending on the source that you provide in the MediaElement, Moonlight will determine the way the video will be played back.
The simplest way of hosting a video or audio file is to place the audio or video file in a web server, and then have Moonlight fetch the file by specifying the Source attribute in the MediaElement. You do not need anything else to start serving videos.
Seeking on the standard Web server scenario: When the programmer requests the media to be played (either by calling the Play method on the MediaElement, or because the MediaElement has AutoPlay set to true) Moonlight will start buffering and play the video back.
If the user wants to seek backwards, or forward, Moonlight will automatically take care of this. In the case where the user fast-forwards to a place in the file that has yet to be downloaded, playback will pause until then.
Seeking with an enhanced media server: If your server implements the Windows Media Streaming HTTP extension if the user seeks to a point in the file beyond the data that has been downloaded, it will send a special message to the server to seek. The server will start sending video from the new position. The user will get the playback started immediately without having to wait. The details of the protocol are documented in the MS-WMSP specification. This is enabled by using the "mms://" prefix for your media files instead of using the "http://" prefix.
Notice that even if it says "mms", Silverlight and Moonlight do not actually speak to an MMS server, they merely replace that with "http" and speak http/streaming to the server.
The extension is pretty simple, it is basically a "Pragma" header on the HTTP requests that contains the stream-time=POSITION value. Our client-side implementation is available here.
You can use IIS, or use the mod_streaming to enhance the video experience for your end users.
This basically means that you can stream videos on the cheap, all you need is a Linux box, two wires, and a 2HB pencil.
Adaptive Streaming
Another cool feature of the Adaptive Streaming support in Moonlight is that the server can detect the client throughput, and depending on the bandwidth available, it can send a high bitrate video, or a low bitrate video. This is a server side feature.
This feature was demoed earlier this year at Mix 08:
I am not aware of an adaptive streaming module for Apache.
Supported Media Formats in Moonlight 1.0
Although Moonlight 1.0 exposes the Silverlight 1.0, Moonlight 1.0 ships a 2.0 media stack (minus the DRM pieces). This means that Moonlight ships with support for the media codecs that are part of Silverlight 2.0 and supports adaptive streaming. This is what we are shipping:
Video:
- WMV1: Windows Media Video 7
- WMV2: Windows Media Video 8
- WMV3: Windows Media Video 9
- WMVA: Windows Media Video Advanced Profile, non-VC-1
- WMVC1: Windows Media Video Advanced Profile, VC-1
Audio:
- WMA 7: Windows Media Audio 7
- WMA 8: Windows Media Audio 8
- WMA 9: Windows Media Audio 9
- WMA 10: Windows Media Audio 10
- MP3: ISO/MPEG Layer-3
- Input: ISO/MPEG Layer-3 data stream
- Channel configurations: mono, stereo
- Sampling frequencies: 8, 11.025, 12, 16, 22.05, 24, 32, 44.1, and 48 kHz
- Bit rates: 8-320 kbps, variable bit rate
- Limitations: "free format mode" (see ISO/IEC 11172-3, sub clause 2.4.2.3) is not supported.
We also support server-side playlists.
For more information see the Silverlight Audio and Video Overview document on MSDN.
Media Pipeline
When we first prototyped Moonlight we used the ffmpeg media pipeline. A media pipeline looks like this:
Charts by the taste-impaired.
Originally ffmpeg handled everything for us: fetching media, demultiplexing it, decoding it and scaling it.
Since we needed much more control over the entire pipeline, we had to write our own, one that was tightly integrated with Moonlight.
Today if you download Moonlight's source code you can build it with either the ffmpeg codecs or you can let Moonlight fetch the binary Microsoft Media Pack and use Microsoft's codecs on Linux.
Microsoft Media Pack
The Microsoft Media Pack is a binary component that contains the same code that Microsoft is using on their Silverlight product.
The Moonlight packages that we distribute do not actually have any media codecs built into them.
The first time that Moonlight hits a page that contains media, it will ask you whether you want to install the Microsoft Media Pack which contains the codecs for all of the formats listed before.
Today Microsoft offers the media codecs for Linux on x86 and Linux x86-64 platforms. We are looking for your feedback to find out for which other platforms we should ship binary codecs.
Tests
No animals were harmed in the development of the Moonlight Video Stack. To ensure that our pipeline supported all of the features that Microsoft's Silverlight implementation supports we used a number of video compliance test that Microsoft provided us with as part of the joint Microsoft-Novell collaboration.
In addition to Microsoft's own tests, we created our own set of open source tests. All of these tests are available from the moon/test/media module. This includes the videos that are specially encoded with all the possible combinations and features used as well as XAML files and associated javascript.
Mono on PowerPC 64
As part of SUSE 11, Mono needs to run on the PowerPC in 64 bit mode. The effort was bootstrapped with some early work from Andreas Faerber.
It was fun to watch Mark's daily commits progress of the port, the tests referenced here are the basic runtime tests that we use to check for regressions and to get a port up and running, it is a good roadmap for how a port comes to life:
* mini-ppc64.c, cpu-ppc64.md: Fixed some opcodes. PPC64 passes basic.exe now. --- * cpu-ppc64.md: Fixed a few instruction lengths. * mini-ppc64.c: Don't emit SETLRET. Now PPC64 passes basic-float.exe. --- * decompose.c: Decompose carry and overflow add on PPC64 like on other 64 bit archs. Don't decompose sub at all on PPC64. * mini-ppc64.c, exceptions-ppc64.c, tramp-ppc64.c, cpu-ppc64.md: Several fixes and new opcodes. Now PPC64 runs (but doesn't pass) basic-long.exe. --- * ppc/ppc-codegen.h: Use ppc_load_reg instead of ppc_ld in ppc_load_func to fix the 2 bit shift. --- * mini-ppc64.c, mini-ppc64.h, cpu-ppc64.md: Several fixes. Now PPC64 passes basic-long.exe. --- * ppc/ppc-codegen.h: Make ppc_is_[u]imm16() work with 64 bit values. --- * mini-ppc64.h, cpu-ppc64.md: Fixed caller/callee saved floating point regs. Now PPC64 passes basic-calls.exe. --- * mini-ppc64.c, mini-ppc64.h, exceptions-ppc64.c, tramp-ppc64.c, cpu-ppc64.md: Several fixes. PPC64 now runs objects.exe. --- * mini-ppc64.c, tramp-ppc64.c: Small fixes. PPC64 now runs arrays.exe and basic-math.exe. --- * mini-ppc64.c, mini-ppc64.h, exceptions-ppc64.c, cpu-ppc64.md: Several fixes. PPC64 now runs exceptions.exe and devirtualization.exe. --- * mini-ppc64.c: Several fixes. PPC64 now runs iltests.exe. --- * mini-ppc64.c, mini-ppc64.h, tramp-ppc64.c: Disable generic code sharing. PPC64 now passes generics.exe. --- * basic-long.cs: New test case. --- * mini-ppc64.c, mini-ppc64.h, tramp-ppc64.c, cpu-ppc64.md: Several fixes. PPC64 now passes most of the runtime regressions.
Followed by today's tweet:
The bootstrap means that the Mono JIT is actually doing a full build of Mono's compilers and class libraries and can be built on the target platform.
Update: Mark has posted a great picture of Jim Purbrick from Second Life, the man behind Mono running on Second Life.
Unity on Linux, First Screenshots
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.
Framework Design Guidelines, 2nd Edition
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).
Silverlight Toolkit, now MS-PL
Update: Fixed some links, corrected some text.
Shawn Burke announced the Silverlight Toolkit and it is licensed under the open source MS-PL. The code is available here complete with unit tests (check Ning's blog on the unit testing framework).
With the Silverlight Toolkit they are taking a new approach to shipping new controls in an effort to move swiftly and deliver the controls to people at the right time. Their previous approach was to ship the Toolkit when every component was ready, and completely fleshed out.
Now they will be shipping the Toolkit with controls that might have different levels of quality (and they are clearly flagged in the documentation). Shawn explains the new "Quality Bands" model that they are using in his post.
You can try the components on the web. The charting control can be tried out with the ChartBuilder (check David's blog for details on the ChartBuilder):
The source code for the Toolkit and the Controls is great to learn how to use Silverlight and it is great for people that need to tweak them for their own applications. When it comes to these controls, you no longer need Microsoft to make small changes for you or the small bug fixes that impact your application.
Themes: An interesting control container in Silverlight is the theming control. You wrap your code around this, and it will let you skin your control with XAML and define the animations and interactions with XAML and the Visual State Manager:
Some of these themes reminded me of the Gtk+ themes from 1998. Back in the days of Enlightenment and the "Cheese Pixmap" theme were hot. Mehdi explains how the themes work and Jafar explains the ImplicitStyleManager, the foundation for themes.
Shawn's Talk
Shawn's talk at the PDC was very interesting. I did not get to see it during the conference, but I watched it in the comfort of home (wmv, mp4 and slide deck).
Moonlight Updates
Last week we
branched Moonlight
for the 1.0 release, full with the licensed Microsoft Codecs
and started our release process for Moonlight Beta 1 to be
available in the next few days. This release is not yet
published on our web site, watch this space.
The Moonlight engine team has now resumed our work on Moonlight 2.0, the version that will track Silverlight 2.0.
In the meantime, while the GUI team was busy completing 1.0, the Mono core team has been working on the security framework for Moonlight, the networking stack (Silverlight allows Socket connections using policy files) and web services (System.ServiceModel, a subset of WCF).
The security system is the trickier and is the one that has received the most attention. We started early on last year in to implementing this, as we knew it would end up burning a lot of cycles to get it right.
Our hero has posted the initial work partition for the upcoming GUI work on Moonlight 2.0.
Moonlight is a blast, and who knows, maybe with our static compilation engine we might be able to deliver Silverlight on the iPhone.
Change.Gov
I wanted to thank everyone that helped get Barack Obama elected. Those that endorsed Obama passionately, those that videocasted, blogged, improved Obama's web site, donated to his campaign, wrote, discussed and voted on Tuesday to get him elected.
Barack does not only represent a change of direction for public policy, he is a truly brilliant candidate.
Some cool links on Barack:
- Larry Lessig: 20 minutes or so on why I am for Barack Obama.
- Tim O'Reilly's Why I Support Barack Obama.
- The Obama I know gives a glimpse of how Obama works.
- The Letter of Endorsement from 76 American Nobel Prize winners. winners.
- For the most cynics among us, you can watch the Chomsky on Obama interview which is as good as an endorsement as you can get from Noam.
- Beautiful pictures from the campaign trail from the Boston Globe.
I was surprised that the Obama campaign already launched their Change.Gov (thanks Nat) web site. You can now see how the team operates in real life, and you can share your story and you can share your vision of where America should go. The blog is here.
The above starts to deliver on the promise he had made during the campaign.
Got a cool collection of pictures about Obama or the reaction to the results? Please post it in the comments.
Inflamatory or misinformed comments will be deleted pronto.
Static Compilation in Mono
Another nice piece of technology that we showed at the PDC was static compilation, the feature behind allowing Mono to run on the iPhone in a fully legit way (no jail-breaking):
Screenshot from the Unity IDE.
Although Mono has supported batch compilation from CIL into native code in the past there was a small amount of code that was still generated dynamically. The intention originally was to help reduce startup and increase code sharing across multiple processes.
Code sharing is important once you have a handful of Mono processes running on the system. Instead of having to JIT the same code once per Mono instance for say "System.Console.WriteLine", the code laid out in essentially a shared object.
Our generated code uses many of the concepts found on the ELF file format to ensure that we can share code and that the code pages are read-only and not written to. This means that methods are invoked through a program linkage table instead of directly (to cope with the shared libraries being loaded at different addresses).
The Extra Mile
Although we are not certified XBox360 developers yet (we have yet to find the right person at Microsoft to talk to) we know from some of our users that have ported Mono to the XBox360 that JITing is not an option on that platform.
The XBox360 seems to have the same security-imposed limitations that the iPhone has, it is not possible for a Just-in-Time compiler to run in the platform as either the license terms or the kernel do not allow writable pages to become executable pages.
During the last few months we developed a static compilation mode for Mono. First we did this for the 1.0 profile, and now we are working on the 2.0 profile (so that we can support static compilation of generics). The work to support the 2.0 profile is reusing Mark's work on generic code sharing, which I found out to be a very nice synergy of efforts internally.
This means that it is now possible compile code from CIL to native code and not even ship the JIT compiler in your final program (saving some precious kilobytes from the final executable).
To do this, you must:
- Use Mono 2.0.1 at least.
- Request that Mono performs a full AOT compilation by using: mono --aot=full program.exe. That will generate your static executable. This executable still needs the runtime for things like garbage collection, threading and other runtime services.
- You then run your executable with Mono: mono --full-aot program.exe
- Optionally: build a new Mono on a separate location that removes the JIT engine by configuring Mono like this: configure --enable-minimal=jit. This will reduce your deployment by a few hundred Ks as the code generation and JIT engines are stripped out.
- Optionally: build a smaller set of libraries by using the Mono Linker (this is the tool that we use for turning Mono's 3.5 APIs into the Silverlight 2.0 APIs).
- Optionally: strip out the CIL code from the assemblies. We still require the assemblies for their rich metadata, but the actual CIL instructions can be safely removed. The new cil-strip tool built on top of Mono.Cecil can further shrink your deployed executables.
Developers interested in trimming down Mono can look into our documentation for more features that can be removed by using the --enable-minimal option.
Of course, once you remove the JIT you will not be able to use any dynamically generated code. This means no Reflection.Emit dynamically and at least for the time being or no IronPython/IronRuby.
John Lam told me at the PDC that they are looking into bringing static compilation for IronPython/IronRuby/DLR back, so this might just be a short-lived limitation.
For those interested in using Mono on the iPhone today the situation is a bit painful right now. You must run Mono on the target system to do the batch compilation and send the data back to assembly it on the host before you send the code back to the iPhone to run.
If you are wondering how did the demo go so smoothly at the PDC, the reason is that I was using Unity. Unity modified their local copy of Mono to be hardwired to do cross compilation to that exact platform. A more general purpose solution is needed to allow arbitrary platform-to-platform cross compilation, and we hope that this will be available in the future.
If you must quench your thirst for C# on the iPhone today your best choice is to use Unity's product and start building games instead of the enterprise application you always dreamed of.
From the Unity's Video Sample
If your boss demands that line of application running on the iPhone, you have a perfect excuse to learn the Unity gaming APIs and deliver the most glorious multi-touch, 3D-transformed line of business application to ever grace this world full with spinning AI for your "Sort By Customer Last Name" button.
C# 4.0: var, object and dynamic
Anders presentation on C# 4 was as usual great to listen to. He continues to evolve the language with solid steps, and the presentation was quite fun.
You can watch his presentation or just read the slide deck.
With C# 4 the new "dynamic" keyword has been introduced to flag a variable as a dynamic variable.
This is slightly different than var and object, the differences are as follows:
- "object x" is a shorthand for "System.Object x". This declares the variable x to have the type System.Object, this is strongly typed. And since C# provides autoboxing, you can assign anything you want to this variable.
- "var x = E" declares a variable x to be of the type of the expression E. The E is required, not optional. This is a strongly typed declaration, and you can only assign values whose type is typeof(E) to it.
- "dynamic x" declares the variable x to have dynamic semantics. This means that the C# compiler will generate code that will allow dynamic invocations on x. The actual meaning of "x.M" is deferred until runtime and will depend on the semantics of the IDynamicObject implementation.
Mono's SIMD Support: Making Mono safe for Gaming
This week at the Microsoft PDC we introduced a new feature in the Mono virtual machine that we have been working on quietly and will appear in our upcoming Mono 2.2 release (due in early December).
I believe we are the first VM for managed code that provides an object-oriented API to the underlying CPU SIMD instructions.
In short, this means that developers will be able to use the types in the Mono.Simd library and have those mapped directly to efficient vector operations on the hardware that supports it.
With Mono.Simd, the core of a vector operations like updating the coordinates on an existing vector like the following example will go from 40-60 CPU instructions into 4 or so SSE instructions.
Vector4f Move (Vector4f [] pos, ref Vector4f delta)
{
for (int i = 0; i < pos.Length; i++)
pos [i] += delta;
}
Which in C# turns out to be a call into the method Vector4f.operator + (Vector4f a, Vector4f b) that is implemented like this:
Vector4f static operator + (Vector3f a, Vector3f b)
{
return new Vector4f (a.x+b.x, a.y+b.y, a.z+b.z, a.w+b.w);
}
The core of the operation is inlined in the `Move' method and it looks like this:
movups (%eax),%xmm0 movups (%edi),%xmm1 addps %xmm1,%xmm0 movups %xmm0,(%eax)
You can see the details on the slides that I used at the PDC and look at the changes in the generated assembly, they are very large.
Ideally, once we tune the API based on our user feedback and contributions, it should be brought to ECMA for standardization. Hopefully we can get Microsoft to implement the SIMD support as well so all .NET developers have access to this.
Making Managed Code Viable for Gaming
Many developers have to resort to C++ or assembly language because managed languages did not provide the performance they needed. We believe that we can bring the productivity gains of managed languages to developers that seek high performance applications:
But even if you want to keep using your hand-tuned C++ game engine, the SIMD extensions will improve the performance of your scripting code. You can accelerate your ray casting operations by doing all the work in the managed world instead of paying for a costly managed to unmanaged transition and back.
You can avoid moving plenty of code from C# into C++ with this new functionality.
Some SIMD Background
Most modern CPUs contain special instructions that are able to perform arithmetic operations on multiple values at once. For example it is possible to add two 4-float vectors in one pass, or perform these arithmetic operations on 16-bytes at a time.
These are usually referred to as SIMD instructions and started showing up a few years ago in CPUs. On x86-class machines these new instructions were part of MMX, 3DNow or the SSEx extensions, on PowerPC these are called Altivec.
CPU manufacturers have been evolving the extensions, and newer versions always include more functionality and expand on the previous generations.
On x86 processors these instructions use a new register bank (the XMM registers) and can be configured to work on 16 bytes at a time using a number of possible combinations:
- byte-level operations on 16 elements.
- short-level operations on 8 elements.
- single precision or integer-level operations on 4 elements.
- double precision or long-integer operations on 2 elements.
The byte level operations are useful for example when doing image composition, scaling or format conversions. The floating point operations are useful for 3D math or physics simulations (useful for example when building video games).
Typically developers write the code in assembly language to take advantage of this feature, or they use compiler-specific intrinsic operations that map to these underlying instructions.
The Idea
Unlike native code generated by a compiler, Common Intermediate Language (CIL) or Java class files contain enough semantic information from the original language that it is very easy to build tools to compute code metrics (with tools like NDepend), find bugs in the code (with tools like Gendarme or FxCop, recreate the original program flow-analysis with libraries like Cecil.FlowAnalysis or even decompile the code and get back something relatively close to the original source code.
With this rich information, virtual machines can tune code when it is just-in-time compiled on a target system by tuning the code to best run on a particular system or recompiling the code on demand.
We had proposed in the past mechanisms to improve code performance of specific code patterns or languages like Lisp by creating special helper classes that are intimately linked with the runtime.
As Mono continues to be used as a high-performance scripting engine for games we were wondering how we could better serve our gaming users.
During the Game Developer Conference early this year, we had a chance to meet with Realtime Worlds which is using the Mono as their foundation for their new work and we wanted to understand how we could help them be more effective.
One of the issues that came up was the performance of Vector operations and how this could be optimized. We discussed with them the possibility of providing an object-oriented API that would map directly to the SIMD hardware available on modern computers. Realtime Worlds shared with us their needs in this space, and we promised that we would look into this.
The Development
Our initial discussion with Realtime Worlds was in May, and at the time we were working both towards Mono 2.0 and also on a new code generation engine that would improve Mono's performance.
The JIT engine that shipped with Mono 2.0 was not a great place to start adding SIMD support, so we decided to postpone this work until we switched Mono to the Linear IL engine.
Rodrigo started work on a proof-of-concept implementation for SIMD and after a weekend he managed to get the basics in place and got a simple demo working.
Beyond the proof of concept, there was a lingering question: were the benefits of Vector operations going to be noticeably faster than the regular code? We were afraid that the register spill/reload would eclipse the benefits of using the SIMD instructions or that our assumptions had been wrong.
Over the next few weeks the rest of the team worked with Rodrigo to turn the prototype into something that could be both integrated into Mono and would execute efficiently (Zoltan, Paolo and Mark).
For example, with Mono 2.2 we will now align the stack conveniently to a 16-byte boundary to improve performance for stack-allocated Mono.SIMD structures.
So far the reception from developers building games has been very positive.
Although today we only support x86 up to SSE3 and some SSE4, we will be expanding both the API and the reach of of our SIMD mapping based on our users feedback. For example, on other architectures we will map the operations to their own SIMD instructions.
The API
The API lives in the Mono.Simd assembly and is available today from our SVN Repository (browse the API or get a tarball). You can also check our Mono.Simd documentation.
This assembly can be used in Mono or .NET and contains the following hardware accelerated types (as of today):
Mono.Simd.Vector16b - 16 unsigned bytes Mono.Simd.Vector16sb - 16 signed bytes Mono.Simd.Vector2d - 2 doubles Mono.Simd.Vector2l - 2 signed 64-bit longs Mono.Simd.Vector2ul - 2 unsigned 64-bit longs Mono.Simd.Vector4f - 4 floats Mono.Simd.Vector4i - 4 signed 32-bit ints Mono.Simd.Vector4ui - 4 unsigned 32-bit ints Mono.Simd.Vector8s - 8 signed 16-bit shorts Mono.Simd.Vector8us - 8 unsigned 16-bit shorts
The above are structs that occupy 16 bytes each, very similar to equivalent types found on libraries like OpenTK.
Our library provides C# fallbacks for all of the accelerated instructions. This means that if your code runs on a machine that does not provide any SIMD support, or one of the operations that you are using is not supported in your machine, the code will continue to work correctly.
This also means that you can use the Mono.Simd API with Microsoft's .NET on Windows to prototype and develop your code, and then run it at full speed using Mono.
With every new generation of SIMD instructions, new features are supported. To provide a seamless experience, you can always use the same API and Mono will automatically fallback to software implementations if the target processor does not support the instructions.
For the sake of documentation and to allow developers to detect at runtime if a particular method is hardware accelerated developers can use the Mono.Simd.SimdRuntime.IsMethodAccelerated method or look at the [Acceleration] atribute on the methods to identify if a specific method is hardware accelerated.
The Speed Tests
When we were measuring the performance improvement of the SIMD extensions we wrote our own home-grown tests and they showed some nice improvements. But I wanted to implement a real game workload and compare it to the non-accelerated case.
I picked a C++ implementation and did a straight-forward port to Mono.Simd without optimizing anything to compare Simd vs Simd. The result was surprising, as it was even faster than the C++ version:
Based on the C++ code from F# for Game Development
The source code for the above tests is available here.
I use the C++ version just because it peeked my curiosity. If you use compiler-specific features in C++ to use SIMD instructions you will likely improve the C++ performance (please post the updated version and numbers if you do).
I would love to see whether Johann Deneux from the F# for Game Development Blog could evaluate the performance of Mono.Simd in his scenarios.
If you are curious and want to look at the assembly code generated with or without the SIMD optimizations, you want to call Mono's runtime with the -v -v flags (yes, twice) and use -O=simd and -O=-simd to enable or disable it.
Presentation
You can watch the presentation to get some color into the above discussion or check it in the Silverlight player, Get it as PDF, or PPTX.
Mono and .NET talk at PDC video.
The PDC 2008 was a blast. It was a privilege to be able to present Mono to all of these developers.
Joseph Hill helped me prepare my presentation for the PDC. Our goal was to explore how Mono could help .NET developers, but we did not want to go down a laundry list of features, or a list of APIs, or rehash what the advanced audience at the PDC already knew.
The idea was to pick a couple of interesting innovations from Mono and try stitch a story together. I discussed our embeddable C# compiler (which we need to start calling "Compiler Service"), some applications of Mono in gaming, our recent SIMD extensions and using Mono on the iPhone.
As for me, I am catching up on all the sessions I missed this weekend. All of the videos and slide decks are available for free from the Microsoft PDC site, and republished in Channel9.
In the next few days I will blog in more detail about each topic.
Interactive GUI Shell
This week at the Microsoft PDC I showed gsharp, our GUI repl for the C# 3.0 language, a tool that I had previously talked about.
Before the PDC we copied an idea from Owen's great reinteract shell where we provide our REPL with a mechanism to turn objects into Gtk.Widgets which we then insert.
Out of the box we support System.Drawing.Bitmap images, we turn those into Gtk Widgets that then we render:
I also added a toy Plot command that can take a number of lambdas that return floats to do some cute plots. The plots are just rendered into a System.Drawing.Bitmap so they get painted on the screen automatically:
But you can add your own handlers for any data types you want, all you have to do is call RegisterTransformHandler with a function that can return a Gtk.Widget based on an input object, or null if it does not know how to render it.
The implementation to render images is very simple, this is the implementation:
using System;
public class MyRenderHelpers {
public static object RenderBitmaps (object o)
{
System.Drawing.Bitmap bitmap = o as System.Drawing.Bitmap;
if (bitmap == null)
return null;
return new BitmapWidget (bitmap);
}
}
You can put your own library of helper methods in a compiled assembly in ~/.config/gsharp, and then register all of your types from a file ending with the extension .cs in ~/.config/gsharp:
RegisterTransformHandler (MyRenderHelpers.RenderBitmaps);
And you are done.
The above could be used for example to create all kinds of information visualizers for the GUI REPL. I would love to see a LINQ query navigator, similar to the one in LinqPad.
Update: A one line change that brings gsharp into the new millenium by rendering `true' and `false' with icons instead of text:
In LA for the Microsoft PDC
After a great week in Copenhagen with the Unity community I spent 14 hours on a high-tech tin can flying to LA for the Microsoft PDC conference.
Mono Talk
I am doing a talk on Wednesday at 4:45 in room 515B.
Unlike previous talks that I have done about Mono, this is an advanced talk and will skip over all the generalities and go straight to Mono CLI/C# features and innovations.
I decided against talking about Moonlight or APIs, as information about can be better learned elsewhere.
Speculation
There has been enough leaked information that we know some bits about C# 4. Some guess it includes dynamic support, other that it will be more F#-like and add immutability, others that it will introduce some Alef-like threading capabilities.
Then there is talk about .NET 4, and I just have no clue what they will announce.
So what do you think they are announcing this week?
Speculate away in the comments.
Live Blogging from Unite
I am live blogging from Unite, the Unity3D conference, one of the most fun users of Mono.
Announcements
Next UnityEditor will run on Windows, and its rewritten in C# (it originated on MacOS, and is now moving to Windows).
Unity as of today ships for building games on the iPhone. These are fully legit binaries, no need to crack your iPhone, they are using Mono's batch compilation to generate static binaries with no JITing involved (per Apple licensing requirements).
Side Note
Since I am a Linuxista, you might be wondering why I am so excited about Unity. Of course I am excited because they use Mono, but I am also excited because Novell is working with Unity to bring this to Linux:
erandi$ uname -a Linux erandi 2.6.25.16-0.1-pae #1 SMP 2008-08-21 00:34:25 +0200 i686 i686 i386 GNU/Linux erandi$ ls -l unity-linux/build/LinuxPlayer -rwxr-xr-x 1 miguel users 45735629 2008-10-12 00:37 unity-linux/build/LinuxPlayer*
We do not have a timeline yet, please do not spam the Unity guys with requests, stay tuned to this blog for updates.
FusionFall pre-mortem
12:17am Joachim explains their strategy with the web plugin and how they will cope with multiple versions of it as time goes by.
12:06am Cartoon Network will drive a lot of the plugin penetration.
11:50am Joachim is showing profiling information (particle, physics, the top scripts, time taken per frame).
The game went from 2gigs to 300megs by using some interesting compressions fo meshes and animations.
All of the features that were added for FusionFall are being folded back into the future Unity 2.5.
Pics: I wish I had brought my USB cable to post pictures from the camera. I will try to spice up this post tonight with the photos.
11:45am Runtime World Streaming: scenes are dynamically loaded and unloaded base on the player position in the world, the world is made up of a 16x16 grid. Scene loading happens when a player approaches a boundary in the world.
11:40am The Unity guys are talkng about the challenge of converting the assets from Gamebryo to Unity, the volume was large (25k files of Gamebryo data, which was constantly changing and growing).
They added support to Unity to interoperate with the Gamebryo and Cartoon Network data and wrote plenty of C# importing scripts and tools.
11:30am FusionFall talk by Joachim Ante.. FusionFall is a project that was done for the Cartoon Network.
It is an MMO with platform game elements.
It has a huge streaming world, so there are no pauses as you navigate the world. The game is targetted at kids (8-14).
The game was produced by Cartoon Network and developed by Grigon Entertainment, a team of 40 developers, 10 of them programmers, and has been under development for 3 years. Originally this was Windows-only standalone executable, developed with Gamebryo.
The cycle at some point included the prototyping done in Unity, shipping the executable to engineering, and engineering reimplementing in Gamebryo. They realized that they could turn the prototype as the actual client and that they could just communicate to their backend server. This allowed them to switch the entire game from Gamebryo to Unity.
Originally the standalone game was 2gb in size (lots of music, voice overs, terrains). This was a problem for kids, since they are not going to wait for 2 gigs to download, this was a big barrier to entry.
Unity's web based distribution and the strong world-streaming features were a good match for this project. This allowed Cartoon Network to give a great experience.
The entire MMO was ported in four months by a team Grigon developers and four Unity engineers working with them. They were on a very tight schedule. Four developers at Grigo ported the game client from C++ to C#.
Keynote
10:52am Interesting overview of the challenges of the game industry. Where does the game industry go next? A discussion on integrarting games with the web and delivering games as services.
On one end there is the flashy stuff, on the other end lots of talk about the enterprise components of gaming. I had no idea.
Between the low-barrier to entry and the high-barrier to entry markets, there is a large space for gaming and where 3D games on the browser will make a difference.
Phil sees Unity as an agent that will help transform the game industry.
10:31am Phil Harrison president of Atari is now on stage, "First time I have done a presentation in a Planetarium". Atari has no commercial relationship with Unity or investing-wise. He is here because "I wanted to be here, what David and his team are doing is transformational for the industry. I had an Eureka moment early this year, I had just joined Atari, and someone told me `check out Unity3d.com', I had heard about it, but never used it. Using the Web player demo was eye opening for me. [...] This is something similar to what I saw at Sony in 1993, when we first got the dinosaur demo on the PS1 [...] The island demo I believe is a game changer in this industry".
"I have become an unpaid evangelist of Unity".
Phil is now going to talk about the game industry, wont blog that.
10:29am Introspection, why we want to do this? Goals: we want people to build games for the web, the iPhone, the Wii, and for everything else.
10:29am Announcing Indie version, 199 dollars, but has some watermark/splashscreen at the beginning.
10:26am Windows Vista logo on screen.
"This is true, I have to admit it", they are demostrating the new Unity3D IDE on Unix. The same Unity3D tool but now running on Windows.
"We are going completely cross platform", every script that you write will run on both platforms (Woohoo! Go CIL! Go!).
10:21am Nicholas is going to talk about "Secret Labs". He talks about "Jus t Press Play", "Buliding for multiple targets" and the script property editor.
They wanted to improved upon th eUnity editor.
They rewrote the Unity editor from zero. Created entirely on top of the Unity APIs themselves - EditorWindows, unityGUI, GameObjects and Components. Unity is built on Unity now. "It is way faster than cocoa".
He is showing Unity 2.5, looks like Unity 2.1; They now use tabs and the various windows can be dragged around, very much like MonoDevelop. He is showing the editor by dragging a lightpost into a paradise island and showing the new GUI tools like snapping, rotation and UIs that are closer to Maya's tools.
He shows "Snap to surface" so you can easily position stuff on the 3D terrain. People like it.
The UI is a lot easier to use. "We have been focused on the tiny details, but we are not shipping this yet". Everything in the IDE can now be scripted.
He shows how a few lines of code a developer can attach a camera view when clicking on a property.
130 new API entry points, Unity developers can now do everything that the Unity3D GUI can do.
10:20am David talks about the pricing; Two pricing: cheap and expensive.
10:13am Joachim Ante is introducing Unity for the iPhone. "With Unity we have always focused on iteration time". He goes into some of the technical details, "With all the new input mechanisms for theiphone, how do we provide a quick feedback system, we wanted to keep the experience of develop, hit run under a second".
They provide a "Unity remote" that runs on the iPhone, you use the iPhone to control the game, but the debugging actually happes on the PC. So you hit "run" and there is no wait at all.
Joachim is explaining how they are using AOT to run native code on the iPhone without having any JIT on the iPhone.
Joachim shows "Build and Run" that does the cross compiler and sends the code to the iPhone. It takes about 10 seconds and he now has the game running on the iPhone and shows how both Javascript and C# code running on the system.
10:10am Some stats: sold out event; 180 attendees; community doubled in the last year (2x employees, 2x posts, 2x users);
Last year they released Unity 2.0.
Unity 2.1 was released, should have been 3.0, but they did not charge more.
They announced Unity for Wii.
Big games using Unity: Sony, Disney. Virtual worlds like Hangout.Net is out (very pretty!) A new online community was created (Blurst). SeriousGames released a new title "Global Conflicts" Latin America.
Hard to keep up with the list of users.
10:04am The Unity founders Joachim, David and Nicholas are on stage to start Unite'08.
They moved us from the room downstairs to the iMax auditorium whihc is packed with game guys. During the moments of panic that ensued after they moved us from the downstairs room into the switched rooms, I ended up in the front row, which in retrospect was a big mistake, you cant take pictures with the standard lens of this massive screen.
Registration
9:48am Waiting for the keynote at the Unite conference. There are about two hundred people packed in the Tycho Planetarium. The Blurst guys are all wearing matching shirts and have taken over the first line of the auditorium, From here I can see a them debugging a Sonic-like game that he is prototyping. Then he switched to some game that has an angry minotaur breaking dishes in a museum.
The minotaur looks angry and just scored 3,000 points of some kind.
Everyone in this conference seems to be using a Mac, and I could swear this computer is the only Linux machine in the audience.
Pre-Conference
Last night I had dinner at the Unity headquarters and got a chance to meet some of the Unity hackers and users before the conference started.
Gained a deeper insight into what we can do to improve Mono's VM for games. Lots of good ideas.
Phil Harrison brought up "the debugger" issue ;-).
Hopefully Rasmus from CellDotNet will show up for the Unity Mingle tonight.
Mono 2.0 OSX Installer Ready
We released an updated installer for Mono 2.0 on MacOS X.
This release got delayed because we wanted to upgrade our bundled Gtk# stack to contain the latest release of Imendio's Gtk+ for MacOS X.
Banshee coming to an OSX near you this week.
Mono OSX Survey!
We are trying to understand how we can improve Mono on the OSX space. Help us figure this out by filling out our Mono on OSX Survey.
Relocatable Applications
If you have followed our Guidelines for Application Deployment your software should be easy to be packaged and distributed for MacOS X as a relocatable application.
Eoin Hennessy worked on integrating Banshee into the OS, and packaging it into a bundle that runs out of the box on MacOS. The following are some screenshots from Aaron's box:
The Banshee open source media player.
Sandy has ported Tomboy and Tasque to MacOS and Windows and provided installers for both.
Tomboy integrates into the dock and menus.
Aaron Bockover from the Novell Desktop Team has promised that Eoin's work will be part of Friday's Banshee release. From this point on, Banshee will be released both for Linux and MacOS X at the same time.
Maybe F-Spot is not too far behind?
The Small Print
- We downgraded the bundled Gtk+ from 2.15 to
2.14.3, as 2.15 was a development version and 2.14 is
the officially supported Gtk+.
This means that applications that linked directly against Gtk+ 2.15 from Mono 1.9 will fail to run. Please re-link those binaries. - We removed MonoDevelop from this distribution, so
our package only contains the Mono SDK and Mono
runtime.
A MonoDevelop installation package will come later, we apologize for this delay.
On the upside: now that the distribution is split, we will be doing MonoDevelop Beta 2 previews as DMGs after the PDC.
Help us improve Mono on OSX by completing the Mono on OSX Survey and providing comments at the end.
Parallel Programming
As much as I personally dislike the use of threads for user code, multi-cores systems are here to stay. They are becoming increasingly popular (most laptops now ship with dual core systems, home computers ship with 3 cpus and gaming consoles ship with multiple general purpose cpus as well).
Developers will need new frameworks for developing software that is ready to take advantage of multiple CPUs. But most importantly they will need to learn the traps and pitfalls of writing parallel/threaded code.
Here are two fantastic articles on MSDN that cover these topics:
- Design Considerations For Parallel Programming by David Callahan.
- Solving 11 Likely Problems In Your Multithreaded Code by the excellent blogger and hacker Joe Duffy.
J�r�mie Laval worked on an ParallelFX implementation for Mono over the summer as part of the Google Summer of Code.
The implementation currently lives on the student repository at code.google.com. I can not wait for the API to be stabilized so we can move it into the main Mono distribution.
Going to Copenhagen
Next week I will be in Copenhagen for Unity3D's Unite conference.
Unity3D is one of the most fun users of Mono as they create IDEs for Game Developers and they are driving the adoption of Mono, C#, Boo and their own UnityScript in the gaming space.
As a newcomer into this industry, there are various sessions from actual Unity user on how they have built their games from start to finish. Other sessions include details on publishing, production (ArtPlant), Physics (Flashbang), Shader Programming (Unity), developing on the iPhone (Unity), a post-morterm on FusionFall's work for Cartoon Network and the hands-on lab.
Some cool stuff from the agenda includes a keynote participation from Atari's President.
If you want to meet up, drop me an email. I will likely be going to the Unity Mingle events at night and departing early on Friday to fly to the Microsoft PDC in LA.
Alan "BitSharp" McGovern Joins Novell
Alan McGovern, who created BitSharp during a Google Summer of Code for Mono has joined the Moonlight team at Novell.
Imagine the possibilities! Bittorrent clients, servers, trackers all running from Silverlight 2.0 Web Applets!
Discuss.
Mono 2.2 Feature: Mono.Options
In the upcoming Mono 2.2 release we will be distributing Jonathan Pryor's most excellent Mono.Options library.
Mono.Options is a beautiful command line parsing library. It is small, succinct, a joy to use, easy and powerful, all in one.
It is one of those libraries that does more with less. Something that every programmer aspires to write, but that we seldom achieve.
It has also struck a good balance for Unix and Windows developers as options can be used on both systems, and map well to practices on both systems. It took a long time to get the right "blend" of parsing, but I think Jonathan has achieved it.
Consider this example:
using System;
using System.Collections.Generic;
using NDesk.Options;
class Test {
static int verbosity;
public static void Main (string[] args)
{
bool show_help = false;
List names = new List ();
int repeat = 1;
var p = new OptionSet () {
{ "n|name=", "the name of someone to greet.",
v => names.Add (v) },
{ "r|repeat=", "the number of times to repeat the greeting.",
(int v) => repeat = v },
{ "v", "increase debug message verbosity",
v => { if (v != null) ++verbosity; } },
{ "h|help", "show this message and exit",
v => show_help = v != null },
};
List extra;
try {
extra = p.Parse (args);
}
catch (OptionException e) {
Console.Write ("greet: ");
Console.WriteLine (e.Message);
Console.WriteLine ("Try `greet --help' for more information.");
return;
}
if (show_help) {
ShowHelp (p);
return;
}
string message;
if (extra.Count > 0) {
message = string.Join (" ", extra.ToArray ());
Debug ("Using new message: {0}", message);
}
else {
message = "Hello {0}!";
Debug ("Using default message: {0}", message);
}
foreach (string name in names) {
for (int i = 0; i < repeat; ++i)
Console.WriteLine (message, name);
}
}
static void ShowHelp (OptionSet p)
{
Console.WriteLine ("Usage: greet [OPTIONS]+ message");
Console.WriteLine ("Greet a list of individuals with an optional message.");
Console.WriteLine ("If no message is specified, a generic greeting is used.");
Console.WriteLine ();
Console.WriteLine ("Options:");
p.WriteOptionDescriptions (Console.Out);
}
static void Debug (string format, params object[] args)
{
if (verbosity > 0) {
Console.Write ("# ");
Console.WriteLine (format, args);
}
}
}
And here is an example of its use:
$ mono greet.exe --help
Usage: greet [OPTIONS]+ message
Greet a list of individuals with an optional message.
If no message is specified, a generic greeting is used.
Options:
-n, --name=VALUE the name of someone to greet.
-r, --repeat=VALUE the number of times to repeat the greeting.
-v increase debug message verbosity
-h, --help show this message and exit
$ mono greet.exe -v- -n A -name=B --name=C /name D -nE
Hello A!
Hello B!
Hello C!
Hello D!
Hello E!
$ mono greet.exe -v -n E custom greeting for: {0}
# Using new message: custom greeting for: {0}
custom greeting for: E
$ mono greet.exe -r 3 -n A
Hello A!
Hello A!
Hello A!
$ mono greet.exe -r not-an-int
greet: Could not convert string `not-an-int' to type Int32 for option `-r'.
Try `greet --help' for more information.
He has also documented it thoroughly.
Where possible (new tools being written, or tools that have a similar command line structure that is compatible) we will be switching to this command line parsing library.
The library is small, so developers should include a copy of the source code in their application, this is how you should include it in your makefiles:
Options.cs: cp `pkg-config --variable=Sources mono-options` .
Then your code can just include a reference to it.
MonoDevelop gets VI bindings
I grew up mostly with Turbo Pascal as my development environment. When I started to write C code in DOS, I used Turbo C briefly but for some reason I switched to the BRIEF text editor for a while.
Around 1989 my friend Max Mendizabal who used nothing but Epsilon told me "Unix is the future, if you learn Epsilon, you will be ready to switch to Emacs when the time comes".
Prophetic words.
When I eventually switched to Unix in 1992, having learned Epsilon was useful, but Emacs was too slow for quick edits. I still used Emacs for programming, but for quickly making changes to a file, I ended up learning vi.
When computers got faster, I tried to switch to Emacs for all my editing tasks, but my brain had been hardwired. I even added "alias vi=emacs" to by shell, and I would find myself typing subconsciously "/usr/bin/vi".
To this day, I use both editors interchangeably.
In any case, the above story was just an excuse to introduce VI Mode for MonoDevelop.
Mono 2.0 is out!
Today we
released Mono 2.0 to
the world. You can download sources and binaries from
our download
page. And our
official release
notes are up as well. This of course would not be
possible without the open source contributors that worked
tirelessly on Mono sending patches, fixing bugs, helping the
community, answering questions, creating test cases and
supporting us all these years.
Mono 2.0 is both a runtime for application and a kit for developers for writing applications with C# and other ECMA CLI languages for a wide spectrum of uses.
Big thanks go to the fantastic Mono team at Novell that has kept the excitement and the pace over all these years (we started in 2001), the large contributions from Mainsoft, Unity3D and our users that pushed us to fix bugs, implement new features and tune Mono. Also, we very much appreciate the work of the ECMA 334 and 335 committee members that worked on the CLI and C# specifications and everyone at Microsoft that answered our questions over the years and specially those that licensed code under open source licenses.
We originally started to work on Mono, because we
wanted to make developers happier and more productive on
Linux. We liked C#, we liked the CIL and we wanted to have
those technologies available on our platform.
Since we have been active in the Linux Desktop world, it is not a surprise that the early use of Mono was mostly on Linux desktop applications, and Mono continues to shine there. Server-side use of Mono was a natural evolution and we soon were powering ASP.NET sites on Linux.
There is one area where we under-delivered in the past, and it has been a constant source of pain. Up until now, we did not have a working debugger. This has finally changed, and Mono 2.0 includes for the first time a debugger, the time for WriteLine() debugging is now behind us.
As the project matured, developers started taking advantage of Mono's open source nature: essentially .NET on their own terms. A platform that could be adapted, morphed, ported and modified to suit many different uses. Today Mono is embedded in portable mp3 players and powers Unity3D's game engine on the Apple iPhone, the Nintendo Wii, MacOS X and Windows (Some folks at Novell are working with Unity on bringing Unity3d to Linux!).
It has also been deployed to run code on large clusters of servers for SecondLife, powers our open source Silverlight implementation (Moonlight) and powers the popular DekiWiki: a Social Collaboration Tool.
Mono is a large project and it is hard to pick one feature to talk about as there are so many, so instead I put together a quick table of the major features that are part of this release:
| Compiler Support | .NET APIs | Mono APIs | |
Mono's Open Source Compilers:
|
Core API:
|
GUI APIs:
Mono Core:
|
We have ported Mono to a wide variety of platforms and operating systems on this 1.0 to 2.0 cycle. These platforms include:
- Linux (x86, x86-64, PowerPC32, Itanium, SPARC, ARM, s390, s390x.
- Solaris (x86-64, SPARC).
- MacOS X (x86, PowerPC32).
- Windows (x86, support for x86-64 will come in Mono 2.2).
- Nintendo's Wii.
- iPhone/iPod Touch (ARM, limited functionality due to licensing requirements; I will blog later this week about this).
- *BSD (x86, x86-64).
Developing with Mono
Long time Linux developers will probably continue to use Emacs and VI, but some new Linux developers might want to use an IDE. New developers can use our open source MonoDevelop IDE on Linux, or alternatively the commercial X-Develop IDE or SlickEdit.
If you are a Windows developer, you can continue using Visual Studio or your IDE of choice to write the code and compile it. Your binaries will run just fine on Linux.
To assist Windows developers in porting their applications to Unix, we have provided the Mono Migration Analysis tool.
Runtime Changes
The Mono Virtual Machine gained plenty of features since Mono 1.2 was released. We have added:
- Generic Code Sharing and VTable Compression have been implemented: this significantly reduces the memory footprint of generic type instantiations, while still getting the speed benefits of using generics.
- AOT support: in addition to x86, we now also support ARM and x86-64.
- COM interop is now complete (works on Windows with "real COM" and can be used on Unix with Mainsoft's COM or Mozilla's XPCOM).
- AOT code can now AOT parts of 2.0 assemblies (assemblies that contain generics).
- Full AOT support (allows code to run JIT-less, this is limited to 1.0 code).
- CIL Verifier: Now Mono has a CIL verifier.
- CoreCLR Security: the security system used by Moonlight.
- Many optimizations that improve execution performance: New intrinsics operations (Math.Min/Max for example); various operations are now inlined by the JIT; managed allocations (no transition to unmanaged code for allocating memory); multi-array access is now tuned by the JIT; constant and block initializations are now handled by the JIT; Faster initialization and access to multi-dimensional arrays (4x faster).
- The runtime went on a diet, many runtime data structures are smaller making Mono lighter.
Tools
In addition the the Mono Debugger making its debut appearance on this release, we are very proud of our code analyzer Gendarme.
Gendarme is a extensible rule-based tool to find problems in .NET applications and libraries. Gendarme inspects programs and libraries that contain code in ECMA CIL format (Mono and .NET) and looks for common problems with the code, problems that compilers do not typically check or have not historically checked.
Feedback
Mono is not perfect, but we want to improve it. Like many other open source projects, we need your bug reports to improve Mono. If you have problems with Mono, help us by filing a bug report.
Special Thanks
Special thanks to Hacker Extraordinaire Aaron Bockover who not only brings us the best media player in the world, but created the new web site design and implemented and tuned it over very long extra hours up until 7am in the morning on his weekend.
And to our packaging and QA team that spent extra hours to get all the bits and pieces in place for the release.
Five Second Linux Boot
I loved this LWN article on the changes necessary to make Linux boot in 5 seconds on the Asus EEE PC (a relatively slow computer).
Hopefully all Linux distributions will adopt these changes for custom deployments.
Moonlight Update: Media Codecs
A couple of weeks ago we started the work on porting Microsoft's Media Codecs to Linux and we got the C version running.
Popfly in Firefox3/Linux/x86
Geoff, Fernando and Rolf have been hard at work on this, and have also added the infrastructure to download and install the codecs on demand.
The next step was getting all the assembly language supported in Linux, and today Geoff got the assembly optimized SSE1 audio decoder running (the first chunk of the decoders).
Of course, the rest of the team has been busy fixing bugs and improving the performance in preparation for the first public beta of Moonlight.
Microsoft changes the Managed Extensibility Framework License
A couple of weeks ago I suggested that developers interested in having their .NET software run in other platforms should avoid Microsoft's Managed Extensibility Framework (MEF) as it was not an open source library.
I had a chance to discuss with Glenn, Sam and Bob the benefits of using the MS-PL for this library first over twitter and then over email.
Representing .NET's loyal competitor, I did not think that we stood a chance of getting Microsoft to change the license, but I was pleasantly surprised. Glenn understood the value of open source, Sam wanted to do the right thing about this library and CodePlex and Bob argued that Mono already had Mono.Addins anyways.
Today Glenn announced that Microsoft has changed the license for MEF to the open source MS-PL license.
Thanks to everyone at Microsoft that helped change the license!
DbLINQ, LINQ to Databases and Mono
Atsushi Enomoto blogs about the work involved in bringing LINQ to Databases to Mono.
The effort was a joint collaboration between the awesome DbLINQ developers, Pablo Iñigo Blasco our Google Summer of Code Student and Novell's Atsushi Enomoto.
The DbLINQ developers had created a general purpose LINQ provider that could be used with database providers other than SQL Server. They also relicensed their code a few months ago to the MIT X11 license to allow for integration with Mono's code base.
Read Atsushi's description of how the effort was put together and how DbLINQ is being refactored to become a full System.Data.Linq implementation and still provide the foundation for third-parties to easily create database LINQ providers.
DbLINQ is a great project, and it needs your help to complete the effort.
Mono at the PDC 2008
Great News Mono Lovers!
Later this month I will be presenting the session "Mono and .NET" at the Microsoft Professional Developers Conference in LA.
Exciting times!
Update: My talk will cover new technologies that we have created as part of Mono. Some of them are reusable on .NET (we try to make our code cross platform) and some other are features that specific to Mono's implementation of the CLI.
Microsoft to incorporate jQuery into Visual Studio
This weekend the news came out that Microsoft was going to bundle and support John Resig's jQuery as part of Visual Studio and ASP.NET. From Scott's blog:
I'm excited today to announce that Microsoft will be shipping jQuery with Visual Studio going forward. We will distribute the jQuery JavaScript library as-is, and will not be forking or changing the source from the main jQuery branch. The files will continue to use and ship under the existing jQuery MIT license.
Beyond the obvious benefits to developers, what interests me is that Microsoft is now bundling an open source component into their commercial offerings.
This is a first time for Microsoft.
With IronPython they continued development of an open source project in house. With IronRuby, they were open to external contributions to the libraries of IronRuby. In both cases they were not taking external code or contributions directly into their core products.
Hopefully they will start using more open source code in their products. Maybe one day they will bundle Mono's Cecil or Mono's embeddable C# compiler.
Monovation: Assembly Injection into Live Processes
People are loving the C# Interactive Shell.
In the past people have embedded languages like Boo into their applications (MonoDevelop and Banshee for example both have options to embed Boo and a shell).
Zoltan designed a new system for Mono that allows developers to inject and execute code into running Mono applications. Paolo provided significant feedback and design guidelines for the code to be incorporated into Mono.
Thanks to both Zoltan and Paolo this functionality is now available through the Mono.Management assembly: you provide an executable and a PID, and the executable is injected and its Main method executed on the target process:
using Mono.Attach;
[..]
// Get a handle to a running Mono process.
VirtualMachine vm = new VirtualMachine (pid);
// Load hello.exe into the target process, and run it
vm.Attach ("/tmp/hello.exe", "");
You can use this for billions of things of course. You could patch running programs, you could attach logging software to a running program, or you could inject a C# evaluator into a live application and examine its state, or tweak it live.
Zoltan came up with a really cool extension to the the csharp command (this is the command-line C# Interactive Shell). The csharp command now takes an --attach command line argument and a PID.
The csharp shell can now use the Mono.Attach.VirtualMachine to injects itself into the remote process and then the client and server communicate through a couple of sockets.
For example, this is the sample that Zoltan used to pitch his idea for supporting attaching to the virtual machine. With the following you can pause a live Banshee process:
$ ps aux | grep banshee miguel 12359 17.0 2.7 141372 55708 pts/5 Sl+ 14:30 0:02 banshee-1 /usr/lib64/banshee-1/Nereid.exe $ csharp --attach 12359 csharp> using Banshee.ServiceStack; csharp> using Banshee.Gui; csharp> var s = ServiceManager.Get(); csharp> s.PlaybackActions ["PlayPauseAction"].Activate ();
All of the code is now on SVN, you need both the mono and mcs modules from trunk.
A GUI Shell
The above commands are a tiny bit risky and are also limited to the shell.
The above commands will execute on a separate thread from the application, and any commands that you execute would be executed on a separate thread which could corrupt the state of your application.
So this weekend, I wrote a tool that integrates with Gtk# applications, its called gsharp and you can find it in the mono-tools module (it borrows some code from Banshee).
gsharp is a Gtk# version of the csharp command. What is important is that it also supports injection of the code on other programs, but makes sure that all the code executes in the Gtk# thread, by issuing all of its commands from the Gtk# idle handler. This means that it is safe to use gsharp with your Gtk# applications.
GUI version of the tool.
Here you can select which project you want to inject the GUI into:
Needs some work, show process names.
This version shows the gsharp tool attached to F-Spot, as I am not very familiar with the codebase, I can not do very much with it:
We will need to implement one of these as well for Windows.Forms applications. This should luckily be easy to do as most of the smarts live in the Mono.CSharp assembly (our embeddable compiler).
Security of Agents
A couple of weeks ago, I asked for people to weigh in on a security concern for temporary files. This was for Zoltan's attach functionality.
The code is now implemented and I would love if security experts could do a source code audit of our implementation. And validate whether our assumptions are safe.
Here is the source code.
Public Service Announcement
In C# the defaut access level for members in classes and structs is "private".
There is no need to pepper the source code with "private" everywhere. It only introduces noise and makes your code more difficult to read.
Love World Domination!
Chris Anderson is wearing a Mono T-Shirt on this PDC interview and IronRuby.com is hosted on DekiWiki, a Mono-powered Wiki site.
This is clearly awesome.
In other news, the awesome hackers at Imendio have officially released Gtk+ for OSX packages.
Stream.CopyStream
Funkists, why does System.IO.Stream not have a CopyStream method, it seems like everyone ends up implementing this.
Discuss.
reCaptcha.NET
Kudos to Ben and the rest of the Captcha team.
Today I downloaded the binaries for reCaptcha.NET for a web page that I was setting up and it worked out of the box. No recompiles necessary:
- Drop the Recaptcha.dll in the bin directory of the ASP.NET app.
- Get your public/private key.
- Insert this in your page:
<recaptcha:RecaptchaControl ID="recaptcha" runat="server" Theme="red" PublicKey="YourKey" PrivateKey="YourOtherKey"/> - Hit refresh. Ta da!
Encrypted File Systems
I just found out about encfs, a user-space encrypted file system that runs on top of FUSE.
To use it, just type:
$ encfs ~/.encryptedstorage ~/secure
And follow the directions. You then will have a ~/secure directory where you can stash all the material that you would not want to become public if you were to lose your laptop.
But it gets better than this. You can use sshfs to store files on a remote server, and then use the sshfs-backed file system as your encrypted storage, you can then keep your files stashed on a remote server, completely encrypted.
Mono team, hiring again
Hey folks, it is that time of the year when we are looking to hire some developers to work on Mono.
We are looking for people with experience in Linux, with experience building software from source code and good C# or Java skills. Experience with ASP.NET and ADO.NET is a plus.
The positions this time are only available in Boston, if you are interested, send me an email.
Update: we have filled this position.
Securing a Unix Domain Socket: Looking for Help
There is a cool hack that we want to introduce in Mono that would allow a remote process to debug a examine data in a running Mono instance. The hack uses the embeddable compiler.
The proposed extension to Mono would use a socket on /tmp/mono-USER/.mono-PID created by the Mono process and set the permissions to read/write for the owner and nothing for the group or other users.
What can go wrong security-wise with the above setup? What should we check that is not immediately obvious?
So far:
- Create directory with 0600 permissions, bail if mkdir returns anything but 0.
- Create socket in directory; It should be safe at this point, and change the permissions of the socket (is this really needed?).
Credit where credit is due
The csharp interactive shell and the embeddable compiler hacks could only have been possible thanks to the work that Marek Safar has put into implementing C# 3.0, cleaning up the compiler and laying down the foundation for a reusable compiler.
Some time ago, our regression test suite for the compiler was taking 20-30 minutes to run. Marek refactored the compiler so that we could reuse the same instance without launching a new process for each of our 1,500 individual tests.
Without Marek's dedication and love for the compiler, we would never have gotten here.
C# Eval: An Embeddable Compiler
Hello Internets and C# Lovers!
After the C# Interactive Shell started working, it became obvious that we now had C#'s eval and that it would be incredibly interesting to enable people to embed a C# Eval in their application.
I did a little bit of refactoring on the codebase last night, and now we expose a few methods that allow developers to evaluate C# expressions and statements dynamically.
Usage is very simple, you must reference the `gmcs.exe' assembly, this contains the C# Eval, then you invoke the CSharpEvaluator.Evaluate method, and get the results back.
The following is a small command line calculator that takes C# expressions:
using Mono.CSharp;
using System;
class MyCalculator {
static void Main (string [] args)
{
Console.WriteLine (CSharpEvaluator.Evaluate (args [0] + ";"));
}
}
Compile the above, and execute:
$ mono calculator.exe '1+2' 3
There are a number of overload methods for Evaluate that give more control over how things are evaluated. The csharp command is now written entirely using the CSharpEvaluator API. The code is now pretty simple: pretty printing of values, dealing with partial input, loading startup files (if any) and import the default namespaces.
A few uses that come to mind:
- Use C# as a scripting language for your application.
- Use it for startup scripts of your own application (similar to .emacs, but with C# instead).
- Use it to explore the state of your application live.
- Use it to debug your application as it is running.
- Embed the compiler on Silverlight and run C# on your web browser, similar to how Jimmy did it for Ruby.
- Embed it into your app and expose it as a service that you can connect to, and do it live!
The four or five public methods of the API are documented in the source using C# doc tags. When Mono 2.2 goes out, we will publish docs for them.
As we announced back in April, Mono's C# compiler is now licensed under the MIT X11 license, so you can embed at will.
Manhole
Joe Shaw mentioned a few days ago that it would be nice to support something like Twisted's Manhole where your application is listening on a port and then you can connect to it and debug it. It should take a dozen lines to write it, but I am heading out for dinner now.
But if I were to do it, I would probably make the csharp command (all 240 lines of it) support a --server command line option and have it connect to the server and send strings over the wire instead of executing locally. That way you get to use the awesome getline.cs command line editor and history locally and let the server run the code.
Getting Your Hands on This
To enjoy this hack, you have to either wait for Mono 2.2 or install Mono from SVN, all of the code is checked in.
Update: Clarification
Since it was not obvious, we do support C# 3.0, which includes the entire LINQ stack in the above expression evaluator:
using Mono.CSharp;
using System.Collections;
using System;
class X {
static void Main (string [] args)
{
Evaluator.Run ("using System; using System.Linq;");
bool ress;
object res;
string s = Evaluator.Evaluate (
"from x in System.IO.Directory.GetFiles (\"/etc\") where x.Length < 10 select x;",
out res, out ress);
foreach (var v in (IEnumerable) res){
Console.Write (v);
Console.Write (' ');
}
}
}
The above uses a LINQ expression, and this is the result in my system (files whose full pathname is less than 10 characters):
/etc/motd /etc/mtab /etc/raw /etc/rpc
Enterprise Library 4.0 now Open Source
Hello Internets!
Some very good news: As part of the ongoing discussion on the MS Limited Permissive License, I was doing some Google searches on it and came across the Enterprise Library 4.0 release.
Enterprise Library was a project that came out of the Patterns and Practices group at Microsoft, and they had historically used licenses that were not open source friendly. This new release is now licensed under the terms of the open-source friendly MS-PL license.
In the past, various people have asked us to implement an open source version of it, so they could use those building blocks on Unix with Mono. We never had any spare cycles to look into this, so the blocks provided by Enterprise Library were always beyond Mono users.
As it turns out, since May 2008 it has been possible to use the library with Mono on non-Windows platforms.
Now all there is left to do is to package it in a convenient form.
Interactive C# Shell
During the last HackWeek, I had a chance to work on a project that we had been discussing in the Mono team: an interactive C# shell.
The idea was simple: create an interactive C# shell by altering the compiler to generate and execute code dynamically as opposed to merely generating static code.
The result is the csharp command. The command provides an read-eval-print loop for entering C# statements and expressions:
csharp> 1;
1
csharp> "Hello, World".IndexOf (",");
5
csharp> Console.WriteLine ("Hello");
Hello
Statements are executed; Expressions are evaluated, and the result displayed. There is support for rendering arrays, IEnumerables and dictionaries specially, consider the following C# 3 declaration:
csharp> new Hashtable () { { "/bin", "executable files" }, { "/etc", "configuration files" } };
You will get this back when rendered:
{{ "/tmp", "Temporary files" }, { "/bin", "executable files" }}
Statements can span multiple lines; In those cases the interactive shell will use a different prompt to indicate that more input is expected, for example:
csharp> 1 + > 2; 3 csharp>
One of the main advantages of this shell is that you can try out your LINQ expressions directly on the shell, for example, the following query works on the result from Directory.GetFiles:
csharp> using System.IO;
csharp> var last_week = DateTime.Now - TimeSpan.FromDays (7);
csharp> from f in Directory.GetFiles ("/etc")
> let fi = new FileInfo (f)
> where fi.LastWriteTime < last_week
> select f;
{ "/etc/adjtime", "/etc/asound.state", "/etc/ld.so.cache",
"/etc/mtab", "/etc/printcap", "/etc/resolv.conf" }
The LINQ expressions are not limited to working on IEnumerables, you can also use LINQ to XML or LINQ to any database provider supported by Mono by loading the assembly:
csharp> LoadLibrary ("System.Xml.Linq");
csharp> using System.Xml.Linq;
csharp> var xml = new XElement("CompilerSources",
> from f in Directory.GetFiles ("/cvs/mcs/mcs")
> let fi = new FileInfo (f)
> orderby fi.Length
> select new XElement ("file", new XAttribute ("name", f), new XAttribute ("size", fi.Length)));
csharp> xml;
<CompilerSources>
<file name="/cvs/mcs/mcs/mcs.exe.config" size="395" />
<file name="/cvs/mcs/mcs/gmcs.exe.config" size="464" />
<file name="/cvs/mcs/mcs/OPTIMIZE" size="498" />
<file name="/cvs/mcs/mcs/lambda.todo" size="658" />
<file name="/cvs/mcs/mcs/smcs.exe.sources" size="726" />
[...]
</CompilerSources>
A differences between csharp and the C# language is that I felt that for interactive use, it would be important to change the type of a variable, so the following is allowed:
csharp> var a = 1; csharp> a; 1 csharp> a.GetType (); System.Int32 csharp> var a = "Foo"; csharp> a; "Foo" csharp> a.GetType (); System.String csharp>
To load code interactive I added two methods: LoadAssembly and LoadPackage.
LoadAssembly is the equivalent of passing the -r command line argument to csharp or mcs, this example shows System.Xml.Linq in use:
csharp> LoadAssembly ("System.Xml.Linq");
csharp> using System.Xml.Linq;
csharp> XDocument doc = new XDocument(
> new XDeclaration("1.0", "utf-8", "yes"),
> new XComment("Sample RSS Feed"),
> new XElement("rss",
> new XAttribute("version", "2.0"),
> new XElement ("channel",
> new XElement("title", "RSS Channel Title"),
> new XElement("description", "RSS Channel Description."),
> new XElement("link", "http://tirania.org"),
> new XElement("item",
> new XElement("title", "First article title"),
> new XElement("description", "First Article Description"),
> new XElement("pubDate", DateTime.Now.ToUniversalTime()),
> new XElement("guid", Guid.NewGuid())),
> new XElement("item",
> new XElement("title", "Second article title"),
> new XElement("description", "Second Article Description"),
> new XElement("pubDate", DateTime.Now.ToUniversalTime()),
> new XElement("guid", Guid.NewGuid()))
> )
> )
> );
The variable doc is then rendered:
csharp> doc;
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<!--Sample RSS Feed-->
<rss version="2.0">
<channel>
<title>RSS Channel Title</title>
<description>RSS Channel Description.</description>
<link>http://tirania.org</link>
<item>
<title>First article title</title>
<description>First Article Description</description>
<pubDate>9/8/2008 5:13:34 PM</pubDate>
<guid>bc6825ab-f1ab-4347-ad6e-3cf076011379</guid>
</item>
<item>
<title>Second article title</title>
<description>Second Article Description</description>
<pubDate>9/8/2008 5:13:34 PM</pubDate>
<guid>a474b2bb-deba-4973-9581-762857b24b53</guid>
</item>
</channel>
</rss>
LoadPackage is the equivalent of invoking the compiler with the -pkg: flag. This is a Mono-ism that integrates Mono libraries with Unix's pkg-config. Packages allow definitions and multiple assemblies to be loaded in a single call, for example, this loads the Gtk# 2.0 package:
csharp> LoadPackage ("gtk-sharp-2.0");
csharp> using Gtk;
csharp> Application.Init ();
csharp> var b = new Button ("Hello Interactive Shell");
csharp> var w = new Window ("So cute!");
csharp> b.Clicked += delegate { Application.Quit (); };
csharp> w.Add (b);
csharp> w.ShowAll ();
csharp> Application.Run ();
Pleasure
This shell has been incredibly useful to debug things in the last few weeks, as it avoids the tedious typing to try out APIs and to see what some function might return. Launch csharp and test things away.
To improve the experience of the command line editing, I wrote a managed readline replacement, it provides history, keyboard navigation and searching.
Also the System, System.Linq, System.Collections, and System.Collections.Generic namespaces are imported by default.
Additionally, the csharp command will load any assemblies and C# scripts that you have in the ~/.config/csharp directory. If you are working constantly say on LINQ, you can put there all of your using and LoadLibrary statements.
Availability
The csharp command will be available in Mono 2.2, which is still a few months away, or it can be obtained by compiling Mono from SVN today.
Interactive Commands
Currently there are a few static methods and properties that you can invoke from the command line, like the "help" property that will display some help, and the "quit" property that terminates the shell as well as things like LoadLibrary and LoadPackage that I have described before. A complete list is available on the CsharpRepl page.
I am interested in hearing which other features should be added to the shell. I think we need some special commands to describe types and objects, like monop.
Additionally, currently values are displayed by using ToString(), but perhaps we need a method Inspect(object) that would show the values of all public fields and properties, like a debugger would.
Which other commands should be added?
Avoid the Managed Extensibility Framework.
Update: Microsoft has now changed the license to the MEF to the open source MS-PL license. Please see the follow up post for details.
As a .NET developer, you should avoid using the newly released Managed Extensibility Framework as its license prevents its use beyond the Windows platform. This will prevent your .NET software from running on Linux or MacOS in the future.
Luckily, there is a cross platform solution available today that has no platform limitations: Mono.Addins, a technology inspired by Eclipse's own plugin system. We have tutorials, reference manuals, API docs, our FAQ our public groups and multiple large applications with source code available that you can learn from (MonoDevelop, Banshee, F-Spot and Gnome-Do).
The rule obviously applies to any new APIs that are built for .NET as they are not immediately available for Mono. But unlike the binary-only APIs, these half-open source code releases pose additional problems for the open source CLI:
- More people are exposed to the source code, preventing them from working on a fully open source implementation of it.
- There is a smaller desire from the community to reimplement the code, as it is relatively easy to just use the existing implementation or ignore the issue for the time being.
- Some folks might not care about the license restriction, and ignore it altogether. A practice I do not endorse.
There are two additional issues that are worth pointing out. Should non-open source libraries be hosted on CodePlex to begin with? CodePlex is branded as the "Open Source Project Hosting" from Microsoft, yet, this license is clearly not open source and does not qualify as open source according to the definition and is a clear violation of Codeplex.Com's requirements:
The above link points to http://en.wikipedia.org/wiki/Open_source_licenses.
MEF should be pulled out of the CodePlex site along with all other platform-limiting software, like ASP.NET MVC (h/t to gblock for pointing out that MVC is also violating the terms). Unless CodePlex cooks up a special exception that some software and restrictions are more equal than others.
The second point that is worth making is that picking licenses like the MS-LPL for .NET software is shooting the .NET community in the foot. The LPL license is obviously an effort to tie things into the Windows platform, putting company first, community and developers second.
The MS-LPL is a poisonous license, do not use it (do not confuse with the MS-PL which is a decent license, the extra "L" makes a big difference).
Update: gblock points out that CodePlex technically only requires a "license" to be picked, but does not require it to be OSI compliant. But even if the wording on the FAQ does allow for that interpretation, it is misleading as there is a link to OSI licenses next to it, and the main page clearly states that Codeplex is an "Open Source Project Hosting" site. Capital "O" and capital "S".
The "CodePlex Basics: Getting Started" page also points to the Open Source License Definition, there are no words about custom licenses or about hosting proprietary code with source code available.
Update2: Glenn has reached out to the community and clearly wants to improve the status quo when it comes to MEF, open source, CodePlex and the official policies. Good luck to Glenn.
It is also worth pointing out that Glenn was one of the early adopters and advocates of the MS-PL at Microsoft (to clarify: the MS-PL is an open source license).
Using Visual Studio to Debug Mono
The following screenshots shows Visual Studio debugging a remote Mono process running on a Linux box.
Breakpoints, current line, and stack traces.
The setup works like this: you run a debugging server on Linux. On Windows you install a Visual Studio extension that provides a Debugging Engine and the configuration tools to start your application.
Then you start your application from Visual Studio (Tools/Launch with Mono) which will send the binaries and debug information over to Linux and execute it.
Showing the disassembled code generated by Mono's JIT
The core of the above work is to get the Windows to Linux debugging functionality enabled. We will have more news when the debugging experience is more complete and we are approaching the time to test drive it.
If you are interested in trying it out, sign up for our preview on our web site.
Debugging Support
Mono 2.0 will for the first time include a debugger, the command line mdb command.
Beyond this, we want to offer GUI debugging. The native solution is being built on top of MonoDevelop and will be available when we release MonoDevelop 2.0. It will work on both Linux and MacOS hosts.
The second GUI engine will be the above Visual Studio plugin for developers that use Windows as their main OS and Visual Studio as their IDE.
More Visual Studio Integration
In addition to this work to integrate Visual Studio with Mono for remote debugging, thanks to the Summer of Code (Ed Ropple) and Jonathan Pobst's work in this hack week we got some support to run applications on Mono/Windows and run our Mono Migration Analysis tool.
Jonathan's work is available today as an MSI, check out his post for more details.
You can also check Ed's summer of code report on CloverLeaf.
getline.cs: Partying like its 1988
In an age where the Unix shell is more relevant every passing minute, we need to have proper command line editing tools everywhere.
For a project of mine, this weekend I put together a command-line editing class for .NET shell applications. The Mono.Terminal.LineEdit class can be used by shell applications to get readline-like capabilities without depending on any external C libraries.
To use it, just do:
using Mono.Terminal;
LineEditor le = new LineEditor ("MyApp");
while ((s = le.Edit ("prompt> ", "")) != null)
Console.WriteLine ("You typed: " + s);
It supports the regular cursor editing, Emacs-like editing commands, history, incremental search in the history as well as history loading and saving.
The code is self-contained, and can be easily reused outside of my project. To use it, you just need to include the getline.cs file in your project. This is built on top of System.Console, so it does not have external library dependencies and will work on both Mono and .NET (finally bringing joy to people using command-line applications that use Console.ReadLine).
It is licensed under the MIT X11 license and the Apache 2.0 license so there are no annoying licensing issues and can be mixed with anything out there.
Second Life Demos
Cool performance demos comparing SecondLife's LSL engine vs LSL running on Mono's VM.
SecondLife rolls out Mono-powered servers
Big news for the Mono team today.
Linden has started the roll out of their Mono-powered simulation servers.
Users can now opt into having their LSL scripts executed using the Mono VM (it remains an opt-in feature, because some scripts are timing sensitive and the performance increase could break code).
Some choice quotes from Jim Purbrick's blog post:
As well as providing immediate benefits, the integration of the Mono virtual machine makes many future improvements possible: the use of mainstream languages to script Second Life alongside the existing LSL language; the removal of arbitrary per-script limits on script resource usage and the use of mainstream libraries and tools for scripting to name a few.
And:
The integration of Mono is the first step in the evolution of Second Life into a true software development platform. Thank you to all the residents who have helped us take this first step.
Congrats to Linden on their launch!
The Technology
From a SecondLife developer perspective, some of the technical details about how Mono is integrated into the Second Life simulators can be found on their Wiki.
When a user opts into using Mono, a special LSL compiler that generates ECMA CLI byte codes is used. The resulting CLI byte codes are then instrumented with some magic (more below) and then the code is exectuted using the Mono VM which translated the bytecodes into native x86 code.
I find the SecondLife technology fascinating. Embedding Mono into SecondLife was not an ordinary task, it was not just a matter of linking with Mono and writing an LSL to CIL compiler.
SecondLife distributes the virtual world on hundreds of servers, and as visitors move through the virtual world, their inventory, character and scripts migrates from server to server.
This migration requires that running scripts be suspended, serialized to a database and their execution resumed on a different server. This means that all the state of a script, including the current location must be preserved while the user navigates across servers.
The technology to do this is absolutely brilliant. I strongly recommend the Lang.NET presentation that Cory and Jim did in 2006.
The first half of the video is an introduction to Second Life, the second delves into the hackery necessary to make it happen.
This are clearly hugenormous news for us, and for everyone that worked with Linden, for everyone that fixed bugs and implemented new features in Mono to run under the conditions that Linden has.
OSX Development with Oxygene, Cocoa and Mono
The RemObject folks have been doing some tutorials on how to build applications with Visual Studio and Interface Builder to target both Windows and MacOS with .NET and Mono respectively.
Check out their tutorial and their notes on cross platform development. The lessons in the tutorial also apply to C#-based development.
It is also worth noting that recent versions of their Oxygene compiler now support generics.
Dynamic Method Invocation Performance
Jon Skeet has an in-depth explanation of how to improve the performance of code that needs to dynamically invoke methods through reflections.
The bottom line is that if you have performance sensitive code that needs to invoke methods that you fetch from reflection, you should avoid using MethodInfo.Invoke() and instead create a delegate from the MethodInfo, and perform the invocations that way:
[...]Using a delegate invocation is only about 10% slower than direct invocation, whereas using reflection takes over 600 times as long. Of course these figures will depend on the method being called - if the direct invocation can be inlined, I'd expect that to make a significant difference in some cases.
This is a well-known trick, but Jon provides a great exploration of the subject.
Protocol Buffers for .NET
Additionally, you can see that Jon's effort to port Google's Protocol Buffers to C# are almost complete.
There are currently three separate approaches to support Protocol Buffers in .NET. Jon's effort essentially mimics the existing support for C# and integrated with the Google implementation and compilers. The other efforts have taken slightly different approaches, one of them is designed with the WCF approach in mind: use C# classes/interfaces as the actual public contract, as opposed to the .proto files.
First preview of Mono 2.0 is out
Our first preview for Mono 2.0 is out; It has been almost six months since we branched version 1.9 so this is a gigantic update to Mono.
Many of the features are listed on the release notes, but the release notes do not even begin to capture the enormous number of fixes, performance improvements, tuning and work that went into this release.
As usual, this is our "best release ever", but it is also the longest we have gone without doing interim releases, so it is possible that we might have regressed where our test suite lacks tests. We would love to get folks to test this, with their code, and to bug reports on any issues they find before our final 2.0 release.
See our Roadmap for more details on the release schedule and the upcoming post-2.0 releases.
GovTrack.Us Interview with Joshua Tauberer
Jon Udell interviews Joshua Tauberer on his service GovTrack.us that helps citizens track legislation and voting in the US.
C# 3.0 and Parallel FX/LINQ in Mono
For a while I wanted to blog about the open source implementation of the Parallel Extensions for Mono that Jeremie Laval has been working on. Jeremie is one of our mentored students in the 2008 Google Summer of Code.
Update: Jeremie's code is available from our mono-soc-2008 repository.
Dual CPU laptops are becoming the norm; quad-core computers are now very affordable, and eight CPU machines are routinely purchased as developer workstations.
The Parallel Extension API makes it easy to prepare your software to run on multi processor machines by providing constructs that take care of distributing the work to various CPUs based on the computer load and the number of processors available.
There are various pieces in the Parallel Extensions framework, the simplest use case is Parallel.For, a loop construct that would execute the code in as optimally as possible given the number of processors available on the system.
Parallel.For is a simple replacement, you usually replace for loops that look like this:
for (int i = 0; i < N; i++)
BODY ();
With the following (this is using lambda expressions):
Parallel.For (0, N, i => BODY);
The above would iterate from 0 to N calling the code in BODY with the parameter scattered across various CPUs.
C# 3 and Parallel LINQ
Marek Safar recently announced that Mono C# compiler was now completely compliant with the 3.0 language specification.
In his announcement he
used Luke
Hoban's
brutal ray tracer-in-one-LINQ statement program. This was a
hard test case for our C# compiler to pass, but we are finally
there. I
had blogged
about it in the past. Luke Hoban's
ray-tracer-in-one-linq-statement looks like this:
var pixelsQuery = from y in Enumerable.Range(0, screenHeight) let recenterY = -(y - (screenHeight / 2.0)) / (2.0 * screenHeight) select from x in Enumerable.Range(0, screenWidth) let recenterX = (x - (screenWidth / 2.0)) / (2.0 * screenWidth) let point = Vector.Norm(Vector.Plus(scene.Camera.Forward,
Vector.Plus(Vector.Times(recenterX, scene.Camera.Right), Vector.Times(recenterY, scene.Camera.Up)))) let ray = new Ray { Start = scene.Camera.Pos, Dir = point } let computeTraceRay = (Func<Func<TraceRayArgs, Color>, Func<TraceRayArgs, Color>>) (f => traceRayArgs => (from isect in from thing in traceRayArgs.Scene.Things select thing.Intersect(traceRayArgs.Ray) where isect != null orderby isect.Dist let d = isect.Ray.Dir let pos = Vector.Plus(Vector.Times(isect.Dist, isect.Ray.Dir), isect.Ray.Start) let normal = isect.Thing.Normal(pos) let reflectDir = Vector.Minus(d, Vector.Times(2 * Vector.Dot(normal, d), normal)) let naturalColors =
from light in traceRayArgs.Scene.Lights let ldis = Vector.Minus(light.Pos, pos) let livec = Vector.Norm(ldis) let testRay = new Ray { Start = pos, Dir = livec } let testIsects = from inter in from thing in traceRayArgs.Scene.Things select thing.Intersect(testRay) where inter != null orderby inter.Dist select inter let testIsect = testIsects.FirstOrDefault() let neatIsect = testIsect == null ? 0 : testIsect.Dist let isInShadow = !((neatIsect > Vector.Mag(ldis)) || (neatIsect == 0)) where !isInShadow let illum = Vector.Dot(livec, normal) let lcolor = illum > 0 ? Color.Times(illum, light.Color) : Color.Make(0, 0, 0) let specular = Vector.Dot(livec, Vector.Norm(reflectDir)) let scolor = specular > 0 ? Color.Times(Math.Pow(specular, isect.Thing.Surface.Roughness), light.Color) : Color.Make(0, 0, 0) select Color.Plus( Color.Times(isect.Thing.Surface.Diffuse(pos), lcolor), Color.Times(isect.Thing.Surface.Specular(pos), scolor)) let reflectPos = Vector.Plus(pos, Vector.Times(.001, reflectDir)) let reflectColor =
traceRayArgs.Depth >= MaxDepth ? Color.Make(.5, .5, .5) : Color.Times(isect.Thing.Surface.Reflect(reflectPos), f(new TraceRayArgs(new Ray { Start = reflectPos, Dir = reflectDir }, traceRayArgs.Scene,
traceRayArgs.Depth + 1))) select naturalColors.Aggregate(reflectColor, (color, natColor) => Color.Plus(color, natColor)))
.DefaultIfEmpty(Color.Background).First()) let traceRay = Y(computeTraceRay) select new { X = x, Y = y, Color = traceRay(new TraceRayArgs(ray, scene, 0)) }; foreach (var row in pixelsQuery) foreach (var pixel in row) setPixel(pixel.X, pixel.Y, pixel.Color.ToDrawingColor());
And renders like this:
The above now compiles and runs as fast as it does on .NET.
Jeremie then modified the above program to use the parallel extensions to LINQ. He replaced Enumerable.Range with ParallelEnumerable.Range and foreach with the parallel ForAll method to take advantage of his library.
You can watch the above ray tracer with and without LINQ on his screencasts (LINQ ray tracer, Parallel LINQ ray tracer).
Tracking Parallel FX
There is much more information on the PFXTeam Blog. Another great blog to follow, in particular check out their Coordination Data Structures Overview, PLINQ Ordering and some demos.
Must follow blog
Another fantastic blog to follow: Fake Twitter Status.
Mono 2.0 branched, and the Linear IL
On Tuesday of last week we branched Mono for the 2.0 release; Packages are being QAed for our first release candidate and will be available next week. Bug fixing for the final release will happen on this branch.
Meanwhile, the excitement continues on trunk. Zoltan today merged the Linear IL branch.
The Linear IL code has been under development for two years and eight months and it was an effort that we started to address some of the main limitations in our current JIT design. Some of these limitations in the old design made it very hard to bring some code generation optimizations into the JIT, or made the optimizations not as effective as they could have been.
The new JIT engine will debut in Mono 2.1, later this year. Now that Linear IL is the default, the entire JIT team will focus on tuning the engine and extracting more performance out of it. But even without tuning, the new engine is already performing very well as you can see in the results comparing the engines.
Additionally, a number of creative ideas that we have to improve Mono all depended on doing this switch. We have a few surprises for developers in the next coming months.
Congratulations to Zoltan for getting this work merged.
C# 4.0 Design
From a recent interview on the design team for C# 4.0 Anders said about the room they meet to discuss the C# design:
We have been meeting in this room for nine years, three times a week.
This seems to be one of the reasons C# has evolved so nicely.
Sadly there are no actual details on the interview about what is coming up on C# 4.0. We have to wait until the PDC to get an idea of what will be coming.
Luckily, Mono's C# compiler is already 3.0 compliant, and we are ready to start adding 4.0 features the moment they become public.
Smuxi: a new IRC client
My friend Mirco Bauer has been maintaining and coordinating the Mono packaging for Debian for many years.
Today
he released
smuxi. His own IRC client that he built on top of Gtk#:
Gtk+ 3.0, take 2
Emmanuele Bassi has summarized a discussion that happened on IRC after my Gtk+ 3.0 post.
His blog entry starts by saying that we should not use blogs to discuss and then goes on to discuss. I agree with the sentiment, but IRC is not a good place to do the meeting either as we do not even have IRC logs for whatever channel they were on discussing.
It is about the ISVs
Emmanuele seems to think that this is a marketing problem. It is not.
This is about the effect that the current Gtk+ 3.0 plan has on ISVs.
KDE has almost no ISVs, Qt does.
GNOME has almost no ISVs, Gtk+ does.
Most likely because anything beyond the core toolkit is too unstable in both cases, and because things are too quickly flagged as deprecated with no roadmap in place.
The Qt situation is much better, as it is commercially designed, and they have existing customers that are paying them money to solve problems for them, not introduce new ones.
Qt is also designed to be bundled with your application, and you can make your proprietary application not break if the user upgrades his Qt. This is not the modus operandi for Gtk+.
Having an "abandoned Gtk 2.x" and a "maintained, but API and ABI incompatible 3.x" which will not be available everywhere at the same time is a major turn off for ISVs.
Creating an ISV ecosystem is incredibly hard, and somehow the new generation of Gtk+ developers is now "OK" to throw away years of work of those that had to work with fewer resources than Gnome has today, fewer developers, a smaller community, slower computers, bigger challenges and yet, managed to keep Gtk+ 2.0 API compatible.
Perhaps it is not a matter of being "OK", but the new crop of Gtk+ developers does just not appreciate just how much value ISVs are for Gtk+, Gnome and the Linux desktop in the first place. They did not have to fight to get those guys on board on the first place.
The premises and the conclusions of Imendio's paper would not hold if you were to consider application developers in the mix. But in particular, it seems that the mindset is dangerously close to the rationalization used recently by a KDE spokesperson and lampooned by the Linux Hater Blog.
What bothered me last night
What bothered me last night after I blogged was the realization that most of the Imendio developers have switched to OSX as their main desktop operating system (At least rhult, hallski and kris).
These are great developers, but for their day-to-day activities, they have given up on the Linux/Gnome desktop. Their concern is no longer to attract ISVs, as long as the source compiles with some changes, they will be OK.
There are certainly some developers at Imendio that still use Linux, and I am sure they have a "Linux partition" to test things out. But when it comes to ensuring the viability of the Linux desktop ecosystem, I do not feel comfortable about wiping out the ISV ecosystem that we have.
Discussion
Emmanuele says:
for instance, I would have loved to have Miguel at the gtk+ team meeting of Tuesday at GUADEC: it would have been a great discussion, I’m sure of it, and we might have had a different state of the union talk.
I mentioned this problem in my previous blog entry. Even if I had made it to Istanbul on Tuesday, I am merely one of the voices concerned about API stability. "Tuesday Meeting at Guadec" is hardly inclusive:
There was no Adobe.
There was no VMware.
There was no Medsphere.
There were no Eclipse folks (who have complained previously about the ABI/API issues).
There was no Gnumeric.
And these are the ones I can think of the top of my head.
Senior voices from our own community were missing, like Morten Welinder who has expressed his opinion in a shorter post:
The best thing about tabs that I can think of is that it will keep certain people from doing more harmful things like changing the gtk+ api for no good reason.
I do not know who attended the Gtk+ planning on Tuesday, but it was not inclusive, and I suspect it was heavily tilted towards the Nokia-ecosystem.
From a Nokia standpoint, I understand the desire of dropping older code, get a smaller version of Gtk+ out there, and be able to get a very flashy system at all costs. The iPhone and OSX are strong UIs, and I can understand the desire to compete, but lets not throw the baby with the bathwater.
Decisions about the future of Gtk+ can not be done without all the stakeholders, and specially without those that have worked for years in keeping the API stability under duress and have built applications on top of it.
Features
Emmanuele says:
Yes, 3.0.0 might not have features. is this bad marketing? probably. so we need to fix this. a way1 to do this would be keeping the 3.0.0 in alpha state, call it 2.99.02 and add features to that until we get to a 3.0.0 that developers will want to migrate to, like the new scenegraph API or the new style API. let’s break with 2.x in style
As I said previously, I would endorse such a plan if it is shown that fundamental new features could not be implemented in an API/ABI compatible way. Nobody has yet refuted my assessment of the various areas that would not break compatibility, and that covers most of the new features.
Although I am not the only stake holder, nor the only ISV, nor the only developer.
Communication
Emmanuele says:
communication: there’s a certain lack of communication between the gtk+ team and the users of the library. in my opinion, it’s due to the small number of active developers and to the fact that ISVs don’t really get involved into shaping the platform they are using. they have the source code, and sometimes it’s easier to fix in-house than to communicate and go through the proper process — and this is a structural problem that is caused by the small number of people involved in the said process as well. the gtk+ team needs to open up more, and at the same time the ISVs need to get more involved. sometimes it feels to me that the team is waiting for features, direction and help in the development, while the users of the library are waiting for the team to come up with the perfect plan to fix all the bugs and warts while retaining the whole API and ABI.
I agree with Emmanuele.
We setup the GNOME Foundation for things like this; Lets use the GNOME Foundation organizational powers to reach out to ISVs; to organize a platform and Gtk+ summit as it is now clearly needed; Lets include all the stakeholders, not only the active developers.
Process
Emmanuele says:
process: this is connected to the first point - we have a lot of channels, and it might be daunting to actually follow them all; but we're also open in terms of discussion and revision. this is our strength. so please: if you want to discuss, join the IRC meetings on the #gtk-devel channel on Tuesday at 20:00 UTC or send an email to gtk-devel-list with your points. get involved. help shaping the future. don’t stand idly by, and wait for stuff to break to complain.
Casual discussion on IRC is OK, but that should not be the repository for decision making for such a fundamental component of GNOME and the Linux desktop.
Perhaps the discussion can start on IRC, but minutes, summaries and decisions should be posted to the Gtk+ developers and users mailing list and given enough time for all the stake holders to participate.
Additionally, you can not expect that your blog has now reached all the ISVs, not even the gtk-devel-list (which is presumably a mailing list for the developers of Gtk+ not for its users).
We need to have a mailing list discussion, and then we need to have an outreach program to get to all stakeholders, including the ISVs to formulate a plan.
Gtk+ 3.0
The Gtk+ 3.0 proposal being discussed currently sounds like a disaster for GNOME. The reasoning was first articulated in the histrionic Imendio Gtk+ 3.0 Vision presentation done at the Gtk+ Hackfest in Berlin. This is a meeting where application developers were underrepresented, and somehow we have accepted those proposals as the community consensus.
The proposal goes like this: Gtk+ 3.0 will hide all public fields in objects, provide accessors to these, remove APIs that have been flagged as deprecated and introduce no new features.
All the actual new features that some people want would come up in future versions. Which features will come is yet to be decided, because nobody knows when and what will be implemented.
There are lots of technical problems with the proposal, and from my discussions this week at GUADEC it does not seem that the Gtk+ developers have discussed the implications with the users of Gtk+.
There is a major strategic problem with the plan as well. The most important one is that there is no actual plan for which features will be added, and when these features will be added. There are no prototype implementations, and the idea of first developing the new features in a branch to actually study the code, the implementation and its potential APi breakage is not even on the agenda.
Basically, we are being told that we should trust that first breaking the API and hiding fields will suddenly enable a whole generation of new features to be implemented.
But it gets better. There are no guarantees that 3.x will not break the API if the feature in question turns out to require API breakage. Which means that we might actually end up in a situation where there will be multiple API breakages.
This by all means sounds like a bad plan.
Towards a Better Plan for Gtk+ 3.0
I am not against breaking the API for newer versions of Gtk+ if the benefits outweigh the downsides, and the execution presented is not bad. But "3.0 will help us clean up" is not a good enough reason.
We need:
- A Clear Roadmap: We need a clear roadmap of
which features will be implemented and when they will
be implemented. This is the first step to making
decisions.
A clear roadmap would also allow new developers to join the efforts and big companies like Red Hat and Novell to dedicate some full time resources to make some of these feature happen. As things stand today, we are basically being told to "wait-until-3.0-then-we-will-sort-it-out".
- Working Code: Before a feature for a future
version of Gtk+ can be considered a reason to break
the API, the technology must exist in the form of a
patch/branch.
This is not new, and should be of no surprise to anyone. This is how the Cairo integration into Gtk+ was done, how the layout changes are being implemented and how every other software product is ran. - New API-breaking features must be publicly
discussed with the community: Since this will
affect every application developer (open source and
proprietary) we should get the feedbacks of these
communities.
We could all get as excited as we want about a "gboolean bouncing_text" field in a GtkLabel, but that does not mean that we should break the API for the sake of it.
Application developers were underrepresented at the Berlin hackfest, and even GUADEC is a microcosm of the ISVs that we had to reach. For instance, I did not see anyone from Adobe, VMware or Medsphere at the conference. - Transitional 2.x Releases: For a long-enough period to get distributions to include the code, Gtk+ 2.x should include getter/setter macros to allow software developers to upgrade their source code to work with and without the public fields. To soft-land the switch to a hiding-field Gtk release (this is covered in the Imendio proposal).
This is by no means a comprehensive plan, it is only the beginning of a plan.
Lets please avoid inflicting in GNOME a KDE 4.0 (yes, I know its not the exact same scenario; and yes, I know those clock applets are cute).
Gtk+ Extensions
From looking at the original Imendio proposal. it seems that plenty of the things they want can be implemented without breaking the API:
- Animation: doable entirely without breaking the API. The animation/storyboard framework is an entirely new codebase, that would not touch anything in Gtk+. Some widgets might require smoother rendering on changes, but all can be done in an API-compatible framework. public API.
- Physics: same, add-on.
- Data-binding: same, add-on.
- Easier language bindings: same, add-on.
- Improved back-ends, more OS integration: Can not think of a major issue, but granted, I could be missing something, and Imendio has done the OSX port.
And my own favorite: killing all Gtk+ theme engines, and replacing it with a Qt-like CSS theme engine. This is not really an API break, as the only consumers of this code are the theme engines, and those we can safely kill and replace with CSS themes, no application code would break.
Maybe Havoc's proposal requires an API breaking change. And maybe this is worth breaking the API for. But breaking it for no gain, and no prototype to even understand the actual effects post 3.0 is wrong.
Update: For what its worth, I would lean towards breaking compatibility in 3.0 if it meant 3.0 would include the Havoc-like Scene system. That would make it worthier of a change.
Update: As usual, the Linux Hater Blog has some great commentary. Some of his feedback on KDE 4.0 applies to our own decision making. Worth a read.
RIA BOF at GUADEC
Thanks to Behdad and the organizers at GUADEC, I will be having a BOF/discussion session tomorrow at 4:30pm to discuss a new class of applications built on Silverlight or Flash and how they relate to the future of the Linux Desktop.
Some of the ideas are clearly derived from Alex and Chris thinking about the desktop; it is heavily influenced by our work on Moonlight; by the recent strides that Adobe has made on creating great looking applications on the web (Buzzword and Photoshop Express) and the future of Gnome.
Join me tomorrow for a discussion on how to launch an effort to create an open-source, RIA-based desktop applications.
I am very excited.
Guadec/Istanbul; Rich Desktop Applications.
Next week I will be attending the GNOME Developer Conference in Istanbul.
Looking forward to meet old friends and looking forward to discuss with people the future of rich applications.
BOF: Does anyone know how to apply for a last-minute BOF?
If there is some free presentation slot, I would like to hold an informal BOF to discuss these ideas.
Aaron and Banshee
Today I walked into Aaron's office unannounced and I just saw him glowing. Like a girl that has been kissed for the first time, like a donkey in the spring.
A voice in the background was narrating Banshee features, and I was wondering just what is that noise?
As I went around to his monitor to see what he was watching and listening to, I saw this Linux.com review on Banshee that included a screencast/podcast.
He was *so* excited that he was actually watching it in three computers at once.
I could not believe it.
Three computers at once. One, two and three. All playing the podcast. At the same time.
I was speechless.
From economic mastermind to flattered developer.
He said to me: "I have never seen a production of such caliber" as he listened to the background music in the above podcast.
I just stood there quietly. Unsuspectingly recovering the Twix office supply.
Moonlight 0.7 Installers
Yesterday I forgot to point to the actual page to install the Moonlight plugins.
You can download the latest plugin from here. Just like the last release, these plugins are compiled without ffmpeg support.
The source code is available here.
You can track the progress and try out a few applications yourself from our Moonlight Status page.
Moonlight 0.7 is now Available
A new release of Moonlight is now available. The team has been working very hard on improving the performance of Moonlight as well as improving our compatibility with Microsoft's Silverlight.
Get your copy here. Source code is moon-0.7.tar.bz2.
This release will also work with both Firefox 2.0 and Firefox 3.0. We have also switched our installation system to use signed XPIs, but we will also require a browser restart (we could not figure out a way of avoiding this).
Some of my favorite work that happened on this cycle is the effort to improve our multi-browser support, work towards supporting WebKit and Opera is underway and will improve over time. This work benefitted from our own work to support both Firefox 2.0 and 3.0 in the plugin.
Windowless mode (the mode that allows blending of HTML content and Silverlight content) is vastly improved but is only available on Firefox 3.0. This is a feature that is used extensively by Silverlight designers.
More details from the release:
- Webkit loads the plugin (kangaroo, lewing)
- The stream/downloader/request/response logic (used for downloading media) has been been almost entirely moved from the browser bridges into libmoon, with the browsers providing subclasses. (kangaroo, sde)
- Finally add argument checking to all wrapped plugin objects (fejj).
- Windowless mode fixes (lewing, toshok)
- Plugin event handling fixes (lewing)
- Many clock/animation framework fixes. We now pass both animation matrix tests, and many, *many* other bugs (and regressions) have been fixed. (mdk).
- Bug fixes in the Stroke{Collection}.HitTest and Stroke{Collection}.Bounds code (toshok, sde).
- Namescope merging fixes (sde, jackson)
- Parser fixes, and changes paving the way for 2.0 work (jackson)
- Fix mouse event bubbling behavior (toshok)
- Big, big strides in our media framework and the various (file, http, mms) downloaders, (fejj, rolf, kangaroo, fer)
- MMS stream selection (kangaroo)
- Shape caching and bounds computation reduction (spouliot)
- Geometry bounds work (spouliot)
- Fast path for position updates (Canvas.Left/Canvas.Top) (toshok)
- Improved temporary cairo surface bounds (lewing)
- Glyph rendering speedups (fejj)
- Resort by ZIndex as a dirty pass (toshok)
- work is progressing. A very simple 2.0 application successfully ran. (miguel, jackson, sde).
Hanging out at Microsoft
I will be at Microsoft on Thursday and Friday, and only have meetings on Thursday afternoon.
I would love to meet other hackers. If you want to meet, discuss, talk, drop me an email: miguel@novell.com
oh. hai.
People at the office became LOLcat fans by reading every day i can has cheezburger a few months ago. It was harmless entertainment.
But recently I have discovered that LOLspeak has started to creep into our codebase.
Consider the IHasSourceView interface or the ActiveSourceCanHasBrowser property.
What other naming conventions should we adopt?
Discuss.
Office Justice, at Last!
For the past few weeks, since Aaron Bockover found out that some of us like Twix. He then bought all the 70 cent twixes in the vending machine at the office and started reselling them for a dollar.
Michael struck back by bringing fruits and vegetables today. To which Aaron replied "I hope those fruits rot".
Today the machine was refilled:
This has brought finally an end to the empire of speculation from this rapacious market meddler. With at least 12 new twix bars injected into the local office economy we should enjoy a smooth sailing for the rest of the week.
Update: Some sources inform me that Aaron was trying to create an artificial scarcity in the office by buying the remaining 12 twixes, he hit a glitch in the machine, he got two bars for the price of one.
This is not bodding well for the local Twix aficionados:
Update 2: Capitalism knows no limits:
Update 3: To add insult to injury, he is now selling individual Twix bars for 70 cents each, or a full pack for 1 dollar.
Update 4: We will be picketing Aaron's office at 4pm this afternoon:
LinuxHater's blog, I am a fan
I love the LinuxHater's Blog. This is a must-read RSS feed.
It is funny in a way that xkcd is funny to Unixers. Whoever is writing that blog has extensive experience on Linux and enviable writing skills.
A first class grilling/roasting of Linux and the Linux community. It should help keep things in perspective.
Some good starting points:
OpenOffice-based applications with Mono and MonoDevelop
The entire OpenOffice suite is built on top of a component technology called UNO (which is inspired by COM, but heavily extended). Pretty much all of the functionality in OpenOffice is exposed through some UNO interface, and although the native interface is built on top of C++ many bridges have been created over the years that expose UNO to a variety of languages, runtimes and object brokers.
A few years ago, Sun implemented a .NET bridge for UNO. This bridge allowed .NET developers to script, extend and reuse open office as a library from C# or any other .NET language.
A couple of years ago, Michael Meeks and the OpenOffice community ported the bridge to work with Mono which allows developers to create OpenOffice based solutions using any of the Mono programming languages (C#, Boo, IronPython, IronRuby, F#, VB, Nemerle and so on).
But even if the engine existed, it was not properly installed in the system and getting a C#-based OpenOffice solution required lots of Unix skills, the kind of skills that would likely be in short supply by those interested in OpenOffice automation. We fixed this in this last development cycle, so now a Novell OpenOffice installation will have everything you need.
Michael Hutchinson, one of our MonoDevelop hackers has put together the missing pieces to simplify the process. He has created the solution templates necessary to create these solutions, and packaged them as a Mono.Addin for exiting MonoDevelop users.
To build OpenOffice solutions, you need to install the OpenOffice addin for MonoDevelop. To do this, follow these steps.
Activate the Add-in Manager
Select Templates.
Select the OpenOffice Automation Samples
Complete the installation for the Mono.Addin, once you are done, create a new Solution:
You can skip this step, and get back here later, but you might want to select "Unix integration":
Take advantage of code-completion:
This is what the default sample looks like, you can use this as a foundation for your program. Since this is a COM-based API, it is not an API that is easy to discover with code-completion popups, so we figured it was best to ship full working samples:
Build and run your application by hitting F5:
Your OpenOffice solution in all of its glory, this is from the samples that we distribute as part of the templates:
Improving the OOo API
Sadly, the OOo API exposed by UNO does not look or feel very .NET-ish at all. It is a COM-based API and is not very discoverable. Code-completion will sadly not be of much help without the samples.
Additionally, the conventions used in the code are not very .NETish, so it will feel a little bit odd.
There are a few options here, we could either massage the .NET exposed API into something more .NET-friendly, or we could create a wrapper around the UNO API for most common usage scenarios. We are not sure what would be best.
We believe using a Cecil-based tool-massager we could rewrite the cli_types.dll library to get a more .NET-ish API:
- Rename classes and methods to follow the casing conventions for .NET.
- Turn setters and getters into properties.
- Change the XBlah convention into IBlah convention for interfaces.
This still leaves the issue of interface identity to be solved where an underlying object that always implements IA, IB and IC interfaces is usually only exposed as one of those interfaces, and you must do an explicit cast to the other interfaces to access the other features.
Thanks to the Michaels for all the hard work.
Gnome-Do 0.5: "The Fighting 0.5!"
Another beautiful desktop application, this one by David Siegel. I have become a fan of it in the last few months since David started working on it:
Gnome-Do is another very polished application, one that shows a lot of love and care for taking care of the small details. David just released a new version a couple of days ago.
Gnome-Do is inspired by Quicksilver from MacOS and like Banshee, it uses Mono.Addins extensively to make the application more useful:
Go to David's page for more details and screenshots on all the new features (Skype, Flickr, Twitter, IM, Google Calendar integration; community plugins, configuration and more).
Banshee 1.0 is out.
Banshee the Gtk#/Mono based media player for Unix has finally reached its 1.0 status.
Congratulations to the Banshee team for this release!
This is one of the finest applications built with Mono, Gtk#, GStreamer, Mono.Addins, DBus#, C# and Boo. The Banshee developers have worked very hard in creating a very polished UI and have paid a lot of attention to the smallest details to provide an enjoyable user experience.
This really should be considered Banshee 2.0 as SLED shipped two years ago with Banshee 0.10, which was already a stable product.
Since that first public release, a lot of work went into improving the user experience by making Banshee faster and cope better with large libraries. This required new custom Gtk# widgets (these are reusable widgets, with a model-view-controller system, and part of the Banshee Core) as well as rethinking the way that storage was handled by pushing as much work as possible to the SQLite layer and never loading all the data in memory.
The full list of the features will give you a better idea of what this player can do.
Plugin Architecture, a Foundation For Experimentation.
This is an architectural overview of Banshee's Core:
Banshee is split up in various components, but most importantly the core does very little work. Pretty much all of the functionality for the media player is implemented as Mono.Addins. Mono.Addins provides services that allow users to install new extensions for Banshee to add new features to the core.
To make it simpler to develop plugins we will be shipping MonoDevelop and VisualStudio templates to get developers started on creating new plugins for Banshee.
For example, Alan McGovern, the creator of MonoTorrent a bittorrent library for Mono and .NET extended the Podcast functionality in Banshee to download your podcasts using Bittorrent (this extension is not part of the 1.0 release).
In this screencast you can see how a download for a Democracy Now podcast goes from 1.5k/s to 650k/s (OGG, low-quality WMV).
Windows
In the next couple of weeks we will package Banshee for Windows to expand the reach of Banshee to more users. And as part of this distribution we will also distribute templates for Visual Studio developers to create their own extensions.
Unity3D now available for the Wii
Unity3D has announced that their game creation tool is now available for Wii developers. Unity lets you script your games in Boo, Javascript or C# with Mono.
Congratulations to Joachim, David and the rest of the team at Unity3D for getting this working.
More Gtk# Widgets
I had forgotten about Medsphere's LGPLed Gtk# widgets, the Medsphere Widgets.
Today Brad blogged about them.
This is my favorite:
Wow. Adobe Buzzword
I am blown away by Adobe's Buzzword web-based word processor.
It feels like a great native application, with great widgetry and lots of attention paid to the details.
Custom Controls in Gtk# Article
CodeProject has a nice article by Olivier Lecointre on how to write custom Gtk# controls.
Sample widget from the article.
Oliver writes:
I recently made the switch to Ubuntu and I am quite delighted with it. I develop mainly on .Net and my dependence on some Windows tools was the sticky point that made me wait this long. This is now not really an issue, thanks to the great work of the Mono and MonoDevelop teams, and the related libraries like Gtk#, Cairo and Pango.Mono brings the .Net platform to Linux and MonoDevelop offers a good alternative to Visual Studio, making the development of GUI applications on Gtk desktop almost painless.
I wrote a cooperation tool that I use on a daily basis and my first goal after the switch was to port it over with Mono and Gtk#. After a few adjustments caused by the fundamental differences between Windows.Forms and Gtk#, I have to admit that the port of the application was a lot easier that I initially thought; I replaced the UI controls by widgets, set the various forms to use the Gtk# layout, and that is pretty much it. The rest of the non UI code worked as expected with an overall good performance.
An area that gave me the most difficulty was the usage of custom controls with a behavior that is different from the base Gtk components. This is the focus of this article.
Holly Gtk Widgets
Daniel has announced his "Holly Widgets" for Gtk#. A collection of useful Gkt# widgets. The widgets also support MonoDevelop/Stetic integration.
The code is available from http://code.google.com/p/holly-gtk-widgets.
Picker screenshots:
Font picker.
Date and time picker.
Color picker.
Nice extensions:
Baloon Tooltips.
Regular expression validating entries.
IP address entry.
Combo box with file system navigation.
Simplified API wrappers:
A simple combobox.
A simple list (avoids TreeView binding, and supports Measure/Draw on a per-item basis).
Simplified tree view API.
Combo box with tree view.
Daniel also has nice samples and documentation for all of his new widgets.
Mono Embeds Nabble
Mono has always been developed on mailing lists like pretty much every other classic open source project. But many of our younger or migrating users are more used to Web-based forums and have always wanted to have a forum-like interface for the Mono mailing lists.
Thomas Wiest and Joseph Hill have just finished the integration Nabble into the Mono web site. Now people can access all of the Mono mailing lists with a Forums UI.
Messages posted in the forum will go to the appropriate mailing list (either hosted at lists.ximian.com or groups.google.com), and messages posted on the mailing lists get reflected on the forums.
You can access the forums http://www.go-mono.com/forums here.
Summary
Message View
Enjoy!
Games Worth Playing
As you might know, I do not consider myself a gamer although I now understand the Penny Arcade cartoon.
I have done my best in the past year to increasing BestBuy and Game Stop share holder value by dumping thousands of dollars in my quest to be entertained by video games.
The games that I actuall enjoyed playing are very few:
- Wii Sports, but the fun fades away after a couple of months.
- Metroid Prime 3, on the Wii, fantastic controls.
- Ratchet and Clank on the PS3, incredibly fun.
- Bioshock on the xbox360, by far, my favorite game.
- Ratchet and Clank on the PSP, just because I love the PS3 version so much.
- Sudoku on the DS.
- Update: I forgot the incredibly fun Simpsons game.
I continue to refuse to play propaganda games and do not enjoy sport games, racing games or fantasy games. I could not get into the games in the Orange Box, even if everyone loves it (Portal was ok). And I have not tried Rock Band or Guitar Hero because I do not want to have a drumset ont he living room.
I guess I like games that have a developing story and are not very repetitive.
Is there anything like Bioshock on the game pipeline?
Silverlight 2.0 Hello World
Silverlight's 2.0 deployment model changed significantly from the 1.1 alpha model. In the past you would load a XAML file, and then on demand load any managed libraries referenced from the XAML file before parsing could continue.
With Silverlight 2.0 the model has changed. One of the downsides is that now you deploy things as a ZIP file with a manifest file which feels obnoxious. On the upside, the loop "try-to-parse-or-keep-requesting-files-from-the-browser-until-all-dependencies-are-downloaded" is now gone. Now you get a zip file asynchronously, unpack it, load all the assemblies in the zip file, create an instance of the class specified as the entry point, and off you go. No more latency.
This hopefully also solves an obnoxious pattern that was common in 1.1: calling createFromXaml from Javascript could hang execution while Moonlight waited for the browser to fetch a missing assembly.
This week Silverlight 2.0 said hello in Linux:
This corresponds to the standard template with the content of the user control set to a TextBlock.
There are some peculiar patterns in Silverlight 2.0 instantiation model. Instead of creating objects from a XAML description, an object of a known-type is first created, and then the object is initialized from a XAML file. Your object is supposed to call LoadComponent ("my-xaml-definition") to initialize itself.
Google IG and Sudoku
A few months ago, am not sure how, but Nat talked me into getting a widescreen laptop. I no longer remember what were the touted benefits of it, but this warpig of a machine is both buggy and heavy.
Since the warpig is just too heavy to carry home every day (and also requires a base station hooked up to high-def output to stay at 2.4 GHz of speed) I just leave it at work and use my five year old computer at home to surf the internets. When I bought the machine I remember distinctively describing it to friends as "a silent computer". Five years later every time I load a new web page the fans make as much noise as the construction site across the street. Was I deaf back then, or did the fans become dirty and loud?
I am a fan of Google IG, and recently I discovered that they have a tiny IDE that you can add to your Google IG page. So I decided to try to write a Silverlight Sudoku application entirely using that tiny editor in my old computer at home:
I actually cheated a little and used Emacs here and there every once in a while.
But I ended up with this cute Sudoku/Silverlight application that has exactly one puzzle:
I am very proud of my one-puzzle Sudoku because it has some of the features that I like from Big Bang's Sudoku (click to flag, double click to set the value, hints) and some cute and simple animations that I wrote in xaml and shows my allegiance to the clean and simple configuration religion:
I published it on IG as "Moonlight Sudoku". To add it to your IG home page, go here and click "Add to Google".
Now the only problem with it is that it seems to work just fine with Firefox but seems to have problems with IE and Safari. I must be doing something wrong with Javascript, but I have no idea what it could be. If you can find the bug, let me know so I can make it work on other browser.
My toy sudoku only has one puzzle, this is clearly a design decision to prevent people from becoming addicted to Moonlight Sudoku. But if you know of a source of http-fetchable Sudoku puzzles, let me know, as I might want to revisit this design decision to include more puzzles.
You can download the self-contained module (ig + html + xaml + js) from here. You might also need the Silverlight.js file.
In clear violation of David Mamet's advise to the aspiring actor, I am now going to act surprised:
In other news, Firefox 3 RC1 came out, and the release notes have nothing to say about the bugs that prevent Silverlight from working with it.
Moonlight - Full Packages Available from Packman
Larry Ewing pointed this out.
PackMan now has full packages of Moonlight for OpenSUSE users (it includes ffmpeg codecs).
You can use these packages to check some videos at channel9 or see the dual-stream updated videos from Mix 08. Keep us posted about bugs and limitations.
Mono's Winforms 2.0 is now API Complete
Jonathan Pobst has posted the update on our Windows.Forms 2.0 work.
Some interesting points from his blog entry:
- We are now API complete, which means that our public API is exactly the same as .Net's (all 12,776 methods).
- The first check-in to our current Winforms implementation was on July 8th, 2004. It took 4 years to get here, and 6,434 individual SVN commits.
- The toolkit is made up of 115k lines of code.
Also:
- We currently have three backends: X11, OSX and Win32.
- There is a Google Summer of Code effort to improve our theming and OS integration this summer.
- Winforms 2.0 will also debut support for XIM to allow input for CJK character sets.
- We have a nice binding to Gecko as our implementation for WebControl which we started last year (currently we are limited to Gecko on X11 though, no Mac support yet for this WebControl).
- The Desktop team at Novell is adding UI Automation and accessibility support to Windows.Forms integrating it with Gnome's ATK. They have a full team dedicated to that goal.
- R-to-L support: It is not an priority for us at this point, but it would be nice if someone with RtoL needs were to complete the work that Sebastien did last year to use Pango inside GDI+.
Winforms 2.0 was the last piece of code holding off the Mono 2.0 release. We anticipate that there will be bugs, so we want to encourage folks to submit their bug reports and to evaluate the portability of their sofwtare using our Mono Migration Analyzer tool.
Congratulations to the Winforms team, and everyone that provided bug reports, test cases, contributed code, tested and worked with us to bring it to where it is today.
First Moonlight Release
Today we are making the first public release of Moonlight,
supporting the Silverlight 1.0 profile for Linux. The release
comes in two forms:
- No-media codecs supported, but easy to install: head to http://www.go-mono.com/moonlight and click on the cute installer for Moonlight. This currently hosts builds for Linux x86 and x86-64 for Firefox.
- Source-code compilation, but you can optionally compile FFMpeg codecs yourself. To do this, download our moon-0.6.tar.bz2. And follow the build instructions.
Update: I apologize for the confussion; This is not Moonlight 1.0, this is the first source code release that we are making of Moonlight for interested contributors and developers. This release is not even a Beta release, as we are not yet feature complete (missing components in media codecs, the media pipeline, as well as fixing about 70 known bugs). Apologies for any confussion.
Although Moonlight works on Firefox 2 and Firefox 3, recent changes in Firefox 3 prevent Silverlight and Moonlight from working (For details see #432371, #430965). There is a user contributed Greasemonkey script that will work around this bug for some sites (requires Greasemonkey).
Windowless: Moonlight supports "windowless" mode, a mechanism that allows Silverlight content to blend with other HTML ements on a page. This is only supported by Firefox 3, users of older versions of Firefox might run into Silverlight applications and web sites that do not work correctly as many Silverlight applications depend on this functionality (Flash sites have the same problem with Firefox 2).
1.1 and 2.0 support: This release only supports the Silverlight 1.0 profile. The 1.1 support is no longer maintained and the release happened at the time when we are transitioning the APIs to 2.0.
If you find bugs, please file them for us to fix.
Cross-platform, standalone Silverilght Applications
Tamir Khason published an interesting approach at hosting standalone Silverlight applications.
His solution is a Windows.Forms application that hosts a Windows.Forms.WebControl and inside the WebControl he hosts Silverlight.
Unlike my proposal for standalone Silverlight Applications that is currently Moonlight-specific (and currently limited to Linux/X11) this approach works on Windows with .NET and with Linux using Mono and Moonlight:
Left side: .NET hosting WebControl and Silverlight on Windows; Right side: Mono hosting WebControl and Moonlight running on Linux.
In addition to hosting the WebControl for hosting Silverlight, a thread is running to dispatch http requests locally using HttpListener. HttpListener is an embeddable HTTP server that is part of the class libraries, and exposes a very limited API. You can host ASP.NET with HttpListener by doing the bindings by hand, or you could use our Mono.WebServer library (part of our XSP/mod_mono distribution) to allow your applications to have a fully hosted ASP.NET server.
Mono.WebServer is what iFolder uses to embed the ASP.NET server to expose SOAP-based WebServices to clients.
Of course, this currently does not work on MacOS X as we do have no implementation of WebControl for Windows.Forms on OSX, something that a contributor might want to look into.
You can get the source for the sample from Tamir's page.
Consulting Gig at Novell
We are looking for consultants to work on a six to nine month project at Novell to write a prototype for a Visual Studio addin in C# or C++ that will connect Visual Studio and its debugging infrastructure to a remote Linux machine running Mono and the Mono Debugger.
If you are interested in working with us in this project, you must have good C# and C++ skills, experience with networking and protocol design, knowledge of COM and assembly language programming are pluses.
We are looking to bring two consultants for the duration of this project. If you are interested, please click this link and attach your resume, pointers to some existing projects of yours and so on.
Rodrigo Kumpera Completes the Mono Verifier
Rodrigo Kumpera, one of our VM developers has completed the instruction verifier for Mono's virtual machine. This effort started in June of last year.
The verifier is a late addition to the Mono VM as it was not a priority to run untrusted code inside the virtual machine.
But as Mono user base grew, it became important to support this feature. Second Life needs this to run potentially malicious code that is uploaded by a user, and we need this to provide an execution sandbox when running Moonlight on the browser.
Rodrigo did this work in stages: the first stage was to add support for the 1.0 virtual machine opcodes. Once that was done, verificiation for the 2.0 generic instructions was added.
This is an important milestone in our support for Silverlight 2.0 support on Linux.
Congratulations to Rodrigo for his work!
Mono and the Google Summer of Code 2008
This year Mono is participating again on the Google Summer of Code. A list of the applications that were accepted is available at Google's page.
This year the quality of the applications and the new ideas submitted (aside from those we proposed) was fantastic. They were too good, and it was very hard to select the final projects (we wanted to pick 33 of the 75 projects proposed, but there were only 15 slots available).
LinuxersForObama
Linuxers, BSDers, FLOSSers, GNUers, OSSers, Mysqlers, Gnomers, KDErs, Monoers, Javaers, PHPers, I invite you to donate to Obama through the LinuxersForObama campaign hosted at My.BarackObama.com web site.
If you are a US citizen, or a legal immigrant (green card holder), you can contribute 10, 20, or perhaps 2,300 to the Obama campaign.
You can donate here http://my.barackobama.com/page/outreach/view/main/LinuxersForObama.
I called the campaign "LinuxersForObama" because its short. I know it should have been called "GNULinuxBSDApacheX11PythonPerlMySQLPostgressPerlRubyJavaRailsMonoForObama", but it was getting hard to type.
And if you are a Windowser or Mac()er, but you like how Linuxers stick it to the man, feel free to donate to my LinuxersForObama campaign.
In retrospect, I should have created one campaign per product, and use that to settle once and for all, which is the best FLOSS project.
Standalone Silverlight Applications
Last year we created a framework to run Silverlight
applications as native applications. At the time we called
those
applications moonlight
desklets.
The desklets are Silverlight applications that run in standalone mode, with full access to the entire Mono API stack (as opposed to be limited to the .NET subset for the web) and that can optionally render without frames. This is a screenshot from three desklets running on Linux from last year:
Beyond hack-value, there are in my opinion many reasons why this is valuable. Powerful .NET programming model, powerful graphics and animation framework, reuse the same code base for Web and desktop development, and a sandboxed execution model.
Many people have asked us privately about this.
The Magical mopen Command
To run a standalone desklet, all you have to do run the mopen command, like this:
$ mopen ruler
The above command will look for a directory called "ruler" listed in your PATH, and if the file default.xaml lives inside that directory, it will open that file up. This XAML file can in turn reference managed code.
We did this so applications could be deployed in directories, very much like they are deployed on MacOS. The rules are simple, applications should be self-contained, keep all their data relative to their executable base directory, the foundation for this started with our application deployment guidelines.
It also draws inspiration from the bundles from MacOS X and the `open' command there.
How does this work? Lets consider our enterprise pixel measuring tool, the Moonlight ruler, which is made up of two files:
- default.xaml, the basic XAML container, it references the managed code in ruler.dll
- ruler.cs contains the code to draw the ruler.
This is what it looks like when you run it:
Awesome Moonlight desktop ruler.
Details
At LugRadio Live this weekend in San Francisco I decided to turn my Mono talk into a Moonlight talk, and I discussed some of the things that we have been doing with Moonlight.
Let me start with this artist rendition of Moonlight's Core:
The orange pieces were built by the Mono/Moonlight team at Novell. The green pieces are provided by Microsoft (and only for use in the browser context, we will get back to this later) and the blue stuff is stuff that we consume from the community.
The Moonlight Core provides the high-level canvas, the XAML loading, the animation framework, timers, media streaming and demuxing and event dispatching. It also has very few dependencies, it uses Cairo to render graphics and interfaces with our media pipeline and needs codecs to do video (currently ffmpeg if you build from source, or Microsoft's when we release).
Our engine today has three frontends:
The most important one of course is the plugin front-end, the one that is embedded into Firefox and renders the Silverlight content.
The other front-end is a Gtk# widget, a simple Gtk+ host that embeds the Moonlight Core into a widget and allows developers to embed any kind of XAML content (including managed code) inside it. I did a demo of Banshee embedding a grid of video players at LugRadio.
This is a widget that can be used to spice up your application. If you feel that you need some bling for your application, some gratuitous animations and special effects, the GtkSilver widget can help you. Using it is trivial:
using Gtk.Moonlight;
[...]
void SetupWidget ()
{
Application.Init ();
GtkSilver surface = new GtkSilver ();
surface.LoadFile ("MyAnimation.xaml");
Window w = new Window ("Demo");
w.Add (surface);
w.ShowAll ();
Application.Run ();
}
If you want to get a handle on specific objects, you can just use the FindName method on the surface's canvas:
MediaElement handler = (MediaElement) surface.Canvas.FindName ("MyVideoPlayer");
// Start playback.
handler.Play ();
And the third interface is the fabulous mopen command that we previously described (which is conveniently implemented on top of GtkSilver; yes, we know, we are geniuses).
The Two Stacks
As you might suspect from reading about GtkSilver and the browser, the Moonlight managed stack (that is, the C#/.NET APIs) actually comes in two shapes:
- Browser API: This is what people creating Silverlight applications are familiar with. Its a subset of .NET 3.5 and it has limitations as to what you can do: no local file system access and a sandbox that encapsulates all the actions of Silverlight applications.
- Full API: We also offer the full API, this is our implementation of .NET 3.5 that has been augmented with the Silverlight APIs.
As you can guess, GtkSilver and the desklets today use the Full API; And our browser plugin uses the more limited Browser API and the security sandbox.
We will get back to this soon.
Adobe Air
Adobe AIR has a great experience for installing native applications on your system, and they are cross platform (Windows, Mac and Linux).
I found a cute twitter application built with it, and have been a happy user of it for a few weeks (see screenshot).
I have no idea how extensive the AIR APIs are, whether they are sandboxed or whether they provide full access to all the APIs like our Moonlight Full API provides, but you can build some cute desktop applications with it.
I like it.
Silverlight Desktop Apps
Part of the reason why our Desklets did not evolve much in the last year was because there were no controls for them. You could build your own, but that was a lot of work, and it was hard to share, and most importantly, everyone knew that Microsoft was going to ship controls for Silverlight.
Now that controls are part of Silverlight 2.0 and that most of the high-level controls have been open sourced and that they are incredibly powerful and great to skin it makes sense to think again about native desktop applications using Silverlight.
We as a team can certainly create a Linux-only platform for these controls, and live happily with mopen, but we would miss an opportunity of having something cross platform like AIR is.
Ideally, Microsoft would follow our direction and implement and distribute the same mopen functionality that we have for Windows and Mac. This would ensure maximum adoption of standalone Silverlight-applications.
In a less ideal world, we (the Mono/Moonlight community) could port Moonlight's mopen command to Windows and MacOS, but with none of the power of influence that Microsoft has.
Directions and Challenges
Michael Hutchinson has suggested that we should have an minstall tool in the same spirit of mopen. This tool would take care of installation on each platform, creating shortcuts, desktop links and using the right icon.
Moonlight currently runs on systems with Cairo, and requires Gtk+ for event processing. It might be interesting to get it running on Win32, OSX and others with the tiniest footprint possible (bundling Gtk+ for Windows and MacOS for native apps sound large).
Another alternative is to use Microsoft's Silverlight on Windows to implement `mopen' as opposed to porting Moonlight. Apparently its possible to instantiate it through COM in some form, but that would still leave OSX out.
The codecs that Microsoft will distribute for use with Moonlight are limited to use inside the browser. This will prevent Moonlight's standalone applications from playing back any vc-1, wmv, wma, mp3 content.
We could add OS-specific codecs; On Linux we could call into Fluendo's commercial codecs, on Windows and Mac use the system codecs.
But we could also standardize on free video and audio codecs for the desktop edition: add support for the free video and audio codecs (BBC's Dirac, which will become VC-2, Vorbis and Theora).
We are currently busy doing Moonlight 1.0, and then we will get busy doing 2.0. So we will not be able to spend time on any of these projects for quite some time, but these are projects that developers in the community could work on or companies interested in pushing Moonlight in that direction.
Discuss.
Mono C# compiler now also MIT X11 licensed
I know, so exciting, a license.
We are dual-licensing under this uber-liberal license because:
We are changing the license to allow parts of the compiler to be reused as part of MonoDevelop, our LINQ class libraries and to embed it in ASP.NET.
In MonoDevelop: This will allow the compiler to be used to improve code-completion to support C# 3.0 as well as improving the heuristics when offering completions. This will reuse the front end and parts of the backend.
Compiler hosting inside ASP.NET: This will embed the whole compiler into the ASP.NET process, eliminating about one second for each compilation of a piece of code. In the past, for each request for an uncompiled resource, we would have to call the compiler, wait for its output and then load the output. This typically shaves between 0.7 to 1 second on those scenarios, ideal to improve the developer experience.
LINQ Class Libraries: This will allow us to reuse parts of the compiler in our System.Core implementation for LINQ for the current 3.5 generation and upcoming generations. Many corner cases are handled by the compiler, and we will now be able to lift those pieces. This will mostly use the backend of the compiler.
Detailed InvalidCastException Goodness Comes to a VM Near You.
When you perform an invalid cast in Mono (trying to force one type into another with a cast) or JIT would throw an InvalidCastException. If you are lucky, you would get a line number (compile with -g, run with --debug), but if you had a complicated expression you would have no idea what the problem was.
A few weeks ago, in support of Marek's growing pains in tracking down some bugs, Zoltan checked in support for a new feature in the Mono runtime: --debug=casts. Now, When you pass this option to the runtime, it will report the type that you are trying to cast. This feature is not activated by default as it generates more code, and consumes more memory.
This sample:
$ cat demo.cs
class Test {
static void Main ()
{
string s = "hola";
object j = s;
object d = (Test) j;
}
}
$ mono demo.exe
Unhandled Exception: System.InvalidCastException: Cannot cast from source type to destination type.
at Test.Main () [0x00000]
$ mono --debug=casts demo.exe
Unhandled Exception: System.InvalidCastException: Unable to cast object of type 'System.String' to type 'Test'.
at Test.Main () [0x00008] in /tmp/demo.cs:10
Awesome.
Generic Code Sharing: Good and Bad News
Mark Probst has been working for the past few months on adding support to the Mono JIT to support generic code sharing. This is a technique that allows the JIT to share the same code generated for two differently instantiated types, for example:
class Stack<T> {
T [] data = new T [10];
int top;
public void Push (T t) { data [top++] = t; }
public T Pop () { return data [--top]; }
public int Count { get { return top; } }
}
class Test {
static void Main ()
{
Stack<long> ls = new Stack<long> ();
ls.Push (10);
Stack<Test> ts = new Stack<Test> ();
ts.Push (new Test ());
Console.WriteLine ("Count={0} {1}", ls.Count, ts.Count);
}
}
The JIT must generate different code for the actual Stack instantiation, one must contain a pointer (32 bits on 32 bit machines) and another one must contain 64 bits. So the structures are different in memory, and so is the implementation for Push and Pop.
But certain methods do not depend on the datatype sizes (for example) and could be shared regardless of how their container type is instantiated.
Mark posted the Good news, the bad news and his strategy to deal with the bad news. Am going to limit myself to the good news, and you can click on the link and read the thread for the bad news:
Now for some interesting statistics. Apart from the runtime's test suite I've used three other test suites/benchmarks, namely IronPython (running pystone), Nemerle (compiling its own compiler) and FSharp (compiling and running a Hello World program). Here are the Good-News-statistics. The numbers given are "no sharing / sharing" and have been collected on a 32 bit system: IronPython Methods compiled: 3614 / 3368 native code space used: 719k / 691k Nemerle Method compiled: 7210 / 6302 native code space used: 2001k / 1943k FSharp Methods compiled: 15529 / 11431 native code space used: 2193k / 2062k
See his post for the rest.
Update: Mark informs me that the "bad news" that I conveniently left out of this post (memory consumption in FSharp for bookkeeping was 600k of memory) has now been fixed.
The 600k of bookkeeping in the FSharp test has been now turned down to 14k. So we can scratch that "bad news" part. Congratulations Mark!
Open Source Powershell Implementation
This weekend ath the Code Camp in Waltham, Igor Moochnick announced the release of pash his open source power shell implementation. It currently runs on Linux, MacOS, WindowsCE and Windows.
pash on Linux.
Igor's project is hosted on sourceforge.
A few years ago Ryan Paul from Arstechnica wrote a nice guide to powershell (when it was still called Monad Shell).
OOXML: The Wins
Regardless of where you stand on the outcome of OOXML becoming an ISO standard, it is worth pointing out that the opposition to OOXML pushed Microsoft into more open directions.
If you are sulking because OOXML was approved, it is worth looking at what actually was accomplished since December of 2005 when the process begun.
Before OOXML came to ISO and the global review of it begun:
- Microsoft moving away from their proprietary file formats to open, and XML-based (easier to manipulate, produce and consume) file formats.
- Novel raised a record number of issues on the specification, many of which were solved before the spec was approved by ECMA.
- About 700 pages worth of descriptions for the formula specifications (one of the major issues from our end when we joined ECMA TC45 in December of 2005).
- The OOXML specification placed under the OSP.
Once OOXML went for discussion at ISO, a number of good things came out and are major community wins:
1. The specifications for the old binary file formats were published under the OSP (February of 2008).
2. The above documents were backed up by the British Library in case Microsoft ever stops publishing them (announcement).
3. Microsoft is funding the development of a translator between the old binary file formats and OOXML which should assist folks that have experience in one format and want to understand the other, or just want to convert documents back and forth. If your app lacked support for OOXML, but had support for the old formats, you can use these tools.
4. Microsoft agreed that future versions of OOXML will be covered by the OSP a concern that some people had about future versions of the document.
5. Microsoft pledged to modify future versions of Office to implement the ISO version of OOXML.
6. working group was created to look into harmonization of OOXML and ODF, something that many developers involved in office suites have been advocating for a long time.
7. Microsoft pledged to support features to support other file formats as native file formats in their office suite:
Last year we sponsored a translator project that gave people the ability to read and write ODF files from Microsoft Office. Last month we announced that we would update the Office product so that the ODF translators could natively plug into Office and give people the same options they get from the other file formats. People will be able to set ODF as the default format in Office if that's what they want by simply installing the translators and then changing their settings.
8. Lots of clarifications went into the spec, and people should be happy about that.
9. And finally, now that OOXML is an ISO standard, as Patrick Durusau implied there are many winners.
Anyways, I wanted to keep this short and uplifting, this seems like a win for everyone all around.
Preemptive-reply-to-the-above-paragraph: I will not reply/approve any flames, FUD or half-truths.
.gif){kind=link}
OOXML, looking forward
I have been reading the OOXML storm in a teacup for more than a year now. Am looking forward to the approval of OOXML as an ISO standard and to be able to move the discussion back to the things that actually matter: free and open source software.
For a year, countless bytes have been wasted on what is now a very difficult plot to follow, specially for people that have not followed it since the start (or as Bill Maher said last week "Its like trying to make sense of a LOST episode". Note: am a Lost fan).
When we go back to what matters, we should be ready to ask IBM to open source its Lotus Notes software based on Open Office (as staunch supporters of open formats, and open source, I think its in their best interest to do so). There are nice components in Lotus Notes that would be nice to integrate into the upcoming OpenOffice 3.
But most importantly, it is a time for all of those strong advocates of open standards to stop talking, and start walking. I look forward for all that energy that went into discussing the pros and cons of OOXML to join an open source project and start contributing code, documentation, support, create support forums, file good bug reports and help us make free and open source software better.
In case you have not been noticing, Apple is gaining market share on the desktop. Some of our own kernel hackers, desktop hackers, web hackers that used to be Linux or BSD users are flocking to the proprietary OSX.
We need to change that, lets reverse that trend, and lets focus on what actually matters: the free and open source desktop. To make this happen we will need all the help that we can get.
Punditry and lobbying will not get us very far, real work will.
Mono: 2008 Google Summer of Code
The Mono project will be participating once
again in the Google Summer of Code.
Although some ideas from various teams are available in our student projects page this year, I want to encourage students to feel free to submit ideas that they think should be done with Mono.
In past years, a handful of students suggested their own ideas as to what would be an interesting project to work on during the summer, we liked those and turned those into full fledged projects.
Feel free to suggest a project that you think would be useful to the Mono community, and to discuss your idea with us in the Mono Summer of Code IRC channel: #monosoc on irc.gnome.org
Documentation: Generics and CSS
Mono contributor Jonathan has been hard at work and has added support for Generics to Monodoc as well as importing the ECMA documentation for the new generic APIs.
Monodoc now also support man pages (we have a handful now, and we will later add all the mono ones) and we now render using a CSS stylesheet instead of the collection of gross hacks that we used to have.
Pastor Wright
From Dave Winer's blog:
Melroy Hodge, from Queens, NY, a contact on Twitter, sent a pointer to a YouTube video of a longer excerpt of Jeremiah Wright's post-911 sermon, one of the speeches that soundbites were shown repeatedly on cable news this week. I guess it's not surprising that the cable news excerpts gave a very misleading impression. (Next time this happens we must do an immediate fact-check.) http://www.youtube.com/watch?v=QOdlnzkeoyQThis is a must-watch video. Stop what you're doing, right now, and watch it.
I found myself captivated by Wright's ideas and the way he expresses them.
I agree with everything he said.
I would have been willing to cut him some slack, because this was less than a week after the attack, and those were crazy days, who knew what was coming next. But he was right, we have done what they did to us, and we're doing it again in Iraq. The US was led by despotic people and we followed; we wanted to punish someone, anyone, and it didn't matter if they had anything to do with what happened to us. And we did.
Read the whole post from Dave Winer's blog. The video as he says, is a must-watch.
Also, from the twitter-o-sphere:
Dog Whisperer
We became fans of the Dog Whisperer TV show from the Discovery Channel in the past few months. Sadly, we are unable to have a dog at home, so we might look for a new place.
My friend Shelly pointed me to Gladewell's article on the New Yorker about Cesar Milan, just as fun and interesting as watching the show.
OOXML SDK
Microsoft is working on a OOXML SDK for managed languages. They have announced a roadmap:
Being selfish here, I would love to see this SDK relreased under an MS-PL license myself, I think it would be great to get folks outside of the Windows world consume and produce OOXML files easily.
This is a win-win for everyone. Microsoft gets more products consuming and producing OOXML documents on the Windows and MacOS worlds through Mono, and we get a great API to use on Linux with .NET languages.
Although I have emailed a few friends, am not sure am reaching the right people inside Microsoft. I would love to discuss the advantages that MS-PLing the code base would have.
It has to be under a license like the MS-PL as opposed to just a license to use and distribute on Linux for this code to make it and be distributed eventually into Linux distributions.
Mono Debugger, now with 2.0 support
Last week, Martin Baulig announced that the debugger in trunk adds supports to many 2.0 features, our last major feature missing in the debugger.
The biggest news is that the debugger now has support for C# 2.0
features such as generics, anonymous methods and iterators:
* We can currently print fields in generic instances, print their
types and parent classes.
* Recursive generic types (see test/src/TestRecursiveGenerics.cs for
an example) are supported, but need more testing.
* There is some limited support for method invocations, but we can't
get their types yet.
* Support for anonymous methods and iterators should now be pretty
much complete; we can fully access captured variables etc.
To try out the updated debugger in trunk, you must use Mono from trunk. With this code in place, we have now started the work to integrate it into MonoDevelop.
MonoDevelop 1.1 (due in six months) will have support for the debugger.
Remote Debugging
Additionally, Harald announced that they have modified the Mono Debugger to support remote debugging (useful for debugging embedded systems for instance).
They wrote a detailed document on the architecture for their remote debugging framework.
Their work is now licensed under the MIT X11 license, which will allow us to integrate this directly into the Mono and Mono Debugger distributions.
Banshee Release
This is what Banshee looks like:
Banshee on Linux.
In other news, thanks to the work of Scott, Banshee will
soon be distributed for Windows as well:
Bringing open source media players to Windows.
Banshee uses Lluis'
Mono.Addins
framework to allow third party developers to extend banshee
with interesting new features.
Yesterday Aaron released
the 
MonoDevelop 1.0 has been Released
After a few years in the oven, we are ready to announce the first release of MonoDevelop. Lluis has put together a set of in-depth release notes that covers the major features available in MonoDevelop and links to various tutorials and screencasts as well as extensive screenshots of what is available in MonoDevelop 1.0.
MonoDevelop 1.0 is designed mostly for Linux developers creating Gnome and ASP.NET applications but MonoDevelop is also available for MacOS users that download our Mono installer and will still be useful if they are building Mono-based applications on OSX.
The IDE has many of the features that you would expect from a modern IDE for Mono: support for programming in multiple languages, an extensible design, editors and designers for ASP.NET and Gnome applications, integration with Unix toolchains and Visual Studio Solutions, support for source code control and following standard Unix development practices, integrated NUnit testing, Unix Packaging and Deployment (following the GNU conventions, and Mono conventions for libraries and packages), internationalization and localization, tools to maintain your project documentation and command line tools to access this functionality.
We have some pretty good language support in this release: C#, VisualBasic.NET, Java, C and C++. Check the previous link for the details as to how extensive the support is for each feature.
Some screencasts:
- Creating a Simple User Interface with MonoDevelop.
- Creating Custom Widgets with MonoDevelop.
- You wrote it, now you want to ship it, see how MonoDevelop can help you: Buildig Packages with MonoDevelop.
- Using Subversion to host your source code, see Using Version Control with MonoDevelop.
There is more documentation on MonoDevelop available as well.
The Early MonoDevelop History.
In late 2003, a few developers were looking for an IDE to write C# code in Linux, not something too fancy, but something that would provide Intellisense features.
Windows developers were used to Visual
Studio, and Mike Krueger and the developers at Alpha Sierra
Papa had created the very
successful SharpDevelop
project, a .NET Windows.Forms-based application. At the
time, Mono did not have a working Windows.Forms implementation
(it would take another three years before our official 1.0
release of Windows.Forms) so this ruled.
Although there had been an attempt to make SharpDevelop portable by Mike (with a variation on the theme of Eclipse's toolkit) this effort had not been completed, and SharpDevelop continued to be a Windows.Forms application.
Pedro Abelleira first extracted the editor and intellisense engine from SharpDevelop into a standalone component that rendered using Gtk# instead of Windows.Forms. This was back late in 2003. Initially it was only going to be a text editor.
Development started mostly on irc and quickly contributors started to porting various other pieces from SharpDevelop or rewriting the GUI components with Glade and Gtk#. By late 2003 Todd Berman had taken over the maintenance duties of MonoDevelop and sent me a email on December 31st:
Oh, and we are shooting for eating our own MonoDevelop dog food by the end of this coming weekend, and it looks like we will be there even before then.
History of the GUI Designers
As regular Gnome developers were were very happy using Glade and Gtk#'s [Widget] attributes to bind the XML GUI representation to our own variables. You double clicked on the .glade file, and Glade would launch from within MonoDevelop, you would tweak your UI, save it, and rerun from MonoDevelop.
Around this time Dan Winship from the desktop team started working on a new GUI designer for Gnome, the Stetic GUI designer. This was a Gtk#-based GUI designer, and the idea is that this could be embedded in other applications. An early screencast of Stetic capabilities is available here:
Stetic in March 2005.
Work continued, but Dan eventually moved on to other projects. By the end of 2005 we were looking at integrating a GUI designer directly into MonoDevelop and Stetic was not ready to do that, so instead Lluis integrated Glade-3 into MonoDevelop:
MonoDevelop with Glade-3, January 2006
This project did not live for too long. Glade-3 had to be patched, and we quickly realized that all the features that we wanted would require more than trivial changes to Glade-3. So we decided that instead of investing time in the C code base and the bridge to C#, that we would complete Stetic which was entirely written in C#, this is what it looks like today:
Stetic Designer inside MonoDevelop.
A complete screencast of Stetic and today's MonoDevelop integration shows all the work that Lluis and his team did to provide a smooth editing experience.
Today MonoDevelop not only supports forms design, but it also provides menu and toolbar editors and support for managing your icon collection in your application.
Menu editor
A key feature of .NET is the creation of reusable components. Lluis brought this to MonoDevelop and the stetic editor. This screencast shows how to create widget libraries with MonoDevelop and Stetic that you can later reuse in your projects or in other projects.
The Future
The team has already started work on the next release of MonoDevelop, version 1.1. Our goal is to release new versions of MonoDevelop every six months. To do this, we are planning on doing all of the disruptive changes on branches, and always keep our HEAD revision stable.
There are a number of incremental improvements on our task list, but also some exciting new features. There were many things that we could not get in time for 1.0 are being incorporated or implemented since the 1.0 tree branched a few months ago. Some of the new features that trunk users or alpha testers can get include:
New Managed Editor: The text editor is now entirely managed and has many new features like configurable keybindings (Really nice Emacs keybindings), split windows, Emacs/Firefox-like incremental search on a toolbar (no more annoying dialog box popping up in the middle of your source code) and one of the most requested features: region folding.
Moving to a fully managed widget written in C# gives us a lot of flexibility to improve the editor. This is a theme that was consistent in the 1.0 release, moving from Glade to Stetic and moving from the GdlDock to our own managed dock paid off every time in terms of developer agility and features that we could implement.
ASP.NET editor: new improvements will provide auto-complete and intellisense while editing .aspx files. Also, with the maturity of WebKit/Gtk we are hoping to replace Mozilla as the GUI editor for ASP.NET pages with this.
Integrated Debugging: Currently the Mono Debugger is only available as a command line tool. Our next release of MonoDevelop will provide debugging directly from the IDE.
Windows Port: There is now a Windows profile release of MonoDevelop. This will be great for developers that are building applications using Gtk# on Windows and want to get access to the Stetic GUI designer which currently requires them to use Linux to do this. It is not our intention to compete with SharpDevelop as an open source IDE for Windows Programmers although there might be some overlap.
msbuild-based model: We want to move to the Visual Studio build model to improve interoperability with Visual Studio, Blend and SharpDevelop and other tools that use msbuild files as their interoperability layer. This will allow developers to easily move across tools to work on different parts of a project.
XML Editor: A backport from SharpDevelop's XML editor has been integrated.
Future versions of MonoDevelop will extend on this feature set an integrate Ivan's Windows.Forms designer, Alan's Silverlight designer and improve Michael's ASP.NET designer.
Mono on the iPhone, video
This video shows the Mono C# compiler building a sample native ObjC# application on the iPhone and then running the resulting executable on the iPhone.
Pay special attention to the beautiful error messages that our C# compiler generates.
This is using the ObjC# bindings that provide access to the Objective-C APIs from C#.
Discussion of the bindings and the Cocoa# APIs takes place in the cocoa-sharp and mono-osx mailing lists.
Update: better version, this one the typing with two hands and with some widgets on the screen and some events hooked up:
See Geoff's Norton for more details and also this one with comic included.
Of course, the iPhone is a locked platform, and chances of people being allowed to run Mono seem low.
The real question is when Android will be open enough that we can do a port of Mono to it (there is no C SDK at this point for Android).
Mix 08
Just got back from Mix 08 in Las Vegas. It was good to catch up again with old friends and make new friends. As usual, the event was a blast. To me the big interesting news were Silverlight 2.0 and the ASP.NET MVC release (details at Phil's blog).
Ray's keynote was light on the details, and too abstract for my taste.
The IE8 announcements were interesting. Their contributed test suite for CSS is good news, and came up with two nice new features: activities and webslices. Both ideas and their specifications were released under the OSP, and apparently by the end of the day there was a Mozilla plugin that implemented Activities. Hopefully we will get WebSlices on Linux as well.
Of course my personal favorite were the Silverlight 2 updates.
Since I attended mostly the hallway session, am using this weekend to catch up on the actual sessions. But I loved Joe Stegman's presentation on Silverlight 2 which Mike Harsh described as "we wanted to show code, not slides, lots of examples; you know, developer porn".
Sadly, I could not make it back to Part 2 with Mike, as the room was full and the bouncers were turning people away (and I also missed the repeat the next day).
Office Ribbon
If you love the software that you build, Jensen Harris' presentation on the History of the Office Ribbon is probably the most inspiring talk I have seen in years.
Every developer building GUI applications should listen to this presentation. This is as inspiring as Joel's articles on UI design were a few years ago when we were working on GNOME 2 or Andy's focus on empowering users were back on the Eazel days.
Silverlight 2
First things first. Catching up with Silverlight 2 is a great place to get demos, samples, tutorials, presentations and in-depth coverage of what is new in Silverlight 2.
Silverlight 1.1 consisted of a .NET binding on top of the
core Silverlight 1.0 engine and the addition of the DLR and
DLR-based languages. This was never intended to be the last
word on it, and it was mostly a showcase of things to come.
Silverlight 2 is the evolution of the 1.1 model in a number of directions.
The distribution model: Possibly the most interesting change is that there is now a "core" of Silverlight that will be available on every system and a model to bundle extra libraries for Silverlight. This keeps the Silverlight 2 download small, but most importantly it means that Silverlight 2.0 can ship without having to complete and freeze the APIs for every possible feature that people want.
The "extras" collection of controls are delivered in this way (like the databound controls) as well as things like the DLR. This means that you can use the DLR today, and still allow the DLR and Iron* teams to continue working and improving it without locking developers to an old version of the DLR that would have been deployed with every 2.0 installation.
Some other important changes:
- The application model is more consistent, and some of the common usage patterns for applications are directly handled by the new model (download all assets at once).
- A control framework. In 1.0 and 1.1, every developer had to create his own control framework, with 2.0 the control framework is in the core, and there is a nice collection of standard controls available (with text input!).
- Styles: The control framework also allows for skinning of controls through XAML snippets. For instance, consider a button, there a number of states that a button is rendered as: focused, unfocused, pressed, not-pressed. To transition from one to the other you can specify a XAML storyboard that will transition the button from any state to any other state. And you can also controls what is rendered, and how, independently of the control itself.
- Seadragon images. This is the support to quickly download images and implement infinite zooming. See this TED presentation for the details and a nice demo.
- Networking: support for socket connections (there are many restrictions here on what can be done) and support for allowing clients to issue HTTP requests to other web sites (this is similar to Flash policy files for the same feature).
- Updated DLR and Iron*.
Open source Silverlight Controls
At the keynote Scott announced that the high-level Silverlight controls were going to be open sourced, they will be released under the MS-PL.
There was apparently a miss-understanding and the controls were released inadvertently under a more restrictive license, but both Scott and Brian confirmed that they wanted us to use those controls.
This is brilliant, not only because it helps us, but for a load of useful reasons: it will let developers learn how to write controls early on the Silverlight 2 release process and will allow developers to fine-tune controls if they don't do exactly what they need.
This is important in particular for things like the DataGrid view, as there history has shown that there is no one-size-fits-all (regardless of how parameterized these controls are)
Moonlight
On Thursday I did a presentation on Moonlight. Due to the
general nervousness of this presentation I forgot to do a few
demos that I wanted to show. I wanted to
show Popfly and wanted to show
the Silverlight Journal (both 1.0-based applications).
If you install Moonlight from SVN, you will be able to watch the presentation on Linux.
Sebastien is now working on the security aspects of Moonlight (auditing code, understanding the attack surface, trying to break our code). He posted an updated diagram of the trusted callers in the various Silverlight 2 assemblies.
Improving Mix
I personally would like to see "Meet the Experts" come back. Meet the Experts last year (and at the PDC) happens in the afternoon, as a last-session, there is food delivered and there are no other sessions scheduled, so its a good time for everyone to get together and quickly get some questions answered.
In my opinion, the bars and the party are no substitute for this session. Discussing styling of Silverlight controls on the bar goes more or less like this "WHAT ARE THE LIMITATIONS?", "NONE, YOU CAN CHANGE THE ENTIRE VISUAL TREE", "THE WHAT TREE?", "VISUAL", "WHAT?", "THE VISUAL TREE", "WHERE IS THE TREE?".
I still had a blast, but I would like to see "Meet the Experts" back on the agenda.
Mono on the iPhone
Luke Howard from PADL Software Ltd sent me some screenshots of Mono ported to the iPhone:
Some stats:
# hostinfo
Mach kernel version:
Darwin Kernel Version 9.0.0d1: Wed Oct 10 00:07:50 PDT 2007;
root:xnu-933.0.0.204.obj~7/RELEASE_ARM_S5L8900XRB
Kernel configured for a single processor only.
1 processor is physically available.
1 processor is logically available.
Processor type: armv6 (arm v6)
Processor active: 0
Primary memory available: 116.00 megabytes
Default processor set: 26 tasks, 164 threads, 1 processors
Load average: 0.00, Mach factor: 0.98
# export MONO_DISABLE_SHM=1
# ./mono hello.exe
Hello Mono World
#
Channel9 works with Moonlight!
I just got back from Mix, updates my Moonlight from SVN and the videos at channel9 are now working with Mono.
Inside Silverlight 2 Beta 1, an overview with Scott Guthrie
This is one of the important pieces of our media pipeline that was missing (support for the HTTP streaming protocol). The implementation is based on the work that Fernando and Rolf did using the recently released specifications that Microsoft published.
Sadly, I was not able to show that at Mix. Its also the first take, so more testing and exercising will be required.
Pre-Mix 08: Moonlight Updates
We have been hard at work in Moonlight and I
keep postponing when to blog some updates about our work every
few days hoping to cram some new feature in the blog post.
And every few days turn into every few weeks and the next thing you know what should have been published a month ago ends up being my pre-Mix post.
Some of the most important changes in the last two months have been:
Moonlight Media Pipeline: So far we had been using ffmpeg's pipeline to process media. This means that ffmpeg was in charge of detecting the media formats, locating the codecs, demultiplexing the data, and decoding the data into video and audio frames.
The ffmpeg pipeline was fine as a sample pipeline, but we needed a few more things. We needed more control over the pipeline to implement things like media streaming and supporting seek operations over HTTP; We want to be able to relicense the code under non-LGPL terms (for people that can not use the LGPL or some commercial uses) and we need to plug Microsoft's Media Pack media decoders.
Rolf rewrote our multimedia pipeline so that the code on SVN no longer depends on ffmpeg's pipeline and only uses ffmpeg's decoders for video and audio:
The end goal is to plug Microsoft's Media Pack (this contains the codecs video and audio) into Moonlight:
The installers that we currently distribute for Linux do not contain the ffmpeg media codecs. If you need to test media you will need to compile the code from source.
Streaming: With our new pipeline we are now able to stream media. In the past Moonlight downloaded the media file into the local file system, and only when the entire file was downloaded we would start the playback.
Moonlight can now start playback as soon as there is enough buffered data. This works for media that is only available over HTTP. Fernando has been working on the support for media that supports the MMS-over-HTTP (controlling seeking for example). Luckily, the specs for HTTP-based streaming to Windows Media servers were released last week (also the specs for the ASF container format, which should help validate our implementation).
Test Tools: As part of our collaboration with Microsoft we received various tools that are used to test Silverlight. We could not reuse the tools directly for Moonlight (too many Win32-isms, too hard to plug into Mozilla/Linux) so Jackson rewrote all of that code for Linux.
The test tools include plugins that expose Javascript APIs to control Silverlight and the browser, simulate user events and take snapshots of the screen. Microsoft has given us permission to open source our implementation of these tools.
This should help us in creating our own tests, and in checking our own code for regressions beyond the test suites that we will have received from them.
The code should hit SVN soon.
Mozilla Installers: We created some installers for Mozilla that should offer a one-click install experience for users on Linux.
Verifier: Rodrigo continues to work on Mono's CIL verifier and on strengthening the image loader, work that will not be used immediately for our Silverlight 1.0 support, but that will be important for 2.0 (when Mono is required).
Historically Mono had not been used to execute untrusted code as we mostly were a runtime for desktop and server applications and errors in the images fell directly in the "doctor it hurts when I do this" category.
But with Silverlight 2.0 the story changes, Mono will be executing potentially hostile code so this work is mandatory. Additionally, Sebastien has been improving Gendarme and his Monoxide tool to help in the audit process and we have created a security audit plan for the runtime. This work, like the verifier work is a work in progress.
In addition to using it for Silverlight, the verifier work will enable the SecondLife folks to allow the execution of binary code in their simulators instead of being limiting SecondLife to use LSL-based scripts.
Windowless Support: As it turns out Windowless rendering is used by many Silverlight applications. This is where Silverlight content seamlessly blends with the HTMl content. This is a must-have for things like Tafiti, the XamlPad, and the Vista simulator and nice-to-have for some other sites.
The good news is that Chris has implemented the support for it:
The bad news is that this is limited to Firefox 3.0, the 2.0 edition does not have support for Windowless rendering.
See Chris' blog entry for the details about the challenges and limitations of Moonlight/Windowless in Firefox/Linux.
Bug weeks: With the test suite running on Linux we have been focusing on passing all the Microsoft tests that we can and implementing the major features missing (like Windowless support).
Silverlight 2.0 Other than the JIT support for Silvelright 2.0 at this point we have not done any work on it (well there are 3 classes stubbed privately).
There are two reasons for this: the updated 2.0 API is not public and although we have access to it, it is a bit of a mess to try to keep two separate trees (public and private) to support this and since Mix is just around the corner, we will just wait until next week.
The second reason is that we want to focus on shipping 1.0, completing the media pack integration and working on the configuration aspects of Moonlight (auto-update configuration for instance).
Our Priorities
Everyone on the team has been working very hard to get all the pieces in place, and we are getting closer to completion. Every time we fix a bug, it has a nice ripple effect of fixing various other issues that we had seen in some sites at once.
Our priority currently is to ship Moonlight 1.0, and this means more or less:
- Integrate the Microsoft Media Pack.
- Complete our media pipeline.
- Fix all the bugs exposed by the test suites.
- Investigate some of the problems with some video card/driver configurations that seem to burn a lot of cycles.
- Improve the performance for heavily animated scenes.
Am excited about the Mix conference, looking forward to see the demos and what gets announced. And obviously very excited about my own session on Thursday to talk about Moonlight and Mono.
Time to go to sleep. Marek and myself are on a 7am flight and it will be hard to make it.
Wooohooo! Am on Channel9!
The interview that I had when I visited Microsoft for the Lang.NET 2008 has been posted to Channel9. Its a conversation between Charles, Dragos (from the Volta team) and myself on open source, .NET, Mono, Moonlight and other fun topics.
Mono and the Game Developers Conference
Last week some of us from the Mono team at Novell went to
San Francisco for the Game Developers Conference. As some of
my dear readers know, I was not much of a gamer a year ago,
and I do not claim to understand this industry.
Mono is currently being used by a major publisher [1] to script a new version of a popular franchise (the new edition) and Mono is also the engine that drives Unity3D for scripting and SecondLife is beta testing Mono now on their beta grid.
Other than being fascinated by Unity3D and SecondLife, we had not really paid much attention to games. But in the last nine months we started to get a constant stream of requests to license the Mono runtime to power more and more games.
When Joseph Hill joined Novell in January as Mono's product manager we started to revisit some of these request. People wanted to get a proprietary license for Mono to use on the PlayStation, the XBox and the Wii and some folks also wanted Mono under non-LGPL terms (as it turns out, important to prevent cheating).
Three weeks before the GDC conference, our in-house expert on the game industry Michael Hutchinson told us that this conference existed. In a couple of days we booked some space on the show and we got things in place, we were going to promote Mono as an accelerated scripting engine.
Mono in Games
As it turns out, .NET-based tools and .NET-based scripting of tools are pervasive in the game industry.
As for the games themselves, engines are typically written in a combination of C++, C and assembly language and the high-level code is written with scripting languages. Lua is the most popular language to embed in a game (a procedural C-like language) and Python, variations on Lisp and a never ending stream of evolved batch languages.
People want to reuse Mono on games for a few different tasks. These are some of the reasons that we know about:
- Speed: as games become more complex, and
people spend more money on software that takes
advantage of GPUs, optimizing compilers and even
special hardware for physics the weakest performance
spot on a game has typically been the language that
has been used to implement the high-level portions of
the game.
In a world that is increasingly green, it is a waste of perfectly healthy computer cycles to interpret your code when you can use an optimizing JIT compiler to run your code. - Mainstream Language Support: In some cases,
game companies have created their own languages,
evolved or modified existing languages (modified
versions of Lua are common). Some people would like
to get access to more mainstream languages to develop
their game logic.
In the short term, jumping from procedural languages to object oriented languages is a first jump.
Hopefully they will drink the functional kool-aid and use some of the C# functional features, or even F# to write their games. - Code Sharing: C# or .NET code that is today written to run on servers, or as part of the tools being used to create games can now be easily be reused on the game itself.
- Mainstream Tool Support: Many games engines are already being developed with Visual Studio. Game developers can use the same tools to develop and debug the high-level game play scripts that they use to develop and debug the game engine.
Luckily, developers that have been writing Lua code for years will be happy to know that they can compile their Lua code to run on Mono (and get the performance boost they need) by using the Lua2IL compiler.
Update: The always great Lua developers have pointed out that the new thing is not Lua2IL but LuaCLR.
Mono and XNA
Mono does not really attempt to compete with Microsoft XNA
Microsoft's XNA is an end-to-end solution for game developers that want to create games for Windows, the XBox and the Zune, the XNA approach is to write manage code on *top* of XNA.
This works for certain kinds of games, but in the game developer space, some developers need to support more than one console and the high-end games (am sure there is a technical terms for these) end up licensing game engines, audio engines, graphics and physics from all kinds of middleware vendors.
In those cases (even when targeting the XBox) C# and .NET would not be available to the game developer.
So we basically think of the Mono runtime merely as a fast scripting engine with all of the ECMA/ISO CLI benefits and not really as providers of gaming APIs.
There has been some discussion in the #mono channel recently about whether we would create or endorse a gaming API developed by a third party. Like blessing Tao or OpenTK as the standard way of building games for Mono.
Although there is some value in having a blessed set of libraries for Mono, and I have no problem if people want to call their libraries Mono.Gaming, at this point the team at Novell is not able to dedicate any cycles to this effort (we can provide spiritual support, along the lines of yelling "Go team! Go" from the sidelines).
Intrinsics and Parallel Code
Am personally fascinated by running computational code on the GPU or taking advantage of special CPU instructions at the runtime level. Last year I wrote a bit about how we could implement this in Mono (Microsoft has already an implementation) and later we even made it part of our interviewing process.
At the
conference some people asked as to whether it would be
possible to take advantage of the PlayStation3 six SPE
processors. During the conference I had no idea that there
was already a project using Mono on the PS3 with Linux that
already does this, but the idea sounded fascinating.
It is particularly fascinating because the SPEs on the PS3 do not have the same limitations than GPU computations have, these are full blown CPUs (with some memory limitations) but still general purpose computation devices.
Paolo pointed me to CellDotNet: A project to make it possible to run .NET code on the Cell architecture.. CellDotNet is basically a JIT compiler (written in entirely in C#) that can compile CIL bytecodes into native code for the PS3 SPE processors (this is a project from Klaus Hansen and Rasmus Halland).
They have ported the SciMark benchmark to use some vector operations in the SPE. Currently I am unable to report the numbers as I do not have a PS3 running Linux, but I am expensing a PS3 as we speak to be able to report these back to you dear readers.
What makes CellDotNet all the more interesting is combining C# new functional features with the the Parallel Extensions to .NET.
Two good articles to get a grasp on what this offers are: Optimize Managed Code For Multi-Core Machines and Parallel LINQ: Running Queries On Multi-Core Processors.
PLINQ is built on top of the Language Integrated Query (LINQ), and although it has been promoted mostly as a technology to do database queries, the Parallel LINQ extensions basically supports map/reduce inside C#.
These libraries are only available as a technology preview currently for .NET and they do not exist yet for Mono. Hopefully we will get these implemented at some point.
[1] Our contract with said major publisher does not allow me to disclose who they are or the the game they develop on my blog. But it allows Novell to publish the information on the Novell site. After a year of asking Novell people to put this information on the web site, the information has not yet been posted. So the mystery as to what this is will sadly continue.
Lang.NET talks available
The Lang.NET 2008 talks have been published.
They require Silverlight 1.0, but Moonlight compiled from source with ffmpeg support is able to play those presentations back.
If you are in a rush, see the following post for details on downloading the WMV file (so you do not need to install Moonlight from source on Linux).
Mono Hackweek Summary
Some of the Mono folks have blogged about their work for last week hack-week:
Paolo and Zoltan rearchitected the Regular expression library in Mono and got a 9x performance improvement in regular expression matching. The work had two components: redesign of the opcodes in the regular expression engine, and generating native code using Reflection.Emit. At least for the Language Shootout case, the new regular expression code is the second best (Tcl is faster, but apparently Tcl does not cope with Unicode regexes).
Wade worked on MythTV under XGL and making Tomboy Scale.
Andrew added Zeroconf/Bonjour support to Giver (a tool used to easily share files with friends or nearby users). And he also worked on Tasky a simple task management tool that integrates with Remember the Milk. He also wrote a command line tool to remotely control Tomboy. screencast.
Mike added support to importing data to his Exert Project (fitness/workout log software) that he started last Hack Week.
Sebastien revamped and added various new rules to Gendarme, our analyzer for CLI assemblies to spot errors and common programming mistakes.
He also improved its APIs and performance. He also started to fix some bugs in our class libraries based on the analysis done by Gendarme.
Jonathan ported his XMPP/VB.NET client to Mono:
And also got MonoDevelop running natively on Windows:
Jonathan Pryor spent the week polishing various loose ends. Including the release of his fantastic NDesk.GetOptions command-line parsing library and providing documentation to various components in Mono.
Atsushi worked on the implementation of WebHttpBinding (part of 3.5 WCF) and various other parts. See his blog for details.
Mark polished his MathMap composer tool.
Marek did some work towards replacing System.Reflection.Emit with Cecil. After some discussion we believe we can keep both backends, one to keep things as usual, and another to be used with MonoDevelop (so MCS provides the actual parsing for the editor intellisense and compile-as-you-type support).
Jackson worked on a couple of interesting demonstrations with Aaron, which hopefully they will be able to demo soon.
Carlos spent his time improving System.IO.Serial, there were a handful of events not implemented that he worked on.
Andreia and Marek worked on a Gtk# native client for Bugzilla.
Stephane created a new Gtk.Print/Cairo dialog for F-Spot and worked on support for TimeZones in F-Spot (code has not been commited yet).
Everaldo worked on packaging Mono for Maemo4. He has promised a number of blog posts detailing the work on GarMono, and the new packages that will be included on it.
Rolf continued to replace SRE with Cecil in the VB.NET compiler.
Lluis worked on improving Mono.Addins and creating an add-in for authoring add-ins in MonoDevelop.
Paolo early on also extended C# to allow inline-IL assembly language code (similar to __asm__ in C or C++ in some compilers). See the blog post for the various samples of C# with embedded IL.
Chris worked on a scheme compiler.
Jeff learned more about Regular Expressions than he wanted to. Update: Jeff wrote an add-in for MonoDevelop to do Evolution plugins in C#.
Update: I had not finished reading all the status reports on the mailing list. Dick Porter wrote bluetooth support for F-Spot. There is a bug in the system underlying bluetooth C libraries that prevents it from working correctly out of the box, but hopefully that will get fixed.
Update: Mike Krueger improved extensively the search functionality in MonoDevelop, it now implements Emacs/Mozilla-like searching and he also wrote an assembly browser/decompiler that is plugged right into the solution browser.
As for me, I spent the week going insane over the incredibly frustrating T61p problems with performance. Inspired by Marek's encouragement to learn LINQ and functional-style programming, I started a project that I abandoned quickly to implement a managed spreadsheet.
At least I learned two lessons: am more comfortable writing tokenizers using the regular call-back system than the automatically generated state machine from generators. I also learned that OOXML is very easy to parse, but it would be nice for PDF files to have hyperlinks in the spec.
I am probably missing a few things, but I did not catch all the blog posts this week.
Game Developer's Conference
Some of us in the Mono team are in San Francisco for the Game Developers Conference at the Moscone Center.
For more details see Joseph's post Mono at the Game Developers Conference.
Politics as Theater
My friend Jon Perr (he was Ximian's Marketing VP) did a fun presentation at Ignite Portland.
The presentation uses an unusual format: you talk for 5 minutes, and 20 slides are displayed, each for 15 seconds (they advance automatically).
Watch his presentation here. The slides contain more data than the 15 seconds allowed, so you can read that here (also check the notes).
ThinkPad T61P Speed Problems
I recently upgraded to a ThinkPad T61p. I did not reinstally my OS, but instead just moved the old hard drive into the new machine.
The new machine is supposed to run at 2.4Ghz when plugged to the AC power, but it keeps going down to 1.2Ghz when am trying to get some work done (start a build: cpu speed goes down; Start firefox, cpu speed goes down). When am idling, the CPU speed will happily go back to 2.4Ghz. It can get as bad as 800Mhz, and in fact, it tends to boot in that mode at 800Mhz so booting takes forever.
The machine is cool, unlike the last laptop it does not feel warm at all (perhaps because it never performs better than a PC/XT).
I have Googled and Googled and various people seem to be having this problem across some other machines and Linux distributions, but there does not seem to be any solution posted. This is also not a new problem.
gnome-power-manager shows that the speed policy is "Always Maximum Speed":
This is what cpufreq-info shows:
I have tried:
- powersave -f, it sometimes makes the machine go to 2.4Ghz, but it will happily go back to 1.2 a few seconds later.
- Setting the minimal frequency in
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
by writing 2401000 to it. This sometimes
works, but sometimes I get:
root# echo 2401000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq sh: echo: write error: Invalid argument
- Calling: cpufreq-set -c 0 -d 2401000 -u 2401000 -g userspace this again works sometimes but when the CPU insists on sticking to 1.2Ghz it will just produce an error.
- Variants on cpufreq-set's governor: I tried userspace, and performance. They both seem to fail sometimes, and work sometimes. When they work, the processor speeds only stays for a few seconds before it goes back to slow speed.
- Tried disabling the speed stepping support in the BIOS. Although /proc/cpuinfo then reports that the CPU is running at 2.4Ghz, regular benchmark programs show that the machine is actually running at 1.2Ghz (building mcs goes from 2.7 seconds to 4.7).
- Tried killing powesaved, gnome-power-manager to make sure they wre not interfering, they still do not work.
If you got some ideas, drop me an email, I will post any solutions
MonoDevelop goes to MacOS X
We have released an updated Mono 1.2.6 package for MacOS X that contains Imendio's Native Gtk+ for OSX, Gtk# and MonoDevelop with Mac support. It is now available from our downloads page.
MonoDevelop on OSX.
MonoDevelop has pretty much the same feature parity than Linux does. There are a few missing features that we hope to resolve in the future, and there is plenty of room to improve.
Our recent efforts to better support the OSX stem from our belief that some Windows expats will want to continue building .NET applications using the Mac. And once they have updated their applications to run on the Mac, the code will run just as well on Linux.
Also, we believe that Unity3D developers will find auto-complete a useful tool when writing extension scripts for Unity. No templates or integration yet, but hopefully we will have those in the future.
This is only our first step.
MonoDevelop for Windows
Eventually, we would also like to bring MonoDevelop to Windows. Not to compete with SharpDevelop as they are focused on being a great IDE for Window developers. Our focus will be in bringing Stetic (our Gtk# GUI designer) to developers building cross platform applications.
Updated Mono VM
Joseph
blogs about our updated Mono VM. This new release is
based on OpenSUSE 10.3 (instead of what we had been using
which was based on 10.2).
It includes various new .NET and Mono applications that we had not shipped before (and that you can find the Mono:Community section of the Build Service).
Lenovo ThinkPads preloaded with Linux
I was doing some shopping today for a Lenovo ThinkPad T series, and noticed that they are finally offering them with SUSE Linux Enterprise Desktop 10 preinstalled.
(At least in the US).
Election Results
Larry Lessig has a fantastic presentation, in the very best Larry Lessig style, of why he supports Obama over Hillary. Chris has a transcript of the presentation for those reading blogs from work.
While reading CNN summary:
But the two-term senator from New York surpassed the one-term senator from Illinois when voters were asked about experience, with 91 percent of voters saying she "has the right experience," versus just 5 percent who said the same thing about Obama.
Both John F Kennedy and Bill Clinton were younger than Obama is today when they became presidents. It seems odd that this fact is not mentioned more often. (Update: Raphael pointed out that I used the wrong word here; Sorry, not a native speaker and all that).
And Wonkette goes through the checklist: Hillary Pre-Election Day Cry For Points: Check:
With Super Tuesday coming tomorrow, and polls showing Hillary Clinton in a dead heat with Barack Obama in states like, let’s see... Connecticut... it seemed like a good opportunity to CRY again. Not that this has anything to do with anything, but Hillary Clinton did cry in New Haven today while discussing children’s health care, one of the various things that she cares about. We’re ashamed at Hillary for this: If she had planned it around mid-afternoon, it might be a fresher topic for the evening news cycle.
Which is at odds with the speech I heard from her appearance in Massachusetts two nights ago when I jumped in a taxi. She was yelling repeatedly "am ready to lead" with a loud and strident voice. Which makes the perfect timing for the crying all too suspicious.
Larry Lessig's post underlines an important point about the way that Obama is conducting his campaign vs the way Hillary is. Hillary will have a debt with all the lobbyist, there will be favors to repay, concesions to make, special initiatives to pass through congress.
The video with Hillary's position on taking lobbyist's money is educational. Not only she is very happy taking their money, but she also twists facts when she says "They represent real Americans, they actually do". She should have added "The top 1% of Americans", you know, the Americans that actually count.
This is the complete context for the debate where the previous video was taken from. Edwards and Obama interventions are brilliant, "we do not have to start for the next election to start reforming, we need to start a grass roots movement to start reform today". Edwards and Obama went down this path: they did not take lobbyist money. Watch the full thing.
Obama as a president would not have those ties, he refuses to take money from the lobbyists.
Moonlight Talks (Paris Tech Days, Las Vegas Mix 08)
Next week I will be in Paris for the Microsoft Tech Days talking about our work on Moonlight. JB Evain will be doing a tutorial on Moonlight on Monday as well. Sadly, due to all the work we have right now in Mono-land, I will only be in Paris for a very short time before I have to head back home. But hopefully Mono-ers and Opensourcers can have some dinner on Sunday night. Drop me an email.
I will also be speaking in depth at the Mix 08 about Moonlight. This will be a more detailed talk about Moonlight than the talk at Lang.NET which was more of a potpourri of Mono stories.
MathMap
Only recently I found out about Mark Probst's MathMap plugin for the GIMP. I ran into it when he posted about a new feature in it called the MathMap Composer.
Check out this video demostration of MathMap's Composer.
I would have put a good screen capture of it, but Google Video seems to have regressed and no longer lets user skip over parts of the video.
Mono Does Robotics
Shawn
at Cogmation has
written us to notify us
that Mono
is being used as the scripting engine for
their robotFoundry
application.
From their testimonial page:
We needed a portable cross-platform, architecture compiler system that would allow us to develop code on one OS or architecture and deploy it on another with out recompiling. The problem with using gcc was that for every target OS or architecture we would need a separate cross compiler. Additionally maintaining and developing this toolset would be a large task.Initially Python was selected as our cross platform language. Python was great but we were always concerned with its speed, especially in real-time applications.
We discovered Mono while we were evaluating 3D engines. Mono was successfully being used to develop video games and it was extremely fast. We performed a small test and compared the speed between Python and C# mono and were shocked at how fast mono was compared to python. In addition to the speed increase and portability, we now had the ability to allow our users to write scripts i