I just noticed that I can barely fit in a shirt that used
to be my favorite two years ago. It must be the large
amount of fat in those carrots:
miguel: I think am becoming chubbier snorp: it's your part-time veggie diet snorp: carrots are high in fat snorp: stick to cow
An interview
with Nicholas Francis from Otee, the makers of the Unity game
development system.
The Unity folks have been reusing the Mono JIT engine as a game engine, here is a nice blurb about what Mono got them:
If I have to pull out a specific feature it would be our scripting interface: We use Mono to get C#, JavaScript and Boo languages in there for gamecode. This means you get a scripting language running incredibly fast (*footnote: Initially, we used Python for GooBall. With that we were spending 50% of the CPU time inside scripting code. When we switched to Mono, the same functionality dropped to 1-2% CPU usage - we were completely blown away with how fast it is.) so this is what you make your games in (we also have C++ plugins for people who are passionate about C++ or need to use an existing library). When you make a Mono class, all public variables show up in the inspector for easy modification. So basically, Scripts are 1st class citizens of Unity. We're also using Mono for extending Unity - It really is that good.
Hopefully, when I have some spare cycles (hahahaha) I would like to assist the Unity folks in porting their game engine to Linux.
Once we have a port to Linux, we could run most of the games unmodified (the only exception would be those that require C++ plugins), educational software, architecture and advertising software that is being built today with Unity.
Alan McGovern who worked with us last summer as part of the Google Summer of Code to build a BitTorrent API for Mono called MonoTorrent joined us at Novell this summer as an intern.
When Alan arrived in Cambridge we had just decided that we would start our hack-a-thon on Moonlight to demo whatever we could get done in 21 days to show at the Mix Paris event.
Alan worked in the summer on a XAML designer for Silverlight that he called "Lunar Eclipse":
Ok, do not make fun of it. The important stuff is the engine, not the looks. Am sure Christianism has a quote for this, but I would not know how to google it up, but something like "look at the heart, not at the look". And if not, it is probably on one of those self-help books that I got at a discount price on that bookstore in Newbury St before they shut down.
The idea was to write the Silverlight designer in Silverlight itself. Currently our designer uses Gtk+ for its user interface plus a Silverlight surface for the designer. We felt that we could also build a web version of it and hence tap into the MacOS crowd that would not have access to the Blend designer either.
He started when we barely got anything working, it was quite challenging, because every few hours the code would be in a completely different stage. He reported more bugs than anyone else as he was our first "native" user of Moonlight.
The designer is able to serialize the designs into XAML, it is possible to hand-edit the XAML and go back to the rendering surface and is also has a timeline editor for creating animations.
Some videos for your pleasure created by Alan:
Of course, our long term goals would be to polish this up and create a Mono Add-In for MonoDevelop to offer a complete Silverlight development stack on Linux.
On the development stack side, we have most of the bits to have a Silverlight development stack for Linux, Unix and MacOS ready. Sadly this will not be part of Mono 1.2.5, it will be part of our next release: Mono 1.2.6 scheduled for sometime in October or November. The adventurous among you can already use this by using Mono from SVN (for full instructions, see this link).
You might notice that LunarEclipse lacks file loading and file saving. This was because Alan insisted that file loading must use the Bittorrent protocol (his argument was that XAML files one day could span multiple gigabytes), but he did not know how to save files with Bittorrent.
For the time being, you can use cut-and-paste to load and save your XAML files. Either that, or send us a patch ;-)
Working with Alan this summer was a pleasure. It was my first time working with an Irish that considered the idea of a "seven course meal" to be a six-pack of Guinness and potatoes. The good news is that we turned him around, and by the end of the summer he was an avid chicken-quesadilla consumer.
Michael Natterer posts on the work to integrate the Gtk+ menu with the OSX menu:
A video is available here.
Congratulations to the folks involved in getting Gtk+ running on OSX.
Update: Replaced the ugly screenshot with a beautiful one from Mikael Hallendal from Imendio.
Dominik Schnitzer's Mirage is an automatic playlist generation plugin for the Banshee Media Player.
This is what makes it interesting:
Mirage uses the latest AI/music information retrieval techniques to compute a similarity model for each song. So before you can use Mirage to automatically compute playlists, your whole music collection has to be analyzed once.After it is analyzed just drag and drop a song you like on the Playlist Generator item in Banshee and a playlist with similar sounding music will be computed.
Mirage is by far not perfect! Yet :-) - Imagine it is a radio station playing songs from your collection.
Video: banshee-mirage.ogg.
This is the first on a series of posts to comment on the results from the students that contributed to Mono as part of the Google Summer of Code.
Laurent Debacker completed his Ribbons widget for Gtk#:
You can also see the widget in action in the following screencast: Ribbons-final.ogg.
Laurent posted his final SoC status report on this blog entry.
Laurent needs a special mention because he also documented this class.
My hope for this widget would be:
Update2: Laurent followed up with a proposal that he had drafted to improve MonoDevelop with the Ribbon UI. What a funny coincidence!
Update: Alan found some nice prior-art applications that used the Ribbon-like interface:
Alan posted on some blog comments a few months ago a much better screenshot. If you own that blog, and remember it, please post the link.
Found this today, it is a very nice testimonial from someone that tried out Mono to port their code using our VMware image.
This is for ProMesh.NET a Web platform built on top of the basic System.Web that replaces ASP.NET:
I was a little curious to see how ProMesh.NET (MVC Web Framework for .NET 2.0) would run on Mono (if at all), so I did the following:
Download the VMWare image with a pre-installed Mono installation on SUSE Linux 10.2 Download VMPlayer (free) Copied the latest ProMesh.NET source tree to the virtual machine Fired up MonoDevelop Compiled the framework... Works (well, it compiled) Copied the ProMesh.NET demo application to the virtual machine Compiled the demo app... Works! Started xsp2.exe (the lightweight .NET web server for Mono) Opened the index.ashx page using FireFox: WORKS Went through the complete demo site. Everything worked! I was utterly amazed by the painless process of compiling and running a ProMesh.NET application on Mono, something I've never tried before (I did have some previous experience with MonoDevelop, but not a lot).
This is pretty exciting stuff, knowing you can just grab your ProMesh.NET web application, dump it on a Linux box and run it from a Linux web server.
Some people continue their unabashed criticism of my life-style choices.
Yes, that was a meat burger with bacon. But as I also explained before we walked into the burger joint that consuming such a burger configuration was perfectly within the limits of my part-time vegetarianism.
I was not on veggy duty while I chugged it down.
Also, for those interested, recommended link of the day: The Meatrix.
Update: My critics have also pointed out my spelling mistakes in the sphere of meat-related naming actitives.
As a part-time vegetarian, I face some small problems. They do not bother me very much, but I feel discriminated by both my meat-eating friends and my full-time vegetarian friends.
The former mock my ways, the latter doubt my commitment.
Dave Winer has an interesting observation on blogging, fact checking and correcting previous statements.
Sometimes I use an "Update" tag when corrections are sent my way, sometimes I use a new post, sometimes I update and link, sometimes am guilty of being sloppy.
What is your take?
A few weeks ago Thomas introduced me to Achim Hasenmueller
from Innotek, the makers
of VirtualBox, an
open source virtual machine system (similar to VMware and
VirtualPC).
It turns out that much of the functionality of VirtualBox is exposed through COM interfaces and at least on Unix they use Mozilla's XPCOM as their COM layer.
Achim wanted to use Mono to script and control VirtualBox through its XPCOM interfaces.
The good news is that for the past few months, Jonathan Chambers has been working on adding COM support to Mono. Jonathan has some software that exposes COM interfaces, and wants to be able to control it from Mono, instantiate COM classes from Mono, consume COM interfaces from Mono and export Mono objects to COM applications.
Jonathan's initial goal was to support COM on Windows, but as the recent testing showed, Mono can use Mozilla's XPCOM to script VirtualBox.
Last time I talked to Jonathan he was putting together a tool that can import type libraries from XPCOM and generate the C# stubs that are necessary to get access to all the APIs exposed by XPCOM instead of having to manually bind each interface.
Hopefully Jonathan will post his sample code for folks that might be interested in using COM with Mono on Unix.
Here is a C# sample that he emailed me recently (for VirtualBox):
static void listVMs(IVirtualBox virtualBox)
{
IMachineCollection collection;
IMachineEnumerator enumerator = null;
collection = virtualBox.Machines;
if (collection == null) return;
enumerator = collection.Enumerate();
if (enumerator == null) return;
while (enumerator.HasMore)
{
IMachine machine = enumerator.Next;
if (machine != null){
IntPtr ptr;
string machineName;
ptr = machine.Name;
machineName = Marshal.PtrToStringUni(ptr);
Console.WriteLine ("\tName: {0}\n", machineName);
}
}
}
static int Main (string[] args)
{
int hr = 0;
nsIServiceManager sm;
hr = NativeMethods.NS_InitXPCOM2 (out sm, IntPtr.Zero, IntPtr.Zero);
IntPtr ptr;
nsIComponentRegistrar cr = (nsIComponentRegistrar)sm;
Guid kEventQueueServiceCID = new Guid("be761f00-a3b0-11d2-996c-0080c7cb1080");
sm.getService(kEventQueueServiceCID, typeof(nsIEventQueueService).GUID, out ptr);
nsIComponentManager cm = (nsIComponentManager)sm;
string NS_VIRTUALBOX_CONTRACTID = "@virtualbox.org/VirtualBox;1";
IVirtualBox virtualBox = (IVirtualBox)cm.createInstanceByContractID(
NS_VIRTUALBOX_CONTRACTID, null, typeof(IVirtualBox).GUID);
listVMs(virtualBox);
Marshal.ReleaseComObject (virtualBox);
NativeMethods.NS_ShutdownXPCOM(sm);
return 0;
}
The code above would also automatically work with any other .NET language (for scripting purposes, IronPython, and one day IronRuby).
COM does not exist on Unix as a service that applications can depend on. Developers today have a choice between using Mainsoft's COM runtime or embedding a variation of Mozilla's XPCOM in their application.
For example, VirtualBox today bundles a copy of XPCOM in its source code distribution.
Some folks have a lot of code that has been built with COM in mind and this should open the doors for folks to take advantage of it on Unix with Mono.
The Mainsoft developers have been busy
implementing the core foundation for ASP.NET AJAX. They
usually do all their testing on Grasshopper.
Recently System.Web.Extensions got added to the default build in Mono (I do not think this will make it into Mono 1.2.5, you will need to use the code from SVN for that) but we had not really tested it directly with Mono.
Onur Gumus posted a How To: ASP.NET Ajax with Mono document today.
For doing native development in Unix this is a bit cumbersome (due to all the new stuff that needs to be added to the Web.config file; Should we put most of this in the standard machine.config?) but if you are moving an application, the Web.config should have been produced by Visual Studio already.
Konstantin Triger reports that the open source ASP.NET AJAX Toolkit works on Grasshopper, we have not tested this directly with Mono and XSP, but hopefully someone will try it soon.
A useful Flash interactive application to browse how much money candidates have raised, how much they have spent and who are their major donors.
Three folks that have impressed me (Dennis Kucinich, Mike Gravel and Ron Paul Gravel) have raised very little money compared to the multi-million juggernauts in the mainstream.
Electability seems to be highly correlated to how much money these folks are raising and spending.
Cuando era niño, era fan de esta colección de
libros de Pemsa que tristemente ya no están a la venta.
Ahora un esfuerzo está tratando de digitalizar libros de segunda mano y completar un acervo histórico en línea (por Barrapunto).
Edd Dumbill has authored a superb summary on where Moonlight is.
He has put together a great description that pulls information from multiple sources to put together a really nice story and give a good idea of where we are headed to.
Ivan has posted the final status report for his Mono.Design work for the summer:
During the summer Ivan worked on implementing a Windows.Forms designer surface and various pieces of the infrastructure to load and save designs. He also worked on integrating Windows.Forms with Gtk# to enable the designer to be used from within MonoDevelop.
Read his entire report here and you can comment on his blog.
OMG2 OMG2 OMG2 OMG2 OMG2 
Mark
Probst pointed me out to the announcement of Canon's 40D
camera. I skipped over the 30D, so this is my
opportunity to continue shopping until I drop.
OMG3 OMG3: it can do Wifi file transfers and hook up to a GPS.
As a very happy Rhapsody customer, the news that Rhapsody will start selling DRM-less music at 0.89 cents a pop is ubertastic.
If I was European or Canadian I would be 30% more excited -- considering the falling dollar.
I have been using it mostly as a radio so far, and avoided purchasing music because it would be DRMed, but there are a bunch of titles that I would like to own.
Let the double-click all-amateur shopping begin!
Today I received my copy of the Annotated
C# Standard that Jon Jagger, Nigel Perry and Peter
Sestoft put together.
This book is an annotated version of the C# specification that comes with plenty of comments and contributions from people that have implemented the language (It has contributions from Mono's Marek Safar, Martin Baulig, Paolo Molaro, Raja Harinath and myself, but also from the C# team at Microsoft, contributors to ECMA and some universities that researched C#).
Jon has been passionate about C# for a long time. The C# specification that we distribute as part of Monodoc was based on his hyperlinked version of the standard.
Nigel contributed to both the CLI and C# standards over the years and recently joined Microsoft.
Peter has written a number of books (Java Precisely, C# Precisely) and is also behind the implementation of C5 a Generic Collection Library (this was a great test case for Mono's C# compiler: it was quite a challenge).
Congratulations to Jon, Nigel and Peter. They have been working on this project for a long time.
A few years ago we met Rafi at one of our Mono summits in Boston, he works for Mainsoft and he has always been amazing.
Watch his interview on what he is doing with Grasshopper here and here.
He talks about Mainsoft's contributions to Mono, about his testing procedures and the kind of things that are possible with Grasshopper when integrating ASP.NET applications when running on J2EE servers.
As you may or may not know, the Mono team is in the process
of switching from the Ximian Bugzilla to the Novell
Bugzilla. The Ximian Bugzilla installation is a very old,
patched, modified, buggy and unmaintained version of
Bugzilla. The Novell Bugzilla team has offered to take over
the maintenance of Bugzilla and give us both a modern Bugzilla
installation and access to various tools that will help our
process.
As part of this process we need everyone to create Novell.Com accounts.
When creating your Novell.Com account, please make sure to use the same e-mail address that you use to login to the Ximian Bugzilla. This will ensure that your Bugzilla configuration stays the same.
Please create your Novell.Com account now, so that you will be able to immediately access the Novell Bugzilla when we do the final switchover.
To create a Novell.Com account, please go to this URL and fill out the form: here
Important: To link your existing bugs from bugzilla.ximian.com to the new bugzilla make sure that you use the same email address in that form so you can keep tracking the bugs that we had for you before.
We appreciate all of the contributions that you have made to mono in the Ximian Bugzilla and hope that you will continue to contribute in the Novell Bugzilla.
Given Toshok's initial reaction to the lack of JSon support in Silverlight last night:
He decided to do something about it.
Silverlight is "webby" in that you can use plain text files and you can generate its content from PHP or any other webby framework by using the mighty print statement.
But XAML is annoying to type, it is webby, but its not uber-webby. It would be nice if Silverlight supported incarnation from JSon instead of incarnation from XAML, for one, it is more wrist friendly than XAML and it also a lot nicer on the eyes.
This morning Chris implemented a JSon to XAML. See his blog post.
This is done with a Javascript program, so it will work with your stock Silverlight installation.
It would be much nicer if Silverlight's Control class had a CreateFromJson in addition to CreateFromXaml.
See Chris post on the subject. You can now use syntax like this for Silverlight:
var json = {
Canvas: {
name: "Toplevel Canvas", children: {
TextBlock: {
Text: "Hello World"
}
}
}
}
Silverlight comes with a shrunk down version of the CLR called the CoreCLR and also comes with a reduced version of the core class libraries.
Silverlight uses a subset of the 2.0 API and removes a lot of stuff that would only be used on a desktop or a server and removes overloads that people are not likely going to use and according to some blog posts even things like System.Collections will be removed giving preference to the generics-based API in System.Collections.Generic.
Nice graphic showing my Inkscape skills:
To support this "thin" profile in Moonlight we had a couple of choices.
We really did not want to branch our source code and chop code left and right until we removed all the extra baggage. We also did not want to use compilation defines because that would get ugly very fast.
Instead what we did was productize Linker tool that was developed as part of the Google Summer of Code last year.
The Linker could take an assembly and a description of the desired API entry points and produce a new assembly that only contains the requested entry points plus any of its dependencies. Although the Linker from last year was able to do some basic linking, but as with all software projects, the devil is on the details. JB has been working on productizing the tool ever since he joined Novell back in May.
The idea was that we would feed the linker a superset of our 2.0 library (2.0 plus the handful of Silverlight-esque APIs) plus a linker description file, and it would produce the resulting Silverlight compatible assembly.
The above approach allowed us to minimize the number of ifdefs that were required in the source code. In addition to the linking stage we also needed a way of inject a number of security attributes (again to avoid having a mess of ifdefs everywhere).
So JB created new specialized tool that allows us to add, remove and validate assemblies. We call this the Tuner. Both the linker and the tuner are based on Cecil a library for handling CIL files.
The tuner can do most of the heavy lifting, but there are a couple of areas that still required human intervention:
Finally, since our C# compiler depends very strongly on its mscorlib (the reason we have 3 compilers today, one for each profile is linked precisely to this dependency on mscorlib) we had to add special support to the VM to allow the compiler to call into methods that we had hidden as part of the tuning process.
This afternoon for the first time JB was able to build the 2.1 profile from the start up to the Silverlight support libraries and the Silverlight plugin with the tuned assemblies.
Although we have been debugging Moonlight with 2.0 assemblies for the past few months due to some of the API changes some applications like the SimpleXPSViewer did not work.
There is still some work left to do as you can see from the warnings generated by the tuner, but we are getting there.
With the 2.1 profile in place it is now possible for people on Linux and MacOS to develop Silverlight applications without using Windows.
The bad news is that the 2.1 profile will not be available in Mono's 1.2.5 release as we branched that release a few weeks ago. So developers interested in doing Silverlight development on Linux or MacOS will have to wait until our 1.2.6 release in a couple of months.
In the meantime Ankit has added support to MonoDevelop for compiling existing Silverlight VS Solutions as well as generating Unix makefiles from the VS solution file. You must be using an SVN release of MonoDevelop (sadly, 0.15 wont do it). for this to work though:
bash$ mdtool generate-makefiles SilverlightAirlines.sln --simple-makefiles Creating configure script Creating rules.make Creating Makefile.include Adding variables to top-level Makefile Makefiles were successfully generated. bash$
The default is to generate auto-tools based makefiles. It is recommended that people with acid reflux, ulcers or other delicate stomach conditions use the --simple-makefiles option. --simple-makefiles produces a configure and Makefile script that are essentially the labor of love.
If we can sort out the license for the Silverlight.js template, we should also be able to ship MonoDevelop templates for creating Silverlight content.
Chris Toshok and myself will be in Microsoft offices in Redmond, WA from Monday to Wednesday next week. Email or post in the comments if you are interested in doing some kind of get together/dinner.
In related news, Jackson posted a screenshot of Silverlight Scribbler running on Moonlight on his blog:
Jackson and Sebastien also got parsing of XAML bezier paths working just in time for the June 21st demo, I like this screenshot:
An important component of Silverlight is a simplified security system for protecting what can be done and what can not be done by user code.
.NET 1.x and 2.x have a system called the "Code Access Security" (CAS) which Mono has never completely implemented since it there are very few applications that actually took advantage of it (Update: On the comments someone points out that CAS is fundamental for any uses of ClickOnce deployment; Mono has no support for ClickOnce deployment either). This is probably due to its complexity, which leads to people not trying it out in the first place.
With Silverlight it becomes very important to ensure that we can execute code in a secure fashion and without allowing malicious code to get access to any resources on the system. Code that is downloaded and executed inside Silverlight/Moonlight needs to be sandboxed.
This new security system is described in a few blog entries from Shawn Farkas:
Today Mark posted his first implementation of this new security system for Mono for use in Moonlight:
Here's a preliminary patch for CoreCLR security, including a small patch for System.Security. It should do pretty much everything with the exception of catching method calls via reflection (I'm not sure how this is handles in Silverlight yet, and Silverlight on my Windows machine doesn't like me anymore - grr). I've included a small C# test program which tries out all the different ways (of which I'm aware) to call a method. That'll become a regression test eventually.
If mono is called with "--security=core-clr" then security attributes are only honored in system assemblies (those in $(PREFIX)/lib/mono/2.1) - other assemblies are always security transparent. To do better testing there's also an option "--security=core-clr-test" which honors security attributes in all assemblies.
Comments are welcome.
In addition to the new CoreCLR security system, the needs of Silverlight have finally pushed us to implement the code verifier in Mono. This is currently under development by Rodrigo.
CoreCLR is very similar to the design that Jim Pubrick has prototyped for SecondLife. Hopefully Jim can switch to the CoreCLR security system. Some of the needs for sandboxing that folks like SecondLife have (execution of untrusted code) can be found in our MonoSandbox page.
This is a great summary of how the security system works, from Shawn Farkas:
Over the last week we took a look at the new Silverlight security model. When you're writing a Silverlight application though, there's a lot of information there that you may not want to wade through to get yourself unblocked. Here's a quick cheat sheet highlighting the important points that you'll need to know when working with the Silverlight security model:
- All applications written for Silverlight are security transparent. This means that they cannot: [details]
- Contain unverifiable code
- Call native code directly
- Silverlight applications can access public methods exposed by platform assemblies which are either: [details]
- Security transparent (neither the defining type nor the method has any security attributes)
- Security safe critical (the method has a SecuritySafeCriticalAttribute)
- Silverlight applications may contain types which derive from: [details]
- Other types defined in the application
- Unsealed, public, security transparent types and interfaces defined by the platform
- Silverlight applications may contain types which override virtual methods and implements interface methods which are: [details]
- Defined in the application itself
- Defined by the platform and are transparent or safe critical
Early this morning Jackson got the Silverlight Chess program working on Mono's Moonlight:
This demo did not work for a while as it requires that the x:Name declarations from controls created dynamically be merged with the container namescope.
Between Chris and Jackson the javascript bridge is complete enough that a few hours later (after fixing a double free) it is now possible to have the Mono VM play against the browser Javascript in Firefox/Linux as well:
Although the original plans were to only support Silverlight 1.1 because we thought that they would be very different runtime, it turns out that by supporting 1.1 we can also support 1.0.
Various 1.0 demos are working with our implementation as well. The limitations currently are more with our overall support than in a 1.0 vs 1.1 difference.
Testing the Chess on Windows vs MacOS on relatively similar hardware seems to give an edge to Windows (as I do not have any two identical machines to compare, it just feels like the Windows box is performing about twice as fast).
Am interested in finding out from folks that have similar hardware if there is any significant performance difference in the CoreCLR implementations between OSX and Windows.
The second screenshot is Mono running on a ThinkPad T60P (T2600@2.16GHz) am curious if someone with Windows with the same machine can report on the .NET vs Javascript nodes/sec.
I was reading a comparison
between Adobe's Tamarin JIT and Sun's HotSpot and there
was some discussion started by Chris:
Maybe, I'm missing something, but I really don't see why Mozilla doesn't build on the Java platform rather than Tamarin. Investing effort in writing a full ECMAScript 3 or 4 translator to JVM byte-code seems like an easier and faster way to get much better results than Tamarin.
To which one of Brendan Eich's replies was:
We don't depend on closed source in-process code, period. I've also mentioned the license requirements, not that it mattered due to the lateness of Java's open source transition (GPL alone is not ok).
I ran the same program that was posted there on Mono, and extrapolating the values (my machine is faster than Chris, but am using Java HotSpot 1.6):
Someone on the thread pointed out that using type
annotations might bring Tamarin to 11 seconds. Update: , but Chris was
not able to replicate that behavior..
It is clear that Mono's floating point performance is far from ideal. Currently Mono on x86-32 platforms is still using the x87 "stack" style of floating point operations as opposed to the more efficient XMM style of code generation that we used on x86-64. We should look into this.
Update: Mike ran the tests on x86-64 where Mono has a different floating point implementation and the results are promising, instead of being 4 times slower than Java in this test Mono is only 2 times slower.
That being said, for Mozilla purposes, it seems that using Mono as their JIT instead of Tamarin would be a better choice:
Planning-wise its probably too late to use Mono on Mozilla, which is a shame.
It might still be interesting to prototype using Mono + Rhyno as a Javascript engine or completing the DLR-based Javascript and see how fast it can get.
This could probably be prototyped on WebKit/Gtk easily.
There is some kind of bug in Mono's implementation of Silverlight that is causing ZeroGravity to claim that I have won:
But at least Aaron's favorite music is playing in the background.
In other news, Chris just got Silverpad Pad working with the refreshed version of Silverlight:
And Silverlight Airlines from the 1.1 Refresh:
Marek Safar reports on the progress on the C# 3.0 compiler front:
This week:
Finished 3.0 type inference. Next Week:
Review and finish the implementation of collection initializers and anonymous types. They are the only remaining bits to have all LINQ components ready for the integration.
Pretty much all the C# 3.0 features are now completed. As Marek points out there are a couple of areas that still need some work (collection initializers and anonymous types), but we are in good shape to complete the LINQ support in Mono's C# compiler.
JB Evain has also been busy creating a new profile of our compiler for developing Silverlight applications. The new command is smcs and it differs from gmcs in the following ways:
The majority of our C# 3.0 support will be available in Mono 1.2.5. The recent developments (type inference) did not make it into the release, so folks will have to wait for 1.2.6.
Last year we had a pretty fun meeting in Boston, but there were a few problems: the event was too short, and renting the hotel was too expensive and we also announced it with very little time ahead.
We want to do another Mono Summit and we would like to do this event in Spain if possible. The reason is that it is relatively easy to reach Spain and for the European Mono developers (the majority of the Mono team is European) it would be cheaper to fly there than to fly to the US. Spain is also a bit cheaper than other destinations.
I would like to find a University that could host us for a week of talks, meetings and conferences of the Mono community.
We would need space for about 120-150 people: maybe some conference rooms for a couple of talks, otherwise classrooms and a place to hack, discuss and some internet connection would be all that we need. This would be sometime in October.
My preference would be for Madrid or Barcelona as they both are well connected by international air travel.
Anyone out there interested in hosting us?
