FePy Status Update (and IronPython on Mono)
FePy is the community edition of IronPython maintained by Seo Sanghyeon. It includes the Python standard library plus various bugfixes and compatibility wrappers for Python modules not normally available with IronPython. More importantly it is intended to be compiled with Mono. (Although the FePy binaries work on Windows and the Windows binaries work on Mono - which is the point of Mono.)
The latest released binary versions of FePy are for IronPython 1 and IronPython 2.0 Alpha 5. These are the versions that are included with Mono. Unfortunately they're pretty old.
Problems with the Mono compiler have prevented IronPython 2 being compiled with Mono. These aren't always bugs; they're usually places where the .NET compiler has a different interpretation of the C# standards to the Mono compiler, or even places where the IronPython sources rely on features of the .NET compiler that appear to actually violate the ECMA language specification for C#.
That aside Seo says that he reported the problems to the Mono developers some time ago and they appear to remain unfixed. However, Seo has had more luck compiling IronPython 2.6 (the development trunk which is still in Alpha) with Mono.
He does still intend to do an IronPython 2.0.x (2.0.2 is on the way soon) release of FePy when possible. He recently posted this status update to the IronPython mailing list:
The latest released binary versions of FePy are for IronPython 1 and IronPython 2.0 Alpha 5. These are the versions that are included with Mono. Unfortunately they're pretty old.
Problems with the Mono compiler have prevented IronPython 2 being compiled with Mono. These aren't always bugs; they're usually places where the .NET compiler has a different interpretation of the C# standards to the Mono compiler, or even places where the IronPython sources rely on features of the .NET compiler that appear to actually violate the ECMA language specification for C#.
That aside Seo says that he reported the problems to the Mono developers some time ago and they appear to remain unfixed. However, Seo has had more luck compiling IronPython 2.6 (the development trunk which is still in Alpha) with Mono.
He does still intend to do an IronPython 2.0.x (2.0.2 is on the way soon) release of FePy when possible. He recently posted this status update to the IronPython mailing list:
FePy seems to be dead, right? Sorry about that. This is a brief status update. And I could use it later as a changelog. How convenient.
1. I am now testing IronPython with CPython 2.6 standard library. FePy used 2.4 so far. Be sure to check collections.py issue Dave mentions. (Dave Fugate IronPython test and infrastructure guy.)
2. NAnt build system has been updated to the latest source layout change. My goal still is to do away with NAnt and improve Mono's implementation of MSBuild to build IronPython out of the box, but that hasn't progressed a bit, sorry. Dave wrote about the source layout change.
3. ExtensionAttribute problem mentioned in the last December is gone. Mono bug on reference equality with generic constraints mentioned in March is still there. FePy trunk patches/latest has a workaround for this. Net result is that latest IronPython source drops from CodePlex compiles and runs with Mono! And no compiler warnings! (This has been my pet peeve, you know.) And I had no problem keeping it that way for some time. I updated "IronPython on Mono reports" page with relevant mails.
4. There is an IronPython bug that manifests only on Mono due to newline difference. The symptom is that expressions are not printed in interactive console. This took some time to debug, but there is a fix now.
(Dino Veihland reports that this fix is now checked into the IronPython source code repository.)
5. Current build on my local system generally works. It imports urllib and urllib2. This is quite a stress test... Not just import, but downloading webpages work too. On the other hand, importing decimal crashes Mono in segmentation fault! I suspect this has to do with move to 2.6 standard library and its abstract base classes meta machineries, but who knows.
Comments
Post a Comment