Awesome, thanks for the clarification on that. I suspected I had the wrong version. Oh, and it turns out the debugger client itself does *not* need os.popen.
cheers, JeffG Zoltan Varga wrote: > Hi, > > The upcoming mono 1.1.13 release will run IronPython 1.0 beta 1. > > Zoltan > > On 1/5/06, Jeff Griffiths <[EMAIL PROTECTED]> wrote: >> Hi Jim, >> >> Thanks for taking the time to go over our issues. I'll see about >> building a snapshot of Mono to see if that helps, and have passed along >> all of your comments to the dev team. Mono is important to us because >> Komodo is available for OS X and Linux as well. >> >> I remember vaguely the bit about using Python's libs with the IronPython >> interpreter, thanks for reminding me. We'll grind on this some more and >> let you know how it goes. >> >> cheers, JeffG >> >> Jim Hugunin wrote: >>> Hi Jeff, >>> >>> It would be cool to see IronPython running in Komodo. >>> >>> The makefile doesn't work out of the box on anything except MS's >>> SSCLI implementation. Your change to gmcs looks like the right one >>> to compile on Mono. The TAB bug is one we need to fix. >>> >>> The general experience people report with Mono is that IronPython >>> will run successfully on versions released after a given version of >>> IronPython. I know that the Mono team uses the test suite we ship as >>> part of their testing process. Because Mono is still in beta for >>> the CLIv2 features that we use, it can sometimes take a release for >>> them to catch up. I expect that this lag will go away as Mono gets >>> to a final CLIv2 compatible release and IronPython development slows >>> as we approach 1.0. Interestingly enough, the binaries that we ship >>> will often run on Mono even if the sources can't be completely >>> recompiled. You might want to try that. >>> >>> We'll take -u as a feature request, but if you have a work-around >>> it'll be pretty low priority. Our primary hosting work is centered >>> around making the CLS PythonEngine class as solid and easy to use as >>> possible. It never occurred to me that there'd be a desire to use >>> the command-line as a pseudo-hosting API. >>> >>> IronPython doesn't ship with any of the standard Python libraries >>> that are implemented in Python. It is designed to be used with the >>> Python-2.4 standard Lib directory - just add this to your site.py or >>> copy into the Lib dir with IronPython. You can get an initial os >>> module by doing this. That'll get you os.getcwd. The os.path you >>> get will be the ntpath (there was a recent message about this). >>> You'll probably want to replace that with the posixpath module on a >>> Unixy platform. Os.popen is probably some work, but is a priority >>> for us. This is something we want to get cleaned up. >>> >>> Similarly, you should be able to use the standard logging.py module. >>> I just tried this in beta 1 and it fails because our time module is >>> missing localtime. We're working on these issues too, but you might >>> find a stub module is the best way to get things going in the very >>> near term. >>> >>> Thanks and let us know if you get IronPython running in Komodo - Jim >>> >>> >>> -----Original Message----- From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Jeff >>> Griffiths Sent: Thursday, January 05, 2006 11:38 AM To: >>> [email protected] Subject: [IronPython] >>> IronPython 1.0 Beta 1 / Mono 1.1.12 Compilation >>> >>> I looked into getting IronPython working on Linux with Mono 1.1.12 >>> this morning. In my defense, I just hadn't seen anything about >>> whether this would work either way, so these problems are likely >>> known issues? >>> >>> Some problems: >>> >>> 1. makefile: I changed this: >>> >>> CSC=gmcs >>> >>> then got this: >>> >>> makefile:16: *** missing separator (did you mean TAB instead of 8 >>> spaces?). Stop. >>> >>> I changed the 8 spaces to a tab in vim, then got a little farther: >>> >>> [EMAIL PROTECTED] Src> make gmcs -t:library -r:bin/IronMath.dll >>> -out:bin/IronPython.dll -recurse:IronPython/*.cs >>> IronPython/Compiler/NewTypeMaker.cs(1011,17): error CS0019: Operator >>> `==' cannot be applied to operands of type >>> `System.RuntimeMethodHandle' and `System.RuntimeMethodHandle' >>> IronPython/Hosting/PythonEngine.cs(76,20): warning CS0219: The >>> variable `o' is assigned but its value is never used Compilation >>> failed: 1 error(s), 1 warnings make: *** [bin/IronPython.dll] Error 1 >>> >>> >>> >>> Is this a mono version incompatibility with 1.0 Beta 1? ( just >>> guessing ) >>> >>> Background: we're looking at IronPython to see what kind of effort is >>> involved in debugging it with Komodo. Using the MS .Net Runtime, >>> currently the issues are: >>> >>> - IronPython has no '-u' option. We can hack around this as we did >>> for Jython in the past. >>> >>> - IronPython does not have an 'os' module, which the PyDBGP client >>> currently depends on. Current os module usage includes: os.environ, >>> os.path.*, os.popen, os.getcwd. We have clever ideas about working >>> around this in a fepy-specific code path. >>> >>> - IronPython does not have the logging module. We could fairly easily >>> cobble up a stub one that was good enough... or look at porting >>> enough of the logging module. >>> >>> cheers, JeffG >>> >>> >>> _______________________________________________ users mailing list >>> [email protected] >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> _______________________________________________ users mailing list >>> [email protected] >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > _______________________________________________ > users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
