Mailman 3 August 2013 - pypy-dev

london sprint travel info
by Carl Friedrich Bolz Aug. 23, 2013

Aug. 23, 2013

Hello sprinters, Lukas prepared a PDF that explains how to get to the sprint room and contact info for some of the local people: http://lukasdiekmann.com/PyPy_sprint_getting_there.pdf We will have a planning meeting at Monday at 10:00 to set up goals for the week and tasks for the day. If you have any logistical questions please mail me. Looking forward to meeting all of you! Cheers, Carl Friedrich

1 0

Quindi farvi fiducia? (Donazione)
by Jacqueline Follereau Aug. 22, 2013

Aug. 22, 2013

Ciao, Con molto rispetto per voi, con molto un buono cuore e la necessità di stabilire una comunicazione, è di conseguenza che vi scrivo. Io voi presi non considerato ciò poiché una scherza o un messaggio che vi causerà problemi. Volete considerare questo messaggio che ad estate inviarvi come una persona che cerca soprattutto la pace e la riservatezza del vostro aiuto. Il mio nome è la Signora JACQUELINE FOLLEREAU nato il 31-mag-1948, vedova senza figli. Sto contattando in questo modo perché … [View More]

1 0

london sprint - newbie question + accommodation note
by Rami Chowdhury Aug. 21, 2013

Aug. 21, 2013

Hey folks, Until yesterday I wasn't sure if I'd be in town during this, but it looks like I will be. I'd like to join in with some sprinting, although I'm not sure how long I'll be able to devote -- will there be any particular intro sessions (e.g. on the Sunday or Monday) besides the lightning talks Tuesday evening? Also, I don't know how helpful this is so close to the time, but I live within walking distance of the sprint venue and would be able to offer a place stay during the sprint. I … [View More]

2 1

build dependencies on SuSE SLES 11
by Riccardo Murri Aug. 20, 2013

Aug. 20, 2013

Hello, I just spent some time figuring out how the necessary dependencies are named in SLES11, maybe you want to add this to the doc page? $ sudo zypper install gcc make python-devel pkg-config \ zlib-devel libopenssl-devel libbz2-devel sqlite3-devel libexpat-devel I could find no Boehm GC nor Sphinx package in the SLES11 repos. Thanks, Riccardo -- Riccardo Murri http://www.gc3.uzh.ch/people/rm Grid Computing Competence Centre University of Zurich Winterthurerstrasse … [View More]

3 3

Where do I find the stm-gc branch?
by Andrew Francis Aug. 18, 2013

Aug. 18, 2013

Hi Folks: I was looking for the pypy stm work. I went to https://bitbucket.org/pypy/pypy/src/stm-gc. However on the page, I get: The branch 'stm-gc' does not exist. Where should I be looking? Cheers, Andrew

3 2

Question about cffi cache dir
by Michal Vyskocil Aug. 14, 2013

Aug. 14, 2013

Hi all, I have just updated pypy to 2.1 in our Open Build Service [1], but got into a trouble with cache directory for cffi files. It seems that __pycache__ is not created during a build, but on runtime, so my attempt to build pypy using pypy ends on [ 66s] IOError: [Errno 2] No such file or directory: '/usr/lib64/pypy-2.1/lib_pypy/__pycache__/_cffi__g7019d5d3xad93c709.c' and I did not find __pycache__ made as a result of a build, neither of python compile call. Looking at lib_pypy/cffi/… [View More]

4 4

The fate of gc-del
by Armin Rigo Aug. 12, 2013

Aug. 12, 2013

Hi all, I'm trying again to look at the gc-del branch, but I'm kind of failing. The current state is: http://buildbot.pypy.org/summary?branch=gc-del The failures are all more or less obscure. The issues all may have to do with subtly broken things in the finalizer ordering code. But now I believe that the attempted implementation was a bad idea. For reference: you call "rgc.register_finalizer(method)" on objects where you want a finalizer to be called (instead of "def __del__()", … [View More]which is now limited to "lightweight" destructors). It's a good idea by itself because (1) you can register a finalizer only after the object is ready, and not have to care for seeing half-initialized objects in the finalizer; and (2) you can register a finalizer at any time, or not at all, on various instances of the same class, which is very convenient for implementing app-level objects that may or may not have a user-level __del__ method. The issue is that the finalizers (particularly the app-level ones) should only be called at known points in time, e.g. between bytecodes, and not from random places. I tried to do this: if a finalizer raises "FinalizeLater", then it suspends calling finalizers --- both the current one and all future ones. Later, between bytecodes, we call rgc.progress_through_finalizer_queue() to resume. This looks innocent enough, but it's a major mess. First in test runs: because the finalizer queue is not attached to any space, and raising FinalizeLater suspends calling any finalizer from there, in order to maintain the correct order. Also, I suspect, in real runs. We're getting cases where the app-level __del__() is not called and I'm really unsure why, but I suspect that some finalizer raises FinalizeLater without making sure that we'll later call rgc.progress_through_finalizer_queue(). Basically, this API looks broken now. It becomes messy when you consider that some helpers in rpython.rlib really need rgc.register_finalizer(), like rmmap. These helpers don't know about the space. The hack of the previous paragraph was an attempt to still have rmmap objects finalized in the globally correct order. Help! :-) Any cleaner ideas welcome! Would it make sense to *not* call automatically any finalizer, and instead require that the RPython program calls rgc.flush_finalizer_queue() regularly? Maybe with some minimal signal-like event from the GC to mean "there are finalizers now"? It would seem closer to what e.g. Java does, which just puts finalizable objects on a queue from the GC. A bientôt, Armin. [View Less]

2 3

os.uname() in rpython/memory/gc/env.py
by Armin Rigo Aug. 10, 2013

Aug. 10, 2013

Hi, During refactorings I found out that os.uname() is called at run-time from rpython/memory/gc/env.py to figure out on which platform we are. It also means that the logic to figure out the L2 cache size *for all platforms* is compiled into any pypy-c. In ab7580454b32 I moved the call to translation-time. Can anyone check if this makes sense for cross-compilation? E.g. if cross-compiling for ARM, say, would not end up with the host x86 platform here? In other words, what is os.uname() … [View More]

2 1

PyPy3: Invalid syntax in stdlib
by David Naylor Aug. 10, 2013

Aug. 10, 2013

Hi, I would like to report some possible errors I've noticed I translated pypy3-2.1.0-beta1 and when doing a: # find . -type d | xargs pypy-c -m compileall -fl for lib_pypy I get the following errors: *** File "/tmp/build/home/DragonSA/pypy3/work/lib/pypy3-2.1/lib_pypy/ctypes_config_cache/rebuild.py", line 50 except Exception, e: ^ SyntaxError: invalid syntax *** File "/tmp/build/home/DragonSA/pypy3/work/lib/pypy3-2.1/lib_pypy/pyrepl/keymaps.py", line 65 … [View More]

1 0

Re: [pypy-dev] [pypy-commit] pypy bigint-with-int: Close branch as abandoned. Breaks too much stuff (fractions and decimals).
by Carl Friedrich Bolz Aug. 7, 2013

Aug. 7, 2013

Hi Stian, could you explain a bit, why the branch was abandoned? Were the problems with the objspace part or the rlib.rbigint part? If the former, it might be useful to merge just the changes to rbigint, because they sound useful in general. Cheers, Carl Friedrich On 07/08/13 15:19, stian wrote: > Author: stian > Branch: bigint-with-int > Changeset: r65995:7f1adb56a558 > Date: 2013-08-07 15:18 +0200 > http://bitbucket.org/pypy/pypy/changeset/7f1adb56a558/ > > Log: … [View More]

1 0