Mailman 3 August 2006 - pypy-dev

compilemodule.py not working
by Haggai Eran 31 Aug '06

31 Aug '06

Hi I cannot get the compilemodule to work. It seems that strings returned from PyString_FromStringAndSize are unwrapped automatically, causing ctypes.byref to fail. Traceback (most recent call last): File "../bin/compilemodule.py", line 12, in ? main(sys.argv) File "/usr/src/pypy-dist/pypy/rpython/rctypes/tool/compilemodule.py", line 78, in main c_ext_module = compilemodule(argv[1], interactive=True) File "/usr/src/pypy-dist/pypy/rpython/rctypes/tool/compilemodule.py", line 26, in compilemodule module = ModuleClass(space, space.wrap(modname)) File "/usr/src/pypy-dist/pypy/module/thread/__init__.py", line 25, in __init__ MixedModule.__init__(self, space, *args) File "/usr/src/pypy-dist/pypy/interpreter/mixedmodule.py", line 18, in __init__ Module.__init__(self, space, w_name) File "/usr/src/pypy-dist/pypy/interpreter/module.py", line 17, in __init__ space.setitem(w_dict, space.new_interned_str('__name__'), w_name) File "/usr/src/pypy-dist/pypy/objspace/cpy/objspace.py", line 171, in new_interned_str PyString_InternInPlace(byref(w_s)) TypeError: byref() argument must be a ctypes instance, not 'str' -- Haggai Eran

1 1

Fw: [Python-3000] Premature optimization and all that
by Ben.Young＠risk.sungard.com 30 Aug '06

30 Aug '06

Hi PyPy'rs! I'm sure you will have already seen this email, but I thought it was quite interesting, as it may mean that Python 3000 is where PyPy can become faster than CPython! Given a years development time at the current rate of progress. I think PyPy is about 2.5 times slower than CPython at the moment isn't it? Cheers, Ben ----- Forwarded by Ben Young/Infinity on 30/08/2006 08:43 ----- python-3000-bounces+python=theyoungfamily.co.uk(a)python.org wrote on 29/08/2006 22:51:17: > Over lunch with Neal we came upon the topic of optimization and Python 3000. > > It is our strong opinion that in this stage of the Py3k project we > should focus on getting the new language spec and implementation > feature-complete, without worrying much about optimizations. > > We're doing major feature-level surgery, e.g. int/long unification, > str/unicode unification, range/xrange unification, keys() views, and > many others. Keeping everything working is hard work in and of itself; > having to keep it as fast as it was through all the transformations > just makes it that much harder. > > if Python 3.0 alpha 1 is twice as slow as 2.5, that's okay with me; we > will have another year to do performance measurements and add new > optimizations in the ramp-up for 3.0 final. Even if 3.0 final is a bit > slower than 2.5 it doesn't bother me too much; we can continue the > tweaks during the 3.1 and 3.2 development cycle. > > Note: I'm note advicating wholesale proactive *removal* of > optimizations. However, I'm allowing new features to slow down > performance temporarily while we get all the features in place. I > expect that the optimization possibilities and needs will be different > than for 2.x, since some of the fundamental data types will be so > different. > > In particular, I hope that Martin's int/long unification code can land > ASAP; it's much better to have this feature landed in the p3yk branch, > where everyone can bang on it easily, and learn how this affects user > code, even if it makes everything twice as slow. This seems much > preferable over having it languish in a separate branch until it's > perfect. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ > Python-3000 mailing list > Python-3000(a)python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: http://mail.python. > org/mailman/options/python-3000/python%40theyoungfamily.co.uk >

1 0

pypy-sync thursday 4pm UTC+2
by hpk＠trillke.net 29 Aug '06

29 Aug '06

Hi folks, at the nice and small Ireland sprint we discussed apart from the weather a bit future sprint planning. Next Thursday 4pm UTC+2, 31st August, there is now a pypy-sync meeting scheduled. Concrete initial topics: * rough sprint planning till March 2007 * concrete sprint planning beginning November, HHU/Duesseldorf? * security prototype: when to work on it and the actual workshop timing with the IBM guy(s), suggestion is January/February feel free to append topics, also at the meeting, but the meeting is limited to 30 minutes from my moderation side. best, holger

1 0

Extension compiler and external DLLs
by laurent destriau 27 Aug '06

27 Aug '06

> I have to admit it didn't work for me... It did for me: from pypy.rpython.rctypes.tool.ctypes_platform import configure, Library class CConfig: _header_ = "" _includes_ = ["windows.h", "gl/gl.h"] gl = Library("opengl32") gl = configure(CConfig)["gl"] glEnd = gl.glEnd glEnd.restype = None def DrawSomething(space): glEnd() Thanks! -- Laurent Destriau

2 1

Extension compiler and external DLLs
by laurent destriau 25 Aug '06

25 Aug '06

Hi, I would like to use pypy/bin/compilemodule.py to compile some of my code, which uses OpenGL. I am wondering why the following does not work (Link error on glEnd) : from ctypes import windll glEnd = windll.opengl32.glEnd glEnd.restype = None def DrawSomething(space): glEnd() While this does compile fine: from pypy.rpython.rctypes.tool import ctypes_platform from pypy.rpython.rctypes.tool.libc import libc from ctypes import * time_t = ctypes_platform.getsimpletype('time_t', '#include <time.h>', c_long) time = libc.time time.argtypes = [POINTER(time_t)] time.restype = time_t def DrawLine(space): time(None) Any help would be much appreciated. Thanks, Laurent Destriau

2 3

Sprint reports 2003-2006
by Beatrice During 24 Aug '06

24 Aug '06

Hi there We now have a page linking to all sprint reports from PyPy sprints since the project started 2003 up to present time. http://codespeak.net/pypy/dist/pypy/doc/sprint-reports.html There are 22 (!!) sprints during this period and we have reports from 16 of them (soon - after the ongoing Limerick sprint 17 ;-). This page should help people to better understand the progress of the project - so enjoy a stroll down the PyPy memory lane. Thanks Michael for helping out with this. Cheers Bea

3 3

[jinty@web.de: [Zope3-dev] zope.interface using PyPy's extension compiler]
by Alexandre Fayolle 23 Aug '06

23 Aug '06

Hi everyone, I hope you're having fun in Ireland. I don't remember seing the information below on this list, and thought it could interest people to know of other's efforts to use pypy. Cheers, ----- Forwarded message from Brian Sutherland <jinty(a)web.de> ----- From: Brian Sutherland <jinty(a)web.de> To: Zope3-dev <zope3-dev(a)zope.org> Date: Mon, 21 Aug 2006 16:57:06 +0200 Subject: [Zope3-dev] zope.interface using PyPy's extension compiler At EuroPython I investigated re-implementing a class from zope.interface in PyPy's Restricted Python. I compiled it to C and then compared it to the Pure Python implementation and handcrafted C optimization. Not having touched PyPy before, I found it extreemly interesting. The report and code I wrote is available here for anyone else interested: http://lentejasverdes.ath.cx/stuff/pypy/europython_2006/README.html -- Brian Sutherland ----- End forwarded message ----- -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science

3 2

Modules on Windows
by Lawrence Oluyede 20 Aug '06

20 Aug '06

I managed to port rctime and mmap on Windows. So there's a little bit more of pypy on Windows platform. I can't tell you how much pain was to configure Windows to compile but I'm sure you all can understand :-) -- Lawrence http://www.oluyede.org/blog

2 1

Self-hosted
by Armin Rigo 18 Aug '06

18 Aug '06

Hi all, A few days ago we got our first version of pypy-c compiled with pypy-c. At least it produced the C code before distutils crashed because of our incomplete posix module; so you have to say cd pypy/translator/goal pypy-c --text --source translate.py cd /tmp/usession-yourname/testing_1 make So now we're self-hosted :-) A bientot, Armin

3 2

Lingering issues w/my pypy tester
by Scott Dial 14 Aug '06

14 Aug '06

Whether any of these are "bugs" or not is up to you, but they are nuissances for my test runs: * module._stackless.test.test_choicepoint http://scottdial.com/pypytest/31094/failed/module._stackless.test.test_choi… This test gets stalled while running a subprocess (testing_1.exe) and I must manually kill this process for the testing to continue. I haven't been able to identify the problem. * translator.c.test.test_stackless.TestStackless().test_stack_too_big http://scottdial.com/pypytest/31094/failed/translator.c.test.test_stackless… This test causes the boehm gc library to throw and catch an exception "Too many heap sections". I suspect this means that the test has indeed failed. However, this assertion from the gc library is modal and blocking, so it stalls the test run until human intervention clicks "ok". I haven't looked deeply into this one. Otherwise, none of the failures require human involvement to get things going again, but there are plenty of other tests which are erroneous failures. -- Scott Dial scott(a)scottdial.com scodial(a)indiana.edu

2 1