[IronPython] MonoTouch support
dinov at microsoft.com
Mon Sep 28 04:41:19 CEST 2009
> Hi, I'm wondering what it would take in theory to get IronPython
> working on MonoTouch (http://monotouch.net/) - the framework for
> writing iPhone apps in C#.
> By that I mean that I'm trying to understand the technical obstacles
> that would need to be overcome and possible ways to overcome them
> (even if it means that e.g. you'd have to introduce abnormal
> restrictions or limitations on IronPython).
> One obvious one seems to be that the iPhone doesn't allow you to mark
> a chunk of data memory as executable, so it prevents any sort of
> runtime code generation (JIT). So maybe another way to look at the
> question is this: what would it take to make it possible to have
> IronPython support 100% AOT compilation?
> I'm looking at alternatives like Boo, which does work for iPhone
> development (via MonoTouch), but IronPython would be my first choice,
> even if there were some extra constraints.
There's a combination of things that we already have that will get you
close - but there's probably a lot of corner cases to be flushed out.
For starter there's general pre-compilation of scripts. In 2.0 we
added clr.CompileModules which will let you produce a DLL for a
script file. It also produces and EXE which will start off an
Next in order to use new-style classes we need a derived type. We
support this via clr.CompileSubclassTypes in 2.6. You can drop the
resulting DLL into the "DLLs" directory next to ipy.exe and we'll
pick up and use these types instead of generating types at runtime.
Both of those produce DLLs that will need to be compiled however
MonoTouch goes about compiling any user app.
The final obvious stumbling block is the call site rules that we
generate. Currently we have pre-compiled rules built into IronPython
for many of these. For others we have versions which can use
reflection in some cases. But these were all added for performance
enhancements not to provide general pre-compiled support. It probably
wouldn't be extremely difficult to force these to be interpreted
by the DLR expression tree interpreter instead though.
There's other limitations - for example you'll be limited in how many
arguments can be supported w/o doing code gen and things of that nature.
And there may be some other small gotchas here and there. Also once
that's all said and done there may be things we do that MonoTouch
doesn't support - I'm thinking of features related to generics such
as generic methods. But maybe they've worked out all of those issues
More information about the Ironpython-users