Mailman 3 August 2005 - pypy-dev

Heidelberg Sprint Report
by Carl Friedrich Bolz Aug. 25, 2005

Aug. 25, 2005

Hi PyPy-Dev! Some notes about what's going on in Heidelberg: People arrived on Saturday and Sunday but we started hacking on Monday morning. First we had to solve all sorts of network problems because the computing center of the University of Heidelberg imposes a kind of restrictive setup. After this was done we had a planning meeting, distributed the work and started. Monday: - Samuele and Carl worked on refactoring the parts of genc that are responsible for the use of refcounting in the translation to make it possible to compile in a different GC. It turned out that refcounting is kind of deeply embedded into genc so it took a lot of time to introduce sensible hooks that other GCs could use. - Armin and Richard started to change genc so that it can handle the new external objects that Armin had to introduce to implement threading in PyPy. For now we have a simple GIL but it is not really deeply implanted in the interpreter so we should be able to change that later. After two days of hacking the were finished. Despite that it is still not possible to translate PyPy with threading because we are missing dictionaries with int keys on the RPython level. - Holger started preparing the release that is planned to happen during the sprint. Then he refactored our website so that all the websites are now generated statically and use a saner URL scheme. He then spent quite some time to make redirections from the old URLs work. See this mail for details: http://codespeak.net/pipermail/pypy-dev/2005q3/002285.html - Anders L. and Jacob worked on compliancy: they fixed various failing tests that are in some ways related to unicode. - Ludovic and Nik worked on making more parts of our compiler RPython. - Laura continued working on a docstring exctraction tool that she started to work on at the Gothenburg sprint. The tool takes the docstrings of types out of CPython and puts them in the relevant places of the PyPy codebase. With this we now have the correct docstrings for the builtin types. - Arre and Christian worked on compliancy. Christian feeled that the compliancy tests were taking to long on the interpreted PyPy so he tried making them run on the translated PyPy. This also involved problems since the compiler of the translated PyPy runs on applevel which means that running scripts involves a big startup overhead before it actually gets faster. Therefore he tried to introduce a hack so that the compiled PyPy uses CPython to translate its stuff and then run it. In the meantime Arre looked at the tests and started to reclassify core tests: he identified some tests that are in core but really shouldn't be there and the other way round. Tuesday: - Samuele, Carl, Richard, Holger and Armin continued to work on the stuff they started on Monday. - Nik worked on his 'Summer of Code'-project: he tried to move more parts of _sre to interplevel and make them annotatable. Additionally he worked on compliancy and fixed some tests. - Arre, Anders L., Jacob worked on compliancy Wednesday: This day was supposed to be devoted entirely to compliancy work. Some exceptions were allowed, though. - Richard and Eric (who arrived on Tuesday afternoon) started working on genllvm to bring it into a shape where it can translate PyPy better (they had already reached the translation goal a few days ago -- great work guys!). They kept finding some small bugs in LLVM. Still some external functions are missing as well and their goal was not to write them by hand but autogenerate them out of C code that already exists for genc. - Carl and Samuele used the garbage collection hooks they had introduced on Monday and Tuesday to make the Boehm garbage collector usable for genc as well (genllvm already uses it as their default (and only) collector). This was compared to factoring out refcounting relatively easy and was finished after a few hours and started working on compliancy afterwards. - Ludovic continued working on the compiler - Basically everybody else worked on compliancy tests. A lot of tests were recategorized to be non-core tests. Quite some failures are related to compiler issues. In the afternoon Holger, Samuele and later Armin started to dive into strange bugs of the compiler module that are related to nested scopes and that made some tests fail. These are the parts that I remember, corrections/additions welcome. Cheers, Carl Friedrich

1 0

Link failures on windows
by Ben.Young＠risk.sungard.com Aug. 24, 2005

Aug. 24, 2005

Hi Everyone, Did someone change the compilation chain so that on windows the modules don't link against Python any more? At the moment, all the genc tests fail with errors like: testing_11.obj : error LNK2019: unresolved external symbol _PyErr_SetString referenced in function __RPyConvertExceptionToCPython testing_11.obj : error LNK2019: unresolved external symbol _PyErr_SetNone referenced in function __RPyConvertExceptionToCPython testing_11.obj : error LNK2019: unresolved external symbol _PyClass_IsSubclass referenced in function __RPyConvertExceptionToCPython testing_11.obj : error LNK2019: unresolved external symbol _PyExc_Exception referenced in function __RPyConvertExceptionToCPython testing_11.obj : error LNK2019: unresolved external symbol _PyClass_Type referenced in function __RPyConvertExceptionToCPython testing_11.obj : error LNK2019: unresolved external symbol _PyDict_GetItemString referenced in function __RPyConvertExceptionToCPython testing_11.obj : error LNK2019: unresolved external symbol _PyEval_GetBuiltins referenced in function __RPyConvertExceptionToCPython testing_11.obj : error LNK2019: unresolved external symbol _PyMethod_New referenced in function _gencfunc_descr_get ... Cheers, Ben

1 0

internal website changes
by hpk＠trillke.net Aug. 23, 2005

Aug. 23, 2005

Hi pypy-dev, today i'd like to internally restructure the PyPy website and the documentation in particular. It seems sensible to do this before the next release that we are currently working on at the Heidelberg sprint. The goal of the new scheme is to get rid of the dynamic '.cgi' script handling and instead be able to generate the website by going into pypy/doc and issueing 'py.test' which will then generate static web pages that you can preview locally. It also checks referential integrity and with '-R' you can check remote URLs from the documentation. As a result, the URLs will change but i'll try to redirect the current URLs to the new location as good as possible. If you notice website-related problems later in the afternoon then please mail me directly instead of spamming pypy-dev. The new scheme also should also enable us to do per-version documentation of PyPy which will probably (hopefully? :-) become an issue some time soon. cheers, holger

1 0

pypy-sync 18th August
by holger krekel Aug. 18, 2005

Aug. 18, 2005

Hi folks, as usually there is the thursday #pypy-sync meeting at 1pm. This weeks topic is planning the heidelberg sprint in some more detail. cheers, holger

1 0

genllvm standalone announcement
by Eric van Riet Paap Aug. 17, 2005

Aug. 17, 2005

We are proud to announce that since this afternoon the llvm backend can also create a standalone executable of the PyPy interpreter! The current version even runs up to and including the InteractiveConsole, though some things are obviously not working yet. The llvm backend would not have been possible without all the people contributing to PyPy. Carl Friedrich did an amazing amount for groundwork during the first half of this year. Holger helped out with the architecture of the current llvm backend and Richard and I worked on it for the last two months. If you would like to run the current version on x86 (linux), the executable can be downloaded from http://codespeak.net/~ericvrp/download/entry_point You will see some debug information and sometimes segfaults because not all external functions are (fully) implemented and neither are some other features. At the Heidelberg sprint hopefully the remaining functionality will be implemented. So for PyPy 0.7 we will have two fully self-contained executables. Who would have thought that 2 months ago... enjoy, Eric

1 0

Fw: Patches
by Ben.Young＠risk.sungard.com Aug. 17, 2005

Aug. 17, 2005

Hi Everyone, I was wondering if anyone would mind applying this patch that causes a few more tests to pass on windows. After this has been applied I've got the number of test failures (on windows) down to 14. Cheers, Ben

2 2

Re: [pypy-svn] r16070 - pypy/dist/pypy/objspace/std
by Christian Tismer Aug. 16, 2005

Aug. 16, 2005

ericvrp(a)codespeak.net wrote: > Author: ericvrp > Date: Sun Aug 14 21:33:03 2005 > New Revision: 16070 > > Modified: > pypy/dist/pypy/objspace/std/strutil.py > Log: > Better to use math.log10(float) consistently. > Backends (at least llvm) will have no math.log10(int) implementation. That's correct in principle, but not the reasoning: The code is applevel and therefore allowed to be more sloppy. No backend will ever see it. The actual version is interp_string_to_float, and that had the correction. ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

3 6

m.lib
by Ben.Young＠risk.sungard.com Aug. 16, 2005

Aug. 16, 2005

Hi, Does anyone know what m.lib is, as alot of the executables produced seem to want to link with it, and I don't have it! (This is on Windows, usgin cygwin) Cheers, Ben

3 4

Re: [pypy-svn] r16013 - in pypy/dist/pypy/interpreter/pyparser: . test
by Armin Rigo Aug. 15, 2005

Aug. 15, 2005

Hi Adrien, On Fri, Aug 12, 2005 at 06:11:51PM +0200, adim(a)codespeak.net wrote: > - don't use eval() builtin anymore in eval_number() and eval_string(). The > replacement implementation is incomplete though, so it needs to be > finished (esp. for raw/unicode strings, and 0x-like numbers) We have done this code during the last sprint, "en passant". Sorry, I intended to mention it here but forgot. We needed it because the app-level ast transformer from the stdlib also uses eval() to get literals, but this causes an infinite recursion (eval() at app-level causes the compiler to be called, which uses the ast transformer again). The code is: * for string literals: interpreter/pyparser/parsestring.parsestr() * for numeric literals: lib/_stablecompiler/transformer.decode_numeric_literal() The latter is not RPython but it's not too long either. Getting these right was a bit involved so I guess there is no point in duplicating the effort... A bientot, Armin

1 0

math.log0 / interactive shell
by Christian Tismer Aug. 15, 2005

Aug. 15, 2005

Just a funny observation: in interpreted PyPy, math.log10(1L << 10000) works just fine. In compiled PyPy, I get an overflow error. Can this be related to some Exception problems? Other problem: When the compiled pypy shell starts, and any exception occours, it takes about 10 minutes(!) until you get the exception. After that, it is as low or fast as other command prompts. This was one reason why I looked into geninterp and gateway, becasue I expected that something would be compiled late, but I didn't find it. Which doesn't mean anything :-) ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

3 3