code praxis

I released a somewhat raw cut of my first android app a few weeks ago.  I love the platform, and OpenGL ES is pretty cool.

Planetoid: Solar Planet Orrery is an interactive simulation of the positions of the solar planets by date. You can change the angle of view or direction through time as you observe the planets orbit around the sun.

The idea man behind this is Ben, eminent LA astronomy and computer geek.

I am considering building a custom DI container, as it occurred to me our own custom providers or even the out-of-the box providers do most of the work. I had been describing the ‘provider’ to other coders as a powerful factory for a long time. Looking into Ninject, I found they describe how their DI bindings are resolved by a provider:

snip

Okay, so remember when we said type bindings were from a service type to an implementation type? Well, we lied. You caught us. Type binding is really a little bit more complicated than we let on. Rather than being from one type to another, bindings are actually from a service type to a provider. Simply put, a provider is an object that can create instances of another type. It’s like a factory, but specifically designed to work with Ninject.

/snip

Ninject is referring to their own concept of provider, but replace that with an ASP.NET provider or any one that pulls in XML config and you have the beginnings of a tiny DI framework.

A repository of well known FOSS is located at dotnetit.org. This includes Apache Xerces (an XML parser including DOM and SAX implementations), Apache Xalan (an XSLT and XPATH parser and processor), regexp libraries, cryptography libraries, etc.

An open source alternative .NET IDE is #develop. This project is coming along fast, and includes a library NRefactory that parses C# and VB.NET and IMO has a superior abstract syntax tree model than the CodeDom.

If broken it is, fix it you should is a great MSDN blog heavy in content that walks through debugging techniques for memory leaks, crashes and the like, using windbg and perfmon. Great place to learn how to poke around your heap from the command line.

The standard corlib doesn’t provide a good library to creating zip files (while it does do zip compression). If you’d like to do this but don’t want to use a third party check out Jon Galoway’s blog. In short, use the J# library and java.util.zip.

I got an email from someone who couldn’t compile GibberMonkey 0.1, after referencing spidermonkey-dotnet 0.2.0. GM code has undergone some changes since the 0.1 binary release. It and SM.NET 0.2 are in the process of being refactored to present a good API to the library user.

Enough catchup. The latest code from TFS on both projects will compile together. To be specific, the GM changeset 9678 will compile against the development branch ($/spidermonkeydotnet/development/spidermonkey-dotnet) SM.NET changeset 21914.

Also, if your a codeplex.com member you can simplify all this by joining the project and hitting the TFS and mapping these projects to your workspace.

I’ve branched the code, and pulled out the stuff I’ve been thinking about to set free (as in speech). This is basically just the raw bridge, no “generic object embedding”. Check out the project on the codeplex project page or on freshmeat. Future enhancements for this piece will include the debugger API, and not much else I can think of right now. More updates to come as I settle down (I’ve just relocated from NYC to LA).

I should apologize for all the bugs in CodePraxis.com lately. I upgraded to the “New Blogger,” which gained me nothing but a broken site. The XML feed of the new Blogger has different schema which has been the root cause of all the issues.

Yesterday I cut the initial release of my first project leveraging spidermonkey-dotnet. It is called GibberMonkey, and it is a JavaScript scriptable IRC bot, programmable even from the chatroom. Source code, .Net & Mono binaries are available on CodePlex. It is the result of a marriage between the SpiderMonkey engine & the SmartIrc4Net library. SmartIrc4Net is a C# library providing an API for communicating with an IRC server, documentation for this API is here.
Part of the purpose of GibberMonkey is to be the usability testbed for the new generic object embedding in spidermonkey-dotnet (see previous posts).

The SmartIrc4Net API is completely exposed to JavaScript, all done generically without specific embedding code. GibberMonkey itself is quite small because of this. The key feature that was missing in the alpha generic embedder was full support of delegates. What is now possible is for a JavaScript function (JSTYPE_FUNCTION) to be created at runtime and be mapped and stored automatically as any needed delegate type. Later on, managed code can make the callback to the JS engine seamlessly.

This solution was implemented by System.Reflection.Emitting a dynamic method of the necessary delegate type. Inside this method the parameters are moved into an array so we can eventually invoke the user JavaScript function via JS_CallFunction. Hardcore. GibberMonkey wraps dozens of SmartIrc4Net delegate types, and this is the primary method of customizing the bot’s behavior.

The alpha version of spidermonkey-dotnet now runs under Mono. Makefiles for Mono compilation and the above features are both in source control.

Embedding custom objects takes too much energy the SpiderMonkey way, and it only gets harder when doing it in C#. My latest work in the spidermonkey-dotnet library has been to abstract this whole process. This is possible thanks to the reflection API and Attributes provided by the .Net platform. The current target of this generic embedding process is the .Net API itself. Here is a screenshot of it in action:

That is a spidermonkey-dotnet shell (coming soon), executing JavaScript which creates a file and launches a modal System.Windows.Forms.Form. Cool. 

I gave some screenshots and a description in an earlier post of what I called “generic object embedding”. I’ve since forked this functionality into a “development” codebase because this aspect of spidermonkey-dotnet is still volatile. Release 0.2.0 [codeplex.com] is available, which also includes a javascript shell implemented with this new technique.

Now let’s take a look at our friend the Customer object refactored and with a few attributes added to the methods we want to embed:

public class Customer
{
    private int m_age;
    private string m_name;

    [JSMember()]
    public int Age
    {
        get { return m_age; }
        set { m_age = value; }
    }

    [JSMember()]
    public string Name
    {
        get { return m_name; }
        set { m_name = value; }
    }

    [JSMember()]
    public void SetName(string newName)
    {
        m_name = newName;
    }

    [JSMember()]
    public int ComputeReduction()
    {
        if (m_age < 25)
            return 10;
        else
            return 5;
    }
}

Now the only code needed to embed this object is the following line:

JSEmbedder.JSObjectInitialize(cxPtr, globPtr, IntPtr.Zero, typeof(Customer), true);

Here’s a screenshot of the shell enabled with the Customer object:

Looking into the performance of spidermonkey-dotnet, I decided to establish a baseline. Executing JavaScript calls to purely indigenous JavaScript functions and objects should perform as well as doing the same thing from an unmanaged program. I did exactly that, testing my own shell against Mozilla’s jsshell. The performance now matches a native-code only binary, after a fix to the problem below. The latest version of the project is available at http://www.codeplex.com/Wiki/View.aspx?ProjectName=spidermonkeydotnet. Following is a description of the bug, and how to avoid it.

The binding has several .Net delegates available that appear like this one:

[UnmanagedFunctionPointerAttribute(CallingConvention.Cdecl)]
public delegate Boolean JS_PropertyDelegate(IntPtr cx,
    IntPtr obj, Int32 id, IntPtr vp);

Objects are embedded in the engine by passing delegates instead of function pointers to the SpiderMonkey API. Whenever a delegate is called it incurs the overhead of interop, so when possible this needs to be avoided.

Here is another snip from the binding:

[DllImport("js32.dll")]
public static extern Boolean JS_PropertyStub(IntPtr cx,
    IntPtr obj, Int32 id, IntPtr vp);

JS_PropertyStub is the corresponding SpiderMonkey API function, that is used to define a class that does not require a custom handler. I had been passing this function pointer to the engine in the form of the delegate above.

new JS.JS_PropertyDelegate(JS.JS_PropertyStub)

The stubs are actually called by the API. In the case of the global object with all its callbacks set to stubs this is very often. Using the code above each of those calls causes marshalling overhead. This is because those delegates are not marshalled as function pointers in unmanaged memory (where the functions reside). The CLR is indeed marshalling all the parameters to the stub function into managed memory, and then back into unmanaged memory when it decides to call the real pointer. I realize this is a special case and I was a little too optimistic when coding this, but it would sure be nice if the marshalling smartened up just enough to pass in that raw pointer.

Now, in the new version of the binding, when passing stubs please acquire them as an IntPtrs using these functions:

public static IntPtr JS_GetPropertyStub()
public static IntPtr JS_GetEnumerateStub()
public static IntPtr JS_GetResolveStub()
public static IntPtr JS_GetConvertStub()
public static IntPtr JS_GetFinalizeStub()