Mailman 3 February 2003 - pypy-dev

IRC chat
by Armin Rigo Feb. 25, 2003

Feb. 25, 2003

Hello again, I think the idea of setting up an IRC channel has been mentioned several times here and at the sprint, but as far as I know nothing concrete occurred. So unless somebody would prefer another server I suggest irc.freenode.net:6667, #pypy. A bientôt, Armin.

3 2

Subversion downtime to implement issue 10
by Jens-Uwe Mager Feb. 24, 2003

Feb. 24, 2003

I will take the subversion server down starting at 14:00 local time for about one hour to implement the following issue: http://codespeak.net/issues/pypy/issue10 This will also move the repository to the data partition, so if you still have file urls in scripts please make sure that these are changed to /data/svn for the main repository or /data/test-svn for the personal and test repositories. -- Jens-Uwe Mager <pgp-mailto:F476EBC2>

3 6

sprint is over, pypy starts
by holger krekel Feb. 23, 2003

Feb. 23, 2003

hello pypy-dev, the sprint is over. It was a pretty intensive and what we think successful week. It proved to be impossible to do daily reports or communicate much with the outside world, sorry. It was hard enough to keep up with what everybody was doing. Watching Twin Peaks in the night didn't help much, either :^) The most interesting result is a somewhat running interactive pypy interpreter which is pretty satisfying. It turned out that the "objectspace" design makes a great lot … [View More]of sense. The concept of dispatching operations on objects to a "library" is already in CPython but PyPy makes this very explicit. There also is an explicit distinction between interpreter-level and application level objects. Whereever possible we work in good old python application space. The interpreter runs with "normal" python, too, but it is even more more explicit in its code and naming. The PyPy-Interpreter only runs on the "trivial" objectspace (dispatching directly to CPython) but we had good progress on doing a "std" objectspace that reimplements all the CPython Types in Python. The "intobject.py" is pretty complete and gives a good example of a conversion from C-Python to Py-Python. When the StdObjSpace is more complete we are eager to generate all kinds of code from it. The first target may be regenerating a python interpreter/core in C-CPython. Those of you familiar with the ceval.c and friends will recognize strong similarities with CPython in http://codespeak.net:8080/svn/pypy/trunk/src/pypy/interpreter/pyframe.py Best of all, we did'nt have big naming, license, PEP308 or coding-style discussions. It's pypy, MIT-license, drop it and http://codespeak.net:8080/svn/pypy/trunk/doc/coding-style.txt This coding-style document was agreed on in much less than one hour which must be a world record, i guess :-) Also we now have "subversion" serving almost all documents and configurations of our project (including the website). We got the server python svn-bindings running so we can directly script all layers of subversion in the future. We refactored parts of our Wiki-code (MoinMoin-based) to have its pages also subversion controled. Although it's not complete you can already edit wiki-pages locally on your machine. I expect website updates to have to wait a bit, though, as most of the sprinters need to catch up with their other activities and slow down a bit. While it is impossible to post a summary of the discussions i guess that these discussions will influence the future development of pypy quite a bit and reflect to the pypy-dev list, of course. Last but not least, we (kind of) fixed another sprint between 20th and 24th of June 2003 right before EuroPython (which is between 25th to 27th). We may do an in-between sprint at beginning of May in Sweden. so much for my little report, have fun, holger [View Less]

1 0

updates
by holger krekel Feb. 21, 2003

Feb. 21, 2003

hello, just updated the website a bit. Apparrently we can't really make the time to post detailed informations about the sprint here. We are having a lot of live discussions and coding and it's hard enough to track them even if you are here at the sprint. Also it's unclear for me if there is enough interest to hear any details from the sprint apart from what we publish on the website (under e.g. Design-Considerations or the subversion-repository). regards, holger

1 0

new website / subversion
by holger krekel Feb. 19, 2003

Feb. 19, 2003

Hello, just a quick note that we updated our website http://codespeak.net/pypy on the second sprint day. There are some visible (content) changes but the real change is that the complete website including the issue-tracker, our modified MoinMoin, the navigation and whatnot is now controled by subversion. We have some more changes pending such as a generated Wiki-Skeleton for an annotated CPython source tree. Here the idea is that we can gather some knowledge about functions/C-files … [View More]

1 0

first code
by Andreas Friedge Feb. 19, 2003

Feb. 19, 2003

first real code can be seen now :) take a look around in the subversion repository with your favorite webbrowser: * http://codespeak.net:8080/svn/pypy/trunk/src/sandbox/interpreter/opcodes.py object space(s) provides implementation of functionality at interpreter level with some mind boggeling help from pure python code at application level that becomes loaded with an dynamic mechanism as seen with various applicationfile.call(...) like in def PRINT_ITEM_TO this dynamically loaded code … [View More]

1 0

about testing
by Laura Creighton Feb. 18, 2003

Feb. 18, 2003

This just out from the gang at Twisted Matrix. Build-bot, an automatic testing service. Produces results like this: http://twistedmatrix.com/~warner.twistd/ I think it is really cool. I wonder if we could adapt it to our purposes. Laura

2 1

RE: [pypy-dev] Object model
by roccomoretti＠netscape.net Feb. 18, 2003

Feb. 18, 2003

Armin Rigo <arigo(a)tunes.org> wrote: >Now I believe in following the idea that CPython's main loop does not assume >anything at all about the PyObjects it manipulates, but does every operation >via calls to library functions like PyNumber_Add(). All it does is moving >PyObjects around, mainly between the stack and the locals. Similarily, our >own main loop should not assume anything about the objects it stores in the >stack and the locals, not even that … [View More]they have some well-known methods. >Instead, we would provide it with the equivalent of PyNumber_Add() & co. I was originally going to say I thought the general-dispatch-function and the standard-object-method-interface options were practically equivalent, but I changed my mind. The reason lies along the concept of multi-methods. (I think that's the right term - functions are polymorphic not just on their first argument (the parent object), but on all arguments.) This may not make much difference on most operations, but it facilitates arithmatic conversion. If we're adding two numbers, we can handle the conversion code in the general Py_NumberAdd routine, instead of spreading it out to the functions implementing float and integers and rationals etc. ... > * wrap(a), taking a *normal* object and putting it into a black box. Its >what the interpreter does for a LOAD_CONST, for example: it has a real Python >object and wants to send it to the object space. For example, if the object >space has a custom implementation "class MyList" for lists, then wrap([1,2,3]) >should create a MyList instance. I wonder whether wrap() and unwrap() are really nessasary - they seem to blur the distinction between interpreter-level and application-object- implementation-level. It seems to me that the LOAD_CONST issue woold be better dealt with by having the compiler/function loader create the black box objects themselves, instead of there being a run-time translation between interpreter-level objects and application-level objects. > * unwrap(x) is the inverse operation. Used by the interpreter in the rare >cases where it really needs to observe the object. For example, for a >conditional jump, after it obtained the truth-value with (say) a call to the >truth() method, it must pull the result out of the object space to know >whether it is really False or True. But how would we handle it if we wanted to redefine what was considered "true"? A generic unwrap couldn't tell what the unwrapped object is being used for. A better way of implementing it would be to look at the specific cases when the interpreter machinery actually cares about the value of the black box object. In the case of conditional branching, it might be best to define a standard function in the ObjectSpace which takes a black-box application-level object and returns an interpreter-level object representing the truth value. (Not a generally "unwrapped" object, specifically 0 or 1 - or rather interpreter-level True and False, depending on how compatible we want to make the the PyPython codebase.) >Looks like a cool point of view, doesn't it ? Very much so, and it interfaces well with the concept of being able to hot-swap bytecodes. (Not only can you change the bytecode semantics of the processor, you can also change the object semantics.) But-first-we-need-a-working-implementation... -Rocco __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ [View Less]

5 5

RE: [pypy-dev] Ideas on pypy architecture (ala tismer)
by sismex01＠hebmex.com Feb. 18, 2003

Feb. 18, 2003

> From: Arman Bostani [mailto:arman@twinsun.com] > Sent: Tuesday, February 18, 2003 1:11 PM > > A long time ago I worked on a Prolog compiler which had the following > design. > > * The system had an abstract machine specification which is analogous > to the Python byte code instructions. > > * There was a second, very low-level instruction set (called progol) > which was essentially a set of macros from which assembly code was > generated. To … [View More]port to a new architecture, new mappings for progol > instructions were defined. > > * The system was able to compile the abstract machine instructions > directly to progol. Also, a Prolog interpreter was written in > progol. > > Now I think Pypy might benefit from a similar architecture. My > suggestion is as follows: > > * Examine the entire C code base and come up with a low-level > instruction set (let's call it pynoth). As above, this instruction > set would be just a bunch of macros but probably translated to C > rather than assembly. > > * Write a semi-automated converter (ala tismer) to translate the > existing C code into pynoth. Perhaps, if the pynoth code > can retain > comments and look semi-decent, the Python gods will accept > to use it > rather than the existing C code base. If not, then we'd have to > retranslate new/modified sources to pynoth as python changes. > > * Develop a psyco-style code generator which generates pynoth instead > of assembly. > > * Over time, we can get rid of the hand-hacked pynoth code and rewrite > much of the system in python. > > -arman > > -- > Arman Bostani 360 N. Sepulveda Blvd. #2055 > Twin Sun Inc. El Segundo, CA 90245 > arman(a)twinsun.com Tel: (310) 524-1800, Fax: (310) 524-1818 > Hello all, I've been lurking around this list for a while, I hope I don't make a complete fool of myself :-) I have only a single question: Why compile to C, when that language has a number of shortcomings which could be eliminated by picking a different target? By "shortcomings", I'm referring to certain aspects of generated code which become inaccesible, simply because C does not facilitate access to those aspects. One of the main aspects I'm talking about is the machine stack. How do you "continue" to another function? How do you inspect the return stack to gain knowledge from the calling sequence to arrive to a certain execution point? I've been playing a bit (emphasis on "playing", nothing serious yet) with forth, and the language itself provides easy access to the machine stack, without having to resort to strange contortions or inline assembly. Continuations and co-routines are written in some 20 lines (simple implementations), without requiring access to mind-bending hacks. Of course, many might say that Forth is *like* inline assembly in some aspects, but the kernel may well be hidden from sight and yet you still retain access to those aspects, normally hidden in C. I'm not advocating Forth as an intermediate language, it's plenty wierd, mostly I'm questioning C's use. Any comments on the following are plenty appreciated. Thanks. -gustavo [View Less]

1 0

Ideas on pypy architecture (ala tismer)
by Arman Bostani Feb. 18, 2003

Feb. 18, 2003

A long time ago I worked on a Prolog compiler which had the following design. * The system had an abstract machine specification which is analogous to the Python byte code instructions. * There was a second, very low-level instruction set (called progol) which was essentially a set of macros from which assembly code was generated. To port to a new architecture, new mappings for progol instructions were defined. * The system was able to compile the abstract machine instructions … [View More]

1 0