From pypy-dev-issue at codespeak.net Fri Apr 1 09:02:39 2011 From: pypy-dev-issue at codespeak.net (Martijn) Date: Fri, 01 Apr 2011 07:02:39 +0000 Subject: [PyPy-issue] [issue664] [PATCH] Extend readline emulation to support colour code and ansi escapes Message-ID: <1301641359.77.0.238102738397.issue664@> Martijn added the comment: Interesting you ask this. I knew this already, which is why I implemented it, but if you ask how I know this, good question. It is used a lot because you can't use ANSI colour codes in prompts without it. I did some digging: the term to search for is RL_PROMPT_START_IGNORE. It is documented under rl_expand_prompt in the info pages, see http://www.manpagez.com/info/rlman/rlman-6.0/rlman_35.php . _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 1 15:05:02 2011 From: pypy-dev-issue at codespeak.net (Martijn) Date: Fri, 01 Apr 2011 13:05:02 +0000 Subject: [PyPy-issue] [issue674] Need a functional distutils.sysconfig for installing packages in pypy Message-ID: <1301663102.8.0.320020237288.issue674@> Martijn added the comment: Also similar to issue 662 (which has a somewhat overly simple patch), it would be very good to get this fixed. ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 4 22:43:54 2011 From: pypy-dev-issue at codespeak.net (Martijn) Date: Mon, 04 Apr 2011 20:43:54 +0000 Subject: [PyPy-issue] [issue650] pypy_decl.h uses incorrect types for arguments Message-ID: <1301949834.41.0.29390890069.issue650@> Martijn added the comment: Attaching a WIP patch for Typedef support. Passes tests and fixes the problem. Needs more tests. _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ctypes_typedef-wip.patch Type: text/x-diff Size: 7558 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Tue Apr 5 21:43:54 2011 From: pypy-dev-issue at codespeak.net (Martijn) Date: Tue, 05 Apr 2011 19:43:54 +0000 Subject: [PyPy-issue] [issue650] [PATCH] pypy_decl.h uses incorrect types for arguments Message-ID: <1302032634.59.0.731446027752.issue650@> Martijn added the comment: Attached is a version with tests. Please review. module/cpyext/api.py | 16 +++++++++------- module/cpyext/test/test_api.py | 21 +++++++++++++++++++++ rpython/lltypesystem/ll2ctypes.py | 4 ++++ rpython/lltypesystem/lltype.py | 28 ++++++++++++++++++++++++++++ rpython/lltypesystem/rffi.py | 2 ++ rpython/lltypesystem/test/test_ll2ctypes.py | 6 ++++++ rpython/lltypesystem/test/test_lltype.py | 16 +++++++++++++++- rpython/lltypesystem/test/test_rffi.py | 1 + translator/c/database.py | 4 +++- translator/c/test/test_database.py | 12 +++++++++++- ---------- title: pypy_decl.h uses incorrect types for arguments -> [PATCH] pypy_decl.h uses incorrect types for arguments _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ctypes_typedef.patch Type: text/x-diff Size: 10252 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Tue Apr 5 23:50:36 2011 From: pypy-dev-issue at codespeak.net (Martijn) Date: Tue, 05 Apr 2011 21:50:36 +0000 Subject: [PyPy-issue] [issue650] [PATCH] pypy_decl.h uses incorrect types for arguments Message-ID: <1302040236.95.0.364386223733.issue650@> Martijn added the comment: Fixed version that doesn't break translation. _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ctypes_typedef.patch Type: text/x-diff Size: 10252 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Tue Apr 5 23:52:43 2011 From: pypy-dev-issue at codespeak.net (Martijn) Date: Tue, 05 Apr 2011 21:52:43 +0000 Subject: [PyPy-issue] [issue650] [PATCH] pypy_decl.h uses incorrect types for arguments Message-ID: <1302040363.05.0.132131267403.issue650@> Martijn added the comment: This time the correct patch. _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: cpython_typedef.patch Type: text/x-diff Size: 10785 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Thu Apr 7 00:02:26 2011 From: pypy-dev-issue at codespeak.net (Martijn) Date: Wed, 06 Apr 2011 22:02:26 +0000 Subject: [PyPy-issue] [issue662] get_config_vars has nothing for CC, while expected internally Message-ID: <1302127346.86.0.486945183148.issue662@> Martijn added the comment: Here is a patch that creates a Makefile and pyconfig.h during building so the unmodified distutils can work and so you can successfully build C extensions with the default setup. With this the problem is solved. ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: capi-distutils.patch Type: text/x-diff Size: 19077 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Thu Apr 7 11:44:29 2011 From: pypy-dev-issue at codespeak.net (Franck Pommereau) Date: Thu, 07 Apr 2011 09:44:29 +0000 Subject: [PyPy-issue] [issue679] TypeError: type 'AST' is not an acceptable base class Message-ID: <1302169469.54.0.776243188838.issue679@> New submission from Franck Pommereau : Dear PyPy developers, The following code fails with PyPy but works well with CPython (2.5 to 3.1) and Jython (2.5.1): >>>> import _ast >>>> class Foo(_ast.AST): pass Traceback (most recent call last): File "", line 1, in TypeError: type 'AST' is not an acceptable base class Is there any reason for that and could it be fixed? Or is there any workaround? I could reproduce that issue with both PyPy 1.4.1 and 1.3. Many thanks for your help! Franck ---------- effort: ??? messages: 2349 nosy: franckp, pypy-issue priority: feature release: 1.4 status: unread title: TypeError: type 'AST' is not an acceptable base class _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Thu Apr 7 11:51:20 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Thu, 07 Apr 2011 09:51:20 +0000 Subject: [PyPy-issue] [issue679] TypeError: type 'AST' is not an acceptable base class Message-ID: <1302169880.02.0.930451653847.issue679@> Amaury Forgeot d Arc added the comment: This has already been fixed in the "default" branch, which will soon become pypy 1.5. (changeset f540780193fd) ---------- status: unread -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 8 06:17:22 2011 From: pypy-dev-issue at codespeak.net (Stepan Bakshaev) Date: Fri, 08 Apr 2011 04:17:22 +0000 Subject: [PyPy-issue] [issue680] Transtale.py filed with KeyError Message-ID: <1302236242.52.0.776047440685.issue680@> New submission from Stepan Bakshaev : stepan at imac-ubuntu:~/develop$ echo 'print "ioioioiooo"' > test.py stepan at imac-ubuntu:~/develop$ python pypy/pypy/translator/goal/translate.py test.py [translation:info] Translating target as defined by test ioioioiooo [platform:msg] Setting platform to 'host' cc=None [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "pypy/pypy/translator/goal/translate.py", line 268, in main [translation:ERROR] default_goal='compile') [translation:ERROR] File "/home/stepan/develop/pypy/pypy/translator/driver.py", line 827, in from_targetspec [translation:ERROR] target = targetspec_dic['target'] [translation:ERROR] KeyError: 'target' [translation] start debugger... > /home/stepan/develop/pypy/pypy/translator/driver.py(827)from_targetspec() -> target = targetspec_dic['target'] (Pdb+) ---------- effort: ??? messages: 2352 nosy: pypy-issue, step2back priority: bug release: ??? status: unread title: Transtale.py filed with KeyError _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 8 06:18:45 2011 From: pypy-dev-issue at codespeak.net (Stepan Bakshaev) Date: Fri, 08 Apr 2011 04:18:45 +0000 Subject: [PyPy-issue] [issue680] Transtale.py filed with KeyError Message-ID: <1302236325.38.0.613743267449.issue680@> Stepan Bakshaev added the comment: stepan at imac-ubuntu:~/develop/pypy$ hg summary parent: 43205:195459aa1891 tip Revert again the changes in the import mechanism. branch: default commit: (clean) update: (current) ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 8 06:25:13 2011 From: pypy-dev-issue at codespeak.net (Alex Gaynor) Date: Fri, 08 Apr 2011 04:25:13 +0000 Subject: [PyPy-issue] [issue680] Transtale.py filed with KeyError Message-ID: <1302236713.03.0.83735642254.issue680@> Alex Gaynor added the comment: This is because translate.py only translates RPython, and your code isn't a valid RPython program. ---------- status: chatting -> wontfix _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 8 06:45:46 2011 From: pypy-dev-issue at codespeak.net (Stepan Bakshaev) Date: Fri, 08 Apr 2011 04:45:46 +0000 Subject: [PyPy-issue] [issue680] Transtale.py failed with KeyError instead output error about "your code isn't a valid RPython program" Message-ID: <1302237946.9.0.936527699691.issue680@> Stepan Bakshaev added the comment: Ok. my mistake. I change title. I reread http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html and don't find why my code is not RPython. ---------- title: Transtale.py filed with KeyError -> Transtale.py failed with KeyError instead output error about "your code isn't a valid RPython program" _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 8 07:55:39 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Fri, 08 Apr 2011 05:55:39 +0000 Subject: [PyPy-issue] [issue680] Transtale.py failed with KeyError instead output error about "your code isn't a valid RPython program" Message-ID: <1302242139.43.0.431411037384.issue680@> Fijal added the comment: You need to create a target. It's indeed not too well documented, look at targetnopstandalone.py. Note that RPython is an internal tool, most errors won't look good. _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 8 18:23:19 2011 From: pypy-dev-issue at codespeak.net (derdon) Date: Fri, 08 Apr 2011 16:23:19 +0000 Subject: [PyPy-issue] [issue681] translating fails on a mac (os.altsep is None) Message-ID: <1302279799.6.0.867906147801.issue681@> New submission from derdon : hg revision id is e5b1300d7453. Operating system is Mac OS X 10.5.8 (Leopard). Paste of the output, traceback and error messages in here: http://paste.pocoo.org/show/367959/. As one can see, the problem lies in pypy/module/imp/importing.py", line 95: It is assumed that os.altsep is always a valid instance of str. However, on my machine it is None. ---------- effort: ??? messages: 2357 nosy: derdon, pypy-issue priority: critical release: ??? status: unread title: translating fails on a mac (os.altsep is None) _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 8 18:34:06 2011 From: pypy-dev-issue at codespeak.net (Armin Rigo) Date: Fri, 08 Apr 2011 16:34:06 +0000 Subject: [PyPy-issue] [issue681] translating fails on a mac (os.altsep is None) Message-ID: <1302280446.83.0.445122593768.issue681@> Armin Rigo added the comment: Fixed in 4e798ad894a6. ---------- status: unread -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 9 17:45:11 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Sat, 09 Apr 2011 15:45:11 +0000 Subject: [PyPy-issue] [issue682] JIT issue in regular expressions Message-ID: <1302363911.18.0.436355632734.issue682@> New submission from Amaury Forgeot d Arc : Attached script shows an issue with the re module. The regexp is really simple: re.compile(" .type") But on 1001th line, it matches whereas the given line is completely different. The script passes when run with "--jit threshold=-1" ---------- effort: ??? messages: 2359 nosy: afa, pypy-issue priority: bug release: ??? status: unread title: JIT issue in regular expressions _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 9 17:46:26 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Sat, 09 Apr 2011 15:46:26 +0000 Subject: [PyPy-issue] [issue682] JIT issue in regular expressions Message-ID: <1302363986.57.0.694950174582.issue682@> Amaury Forgeot d Arc added the comment: I use the "pypy" programm installed on tannit 64bit: Python 2.7.0 (e1a23ce7b59a, Mar 14 2011, 18:13:20) [PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2 ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 9 18:03:59 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Sat, 09 Apr 2011 16:03:59 +0000 Subject: [PyPy-issue] [issue682] JIT issue in regular expressions Message-ID: <1302365039.7.0.0655357234242.issue682@> Amaury Forgeot d Arc added the comment: It passes with a more recent build: pypy-c-jit-43205-195459aa1891-linux64 Let's close the issue then ---------- status: chatting -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sun Apr 10 19:51:25 2011 From: pypy-dev-issue at codespeak.net (Chris Spencer) Date: Sun, 10 Apr 2011 17:51:25 +0000 Subject: [PyPy-issue] [issue683] Compiling with opt=jit on OS X gives binary that fails assertion Message-ID: <1302457885.47.0.900858271926.issue683@> New submission from Chris Spencer : Files at https://gist.github.com/912564 Compilation log succeeds, but trying to execute the mandel.b script gives an assertion failure. example5.py and mandel.b are taken from the pypy blog example (http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html). Compilation succeeds and runs without the JIT. (example2.py from previous post). The compilation fails if the gcrootfinder is left as default. ---------- effort: ??? messages: 2362 nosy: cspencer, pypy-issue priority: bug release: ??? status: unread title: Compiling with opt=jit on OS X gives binary that fails assertion _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 11 01:26:32 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Sun, 10 Apr 2011 23:26:32 +0000 Subject: [PyPy-issue] [issue683] Compiling with opt=jit on OS X gives binary that fails assertion Message-ID: <1302477992.51.0.757634266698.issue683@> Fijal added the comment: This should be fixed now, try again? ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 11 10:57:00 2011 From: pypy-dev-issue at codespeak.net (Chris Spencer) Date: Mon, 11 Apr 2011 08:57:00 +0000 Subject: [PyPy-issue] [issue683] Compiling with opt=jit on OS X gives binary that fails assertion Message-ID: <1302512220.18.0.685309043959.issue683@> Chris Spencer added the comment: That compiles and runs successfully with the default gcrootfinder now, thanks. ---------- status: chatting -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 15 01:02:46 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Thu, 14 Apr 2011 23:02:46 +0000 Subject: [PyPy-issue] [issue650] [PATCH] pypy_decl.h uses incorrect types for arguments Message-ID: <1302822166.84.0.0510904442332.issue650@> Amaury Forgeot d Arc added the comment: Applied the patch with d381cb2c140b (slightly modified: I changed T._origtype into T.OF) Thank you! ---------- status: in-progress -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 16 20:30:39 2011 From: pypy-dev-issue at codespeak.net (Ezio Melotti) Date: Sat, 16 Apr 2011 18:30:39 +0000 Subject: [PyPy-issue] [issue660] str.decode('utf8', 'replace') -- conformance with Unicode 5.2/6.0 Message-ID: <1302978639.67.0.534559969751.issue660@> Ezio Melotti added the comment: I wrote the patch without using bitmanipulation because it wasn't really obvious what it was doing, and since the patched code turned out to be faster than before I didn't introduce it again. _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 16 21:11:00 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Sat, 16 Apr 2011 19:11:00 +0000 Subject: [PyPy-issue] [issue660] str.decode('utf8', 'replace') -- conformance with Unicode 5.2/6.0 Message-ID: <1302981059.74.0.0165996488935.issue660@> Fijal added the comment: Commited, thanks for the patch and sorry for waiting! ---------- status: chatting -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sun Apr 17 12:58:56 2011 From: pypy-dev-issue at codespeak.net (Valery) Date: Sun, 17 Apr 2011 10:58:56 +0000 Subject: [PyPy-issue] [issue684] translation.compile_c() fails in translatorshell.py session (as of trunk 16.04.2011)) Message-ID: <1303037936.88.0.525755981859.issue684@> New submission from Valery : translator/c/src/g_include.h:11: fatal error: marshal.h: No such file or directory (during translation.compile_c() from translatorshell.py) I've to commented out #include and than it fails like that : [...] OSError: /tmp/usession-default-16/testing_1/testing_1.so: /tmp/usession-default- 16/testing_1/testing_1.so: undefined symbol: PyObject_Malloc Details: Python 2.7.0 (7bcedc5f2e61, Apr 16 2011, 18:24:11) [PyPy 1.5.0-alpha0 with GCC 4.4.4] on linux2 AMD64 Session to reproduce: def ack(x,y): if x == 0: return y + 1 elif y == 0: return ack(x - 1, 1) else: return ack(x - 1, ack(x, y - 1)) t = Translation(ack) t.annotate([int, int]) t.rtype() ack_c = t.compile_c() ---------- effort: ??? messages: 2368 nosy: pypy-issue, vak priority: bug release: ??? status: unread title: translation.compile_c() fails in translatorshell.py session (as of trunk 16.04.2011)) _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sun Apr 17 20:00:03 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Sun, 17 Apr 2011 18:00:03 +0000 Subject: [PyPy-issue] [issue684] translation.compile_c() fails in translatorshell.py session (as of trunk 16.04.2011)) Message-ID: <1303063202.96.0.0340918436626.issue684@> Fijal added the comment: Install python-dev package (CPython header files). Why are you using translatorshell.py anyway? ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sun Apr 17 20:02:39 2011 From: pypy-dev-issue at codespeak.net (Steven Marguet) Date: Sun, 17 Apr 2011 18:02:39 +0000 Subject: [PyPy-issue] [issue685] Tkinter support by pypy Message-ID: <1303063359.64.0.136008666208.issue685@> New submission from Steven Marguet : Hello, I am quite new to Pyhton. I have made a program which meshes a 3D space with troncated octaedra. Since I have to create a lot of octaedra and that it was quite slow in pure python, I have decided to try PyPy, "just to see"... I have been amazingly surprised by the results. My code runs much faster, even much faster than Fortran 95 code using exactly the same algorithm (which might be not optimal at all, but respect for PyPy !) To make sure there was no mistakes, I tried many compiler options of the gfortran compiler, but PyPy was always faster ! (here is an example of the options I used : gfortran -Wall -lf2c -O3 -funroll-loops -c "%f") I now want to create a GUI to help my students to use the mesher but a face a problem. Since I am not familiar with GUI programming, I have decided to try Tkinter about which I have read it was suited for beginners. I was able to download the Pmw module and to build it on my computer with PyPy : cd MyDirectoryOfPwm pypy setup.py install I am now able to import it with PyPy. My problem is that I am not able to do the same thing with Tkinker and I really have no idea of how to proceed. In the librairies of python, I can see the different files of Tkinter, but no setup.py to reinstall it... I don't know if it is possible to write a program by hand to perform the installation with pypy... So if you have a little bit of free time and an idea to help me I would be gratefull ! Thank you, Steven PS : a support of numpy and scipy by PyPy should also be awesome ! ---------- effort: ??? messages: 2370 nosy: pypy-issue, steven.marguet priority: wish release: 1.4 status: testing title: Tkinter support by pypy _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sun Apr 17 20:18:45 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Sun, 17 Apr 2011 18:18:45 +0000 Subject: [PyPy-issue] [issue684] translation.compile_c() fails in translatorshell.py session (as of trunk 16.04.2011)) Message-ID: <1303064325.71.0.174162558652.issue684@> Fijal added the comment: Then something is wrong with your python-dev if it doesn't work. Make sure you can compile things using "Python.h". translatorshell is just for playing. If you really want to do rpython programs, you need to create target in translator/goal, look for targetnopstandalone.py Anyway, RPython is not a general purpose language and we dicourage using it. Why would you bother? _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 18 09:04:05 2011 From: pypy-dev-issue at codespeak.net (Vetoshkin Nikita) Date: Mon, 18 Apr 2011 07:04:05 +0000 Subject: [PyPy-issue] [issue686] PyPy dir() implementation differs from CPython's Message-ID: <1303110245.62.0.150918556921.issue686@> New submission from Vetoshkin Nikita : Here's a bit patological case class AsString(object): def __getattribute__(self, name): return name print dir(AsString()) Passes on cpython, failes on PyPy. I raised this issue once on #pypy, but it's still there :) So - here's a ticket. PyPy calls obj.__dir__ instead of type(obj).__dir__ Patch is pretty straighforward: diff -r 2d96e93e4a47 pypy/module/__builtin__/app_inspect.py --- a/pypy/module/__builtin__/app_inspect.py Mon Apr 18 08:07:53 2011 +0200 +++ b/pypy/module/__builtin__/app_inspect.py Mon Apr 18 12:40:17 2011 +0600 @@ -76,8 +76,8 @@ result.sort() return result - elif hasattr(obj, '__dir__'): - result = obj.__dir__() + elif hasattr(type(obj), '__dir__'): + result = type(obj).__dir__() if not isinstance(result, list): raise TypeError("__dir__() must return a list, not %r" % ( type(result),)) But example still failes, cause cpython (http://hg.python.org/cpython/file/ac563fba7161/Objects/object.c#l1315) makes a new dict if __dict__ isn't a dictionary - pypy doesn't. ---------- effort: easy messages: 2373 nosy: nekto0n, pypy-issue priority: bug release: ??? status: unread title: PyPy dir() implementation differs from CPython's _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 18 09:28:30 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Mon, 18 Apr 2011 07:28:30 +0000 Subject: [PyPy-issue] [issue684] translation.compile_c() fails in translatorshell.py session (as of trunk 16.04.2011)) Message-ID: <1303111710.59.0.242053940218.issue684@> Fijal added the comment: Bah. This should be fixed, but it's indeed not the highest priority since nobody uses translatorshell anyway :) feel free to discuss using RPython on pypy-dev, will close this issue now ---------- status: chatting -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 18 10:16:01 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Mon, 18 Apr 2011 08:16:01 +0000 Subject: [PyPy-issue] [issue686] PyPy dir() implementation differs from CPython's Message-ID: <1303114561.46.0.403445896967.issue686@> Amaury Forgeot d Arc added the comment: Fixed in addc4bcf08a3, with other changes to let you example pass. Thanks for the report and the patch! ---------- status: unread -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 18 18:19:18 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Mon, 18 Apr 2011 16:19:18 +0000 Subject: [PyPy-issue] [issue685] Tkinter support by pypy Message-ID: <1303143558.41.0.37419436327.issue685@> Fijal added the comment: Hi. It's good to hear :) We're working on tkinter, the preliminary version is available here: https://bitbucket.org/pypy/tkinter numpy and scipy is on-the-way, but we don't know how much time it'll take. Nobody is working on it full-time and progress only happen sporadically. Please restrict use of issue tracker to bugs (like tkinter does not work) and post other stuff (like "I want to help") to the mailing list, it's easier to start a discussion there. Cheers, fijal _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 19 00:59:10 2011 From: pypy-dev-issue at codespeak.net (Dave Malcolm) Date: Mon, 18 Apr 2011 22:59:10 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303167550.88.0.74790300324.issue687@> New submission from Dave Malcolm : Rationale: I'm trying to make the generated C "sources" for PyPy be more amenable to debugging at the C level, when debugging low level crashes, or e.g. when valgrinding pypy. Currently, the bulk of the generated C sources are of the form: implement.c, implement1.c, implement2.c, etc I'm attaching a patch which tries to make the generated C sources reflect that of the RPython sources, and adds testing for this. With this is place: pypy/translator/c/test/test_standalone.py:TestStandalone.test_hello_world has these generated C files: [c:writing] structdef.h [c:writing] forwarddecl.h [c:writing] structimpl.c [c:writing] nonfuncnodes.c [c:writing] rpython_memory_gctransform_refcounting.c [c:writing] rpython_exceptiondata.c [c:writing] rlib_rposix.c [c:writing] translator_c_test_test_standalone.c [c:writing] rpython_lltypesystem_rclass.c [c:writing] rpython_lltypesystem_llmemory.c [c:writing] translator_c_extfunc.c [c:writing] rpython_memory_gctransform_transform.c [c:writing] implement.c [c:writing] translator_exceptiontransform.c [c:writing] rpython_lltypesystem_ll_str.c [c:writing] rpython_lltypesystem_rffi.c [c:writing] rpython_module_ll_os.c [c:writing] rpython_lltypesystem_rrange.c [c:writing] rpython_lltypesystem_rlist.c [c:writing] rpython_rlist.c [c:writing] rlib_rgc.c [c:writing] rpython_rrange.c [c:writing] rpython_lltypesystem_rstr.c [c:writing] rpython_rstr.c rather than merely lots of implement([0-9]+).c files. Note that all generated files are still within the same directory, which I believe is a requirement (to be amenable to easy grepping). With this patch, test_genc.py and test_standalone.py fully pass; am about to try a full translation. Notes: I showed a variant of this to arigo at PyCon US last month, in which I attempted to subdivide the FuncNode instances based on heir names. Doing so required introducing a rather ugly and arbitrary naming policy into the translator, which IIRC arigo greatly disliked. This new approach is purely based on the RPython filenames, and is hopefully therefore more acceptable. ---------- effort: ??? files: pypy-make-c-filenames-reflect-rpython-filenames.patch messages: 2378 nosy: dmalcolm, pypy-issue priority: wish release: ??? status: unread title: Patch to make the generated C filenames reflect the RPython source filenames _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pypy-make-c-filenames-reflect-rpython-filenames.patch Type: text/x-patch Size: 3893 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Tue Apr 19 09:59:58 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Tue, 19 Apr 2011 07:59:58 +0000 Subject: [PyPy-issue] [issue664] [PATCH] Extend readline emulation to support colour code and ansi escapes Message-ID: <1303199998.36.0.679052652727.issue664@> Fijal added the comment: Is this patch submitted and this issue can be closed? _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 19 10:02:13 2011 From: pypy-dev-issue at codespeak.net (Antonio Cuni) Date: Tue, 19 Apr 2011 08:02:13 +0000 Subject: [PyPy-issue] [issue664] [PATCH] Extend readline emulation to support colour code and ansi escapes Message-ID: <1303200133.52.0.642592735319.issue664@> Antonio Cuni added the comment: I thought I already closed it, sorry. ---------- status: chatting -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 19 10:04:17 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Tue, 19 Apr 2011 08:04:17 +0000 Subject: [PyPy-issue] [issue637] twisted.conch.test.test_recvline.RecvlineLoopbackTelnet.testLeftArrow fails after 29 iterations Message-ID: <1303200257.61.0.510858110563.issue637@> Fijal added the comment: This is fixed ---------- status: chatting -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 19 10:06:39 2011 From: pypy-dev-issue at codespeak.net (Antonio Cuni) Date: Tue, 19 Apr 2011 08:06:39 +0000 Subject: [PyPy-issue] [issue438] ootype methods starts with a oodowncast to the class type Message-ID: <1303200399.81.0.912137026975.issue438@> Antonio Cuni added the comment: probably it's not an issue, and I'm not going to fix it anyway :-) ---------- nosy: +pypy-issue -ac, arigo, cfbolz, mwh, pedronis, tismer status: unread -> wontfix _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 19 17:59:14 2011 From: pypy-dev-issue at codespeak.net (Dave Malcolm) Date: Tue, 19 Apr 2011 15:59:14 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303228754.06.0.794668375381.issue687@> Dave Malcolm added the comment: As it turned out, the full translation failed (after 2 hours...), with a bug that's easily reproducible by pypy/translator/c/test/test_stackless.py : it seems that not all FunctionGraph instances have a "func" attribute, and thus attempts to call access "filename" or call getfilename fail (likewise for the various other func-based properties). I'm attaching a modified version of the patch which bulletproofs it against such FunctionGraph instances. With this, all of the tests below pypy/translator/c/test pass; I have a full translation (with --opt=jit) running now. I'm not sure yet how common such FunctionGraph instances are. I saw this in a full translation with this object: (Pdb+) p node (Pdb+) p node.obj with this generated code: struct pypy_pypy_interpreter_baseobjspace_W_Root0 *pypy_g_dispatcher(char l_v105, struct pypy_pypy_objspace_std_dictmultiobject_W_DictMultiObjec0 *l_v1810, struct pypy_rpy_string0 *l_key_345) { (I have the full function saved, in case that's helpful) I saw it with pypy/translator/c/test/test_stackless.py with this object: (Pdb) p self For reference, here's the traceback: [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "translate.py", line 299, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/driver.py", line 809, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/tool/taskengine.py", line 116, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/driver.py", line 286, in _do [translation:ERROR] res = func() [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/driver.py", line 530, in task_source_c [translation:ERROR] exe_name=exe_name) [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/c/genc.py", line 270, in generate_source [translation:ERROR] defines = defines) [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/c/genc.py", line 975, in gen_source_standalone [translation:ERROR] sg.gen_readable_parts_of_source(f) [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/c/genc.py", line 824, in gen_readable_parts_of_source [translation:ERROR] split_criteria_big): [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/c/genc.py", line 714, in splitnodesimpl [translation:ERROR] c_filename = self.getbasecfilefornode(node, basecname) [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/c/genc.py", line 701, in getbasecfilefornode [translation:ERROR] if node.obj.graph.filename.endswith('.py'): [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/tool/descriptor.py", line 9, in __get__ [translation:ERROR] return self.getter(obj) [translation:ERROR] File "/home/david/coding/pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/objspace/flow/model.py", line 73, in getfilename [translation:ERROR] return self.func.func_code.co_filename [translation:ERROR] AttributeError: 'FunctionGraph' object has no attribute 'func' ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: pypy-make-c-filenames-reflect-rpython-filenames-v2.patch Type: text/x-patch Size: 4088 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Tue Apr 19 20:17:34 2011 From: pypy-dev-issue at codespeak.net (Dave Malcolm) Date: Tue, 19 Apr 2011 18:17:34 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303237054.24.0.539382930725.issue687@> Dave Malcolm added the comment: Still doing the full build, but it's finished emitting C code. Am attaching list of all .c and .h files (with sizes) for reference. The Makefile has them in an arbitrary order, I guess I can sort them by filename when writing out the nodes. _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: contents-of-dir.txt URL: From pypy-dev-issue at codespeak.net Tue Apr 19 20:28:33 2011 From: pypy-dev-issue at codespeak.net (Dave Malcolm) Date: Tue, 19 Apr 2011 18:28:33 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303237713.12.0.325268063082.issue687@> Dave Malcolm added the comment: It built successfully with pypy-make-c-filenames-reflect-rpython-filenames- v2.patch ; I have a working pypy-c from this. _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 19 23:27:32 2011 From: pypy-dev-issue at codespeak.net (Dave Malcolm) Date: Tue, 19 Apr 2011 21:27:32 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303248452.49.0.859773811394.issue687@> Dave Malcolm added the comment: amaury asked on IRC about what was still ending up in implement*.c I'm attaching the result of running the following: $ grep -e "^\S.*{$" /tmp/usession-default-71/testing_1/implement*.c > functions-still- within-an-implement-dot-c.txt $ gzip functions-still-within-an-implement-dot-c.txt to try to capture all function definitions within the generated C files. _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: functions-still-within-an-implement-dot-c.txt.gz Type: application/x-gzip Size: 110298 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Wed Apr 20 12:23:56 2011 From: pypy-dev-issue at codespeak.net (Antonio Cuni) Date: Wed, 20 Apr 2011 10:23:56 +0000 Subject: [PyPy-issue] [issue685] Tkinter support by pypy Message-ID: <1303295036.32.0.267787856002.issue685@> Antonio Cuni added the comment: Tkinter now works correctly with PyPy, see this blog post for instructions: http://morepypy.blogspot.com/2011/04/using-tkinter-and-idle-with-pypy.html ---------- status: testing -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Wed Apr 20 13:52:20 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Wed, 20 Apr 2011 11:52:20 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303300340.33.0.491677283169.issue687@> Fijal added the comment: Hey. Can you run the benchmark suite and confirm that it does not make stuff slower? _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Wed Apr 20 17:14:59 2011 From: pypy-dev-issue at codespeak.net (Winston Ewert) Date: Wed, 20 Apr 2011 15:14:59 +0000 Subject: [PyPy-issue] [issue688] JIT confusion: inconsistent guards Message-ID: <1303312499.41.0.954136071254.issue688@> New submission from Winston Ewert : The attached trace shows an immutable field being read off an object twice in a trace. In both cases the value of the field is given to guard_value; however, it appears that the value being guarded for the field is different in each case. I suspect that this is resulting in the optimizer giving up. I've simplified the code as much as I can. There are several bits that shouldn't affect the running of the program, but they are necessary to produce this trace. ---------- effort: ??? files: case.py messages: 2389 nosy: pypy-issue, winstonewert priority: bug release: ??? status: unread title: JIT confusion: inconsistent guards _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: case.py Type: text/x-python Size: 1177 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Wed Apr 20 17:15:37 2011 From: pypy-dev-issue at codespeak.net (Winston Ewert) Date: Wed, 20 Apr 2011 15:15:37 +0000 Subject: [PyPy-issue] [issue688] JIT confusion: inconsistent guards Message-ID: <1303312537.01.0.169038565952.issue688@> Winston Ewert added the comment: attaching the trace. ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: logfile Type: application/octet-stream Size: 2122 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Wed Apr 20 20:05:35 2011 From: pypy-dev-issue at codespeak.net (Dave Malcolm) Date: Wed, 20 Apr 2011 18:05:35 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303322735.08.0.714577497286.issue687@> Dave Malcolm added the comment: I ran hg.python.org/benchmarks to compare a build without the patch (control) to one with (experiment) Report on Linux surprise 2.6.33.3-84.fc13.x86_64 #1 SMP Wed May 5 19:55:35 UTC 2010 x86_64 x86_64 Total CPU cores: 4 ### 2to3 ### 9.649533 -> 9.414569: 1.02x faster ### django ### Min: 0.124686 -> 0.128888: 1.03x slower Avg: 0.125681 -> 0.130671: 1.04x slower Significant (t=-7.23) Stddev: 0.00164 -> 0.00460: 2.7979x larger Timeline: http://tinyurl.com/4x7qc3u ### slowspitfire ### Min: 0.918111 -> 0.948506: 1.03x slower Avg: 0.939797 -> 0.996172: 1.06x slower Significant (t=-17.48) Stddev: 0.01803 -> 0.01397: 1.2905x smaller Timeline: http://tinyurl.com/3n22po3 The following not significant results are hidden, use -v to show them: nbody, slowpickle, slowunpickle, spambayes. _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Wed Apr 20 20:09:07 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Wed, 20 Apr 2011 18:09:07 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303322947.25.0.262349147623.issue687@> Fijal added the comment: Actually, our own benchmark suite is much better. Can you run this one? (http://bitbucket.org/pypy/benchmarks), preferably paste the result with -v _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Wed Apr 20 20:56:45 2011 From: pypy-dev-issue at codespeak.net (Dave Malcolm) Date: Wed, 20 Apr 2011 18:56:45 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303325805.33.0.255511789593.issue687@> Dave Malcolm added the comment: The http://bitbucket.org/pypy/benchmarks suite doesn't seem to have a "-v" option (I'm looking at "runner.py") Were you referring to the hg.python.org/benchmarks suite? There doesn't appear to be any documentation on running the latter benchmark suite. I tried running $ ./runner.py \ --baseline=../../pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/goal/pypy-c-without-patch \ --pypy-c=../../pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/goal/pypy-c-with-patch-v2 and it appeared to be comparing the control and experiment, but it eventually died with this ImportError. Is there some installation method needed by the benchmark suite, or should I be setting PYTHONPATH? Traceback (most recent call last): File "./runner.py", line 113, in main(sys.argv[1:]) File "./runner.py", line 110, in main baseline=options.baseline, full_store=options.full_store) File "./runner.py", line 27, in run_and_store results = perf.main(opts, funcs) File "/home/david/coding/pypy-dmalcolm-bitbucket/benchmarks/unladen_swallow/perf.py", line 1608, in main options))) File "/home/david/coding/pypy-dmalcolm-bitbucket/benchmarks/benchmarks.py", line 35, in BM return SimpleBenchmark(Measure, *args, **kwds) File "/home/david/coding/pypy-dmalcolm-bitbucket/benchmarks/unladen_swallow/perf.py", line 455, in SimpleBenchmark *args, **kwargs) File "/home/david/coding/pypy-dmalcolm-bitbucket/benchmarks/benchmarks.py", line 31, in Measure return MeasureGeneric(python, options, bm_path, parser=parser, **opts) File "/home/david/coding/pypy-dmalcolm-bitbucket/benchmarks/unladen_swallow/perf.py", line 804, in MeasureGeneric inherit_env=options.inherit_env) File "/home/david/coding/pypy-dmalcolm-bitbucket/benchmarks/unladen_swallow/perf.py", line 760, in CallAndCaptureOutput raise RuntimeError("Benchmark died: " + err) RuntimeError: Benchmark died: Traceback (most recent call last): File "app_main.py", line 53, in run_toplevel File "/home/david/coding/pypy-dmalcolm-bitbucket/benchmarks/own/twisted/iteration.py", line 4, in from benchlib import Client, driver File "/home/david/coding/pypy-dmalcolm-bitbucket/benchmarks/own/twisted/benchlib.py", line 3, in from twisted.internet.defer import Deferred ImportError: No module named twisted _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Thu Apr 21 09:20:13 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Thu, 21 Apr 2011 07:20:13 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303370413.29.0.283419657433.issue687@> Fijal added the comment: Can you just checkout twisted somewhere and set PYTHONPATH? It seems twisted evaporated from the checkout during the svn->hg transition, fixing _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Thu Apr 21 10:42:14 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Thu, 21 Apr 2011 08:42:14 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303375334.04.0.471529374359.issue687@> Fijal added the comment: should be fixed by now, sorry about that _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Thu Apr 21 17:51:35 2011 From: pypy-dev-issue at codespeak.net (Chris Smowton) Date: Thu, 21 Apr 2011 15:51:35 +0000 Subject: [PyPy-issue] [issue689] RPython exception unpickling a coroutine whose creator's stack has shrunk since it was switch()'d Message-ID: <1303401095.54.0.595755932822.issue689@> New submission from Chris Smowton : Here's an interesting bug that occurs when unpickling coroutines whose creator's stack has grown shorter since that creator was switched-in. That's a fairly tangled sentence -- here's a situation summary: Coro MAIN creates coro A, then switches to A. A enters f, then g (A's stack is [f,g]) A switches to MAIN MAIN switches back to A A returns from g (his stack is now [f]) A creates a coro B, bound to anything, and PICKLES B We try to UNPICKLE B: Result: RPython exception in reconstruct_frame_chain. I don't have a patch to fix this, but I have a solid idea what's wrong from instrumenting lib-python/modified-2.5.2/pickle.py. I stuck some prints into __reduce_ex__ and __setstate__ calls, and it looks like the frame for g is being pickled when we create B, even though g is *not* on the stack at the time B is created or pickled. Looking at the series of __reduce_ex__ calls, it looks like we're pickling A's coroutine *as it was when A was switched in* rather than as it was at the time we created B. Here's an example run, in which I carry out pretty much what I just described, with logging prints in pickle.py active. The crash looks exactly the same with or without the prints. Python 2.5.2 (, Mar 10 2011, 13:06:15) [PyPy 1.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``2009 is the year of reflection on the desktop'' >>>> import pickle >>>> import stackless >>>> h = None >>>> main_coro = stackless.coroutine.getcurrent() >>>> >>>> def f(): .... g() .... global h .... new_coro = stackless.coroutine() .... new_coro.bind(lambda x: x, 5) .... h = pickle.dumps(new_coro) .... >>>> def g(): .... main_coro.switch() .... >>>> user_coro = stackless.coroutine() >>>> user_coro.bind(f) >>>> >>>> user_coro.switch() >>>> user_coro.switch() !!!!! REDUCE_EX <_stackless.coroutine object at 0x00007f8c20ff8770> TO (, (), (0, (), ( at 0x00007f8c20fdbe60>, (5,), {}), <_stackless.coroutine object at 0x00007f8c20ff86e0>)) !!!!! REDUCE_EX , file '', line 5> TO (, (1, 1, 1, 595, '|\x00\x00S', (None,), (), ('x',), '', '', 5, '', (), (), 168686271)) !!!!! REDUCE_EX TO (, ('__main__', None, None, ('',))) !!!!! REDUCE_EX <_stackless.coroutine object at 0x00007f8c20ff86e0> TO (, (), (0, (, ), None, <_stackless.coroutine object at 0x0000000002319000>)) !!!!! REDUCE_EX TO (, (), (None, , ', line 1>, ((1,), , None, <_stackless.coroutine object at 0x00007f8c20ff8770>), (), None, None, {'main_coro': <_stackless.coroutine object at 0x0000000002319000>, 'stackless': , 'g': , 'h': None, '__builtins__': , '__name__': '__main__', 'user_coro': <_stackless.coroutine object at 0x00007f8c20ff86e0>, 'f': , 'pickle': , '__doc__': None}, 47, False, 6, ((), <_stackless.coroutine object at 0x00007f8c20ff8770>), None, None, 0, -1, -1, None)) !!!!! REDUCE_EX TO (, ('__builtin__', None, None, ('',))) !!!!! REDUCE_EX ', line 1> TO (, (0, 1, 4, 2627, 't\x00\x00\x83\x00\x00\x01t\x01\x00\x91\x02\x00\x92\x00\x00}\x00\x00|\x00\x00\x91\x03\x00d\x01\x00\x84\x00\x00d\x02\x00\x92\x02\x00\x01t\x04\x00\x91\x05\x00|\x00\x00\x92\x01\x00a\x06\x00d\x00\x00S', (None, , file '', line 5>, 5), ('g', 'stackless', 'coroutine', 'bind', 'pickle', 'dumps', 'h'), ('new_coro',), '', 'f', 1, '\x00\x01\x07\x02\x0c\x01\x13\x01', (), (), 168686271)) !!!!! REDUCE_EX TO (, (), (, , ', line 1>, ((),), (), None, None, {'main_coro': <_stackless.coroutine object at 0x0000000002319000>, 'stackless': , 'g': , 'h': None, '__builtins__': , '__name__': '__main__', 'user_coro': <_stackless.coroutine object at 0x00007f8c20ff86e0>, 'f': , 'pickle': , '__doc__': None}, 13, True, 2, ((),), None, None, 0, -1, -1, None)) !!!!! REDUCE_EX ', line 1> TO (, (0, 0, 2, 2627, 't\x00\x00\x91\x01\x00\x92\x00\x00\x01d\x00\x00S', (None,), ('main_coro', 'switch'), (), '', 'g', 1, '\x00\x01', (), (), 168686271)) !!!!! REDUCE_EX <_stackless.coroutine object at 0x0000000002319000> TO (, ()) >>>> print h c_stackless coroutine p0 (tRp1 (I0 (t(c_pickle_support func_new p2 (tRp3 (S'' p4 Nc_pickle_support code_new p5 (I1 I1 I1 I595 S'|\x00\x00S' p6 (Ntp7 (t(S'x' p8 tp9 S'' p10 S'' p11 I5 S'' p12 (t(tI168686271 tp13 Rp14 c__builtin__ getattr p15 (c__builtin__ __import__ p16 (S'__main__' p17 NN(S'' p18 tp19 tp20 Rp21 S'__dict__' p22 tp23 RN(t(dp24 g17 tp25 b(I5 tp26 (dp27 tp28 g0 (tRp29 (I0 (c_pickle_support frame_new p30 (tRp31 (Ng16 (S'__builtin__' p32 NN(g18 tp33 tp34 Rp35 g5 (I0 I1 I4 I2627 S't\x00\x00\x83\x00\x00\x01t\x01\x00\x91\x02\x00\x92\x00\x00}\x00\x00|\x00\x00\x91\x03\x00d\x01\x00\x84\x00\x00d\x02\x00\x92\x02\x00\x01t\x04\x00\x91\x05\x00|\x00\x00\x92\x01\x00a\x06\x00d\x00\x00S' p36 (Ng14 I5 tp37 (S'g' p38 S'stackless' p39 S'coroutine' p40 S'bind' p41 S'pickle' p42 S'dumps' p43 S'h' p44 tp45 (S'new_coro' p46 tp47 S'' p48 S'f' p49 I1 S'\x00\x01\x07\x02\x0c\x01\x13\x01' p50 (t(tI168686271 tp51 Rp52 ((I1 tp53 cpickle dumps p54 Ng1 tp55 (tNNg15 (g21 g22 tp56 RI47 I00 I6 ((tg1 tp57 NNI0 I-1 I-1 Ntp58 bg30 (tRp59 (g31 g35 g5 (I0 I0 I2 I2627 S't\x00\x00\x91\x01\x00\x92\x00\x00\x01d\x00\x00S' p60 (Ntp61 (S'main_coro' p62 S'switch' p63 tp64 (tS'' p65 S'g' p66 I1 S'\x00\x01' p67 (t(tI168686271 tp68 Rp69 ((ttp70 (tNNg15 (g21 g22 tp71 RI13 I01 I2 ((ttp72 NNI0 I-1 I-1 Ntp73 btp74 Nc_stackless _return_main p75 (tRp76 tp77 btp78 b. >>>> pickle.loads(h) @@@SETSTATE ('', None, , file '', line 5>, {'main_coro': <_stackless.coroutine object at 0x0000000002319000>, 'stackless': , 'g': , 'h': "c_stackless\ncoroutine\np0\n(tRp1\n(I0\n(t(c_pickle_support\nfunc_new\np2\n(tRp3\n(S''\np4\nNc_pickle_support\ncode_new\np5\n(I1\nI1\nI1\nI595\nS'|\\x00\\x00S'\np6\n(Ntp7\n(t(S'x'\np8\ntp9\nS''\np10\nS''\np11\nI5\nS''\np12\n(t(tI168686271\ntp13\nRp14\nc__builtin__\ngetattr\np15\n(c__builtin__\n__import__\np16\n(S'__main__'\np17\nNN(S''\np18\ntp19\ntp20\nRp21\nS'__dict__'\np22\ntp23\nRN(t(dp24\ng17\ntp25\nb(I5\ntp26\n(dp27\ntp28\ng0\n(tRp29\n(I0\n(c_pickle_support\nframe_new\np30\n(tRp31\n(Ng16\n(S'__builtin__'\np32\nNN(g18\ntp33\ntp34\nRp35\ng5\n(I0\nI1\nI4\nI2627\nS't\\x00\\x00\\x83\\x00\\x00\\x01t\\x01\\x00\\x91\\x02\\x00\\x92\\x00\\x00}\\x00\\x00|\\x00\\x00\\x91\\x03\\x00d\\x01\\x00\\x84\\x00\\x00d\\x02\\x00\\x92\\x02\\x00\\x01t\\x04\\x00\\x91\\x05\\x00|\\x00\\x00\\x92\\x01\\x00a\\x06\\x00d\\x00\\x00S'\np36\n(Ng14\nI5\ntp37\n(S'g'\np38\nS'stackless'\np39\nS'coroutine'\np40\nS'bind'\np41\nS'pickle'\np42\nS'dumps'\np43\nS'h'\np44\ntp45\n(S'new_coro'\np46\ntp47\nS''\np48\nS'f'\np49\nI1\nS'\\x00\\x01\\x07\\x02\\x0c\\x01\\x13\\x01'\np50\n(t(tI168686271\ntp51\nRp52\n((I1\ntp53\ncpickle\ndumps\np54\nNg1\ntp55\n(tNNg15\n(g21\ng22\ntp56\nRI47\nI00\nI6\n((tg1\ntp57\nNNI0\nI-1\nI-1\nNtp58\nbg30\n(tRp59\n(g31\ng35\ng5\n(I0\nI0\nI2\nI2627\nS't\\x00\\x00\\x91\\x01\\x00\\x92\\x00\\x00\\x01d\\x00\\x00S'\np60\n(Ntp61\n(S'main_coro'\np62\nS'switch'\np63\ntp64\n(tS''\np65\nS'g'\np66\nI1\nS'\\x00\\x01'\np67\n(t(tI168686271\ntp68\nRp69\n((ttp70\n(tNNg15\n(g21\ng22\ntp71\nRI13\nI01\nI2\n((ttp72\nNNI0\nI-1\nI-1\nNtp73\nbtp74\nNc_stackless\n_return_main\np75\n(tRp76\ntp77\nbtp78\nb.", '__builtins__': , '__name__': '__main__', 'user_coro': <_stackless.coroutine object at 0x00007f8c20ff86e0>, 'f': , 'pickle': , '__doc__': None}, None, (), {}, '__main__') @@@SETSTATE (None, , ', line 1>, ((1,), , None, <_stackless.coroutine object at 0x00007f8c20ff8800>), (), None, None, {'main_coro': <_stackless.coroutine object at 0x0000000002319000>, 'stackless': , 'g': , 'h': "c_stackless\ncoroutine\np0\n(tRp1\n(I0\n(t(c_pickle_support\nfunc_new\np2\n(tRp3\n(S''\np4\nNc_pickle_support\ncode_new\np5\n(I1\nI1\nI1\nI595\nS'|\\x00\\x00S'\np6\n(Ntp7\n(t(S'x'\np8\ntp9\nS''\np10\nS''\np11\nI5\nS''\np12\n(t(tI168686271\ntp13\nRp14\nc__builtin__\ngetattr\np15\n(c__builtin__\n__import__\np16\n(S'__main__'\np17\nNN(S''\np18\ntp19\ntp20\nRp21\nS'__dict__'\np22\ntp23\nRN(t(dp24\ng17\ntp25\nb(I5\ntp26\n(dp27\ntp28\ng0\n(tRp29\n(I0\n(c_pickle_support\nframe_new\np30\n(tRp31\n(Ng16\n(S'__builtin__'\np32\nNN(g18\ntp33\ntp34\nRp35\ng5\n(I0\nI1\nI4\nI2627\nS't\\x00\\x00\\x83\\x00\\x00\\x01t\\x01\\x00\\x91\\x02\\x00\\x92\\x00\\x00}\\x00\\x00|\\x00\\x00\\x91\\x03\\x00d\\x01\\x00\\x84\\x00\\x00d\\x02\\x00\\x92\\x02\\x00\\x01t\\x04\\x00\\x91\\x05\\x00|\\x00\\x00\\x92\\x01\\x00a\\x06\\x00d\\x00\\x00S'\np36\n(Ng14\nI5\ntp37\n(S'g'\np38\nS'stackless'\np39\nS'coroutine'\np40\nS'bind'\np41\nS'pickle'\np42\nS'dumps'\np43\nS'h'\np44\ntp45\n(S'new_coro'\np46\ntp47\nS''\np48\nS'f'\np49\nI1\nS'\\x00\\x01\\x07\\x02\\x0c\\x01\\x13\\x01'\np50\n(t(tI168686271\ntp51\nRp52\n((I1\ntp53\ncpickle\ndumps\np54\nNg1\ntp55\n(tNNg15\n(g21\ng22\ntp56\nRI47\nI00\nI6\n((tg1\ntp57\nNNI0\nI-1\nI-1\nNtp58\nbg30\n(tRp59\n(g31\ng35\ng5\n(I0\nI0\nI2\nI2627\nS't\\x00\\x00\\x91\\x01\\x00\\x92\\x00\\x00\\x01d\\x00\\x00S'\np60\n(Ntp61\n(S'main_coro'\np62\nS'switch'\np63\ntp64\n(tS''\np65\nS'g'\np66\nI1\nS'\\x00\\x01'\np67\n(t(tI168686271\ntp68\nRp69\n((ttp70\n(tNNg15\n(g21\ng22\ntp71\nRI13\nI01\nI2\n((ttp72\nNNI0\nI-1\nI-1\nNtp73\nbtp74\nNc_stackless\n_return_main\np75\n(tRp76\ntp77\nbtp78\nb.", '__builtins__': , '__name__': '__main__', 'user_coro': <_stackless.coroutine object at 0x00007f8c20ff86e0>, 'f': , 'pickle': , '__doc__': None}, 47, False, 6, ((), <_stackless.coroutine object at 0x00007f8c20ff8800>), None, None, 0, -1, -1, None) @@@SETSTATE (, , ', line 1>, ((),), (), None, None, {'main_coro': <_stackless.coroutine object at 0x0000000002319000>, 'stackless': , 'g': , 'h': "c_stackless\ncoroutine\np0\n(tRp1\n(I0\n(t(c_pickle_support\nfunc_new\np2\n(tRp3\n(S''\np4\nNc_pickle_support\ncode_new\np5\n(I1\nI1\nI1\nI595\nS'|\\x00\\x00S'\np6\n(Ntp7\n(t(S'x'\np8\ntp9\nS''\np10\nS''\np11\nI5\nS''\np12\n(t(tI168686271\ntp13\nRp14\nc__builtin__\ngetattr\np15\n(c__builtin__\n__import__\np16\n(S'__main__'\np17\nNN(S''\np18\ntp19\ntp20\nRp21\nS'__dict__'\np22\ntp23\nRN(t(dp24\ng17\ntp25\nb(I5\ntp26\n(dp27\ntp28\ng0\n(tRp29\n(I0\n(c_pickle_support\nframe_new\np30\n(tRp31\n(Ng16\n(S'__builtin__'\np32\nNN(g18\ntp33\ntp34\nRp35\ng5\n(I0\nI1\nI4\nI2627\nS't\\x00\\x00\\x83\\x00\\x00\\x01t\\x01\\x00\\x91\\x02\\x00\\x92\\x00\\x00}\\x00\\x00|\\x00\\x00\\x91\\x03\\x00d\\x01\\x00\\x84\\x00\\x00d\\x02\\x00\\x92\\x02\\x00\\x01t\\x04\\x00\\x91\\x05\\x00|\\x00\\x00\\x92\\x01\\x00a\\x06\\x00d\\x00\\x00S'\np36\n(Ng14\nI5\ntp37\n(S'g'\np38\nS'stackless'\np39\nS'coroutine'\np40\nS'bind'\np41\nS'pickle'\np42\nS'dumps'\np43\nS'h'\np44\ntp45\n(S'new_coro'\np46\ntp47\nS''\np48\nS'f'\np49\nI1\nS'\\x00\\x01\\x07\\x02\\x0c\\x01\\x13\\x01'\np50\n(t(tI168686271\ntp51\nRp52\n((I1\ntp53\ncpickle\ndumps\np54\nNg1\ntp55\n(tNNg15\n(g21\ng22\ntp56\nRI47\nI00\nI6\n((tg1\ntp57\nNNI0\nI-1\nI-1\nNtp58\nbg30\n(tRp59\n(g31\ng35\ng5\n(I0\nI0\nI2\nI2627\nS't\\x00\\x00\\x91\\x01\\x00\\x92\\x00\\x00\\x01d\\x00\\x00S'\np60\n(Ntp61\n(S'main_coro'\np62\nS'switch'\np63\ntp64\n(tS''\np65\nS'g'\np66\nI1\nS'\\x00\\x01'\np67\n(t(tI168686271\ntp68\nRp69\n((ttp70\n(tNNg15\n(g21\ng22\ntp71\nRI13\nI01\nI2\n((ttp72\nNNI0\nI-1\nI-1\nNtp73\nbtp74\nNc_stackless\n_return_main\np75\n(tRp76\ntp77\nbtp78\nb.", '__builtins__': , '__name__': '__main__', 'user_coro': <_stackless.coroutine object at 0x00007f8c20ff86e0>, 'f': , 'pickle': , '__doc__': None}, 13, True, 2, ((),), None, None, 0, -1, -1, None) @@@SETSTATE (0, (, ), None, <_stackless.coroutine object at 0x0000000002319000>) RPython traceback: File "implement_26.c", line 197241, in AppCoroutine_descr__setstate__ File "implement_28.c", line 20393, in AppCoroutine_reconstruct_framechain Fatal RPython error: AssertionError Aborted ---------- effort: ??? messages: 2396 nosy: pypy-issue, smowton priority: bug release: 1.4 status: unread title: RPython exception unpickling a coroutine whose creator's stack has shrunk since it was switch()'d _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 22 17:45:03 2011 From: pypy-dev-issue at codespeak.net (Winston Ewert) Date: Fri, 22 Apr 2011 15:45:03 +0000 Subject: [PyPy-issue] [issue688] JIT not optimizing pure field access Message-ID: <1303487103.31.0.318611920741.issue688@> Winston Ewert added the comment: I've been doing a little investigation on this, and I've determined that I was wrong about the trace. The output seems to suggest that two different pointers are produced for the same field during the trace, but this seems to be an artifact of the method used to print the log. The .value attribute on the pointers agrees. ---------- status: chatting -> unread title: JIT confusion: inconsistent guards -> JIT not optimizing pure field access _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sun Apr 24 20:28:11 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Sun, 24 Apr 2011 18:28:11 +0000 Subject: [PyPy-issue] [issue690] pypy fails to compile under FreeBSD (9) Message-ID: <1303669691.11.0.686211231837.issue690@> New submission from David Naylor : Using the source from pypy-1.4.1, the source fails to compile when using `python translate.py -Ojit`. No other combinations were tried. The system details: # uname -a FreeBSD dragon.dg 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Wed Apr 13 19:16:40 SAST 2011 root at dragon.dg:/tmp/home/freebsd9/src/sys/DRAGON amd64 # gcc -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] [Note: the gcc in FreeBSD is a modified version of 4.2.1 with some GPLv2 patches back ported] The translating works until it gets to compiling the source code (compile_c), with the error message: # gmake /usr/local/bin/python /home/DragonSA/projects/pypy-1.4.1- src/pypy/translator/c/gcc/trackgcroot.py -mmain -t implement_25.s > implement_25.gctmp Traceback (most recent call last): File "/home/DragonSA/projects/pypy-1.4.1- src/pypy/translator/c/gcc/trackgcroot.py", line 1939, in tracker.process(f, g, entrypoint=entrypoint, filename=fn) File "/home/DragonSA/projects/pypy-1.4.1- src/pypy/translator/c/gcc/trackgcroot.py", line 1830, in process tracker = parser.process_function(lines, entrypoint, filename) File "/home/DragonSA/projects/pypy-1.4.1- src/pypy/translator/c/gcc/trackgcroot.py", line 1348, in process_function table = tracker.computegcmaptable(self.verbose) File "/home/DragonSA/projects/pypy-1.4.1- src/pypy/translator/c/gcc/trackgcroot.py", line 60, in computegcmaptable return self.gettable() File "/home/DragonSA/projects/pypy-1.4.1- src/pypy/translator/c/gcc/trackgcroot.py", line 94, in gettable localvar) AssertionError: pypy_g_Scope_finalize: %rdx gmake: *** [implement_25.gcmap] Error 1 ---------- effort: ??? messages: 2398 nosy: DragonSA, pypy-issue priority: critical release: 1.4 status: unread title: pypy fails to compile under FreeBSD (9) _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 01:21:50 2011 From: pypy-dev-issue at codespeak.net (Dave Malcolm) Date: Sun, 24 Apr 2011 23:21:50 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303687310.34.0.416613916496.issue687@> Dave Malcolm added the comment: $ ./runner.py \ > --baseline=../../pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/goal/pypy-c-without-patch \ > --pypy-c=../../pypy-dmalcolm-bitbucket/pypy-c-filenames/pypy/translator/goal/pypy-c-with-patch-v2 ... snip ... Report on Linux surprise 2.6.33.3-84.fc13.x86_64 #1 SMP Wed May 5 19:55:35 UTC 2010 x86_64 x86_64 Total CPU cores: 4 ### ai ### Min: 0.252772 -> 0.242124: 1.0440x faster Avg: 0.266032 -> 0.254590: 1.0449x faster Significant (t=3.005309, a=0.95) Stddev: 0.01742 -> 0.02053: 1.1787x larger ### bm_mako ### Min: 0.094809 -> 0.096343: 1.0162x slower Avg: 0.104784 -> 0.105018: 1.0022x slower Not significant Stddev: 0.02093 -> 0.01476: 1.4179x smaller ### chaos ### Min: 0.026513 -> 0.026468: 1.0017x faster Avg: 0.036599 -> 0.036914: 1.0086x slower Not significant Stddev: 0.05291 -> 0.05429: 1.0261x larger ### crypto_pyaes ### Min: 0.161282 -> 0.161050: 1.0014x faster Avg: 0.177425 -> 0.176228: 1.0068x faster Not significant Stddev: 0.07523 -> 0.06401: 1.1753x smaller ### django ### Min: 0.127199 -> 0.126591: 1.0048x faster Avg: 0.128528 -> 0.127908: 1.0048x faster Not significant Stddev: 0.00145 -> 0.00212: 1.4614x larger ### fannkuch ### Min: 0.385839 -> 0.383676: 1.0056x faster Avg: 0.390883 -> 0.387971: 1.0075x faster Not significant Stddev: 0.01344 -> 0.01180: 1.1389x smaller ### float ### Min: 0.064076 -> 0.065365: 1.0201x slower Avg: 0.072866 -> 0.074947: 1.0286x slower Not significant Stddev: 0.01033 -> 0.01292: 1.2509x larger ### go ### Min: 0.143750 -> 0.144220: 1.0033x slower Avg: 0.177171 -> 0.175397: 1.0101x faster Not significant Stddev: 0.03076 -> 0.03149: 1.0238x larger ### html5lib ### Min: 5.355597 -> 5.325249: 1.0057x faster Avg: 6.161880 -> 6.137079: 1.0040x faster Not significant Stddev: 1.42925 -> 1.43027: 1.0007x larger ### meteor-contest ### Min: 0.241639 -> 0.241342: 1.0012x faster Avg: 0.246134 -> 0.246784: 1.0026x slower Not significant Stddev: 0.00967 -> 0.00956: 1.0118x smaller ### nbody_modified ### Min: 0.072565 -> 0.074115: 1.0214x slower Avg: 0.074352 -> 0.076266: 1.0257x slower Significant (t=-2.083538, a=0.95) Stddev: 0.00486 -> 0.00431: 1.1258x smaller ### pyflate-fast ### Min: 1.012426 -> 1.028694: 1.0161x slower Avg: 1.027880 -> 1.043845: 1.0155x slower Significant (t=-7.215902, a=0.95) Stddev: 0.01084 -> 0.01128: 1.0404x larger ### raytrace-simple ### Min: 0.113922 -> 0.117465: 1.0311x slower Avg: 0.125349 -> 0.126403: 1.0084x slower Not significant Stddev: 0.03190 -> 0.01329: 2.4000x smaller ### richards ### Min: 0.015552 -> 0.015647: 1.0061x slower Avg: 0.017806 -> 0.017842: 1.0020x slower Not significant Stddev: 0.00384 -> 0.00308: 1.2463x smaller ### rietveld ### Min: 0.207570 -> 0.210311: 1.0132x slower Avg: 0.395354 -> 0.397723: 1.0060x slower Not significant Stddev: 0.24071 -> 0.24027: 1.0018x smaller ### slowspitfire ### Min: 0.919637 -> 0.967751: 1.0523x slower Avg: 0.968271 -> 1.010964: 1.0441x slower Significant (t=-15.209236, a=0.95) Stddev: 0.01306 -> 0.01495: 1.1450x larger ### spambayes ### Min: 0.114921 -> 0.113683: 1.0109x faster Avg: 0.167824 -> 0.167439: 1.0023x faster Not significant Stddev: 0.05021 -> 0.05061: 1.0080x larger ### spectral-norm ### Min: 0.029770 -> 0.030391: 1.0209x slower Avg: 0.031601 -> 0.032258: 1.0208x slower Not significant Stddev: 0.00764 -> 0.00744: 1.0272x smaller ### spitfire ### Min: 8.010000 -> 8.200000: 1.0237x slower Avg: 8.106000 -> 8.288600: 1.0225x slower Significant (t=-12.196010, a=0.95) Stddev: 0.07505 -> 0.07467: 1.0051x smaller ### spitfire_cstringio ### Min: 4.240000 -> 4.280000: 1.0094x slower Avg: 4.319600 -> 4.366600: 1.0109x slower Significant (t=-3.994920, a=0.95) Stddev: 0.05264 -> 0.06442: 1.2236x larger ### telco ### Min: 0.154976 -> 0.153976: 1.0065x faster Avg: 0.168054 -> 0.166555: 1.0090x faster Not significant Stddev: 0.02112 -> 0.02221: 1.0513x larger ### twisted_iteration ### Min: 0.024704 -> 0.024834: 1.0052x slower Avg: 0.024958 -> 0.025119: 1.0064x slower Significant (t=-3.561483, a=0.95) Stddev: 0.00020 -> 0.00025: 1.2080x larger ### twisted_names ### Min: 0.004697 -> 0.004744: 1.0100x slower Avg: 0.004829 -> 0.004859: 1.0061x slower Not significant Stddev: 0.00009 -> 0.00009: 1.0784x larger ### twisted_pb ### Min: 0.031447 -> 0.032051: 1.0192x slower Avg: 0.034114 -> 0.034176: 1.0018x slower Not significant Stddev: 0.00139 -> 0.00114: 1.2152x smaller ### twisted_tcp ### Min: 0.890869 -> 0.900901: 1.0113x slower Avg: 0.901931 -> 0.932653: 1.0341x slower Significant (t=-14.913966, a=0.95) Stddev: 0.00779 -> 0.01231: 1.5799x larger ### waf ### Min: 6.832415 -> 6.748354: 1.0125x faster Avg: 7.349399 -> 8.536454: 1.1615x slower Not significant Stddev: 0.41150 -> 2.43263: 5.9116x larger _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 10:24:31 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Mon, 25 Apr 2011 08:24:31 +0000 Subject: [PyPy-issue] [issue690] pypy fails to compile under FreeBSD (9) Message-ID: <1303719871.25.0.750751215704.issue690@> David Naylor added the comment: Using the latest source from mercurial I get (using the system compiler): # gmake /usr/local/bin/python /home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py -mmain -t implement_20.s > implement_20.gctmp Traceback (most recent call last): File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1950, in tracker.process(f, g, entrypoint=entrypoint, filename=fn) File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1841, in process tracker = parser.process_function(lines, entrypoint, filename) File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1350, in process_function table = tracker.computegcmaptable(self.verbose) File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 60, in computegcmaptable return self.gettable() File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 94, in gettable localvar) AssertionError: pypy_g_dispatcher_151: %rsi gmake: *** [implement_20.gcmap] Error 1 ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 14:36:57 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Mon, 25 Apr 2011 12:36:57 +0000 Subject: [PyPy-issue] [issue488] -m profile fails Message-ID: <1303735017.47.0.281651780645.issue488@> Carl Friedrich Bolz added the comment: the jit-lsprof branch was merged, closing this. ---------- status: chatting -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 14:37:41 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Mon, 25 Apr 2011 12:37:41 +0000 Subject: [PyPy-issue] [issue488] -m profile fails Message-ID: <1303735061.96.0.208185203446.issue488@> Carl Friedrich Bolz added the comment: the jit-lsprof branch was merged, closing this. ---------- status: resolved -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 14:40:55 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Mon, 25 Apr 2011 12:40:55 +0000 Subject: [PyPy-issue] [issue623] Add footer in docs pages Message-ID: <1303735255.97.0.424992931048.issue623@> Carl Friedrich Bolz added the comment: fixed with the switch to sphinx ---------- status: chatting -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 14:42:15 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Mon, 25 Apr 2011 12:42:15 +0000 Subject: [PyPy-issue] [issue546] classes in translator.platform should use tuples in the class attributes Message-ID: <1303735335.93.0.651250172766.issue546@> Carl Friedrich Bolz added the comment: closing, since nobody complained ---------- status: testing -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 15:19:30 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Mon, 25 Apr 2011 13:19:30 +0000 Subject: [PyPy-issue] [issue691] pypy-head does not compile under Windows Message-ID: <1303737570.22.0.620331113708.issue691@> New submission from David Naylor : When compiling under Windows with MingW it fails with: (Hand copied) Error: Traceback (most recent call last): File "translate.py", line 291, in main: assert not os.path.samefile(exe_name, sys.executable), ( AttributeError: 'module' object has no attribute 'samefile' os.path.samefile does not appear to exist on Windows versions of python. ---------- effort: ??? messages: 2405 nosy: DragonSA, pypy-issue priority: critical release: ??? status: unread title: pypy-head does not compile under Windows _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 16:37:44 2011 From: pypy-dev-issue at codespeak.net (Hakan Ardo) Date: Mon, 25 Apr 2011 14:37:44 +0000 Subject: [PyPy-issue] [issue688] JIT not optimizing pure field access Message-ID: <1303742264.27.0.216084988828.issue688@> Hakan Ardo added the comment: I've fixed this in the post-release-1.5 branch. It now removes all the getitem_gc_pure's from the loop and only keeps 2 in the preamble. ---------- status: unread -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 19:40:32 2011 From: pypy-dev-issue at codespeak.net (Vetoshkin Nikita) Date: Mon, 25 Apr 2011 17:40:32 +0000 Subject: [PyPy-issue] [issue692] zope.i18nmessageid C extension failes Message-ID: <1303753232.55.0.739751311395.issue692@> New submission from Vetoshkin Nikita : (.pypyenv)nekto at darkstar:~/workspace/pyr$ easy_install zope.i18nmessageid ... (.pypyenv)nekto at darkstar:~/workspace/pyr$ pypy Python 2.7.0 (1615dfd7d8f1, Apr 20 2011, 02:00:42) [PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``Python 2.x est presque mort, vive Python!'' >>>> from zope.i18nmessageid import ZopeMessageFactory as _z_ >>>> foo = _z_('foo') RPython traceback: File "implement.c", line 27183, in PyTuple_New File "implement_3.c", line 10020, in make_ref File "implement_4.c", line 65240, in create_ref Segmentation fault This line: s = PyUnicode_Type.tp_new(type, args, NULL); from http://goo.gl/SX5nh is being called over and over. ---------- effort: ??? messages: 2407 nosy: nekto0n, pypy-issue priority: bug release: ??? status: unread title: zope.i18nmessageid C extension failes _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 22:14:48 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Mon, 25 Apr 2011 20:14:48 +0000 Subject: [PyPy-issue] [issue692] zope.i18nmessageid C extension failes Message-ID: <1303762488.41.0.956497295948.issue692@> Amaury Forgeot d Arc added the comment: The issue is that cpyext generates the same tp_new for all builtin types... which simply calls type.__new__(type, args). The correct call would be unicode.__new__(type, args). The solution has already been written for tp_setattro, and should be applied to all slots. See the function build_slot_tp_function() in pypy/module/cpyext/slotdefs.py. Careful, this can greatly increase the size of code and data of the pypy executable. ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 22:39:38 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Mon, 25 Apr 2011 20:39:38 +0000 Subject: [PyPy-issue] [issue691] pypy-head does not compile under Windows Message-ID: <1303763978.21.0.361256956996.issue691@> Amaury Forgeot d Arc added the comment: Fixed with 30610b96e715. Thanks for the report! ---------- status: unread -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 22:44:54 2011 From: pypy-dev-issue at codespeak.net (Chris Smowton) Date: Mon, 25 Apr 2011 20:44:54 +0000 Subject: [PyPy-issue] [issue667] Final link failure due to libtinfo dependency Message-ID: <1303764294.8.0.57865491531.issue667@> Chris Smowton added the comment: Oops, just realised I'd forgotton to reply to this: yes it works fine :) _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 22:45:34 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Mon, 25 Apr 2011 20:45:34 +0000 Subject: [PyPy-issue] [issue690] pypy fails to compile under FreeBSD (9) Message-ID: <1303764334.21.0.615279468837.issue690@> Amaury Forgeot d Arc added the comment: Could you attach a (compressed) copy of implement_20.s? _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 22:50:52 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Mon, 25 Apr 2011 20:50:52 +0000 Subject: [PyPy-issue] [issue691] pypy-head does not compile under Windows Message-ID: <1303764652.64.0.616940053021.issue691@> David Naylor added the comment: Thanks for the quick response, however I am still running into some problems: (I worked around the problem originally mentioned by removing the assert) gcc -O3 -DPy_BUILD_CORE -frandom-seed=implement_3.c -o implement_3.s -S implemen t_3.c -IC:\\cygwin\\home\\${USER}\\pypy\\pypy\\translator\\c - IC:\\cygwin\\home\\ ${USER}\\pypy\\pypy\\module\\cpyext\\include -I.. - IC:\\cygwin\\home\\${USER}\\lib ffi-3.0.8.tar.gz\\include implement_3.c: In function 'pypy_g_setup_root_walker': implement_3.c:3079:2: warning: assignment makes pointer from integer without a c ast implement_3.c: In function 'pypy_g_Py_FindMethod': implement_3.c:64787:11: warning: assignment discards qualifiers from pointer tar get type implement_3.c:64793:12: warning: assignment discards qualifiers from pointer tar get type implement_3.c:64813:11: warning: assignment discards qualifiers from pointer tar get type implement_3.c:65036:11: warning: assignment discards qualifiers from pointer tar get type C:/Python27/python.exe C:\\cygwin\\home\\${USER}\\pypy\\pypy/translator/c/gcc/tra ckgcroot.py -mpypy_main_startup -t implement_3.s > implement_3.gctmp Traceback (most recent call last): File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 1 950, in tracker.process(f, g, entrypoint=entrypoint, filename=fn) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 1 841, in process tracker = parser.process_function(lines, entrypoint, filename) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 1 438, in process_function lines, entrypoint, filename) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 1 350, in process_function table = tracker.computegcmaptable(self.verbose) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 4 7, in computegcmaptable self.parse_instructions() File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 1 90, in parse_instructions insn = meth(line) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 7 04, in conditional_jump self.register_jump_to(label) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 6 85, in register_jump_to self.labels[label].previous_insns.append(self.insns[-1]) KeyError: 'L3999' make: *** [implement_3.gcmap] Error 1 ---------- status: resolved -> unread _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 22:52:09 2011 From: pypy-dev-issue at codespeak.net (Chris Smowton) Date: Mon, 25 Apr 2011 20:52:09 +0000 Subject: [PyPy-issue] [issue693] Documentation needed: Coroutine garbage collection Message-ID: <1303764729.22.0.0275992164448.issue693@> New submission from Chris Smowton : Hey all, I just spent a day trying to figure out a weird bug using coroutines: I think it'd be useful if the following two counter-intuitive facts were documented: 1. When coroutines are garbage collected, they don't just go away: a CoroutineExit exception is thrown as if explicitly kill()'d 2. The coroutine will be executed to deal with the exception at next switch, so that the programmer might not actually end up in the coroutine they expect when they say "my_coro.switch()". Of course normally coroutines shouldn't end up garbage; they should be closed down in an orderly fashion. I ran into this situation when using coroutine pickle/unpickle to save program state, so old programs which had been pickled also got GC'd some time later. In a broader sense, it would be great to a) Attach a 'reason' parameter to CoroutineExit, as I'd often like to react differently to became-garbage (probably indicating a bug) compared to explicitly-killed, and b) add a "really kill" call that stops a coroutine rather than throwing a CoroutineExit exception; this would be useful in this case where I'm using pickle to "hibernate" a coroutine. These are really wishes/feature-requests though; I think the "bug" is that the current state of the world should be documented. ---------- effort: ??? messages: 2413 nosy: pypy-issue, smowton priority: bug release: 1.4 status: unread title: Documentation needed: Coroutine garbage collection _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 22:52:20 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Mon, 25 Apr 2011 20:52:20 +0000 Subject: [PyPy-issue] [issue691] pypy-head does not compile under Windows Message-ID: <1303764740.97.0.932892720049.issue691@> Amaury Forgeot d Arc added the comment: Can you attach a compressed copy of implement_3.s? ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 23:06:39 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Mon, 25 Apr 2011 21:06:39 +0000 Subject: [PyPy-issue] [issue691] pypy-head does not compile under Windows Message-ID: <1303765599.25.0.429838836701.issue691@> David Naylor added the comment: Here is the file. The one for FreeBSD will come (much) later... _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: implement_3.s.xz Type: application/x-xz Size: 78932 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Mon Apr 25 23:30:32 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Mon, 25 Apr 2011 21:30:32 +0000 Subject: [PyPy-issue] [issue690] pypy fails to compile under FreeBSD (9) Message-ID: <1303767032.63.0.432352510917.issue690@> David Naylor added the comment: After doing a `hg pull` and `hg update` I now get: [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "translate.py", line 294, in main [translation:ERROR] samefile = this_exe.samefile(exe_name) [translation:ERROR] File "/home/DragonSA/projects/pypy/py/_path/local.py", line 163, in samefile [translation:ERROR] os.path.samefile, str(self), str(other)) [translation:ERROR] File "/home/DragonSA/projects/pypy/py/_error.py", line 82, in checked_call [translation:ERROR] raise cls("%s%r" % (func.__name__, args)) [translation:ERROR] ENOENT: [No such file or directory]: samefile('/usr/local/bin/python', '/home/DragonSA/projects/pypy/pypy/translator/goal/pypy-c') _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Mon Apr 25 23:43:26 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Mon, 25 Apr 2011 21:43:26 +0000 Subject: [PyPy-issue] [issue690] pypy fails to compile under FreeBSD (9) Message-ID: <1303767806.37.0.915091970219.issue690@> Amaury Forgeot d Arc added the comment: oops, should be fixed with f7345e7d367d. _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 26 00:15:52 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Mon, 25 Apr 2011 22:15:52 +0000 Subject: [PyPy-issue] [issue690] pypy fails to compile under FreeBSD (9) Message-ID: <1303769752.13.0.743001706868.issue690@> David Naylor added the comment: Thanks, it works. Once the run completes I will send you the file it chokes on. _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 26 00:21:11 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Mon, 25 Apr 2011 22:21:11 +0000 Subject: [PyPy-issue] [issue691] pypy-head does not compile under Windows Message-ID: <1303770071.28.0.540296401393.issue691@> Amaury Forgeot d Arc added the comment: It's probably fixed with 11ec65b8347f, can you chech? _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 26 00:28:16 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Mon, 25 Apr 2011 22:28:16 +0000 Subject: [PyPy-issue] [issue691] pypy-head does not compile under Windows Message-ID: <1303770496.86.0.755671453657.issue691@> David Naylor added the comment: I will check after the run for FreeBSD _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 26 08:58:50 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Tue, 26 Apr 2011 06:58:50 +0000 Subject: [PyPy-issue] [issue693] Documentation needed: Coroutine garbage collection Message-ID: <1303801130.11.0.338653056837.issue693@> Carl Friedrich Bolz added the comment: Documenting this sounds good. I added the below paragraph to stackless.html: When a coroutine is garbage-collected, it gets the ``.kill()`` method sent to it. This happens at the point the next ``.switch`` method is called, so the target coroutine of this call will be executed only after the ``.kill`` has finished. sounds good? ---------- status: unread -> testing _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 26 09:05:33 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Tue, 26 Apr 2011 07:05:33 +0000 Subject: [PyPy-issue] [issue690] pypy fails to compile under FreeBSD (9) Message-ID: <1303801533.09.0.934085015595.issue690@> David Naylor added the comment: Compiling on HEAD/master/trunk I get the following error: /usr/local/bin/python /home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py -mmain -t implement_6.s > implement_6.gctmp Traceback (most recent call last): File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1950, in tracker.process(f, g, entrypoint=entrypoint, filename=fn) File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1841, in process tracker = parser.process_function(lines, entrypoint, filename) File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 1350, in process_function table = tracker.computegcmaptable(self.verbose) File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 60, in computegcmaptable return self.gettable() File "/home/DragonSA/projects/pypy/pypy/translator/c/gcc/trackgcroot.py", line 94, in gettable localvar) AssertionError: pypy_g_unicode_encode_ucs1_helper: %rdx gmake: *** [implement_6.gcmap] Error 1 Attached is the implement_6.s file. _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: implement_6.s.xz Type: application/x-xz Size: 91080 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Tue Apr 26 10:40:57 2011 From: pypy-dev-issue at codespeak.net (Chris Smowton) Date: Tue, 26 Apr 2011 08:40:57 +0000 Subject: [PyPy-issue] [issue693] Documentation needed: Coroutine garbage collection Message-ID: <1303807257.73.0.00660700364799.issue693@> Chris Smowton added the comment: Nearly, but I'm not sure the "executed only after the .kill has finished" bit is true! Here's an example session: >>>> >>>> >>>> import gc >>>> import stackless >>>> >>>> def f(): .... try: .... print "Start F!" .... main_coro.switch() .... print "End F!" .... except CoroutineExit: .... print "F: killed; switching to main" .... main_coro.switch() .... print "F: back in EH?" .... >>>> def g(): .... print "Start G!" .... main_coro.switch() .... print "End G!" .... >>>> main_coro = stackless.coroutine.getcurrent() >>>> coro1 = stackless.coroutine() >>>> coro1.bind(f) >>>> coro2 = stackless.coroutine() >>>> coro2.bind(g) >>>> >>>> coro1.switch() Start F! >>>> coro2.switch() Start G! >>>> del coro1 >>>> gc.collect() 0 >>>> coro2.switch() F: killed; switching to main >>>> coro2.switch() End G! >>>> Because F catches the CoroutineExit exception, we *never* end up in coro2! If there's any possibility a coroutine will be GC'd and will catch that call, the programmer will need to instrument their coroutines to figure out what actually got executed and re-issue the coro2.switch() at the next opportunity. This doesn't seem good -- if there's any possibility a coroutine might become garbage, the programmer will need to instrument their coroutines in order to work out that this happened and re-issue the switch. I'm not sure what the right thing to do would be here? _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 26 10:52:28 2011 From: pypy-dev-issue at codespeak.net (showstopper) Date: Tue, 26 Apr 2011 08:52:28 +0000 Subject: [PyPy-issue] [issue694] translate.py targetnopstandalone.py: fails because of a missing header guard Message-ID: <1303807948.34.0.895565561891.issue694@> New submission from showstopper : In the created c-source "c/src/asm_gcc_x86.h" is included twice which results in a redefinition error of static unsigned short _PyPy_get_387controlword(void) { and static void _PyPy_set_387controlword(unsigned short cw) { Adding a header guard to asm_gcc_x86.h fixes the issue. Platform is archlinux x86 and I used the latest hg-trunk. ---------- effort: ??? messages: 2424 nosy: pypy-issue, showstopper priority: bug release: ??? status: unread title: translate.py targetnopstandalone.py: fails because of a missing header guard _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 26 12:02:06 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Tue, 26 Apr 2011 10:02:06 +0000 Subject: [PyPy-issue] [issue693] Coroutine garbage collection prevents switches Message-ID: <1303812126.76.0.70079612406.issue693@> Carl Friedrich Bolz added the comment: ok, this I would consider a bug, and then this issue should be about that bug. If you feel like making the stuff below to a test in pypy/module/_stackless that would be helpful. ---------- status: testing -> chatting title: Documentation needed: Coroutine garbage collection -> Coroutine garbage collection prevents switches _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 26 13:23:03 2011 From: pypy-dev-issue at codespeak.net (David Naylor) Date: Tue, 26 Apr 2011 11:23:03 +0000 Subject: [PyPy-issue] [issue691] pypy-head does not compile under Windows Message-ID: <1303816983.87.0.300958314961.issue691@> David Naylor added the comment: I've run a compile with an updated checkout and get this error: # make gcc -O3 -DPy_BUILD_CORE -frandom-seed=testing_1.c -o testing_1.s -S testing_1.c -IC:\\cygwin\\home\\${USER}\\pypy\\pypy\\translator\\c - IC:\\cygwin\\home\\${USER}\\pypy\\pypy\\module\\cpyext\\include -I.. - IC:\\cygwin\\home\\${USER}\\libffi-3.0.8.tar.gz\\include In file included from common_header.h:36:0, from testing_1.c:1: C:\cygwin\home\${USER}\pypy\pypy\translator\c/src/stack.h:55:1: warning: 'thread' attribute directive ignored In file included from C:\cygwin\home\${USER}\pypy\pypy\translator\c/src/asm.h:4:0, from C:\cygwin\home\${USER}\pypy\pypy\translator\c/src/debug_print.h:44, from C:\cygwin\home\${USER}\pypy\pypy\translator\c/src/g_include.h:44, from testing_1.c:43: C:\cygwin\home\${USER}\pypy\pypy\translator\c/src/asm_gcc_x86.h:94:23: error: redefinition of '_PyPy_get_387controlword' C:\cygwin\home\${USER}\pypy\pypy\translator\c/src/asm_gcc_x86.h:94:23: note: previous definition of '_PyPy_get_387controlword' was here C:\cygwin\home\${USER}\pypy\pypy\translator\c/src/asm_gcc_x86.h:99:13: error: redefinition of '_PyPy_set_387controlword' C:\cygwin\home\${USER}\pypy\pypy\translator\c/src/asm_gcc_x86.h:99:13: note: previous definition of '_PyPy_set_387controlword' was here make: *** [testing_1.s] Error 1 After working around that error with #ifndef protection in pypy/translator/c/src/asm_gcc_x86.h on the file I get this error: # make C:/Python27/python.exe C:\\cygwin\\home\\${USER}\\pypy\\pypy/translator/c/gcc/trackgcroot.py - mpypy_main_startup -t implement_22.s > implement_22.gctmp Traceback (most recent call last): File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 1951, in tracker.process(f, g, entrypoint=entrypoint, filename=fn) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 1842, in process tracker = parser.process_function(lines, entrypoint, filename) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 1438, in process_function lines, entrypoint, filename) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 1350, in process_function table = tracker.computegcmaptable(self.verbose) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 47, in computegcmaptable self.parse_instructions() File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 190, in parse_instructions insn = meth(line) File "C:\cygwin\home\${USER}\pypy\pypy/translator/c/gcc/trackgcroot.py", line 789, in visit_call assert lineoffset in (1,2) AssertionError make: *** [implement_22.gcmap] Error 1 Attached is the implement_22.s file. _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: implement_22.s.xz Type: application/x-xz Size: 71712 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Tue Apr 26 14:06:34 2011 From: pypy-dev-issue at codespeak.net (Chris Smowton) Date: Tue, 26 Apr 2011 12:06:34 +0000 Subject: [PyPy-issue] [issue693] Coroutine garbage collection prevents switches Message-ID: <1303819594.12.0.101165379491.issue693@> Chris Smowton added the comment: I'll do that when I get some time (likely this weekend). I think it's an design issue more than a bug though -- you have to run that implied exit some time, and you have to do *something* if the coroutine doesn't die during that invocation. You could redefine the behaviour so you don't have an implied exit, just a silent death? You could define it as a programming error to leave a coroutine as garbage? Or the user could be required to cooperate with the gc, restoring the property that a switch() always ends up where you intend? _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Tue Apr 26 14:13:19 2011 From: pypy-dev-issue at codespeak.net (Chris Smowton) Date: Tue, 26 Apr 2011 12:13:19 +0000 Subject: [PyPy-issue] [issue693] Coroutine garbage collection prevents switches Message-ID: <1303819999.89.0.676859165546.issue693@> Chris Smowton added the comment: Another interesting case happens if a coroutine saves itself from the GC in its exception handler -- e.g. try: blah except CoroutineExit: global g; g = stackless.coroutine.getcurrent(). It looks like such a coroutine becomes a weird zombie creature that won't be killed again, even if it becomes garbage for a second time. _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Wed Apr 27 00:00:07 2011 From: pypy-dev-issue at codespeak.net (qbproger) Date: Tue, 26 Apr 2011 22:00:07 +0000 Subject: [PyPy-issue] [issue695] Make --opt=jit the default translation option Message-ID: <1303855207.73.0.76694575285.issue695@> New submission from qbproger : I think the default translation option should be --opt=jit. I feel as though the user wanting the jit is much more common than not wanting the jit. I wasted 2 translations because I didn't realize it wasn't the default. ---------- effort: ??? messages: 2429 nosy: pypy-issue, qbproger priority: wish release: ??? status: unread title: Make --opt=jit the default translation option _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Wed Apr 27 11:04:14 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Wed, 27 Apr 2011 09:04:14 +0000 Subject: [PyPy-issue] [issue694] translate.py targetnopstandalone.py: fails because of a missing header guard Message-ID: <1303895054.45.0.6725807865.issue694@> Carl Friedrich Bolz added the comment: this should be fixed in current head. ---------- status: unread -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Wed Apr 27 20:22:27 2011 From: pypy-dev-issue at codespeak.net (Armin Rigo) Date: Wed, 27 Apr 2011 18:22:27 +0000 Subject: [PyPy-issue] [issue648] __package__ not defined on import Message-ID: <1303928547.31.0.724643873191.issue648@> Armin Rigo added the comment: Should be fixed now. ---------- status: testing -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Wed Apr 27 20:23:58 2011 From: pypy-dev-issue at codespeak.net (Armin Rigo) Date: Wed, 27 Apr 2011 18:23:58 +0000 Subject: [PyPy-issue] [issue653] fix for test_absolute_import_without_future Message-ID: <1303928638.69.0.346864588917.issue653@> Armin Rigo added the comment: Might be fixed now, can you test? ---------- status: chatting -> testing _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Wed Apr 27 20:27:26 2011 From: pypy-dev-issue at codespeak.net (Armin Rigo) Date: Wed, 27 Apr 2011 18:27:26 +0000 Subject: [PyPy-issue] [issue696] importing.py ignores all StreamErrors Message-ID: <1303928846.14.0.439008599096.issue696@> New submission from Armin Rigo : pypy.module.imp.importing needs to be fixed to not eat all StreamErrors, at least at one place. It has the effect that e.g. if we are low on remaining file descriptors, importing some more modules will fail with just a very confusing "ImportError: modulename". ---------- effort: ??? messages: 2433 nosy: pypy-issue priority: bug release: ??? status: unread title: importing.py ignores all StreamErrors _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Thu Apr 28 09:44:27 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Thu, 28 Apr 2011 07:44:27 +0000 Subject: [PyPy-issue] [issue667] Final link failure due to libtinfo dependency Message-ID: <1303976667.67.0.616644940098.issue667@> Fijal added the comment: Closing then ---------- status: chatting -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Thu Apr 28 13:44:21 2011 From: pypy-dev-issue at codespeak.net (Fijal) Date: Thu, 28 Apr 2011 11:44:21 +0000 Subject: [PyPy-issue] [issue687] Patch to make the generated C filenames reflect the RPython source filenames Message-ID: <1303991061.6.0.53587426097.issue687@> Fijal added the comment: Sounds good to me, will look into merging it (probably not 1.5 though) _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 29 12:26:41 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Fri, 29 Apr 2011 10:26:41 +0000 Subject: [PyPy-issue] [issue383] string subclasses in getattr/setattr Message-ID: <1304072801.89.0.665599183012.issue383@> Carl Friedrich Bolz added the comment: this seems resolved since a long time ---------- nosy: +pypy-issue -ac, arigo, cfbolz, mwh, pedronis, tismer status: unread -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Fri Apr 29 16:40:00 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Fri, 29 Apr 2011 14:40:00 +0000 Subject: [PyPy-issue] [issue691] pypy-head does not compile under Windows Message-ID: <1304088000.45.0.754126353844.issue691@> Carl Friedrich Bolz added the comment: Can you try with current head again, the last failure is definitely fixed on head. _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 13:35:27 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Sat, 30 Apr 2011 11:35:27 +0000 Subject: [PyPy-issue] [issue697] write a getting-started-jit document Message-ID: <1304163327.08.0.386079498171.issue697@> New submission from Carl Friedrich Bolz : right now there is no intro about how to do the first steps with the JIT, like getting the logs, running jitviewer, etc. ---------- effort: medium messages: 2438 nosy: pypy-issue priority: wish release: ??? status: unread title: write a getting-started-jit document _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 13:50:18 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Sat, 30 Apr 2011 11:50:18 +0000 Subject: [PyPy-issue] [issue698] silence gcc ERRORs during compilation Message-ID: <1304164218.31.0.0561022094379.issue698@> New submission from Carl Friedrich Bolz : The red errors you get during compilation are scary, because often they can be ignored. Silence them somehow. ---------- effort: ??? messages: 2439 nosy: pypy-issue priority: bug release: ??? status: unread title: silence gcc ERRORs during compilation _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 13:57:03 2011 From: pypy-dev-issue at codespeak.net (Carl Friedrich Bolz) Date: Sat, 30 Apr 2011 11:57:03 +0000 Subject: [PyPy-issue] [issue699] add videos to docs Message-ID: <1304164623.31.0.0150249819834.issue699@> New submission from Carl Friedrich Bolz : The video page should be updated with some of the videos of talks we've given, e.g.: http://research.microsoft.com/apps/video/dl.aspx?id=144687 ---------- effort: ??? messages: 2440 nosy: pypy-issue priority: feature release: ??? status: unread title: add videos to docs _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 17:33:12 2011 From: pypy-dev-issue at codespeak.net (Armin Rigo) Date: Sat, 30 Apr 2011 15:33:12 +0000 Subject: [PyPy-issue] [issue595] Add Tkinter support through cpyext Message-ID: <1304177592.52.0.559950632146.issue595@> Armin Rigo added the comment: Works now, according to http://morepypy.blogspot.com/2011/04/using-tkinter-and-idle-with-pypy.html . ---------- status: unread -> resolved _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 19:06:18 2011 From: pypy-dev-issue at codespeak.net (zelegolas) Date: Sat, 30 Apr 2011 17:06:18 +0000 Subject: [PyPy-issue] [issue700] The release 1.5 for OSX it's not a release Message-ID: <1304183178.82.0.850495223512.issue700@> New submission from zelegolas : Hi When I run PyPy 1.5 (official release) on my Mac I have this: Python 2.7.1 (b590cf6de419, Apr 30 2011, 03:30:00) [PyPy 1.5.0-alpha0 with GCC 4.0.1] on darwin Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``"peephope" optimizations are what an optimistic Compiler uses'' >>>> And on my Mac with OSX 10.6.7 + Xcode 4 the latest version of GCC it's not GCC 4.0.1 : $ gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Could you build PyPy 1.5 with GCC 4.2.1 and don't change the name of the alpha version to a release name ---------- effort: ??? messages: 2442 nosy: pypy-issue, zelegolas priority: bug release: ??? status: unread title: The release 1.5 for OSX it's not a release _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 20:22:18 2011 From: pypy-dev-issue at codespeak.net (Ram Rachum) Date: Sat, 30 Apr 2011 18:22:18 +0000 Subject: [PyPy-issue] [issue701] Pypy can't find msvcr100.dll if launched via symlink Message-ID: <1304187738.03.0.397564181695.issue701@> New submission from Ram Rachum : Someone please tag this to the 1.5 release, it doesn't exist yet. I downloaded Pypy1.5 to my Windows machine. I noticed it needs msvcr100.dll, so I copied it to its folder. Now Pypy works when launched directly from folder, but when I made a symlink to it from a different folder, and tried to launch it, it gives a Windows error dialog saying that msvcr100.dll is missing. ---------- effort: ??? messages: 2443 nosy: cool-RR, pypy-issue priority: bug release: ??? status: unread title: Pypy can't find msvcr100.dll if launched via symlink _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 20:29:43 2011 From: pypy-dev-issue at codespeak.net (Ram Rachum) Date: Sat, 30 Apr 2011 18:29:43 +0000 Subject: [PyPy-issue] [issue701] Pypy can't find msvcr100.dll if launched via symlink Message-ID: <1304188183.69.0.333278284383.issue701@> Ram Rachum added the comment: My mistake, it's actually "libpypy.dll" that it's not finding, not "msvcr100.dll". ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 20:53:23 2011 From: pypy-dev-issue at codespeak.net (Ram Rachum) Date: Sat, 30 Apr 2011 18:53:23 +0000 Subject: [PyPy-issue] [issue702] Can't easy_install pip on Windows Message-ID: <1304189603.97.0.212366277513.issue702@> New submission from Ram Rachum : Please tag this as 1.5 release, there's no such tag now. I installed Pypy1.5 on my WinXP box. I installed distribute. I tried to `easy_install pip`, but got this: Searching for pip Reading http://pypi.python.org/simple/pip/ Reading http://pip.openplans.org Reading http://www.pip-installer.org Best match: pip 1.0 Downloading http://pypi.python.org/packages/source/p/pip/pip- 1.0.tar.gz#md5=327fc4a03df189506966e15021730550 Processing pip-1.0.tar.gz Running pip-1.0\setup.py -q bdist_egg --dist-dir c:\docume~1\user\locals~1\temp\easy_install-giu0b9\pip-1.0\egg-dist-tmp-guxqiw warning: no files found matching '*.html' under directory 'docs' warning: no previously-included files matching '*.txt' found under directory 'docs\_build' no previously-included directories found matching 'docs\_build\_sources' No eggs found in c:\docume~1\user\locals~1\temp\easy_install-giu0b9\pip-1.0\egg- dist-tmp-guxqiw (setup script problem?) ---------- effort: ??? messages: 2445 nosy: cool-RR, pypy-issue priority: bug release: ??? status: unread title: Can't easy_install pip on Windows _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 22:54:50 2011 From: pypy-dev-issue at codespeak.net (Bouchard) Date: Sat, 30 Apr 2011 20:54:50 +0000 Subject: [PyPy-issue] [issue703] Pypy runs slower that cpython in a function call cache Message-ID: <1304196890.39.0.215602888065.issue703@> New submission from Bouchard : The attached code works slowly on pypy1.5 than on python 3.2 This is my pypy version % 21:15 guillaume at guillaume-desktop ~/partitions pypy1.5 -V Python 2.7.1 (b590cf6de419, Apr 30 2011, 02:00:34) [PyPy 1.5.0-alpha0 with GCC 4.4.3] On a i7-950, I get the following time running this code with pypy and with python 3.2 Short process: $ time python3.2 partition.py 360 48 360 176175 python3.2 partition.py 360 48 360 0.55s user 0.02s system 99% cpu 0.575 total $ time pypy1.5 partition.py 360 48 360 176175 pypy1.5 partition.py 360 48 360 0.56s user 0.03s system 98% cpu 0.597 total Long process: $ time python3.2 partition.py 460 48 460 5611878 python3.2 partition.py 460 48 460 6.35s user 0.62s system 99% cpu 7.003 total $ time pypy1.5 partition.py 460 48 460 5611878 pypy1.5 partition.py 460 48 460 8.45s user 0.61s system 99% cpu 9.091 total Funny fact, if you remove the lru_cache (just comment out the decorator line 35), pypy run dramatically quicker (~10 times) than python 3.2 Without the lru_cache : $ time python3.2 partition.py 360 48 360 176175 python3.2 partition.py 360 48 360 3.24s user 0.01s system 99% cpu 3.262 total $ time pypy1.5 partition.py 360 48 360 176175 ~/src/pypy/pypy-1.5/bin/pypy partition.py 360 48 360 0.28s user 0.04s system 99% cpu 0.322 total So I *guess* the issue may be in how the jit behave with the lru_cache function. ---------- effort: ??? files: partition.py messages: 2446 nosy: guibou, pypy-issue priority: bug release: ??? status: unread title: Pypy runs slower that cpython in a function call cache _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: partition.py Type: text/x-python Size: 1397 bytes Desc: not available URL: From pypy-dev-issue at codespeak.net Sat Apr 30 22:54:54 2011 From: pypy-dev-issue at codespeak.net (Amaury Forgeot d Arc) Date: Sat, 30 Apr 2011 20:54:54 +0000 Subject: [PyPy-issue] [issue701] Pypy can't find msvcr100.dll if launched via symlink Message-ID: <1304196894.94.0.507652057366.issue701@> Amaury Forgeot d Arc added the comment: Copying msvcr100.dll does not work in some conditions, and you've found one. Please use the link mentioned in the download page: http://pypy.org/download.html ("VS 2010 install libraries") _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 23:00:41 2011 From: pypy-dev-issue at codespeak.net (Bouchard) Date: Sat, 30 Apr 2011 21:00:41 +0000 Subject: [PyPy-issue] [issue703] Pypy runs slower that cpython in a function call cache Message-ID: <1304197241.81.0.447700446899.issue703@> Bouchard added the comment: Sorry, in the attached code, there is a special case for python 3.2 that use the functool.lru_cache method instead of the writed method. You can comment out it, the time results (and the issue) are still valid. In fact, the functool.lru_cache (used only for cpython time measure) is slower than the attached lru_cache function, so in fact python3.2 runs a bit quicker than what I have writed. This does not changes the pypy1.5 time measures. ---------- status: unread -> chatting _______________________________________________________ PyPy development tracker _______________________________________________________ From pypy-dev-issue at codespeak.net Sat Apr 30 23:33:18 2011 From: pypy-dev-issue at codespeak.net (Ram Rachum) Date: Sat, 30 Apr 2011 21:33:18 +0000 Subject: [PyPy-issue] [issue701] Pypy can't find msvcr100.dll if launched via symlink In-Reply-To: <-2565425866386755757@unknownmsgid> Message-ID: Ram Rachum added the comment: As I said, it happens to libpypy.dll too. On Sat, Apr 30, 2011 at 10:54 PM, Amaury Forgeot d Arc < pypy-dev-issue at codespeak.net> wrote: > > Amaury Forgeot d Arc added the comment: > > Copying msvcr100.dll does not work in some conditions, and you've found > one. > Please use the link mentioned in the download page: > http://pypy.org/download.html > ("VS 2010 install libraries") > > _______________________________________________________ > PyPy development tracker > > _______________________________________________________ > -- Sincerely, Ram Rachum _______________________________________________________ PyPy development tracker _______________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: