Mailman 3 August 2005 - pypy-dev

bug in http://codespeak.net/moin/pypy/moin.cgi/FrontPage?action=show
by Laura Creighton 10 Oct '05

10 Oct '05

If you click on the 'documentation' link you get a traceback! ooops. I will look at this later unless somebody beats me to it. Laura

5 4

Release
by Ben.Young＠risk.sungard.com 05 Sep '05

05 Sep '05

Congratulations everyone one the release! It looks really good! So what's the next priority? Speed or more customisability (or both!)? Cheers, Ben

7 9

refactoring Module discovery/implementation?
by hpk＠trillke.net 02 Sep '05

02 Sep '05

Hi pypy-dev, I'd like to suggest heading towards making PyPy's mixed C-ported modules more self-contained and not have it's implementation and initilization spread over several directories and code areas. IMO it's good that CPython has basically one C file that describes a Module's implementation. With Python we could make it a package so that we can still separate information like interp-level, app-level and low-level glue code but keep things more together and have it picked up via some more plugin-based scheme. The package scheme (probably based on the current mixed modules approach) should have a runtime interface and try to stay indepedent from the inner PyPy developments like where exactly things at low level are located. With "runtime interface" i mean that PyPy would automatically discover all modules in a given plugin/module directory by importing and querying them to get information the provided module, a description (docstring) and e.g. which ll-functions are provided and special annotations and what not. Oh, and "py.py --listmodules" should provide a full view of available modules (and modules included by the current defaults) so that you can pass that to --usemodules="x,y,z". This involves a bit of API design that we haven't done much for our internal stuff yet but i think it's about time to provide some nicer APIs and separate things. What do you think? A sprint topic? First write documentation and then implement? cheers, holger

3 2

pypy-sync back again thursday 1pm
by hpk＠trillke.net 31 Aug '05

31 Aug '05

Hi again, so the heidelberg sprint wears off and just when you thought things were getting relaxed here is the next pypy-sync meeting invitation :-) ============================================= pypy-sync developer meeting 1st September ============================================= Time & location: 1pm (30 minutes) at #pypy-sync Regular Topics ==================== - activity reports (3 prepared lines of info, LAST/NEXT/BLOCKERS). - resolve conflicts/blockers Annotated Topics of the week ================================= Recap of discussed development areas until October ------------------------------------------------------- At the meeting at the heidelberg sprint we listed a few areas that deserve developing focus in the next time: - bringing the compiler to good state, Arre and Samuele will try to help and discuss with Ludovic. The idea is to have the compiler effort almost done before the October Paris sprint and get rid of the various temporary hacks we have around. - cleanups in various areas should be tackled, in particular - the translation driving (translate_pypy.py and friends) and - improved test/reporting support. Anything else that we want to list explicitely? Like lifting the number of Pystones? :-) Paris Sprint announcement ----------------------------------------------- We need to check what the status of the Paris sprint announcement is as it should go out this week. Topics as discussed at the end of the heidelberg sprint: - threading and GC - refactoring/translation features - start on JIT/optimizations/stackless Let's reconfirm/extend this and then make sure that we have it out by the weekend. Preparation/Moderation Next pypy-sync meeting -------------------------------------------------- There is the idea to rotate pypy-sync meeting preparation and moderation between developers. So who would like to do some preparation and the moderation next time? It would be great if we had at least 3 people who shift between them unless we just want to do alphabetical order :-)

1 0

irc logs dead?
by Ben.Young＠risk.sungard.com 31 Aug '05

31 Aug '05

Hi Everyone, The archived irc log server appears to be dead at the moment (and has been for a couple of days). Does anyone know anything about this, or is it out of your hands? Cheers, Ben

2 1

Re: [pypy-dev] pypy-0.7.0 is out!
by Arthur Peters 29 Aug '05

29 Aug '05

Thanks for your replies. I had forgoten -t-lowmem. I unloaded X and a few other things and tried it again. It translated without swapping. The python translator process finished holding 704M. I didn't notice it going any higher (but it may have). It used about 28 minutes of CPU time. I used the options "-t-lowmem -text" (-text because I'm not running under X). The cc1 process used in excess of 800M again. Would it be posible to emit a set of files instead of a single file? Then compile them seperately. Spliting it into 10 files would speed up compilation alot because it wouldn't swap. pypy-c starts and seems to work but is VERY slow. It spends a lot of time consuming 100% CPU and not accessing the disk. It also seems to be constantly allocating more RAM, also. Is this the issue related to slow module loading or something else? (help(theading) took almost 40 minutes, and failed with missing popen) Also it takes a couple seconds to respond after I hit enter no matter what the command is (even things like "x = 1"). I think implementing readline-like features for the interactive prompt would be very nice. At the very least a working backspace and command history. I tried llvm but it failed will downloading from codespeak.net/pypy/llvm-gcc.cgi (Strange problem for a compiler) because the ethernet cable had come loose from the machine. Overall I am very impressed and I can't wait for some new features to come out of this. The JIT will be neat, but I'm also interested in the thunk object space as a way of implementing a threading model in which each thread makes requests from other threads. The requests return immediately, but the returned object is a special object that is automatically replaced with the actual result when it is available. It seems like a thread safe version of the thunk object space would do quite nice for implementing this. (I learn about this idea from reading about Eifel but I've never actually programmed with it) Just some thoughts of my own. Not a request. Once the whole thing gets a bit more stable I'll start playing with implementing this kinda thing myself. (assuming I have some free time ;-) Good work, -Arthur PS: I'll remember the "compile it by hand later" trick, but it wasn't needed this time. On 8/28/2005, "Carl Friedrich Bolz" <cfbolz(a)gmx.de> wrote: >Hi Arthur! > >Arthur Peters wrote: >> I tried translating pypy on my AMD64 laptop and it translated fine, >> compilation did finally run the machine out of ram. > >Damn. > >[snip] > >> PS: BTW, I'm willing to try it again if it would help. This time I will >> kill everything unnessisary and use 2-3GB of swap ;-) > >I don't know if you did that already but you might want to use -t-lowmem > as an option to translate_pypy which should reduce memory usage quite >a bit. > >Thanks for trying this out! > >Cheers, > >Carl Friedrich

2 1

pypy-0.7.0 is out!
by hpk＠trillke.net 29 Aug '05

29 Aug '05

pypy-0.7.0: first PyPy-generated Python Implementations ============================================================== What was once just an idea between a few people discussing on some nested mailing list thread and in a pub became reality ... the PyPy development team is happy to announce its first public release of a fully translatable self contained Python implementation. The 0.7 release showcases the results of our efforts in the last few months since the 0.6 preview release which have been partially funded by the European Union: - whole program type inference on our Python Interpreter implementation with full translation to two different machine-level targets: C and LLVM - a translation choice of using a refcounting or Boehm garbage collectors - the ability to translate with or without thread support - very complete language-level compliancy with CPython 2.4.1 What is PyPy (about)? ------------------------------------------------ PyPy is a MIT-licensed research-oriented reimplementation of Python written in Python itself, flexible and easy to experiment with. It translates itself to lower level languages. Our goals are to target a large variety of platforms, small and large, by providing a compilation toolsuite that can produce custom Python versions. Platform, Memory and Threading models are to become aspects of the translation process - as opposed to encoding low level details into a language implementation itself. Eventually, dynamic optimization techniques - implemented as another translation aspect - should become robust against language changes. Note that PyPy is mainly a research and development project and does not by itself focus on getting a production-ready Python implementation although we do hope and expect it to become a viable contender in that area sometime next year. Where to start? ----------------------------- Getting started: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/ PyPy Homepage: http://codespeak.net/pypy/ The interpreter and object model implementations shipped with the 0.7 version can run on their own and implement the core language features of Python as of CPython 2.4. However, we still do not recommend using PyPy for anything else than for education, playing or research purposes. Ongoing work and near term goals --------------------------------- PyPy has been developed during approximately 15 coding sprints across Europe and the US. It continues to be a very dynamically and incrementally evolving project with many one-week meetings to follow. You are invited to consider coming to the next such meeting in Paris mid October 2005 where we intend to plan and head for an even more intense phase of the project involving building a JIT-Compiler and enabling unique features not found in other Python language implementations. PyPy has been a community effort from the start and it would not have got that far without the coding and feedback support from numerous people. Please feel free to give feedback and raise questions. contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html contributor list: http://codespeak.net/pypy/dist/pypy/doc/contributor.html have fun, the pypy team, of which here is a partial snapshot of mainly involved persons: Armin Rigo, Samuele Pedroni, Holger Krekel, Christian Tismer, Carl Friedrich Bolz, Michael Hudson, Eric van Riet Paap, Richard Emslie, Anders Chrigstroem, Anders Lehmann, Ludovic Aubry, Adrien Di Mascio, Niklaus Haldimann, Jacob Hallen, Bea During, Laura Creighton, and many contributors ... PyPy development and activities happen as an open source project and with the support of a consortium partially funded by a two year European Union IST research grant. Here is a list of the full partners of that consortium: Heinrich-Heine University (Germany), AB Strakt (Sweden) merlinux GmbH (Germany), tismerysoft GmbH(Germany) Logilab Paris (France), DFKI GmbH (Germany) ChangeMaker (Sweden), Impara (Germany)

3 2

Re: [pypy-svn] r16598 - pypy/dist/lib-python/modified-2.4.1
by Ben.Young＠risk.sungard.com 28 Aug '05

28 Aug '05

Wasn't this discussed on Python-Dev recently? I think CPython has the same problem. Cheers, Ben pypy-svn-bounces(a)codespeak.net wrote on 26/08/2005 12:07:00: > Author: cfbolz > Date: Fri Aug 26 13:07:00 2005 > New Revision: 16598 > > Added: > pypy/dist/lib-python/modified-2.4.1/linecache.py > - copied, changed from r16593, pypy/dist/lib-python/2.4.1/linecache.py > Log: > For now, use Richard's idea to optimize linecache.py until we figure out why > readlines() is so slow in 'U'-mode files. > > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn >

2 1

PyPy-dev
by Ben.Young＠risk.sungard.com 26 Aug '05

26 Aug '05

Hi PyPy'rs, Are the sprinters reading pypy-dev at the moment? Cheers, Ben

3 3

Release
by Ben.Young＠risk.sungard.com 26 Aug '05

26 Aug '05

I know you are making a release soon, so I thought I'd send you this patch which fixes a couple of test issues. With this patch I get 14 test failures still, so I will attach the test log as well. Cheers, Ben

1 1

pypy-dev August 2005