Re: [IronPython] Rich comparison usage by IronPython's heapq implementation

2011-03-14 Thread Jeff Hardy 
Regardless of what's "correct", we should follow what CPython does
(plus, using only __lt__ and __eq__ makes sense). Can you try this in
2.7 to see if it's still an issue, and open a bug if it is? I doubt
we'll make any more changes to 2.6.

- Jeff

On Mon, Mar 14, 2011 at 6:04 AM, Robert Smallshire
 wrote:
> Hello,
> I recently ran into some issues with IronPython's heapq implementation
> whereby code that functions correctly on CPython failed with IronPython 2.6.
>  The issue is that the CPython implementation of heapq only calls __le__()
> and __eq__() on the heap elements whereas the IronPython implementation
> calls __le__(), __eq__() *and* __gt__().  Although it seems that IronPython
> is well within specification to do so, there are some statements in the
> Python documentation that only __le__() will be used for sorting.  Of
> course, it's arguable whether 'sorting' applies to heapq and indeed other
> similar algorithms or containers which rely on a defined ordering.
> In any case, this is an avoidable difference between CPython and IronPython
> which tripped me up.  I'm not sure whether the correct fix - if one is
> needed at all - is to IronPython's heapq implementation, to CPythons
> documentation, or to both.
> I wrote a little more about the issue here:
>   
> Rob
>
>
>
> ___
> 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] ArenaNet's Use of IronPython

2011-03-14 Thread Jeff Hardy 
That's awesome. I think it might be time to start a "Who's using
IronPython" page somewhere.

The upgrade to 2.7 should be pretty seamless, BTW. Is there anything
that you're missing? Anything that would make your use case easier?

- Jeff

On Mon, Mar 14, 2011 at 3:30 PM, Daniel Jennings  wrote:
> Just thought I’d share with you guys an article that among other things
> discusses how we at ArenaNet are using IronPython. We don’t go into many
> details about how important IronPython is to our editor, but we at least
> allude to it. Every time Python is mentioned it’s using IronPython J
>
>
>
> http://altdevblogaday.org/2011/03/13/before-you-wreck-yourself/
>
>
>
> Let me know if you have any questions about the boring details! We’re
> currently using 2.7A1, but that’s only because we haven’t taken the time to
> make sure that we’re immediately compatible with the later versions J
>
>
>
>
>
> Daniel Jennings
>
> ___
> 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] numpy / IronClad?

2011-03-14 Thread Jeff Hardy 
On Mon, Mar 14, 2011 at 11:30 AM, Chad Brockman  wrote:
> So I’m assuming no Silverlight then? For the same reasons?
>
>
>
> Thanks, Chad

I'm pretty sure Silverlight doesn't support native code, at least not
in the browser and phone.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] ArenaNet's Use of IronPython

2011-03-14 Thread Daniel Jennings 
Just thought I'd share with you guys an article that among other things 
discusses how we at ArenaNet are using IronPython. We 
don't go into many details about how important IronPython is to our editor, but 
we at least allude to it. Every time Python is mentioned it's using IronPython 
:)

http://altdevblogaday.org/2011/03/13/before-you-wreck-yourself/

Let me know if you have any questions about the boring details! We're currently 
using 2.7A1, but that's only because we haven't taken the time to make sure 
that we're immediately compatible with the later versions :)


Daniel Jennings
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] numpy / IronClad?

2011-03-14 Thread Jason McCampbell 
>
> So I’m assuming no Silverlight then? For the same reasons?
>

I'm not sure, I haven't used Silverlight. But if it can load the DLR is
should be able to use at least the functionality that is accessible through
.NET methods even if executing Python statements is difficult/restricted
 Moonlight won't work because of the C++/CLI limitation of course.

Jason
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] numpy / IronClad?

2011-03-14 Thread Chad Brockman 
So I’m assuming no Silverlight then? For the same reasons?

Thanks, Chad

From: Jason McCampbell [mailto:jmccampb...@enthought.com]
Sent: Monday, March 14, 2011 1:28 PM
To: Doug Blank
Cc: Discussion of IronPython; Chad Brockman
Subject: Re: [IronPython] numpy / IronClad?

As IronPython runs under many different operating systems now, it
would be useful to know what the dependencies are for numpy and scipy:

- is Windows a requirement?
- does it work under Mono?

No, not directly but practically for the short-term Windows is requires for the 
SciPy piece.  NumPy is quite cross-platform and uses the very cross-platform 
NumPy core (C code), a little bit of C++ code, and a bunch of C#.  I haven't 
tried building it on Mono recently but aside from getting the builds to work 
there shouldn't be a lot of work.  It does require .NET 4 so likely Mono 2.10 
will be a requirement.

SciPy is more restrictive because it relies on C++/CLI which is not supported 
on Mono.  The reason is that we are using the Cython tool to generate 
interfaces for CPython and IronPython from a single source.  Unfortunately 
because Cython allows users to import arbitrary C header files, C++/CLI was the 
only practical option for the time being.

- can IronRuby etc take advantage of these libraries?

Probably, at least some of the functionality.  The interface is straight .NET 
so C#, F# and other languages can make use of the NumPy ndarray object and 
other objects.  The biggest limitation is that a fair amount of the 
functionality is implemented in Python so it is necessary to evaluate Python 
expressions to make use of it.  This is straightforward from C# or F# and I am 
assuming it can be done from IronRuby, but that's just a guess.

I tried to run the build the process with xbuild rather than msbuild,
but it looks like System.Numerics might not be implemented in Mono?

I was able to add a reference to System.Numerics and open it under Mono 2.10 
and I thought it was part of 2.8 but I may be mistaken. Perhaps Mono is 
selecting the wrong .NET runtime?

Thanks!

-Doug

> On Tue, Mar 1, 2011 at 4:32 PM, Chad Brockman 
> mailto:cha...@slb.com>> wrote:
>>
>> Anyone know if the effort to port numpy to IronPython is still alive?
>> Enthought / MS announced it last year?
>> http://www.enthought.com/media/SciPyNumPyDotNet.pdf
>>
>>
>>
>> Anyone know if IronClad is still being developed?
>>
>>
>>
>> Thanks, Chad
>>
>> ___
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
>
> --
> Jason McCampbell
> Enthought, Inc.
> 512.850.6069
> jmccampb...@enthought.com
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>



--
Jason McCampbell
Enthought, Inc.
512.850.6069
jmccampb...@enthought.com

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] numpy / IronClad?

2011-03-14 Thread Jason McCampbell 
>
> As IronPython runs under many different operating systems now, it
> would be useful to know what the dependencies are for numpy and scipy:
>
> - is Windows a requirement?

- does it work under Mono?


No, not directly but practically for the short-term Windows is requires for
the SciPy piece.  NumPy is quite cross-platform and uses the very
cross-platform NumPy core (C code), a little bit of C++ code, and a bunch of
C#.  I haven't tried building it on Mono recently but aside from getting the
builds to work there shouldn't be a lot of work.  It does require .NET 4 so
likely Mono 2.10 will be a requirement.

SciPy is more restrictive because it relies on C++/CLI which is not
supported on Mono.  The reason is that we are using the Cython tool to
generate interfaces for CPython and IronPython from a single source.
 Unfortunately because Cython allows users to import arbitrary C header
files, C++/CLI was the only practical option for the time being.

- can IronRuby etc take advantage of these libraries?
>

Probably, at least some of the functionality.  The interface is straight
.NET so C#, F# and other languages can make use of the NumPy ndarray object
and other objects.  The biggest limitation is that a fair amount of the
functionality is implemented in Python so it is necessary to evaluate Python
expressions to make use of it.  This is straightforward from C# or F# and I
am assuming it can be done from IronRuby, but that's just a guess.


> I tried to run the build the process with xbuild rather than msbuild,
> but it looks like System.Numerics might not be implemented in Mono?
>

I was able to add a reference to System.Numerics and open it under Mono 2.10
and I thought it was part of 2.8 but I may be mistaken. Perhaps Mono is
selecting the wrong .NET runtime?


> Thanks!
>
> -Doug
>
> > On Tue, Mar 1, 2011 at 4:32 PM, Chad Brockman  wrote:
> >>
> >> Anyone know if the effort to port numpy to IronPython is still alive?
> >> Enthought / MS announced it last year?
> >> http://www.enthought.com/media/SciPyNumPyDotNet.pdf
> >>
> >>
> >>
> >> Anyone know if IronClad is still being developed?
> >>
> >>
> >>
> >> Thanks, Chad
> >>
> >> ___
> >> Users mailing list
> >> Users@lists.ironpython.com
> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>
> >
> >
> >
> > --
> > Jason McCampbell
> > Enthought, Inc.
> > 512.850.6069
> > jmccampb...@enthought.com
> >
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
>



-- 
*Jason McCampbell*
Enthought, Inc.
512.850.6069
jmccampb...@enthought.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] numpy / IronClad?

2011-03-14 Thread Doug Blank 
On Mon, Mar 14, 2011 at 1:25 PM, Jason McCampbell
 wrote:
> Hi Chad,
> Sorry for the delayed response, we were busy getting the beta release of
> NumPy and SciPy together.  Microsoft announced the availability of NumPy and
> SciPy for IronPython / .NET  at PyCon the end of last week.

This is great news! Had no idea this was under development.

> You can find the install instructions here for the pre-built
> binaries: http://www.enthought.com/repo/.iron/
> Alternately you can grab the source code from the following repositories:
>     https://github.com/numpy/numpy-refactor
>     https://github.com/jasonmccampbell/scipy-refactor
> One note we don't have documented right now is that SciPy requires the
> Python stack frames access, which IronPython doesn't enable by default.  To
> run SciPy you need to use the "-X:Frames" argument:
>     ipy.exe -X:Frames -c "import scipy"
> Regards,
> Jason

As IronPython runs under many different operating systems now, it
would be useful to know what the dependencies are for numpy and scipy:

- is Windows a requirement?
- does it work under Mono?
- can IronRuby etc take advantage of these libraries?

I tried to run the build the process with xbuild rather than msbuild,
but it looks like System.Numerics might not be implemented in Mono?

Thanks!

-Doug

> On Tue, Mar 1, 2011 at 4:32 PM, Chad Brockman  wrote:
>>
>> Anyone know if the effort to port numpy to IronPython is still alive?
>> Enthought / MS announced it last year?
>> http://www.enthought.com/media/SciPyNumPyDotNet.pdf
>>
>>
>>
>> Anyone know if IronClad is still being developed?
>>
>>
>>
>> Thanks, Chad
>>
>> ___
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
>
> --
> Jason McCampbell
> Enthought, Inc.
> 512.850.6069
> jmccampb...@enthought.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] numpy / IronClad?

2011-03-14 Thread Jason McCampbell 
Hi Chad,

Sorry for the delayed response, we were busy getting the beta release of
NumPy and SciPy together.  Microsoft announced the availability of NumPy and
SciPy for IronPython / .NET  at PyCon the end of last week.

You can find the install instructions here for the pre-built binaries:
http://www.enthought.com/repo/.iron/

Alternately you can grab the source
code from the following repositories:
https://github.com/numpy/numpy-refactor
https://github.com/jasonmccampbell/scipy-refactor

One note we don't have documented right now is that SciPy requires the
Python stack frames access, which IronPython doesn't enable by default.  To
run SciPy you need to use the "-X:Frames" argument:
ipy.exe -X:Frames -c "import scipy"

Regards,
Jason


On Tue, Mar 1, 2011 at 4:32 PM, Chad Brockman  wrote:

>  Anyone know if the effort to port numpy to IronPython is still alive?
> Enthought / MS announced it last year?
> http://www.enthought.com/media/SciPyNumPyDotNet.pdf
>
>
>
> Anyone know if IronClad is still being developed?
>
>
>
> Thanks, Chad
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


-- 
*Jason McCampbell*
Enthought, Inc.
512.850.6069
jmccampb...@enthought.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Rich comparison usage by IronPython's heapq implementation

2011-03-14 Thread Robert Smallshire 
Hello,

I recently ran into some issues with IronPython's heapq implementation
whereby code that functions correctly on CPython failed with IronPython 2.6.
 The issue is that the CPython implementation of heapq only calls __le__()
and __eq__() on the heap elements whereas the IronPython implementation
calls __le__(), __eq__() *and* __gt__().  Although it seems that IronPython
is well within specification to do so, there are some statements in the
Python documentation that only __le__() will be used for sorting.  Of
course, it's arguable whether 'sorting' applies to heapq and indeed other
similar algorithms or containers which rely on a defined ordering.

In any case, this is an avoidable difference between CPython and IronPython
which tripped me up.  I'm not sure whether the correct fix - if one is
needed at all - is to IronPython's heapq implementation, to CPythons
documentation, or to both.

I wrote a little more about the issue here:

  <
http://www.smallshire.org.uk/sufficientlysmall/2011/03/12/specification-of-rich-comparison-protocol-use-by-the-python-standard-library/
>

Rob
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython 2.7.1 & 3.x Development

2011-03-14 Thread Jeff Hardy 
On Mon, Mar 14, 2011 at 7:50 AM, Vernon Cole  wrote:
> I was running a test of adodbapi -- IPy 2.7 RC2 ran it fine, but CPython 2.7
> had errors. I was starting to debug the CPython when I discovered that I was
> running the Python _3_ version of the test suite! The "error" was in the
> Unicode vs String logic. IronPython already does the right (P3k) thing.

Yep - the unicode support is the single biggest change in Py3k, and we
already support it. Pulling the new stdlib & tests in is easy as well.
There are some parser changes (function annotations) but even those
should be minor. I'm really optimistic.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IronPython 2.7.1 & 3.x Development

2011-03-14 Thread Vernon Cole 
Sounds like a good plan, Jeff.

I got a quick hint the other day that IronPython 3.2 might not be as hard as
we think...

I was running a test of adodbapi -- IPy 2.7 RC2 ran it fine, but CPython 2.7
had errors. I was starting to debug the CPython when I discovered that I was
running the Python _3_ version of the test suite! The "error" was in the
Unicode vs String logic. IronPython already does the right (P3k) thing.
--
Vernon

On Mon, Mar 14, 2011 at 12:24 AM, Jeff Hardy  wrote:

> With the 2.7 out the door, it's time to start thinking about 3.x. I've
> created a ipy-2.7-maint branch for continued 2.7 work (and it needs
> some), and any 3.x work will go on master. Any 2.7 fixes that also go
> into 3.x (and really, most of them should) go into the 2.7 branch
> *first*, and then be cherry-picked into master (yes, I'll write some
> docs on that). This is to (hopefully) prevent any 3.x features from
> being inadvertently backported to 2.7.
>
> I'll pull in the 3.2 standard lib and tests very soon, and then work
> on the parser/compiler changes and such can start. I'm not expecting
> to have a reasonable 3.x release until fall at the earliest, although
> I would like to get nightly builds set up so people can still try it
> easily in the meantime.
>
> For now, the 3.x series will have the 3.0 version number; whether it
> becomes 3.2 or 3.3 remains to be seen.
>
> There's still a lot of stuff that should go into 2.7.1 - bug fixes,
> new modules, etc. Ideally I'd like to see that released in 6-8 weeks,
> which puts it around the beginning of May, and then on basically the
> same cycle as long as there's fixes to go in.
>
> - Jeff
> ___
> 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