Mailman 3 March 2003 - pypy-dev

Re: [pypy-dev] subversion
by roccomoretti＠netscape.net March 2, 2003

March 2, 2003

Christian Tismer <tismer(a)tismer.com> wrote: >Despite the fact that the wiki page does not list >TortoiseSVN (should it do this now? I htink it is more >stable), I'm very happy with it, since it sicely >adds itself as a shell extension and shows the file >status as you look into your folders with explorer: >http://codespeak.net/~jum/TortoiseSVN-0.6.msi Pardon my ignorance, but what is an .msi file and how does one use it? -Rocco … [View More]

2 1

Fork lib?
by logistix March 2, 2003

March 2, 2003

This brief interactive session scares me a little. ---START CONSOLE TEXT--- Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\grant>cd \python22\lib\site-packages\pypy\interpreter C:\Python22\Lib\site-packages\pypy\interpreter>python interactive.py Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] in pypy PyPyConsole / TrivialObjSpace >>> import sys >>> sys.path ['', 'C:\\Python22\\lib\\site-… [View More]

1 0

stdobjspace summary?
by Armin Rigo March 2, 2003

March 2, 2003

Hello everybody, As I won't read my mail during the whole next week I thought it might be helpful if I attempted some kind of summary. It collects numerous ideas posted here (recently or not) and a bit of personal feelings. I hope it might help in getting some distance over what we are actually trying to do with our "standard object space". I am afraid it is all very vague, but should be kept in mind before we actually design something new there. The std/ directory is the "space of compliant … [View More]Python object implementations", as opposed to non-compliant object spaces which do some more funny things while the interpreter follows the bytecode. It collects various implementations for the same user types, which are based on some lower-level abstractions. The abstractions that are used are explicitely described in each file, for example: N-bits or machine-sized signed or unsigned integers; memory blocks with explicit management; bitfield objects; various hints (e.g. "this implementation should not be used with refcounts because it has many circularities"); or even which "RPython level" we use (if we develop more and more complex translators), including what basic type operations we allow. Then each low-level abstraction itself has a reference implementation in Python, like Christian's r_int; this should be put in a file that can easily be associated to alternate implementations of the same concept, the ones that can be used by the translator (like the description of the C 'int' type and the tedious complexities of overflow detection in C). These low-level implementations can also explicitely depend on other low-level implementations: for example, "C lists with stored length" could be implemented in term of malloc-style memory blocks -- as opposed to "lists as Java arrays" which don't go lower-level because the length is always stored in Java arrays. "Above" all these files, we have several compliant object spaces, whose purpose is to link a selection of implementations together. For testing purposes object spaces should be easy to build and run in Python, thanks to the Python reference implementations of low-level abstractions. On the other hand, the "C object space" links some or all the files which are (indirectly) based on C-implemented low-level abstractions only; this is what the translator will input. Which files an object space depends on should be specified declaratively, in such a way that we can actually use this information to implement the "wrap", "newlist", "newstring",... methods of the object space. These are the functions that build W_XxxObject instances of the basic types from scratch. Let me stress again that the maximum flexibility seems to be to allow each concept to be implemented in possibly several ways above lower-level concepts, including new ones if the existing ones don't suit you. The arguments on the mailing list show nicely enough that there is just no single better way to implement things, so we should just allow them all to coexist[1]. After that, *other* files are responsible for putting the pieces together -- explicitely (listing the files to include), implicitely (automatically searching for implementations that meet some requirements), or even dynamically at run-time to optimize the performances (not easy, but at least it should be *possible*)! [1] is a departure from one of Python's moto: "there is one and only one obvious way to do something". Well, I assume that I won't shock people around here if I say I never liked this one :-) A bientôt, Armin. [View Less]

2 2

Re: [pypy-dev] Re: Base Object library (was: stdobjspace status)
by Armin Rigo March 1, 2003

March 1, 2003

Hello Stephan, On Thu, Feb 27, 2003 at 05:23:44PM +0100, Stephan Diehl wrote: > About object instantiation: > Where excatly is the textual representation of a python object turned into an > object? Is it done by the parser? (for example "12345L" --> 12345L) Damn. I don't know. If we don't include any 'long' type among our allowed RPython types (and we probably don't), then we will have to rethink the way code objects are currently completely put into interpreter-space level. … [View More]

4 6

Re: [pypy-dev] hash negotiation
by Laura Creighton March 1, 2003

March 1, 2003

I think that Armin is left for a week in the outdoors in Finland, and it is probably not a good idea to bbq him in absentia, but that we _have_ to make a C-compliant implementation, or else we will only be viewed as an esoteric weird hobby. But I also don't think that 'futzing around trying to see what we can fool around with' counts as a big permanent commitment to not produce something compatible. It just means we are sloppy with our private object spaces. I've already made one proposal to … [View More]

1 0

Re: [pypy-dev] interface changes (would-have-been: builtin -- gettingstarted)
by Laura Creighton March 1, 2003

March 1, 2003

In a message of Sat, 01 Mar 2003 10:21:33 +0100, "Samuele Pedroni" writes: >From: "Christian Tismer" <tismer(a)tismer.com> >> either by private emails or by an automagic update magic >> from Subversion -- anyway, this doesn't matter so much. > >1) I think the project need a checkins mailing list, I hope that one can >be setup with subversion, >e.g. CPython and Jython projects have one > >2) unless my last email titled 'question' has gone lost, I'm a bit … [View More]

2 1

Re: [pypy-dev] interface changes (would-have-been: builtin -- getting started)
by Laura Creighton March 1, 2003

March 1, 2003

In a message of Sat, 01 Mar 2003 06:55:27 +0100, Christian Tismer writes: >Hi friends, > >as stated in my last message, I think that we suffer from >a lack of "recipies" how to get started, and we are all >eager to do some implementation. > >I'd like to encourage everybody on this list to do get >started, although we are probably defining interfaces >"after the fact". >That menas, you may write something up, but you will >need to be aware that the interface … [View More]might be changed. > >This is not as bad as it sounds, it just means that >you shouldn't worry about the interfaces too much, >instead concentrate on the meat of the implementation. > >Just to give you an example, I just discovered that "my" >integer object happened to change without notice. On >Armin's request, I dropped the "cmp" operator and implemented >rich comparisons. Suddenly, I today see my if-then-else >battery changed into six single functions. This is fine with >me, although I had appreciated some notice about that change, >either by private emails or by an automagic update magic >from Subversion -- anyway, this doesn't matter so much. This scares me a bit. I might write 2 functions one of which depends on the implementation of the other. I know that I should document that, but sometimes I am not really conscious that one depends on the other, until 'the other' changes, and ooops, 'the one' breaks. I'm afraid that this will happen here, plus we may thrash as people commit changes over each others changes because each is persuing an active development strategy which aren't leading to one harmonious whole, but as two different interpretations. Because we can do this, I would like it we started out with a way to load a collection of unit tests, which define 'C-Python- compliant' in such a way that you could develop as follows: (note this this uses make syntax. I am not demanding this, the Scons way, or the A-A-A way are all fine by me - I am using make as an example because I am familiar with it, nothing else) 1. Make a directory -- say trunk/src/pypy/objspace/lacobjspace 2. Copy basic makefile to there from some known location. 3. Then type make getunittests You will get a test suite made which includes all the unit tests we know we have to satisfy to make a compliant object space. This I think should be a bunch of separate files in a directory, not one big file. 4. Then you go get whatever modules you like from trunk/src/pypy/objspace/* and copy them into yoru directory. 5. Then you modify them, and write new ones. Writing new ones means writing new unit tests, which should come first IMHO 6. At some point you decide that you want to contribute your unittests to the project. This may be before you have your objects working exactly right -- the idea is to save the next guy from doing the same work twice even if you are working on different implementations of the same builtin. make donate-unittest unittestfile should work. What is important is that this just adds your unit test to the collection of tests, and doesn't replace somebody else's test. If you think that a test is _wrong_ that is a different matter. We may need a way to specify that in trunk/src/pypy/objspace/lacobjspace we _don't_ want Stephan's double tests15-20, since his doubles are made differently than mine, and those are to test that you get the correct tuple back, and mine aren't tuples at all. 7. At some point, you decide you want to let everybody see and use your code. You post a 'these are now working' note. I don't know if pypy-dev is the correct place for this. It is traditional to have a separate mailing list for checkins, which this sounds like. Maybe we need to use the issue tracker for this, though I like getting mail myself. Old habits and all that. Is this scheme too complicated? Comments, criticism, strongly desired ... Laura [View Less]

1 0