Mailman 3 October 2005 - pypy-dev

Re: [pypy-svn] r19046 - pypy/dist/pypy/objspace/std
by Christian Tismer Oct. 26, 2005

Oct. 26, 2005

cfbolz(a)codespeak.net wrote: > replace MultiMethod with StdObjspaceMultiMethod I understand the textual effect of the change, but it would be nice to mention the reasoning: Why is this done? 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/

2 2

pypy-sync meeting on thursday, 27/10/2005
by Carl Friedrich Bolz Oct. 26, 2005

Oct. 26, 2005

Hi PyPy-dev! another wonderful pypy-sync meeting is coming up tomorrow! ======================================== pypy-sync developer meeting 21th Octover ======================================== Time & location: 1.00 - 1.30 pm (GMT+2) at #pypy-sync Regular Topics ==================== - activity reports (3 prepared lines of info, LAST/NEXT/BLOCKERS). - resolve conflicts/blockers Annotated Topics of the week ================================= "this week on #pypy" -------------------------- Michael volunteered to write a short "This week on #pypy" text every week. This would make navigating the logs a lot easier but is quite a lot of work. Therefore he would like everybody to send him mails what they want there in a particular week ("please include this-and-that discussion with armin about such-and-such!"). Does that approach make sense? new release -------------------------- One of the deliverables we promised to the EU for the August release was a flexible parser/compiler implementation. At this point the compiler situation was a horrible mess so it was considered in Paris to make another release before December. Does a release that spotlights the compiler make sense? When and how should we do it? gothenburg sprint topics -------------------------- (topic suggested by Bea) We have a sprint planned at the beginning of December in Gothenburg. What should the topics of the sprint be? Will it be a more open sprint or more rather targeted at core developpers? See you all tomorrow, Carl Friedrich

1 0

Re: [pypy-svn] r19048 - pypy/dist/pypy/objspace/std
by Christian Tismer Oct. 26, 2005

Oct. 26, 2005

cfbolz(a)codespeak.net wrote: > Author: cfbolz > Date: Thu Oct 27 01:43:41 2005 > New Revision: 19048 > > Modified: > pypy/dist/pypy/objspace/std/dicttype.py > pypy/dist/pypy/objspace/std/listtype.py > pypy/dist/pypy/objspace/std/model.py > pypy/dist/pypy/objspace/std/objspace.py > pypy/dist/pypy/objspace/std/slicetype.py > pypy/dist/pypy/objspace/std/stdtypedef.py > pypy/dist/pypy/objspace/std/stringtype.py > pypy/dist/pypy/objspace/std/unicodetype.py > Log: > oops Argll? Please, explain! -- 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/

1 0

Paris sprint report conclusion
by Carl Friedrich Bolz Oct. 25, 2005

Oct. 25, 2005

Hi PyPy-dev! Now that the sprint has ended and we (Micheal, Carl, Armin) are sitting in the Thalys to Koeln, we fear we should at least write a few words about the last days. On Friday morning another discussion group was founded and discussed - again - the state and future of the l3interpreter (l3 = lll = low low level), that is the translatable llinterpreter. The results were presented after lunch, together with some ideas about the JIT. Afterwards Carl gave a short talk on the results of his summer of code project on writing garbage collectors in RPython. Boris, Michael, Bert with help from Samuele spent the whole rest of the sprint working on the many open issues related to ootyping. Simple programs can now be ootyped, including inheritance, methods, instance attributes and right at the end some support for prebuilt instances. In addition they extended the llinterpreter to understand the ootype operations as well (we were worried that our names were starting to make sense). Armin spent the last days fixing different cases that crashed pypy-c which he found by running the CPython compliancy tests. In addition he helped various people to find their way around the codebase. Adrien and Arre worked on fixing compiler and parser issues that led to wrong line numbers and different issues that popped up. Ludovic and Adrien experimented with rewriting parts of the Numeric package in RPython. Valentino and Amaury continued on implementing the socket module which turned out (as expected) to be a platform dependent nightmare. They have a kind of complete socket module now, but some functions cannot yet be translated. Christian worked on an experiment to reorder functions in the created C code to improve code locality. Finally, after a week of srapped attemps, much headscratching and heated discussion there was some code written for the l3interpreter. On Saturday afternoon Holger and Carl wrote the basic model and managed to interpret interesting functions like x + 4. On Sunday Samuele and Carl continued and started on a graph converter that takes ll graphs and transforms into the form the l3interpreter expects. On Saturday afternoon there was a planning meeting where the actions of the following weeks were discussed. The tedious EU-report writing was distributed to those unfortunate creatures that are paid for working on PyPy. Furthermore we discussed the various conference and sprints people want to attend -- it seems that nobody will see home much in the next few months. All in all it was a very productive sprint but of course we all have to recover for two weeks now. Exhaustedly, Armin, Michael & Carl Friedrich

2 1

Re: [pypy-dev] Re: [pypy-svn] r18901 - in pypy/dist/pypy: module/_socket module/_socket/rpython module/_socket/rpython/test translator/c translator/c/src translator/c/test
by Amaury Forgeot D Arc Oct. 25, 2005

Oct. 25, 2005

Armin Rigo wrote: > > +from pypy.module._socket.rpython import rsocket > > But no rpython.py :-) svn add missing... Oops - thanks. I just tried to rebuild a new one from scratch - at least tests are passing again. I'll have to wait until I go home to check in the "real" version. Sorry for the inconvenience... -- Amaury Forgeot d'Arc Ubix Development www.ubitrade.com

1 0

Re: [pypy-svn] r18901 - in pypy/dist/pypy: module/_socket module/_socket/rpython module/_socket/rpython/test translator/c translator/c/src translator/c/test
by Armin Rigo Oct. 25, 2005

Oct. 25, 2005

Hi Amaury, On Tue, Oct 25, 2005 at 02:52:08AM +0200, afa(a)codespeak.net wrote: > +from pypy.module._socket.rpython import rsocket But no rpython.py :-) svn add missing... A bientot, Armin

1 0

pypy calendar
by Michael Hudson Oct. 24, 2005

Oct. 24, 2005

With help from Nicholas Riley, I've set up a iCal style calendar with important PyPy dates on it: http://pypycal.sabi.net/ (or webcal://pypycal.sabi.net///calendars/PyPy.ics if you have ical or sunbird installed) If you want to make changes, hassle me or sabi for the password. Thanks again to Nicholas for setting this up, I hope it proves useful... Cheers, mwh -- If comp.lang.lisp *is* what vendors are relying on to make or break Lisp sales, that's more likely the problem than is the effect of any one of us on such a flimsy marketing strategy... -- Kent M Pitman, comp.lang.lisp

1 0

Re: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
by Laura Creighton Oct. 24, 2005

Oct. 24, 2005

In a message of Wed, 19 Oct 2005 13:26:30 +0200, Armin Rigo writes: <snip> >I think it's still correct to call them continuations, but I'm open to >suggestions for a better name. If the name suggests it's an internal >implementation basic block, the better. Gerald J Sussman and Drew McDermott called re-invocable continuations 'Hairy Control Structures' :-) I think the word 'continuation' has been used by too many people for too many slightly different things. Thus it is confusing because people will think our continuations are like the ones they know from some other place. Maybe we need to not find another _noun_ but instead find a _verb_? Laura

3 5

Re: [pypy-svn] r18792 - in pypy/dist/pypy/translator/c: . src test
by Christian Tismer Oct. 23, 2005

Oct. 23, 2005

arigo(a)codespeak.net wrote: > Modified: > pypy/dist/pypy/translator/c/extfunc.py > pypy/dist/pypy/translator/c/src/ll_os.h > pypy/dist/pypy/translator/c/test/test_extfunc.py > Log: > C version of opendir/readdir/closedir. Hopefully this works on > Windows as well -- looking at the CPython posixmodule.c, there is > a chance that modern Windows have these functions as well, but I > can't tell for sure. Unfortunately it has absolutely not. :-( The semantics are quite a bit different. First of all, the directory parameter must be augmented with r"\*.*". I first tried that from ll_os, but it makes all code windows dependent. Then, there is no plain opendir() equivalent, but only FindFirstFile, which is like opendir and readdir() in one call. As a result, I created a DIR structure that holds the windows handle plus the search structure,and it acts as the dirent structure as well. The opendir() allocates and returns this structure and sets a flag. readdir() checks the flag on first call and takes the already existing resultfrom the structure. Otherwise it behaves as expected. Implementing this at a higher level would be quite some trouble AFAICT. At least the current simple model in ros.py would not fit at all. I'm not sure if we should make these matters more complicated. Maybe it will be necessary when we support unicode directories. For now, I just hacked around the needed interface from the C code. It is not that long. But I would have been happier with less C. And I'm especially unhappy that I needed to use malloc. But to avoid this, the opendir() would need to have an interface to pass some memory in, you would need a call to obtain its needed size, ... Please let me know if you see a better solution. For now, it works :-) 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/

2 1

OFFTOPIC (and silly): faked #pypy logs
by Carl Friedrich Bolz Oct. 22, 2005

Oct. 22, 2005

Hi pypy-dev, just a bit of playing around: This afternoon I wrote a small script that randomly creates texts out of statistics collected from some input data using markov chains. It got especially funny (and quite absurd) when I took the logs of #pypy as data. Look here for an example: http://codespeak.net/~cfbolz/log.txt There are some really funny parts in there: <stakkars> I stinglike some for things like calling and how being an EU point there was on them... <arigo> makes sense. <stakkars> I said I won't have them in the results probably a question? <pedronis> if you know if we work is a dirt regression test or available <arigo> sorry for the whole lltype or: <hpk> well, profiler too, Christian to believe that something for which test? <mwh2> oh good to know <pedronis> I'm going to write a ll helper The code is here: http://codespeak.net/svn/user/cfbolz/python/random_markov.py Cheers, Carl Friedrich

1 0