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.

Craig Dunn has turned his Monospace application for the iPhone into a Microsoft PDC application that conference attendees can use at the upcoming conference.

Mandatory screenshot:

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.

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.

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:

The Technology

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.

MonoDevelop and the iPhone

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.

Pros and Cons

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

The protocol used between the debugging agent running inside the Mono process and a debugger is implemented in the debugger-agent.c file.

Availability

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.

Screenshots

Brent has a nice gallery of screenshots of the debugger in action on his MonoTouch 1.2 with debugging released! post.

April IM logs:

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.

I woke up this morning and found that the amazing Craig Dunn put together an iPhone app for the Monospace Conference using MonoTouch!

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.

Over the past few weeks, the final details of the program for the Monospace Conference have been announced, and now the event is just less than two weeks away. Some key details you may have missed:

• The Monspace conference features 2 days of workshops and 2 days of Open Space sessions.
• The full conference agenda has been posted, and now includes a full day of MonoTouch training (Mono for the iPhone).
• The two-day open space sessions will be kicked off on Thursday with an Open Source Panel featuring Sam Ramji (CodePlex Foundation), Ayende Rahien (NHibernate and Castle Contributor), and Glenn Block (Managed Extensibility Framework) and moderated by Rod Paddock, Editor of CoDe Magazine.
• The famous, prolific and thorough Ayende Rahien will be speaking on NHibernate.
• Microsoft's own Glenn will be talking about the Managed Extesibility Framework.
• M David Peterson will be discussing Mono on Amazon EC2.
• The ThoughtWorks crew will be talking about F# on Mono.
• Eric Hexter from Headsprings will be covering ASP.NET MVC.

From the Mono team, various engineers will be presenting on special topics:

• Larry Ewing will talk about the Moonlight, the open source implementation from
• Aaron Bockover will talk about cross platform GUI development with Gtk#.
• Geoff Norton will discuss development with MonoTouch on the iPhone.
• Jackson Harper will talk about ASP.NET MVC development with Mono and Joseph Hill will discuss Mono Tools for Visual Studio.
• Rodrigo Kumpera from our JIT team will do a low-level talk on Mono's Virtual Machine covering some of the innovations on the VM that are Mono-specific.
• And I will focus on the schmoozing.

The Monospace conference will be held in Austin, TX on Tuesday, October 27 through Friday, October 30. To register for the event, visit the Monospace Conference Registration Page.

Check the program for more information.

Registered Monospace attendees will receive a $150 discount on MonoTouch, if they purchase in the month of October.

When we were designing the MonoTouch APIs we had to map some of the constructs used by CocoaTouch and Objective-C to what C# developer expect.

Like other modern toolkits, the behavior of a control can be customized by the programmer by hooking up to events and the responses to those events.

This is a common pattern used in other toolkits. In Gtk+ objects emit signals, and the programmer can connect event handlers to individual signals, for example this is how you would connect

void pause_player ()
{
	// pause the player.
}

void configure_pause ()
{
	button = gtk_button_new_with_label ("pause");
	gtk_signal_connect (button, "clicked", pause_player, NULL);
}
	

In the ECMA CLI world developers hook up to events by connecting to events directly in the object, it is similar in spirit:

void configure_pause ()
{
	button = new Button ("Pause");
	button.Clicked += delegate {
		// Pause the player here.
	};
}

In both the Gtk+ and the ECMA CLI worlds there can be multiple subscribers to the event.

In CocoaTouch, instead of having an event per action they use a pattern where the components emits all of its messages to an instance of an object. If a button were to emit messages like "clicked", "clicked_violently" and "caption_changed" all of those messages will be sent to an object that implemented the required interface.

I am going to give myself a literary license and use some terms loosely and write a little bit of imaginary C#.

A button implementation would look like this:

interface ButtonDelegate {
	optional void clicked ();
	optional void clicked_violently ();
	optional void caption_changed ();
}

class Button {
	public ButtonDelegate Delegate { get; set; }

	public Button (string text) { ... }

	public string Text {
		get { return text; }
		set {
			text = value;
			DoSomeRepainting ();
			Delegate.caption_changed ();
		}
	}

	public EventHandler ()
	{
		...
		if (event_this_is_the_user_clicking){
			// Send the message to the Delegate
			Delegate.clicked ();
		}
		

The user of the Button class then needs to implement the interface ButtonDelegate to respond to messages. This in Objective-C is made simple by allowing this interface to have optional methods.

This would not work with C# interfaces as those require that all the methods on the interface are implemented.

So we came up with a design that would blend those worlds together.

Supporting the Objective-C approach

We can support the Objective-C model where a class can satisfy the contract by just registering methods to respond to the actions. A user could respond to some events like this:

class Foo : NSObject { 
	void ConfigureButton ()
	{
		button = new Button ("pause");
		button.WeakDelegate = this;
	}
	
	[Export ("clicked")]
	void pause_clicked ()
	{
		// Pause the button.
	}
}

In MonoTouch we expose the "WeakDelegate" property as the weakly-typed version of the delegate, that means that you can assign to it anything that derives from the NSObject class, and respond to messages by just annotating your method with the [Export ("name")] attribute.

But weakly typing could introduce errors. What if the parameters of the method or the return value do not match the actual signature of the selector. If the developer introduce a typo, the compiler would not be able to point this out, and you would get a nice crash or some corrupt memory.

So we introduced strongly typed delegates, these require the programmer to implement a class and override methods that have a very specific signature. The code would then look like this:

class Foo : ButtonDelegate {
	void ConfigureButton ()
	{
		button = new Button ("pause");
		button.Delegate = this;
	}

	// strongly typed: override ensures that this method exists in
	// the base class, or the contract is not satisfied. 
	public override void pause_clicked ()
	{
		// Pause the button.
	}
}

The ButtonDelegate class is flagged with a special attribute, the [Model] attribute which informs the MonoTouch runtime that only methods that are overwritten from this class will be dispatched, any other methods will be considered optional and treated like optional methods.

The problem of course is that if you wanted to respond to multiple buttons, you would have to actually distinguish them somewhere in your pause_clicked with some sort of closure value, or use helper classes, one for each button that you want to respond to. But that is a minor detail.

So Objective-C developers that like the separation between model, view and controller can continue to use those patterns.

That being said, although there is a lot of literature and discussion about the clean separation of Models, Views and Controllers, most samples I run across are a hodgepodge of Controller code for all sorts of things. At least the production code and the samples I have seen make it obvious that the separation of concerns is mostly academic, and in practice an instance object becomes a general purpose responder to all events, very much like you see in Gtk+, Qt, or Winforms.

Our approach also has a limitation: the hodgepodge approach does not really work with the strongly-typed signatures as you can only derive from one class at a time. The solution is to use separate classes for each controller. Although that cleans things up and has some aesthetics associated with it in terms of clean separation of concerns, in my opinion, it is not very practical.

Supporting the C# style

With MonoTouch we wanted to preserve the C# style of programming where you could attach code to these notifications one-by-one.

With C# you can use anonymous methods or lambda functions. These are incredibly powerful as they are able to capture the environment in which they were created. This means that you can trivially pass information and share information between multiple handlers.

Additionally, you more than one method can "subscribe" to the same event, you are not limited to a single method being the receiving of the events.

This means that in MonoTouch you configure buttons like this:

void configure_button ()
{
	button = new UIButton (dims) { Text = "Pause" };
	button.Clicked += delegate {
		// Pause the video
	};
}

What MonoTouch does internally is that the first time that you attach to a C#-like event, it create an instance of the ButtonDelegate that merely raises the event in the C# style.

This means that you only pay for the memory usage if you use the feature. But when you do, you can subscribe to individual events and you can have more than one listener attached to the event.

The Pattern

Although we brought the pattern to most places in MonoTouch where a delegate was used, it is notably missing from the UITableView as we felt that the number of methods that had to be overwritten were too big for the model to make sense.

In a few instances like UITableView, we suggest that developers just use the strongly typed version of the delegate classes and override the methods accordingly.

One of the things that I would like to see is a UITableView derived class that can present the data and style the data entirely based on properties discovered at runtime with System.Reflection.

Another thing that I want to see is support for System.Data data binding style versions of the UITableView and other UI controls in a single page.

More details on the low-level implementation are available on the API design document on the web site.

Meinrad Recheis has lead the effort to bring a full managed GIT implementation to the .NET and Mono worlds and he just announced the release of GitSharp 0.1.3, the first public release of Git#.

The code is based on the original work from Kevin Thompson who ported the JGit Eclipse plugin to C#. Meinrad has put together a great community of contributors that integrated every JGit improvement, the credits for the first release are as follows:

• Dave Cameron: for fixing bugs
• Björn Carlson: for killing bugs that crept into the core
• caytchen: for porting huge parts of the transport layer, and hunting down nasty bugs. btw, what's your real name?
• Emeric Fermas: for eliminating some of the hardest to find bugs and for verifying the complete test suite against jgit
• Martinho Fernandes: for fixing bugs
• Andriano Machado: for porting massive amounts of code and tests, also fixing many bugs
• Jim Radford: for the continuous integration server account and the support
• Gil Ran: for porting and fixing lots of tests and initial efforts on Mono
• Dan Rigby: for porting and fixing tests
• rolenun: for the command line interface framework. hey, what is your real name?
• Mauricio Scheffer: for the testing and build server expertise and CI server trouble shooting
• Neil Stalker: for holding up the flag for git# on Mono compatibility and squashing bugs
• Kevin Thompson: for initially porting large amounts of code and letting me rise the baby

An easy to use API is being developed on top of the GIT core, check out some of the examples.