From david.schneider at bivab.de Thu Aug 1 11:40:18 2013 From: david.schneider at bivab.de (David Schneider) Date: Thu, 1 Aug 2013 11:40:18 +0200 Subject: [pypy-dev] Pypy-2.1-beta2 translation error In-Reply-To: References: <11961581.rsoAsemi6P@dragon.dg> Message-ID: On 31.07.2013, at 22:57, David Naylor wrote: > > On 31 Jul 2013 10:29 PM, "Alex Gaynor" wrote: > > > > What version of PyPy are you using to translate? > > Pypy 2.1-beta2 gives me this error. I had previously translated with beta1 but without this error (I can confirm this if needed). > > > On Wed, Jul 31, 2013 at 12:20 PM, David Naylor wrote: > >> > >> Hi, > >> > >> While trying to self-translate pypy-2.1-beta2 I got the following error: > >> > >> RPython traceback: > >> File "rpython_jit_metainterp_resume.c", line 7778, in > >> blackhole_from_resumedata > >> File "rpython_jit_metainterp_resume.c", line 9972, in > >> ResumeDataDirectReader_consume_vref_and_vable > >> File "rpython_jit_metainterp_resume.c", line 695, in > >> ResumeDataDirectReader_consume_vable_info > >> Fatal RPython error: AssertionError > >> > >> Is this a known problem or something wrong with my setup? > >> > >> Regards > >> _______________________________________________ > >> pypy-dev mailing list > >> pypy-dev at python.org > >> http://mail.python.org/mailman/listinfo/pypy-dev > >> > > > > > > > > -- > > "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > > "The people's good is the highest law." -- Cicero > > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev Hi David, Thanks for reporting, I'm unable to reproduce this error so far. Could you post the exact version of the source code and binary you are using to translate as well as the command line flags? Thanks, David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From david.schneider at bivab.de Thu Aug 1 15:44:39 2013 From: david.schneider at bivab.de (David Schneider) Date: Thu, 1 Aug 2013 15:44:39 +0200 Subject: [pypy-dev] PyPy 2.1 released Message-ID: <28ED2373-DD11-4C13-AA3F-867593BEB229@bivab.de> ============================ PyPy 2.1 - Considered ARMful ============================ We're pleased to announce PyPy 2.1, which targets version 2.7.3 of the Python language. This is the first release with official support for ARM processors in the JIT. This release also contains several bugfixes and performance improvements. You can download the PyPy 2.1 release here: http://pypy.org/download.html We would like to thank the Raspberry Pi Foundation http://www.raspberrypi.org for supporting the work to finish PyPy's ARM support. The first beta of PyPy3 2.1, targeting version 3 of the Python language, was just released, more details can be found here: http://morepypy.blogspot.com/2013/07/pypy3-21-beta-1.html What is PyPy? ============= PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7. It's fast (http://speed.pypy.org) due to its integrated tracing JIT compiler. This release supports x86 machines running Linux 32/64, Mac OS X 64 or Windows 32. This release also supports ARM machines running Linux 32bit - anything with ARMv6 (like the Raspberry Pi) or ARMv7 (like the Beagleboard, Chromebook, Cubieboard, etc.) that supports VFPv3 should work. Both hard-float armhf/gnueabihf and soft-float armel/gnueabi builds are provided. armhf builds for Raspbian are created using the Raspberry Pi `custom cross-compilation toolchain `_ based on gcc-arm-linux-gnueabihf and should work on ARMv6 and ARMv7 devices running Debian or Raspbian. armel builds are built using the gcc-arm-linux-gnuebi toolchain provided by Ubuntu and currently target ARMv7. Windows 64 work is still stalling, we would welcome a volunteer to handle that. Highlights ========== * JIT support for ARM, architecture versions 6 and 7, hard- and soft-float ABI * Stacklet support for ARM * Support for os.statvfs and os.fstatvfs on unix systems * Improved logging performance * Faster sets for objects * Interpreter improvements * During packaging, compile the CFFI based TK extension * Pickling of numpy arrays and dtypes * Subarrays for numpy * Bugfixes to numpy * Bugfixes to cffi and ctypes * Bugfixes to the x86 stacklet support * Fixed issue 1533: fix an RPython-level OverflowError for space.float_w(w_big_long_number). https://bugs.pypy.org/issue1533 * Fixed issue 1552: GreenletExit should inherit from BaseException. https://bugs.pypy.org/issue1552 * Fixed issue 1537: numpypy __array_interface__ https://bugs.pypy.org/issue1537 * Fixed issue 1238: Writing to an SSL socket in PyPy sometimes failed with a "bad write retry" message. https://bugs.pypy.org/issue1238 Cheers, David Schneider for the PyPy team. From naylor.b.david at gmail.com Thu Aug 1 19:54:17 2013 From: naylor.b.david at gmail.com (David Naylor) Date: Thu, 01 Aug 2013 20:54:17 +0300 Subject: [pypy-dev] Pypy-2.1-beta2 translation error In-Reply-To: References: <11961581.rsoAsemi6P@dragon.dg> Message-ID: <9422568.thh68tl4Oh@dragon.dg> On Thursday, 1 August 2013 11:40:18 David Schneider wrote: > On 31.07.2013, at 22:57, David Naylor wrote: > > On 31 Jul 2013 10:29 PM, "Alex Gaynor" wrote: > > > What version of PyPy are you using to translate? > > > > Pypy 2.1-beta2 gives me this error. I had previously translated with beta1 > > but without this error (I can confirm this if needed).> > > > On Wed, Jul 31, 2013 at 12:20 PM, David Naylor wrote: > > >> Hi, > > >> > > >> While trying to self-translate pypy-2.1-beta2 I got the following > > >> error: > > >> > > >> RPython traceback: > > >> File "rpython_jit_metainterp_resume.c", line 7778, in > > >> > > >> blackhole_from_resumedata > > >> > > >> File "rpython_jit_metainterp_resume.c", line 9972, in > > >> > > >> ResumeDataDirectReader_consume_vref_and_vable > > >> > > >> File "rpython_jit_metainterp_resume.c", line 695, in > > >> > > >> ResumeDataDirectReader_consume_vable_info > > >> Fatal RPython error: AssertionError > > >> > > >> Is this a known problem or something wrong with my setup? > Hi David, > > Thanks for reporting, I'm unable to reproduce this error so far. Could you > post the exact version of the source code and binary you are using to > translate as well as the command line flags? I can no longer reproduce the error. For the record the command was: # /usr/bin/env PYPY_GC_MAX_DELTA=200MB /usr/local/bin/pypy --jit loop_longevity=300 ../../rpython/bin/rpython --source -Ojit targetpypystandalone.py I'll let you know if this error re-occurs (reliably). Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part. URL: From vito.detullio at gmail.com Fri Aug 2 06:37:10 2013 From: vito.detullio at gmail.com (Vito De Tullio) Date: Fri, 02 Aug 2013 06:37:10 +0200 Subject: [pypy-dev] speed.pypy.org and pypy3 Message-ID: Hi. with the release of pypy3, I was hoping to see also this version on the speed center (running against cpython3 or, if it makes sense, versus pypy/cpython2) but I cannot find it. Are there some plan to integrate pypy3 on the speed center? -- ZeD From fijall at gmail.com Fri Aug 2 10:04:34 2013 From: fijall at gmail.com (Maciej Fijalkowski) Date: Fri, 2 Aug 2013 10:04:34 +0200 Subject: [pypy-dev] speed.pypy.org and pypy3 In-Reply-To: References: Message-ID: On Fri, Aug 2, 2013 at 6:37 AM, Vito De Tullio wrote: > Hi. > > with the release of pypy3, I was hoping to see also this version on the > speed center (running against cpython3 or, if it makes sense, versus > pypy/cpython2) but I cannot find it. > > Are there some plan to integrate pypy3 on the speed center? The main problem is that most benchmarks don't support python 3. There has been some work, but the most interesting ones are not ported. From matti.picus at gmail.com Fri Aug 2 13:25:43 2013 From: matti.picus at gmail.com (Matti Picus) Date: Fri, 02 Aug 2013 14:25:43 +0300 Subject: [pypy-dev] cpyext, PyArray, and matplotlib Message-ID: <51FB9737.3000900@gmail.com> Stefan H. Muller has been working hard to expand cpyext enough so that matplotlib non-interactive backends can work with PyPy. The steps to get it all working are included[0]. While pypy translates for him (on MacOS I think), I could not get past the platform checks on linux 64. If anyone would like to help, the branch is pypy-pyarray and the author is Stefan__ on IRC (off work hours). The traceback is here http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/1602/steps/translate/logs/stdio the last lines are [translation:ERROR] CompilationError: CompilationError(err=""" [translation:ERROR] /tmp/usession-pypy-pyarray-0/platcheck_35.o: In function `PyComplex_FromCComplex': [translation:ERROR] platcheck_35.c:(.text+0x13): undefined reference to `_PyComplex_FromCComplex' Matti [0] Matplotlib on pypy 0. hack numpypy to implement __version__ and get_include() 1. build pypy from pypy/pypy-pyarray branch 2. install it into a virtualenv 3. download and install rlamy's pypy-hack https://github.com/rlamy/numpy/tree/pypy-hack 4. donwload and install stefan's matplotlib https://github.com/shmuller/matplotlib 5. use a non-interactive backend Matti From pjenvey at underboss.org Fri Aug 2 23:40:19 2013 From: pjenvey at underboss.org (Philip Jenvey) Date: Fri, 2 Aug 2013 14:40:19 -0700 Subject: [pypy-dev] speed.pypy.org and pypy3 In-Reply-To: References: Message-ID: <519C4FE4-BEBF-4A57-B572-3E1108C9F870@underboss.org> On Aug 2, 2013, at 1:04 AM, Maciej Fijalkowski wrote: > On Fri, Aug 2, 2013 at 6:37 AM, Vito De Tullio wrote: >> Hi. >> >> with the release of pypy3, I was hoping to see also this version on the >> speed center (running against cpython3 or, if it makes sense, versus >> pypy/cpython2) but I cannot find it. >> >> Are there some plan to integrate pypy3 on the speed center? > > The main problem is that most benchmarks don't support python 3. There > has been some work, but the most interesting ones are not ported. Brett Cannon put some effort into bringing PyPy's benchmarks[1] over to the 'official' Python benchmark suite[2] as well as porting them to Python 3. I'm not sure if everything was actually migrated over and or ported. http://speed.pypy.org still uses the PyPy benchmark suite. Maciej, isn't there someone else now working on unifying the benchmark suite and the speed.pypy/python.org sites? [1] https://bitbucket.org/pypy/benchmarks [2] http://hg.python.org/benchmarks/ -- Philip Jenvey From freemanfhx at gmail.com Mon Aug 5 01:19:17 2013 From: freemanfhx at gmail.com (Freeman Feng) Date: Mon, 5 Aug 2013 07:19:17 +0800 Subject: [pypy-dev] Could not download pypy codes Message-ID: Hi, Pypyers, For some reasons, download from bitbucket.org is blocked in China. Is it possible to provide alternative way of download? such as make a mirror in Github? thanks a lot. Regards, Freeman -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Mon Aug 5 09:03:56 2013 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 5 Aug 2013 09:03:56 +0200 Subject: [pypy-dev] speed.pypy.org and pypy3 In-Reply-To: <519C4FE4-BEBF-4A57-B572-3E1108C9F870@underboss.org> References: <519C4FE4-BEBF-4A57-B572-3E1108C9F870@underboss.org> Message-ID: On Fri, Aug 2, 2013 at 11:40 PM, Philip Jenvey wrote: > > On Aug 2, 2013, at 1:04 AM, Maciej Fijalkowski wrote: > >> On Fri, Aug 2, 2013 at 6:37 AM, Vito De Tullio wrote: >>> Hi. >>> >>> with the release of pypy3, I was hoping to see also this version on the >>> speed center (running against cpython3 or, if it makes sense, versus >>> pypy/cpython2) but I cannot find it. >>> >>> Are there some plan to integrate pypy3 on the speed center? >> >> The main problem is that most benchmarks don't support python 3. There >> has been some work, but the most interesting ones are not ported. > > Brett Cannon put some effort into bringing PyPy's benchmarks[1] over to the 'official' Python benchmark suite[2] as well as porting them to Python 3. I'm not sure if everything was actually migrated over and or ported. > > http://speed.pypy.org still uses the PyPy benchmark suite. Maciej, isn't there someone else now working on unifying the benchmark suite and the speed.pypy/python.org sites? > > [1] https://bitbucket.org/pypy/benchmarks > [2] http://hg.python.org/benchmarks/ > > -- > Philip Jenvey > Not that I know of. The port obviously ignored all the "this large library + benchmark" parts, which might be better these days. Someone has to revisit that. Cheers, fijal From fijall at gmail.com Mon Aug 5 09:04:32 2013 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 5 Aug 2013 09:04:32 +0200 Subject: [pypy-dev] Could not download pypy codes In-Reply-To: References: Message-ID: On Mon, Aug 5, 2013 at 1:19 AM, Freeman Feng wrote: > Hi, Pypyers, > For some reasons, download from bitbucket.org is blocked in China. > Is it possible to provide alternative way of download? > such as make a mirror in Github? > > thanks a lot. > > Regards, > Freeman Bah. Which one do you want, I'll put it somewhere else. Cheers, fijal From arigo at tunes.org Mon Aug 5 09:32:47 2013 From: arigo at tunes.org (Armin Rigo) Date: Mon, 5 Aug 2013 09:32:47 +0200 Subject: [pypy-dev] Could not download pypy codes In-Reply-To: References: Message-ID: Hi, On Mon, Aug 5, 2013 at 1:19 AM, Freeman Feng wrote: > For some reasons, download from bitbucket.org is blocked in China. > Is it possible to provide alternative way of download? > such as make a mirror in Github? Would using a file-sharing site such as http://www.mediafire.com/ help? A bient?t, Armin. From Martin.Gfeller at swisscom.com Tue Aug 6 11:12:10 2013 From: Martin.Gfeller at swisscom.com (Martin.Gfeller at swisscom.com) Date: Tue, 6 Aug 2013 09:12:10 +0000 Subject: [pypy-dev] A case for numpypy object arrays Message-ID: Dear all I've read on an old status blog (http://morepypy.blogspot.ch/2012/04/numpy-on-pypy-progress-report.html): > We merged record dtypes support. The only missing dtypes left are complex (important), datetime (less important) and object (which will probably never be implemented because it makes very little sense and is a mess with moving GCs). I use object arrays extensively in CPython, because the numpy API is very convenient and object array operations (such as indexing with an array) can be much faster than equivalent list comprehensions. I'm measured a particular indexing operation to be 10x faster than a list comprehension in CPython. In PyPy, the list comprehension has roughly the same speed as CPython's numpy indexing, so there's nothing to be gained, *except for code portability*. So from a portability point of view, object arrays do make a lot of sense, even if the implementation may internally rely on lists, because PyPy optimizes their speed disadvantage away. Best regards Martin Martin Gfeller ___________________________________________________________________________ Senior Manager Head of Quantax martin.gfeller at swisscom.com Xing -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Tue Aug 6 11:32:05 2013 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 6 Aug 2013 11:32:05 +0200 Subject: [pypy-dev] A case for numpypy object arrays In-Reply-To: References: Message-ID: On Tue, Aug 6, 2013 at 11:12 AM, wrote: > Dear all > > I?ve read on an old status blog > (http://morepypy.blogspot.ch/2012/04/numpy-on-pypy-progress-report.html): > > > We merged record dtypes support. The only missing dtypes left are complex > (important), datetime (less important) and object (which will probably never > be implemented because it makes very little sense and is a mess with moving > GCs). > > > I use object arrays extensively in CPython, because the numpy API is very > convenient and object array operations (such as indexing with an array) can > be much faster than equivalent list comprehensions. I?m measured a > particular indexing operation to be 10x faster than a list comprehension in > CPython. In PyPy, the list comprehension has roughly the same speed as > CPython?s numpy indexing, so there?s nothing to be gained, *except for code > portability*. > > So from a portability point of view, object arrays do make a lot of sense, > even if the implementation may internally rely on lists, because PyPy > optimizes their speed disadvantage away. > > Best regards > Martin > > > Martin Gfeller > ___________________________________________________________________________ > Senior Manager > Head of Quantax > > martin.gfeller at swisscom.com > Xing Hi Martin We decided we'll implement object arrays, mostly just because why not (and for reasons you mentioned), however you won't be able to take an address of an object array (just like you can in the case of a normal array) and internally use a list. The blog post is simply outdated. Cheers, fijal From cfbolz at gmx.de Wed Aug 7 21:19:32 2013 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 07 Aug 2013 21:19:32 +0200 Subject: [pypy-dev] [pypy-commit] pypy bigint-with-int: Close branch as abandoned. Breaks too much stuff (fractions and decimals). In-Reply-To: <20130807131924.B985E1C00F4@cobra.cs.uni-duesseldorf.de> References: <20130807131924.B985E1C00F4@cobra.cs.uni-duesseldorf.de> Message-ID: <52029DC4.3010409@gmx.de> 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: Close branch as abandoned. Breaks too much stuff (fractions and > decimals). > > _______________________________________________ > pypy-commit mailing list > pypy-commit at python.org > http://mail.python.org/mailman/listinfo/pypy-commit > From mvyskocil at suse.cz Thu Aug 8 15:39:59 2013 From: mvyskocil at suse.cz (Michal Vyskocil) Date: Thu, 8 Aug 2013 15:39:59 +0200 Subject: [pypy-dev] Question about cffi cache dir Message-ID: <20130808133959.GB2684@linux-xtv2.site> 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/verifier.py it seems there is some support for a tempdir in _caller_dir_pycache, set_tmpdir and clean_tmpdir. This indicates that such directory is intended to be really temporary, so there is no way to build it in advance and install with pypy package. Or am I wrong? So I would like to know 1.) Is cache/tempdir for cffi files intended to be regenerated on each attempt, or it can be stable? 2.) In case of stable, how can I create all __pycache__ files during build? 3.) In opposite case, should not be there a default directory, which is expected to be writtable by end-users? eg: ~/.cache/pypy on unix? [1] http://software.opensuse.org/package/pypy Regards Michal Vyskocil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From arigo at tunes.org Sat Aug 10 10:06:48 2013 From: arigo at tunes.org (Armin Rigo) Date: Sat, 10 Aug 2013 10:06:48 +0200 Subject: [pypy-dev] Question about cffi cache dir In-Reply-To: <20130808133959.GB2684@linux-xtv2.site> References: <20130808133959.GB2684@linux-xtv2.site> Message-ID: Hi Michal, On Thu, Aug 8, 2013 at 3:39 PM, Michal Vyskocil wrote: > 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' I'm not sure, but I would believe the problem to be different: it's *expected* that there is no directory __pycache__ there. What the error message is telling you is that some module from .../pypy-2.1/lib_pypy/ did not have its CFFI part correctly compiled at installation. Can you find out which module it is? E.g. it should be in the traceback. A bient?t, Armin. From arigo at tunes.org Sat Aug 10 13:43:06 2013 From: arigo at tunes.org (Armin Rigo) Date: Sat, 10 Aug 2013 13:43:06 +0200 Subject: [pypy-dev] os.uname() in rpython/memory/gc/env.py Message-ID: 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() returning when called from a Python running inside the cross-compilation environments we use? A bient?t, Armin. From naylor.b.david at gmail.com Sat Aug 10 13:40:22 2013 From: naylor.b.david at gmail.com (David Naylor) Date: Sat, 10 Aug 2013 14:40:22 +0300 Subject: [pypy-dev] Question about cffi cache dir In-Reply-To: References: <20130808133959.GB2684@linux-xtv2.site> Message-ID: <4698872.GIeNVz5Fom@dragon.dg> Hi Michal On Saturday, 10 August 2013 10:06:48 Armin Rigo wrote: > Hi Michal, > > On Thu, Aug 8, 2013 at 3:39 PM, Michal Vyskocil wrote: > > 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' > > I'm not sure, but I would believe the problem to be different: it's > *expected* that there is no directory __pycache__ there. What the > error message is telling you is that some module from > .../pypy-2.1/lib_pypy/ did not have its CFFI part correctly compiled > at installation. Can you find out which module it is? E.g. it should > be in the traceback. When creating the port on FreeBSD for PyPy I encountered a similar problem. It was solved, by doing in the build/installation stage: # pypy -c 'import _sqlite3, _curses, syslog' Make sure you run this with the appropriate permissions (root when installing or same user that build pypy for the build stage). This will create the required shared library (.dll or .so) files required for cffi. Please have a look at pypy/tool/release/package.py for the correct procedure to install PyPy. Regards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part. URL: From naylor.b.david at gmail.com Sat Aug 10 14:30:09 2013 From: naylor.b.david at gmail.com (David Naylor) Date: Sat, 10 Aug 2013 15:30:09 +0300 Subject: [pypy-dev] PyPy3: Invalid syntax in stdlib Message-ID: <7647384.RYWPikLSFy@dragon.dg> 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 SyntaxError: invalid comparison *** File "/tmp/build/home/DragonSA/pypy3/work/lib/pypy3-2.1/lib_pypy/pyrepl/pygame_console.py", line 133 def refresh(self, screen, (cx, cy)): ^ SyntaxError: invalid syntax *** File "/tmp/build/home/DragonSA/pypy3/work/lib/pypy3-2.1/lib_pypy/pyrepl/pygame_keymap.py", line 93 raise KeySpecError, \ ^ SyntaxError: invalid syntax I also get errors from the stdlib however those are all in tests (so not sure if that was intentional). Regards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part. URL: From david.schneider at bivab.de Sat Aug 10 17:28:30 2013 From: david.schneider at bivab.de (David Schneider) Date: Sat, 10 Aug 2013 17:28:30 +0200 Subject: [pypy-dev] os.uname() in rpython/memory/gc/env.py In-Reply-To: References: Message-ID: Hi Armin, On 10.08.2013, at 13:43, Armin Rigo wrote: > 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() returning when called from a Python running inside the > cross-compilation environments we use? with the cross-compilation we use, this change would lead to picking the information of the host machine and not of the ARM target itself. Eventually something like detect_model_from_c_compiler from rpython/jit/backend/detect_cpu.py might be useful to check for the machine, which uses the (cross-)compiler to do the check. Cheers, David From arigo at tunes.org Sun Aug 11 09:52:55 2013 From: arigo at tunes.org (Armin Rigo) Date: Sun, 11 Aug 2013 09:52:55 +0200 Subject: [pypy-dev] The fate of gc-del Message-ID: 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__()", 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. From arigo at tunes.org Mon Aug 12 09:38:23 2013 From: arigo at tunes.org (Armin Rigo) Date: Mon, 12 Aug 2013 09:38:23 +0200 Subject: [pypy-dev] The fate of gc-del In-Reply-To: References: Message-ID: Re-hi, Update after discussion on IRC (thanks cfbolz). First, there are two problems that should be separated. One is the change in interface for RPython programs, calling rgc.register_finalizer() instead of having regular __del__()s. The other is making these finalizers be called more quickly in case of a chain of objects that all have finalizers. Let's focus on the second problem. We found a more reasonable way to address it --- or at least, to reduce its bad effects to a large extent. Recall that finalizers are only run after major collections. Why? Because there would be little point in running them after minor collections. Consider the case of two objects A -> B, both with finalizers. Even if we would discover during a minor collection that they are dead, they still need to be both promoted to old objects, after which we can call A.__del__ --- but not B.__del__. The latter needs to wait until the following collection --- the following *major* collection, because at this point B is an old object. The proposed fix is to re-make these objects young. In other words, when we find that A and B are not reachable, all objects that are referenced only from A or B still survive of course, but they all become young again. Then the next *minor* collection will deal with them again. In details: * we run a major or minor collection and find that A -> B are not reachable * A and B and objects only reachable from them are made young again * we immediately schedule A.__del__ to be called * at the next *minor* collection we're again likely to find that B is not reachable * B and objects only reachable from it are made young again * we schedule B.__del__ to be called ...and so on if we have a full chain of objects with finalizers rather than just two. They would be finalized at the rythm of one per minor collection. Even if not perfect, this is much, much better than the current rythm, which is one per major collection. The advantage of this approach is that it's done without RPython changes, just by tweaks in the GC. A bient?t, Armin. From william.leslie.ttg at gmail.com Mon Aug 12 10:00:38 2013 From: william.leslie.ttg at gmail.com (William ML Leslie) Date: Mon, 12 Aug 2013 18:00:38 +1000 Subject: [pypy-dev] The fate of gc-del In-Reply-To: References: Message-ID: On 12 August 2013 17:38, Armin Rigo wrote: > The advantage of this approach is that it's done without RPython > changes, just by tweaks in the GC. Do you know what changes to the GC interface you expect to make, if any? -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. From arigo at tunes.org Mon Aug 12 10:09:40 2013 From: arigo at tunes.org (Armin Rigo) Date: Mon, 12 Aug 2013 10:09:40 +0200 Subject: [pypy-dev] The fate of gc-del In-Reply-To: References: Message-ID: Hi William, On Mon, Aug 12, 2013 at 10:00 AM, William ML Leslie wrote: > On 12 August 2013 17:38, Armin Rigo wrote: >> The advantage of this approach is that it's done without RPython >> changes, just by tweaks in the GC. > > Do you know what changes to the GC interface you expect to make, if any? What do you call the GC interface? The way the GC internally interacts with the rest of the RPython program? Or the API exposed by rpython.rlib.rgc? Or are you asking from the point of view of a PyPy user, how we will change the following sentence on http://pypy.readthedocs.org/en/latest/cpython_differences.html? """Note that if you have a long chain of objects, each with a reference to the next one, and each with a __del__, PyPy?s GC will perform badly.""" A bient?t, Armin. From riccardo.murri at gmail.com Mon Aug 12 15:14:58 2013 From: riccardo.murri at gmail.com (Riccardo Murri) Date: Mon, 12 Aug 2013 15:14:58 +0200 Subject: [pypy-dev] build dependencies on SuSE SLES 11 Message-ID: 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 190, CH-8057 Z?rich (Switzerland) Tel: +41 44 635 4222 Fax: +41 44 635 6888 From riccardo.murri at gmail.com Mon Aug 12 15:16:27 2013 From: riccardo.murri at gmail.com (Riccardo Murri) Date: Mon, 12 Aug 2013 15:16:27 +0200 Subject: [pypy-dev] build dependencies on SuSE SLES 11 In-Reply-To: References: Message-ID: On 12 August 2013 15:14, Riccardo Murri wrote: > $ sudo zypper install gcc make python-devel pkg-config \ > zlib-devel libopenssl-devel libbz2-devel sqlite3-devel libexpat-devel Sorry, `libffi-devel` is missing from that list. Riccardo From mvyskocil at suse.cz Mon Aug 12 16:06:34 2013 From: mvyskocil at suse.cz (Michal Vyskocil) Date: Mon, 12 Aug 2013 16:06:34 +0200 Subject: [pypy-dev] build dependencies on SuSE SLES 11 In-Reply-To: References: Message-ID: <20130812140634.GA13593@linux-xtv2.site> On Mon, Aug 12, 2013 at 03:16:27PM +0200, Riccardo Murri wrote: > On 12 August 2013 15:14, Riccardo Murri wrote: > > $ sudo zypper install gcc make python-devel pkg-config \ > > zlib-devel libopenssl-devel libbz2-devel sqlite3-devel libexpat-devel > > Sorry, `libffi-devel` is missing from that list. You'd need to have python-curses for _curses.so. Anyway I do build pypy in OBS for openSUSE, so feel free to contact me in a case you'd want to add SLE_11 build. Regards Michal Vyskocil > > Riccardo > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mvyskocil at suse.cz Wed Aug 14 09:20:14 2013 From: mvyskocil at suse.cz (Michal Vyskocil) Date: Wed, 14 Aug 2013 09:20:14 +0200 Subject: [pypy-dev] Question about cffi cache dir In-Reply-To: <4698872.GIeNVz5Fom@dragon.dg> References: <20130808133959.GB2684@linux-xtv2.site> <4698872.GIeNVz5Fom@dragon.dg> Message-ID: <20130814072014.GA19599@linux-xtv2.site> On Sat, Aug 10, 2013 at 02:40:22PM +0300, David Naylor wrote: > Hi Michal > > On Saturday, 10 August 2013 10:06:48 Armin Rigo wrote: > > Hi Michal, > > > > On Thu, Aug 8, 2013 at 3:39 PM, Michal Vyskocil wrote: > > > 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' > > > > I'm not sure, but I would believe the problem to be different: it's > > *expected* that there is no directory __pycache__ there. What the > > error message is telling you is that some module from > > .../pypy-2.1/lib_pypy/ did not have its CFFI part correctly compiled > > at installation. Can you find out which module it is? E.g. it should > > be in the traceback. > > When creating the port on FreeBSD for PyPy I encountered a similar problem. > It was solved, by doing in the build/installation stage: > > # pypy -c 'import _sqlite3, _curses, syslog' > > Make sure you run this with the appropriate permissions (root when installing > or same user that build pypy for the build stage). This will create the > required shared library (.dll or .so) files required for cffi. > > Please have a look at pypy/tool/release/package.py for the correct procedure > to install PyPy. Thanks for the hint, now it works well. And I have deliberately "stolen" your nice find/xargs code to remove __pycache__ subdirs. Regards Michal Vyskocil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From fijall at gmail.com Wed Aug 14 10:24:32 2013 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 14 Aug 2013 10:24:32 +0200 Subject: [pypy-dev] Question about cffi cache dir In-Reply-To: <20130814072014.GA19599@linux-xtv2.site> References: <20130808133959.GB2684@linux-xtv2.site> <4698872.GIeNVz5Fom@dragon.dg> <20130814072014.GA19599@linux-xtv2.site> Message-ID: On Wed, Aug 14, 2013 at 9:20 AM, Michal Vyskocil wrote: > On Sat, Aug 10, 2013 at 02:40:22PM +0300, David Naylor wrote: >> Hi Michal >> >> On Saturday, 10 August 2013 10:06:48 Armin Rigo wrote: >> > Hi Michal, >> > >> > On Thu, Aug 8, 2013 at 3:39 PM, Michal Vyskocil wrote: >> > > 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' >> > >> > I'm not sure, but I would believe the problem to be different: it's >> > *expected* that there is no directory __pycache__ there. What the >> > error message is telling you is that some module from >> > .../pypy-2.1/lib_pypy/ did not have its CFFI part correctly compiled >> > at installation. Can you find out which module it is? E.g. it should >> > be in the traceback. >> >> When creating the port on FreeBSD for PyPy I encountered a similar problem. >> It was solved, by doing in the build/installation stage: >> >> # pypy -c 'import _sqlite3, _curses, syslog' >> >> Make sure you run this with the appropriate permissions (root when installing >> or same user that build pypy for the build stage). This will create the >> required shared library (.dll or .so) files required for cffi. >> >> Please have a look at pypy/tool/release/package.py for the correct procedure >> to install PyPy. > > Thanks for the hint, now it works well. And I have deliberately "stolen" > your nice find/xargs code to remove __pycache__ subdirs. > > Regards > Michal Vyskocil Sharing is caring :) From andrewfr_ice at yahoo.com Fri Aug 16 19:51:55 2013 From: andrewfr_ice at yahoo.com (Andrew Francis) Date: Fri, 16 Aug 2013 10:51:55 -0700 (PDT) Subject: [pypy-dev] Where do I find the stm-gc branch? Message-ID: <1376675515.60332.YahooMailNeo@web140705.mail.bf1.yahoo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Fri Aug 16 20:49:18 2013 From: fijall at gmail.com (Maciej Fijalkowski) Date: Fri, 16 Aug 2013 20:49:18 +0200 Subject: [pypy-dev] Where do I find the stm-gc branch? In-Reply-To: <1376675515.60332.YahooMailNeo@web140705.mail.bf1.yahoo.com> References: <1376675515.60332.YahooMailNeo@web140705.mail.bf1.yahoo.com> Message-ID: It's stmgc-c4 https://bitbucket.org/pypy/pypy/src/86ed2339b72395703ce6d5824286355bf33a2da9/?at=stmgc-c4 On Fri, Aug 16, 2013 at 7:51 PM, Andrew Francis wrote: > 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 > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev > From arigo at tunes.org Sun Aug 18 09:08:37 2013 From: arigo at tunes.org (Armin Rigo) Date: Sun, 18 Aug 2013 09:08:37 +0200 Subject: [pypy-dev] Where do I find the stm-gc branch? In-Reply-To: References: <1376675515.60332.YahooMailNeo@web140705.mail.bf1.yahoo.com> Message-ID: Hi, On Fri, Aug 16, 2013 at 8:49 PM, Maciej Fijalkowski wrote: > It's stmgc-c4 https://bitbucket.org/pypy/pypy/src/86ed2339b72395703ce6d5824286355bf33a2da9/?at=stmgc-c4 And right now, the most "translatable" branch is "stmgc-static-barrier", in the sense of giving the fastest jit-less version. The stmgc-c4 branch contains the most recent work on the jit, but that still crashes right now. A bient?t, Armin. From arigo at tunes.org Tue Aug 20 13:54:12 2013 From: arigo at tunes.org (Armin Rigo) Date: Tue, 20 Aug 2013 13:54:12 +0200 Subject: [pypy-dev] build dependencies on SuSE SLES 11 In-Reply-To: References: Message-ID: Hi, On Mon, Aug 12, 2013 at 3:16 PM, Riccardo Murri wrote: > On 12 August 2013 15:14, Riccardo Murri wrote: >> $ sudo zypper install gcc make python-devel pkg-config \ >> zlib-devel libopenssl-devel libbz2-devel sqlite3-devel libexpat-devel > > Sorry, `libffi-devel` is missing from that list. Sorry for the delay. Added, thanks! A bient?t, Armin. From n210241048576 at gmail.com Tue Aug 20 15:06:38 2013 From: n210241048576 at gmail.com (Robert Grosse) Date: Tue, 20 Aug 2013 09:06:38 -0400 Subject: [pypy-dev] Windows 7 x64 development Message-ID: Hi, I am interested in working on Windows 7 64bit support for PyPy. Does anyone know what the best way to get started with this is? Is there a list of work that needs to be done to support Windows anywhere? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Tue Aug 20 15:31:43 2013 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 20 Aug 2013 15:31:43 +0200 Subject: [pypy-dev] Windows 7 x64 development In-Reply-To: References: Message-ID: First - getting a buildbot running http://buildbot.pypy.org/builders/own-win-x86-64 <- this one has been down for quite a while Second - starting to make tests pass. On Tue, Aug 20, 2013 at 3:06 PM, Robert Grosse wrote: > Hi, I am interested in working on Windows 7 64bit support for PyPy. Does > anyone know what the best way to get started with this is? Is there a list > of work that needs to be done to support Windows anywhere? > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev > From taavi.burns at gmail.com Tue Aug 20 21:14:25 2013 From: taavi.burns at gmail.com (Taavi Burns) Date: Tue, 20 Aug 2013 15:14:25 -0400 Subject: [pypy-dev] Windows 7 x64 development In-Reply-To: References: Message-ID: <1B12946B-109E-4105-B1CB-60FDD1A59E49@gmail.com> Turns out I now have a windows 8 64bit machine at work, so I can try running tests and translating, too. -- taa /*eof*/ On 2013-08-20, at 9:31 AM, Maciej Fijalkowski wrote: > First - getting a buildbot running > > http://buildbot.pypy.org/builders/own-win-x86-64 <- this one has been > down for quite a while > > Second - starting to make tests pass. > > On Tue, Aug 20, 2013 at 3:06 PM, Robert Grosse wrote: >> Hi, I am interested in working on Windows 7 64bit support for PyPy. Does >> anyone know what the best way to get started with this is? Is there a list >> of work that needs to be done to support Windows anywhere? >> >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> http://mail.python.org/mailman/listinfo/pypy-dev > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev From arigo at tunes.org Wed Aug 21 09:46:05 2013 From: arigo at tunes.org (Armin Rigo) Date: Wed, 21 Aug 2013 09:46:05 +0200 Subject: [pypy-dev] Windows 7 x64 development In-Reply-To: <1B12946B-109E-4105-B1CB-60FDD1A59E49@gmail.com> References: <1B12946B-109E-4105-B1CB-60FDD1A59E49@gmail.com> Message-ID: Hi all, I finally wrote out the details of what I think is a reasonable plan. https://bitbucket.org/pypy/pypy/raw/default/pypy/doc/windows.rst "What is missing for a full 64-bit translation" A bient?t, Armin. From rami.chowdhury at gmail.com Wed Aug 21 15:13:35 2013 From: rami.chowdhury at gmail.com (Rami Chowdhury) Date: Wed, 21 Aug 2013 14:13:35 +0100 Subject: [pypy-dev] london sprint - newbie question + accommodation note Message-ID: 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 have a spare room that can accommodate one and even a sofa bed if anyone is particularly adventurous. If anyone's looking for somewhere to crash, please contact me off-list. Cheers, Rami -- Rami Chowdhury "A mind all logic is like a knife all blade - it makes the hand bleed that uses it." -- Rabindranath Tagore +44-7581-430-517 / +1-408-597-7068 / +88-01771-064063 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Wed Aug 21 18:25:32 2013 From: arigo at tunes.org (Armin Rigo) Date: Wed, 21 Aug 2013 18:25:32 +0200 Subject: [pypy-dev] london sprint - newbie question + accommodation note In-Reply-To: References: Message-ID: Hi Rami, On Wed, Aug 21, 2013 at 3:13 PM, Rami Chowdhury wrote: > 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? Yes: we will certainly give intro sessions, as needed by the people and the topics we (collectively) choose to work on; "dynamically-allocated", I suppose. But you can count on getting some intro sessions Monday morning, after we start the sprint officially. A bient?t, Armin. From jacqueline.follereau at hotmail.fr Thu Aug 22 15:38:29 2013 From: jacqueline.follereau at hotmail.fr (Jacqueline Follereau) Date: Thu, 22 Aug 2013 15:38:29 +0200 Subject: [pypy-dev] Quindi farvi fiducia? (Donazione) Message-ID: 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? voglio comunicare con il mondo e fare qualcosa che avrei forse non fatto, ma penso che dovremmo rischiare, confidando qualcuno. Sono affetto da cancro al cervello in malati terminali, e le mie giornate non sono pi? su un filo secondo l'ultimo analizza lo scanner che il mio medico mi ha detto per giustificare me stesso la palla che si deposita nel mio cervello per oltre 4 anni. Sono sterile vale a dire senza figli, ho intenzione di donare parte della mia propriet?. Ho lavorato nel business del petrolio per due anni presso la Refinery Company ivoriano (SIR), voglio un podi quel denaro va a varie associazioni, orfanotrofi e alle persone bisognose. Non importa chi siete, desidero con tutto il cuore di donare questo denaro del valore di circa euro 2.903.000 (Due Milioni Di Novecento e tre Mila euro) che viene aggiornato una societ? di sicurezza. Soffro tanto che faccio fatica a dormire, io sono turbato sapere che cosa sarebbe il denaro investito dopo la mia morte, non mi importa se si finisce nelle mani di qualcuno che ? cosciente e timore di Dio con un cuore aperto e generoso pu? fare buon uso; Ma chi? Non lo so! Se ? possibile con tutto il cuore e accettare questo compito, per favore fatemelo sapere, per favore! Vi prego di contattarmi al pi? presto se siete d'accordo a rispettare le mie istruzioni. Possa la pace e la misericordia di Dio sia con voi. Signora JACQUELINE FOLLEREAU -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Fri Aug 23 12:57:38 2013 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 23 Aug 2013 12:57:38 +0200 Subject: [pypy-dev] london sprint travel info Message-ID: <52174022.3020105@gmx.de> 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 From arigo at tunes.org Fri Aug 23 19:40:20 2013 From: arigo at tunes.org (Armin Rigo) Date: Fri, 23 Aug 2013 19:40:20 +0200 Subject: [pypy-dev] Windows 7 x64 development In-Reply-To: References: <1B12946B-109E-4105-B1CB-60FDD1A59E49@gmail.com> Message-ID: Hi again, On Wed, Aug 21, 2013 at 9:46 AM, Armin Rigo wrote: > I finally wrote out the details of what I think is a reasonable plan. > > https://bitbucket.org/pypy/pypy/raw/default/pypy/doc/windows.rst > "What is missing for a full 64-bit translation" Updated the file. Anyone with an interest in helping on Win64, please start by looking there --- the first step does not require any PyPy knowledge, because it's hacking at *CPython* :-) A bient?t, Armin. From hzhou1 at cs.uml.edu Sat Aug 24 13:04:06 2013 From: hzhou1 at cs.uml.edu (Heng Zhou) Date: Sat, 24 Aug 2013 07:04:06 -0400 Subject: [pypy-dev] Difficult in installing PyPy3 2.1 Beta 1 on ubuntu Message-ID: I downloaded the PyPy3 2.1 Beta 1 prebuilt binary file " https://bitbucket.org/pypy/pypy/downloads/pypy-2.1-linux64.tar.bz2" and unpack it. But When I run pypy in the bin directory, I was given an error: "The program 'pypy' is currently not installed. You can install it by typing: ..." instead of the success message in http://doc.pypy.org/en/latest/getting-started.html#id14. Actually this webpage says "PyPy is ready to be executed as soon as you unpack the tarball or the zip file, with no need to install it in any specific location:" Is there any particular install instruction for PyPy3 2.1 Beta 1 on Ubuntu as opposed to the web? Do I have to create a symlink? Btw, I'm using Ubuntu 13.04, is this mismatch of Ubuntu version the reason for the installation failure? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.legoll at gmail.com Sat Aug 24 14:05:40 2013 From: vincent.legoll at gmail.com (Vincent Legoll) Date: Sat, 24 Aug 2013 14:05:40 +0200 Subject: [pypy-dev] Difficult in installing PyPy3 2.1 Beta 1 on ubuntu In-Reply-To: References: Message-ID: Hello, On Sat, Aug 24, 2013 at 1:04 PM, Heng Zhou wrote: > I downloaded the PyPy3 2.1 Beta 1 prebuilt binary file " > https://bitbucket.org/pypy/pypy/downloads/pypy-2.1-linux64.tar.bz2" and > unpack it. But When I run pypy in the bin directory > What are you doing exactly when you say "When I run pypy in the bin directory" ? what's your PATH ? Did you cd into bin and run it as ./pypy ? -- Vincent Legoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From hzhou1 at cs.uml.edu Sun Aug 25 01:56:01 2013 From: hzhou1 at cs.uml.edu (Heng Zhou) Date: Sat, 24 Aug 2013 19:56:01 -0400 Subject: [pypy-dev] question about install pymongo Message-ID: I have installed the PyPy3 2.1 Beta 1 on my ubuntu. When I tried to import pymongo, a third party driver for mongodb, I was told "ImportError: No module named pymongo". So my questions are: (1)Does it mean I have to install pymongo again for pypy3 2.1 Beta 1? (2)If yes, http://doc.pypy.org/en/latest/getting-started.html#installing-pypy says: If you want to install 3rd party libraries, the most convenient way is to install distribute and pip: $ curl -O http://python-distribute.org/distribute_setup.py $ curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py $ ./pypy-2.1/bin/pypy distribute_setup.py $ ./pypy-2.1/bin/pypy get-pip.py $ ./pypy-2.1/bin/pip install pygments # for example But, These instructions seems for pypy-2.1, the stable release for python 2.x only, not for PyPy3 which is used for python 3. Are the steps for installing 3rd party libraries for PyPy3 similar to the above ones? (3)If yes, I don't have curl installed in my ubuntu, do I have to install it? (4)I used "pip-3.3" which is particularly designed for python3 to install the pymongo instead of "pip". Is there any corresponding counterpart of pip-3.3 for PyPy3 2.1 Beta 1? If there is any, how to get it? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From santagada at gmail.com Sun Aug 25 04:06:44 2013 From: santagada at gmail.com (Leonardo Santagada) Date: Sat, 24 Aug 2013 23:06:44 -0300 Subject: [pypy-dev] question about install pymongo In-Reply-To: References: Message-ID: just a tip, distribute merged with setuptools so probably the docs should be updated (if the new setuptools support pypy3) On Sat, Aug 24, 2013 at 8:56 PM, Heng Zhou wrote: > I have installed the PyPy3 2.1 Beta 1 on my ubuntu. When I tried to import > pymongo, a third party driver for mongodb, I was told "ImportError: No > module named pymongo". So my questions are: > > (1)Does it mean I have to install pymongo again for pypy3 2.1 Beta 1? > (2)If yes, > http://doc.pypy.org/en/latest/getting-started.html#installing-pypy says: > If you want to install 3rd party libraries, the most convenient way is to > install distribute and pip: > $ curl -O http://python-distribute.org/distribute_setup.py > $ curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py > $ ./pypy-2.1/bin/pypy distribute_setup.py > $ ./pypy-2.1/bin/pypy get-pip.py > $ ./pypy-2.1/bin/pip install pygments # for example > > But, These instructions seems for pypy-2.1, the stable release for python > 2.x only, not for PyPy3 which is used for python 3. Are the steps for > installing 3rd party libraries for PyPy3 similar to the above ones? > (3)If yes, I don't have curl installed in my ubuntu, do I have to install > it? > (4)I used "pip-3.3" which is particularly designed for python3 to install > the pymongo instead of "pip". Is there any corresponding counterpart of > pip-3.3 for PyPy3 2.1 Beta 1? If there is any, how to get it? > > Thank you. > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev > > -- Leonardo Santagada -------------- next part -------------- An HTML attachment was scrubbed... URL: From hzhou1 at cs.uml.edu Sun Aug 25 05:36:48 2013 From: hzhou1 at cs.uml.edu (Heng Zhou) Date: Sat, 24 Aug 2013 23:36:48 -0400 Subject: [pypy-dev] question about install pymongo In-Reply-To: References: Message-ID: Just now I tried to execute the steps in http://doc.pypy.org/en/latest/ getting-started.html#installing-pypy. curl -O http://python-distribute.org/distribute_setup.py is OK, curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py is OK, ./pypy-2.1/bin/pypy distribute_setup.py is OK (I have a different directory for PyPy3 2.1 Beta 1, but the executable pypy is still in the bin directory and I do all the steps in the bin directory). But ./pypy-2.1/bin/pypy get-pip.py gives error : "An error occurred while trying to run get- pip.py, Make sure you have setuptools or distribute installed." I checked the bin directory, distribute_setup.py and get-pip.py is in it. What's the matter and how can I install pymongo in the PyPy3 2.1 Beta 1? On Sat, Aug 24, 2013 at 10:06 PM, Leonardo Santagada wrote: > just a tip, distribute merged with setuptools so probably the docs should > be updated (if the new setuptools support pypy3) > > > On Sat, Aug 24, 2013 at 8:56 PM, Heng Zhou wrote: > >> I have installed the PyPy3 2.1 Beta 1 on my ubuntu. When I tried to >> import pymongo, a third party driver for mongodb, I was told "ImportError: >> No module named pymongo". So my questions are: >> >> (1)Does it mean I have to install pymongo again for pypy3 2.1 Beta 1? >> (2)If yes, >> http://doc.pypy.org/en/latest/getting-started.html#installing-pypysays: >> If you want to install 3rd party libraries, the most convenient way is to >> install distribute and pip: >> $ curl -O http://python-distribute.org/distribute_setup.py >> $ curl -O https://raw.github.com/pypa/pip/master/contrib/get-pip.py >> $ ./pypy-2.1/bin/pypy distribute_setup.py >> $ ./pypy-2.1/bin/pypy get-pip.py >> $ ./pypy-2.1/bin/pip install pygments # for example >> >> But, These instructions seems for pypy-2.1, the stable release for python >> 2.x only, not for PyPy3 which is used for python 3. Are the steps for >> installing 3rd party libraries for PyPy3 similar to the above ones? >> (3)If yes, I don't have curl installed in my ubuntu, do I have to install >> it? >> (4)I used "pip-3.3" which is particularly designed for python3 to install >> the pymongo instead of "pip". Is there any corresponding counterpart of >> pip-3.3 for PyPy3 2.1 Beta 1? If there is any, how to get it? >> >> Thank you. >> >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> http://mail.python.org/mailman/listinfo/pypy-dev >> >> > > > -- > > Leonardo Santagada > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacqueline.follereau at yahoo.fr Tue Aug 27 05:32:19 2013 From: jacqueline.follereau at yahoo.fr (Jacqueline Follereau) Date: Tue, 27 Aug 2013 05:32:19 +0200 Subject: [pypy-dev] Quindi farvi fiducia? (Donazione) RICHIAMO Message-ID: <8BQK8K2L-HEAE-F6HM-RRQD-UL4C95X01F8W@yahoo.fr> Ciao, Nomino Jacqueline Follereau, li avevo indirizzare un messaggio per spiegarvi la mia volont?, a seguito di ci?, il mio computer ? guastarsi e non arrivo ad avere accesso al mio indirizzo posta elettronica. Per ci? vi chiedo di inviarmi la vostra risposta al mio nuovo indirizzo sul quale vi scrivo attualmente affinch? possa rispondervi affinch? possa darvi le istruzioni. Vi presento tutte le mie scuse per il fastidio involontario che ? stato crea. Vi lascio sotto il messaggio che voi avevo lasciare: 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? voglio comunicare con il mondo e fare qualcosa che avrei forse non fatto, ma penso che dovremmo rischiare, confidando qualcuno. Sono affetto da cancro al cervello in malati terminali, e le mie giornate non sono pi? su un filo secondo l'ultimo analizza lo scanner che il mio medico mi ha detto per giustificare me stesso la palla che si deposita nel mio cervello per oltre 4 anni. Sono sterile vale a dire senza figli, ho intenzione di donare parte della mia propriet?. Ho lavorato nel business del petrolio per due anni presso la Refinery Company ivoriano (SIR), voglio un podi quel denaro va a varie associazioni, orfanotrofi e alle persone bisognose. Non importa chi siete, desidero con tutto il cuore di donare questo denaro del valore di circa euro 2.903.000 (Due Milioni Di Novecento e tre Mila euro) che viene aggiornato una societ? di sicurezza. Soffro tanto che faccio fatica a dormire, io sono turbato sapere che cosa sarebbe il denaro investito dopo la mia morte, non mi importa se si finisce nelle mani di qualcuno che ? cosciente e timore di Dio con un cuore aperto e generoso pu? fare buon uso; Ma chi? Non lo so! Se ? possibile con tutto il cuore e accettare questo compito, per favore fatemelo sapere, per favore! Vi prego di contattarmi al pi? presto se siete d'accordo a rispettare le mie istruzioni. Possa la pace e la misericordia di Dio sia con voi. Signora JACQUELINE FOLLEREAU -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurie at tratt.net Wed Aug 28 15:28:05 2013 From: laurie at tratt.net (Laurence Tratt) Date: Wed, 28 Aug 2013 14:28:05 +0100 Subject: [pypy-dev] Some benchmarking numbers Message-ID: <20130828132805.GX17807@phase.tratt.net> Some of you may remember an experiment that Carl Friedrich and I did at the beginning of this year, comparing PyPy against various other VMs. I've recently added V8 to the experiment, Tim Felgentreff has added Topaz, and I've updated all other VMs to the latest public release. See the numbers here: http://tratt.net/laurie/research/pubs/files/metatracing_vms/results/0.4/linux_x86_64_1.html All the normal cautions about over-interpreting benchmark results (particularly on synthetic micro-benchmarks) apply. Nevertheless, you may still find this interesting. In the future, it might be interesting to add the DeltaBlue benchmark for as many languages as we can find. I'm not going to put too much work into this, so patches are welcome: https://github.com/ltratt/metatracing_vms_experiment Laurie -- Personal http://tratt.net/laurie/ Software Development Team http://soft-dev.org/ https://github.com/ltratt http://twitter.com/laurencetratt From cfbolz at gmx.de Fri Aug 30 11:23:07 2013 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 30 Aug 2013 10:23:07 +0100 Subject: [pypy-dev] [pypy-commit] pypy default: Unroll list.count() when the list is virtual or very small and constant lenght In-Reply-To: <20130829224743.5B7C41C01F5@cobra.cs.uni-duesseldorf.de> References: <20130829224743.5B7C41C01F5@cobra.cs.uni-duesseldorf.de> Message-ID: <5220647B.1080809@gmx.de> Hi Alex, please revert this change, it can lead to combinatorial explosion: it can give a bridge per pattern of where in the list the object is found. Cheers, Carl Friedrich On 29/08/13 23:47, alex_gaynor wrote: > Author: Alex Gaynor > Branch: > Changeset: r66432:185512e0c4df > Date: 2013-08-29 15:47 -0700 > http://bitbucket.org/pypy/pypy/changeset/185512e0c4df/ > > Log: Unroll list.count() when the list is virtual or very small and > constant lenght > > diff --git a/pypy/module/pypyjit/test_pypy_c/test_containers.py b/pypy/module/pypyjit/test_pypy_c/test_containers.py > --- a/pypy/module/pypyjit/test_pypy_c/test_containers.py > +++ b/pypy/module/pypyjit/test_pypy_c/test_containers.py > @@ -241,3 +241,22 @@ > loop, = log.loops_by_filename(self.filepath) > ops = loop.ops_by_id('getitem', include_guard_not_invalidated=False) > assert log.opnames(ops) == [] > + > + def test_list_count_virtual_list(self): > + def main(n): > + i = 0 > + while i < n: > + i += [n].count(n) > + return i > + > + log = self.run(main, [1000]) > + assert log.result == main(1000) > + loop, = log.loops_by_filename(self.filepath) > + assert loop.match(""" > + i7 = int_lt(i5, i6) > + guard_true(i7, descr=...) > + guard_not_invalidated(descr=...) > + i9 = int_add(i5, 1) > + --TICK-- > + jump(..., descr=...) > + """) > diff --git a/pypy/objspace/std/listobject.py b/pypy/objspace/std/listobject.py > --- a/pypy/objspace/std/listobject.py > +++ b/pypy/objspace/std/listobject.py > @@ -562,6 +562,8 @@ > 'L.reverse() -- reverse *IN PLACE*' > self.reverse() > > + @jit.look_inside_iff(lambda self, space, w_value: > + jit.loop_unrolling_heuristic(self, self.length(), UNROLL_CUTOFF)) > def descr_count(self, space, w_value): > '''L.count(value) -> integer -- return number of > occurrences of value''' > _______________________________________________ > pypy-commit mailing list > pypy-commit at python.org > http://mail.python.org/mailman/listinfo/pypy-commit > From amauryfa at gmail.com Fri Aug 30 13:58:01 2013 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Fri, 30 Aug 2013 13:58:01 +0200 Subject: [pypy-dev] [pypy-commit] pypy default: Unroll list.count() when the list is virtual or very small and constant lenght In-Reply-To: <5220647B.1080809@gmx.de> References: <20130829224743.5B7C41C01F5@cobra.cs.uni-duesseldorf.de> <5220647B.1080809@gmx.de> Message-ID: 2013/8/30 Carl Friedrich Bolz > Hi Alex, > > please revert this change, it can lead to combinatorial explosion: it > can give a bridge per pattern of where in the list the object is found. > Doesn't list.count() traverse all the list in all cases? -- Amaury Forgeot d'Arc -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Fri Aug 30 14:31:18 2013 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 30 Aug 2013 13:31:18 +0100 Subject: [pypy-dev] [pypy-commit] pypy default: Unroll list.count() when the list is virtual or very small and constant lenght In-Reply-To: References: <20130829224743.5B7C41C01F5@cobra.cs.uni-duesseldorf.de> <5220647B.1080809@gmx.de> Message-ID: <52209096.3080905@gmx.de> On 30/08/13 12:58, Amaury Forgeot d'Arc wrote: > > 2013/8/30 Carl Friedrich Bolz > > > Hi Alex, > > please revert this change, it can lead to combinatorial explosion: it > can give a bridge per pattern of where in the list the object is found. > > > Doesn't list.count() traverse all the list in all cases? It looks like this: count = 0 i = 0 while i < self.length(): if space.eq_w(self.getitem(i), w_value): count += 1 i += 1 So there's a guard_true/false for every item. Note that even changing to: count += space.eq_w(self.getitem(i), w_value) does not fix this, because the guard is coming from inside space.istrue, or space.eq Cheers, Carl Friedrich From alex.gaynor at gmail.com Fri Aug 30 16:09:25 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Fri, 30 Aug 2013 07:09:25 -0700 Subject: [pypy-dev] [pypy-commit] pypy default: Unroll list.count() when the list is virtual or very small and constant lenght In-Reply-To: <52209096.3080905@gmx.de> References: <20130829224743.5B7C41C01F5@cobra.cs.uni-duesseldorf.de> <5220647B.1080809@gmx.de> <52209096.3080905@gmx.de> Message-ID: Hi Carl, I wonder if there's some sub-set of cases we can still unroll in. The particular code this was for is: https://bitbucket.org/pypy/pypy/src/default/lib-python/2.7/uuid.py#cl-130 . I wonder if there are cases where the list is both virtual *and* we aren't able to constant fold some of the space.eq_w()? Alex On Fri, Aug 30, 2013 at 5:31 AM, Carl Friedrich Bolz wrote: > On 30/08/13 12:58, Amaury Forgeot d'Arc wrote: > > > > 2013/8/30 Carl Friedrich Bolz > > > > > Hi Alex, > > > > please revert this change, it can lead to combinatorial explosion: it > > can give a bridge per pattern of where in the list the object is > found. > > > > > > Doesn't list.count() traverse all the list in all cases? > > It looks like this: > > count = 0 > i = 0 > while i < self.length(): > if space.eq_w(self.getitem(i), w_value): > count += 1 > i += 1 > > So there's a guard_true/false for every item. > > Note that even changing to: > > count += space.eq_w(self.getitem(i), w_value) > > does not fix this, because the guard is coming from inside space.istrue, > or space.eq > > Cheers, > > Carl Friedrich > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Fri Aug 30 18:47:26 2013 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 30 Aug 2013 17:47:26 +0100 Subject: [pypy-dev] [pypy-commit] pypy default: Unroll list.count() when the list is virtual or very small and constant lenght In-Reply-To: References: <20130829224743.5B7C41C01F5@cobra.cs.uni-duesseldorf.de> <5220647B.1080809@gmx.de> <52209096.3080905@gmx.de> Message-ID: <5220CC9E.5020908@gmx.de> On 30/08/13 15:09, Alex Gaynor wrote: > Hi Carl, > > I wonder if there's some sub-set of cases we can still unroll in. The > particular code this was for is: > https://bitbucket.org/pypy/pypy/src/default/lib-python/2.7/uuid.py#cl-130 . This is a completely indirect and way too clever way to express what is meant. I have absolutely no pity for this code being slow. Let's rewrite it to simply be more explicit, even if it's a few lines longer. > I wonder if there are cases where the list is both virtual *and* we > aren't able to constant fold some of the space.eq_w()? Yes, there can be, it's easy to write. Even the uuid case has the combinatorial problem, it's just that we expect people to not pass in random combinations of arguments. Cheers, Carl Friedrich From alex.gaynor at gmail.com Fri Aug 30 19:04:55 2013 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Fri, 30 Aug 2013 10:04:55 -0700 Subject: [pypy-dev] [pypy-commit] pypy default: Unroll list.count() when the list is virtual or very small and constant lenght In-Reply-To: <5220CC9E.5020908@gmx.de> References: <20130829224743.5B7C41C01F5@cobra.cs.uni-duesseldorf.de> <5220647B.1080809@gmx.de> <52209096.3080905@gmx.de> <5220CC9E.5020908@gmx.de> Message-ID: Fixing the code is fine with me, does someone want to help get that patch upstream into CPython so we don't have to worry about losing our modifications when we upgrade the stdlib? Alex On Fri, Aug 30, 2013 at 9:47 AM, Carl Friedrich Bolz wrote: > On 30/08/13 15:09, Alex Gaynor wrote: > > Hi Carl, > > > > I wonder if there's some sub-set of cases we can still unroll in. The > > particular code this was for is: > > > https://bitbucket.org/pypy/pypy/src/default/lib-python/2.7/uuid.py#cl-130. > > This is a completely indirect and way too clever way to express what is > meant. I have absolutely no pity for this code being slow. Let's > rewrite it to simply be more explicit, even if it's a few lines longer. > > > I wonder if there are cases where the list is both virtual *and* we > > aren't able to constant fold some of the space.eq_w()? > > Yes, there can be, it's easy to write. Even the uuid case has the > combinatorial problem, it's just that we expect people to not pass in > random combinations of arguments. > > Cheers, > > Carl Friedrich > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anto.cuni at gmail.com Sat Aug 31 16:11:06 2013 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sat, 31 Aug 2013 16:11:06 +0200 Subject: [pypy-dev] pypy-pyarray branch Message-ID: Hi Matti, I and Romain reviewed the pypy-pyarray branch: we think there are a couple of issues to be solved before it can be merged, we added some comments to your TODO list. Otherwise, the branch looks fine and useful :) ciao, Anto. Romain -------------- next part -------------- An HTML attachment was scrubbed... URL: