Chris posted the new rules for the moonlight-2-0 branch and how to start working on 3.0 stuff.
Another intesting post is David's initial take on bringing pixel shaders, perspective transforms and hardware acceleration to Moonlight.
Posted on 11 Nov 2009
Today is a big day for the Mono team, we just released the Mono Tools for Visual Studio. The goal of this release is to make it simpler for Visual Studio developers to deploy their applications on Linux. ASP.NET, Windows.Forms, server and console applications are supported. These are the major features in the release:
Deploy to Linux: You can deploy from Visual Studio to a Linux machine running Mono your software. We are using Universal Plug and Play to detect Linux machines on your local network, or you can enter the IP address of your favorite hosting provider.
Debug Linux system remotely from Visual Studio: Developers complained that our debugging story left much to be desired, that deploying to Linux was possible, but debugging cumbersome. We now allow you to debug your application running on Linux without ever having to leave Visual Studio.
You can continue to edit, build and debug the way you have always done it, but the software will be running on a Linux machine:
We hooked the Mono debugging engine to Visual Studio, so all the regular debugging tasks are available (watches, locals, breakpoints, stepping) that you come to expect from Visual Studio debugging are available.
Review your code for portability: We have integrated Mono's Migration Analysis (MOMA) tool into Visual Studio so you can check your software for Windows/Linux differences right from your IDE and work around APIs that do not exist in Linux or Mono and refactor your code accordingly.
Package your software for Linux: Right from Visual Studio you can package your .NET application in Linux native installation format. Just create a packaging project in your solution, configure your package and produce an RPM that you can distribute:
And finally, one of the most exciting features in this tool: go from shipping applications into shipping appliances in minutes:
You use our wizard to prepare your appliance, select a base operating system template (Server, Client, and base operating system) and off you go.
Once your appliance is built, you can test it and apply the finishing touches over the web (using a Flash applet that connects to our virtual machines in our data center) and when you are happy with the results, you can download and redistribute your appliance to your users.
Today, as a .NET developer, when you distribute your software to your users and customers, you probably have a list of requirements that goes like this:
Then your users can start installing your software. At that point, you initiate a series of support calls that go like this:
And repeat the above process for every single one of your users.
Basically, every user has to repeat the same steps. Everyone has to assemble the solutions made up of the operating system, various pieces of dependencies that you have and your software, like this:
The experience today is like trying to buy a car by buying the individual parts:
We believe that for a class of developers there is a better way.
We believe that we can help you put together the full car, and deliver the car in a single piece.
With appliances you can ship a pre-configured operating system, pre-configured database and every service pre-configured and installed together with your software to deliver a full package, so you prepare your software for distribution once, you configure the database once, and then you give your users a ready-to-run virtual machine, CD-ROM or USB stick:
SUSE Studio has been used to build Linux based appliances (over four thousand per week), and now we are making it easy for .NET developers to take advantage of one of Linux's strengths: it is free, it is open source, you can shrink it, you can grow it and you can ship your own version (and yes, we do provide the updates for all of the core components that you pick).
Check out our getting started document.
This is a cool use of Mono for Visual Studio debugging the Axiom 3D engine from the amazing Michael Cummings:
Visual Studio remotely debugging Axiom on an Ubuntu virtual machine hosted in Sun's VirtualBox.
Update: How to get it to work with Ubuntu
Posted on 10 Nov 2009
This is pretty sweet in a couple of levels.
Not only this is sweet in that these are the first set of 3rd party controls for MonoTouch, they are also sweet because the authors built these controls using Oxygene, their Object Pascal compiler.
Update: Some documentation can be found here: introducing Plateau for MonoTouch.
Posted on 09 Nov 2009
I missed this post from Friday.
Mark Probst has posted a call for testers for Mono's new garbage collector:
Our new garbage collector, SGen, is now at the point where it's ready for early testing. It's still a long way from being ready for production use - it's still slow and consumes too much memory, especially for long-running processes - but if you'd like to help us find bugs, please consider giving it a try. I'm especially interested in cases where Mono crashes or hangs with SGen (other than for memory exhaustion). The simpler the test cases the better. To use SGen instead of Boehm, configure mono with the switch "--with-gc=sgen". At this point it's only known to run on x86 and AMD64 Linux.
This collector is a precise-heap, conservative stack, moving, copying collector and will return unused memory back to the operating system. The details of this collector are available in our Compacting GC page.
I am rebuilding my own Mono with Compacting GC now as we speak.
Posted on 09 Nov 2009
Since this app is not on the AppStore, you need to compile it and use Ad-Hoc deployment to run it into your phone.
Update: If you do not have a Mac, come to our booth at the Microsoft PDC, and we will ad-hoc deploy the app for you.
Posted on 09 Nov 2009
Currently, Mono's Garbage Collector does not compact the heap and one of the problems that users have is that certain allocation patterns might result in a heap fragmentation that is hard to recover from. The observable side effect is that your process memory usage grows, but the memory is mostly unused:
You can read more about this in the Compacting GC page at the Mono web site.
Although a new GC is being developed to address this, the code is still not switched on by default in Mono as we do not consider it ready for production use (you must compiled Mono with --with-gc=sgen).
Avoid allocating very large buffers, instead allocate smaller buffers, and if you need to provide the illusion of a large buffer, hide this behind an interface.
If you must use large buffers, you might want to consider using MindTouch's ChunkedMemoryStream which exposes the same interface as MemoryStream, except that it uses 16k chunks instead of a very large buffer.
This will avoid the fragmentation for a very common use case.
Posted on 09 Nov 2009
April IM logs:
Posted on 04 Nov 2009
Today we released MonoTouch 1.2.
Perhaps the most important new feature in MonoTouch 1.2 is that it now has a debugger that supports debugging on both the iPhone simulator and on the iPhone/iPod Touch.
The debugger is integrated directly into MonoDevelop/OSX. All you have to do is select one of the debugging configurations (either Debug|iPhone or Debug|iPhoneSimulator):
and run your application:
To set breakpoints, you use the usual MonoDevelop UI, just click on the left-hand side of the editor, or use Command-/:
The debugger offers the usual watch windows, and also allows you to navigate object state by hovering over the value in the IDE:
Although this was developed for the iPhone, I should probably have said that this is Mono's new soft debugger engine.
The iPhone is once again a challenging platform to get debugging working on. Since Apple has not published the information necessary to implement something like GDB or Mono's own MDB and we are not going to reverse engineer the protocol, instead we created a new way of debugging Mono applications.
The Mono Debugger for the iPhone platform uses a soft-debugger. Unlike traditional debuggers that act like a fully controlling entity over the Mono process, the soft-debugger is actually a debugger that is built into the Mono process itself. MonoDevelop communicates with this debugger over a compact protocol, similar to what has been done in the past with Java debuggers:
We are providing a new library, the Mono.Debugger.Soft.dll that encapsulates the protocol and offers an API that developers can use to debug a remote Mono process.
On systems where we have access to breakpoints the soft debugging engine will use the standard operating system facilities to single step and set breakpoints.
But on systems like the iPhone and some video game consoles where there is no way to modify memory without special privileges we had to resort to a different technique. The Mono static compiler inserts special code at every sequence point that checks for single stepping or breakpoints. The code generated during these debug builds is larger, but it allows us to support the iPhone without having to resort to undocumented APIs in any form or shape.
When the user selects an application for debugging, MonoDevelop configures the application to contact MonoDevelop on startup and link the debugger to it, starts listening on a couple of ports (one for the debugging protocol, and one for redirecting standard output/standard error) and waits for the application on either the iPhone simulator or the iPhone to contact it.
Upon contact, the debugger handshake takes place and operation continues. For the simulator, this takes place with a local socket; for the device, this happens over a TCP/IP socket over WiFi.
One of the nice side effects of this approach to debugging is that it is possible to distribute binaries to testers (using the Ad-Hoc distribution model) and debug problems on a user's iPhone over the network.
To support this scenario, when you build applications with the "Debug|iPhone" configuration, MonoDevelop will modify your application's Settings file on the iPhone.
This allows your beta-testers to enable debugging and connect to your debugger for inspection. This is what the settings looks like:
The first port is the port where MonoDevelop will be listening to. The second port is the port where the standard output and standard error will be redirected to.
All of the Console.Output and Console.Error output will be sent to this port when debugging is enabled on the application.
There are pros and cons to the soft debugger approach.
Soft debuggers are unable to do low-level debugging or debug Mono itself (mixed-mode debugging) and they are unable to stop applications at will, all it can do is request politely that the application stops, and when the Mono runtime decides that it is a good time to stop, it will stop.
On the pro side, the soft debugger is easier to port and is more robust as it eliminates some dead-lock situations. These can happen when the runtime has been forcefully stopped by the debugger, and then the debugger invokes methods on the target. These methods in turn might require an internal lock that is currently held by a different thread.
The protocol used between the debugging agent running inside the Mono process and a debugger is implemented in the debugger-agent.c file.
MonoTouch customers will be offered the update the next time they start MonoDevelop or if they manually "Check for Updates" on the MonoDevelop IDE.
Users of MonoTouch for the iPhone simulator can get the it from the trial page.
The source code for the soft-debugger is available on SVN. The API to communicate with the Mono runtime is available in the Mono.Debugger.Soft assembly and the debugger itself has already been integrated into the Mono 2.6 branch and Mono trunk on SVN.
This should prove useful to other users of Mono that might benefit from a soft debugger like Unity3D or Second Life.
Brent has a nice gallery of screenshots of the debugger in action on his MonoTouch 1.2 with debugging released! post.
Posted on 04 Nov 2009
Today is the ten year anniversary of the incorporation of Ximian, Inc. A company founded by Nat Friedman and myself whose goal was to advance the state of the Linux desktop. It was also an excuse for Nat and myself to hang out as we had become best friends forever in the previous two years.
Our conversations over the years have always been a little surreal. I have megabytes worth of logs that look like this:
Ximian was made up of friends that shared this vision, and its founders had no startup, business or management experience when we launched the company. We learned on the job and we were advised by friends that believed in our goals, and by people that cared about our mission.
From the archive: Ettore Perazzoli, Raph Levien, Nat and myself in Summer of Linux.
Ximian hired 90% of its employees from open source contributors in the community and folks that we had met over mailing lists or IRC channels.
Nat was a Computer Science and Math graduate; I was a math drop out and we had no management experience. This means that we made every possible management mistake in the book, but all of our friends and employees stuck with us as we learned and as we worked to get the company off the ground.
This is an interesting time to reflect on 10 years of hacking adventures. Writing, funding and advancing the state of the art of open source. In the next few weeks, Nat and myself will be publishing some short stories from Ximian.
Today Ximian has been incorporated into Novell. Our goals have been expanded, but we still continue to work to advance the state of the art in Linux.
Looking forward to another 10 years of joy and hacking.
Posted on 19 Oct 2009
The app provides the schedule, access to the twitter feeds for the speakers and the conference, access to the MonoSpace blog, speaker profiles and access to their blogs and twitter feeds and a map to find the event.
You can learn more, see larger screenshots and download the code to run on your iPhone from Craig's Post.
Posted on 17 Oct 2009