Herb Sutter from the ISO C++ group, reached out to the Cairo folks: We are actively looking at the potential standardization of a basic 2D drawing library for ISO C++, and would like to base it on (or outright adopt, possibly as a binding) solid prior art in the form of an existing library.
And also: we are focused on current Cairo as a starting point, even though it's not C++ -- we believe Cairo itself it is very well written C (already in an OO style, already const-correct, etc.).
Congratulations to the Cairo guys for designing such a pleasant to use 2D API.
But this would not be a Saturday blog post without pointing out that Cairo's C-based API is easier and simpler to use than many of those C++ libraries out there. The more sophisticated the use of the C++ language to get some performance benefit, the more unpleasant the API is to use.
The incredibly powerful Antigrain sports an insanely fast software renderer and also a quite hostile template-based API.
We got to compare Antigrain and Cairo back when we worked on Moonlight. Cairo was the clear winner.
We built Moonlight in C++ for all the wrong reasons ("better performance", "memory usage") and was a decision we came to regret. Not only were the reasons wrong, it is not clear we got any performance benefit and it is clear that we did worse with memory usage.
But that is a story for another time.
Few guys have approached us recently about doing remote debugging of a Mono process. Typically this involves an underpowered system, or some kind of embedded system running Mono, and a fancy Mac or PC on the other end.
These are the instructions that Michael Hutchinson kindly provided on how to remotely debug your process using either Xamarin Studio or MonoDevelop: Remote debugging is actually really easy with the Mono soft debugger. The IDE sends commands over TCP/IP to the Mono Soft Debugger agent inside the runtime. Depending how you launch the debuggee, you can either have it connect to the IDE over TCP, or have it open a port and wait for the IDE to connect to it.
For simple prototyping purposes, you can just set the MONODEVELOP_SDB_TEST env var, and a new "Run->Run With->Custom Soft Debugger" command will show up in Xamarin Studio / MonoDevelop, and you can specify an arbitrary IP and port or connect or or listen on, and optionally a command to run. Then you just have to start the debuggee with the correct --debugger-agent arguments (see the Mono manpage for details), start the connection, and start debugging.
For a production workflow, you'd typically create a MonoDevelop addin with a debugger engine and session subclassing the soft debugger classes, and overriding how to launch the app and set up the connection parameters. You'd typically have a custom project type too subclassing the DotNetProject, so you could override how the project was built and executed, and so that the new debugger engine could be the primary debugger for projects of that type. You'd get all the default .NET/Mono project and debugger functionality "for free".
You can get some inspiration on how to build your own add-in from the old MeeGo add-in. It has bitrotted, since MeeGo is no more, but it is good enough as a starting point.