Re: [pypy-dev] fdopen(fd, 'w') whe fd is opened 'r'

What version of CPython did you compare with? This behavior was added/changed in 2.7.8. CPython has the exact same test and it doesn't seem to be skipped on Windows. Comparing directly with C fdopen does not make sense because os.fdopen isn't just a direct call to fdopen (includes verification of m

Re: [pypy-dev] PyPy current status

As far as numpy, the last few blog status posts are probably give the best idea: http://morepypy.blogspot.com/2014/04/numpy-on-pypy-status-update.html http://morepypy.blogspot.com/2014/03/numpy-status-update-february.html Somewhere in there I mention count of tests passing out of tests total -- t

Re: [pypy-dev] release of pypy2.3 is imminent

Also, what about the existence of other blockers? For example: https://bugs.pypy.org/issue1695 On Fri, Apr 25, 2014 at 2:30 AM, Maciej Fijalkowski wrote: > Hey Matti > > We have a potential release blocker with an unrolling bug. > > On Fri, Apr 25, 2014 at 11:01 AM, Matti Picus > wrote: > > If

Re: [pypy-dev] should os.fdopen(fd-of-a-directory, "r") succeed?

Fixed in fcb0695ec986 On Wed, Apr 9, 2014 at 11:32 AM, Alex Gaynor wrote: > It fails under CPython 2.7 as well, I guess we should fix it. > > Alex > > > On Wed, Apr 9, 2014 at 2:29 PM, Dima Tisnek wrote: > >> it fails on py 2.7 (with a bug), fails correctly in py 3.3 and >> succeeds in pypy 2.

Re: [pypy-dev] unaligned raw_load (align_float_cast branch)

I believe all of them in micronumpy are at risk -- any type could be a subtype of a record type consisting of something like a single char followed by whatever type. On Sun, Feb 23, 2014 at 1:43 AM, Armin Rigo wrote: > Hi Matti, > > I've checked in some new code in rawstorage.py on default: > r