Mailman 3 May 2003 - pypy-dev

we need an irc meeting about the G�teborg Sprint soon.
by Laura Creighton 20 May '03

20 May '03

Tomorrow at 1900? Laura

4 3

Re: [pypy-dev] we need an irc meeting about the Göteborg Sprint soon.
by Laura Creighton 20 May '03

20 May '03

In a message of Tue, 20 May 2003 14:52:06 +0200, holger krekel writes: >[Laura Creighton Tue, May 20, 2003 at 02:46:34PM +0200] >> Tomorrow at 1900? > >If you want to use the sprint list just drop me the list >of participants and i'll set it up today. We should do this >for the Belgium-sprint anyway. > > holger In Göteborg: Armin, Christian, Michael, Tomek, Jacob and I will be returning. Add Anders Hammerquist iko(a)strakt.com, Alex Martelli aleaxit(a)yahoo.com, Anna Ravenscroft rev_anna_r(a)yahoo.com, and Samuele Pedroni pedronis(a)bluewin.ch In Belgium: Add yourself, Dinu, and Guido van Rossum (guido(a)python.org) Who else is coming? Have I forgotten anybody? Can Jens-Uwe make it? Laura

2 1

Re: Re: [pypy-dev] we need an irc meeting about the Göteborg Sprint soon.
by Laura Creighton 20 May '03

20 May '03

In a message of Tue, 20 May 2003 16:17:32 +0200, Christian Tismer writes: >Laura Creighton wrote: >... >> In Belgium: >> >> Add yourself, Dinu, and Guido van Rossum (guido(a)python.org) >> >> Who else is coming? Have I forgotten anybody? Can Jens-Uwe make it? > >And add me, of course. > >ciao - chris > >-- >Christian Tismer :^) <mailto:tismer@tismer.com> >Mission Impossible 5oftware : 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 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 >PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 > whom do you want to sponsor today? http://www.stackless.com/ Ahh, I meant in _addition_ to those on the Göteborg list .... I wasn't forgetting you ... Laura

1 0

Re: Extending the ObjectSpace Concept
by roccomoretti＠netscape.net 19 May '03

19 May '03

Armin Rigo <arigo(a)tunes.org> wrote: >On Sun, May 04, 2003 at 04:17:34PM -0400, Rocco Moretti wrote: >> I think it may be worthwhile to extend the concept of Object Spaces to the >> bytecode and sourcecode levels. (Provisional names: BytecodeSpace and >> SyntaxSpace.) > >Ok. It makes sense. I should write a bit more about what I intended to use >ObjectSpaces for, though, and see how explicit Bytecode/Syntax spaces fit >in the picture. I promize I'll. In particular, I don't think about >ObjectSpaces as controlling spaces, as you do, so there is some idea >matching to do there >:-) I think I may have not been clear on this point. I now think "controlling" is too strong a word. What I meant to imply is that the Spaces are the codification of abstrace concepts, and are on a somewhat equal footing in that regards. However, in an inheratance fashion, the ObjectSpaces are somewhat "superior" to either the Bytecode or SynataxSpaces in that you can swap out the Bytecode or SyntaxSpace without much change, if any, to the ObjectSpace, but if you rewrite the ObjectSpace, the Bytecode and SyntaxSpaces need updating to accomidate the change. Where "control" comes in can somewhat be seen in the bootstrapping of the intrpreter. This is how I imagine it working (in pseudocode - method names are descriptive only): #script is a file containing the script to run w_str = ObjectSpace.to_string(script.read()) #ObjectSpace contains a reference to a SyntaxSpace to use to compile # the string w_code = ObjectSpace.compile(w_str) #w_code is the script's code object #ObjectSpace contains a reference to the BytecodeSpace to use to run # this code object ObjSpace.execute_code(w_code) The script is converted to an application level string first because I imagine we would want to write the compiler in the application level (and so the input string would need to be converted anyway.) The ObjectSpace "controls" in that Bytecode objects and input Strings are Objects, and their semantics are controled by the ObjectSpace. (Part of those semantics being what happens when you run or compile those objects.) >> If accepted, one change that should be made is to shift the function call >> semantics in the object space to have an explicit execution context as a >> parameter, so that it is clear that the ObjectSpace is controling >> execution. > >That's not clear, because almost any other operation could indirectly do a >function call (e.g. hash() calling the class' __hash__() method). Good point. An alterior motive in keeping the execution context explicit is that it eliminates that implicit global, and makes multiple threads less headache provoking. Is there a good way of keeping the execution context explicit? Or another possibility: do we need to maintain the same execution context when calling implementing methods? (e.g. spawn a new execution context when starting the __hash__() method call.) I'm not too familiar with it, but I recall hearing that originally Smalltalk was to have the implementation of each object be in a seperate thread. (Hence the Smalltalk terminology "message passing" as opposed to "calling a method function".) > >> (...) __import__(). However, in order to do so, __import__() needs >> to be able to call out to interpreter level python functions. With the >> current TrivialObjectSpace, that's impossible as all python functions are >> run through the pypy interpreter. > >Yes; we miss a way to call interpreter-level functions from >application-level ones (the CPython's "builtin function objects"). Exactally. Except that for CPython, "builtin function objects" are written in C, and for PyPy, they can be written in either C or Python. >We could take a broader point of view here, and use the separation between >function objects and code objects. We could have several types of code >objects, each one corresponding to a kind of function that you list: >bytecodes, built-in (i.e. interpreter-level), compiled machine code... The >(single) function object type would have the role of the interface, allowing >introspection -- which is a nice thing to have, CPython's built-in functions >lack that -- whereas the various code object types would correspond to the >various ways of implementing a function. Come to that, these ways could be >tied to various BytecodeSpaces -- a concept we could rename ExecutionSpace, >maybe ? As I mentioned, I'm not tied to the names - they were just something to start from. That said, I do agree that "ExecutionSpace" does a better job of capturing the true sense of what they are than "BytecodeSpaces" does. >Executing a function object would then be done by collecting the arguments >based on the signature (which would be published in the function object), >which would result, say, in a single dictionary (the "locals"); then we call >"f.func_code.execute(globals, locals)". > >What do you think about it ? Sounds sensable. However, this proposal seems to go beyond reworking the internals and crosses into redesigning the user interface. (Which was something we were avoiding, if I remember correctly.) Properly reworked, though, it may be a worthwhile thing to change about CPython, at which point it isn't a redesign. Is this PEP material, or is it destined for a BDFL veto? -Rocco __________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

1 0

Re: Extending the ObjectSpace Concept
by roccomoretti＠netscape.net 19 May '03

19 May '03

Michael Hudson <mwh(a)python.net> wrote: >roccomoretti(a)netscape.net (Rocco Moretti) writes: > >[...] >> Which sort of leads me to the reason I got on this train of thought. Over >> the past couple of weeks I've been trying to fix the remaining bugs in the >> trivial object space. Some of them seem to stem (at least in part) to the >> lack of a separate sys/builtins module for the application level code. (As >> was mentioned earlier by mwh). I've attempted to fix it by special casing >> the builtin __import__(). However, in order to do so, __import__() needs >> to be able to call out to interpreter level python functions. With the >> current TrivialObjectSpace, that's impossible as all python functions are >> run through the pypy interpreter. > >Yes! I ran into this a few weeks back but then forgot exactly what >the issue was :-( Although I don't know exacally the problems you had with your implementation, there are two somewhat different issues that I came across. The first is that any Python function called by interpreted code is also interpreted. This means we can never "escape" to the interpreter level python code. The second is that even if it was possible to call interpreter level functions, an application level __import__() would not have any references to those functions anyway, and so would not be able to call them in the first place. >Are you coming to the sprint in May? Unfortunately, due to my schedule, I cannot. But I wish the best of luck to those who can. -Rocco __________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

1 0

EuroPython 2003 sprints
by Godefroid Chapelle 15 May '03

15 May '03

Hi all, Two sprints (Pypy and Zope3) will be organised on June 22-24 in Louvain-la-Neuve, very near Charleroi. I send you this information so that you can make your rooms reservations. The classrooms are still not definitely confirmed but there should be no problems to get free access to the classrooms on those Sunday, Monday and Tuesday. Still, if you have any money problem, make sure you can cancel without too much expenses. You will find any needed information at http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/EuroPython… Gregoire Weber is taking the lead of the Zope3 sprint organization. I'll be the contact till he comes back from military service at the end of this month. I'd appreciate if the Pypy sprint leader(s) could contact me. -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 18 / 202 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 459901 TVA 467 093 008 RC Niv 49849

1 0

PyPy and Zope3-Sprints before Europython
by Grégoire Weber 07 May '03

07 May '03

Hi people, I'm organizing (wich Godefroid, gotcha AT pop.swing DOT be) the Zope3 sprint hold in parallel to your PyPy sprint before the europython conference. Can somebody confirm the dates you planed the sprints: 22 of June to the 24 of june 2003 ? Thanks! Gregoire P.S.: Godefroid will be your contact in the next two and a half weeks, as I have to go to my yearly military service. _____________________________________ Grégoire Weber Rigistr. 31 CH-8006 Zürich Switzerland phone: +41-(0)1-361 66 11 mobile: +41-(0)79-44 11 457 mailto:gregoire.weber@switzerland.org

1 0

Extending the ObjectSpace Concept
by roccomoretti＠netscape.net 06 May '03

06 May '03

I think it may be worthwhile to extend the concept of Object Spaces to the bytecode and sourcecode levels. (Provisional names: BytecodeSpace and SyntaxSpace.) Just as an ObjectSpace embokdies the abstract concept of the semantics of objects and their interactions, a Bytecode space embodies the concept of the bytecode and its effect on execution flow control. Likewise, a SyntaxSpace embodies the abstract concept of the textual program and its mapping onto bytecode and object definitons. Now, these spaces are distinct, but they are not independant. The SyntaxSpace needs to know which BytecodeSpace and ObjectSpace to use to output functions and objects, a BytecodeSpace needs to know what ObjectSpace to use to implement object interactions, and an ObjectSpace needs to have some idea about SyntaxSpaces and Bytecode spaces so that it can compile strings and execute functions. As I imagine it currently, the ObjectSpace will be the controlling space. A string or file is given to the ObjectSpace to execute. It passes the string to the SyntaxSpace, which then compiles it into a number of ObjectSpace objects, including module, function and code objects. The object space then executes those functions by passing them to the appropriate BytecodeSpace. In the process of execution, the BytecodeSpace then calls back to the ObjectSpace to implement the object semantics. Note that there is a distinction between BytecodeSpaces and the an ExecutionContext, in that each BytecodeSpace would have singleton semantics, but there can be multiple different ExecutionContexts. (Perhaps it could be as simple as a class/instance distinction.) Perhaps the Bytecode/Syntax Spaces don't need to be actual entities, but could stay as abstract concepts. If accepted, one change that should be made is to shift the function call semantics in the object space to have an explicit execution context as a parameter, so that it is clear that the ObjectSpace is controling execution. Which sort of leads me to the reason I got on this train of thought. Over the past couple of weeks I've been trying to fix the remaining bugs in the trivial object space. Some of them seem to stem (at least in part) to the lack of a separate sys/builtins module for the application level code. (As was mentioned earlier by mwh). I've attempted to fix it by special casing the builtin __import__(). However, in order to do so, __import__() needs to be able to call out to interpreter level python functions. With the current TrivialObjectSpace, that's impossible as all python functions are run through the pypy interpreter. As I see it, there are two simultaneous execution "threads" running through the interpreter. The host interpreted "interperter level" functions, and the pypy interpreted "application level" functions. The host interperter takes care of the first, so I'll deal with the second. You can split the application level functions into three categories: Application Space Functions: Python functions which should be run under the pypy interpreter. (i.e. User code) Interpreter Level Python Functions: Functions written in Python which need to be run on the host interpreter. These are functions which are called from and return to user code. (Like a special cased __import__()). Builtin Functions: Compiled code, to be run on the processor itself. Currently, we don't make a distinction between the two types of Python functions - we do exclusively Application Level functions. To do this we need to distinguish between the two. Therefore I propose that even in the TrivialObjectSpace we have special function objects. These can be just a simple wrapper around the host function objects to mark them as Application Level functions, as opposed to the unwrapped Interpreter Level functions. I think the wrapping can easily be accomplished in the MAKE_FUNCTION opcode. Does any of this sound reasonable? I tried to explain it well, but I'm quite sure I failed, so if you have any questions, please ask. -Rocco __________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

3 2

Linking to the web page
by Armin Rigo 06 May '03

06 May '03

Hello, I've had feedback from someone not finding Pypy's web pages. He says the mailing list page is showing up in a Yahoo search but not the http://codespeak.net/pypy/. Can someone please add a link to the latter from the former ? Thanks ! Armin

1 0