Mailman 3 April 2012 - pypy-dev

STM proposal funding
by Armin Rigo April 17, 2012

April 17, 2012

Hi all, For those of you who missed it: the proposal on Software Transactional Memory is launched ("remove the GIL but give a better way to write multi-threaded applications"). It is available at http://pypy.org/tmdonate.html . I plan to ask the PSF for some participation, following the push towards doing so at the PyCon PSF meeting. See http://mail.python.org/pipermail/python-dev/2012-March/117680.html , "Funding from the Python Software Foundation". A bientôt, Armin.

5 14

STM/AME for CPython?
by Armin Rigo April 16, 2012

April 16, 2012

Hi all, Countrary to what is written in the STM/AME proposal, since last week I believe it might be (reasonably) possible to apply the same techniques to CPython. For now I am experimenting with applying them in a simple CPython-like interpreter. If it works, it might end up as a patch to the core parts of CPython. The interesting property is that it would still be able to run unmodified C extension modules --- the Python code gets the benefits of multi-core STM/AME only if it involves only … [View More]

3 4

Cython-CEP: Native dispatch through Python callables
by Stefan Behnel April 15, 2012

April 15, 2012

Hi, I already mentioned this possibility a couple of times on this list, but now the idea has attracted some more general interest. The Cython project would like to specify a general way of unpacking wrapped native functions for Python implementations. This is interesting for CPython because it would allow NumPy and other extensions to unpack functions implemented by other extensions before calling them in loops. PyPy could let its JIT do the same at runtime. Cython and low-level wrapper … [View More]

3 10

Communications of the European Neurological Society - April 2012
by ENS Newsletter April 14, 2012

April 14, 2012

1 0

PyPy as part of a larger, bundled project?
by Leo Trottier April 12, 2012

April 12, 2012

Hi, A number of Python applications (e.g. http://calibre-ebook.com/, http://www.psychopy.org/ ... http://en.wikipedia.org/wiki/List_of_Python_software#Applications) are deployed together with the libraries and interpreter that they will use. Often, these applications are larger, and can end up performing operations that are computationally intensive. In the case of Calibre, e.g., large batch conversions from one book format to another can take more than an hour (for sufficiently large batches)… [View More]

3 6

__exit__ not called in certain cases
by Hong Minhee April 12, 2012

April 12, 2012

I reported https://bugs.pypy.org/issue1126 which shows that __exit__ is not called in certain cases when I think it should be. The code to reproduce the bug is there. The code works on CPython. It was closed as invalid saying this is a GC issue, but I don't think it is. This is about __exit__, not __del__. __exit__ should be always called if __enter__ succeeds.

2 1

Re: [pypy-dev] [pypy-commit] pypy win32-stdlib: fix close() and tests for file closing
by Antonio Cuni April 11, 2012

April 11, 2012

Hi Matti, On 04/11/2012 01:24 PM, mattip wrote: > Author: Matti Picus<matti.picus(a)gmail.com> > Branch: win32-stdlib > Changeset: r54283:2a8e4f56269f > Date: 2012-04-11 13:26 +0300 > http://bitbucket.org/pypy/pypy/changeset/2a8e4f56269f/ > > Log: fix close() and tests for file closing > > diff --git a/lib-python/2.7/mailbox.py b/lib-python/2.7/mailbox.py > deleted file mode 100644 the idea for 2.7 vs modified-2.7 is to keep 2.7 intact, so you should not … [View More]

1 0

changing the stdlib tracking
by Ronny Pfannschmidt April 11, 2012

April 11, 2012

hi, since its kind of troublesome to deal with stdlib vs modified-stdlib, i'd like to propose an new model for tracking our changes to the stdlib the unmodified stdlib would be in a branch, say vendor/stdlib, while our modifications will get inlined in the default branch that way we get easier merging and easier diffing + we might be able to supply patches to cpython more easily the same approach can also be applied to pylib/pytest so i propose 2 vendor branches for tracking unmodified … [View More]

2 2

multiple versions of Python.h
by Matti Picus April 10, 2012

April 10, 2012

Two copies of Python.h exist: pypy\include\Python.h pypy\module\cpyext\include\Python.h When translating targetpypystandalone on win32, the created Makefile prefers the cpyext\include. It appears that the CConfig class used to create the Makefile is the one in module/cpyext/api.py (since I see the flag Py_BUILD_CORE which occurs only there), and the include_dirs there does not pull in the first path. Two questions: 1. Do we really want two copies of this header in our tree 2. If so, … [View More]

1 1

Findings in the Cython test suite
by Stefan Behnel April 8, 2012

April 8, 2012

Hi, the new exception handling functions enabled a lot more tests in Cython's test suite, with still lots and lots of failures. I created tickets for a couple of them where it's clear that the problem is in PyPy/cpyext. The test results are collected here: https://sage.math.washington.edu:8091/hudson/view/dev-scoder/job/cython-sco… Here's the general log (which I find easier to read in this case): https://sage.math.washington.edu:8091/hudson/view/dev-scoder/job/cython-sco… For C compiler … [View More]errors ("CompileError" exceptions) you'll have to look in the log at the place where the test was executed, but those are getting few. The test results are also recorded in the log, at the end (which, given the amount of failures, starts at about one third through the log). Some failures are due to wrong expectations in test code, e.g. we sometimes use the fact that small integers are cached in CPython. Others fail due to different exception messages in the doctests. Both can be handled on Cython side, given that CPython's own error messages aren't exactly carved in stone either. There is one major problem that accounts for the bulk of the test failures, somehow related to frame handling. You can tell by the huge amount of long traceback sequences that run into StackOverflowErrors and equivalent RuntimeErrors. When you look closer (e.g. repeatedly searching the log for the "classkwonlyargs" test), you will notice that the traceback refers to more than one test, i.e. the next doctest execution somehow picks up the frame of a previous test and continues from it. Funny enough, the frame leaking tests that have run (and failed) before the current one appear *below* the current test in the stack trace. This makes it likely that this is due to the way exception stack frames are constructed in Cython. They are only instantiated when an exception is being propagated, and then registered using PyTraceBack_Here(). It looks similarly likely that this is a bug in cpyext as it being due to problematic code in Cython. In case it's PyPy's fault, maybe there's something like an off-by-one when cleaning up the traceback frames somewhere? Another minor thing I noticed, PyPy seems to check the object type of keyword argument names at the caller side, whereas CPython does it as part of the function argument unpacking. Since Cython also does it on the function side and therefore expects its own error messages in the tests (which mimic CPython's, including the name of the function), these tests fail now (look for "keywords must be strings" in the test log). Not sure if it's worth doing anything about this - checking the type at call time isn't really wrong, just different. However, this is one of the cases where it would be nice if PyPy simply included the function name in the error message. The same applies to the "got multiple values for keyword argument" error. Apart from the frame handling bug, the remaining problems look minor enough to say that we are really close to a point where Cython on PyPy becomes usable. Stefan [View Less]

4 10