Road to IronPython 2.7 (update)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Road to IronPython 2.7 (update)

Jeff Hardy-4
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
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Steve Dower
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 <[hidden email]> 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
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Jimmy Schementi-3
I can do a quick test pass of the silverlight support.
~Jimmy



On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Tristan Zajonc
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:


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 <[hidden email]> wrote:
I can do a quick test pass of the silverlight support.
~Jimmy



On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Dino Viehland

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: [hidden email] [mailto:[hidden email]] 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:

 

 

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 <[hidden email]> wrote:

I can do a quick test pass of the silverlight support.
~Jimmy




On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Tomas Matousek
In reply to this post by Tristan Zajonc

IronPython.Mono.sln should build fine on Mono 2.10 RC2.

 

Tomas

 

From: [hidden email] [mailto:[hidden email]] 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:

 

 

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 <[hidden email]> wrote:

I can do a quick test pass of the silverlight support.
~Jimmy




On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Tristan Zajonc
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.UpdateAndExecute2<object, object, object> (System.Runtime.CompilerServices.CallSite,object,object) <0x00382>
at Microsoft.Scripting.Interpreter.DynamicInstruction`3<object, 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 <[hidden email]> wrote:

IronPython.Mono.sln should build fine on Mono 2.10 RC2.

 

Tomas

 

From: [hidden email] [mailto:[hidden email]] 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:

 

 

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 <[hidden email]> wrote:

I can do a quick test pass of the silverlight support.
~Jimmy




On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Tristan Zajonc
In reply to this post by Tomas Matousek
Tomas,

Have you compiled on OSX with MonoDevelop?  When I try this with latest Mono 2.10/MonoDevelop 2.4.2 and latest github ironlanguage code I get tons of issues.  That being said the latest MonoDevelop/Mono combo also doesn't seem to be working very well on their own either.  I have to go back several versions to get something stable.

Tristan

On Mon, Feb 21, 2011 at 10:01 PM, Tomas Matousek <[hidden email]> wrote:

IronPython.Mono.sln should build fine on Mono 2.10 RC2.

 

Tomas

 

From: [hidden email] [mailto:[hidden email]] 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:

 

 

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 <[hidden email]> wrote:

I can do a quick test pass of the silverlight support.
~Jimmy




On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Tomas Matousek

No. Have you tried building from command line?

 

xbuild IronPython.Mono.sln

 

Tomas

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Tristan Zajonc
Sent: Tuesday, February 22, 2011 12:07 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Road to IronPython 2.7 (update)

 

Tomas,

 

Have you compiled on OSX with MonoDevelop?  When I try this with latest Mono 2.10/MonoDevelop 2.4.2 and latest github ironlanguage code I get tons of issues.  That being said the latest MonoDevelop/Mono combo also doesn't seem to be working very well on their own either.  I have to go back several versions to get something stable.

 

Tristan

On Mon, Feb 21, 2011 at 10:01 PM, Tomas Matousek <[hidden email]> wrote:

IronPython.Mono.sln should build fine on Mono 2.10 RC2.

 

Tomas

 

From: [hidden email] [mailto:[hidden email]] 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:

 

 

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 <[hidden email]> wrote:

I can do a quick test pass of the silverlight support.
~Jimmy




On Mon, Feb 21, 2011 at 7:01 PM, Steve Dower <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Jeff Hardy-4
In reply to this post by Tristan Zajonc
On Tue, Feb 22, 2011 at 12:42 AM, Tristan Zajonc <[hidden email]> wrote:

> 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.UpdateAndExecute2<object, object, object>
> (System.Runtime.CompilerServices.CallSite,object,object) <0x00382>
> at Microsoft.Scripting.Interpreter.DynamicInstruction`3<object, object,
> object>.Run (Microsoft.Scripting.Interpreter.InterpretedFrame) <0x000bc>
> at Microsoft.Scripting.Interpreter.Interpreter.Run
> (Microsoft.Scripting.Interpreter.InterpretedFrame) <0x00077>
> OverflowError: Number overflow.

This *looks* like an issue in Mono, especially since it works on .NET.

Can you try computing '1<<128' on Mono? That seems to be the failing expression.

- Jeff
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Tristan Zajonc
>>> 1<<128
340282366920938463463374607431768211456L

Thomas: Hadn't tried that and it works.  (At some point it might be nice to try to get it working with MonoDevelop GUI.  When I load it it's targeting .NET 2.0 and has a bunch of issues.)

Tristan


On Tue, Feb 22, 2011 at 12:34 PM, Jeff Hardy <[hidden email]> wrote:
On Tue, Feb 22, 2011 at 12:42 AM, Tristan Zajonc <[hidden email]> wrote:
> 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.UpdateAndExecute2<object, object, object>
> (System.Runtime.CompilerServices.CallSite,object,object) <0x00382>
> at Microsoft.Scripting.Interpreter.DynamicInstruction`3<object, object,
> object>.Run (Microsoft.Scripting.Interpreter.InterpretedFrame) <0x000bc>
> at Microsoft.Scripting.Interpreter.Interpreter.Run
> (Microsoft.Scripting.Interpreter.InterpretedFrame) <0x00077>
> OverflowError: Number overflow.

This *looks* like an issue in Mono, especially since it works on .NET.

Can you try computing '1<<128' on Mono? That seems to be the failing expression.

- Jeff


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Tristan Zajonc
It appears to be because int is a very large long.  This is probably the core issue:

In IronPython:

>>> a=143098242404177361603877621312831893704 
Traceback (most recent call last):
OverflowError: Number overflow.
>>> a=143098242404177361603877621312831893704L
>>> a
143098242404177361603877621312831893704L

In Python:

>>> a=143098242404177361603877621312831893704
>>> a
143098242404177361603877621312831893704L
>>> a=143098242404177361603877621312831893704L
>>> a
143098242404177361603877621312831893704L
>>> 

Tristan

On Tue, Feb 22, 2011 at 1:39 PM, Tristan Zajonc <[hidden email]> wrote:
>>> 1<<128
340282366920938463463374607431768211456L

Thomas: Hadn't tried that and it works.  (At some point it might be nice to try to get it working with MonoDevelop GUI.  When I load it it's targeting .NET 2.0 and has a bunch of issues.)

Tristan


On Tue, Feb 22, 2011 at 12:34 PM, Jeff Hardy <[hidden email]> wrote:
On Tue, Feb 22, 2011 at 12:42 AM, Tristan Zajonc <[hidden email]> wrote:
> 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.UpdateAndExecute2<object, object, object>
> (System.Runtime.CompilerServices.CallSite,object,object) <0x00382>
> at Microsoft.Scripting.Interpreter.DynamicInstruction`3<object, object,
> object>.Run (Microsoft.Scripting.Interpreter.InterpretedFrame) <0x000bc>
> at Microsoft.Scripting.Interpreter.Interpreter.Run
> (Microsoft.Scripting.Interpreter.InterpretedFrame) <0x00077>
> OverflowError: Number overflow.

This *looks* like an issue in Mono, especially since it works on .NET.

Can you try computing '1<<128' on Mono? That seems to be the failing expression.

- Jeff



_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Jeff Hardy-4
On Tue, Feb 22, 2011 at 11:55 AM, Tristan Zajonc <[hidden email]> wrote:
> It appears to be because int is a very large long.  This is probably the
> core issue:
> In IronPython:
>>>> a=143098242404177361603877621312831893704
> Traceback (most recent call last):
> OverflowError: Number overflow.
>>>> a=143098242404177361603877621312831893704L
>>>> a
> 143098242404177361603877621312831893704L

This works for me on .NET, so it's almost certainly a Mono bug. Can
you reproduce it in a C# program?

Doesn't mean we can't work around it, though, but I'd prefer not too.
I've bumped it to high priority; one way or another it'll get fixed
for 2.7.

- Jeff
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Tristan Zajonc
Looks like a Mono Bug.  The following code prints both "small enough" and "big enough", which not true.

var a = System.Numerics.BigInteger.Parse("143098242404177361603877621312831893704");
Console.WriteLine(a);
if (a < System.Int32.MaxValue) {
Console.WriteLine("Small enough");
}
if (a > System.Int32.MinValue) {
Console.WriteLine("Big enough");
}

I will report this to Mono team.

Tristan

On Tue, Feb 22, 2011 at 2:09 PM, Jeff Hardy <[hidden email]> wrote:
On Tue, Feb 22, 2011 at 11:55 AM, Tristan Zajonc <[hidden email]> wrote:
> It appears to be because int is a very large long.  This is probably the
> core issue:
> In IronPython:
>>>> a=143098242404177361603877621312831893704
> Traceback (most recent call last):
> OverflowError: Number overflow.
>>>> a=143098242404177361603877621312831893704L
>>>> a
> 143098242404177361603877621312831893704L

This works for me on .NET, so it's almost certainly a Mono bug. Can
you reproduce it in a C# program?

Doesn't mean we can't work around it, though, but I'd prefer not too.
I've bumped it to high priority; one way or another it'll get fixed
for 2.7.

- Jeff


_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Reply | Threaded
Open this post in threaded view
|

Re: Road to IronPython 2.7 (update)

Jeff Hardy-4
In reply to this post by Steve Dower
Opened http://ironpython.codeplex.com/workitem/30240 as high priority. Thanks!

- Jeff

On Mon, Feb 21, 2011 at 5:01 PM, Steve Dower <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com