[IronPython] How do you detect operating systems from within IronPython?
I received a reminder today on a module I modified: v v v dsblank http://www.codeplex.com/site/users/view/dsblank wrote Today at 8:01 AM Remember that IronPython runs on many different operating systems. It isn't clear from the patch if this works on Mac and Linux under Mono. ^ ^ ^ Which brings up a really good point How do I tell what operating system IronPython is running on? The original module (webbrowser.py) has lots of operating systems specific code, all separated by: if os.platform[:3] == 'win' which I have modified to: if os.platform[:3] in ['win','cli'] but that assumes that mono emulates Windows to a high degree, which thing I doubt. The best guess I can make as to more correct code would be: if os.platform[:3] == 'win' or (os.platform[:3] == 'cli' and os.linesep == '\r\n') Yeeach! How should I really be doing it? -- Vernon Cole ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] How do you detect operating systems from within IronPython?
On Mon, Feb 21, 2011 at 11:05 AM, Vernon Cole vernondc...@gmail.com wrote: How should I really be doing it? os.name usually has the actual underlying OS, but depending on what you need to do it may be better to have a block that is just for 'cli' that calls into a .NET API, and let .NET/Mono smooth over the platform differences. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Arright dangit! Where is the OFFICIAL IronPython source code?
On Sun, Feb 20, 2011 at 23:39, Vernon Cole vernondc...@gmail.com wrote: Thanks! That worked great. Now here's my first direct contribution. see http://ironpython.codeplex.com/workitem/30218 for a version of webbrowser.py which actually works on cli. (and therefore import antigravity also works.) -- Vernon I think this would be better suited in the standard library at svn.python.org, rather than just within IronPython. Thoughts on that? I haven't followed long enough to know how standard library changes are usually handled around here, but you'd have to re-apply this change whenever re-syncing. As for the change, wouldn't it be cleaner to make a shortcut like windows = sys.platform in [win32, cli] and then test if windows:? ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] How do you detect operating systems from within IronPython?
This is probably almost a confession on this group, but I don't USE the .NET
API very often.
My reason for mucking with IronPython is left handed. I have this great
module which works on CPython 2.n and CPyton 3.n and I want it to work on
IronPython, too. I feel that the .NET API is almost as ungodly as the Java
API, and not quite as well documented. That's why I am working on
cross-platform tools, so the application programmer does not need to learn
the gnarly details of the API's. So I learn just barely enough .NET to make
my module work. The app programmer calls webbrowser.open('http://digvil.info')
and the magic happens. Then I go searching for another tool that application
programmers need. I don't really have a life.
So I wrote (okay, modified) a tool which calls into the .NET API and let
.NET/Mono smooth out the difference.
Next morning, I get a note from a Mono user that I may have screwed up. So
now I get to spend several more days thrashing around in an IDE that I don't
know and will probably never use again so that I can build a current copy of
Mono/IronPython to test against. [puff -- puff -- whew! Thanks, I feel
better now.]
Thanks for the hint about os.name. I was hoping for something a little more
definitive than 'nt', but it will suffice for the time being. What I was
originally looking for was an answer to the question does this operating
system use/require UAC elevation. Is there a .NET call which will answer
that question? Mono people -- can you tell me whether I need to use 'sudo'
in Ubuntu?
--
Vernon
On Mon, Feb 21, 2011 at 11:19 AM, Jeff Hardy jdha...@gmail.com wrote:
On Mon, Feb 21, 2011 at 11:05 AM, Vernon Cole vernondc...@gmail.com
wrote:
How should I really be doing it?
os.name usually has the actual underlying OS, but depending on what
you need to do it may be better to have a block that is just for 'cli'
that calls into a .NET API, and let .NET/Mono smooth over the platform
differences.
- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Arright dangit! Where is the OFFICIAL IronPython source code?
On Mon, Feb 21, 2011 at 11:58 AM, Brian Curtin brian.cur...@gmail.com wrote: I think this would be better suited in the standard library at svn.python.org, rather than just within IronPython. Thoughts on that? I haven't followed long enough to know how standard library changes are usually handled around here, but you'd have to re-apply this change whenever re-syncing. Generally we prefer to remain as close as possible to the CPython stdlib, but I think the 2.7 stdlib is pretty much frozen at this point. When switching to the 3.x stdlib, we'll figure out what can be pushed upstream and what should maybe be IronPython-specific. I'm hoping that, with 3.2 now out, the process of splitting off the stdlib can proceed, but I think it's held up by the hg transition as well. That would be ideal. As for the change, wouldn't it be cleaner to make a shortcut like windows = sys.platform in [win32, cli] and then test if windows:? The problem is that just 'cli' != 'windows' - it could be running on Linux or MacOS via Mono. The best I've found for identifying Windows is: sys.platform == 'win32' or (sys.platform == 'cli' and os.name == 'nt') or, just: os.name == 'nt' - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Arright dangit! Where is the OFFICIAL IronPython source code?
I agree with all of you. I was trying to get something that works in the default case (no switches, IronPython on Windows). I am not really equipped to test the other options. I'ld like to, but I'm not going to run out and buy a Mac just to test on. (If only I could.) If it only works in the default case, but not the edges, it's better than not working at all, IMHO. I'll spend more time working on it, then learn to make a patch file (last time I tried, Mark could not read it, and I ended up sending him the whole text) and re-submit. Will someone please volunteer to help me figure out why I can't build IPy on Ubuntu? I'll pay the phone/connection charges. -- Vernon http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Arright dangit! Where is the OFFICIAL IronPython source code?
Ubuntu doesn't have the latest version of Mono, which is required for the .NET 4.0 equivalent compiler (dmcs). You would have to build Mono from sources to get it. Alternatively, most other distributions seem to use the latest version (in particular, OpenSUSE and RHEL are actively supported by Mono). You can get a ready-made OpenSUSE VM from the Mono site. You may not even need to build IronPython using Mono. I'm using msbuild binaries on OpenSUSE at the moment and haven't had any issues (yet). Also, buying a Mac for testing appears to be the only option, since they don't allow the use of MacOS in VMs (legally, anyway). (I'm sure that will be taken into consideration when setting up CI, right...?) On Tue, Feb 22, 2011 at 08:41, Vernon Cole vernondc...@gmail.com wrote: I agree with all of you. I was trying to get something that works in the default case (no switches, IronPython on Windows). I am not really equipped to test the other options. I'ld like to, but I'm not going to run out and buy a Mac just to test on. (If only I could.) If it only works in the default case, but not the edges, it's better than not working at all, IMHO. I'll spend more time working on it, then learn to make a patch file (last time I tried, Mark could not read it, and I ended up sending him the whole text) and re-submit. Will someone please volunteer to help me figure out why I can't build IPy on Ubuntu? I'll pay the phone/connection charges. -- Vernon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IronPython 2.7 Release Candidate 1 is now available
On behalf of the entire IronPython team: We are pleased to announce the first Release Candidate for IronPython 2.7[1]. This release contains over two dozen bugs fixed in preparation for 2.7 Final. See the release notes for 2.7 Beta 2[2] for details and what has already been fixed in the earlier 2.7 prereleases. - IronPython Team [1] http://ironpython.codeplex.com/releases/view/61395 [2] http://ironpython.codeplex.com/releases/view/60193 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Arright dangit! Where is the OFFICIAL IronPython source code?
Or we can find the bloke who is not keeping Ubuntu Mono and Iron Python releases up to date and kick his errr... ummm (mumble)... It is pretty weird that the distro which always has the latest of everything is the one with the old IPy/Mono, where the one which is NEVER up to date (RHEL) has it. I'll do some investigating. I'm afraid my experiences with SUSE and Red Hat are what drove me to Ubuntu. I do almost all of my open source work on a laptop, and there is a limit to what I dare ask it to do. Two operating systems and six IDEs/languages are pushing it a bit. Running VM would be over the top. Perhaps I can set up another desktop when I get home. Thanks for the advice. Vernon On Mon, Feb 21, 2011 at 2:48 PM, Steve Dower s.j.do...@gmail.com wrote: Ubuntu doesn't have the latest version of Mono, which is required for the .NET 4.0 equivalent compiler (dmcs). You would have to build Mono from sources to get it. Alternatively, most other distributions seem to use the latest version (in particular, OpenSUSE and RHEL are actively supported by Mono). You can get a ready-made OpenSUSE VM from the Mono site. You may not even need to build IronPython using Mono. I'm using msbuild binaries on OpenSUSE at the moment and haven't had any issues (yet). Also, buying a Mac for testing appears to be the only option, since they don't allow the use of MacOS in VMs (legally, anyway). (I'm sure that will be taken into consideration when setting up CI, right...?) On Tue, Feb 22, 2011 at 08:41, Vernon Cole vernondc...@gmail.com wrote: I agree with all of you. I was trying to get something that works in the default case (no switches, IronPython on Windows). I am not really equipped to test the other options. I'ld like to, but I'm not going to run out and buy a Mac just to test on. (If only I could.) If it only works in the default case, but not the edges, it's better than not working at all, IMHO. I'll spend more time working on it, then learn to make a patch file (last time I tried, Mark could not read it, and I ended up sending him the whole text) and re-submit. Will someone please volunteer to help me figure out why I can't build IPy on Ubuntu? I'll pay the phone/connection charges. -- Vernon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Road to IronPython 2.7 (update)
Hi all, The following issues are blockers for IronPython 2.7: * #29841 - sysconfig traceback when starting 2.7B1 - http://ironpython.codeplex.com/workitem/29841 I don't know enough about Mono/MacOS/POSIX to fix this one properly. I haven't yet chercked what the Mono guys did to get it working on Linux. * (no issue) - Visual Studio tools The Visual Studio tools are basically broken right now - I can't launch or debug even the default console program. I think it's because it can't find the interpreter, but I thought I fixed that already. * (no issue) - silverlight support I have no idea what the status of the silverlight support is. Once these are resolved (one way of another) I think 2.7 will be ready to go. - Jeff P.S. In all honesty I would have preferred to call the latest release Beta 3 instead of RC1, but I had already changed the version strings and didn't want to change them back :|. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Road to IronPython 2.7 (update)
The tools problem seems to be to do with the installer. IPyTools (PythonRuntimeHost.cs:89-100) tries to load the installed path from HKLM\SOFTWARE\IronPython\2.7\(default). On my machine (Win7 x64, IPy 2.7 RC1 installed without IPyTools, which were built from source) this is actually in HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) which contains ipy64, which is then combined (PythonStarter.cs:69) with ipy.exe to make ipy64\ipy.exe as the interpreter path (which doesn't exist). If I set HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) to my actual install path (where ipy.exe is) it works fine. I assume this should be done in the installer. Steve On Tue, Feb 22, 2011 at 10:12, Jeff Hardy jdha...@gmail.com wrote: Hi all, The following issues are blockers for IronPython 2.7: * #29841 - sysconfig traceback when starting 2.7B1 - http://ironpython.codeplex.com/workitem/29841 I don't know enough about Mono/MacOS/POSIX to fix this one properly. I haven't yet chercked what the Mono guys did to get it working on Linux. * (no issue) - Visual Studio tools The Visual Studio tools are basically broken right now - I can't launch or debug even the default console program. I think it's because it can't find the interpreter, but I thought I fixed that already. * (no issue) - silverlight support I have no idea what the status of the silverlight support is. Once these are resolved (one way of another) I think 2.7 will be ready to go. - Jeff P.S. In all honesty I would have preferred to call the latest release Beta 3 instead of RC1, but I had already changed the version strings and didn't want to change them back :|. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Road to IronPython 2.7 (update)
I can do a quick test pass of the silverlight support. ~Jimmy On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower s.j.do...@gmail.com wrote: The tools problem seems to be to do with the installer. IPyTools (PythonRuntimeHost.cs:89-100) tries to load the installed path from HKLM\SOFTWARE\IronPython\2.7\(default). On my machine (Win7 x64, IPy 2.7 RC1 installed without IPyTools, which were built from source) this is actually in HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) which contains ipy64, which is then combined (PythonStarter.cs:69) with ipy.exe to make ipy64\ipy.exe as the interpreter path (which doesn't exist). If I set HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) to my actual install path (where ipy.exe is) it works fine. I assume this should be done in the installer. Steve On Tue, Feb 22, 2011 at 10:12, Jeff Hardy jdha...@gmail.com wrote: Hi all, The following issues are blockers for IronPython 2.7: * #29841 - sysconfig traceback when starting 2.7B1 - http://ironpython.codeplex.com/workitem/29841 I don't know enough about Mono/MacOS/POSIX to fix this one properly. I haven't yet chercked what the Mono guys did to get it working on Linux. * (no issue) - Visual Studio tools The Visual Studio tools are basically broken right now - I can't launch or debug even the default console program. I think it's because it can't find the interpreter, but I thought I fixed that already. * (no issue) - silverlight support I have no idea what the status of the silverlight support is. Once these are resolved (one way of another) I think 2.7 will be ready to go. - Jeff P.S. In all honesty I would have preferred to call the latest release Beta 3 instead of RC1, but I had already changed the version strings and didn't want to change them back :|. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Road to IronPython 2.7 (update)
Can you run w/ -X:ExceptionDetail? My guess is there's something different about Mono's big integer implementation when you do bigInt.ToString(X). We used to convert the string to hex ourselves but that was slower than .NETs ToString implementation so I switched to using ToString instead (and uuid goes through this path). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Tristan Zajonc Sent: Monday, February 21, 2011 6:11 PM To: Discussion of IronPython Subject: Re: [IronPython] Road to IronPython 2.7 (update) There seems to be some regressions between 2.6 and 2.7 for OSX/Mono. In particular, in addition to the traceback bug, the uuid module still has a problem: http://ironpython.codeplex.com/workitem/28904 Given that uuid appears all over the place, this is relatively serious, I think. I'd look into these, but the standard IronPython solution doesn't compile on OSX/Mono. Tristan On Mon, Feb 21, 2011 at 7:31 PM, Jimmy Schementi ji...@schementi.commailto:ji...@schementi.com wrote: I can do a quick test pass of the silverlight support. ~Jimmy On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower s.j.do...@gmail.commailto:s.j.do...@gmail.com wrote: The tools problem seems to be to do with the installer. IPyTools (PythonRuntimeHost.cs:89-100) tries to load the installed path from HKLM\SOFTWARE\IronPython\2.7\(default). On my machine (Win7 x64, IPy 2.7 RC1 installed without IPyTools, which were built from source) this is actually in HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) which contains ipy64, which is then combined (PythonStarter.cs:69) with ipy.exe to make ipy64\ipy.exe as the interpreter path (which doesn't exist). If I set HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) to my actual install path (where ipy.exe is) it works fine. I assume this should be done in the installer. Steve On Tue, Feb 22, 2011 at 10:12, Jeff Hardy jdha...@gmail.commailto:jdha...@gmail.com wrote: Hi all, The following issues are blockers for IronPython 2.7: * #29841 - sysconfig traceback when starting 2.7B1 - http://ironpython.codeplex.com/workitem/29841 I don't know enough about Mono/MacOS/POSIX to fix this one properly. I haven't yet chercked what the Mono guys did to get it working on Linux. * (no issue) - Visual Studio tools The Visual Studio tools are basically broken right now - I can't launch or debug even the default console program. I think it's because it can't find the interpreter, but I thought I fixed that already. * (no issue) - silverlight support I have no idea what the status of the silverlight support is. Once these are resolved (one way of another) I think 2.7 will be ready to go. - Jeff P.S. In all honesty I would have preferred to call the latest release Beta 3 instead of RC1, but I had already changed the version strings and didn't want to change them back :|. ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Road to IronPython 2.7 (update)
IronPython.Mono.sln should build fine on Mono 2.10 RC2. Tomas From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Tristan Zajonc Sent: Monday, February 21, 2011 6:11 PM To: Discussion of IronPython Subject: Re: [IronPython] Road to IronPython 2.7 (update) There seems to be some regressions between 2.6 and 2.7 for OSX/Mono. In particular, in addition to the traceback bug, the uuid module still has a problem: http://ironpython.codeplex.com/workitem/28904 Given that uuid appears all over the place, this is relatively serious, I think. I'd look into these, but the standard IronPython solution doesn't compile on OSX/Mono. Tristan On Mon, Feb 21, 2011 at 7:31 PM, Jimmy Schementi ji...@schementi.commailto:ji...@schementi.com wrote: I can do a quick test pass of the silverlight support. ~Jimmy On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower s.j.do...@gmail.commailto:s.j.do...@gmail.com wrote: The tools problem seems to be to do with the installer. IPyTools (PythonRuntimeHost.cs:89-100) tries to load the installed path from HKLM\SOFTWARE\IronPython\2.7\(default). On my machine (Win7 x64, IPy 2.7 RC1 installed without IPyTools, which were built from source) this is actually in HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) which contains ipy64, which is then combined (PythonStarter.cs:69) with ipy.exe to make ipy64\ipy.exe as the interpreter path (which doesn't exist). If I set HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) to my actual install path (where ipy.exe is) it works fine. I assume this should be done in the installer. Steve On Tue, Feb 22, 2011 at 10:12, Jeff Hardy jdha...@gmail.commailto:jdha...@gmail.com wrote: Hi all, The following issues are blockers for IronPython 2.7: * #29841 - sysconfig traceback when starting 2.7B1 - http://ironpython.codeplex.com/workitem/29841 I don't know enough about Mono/MacOS/POSIX to fix this one properly. I haven't yet chercked what the Mono guys did to get it working on Linux. * (no issue) - Visual Studio tools The Visual Studio tools are basically broken right now - I can't launch or debug even the default console program. I think it's because it can't find the interpreter, but I thought I fixed that already. * (no issue) - silverlight support I have no idea what the status of the silverlight support is. Once these are resolved (one way of another) I think 2.7 will be ready to go. - Jeff P.S. In all honesty I would have preferred to call the latest release Beta 3 instead of RC1, but I had already changed the version strings and didn't want to change them back :|. ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Road to IronPython 2.7 (update)
IronPython 2.7 RC 1 (2.7.0.30) on .NET 4.0.30319.1 Type help, copyright, credits or license for more information. import uuid Number overflow. at System.Numerics.BigInteger.op_Explicit (System.Numerics.BigInteger) 0x000aa at Microsoft.Scripting.Utils.MathUtils.AsInt32 (System.Numerics.BigInteger,int) 0x00067 at IronPython.Runtime.Operations.BigIntegerOps.Compare (System.Numerics.BigInteger,int) 0x00028 at (wrapper dynamic-method) object.CallSite.Target (System.Runtime.CompilerServices.Closure,System.Runtime.CompilerServices.CallSite,object,object) 0x0011d at System.Dynamic.UpdateDelegates.UpdateAndExecute2object, object, object (System.Runtime.CompilerServices.CallSite,object,object) 0x00382 at Microsoft.Scripting.Interpreter.DynamicInstruction`3object, object, object.Run (Microsoft.Scripting.Interpreter.InterpretedFrame) 0x000bc at Microsoft.Scripting.Interpreter.Interpreter.Run (Microsoft.Scripting.Interpreter.InterpretedFrame) 0x00077 OverflowError: Number overflow. On Mon, Feb 21, 2011 at 10:01 PM, Tomas Matousek tomas.matou...@microsoft.com wrote: IronPython.Mono.sln should build fine on Mono 2.10 RC2. Tomas *From:* users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] *On Behalf Of *Tristan Zajonc *Sent:* Monday, February 21, 2011 6:11 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Road to IronPython 2.7 (update) There seems to be some regressions between 2.6 and 2.7 for OSX/Mono. In particular, in addition to the traceback bug, the uuid module still has a problem: http://ironpython.codeplex.com/workitem/28904 Given that uuid appears all over the place, this is relatively serious, I think. I'd look into these, but the standard IronPython solution doesn't compile on OSX/Mono. Tristan On Mon, Feb 21, 2011 at 7:31 PM, Jimmy Schementi ji...@schementi.com wrote: I can do a quick test pass of the silverlight support. ~Jimmy On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower s.j.do...@gmail.com wrote: The tools problem seems to be to do with the installer. IPyTools (PythonRuntimeHost.cs:89-100) tries to load the installed path from HKLM\SOFTWARE\IronPython\2.7\(default). On my machine (Win7 x64, IPy 2.7 RC1 installed without IPyTools, which were built from source) this is actually in HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) which contains ipy64, which is then combined (PythonStarter.cs:69) with ipy.exe to make ipy64\ipy.exe as the interpreter path (which doesn't exist). If I set HKLM\SOFTWARE\Wow6432Node\IronPython\2.7\(default) to my actual install path (where ipy.exe is) it works fine. I assume this should be done in the installer. Steve On Tue, Feb 22, 2011 at 10:12, Jeff Hardy jdha...@gmail.com wrote: Hi all, The following issues are blockers for IronPython 2.7: * #29841 - sysconfig traceback when starting 2.7B1 - http://ironpython.codeplex.com/workitem/29841 I don't know enough about Mono/MacOS/POSIX to fix this one properly. I haven't yet chercked what the Mono guys did to get it working on Linux. * (no issue) - Visual Studio tools The Visual Studio tools are basically broken right now - I can't launch or debug even the default console program. I think it's because it can't find the interpreter, but I thought I fixed that already. * (no issue) - silverlight support I have no idea what the status of the silverlight support is. Once these are resolved (one way of another) I think 2.7 will be ready to go. - Jeff P.S. In all honesty I would have preferred to call the latest release Beta 3 instead of RC1, but I had already changed the version strings and didn't want to change them back :|. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
