From tismer at tismer.com Sat Mar 1 05:59:38 2003 From: tismer at tismer.com (Christian Tismer) Date: Sat, 01 Mar 2003 05:59:38 +0100 Subject: [pypy-dev] stdobjspace summary? In-Reply-To: <20030228195346.7D61C5261@bespin.org> References: <20030228195346.7D61C5261@bespin.org> Message-ID: <3E603E3A.9050506@tismer.com> Armin Rigo wrote: > 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. [snipped all the goodies] Thanks for the nice summary. I see that you might have different opinions, but you accept that there is the possibility to allow different opinions to coexist, since we don't target to the one-size-fits-all concept, that CPython is restricted to by nature. I think this is a wise decision, since this allows us to continue without having to fight about peanuts issues: Assuming that I insist on naked memory arrays, neglecting any built-in array operations, I can build a worthwile list implementation. At the same time, you may prefer to assume more builtin flexibility and implement arrays in Java-style, either on top of my primitive assembly-like layer with ease, or just by ignoring it. Both ways are OK for me. I would just like to write my implementation now, in the way I think about it, and I'm open to either wrap it later on top, or to modify it for "the new standard" or whatever. I just don't think that this will change the "meat of the implementation", which is not just wrappers around builtin lists, but that implements hairy stuff like sorting, dynamic allocation size decisions, and more. Well, because you are not available next week, please let me ask some questions, in order to avoid too much diversification and less later work to get towards the yet not well-defined target: Assuming I would implement a tuple/list type, what would you prefer: An implementation that uses lists just to denotate a malloc'ed piece of memory, therefore explicitly maintaining actlen and maxlen, or more of the notation of a Java array? (Which I guess) Which are the allowed basic operations assumed to be available? If there were two different implementations, one in terms of plain memory chunks, and one in terms of Java arrays, how would they be split? Is there one interface file in std, which configures itself by some global options and some local include, or would there be a std_c and a java folder? As Stephan pointed out in private emails, he actually is in favor of not doing a long implementation at all, but to link against an external library. This is personal taste which we should provide space for. Where do you think this space should live? And if I pefer to do "real longs", since I'm the earth-bound, hack-all-or-nothing guy, where should I put my stuff? Should I create more specific folder names? Do the STD objects generally turn themselves into just interfaces, which redirect to something else by some means of config files? Assuming that I'm going to implement some basic string type, to you prefer to have this done using builtin Python strings? Of course, I'd use them for constants, like the C strings, but then, when I implement them as basic types, I'm thinking to build them either upon array.array("c","abc") (less likely, since array is not favored by Guido, and seems to not support unicode), or by some restricted list class (ouch!), again. This list class would be meant as a plain memory interface, allowing no list-level operations like "+", len, append or such, just creation, indexing and element assignment, and the implementation would pretty much resemble the current C imple- mentation. So the underlying primitive list would be restricted to able to hold single chars and None, only. This is, as stated in earlier, less coherent emails, just a way to express what the primitive type *cannot* do, in order to let the restricted base list object be error-checked interpreted by CPython, *and* be an easy target for a simple compiler to C. The W_Stringobject class would take care of everything a string can do, by providing every string function that CPython has as well. If I implement things this way, I think it will be more than easy to generate C code, even for a simple mind like mine. If you are uneasy with my way to tackle this, I have no problems if somebody rewrites the stuff in slightly higher level style, or if (s)he wraps it up, claiming "this is the Java level implementation". No problem. But allowing for this allows me to write what I want to write, right now. What I'm just asking for is just how I should put it where, in which directory, with which file naming conventions. I think it's more efficient to just let me keep going in some way, than to let me get stuck in some general interface/ /principle discussion, which is neither my point nor my strength. There is another issue concerning builtins and similar stuff, where we also still have no coherent interface for, and I'm going to propose a simple-minded approach, just to get people like me started. Will write that up in another thread. thanks for your patience with the ancient hacker -- chris -- Christian Tismer :^) 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/ From tismer at tismer.com Sat Mar 1 06:55:27 2003 From: tismer at tismer.com (Christian Tismer) Date: Sat, 01 Mar 2003 06:55:27 +0100 Subject: [pypy-dev] interface changes (would-have-been: builtin -- getting started) Message-ID: <3E604B4F.3000902@tismer.com> 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 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. What does matter a bit is that we don't have a general policy about interfaces, and that these appear to be changed from time to time, without notice. I think it would be nice not to change such things without notice, but to post a request for interface change to the PyPy list, and maybe doing the change after some confirmation. Essentially, this project is not owned by a few people, but this is a community effort. If this is not going to be a basic principle, I'd like to know, and to be able to decide on myself, if I want to continue to contribute. Open source is a nice thing, but I do think that there should be some "netiquette" about changing "anyone's code". At least, a notice of change is required. I don't believe that we should adopt a concept of "godfathers" who are allowed to mess with everything without at least owing the authors some measures of a note! Actually, I wanted to give some hints about contributing to builtins, but unfortunately that change distracted me from the point, so I'm going to write yet another posting, to get at the point. cheers - chris -- Christian Tismer :^) 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/ From lac at strakt.com Sat Mar 1 07:29:32 2003 From: lac at strakt.com (Laura Creighton) Date: Sat, 01 Mar 2003 07:29:32 +0100 Subject: [pypy-dev] interface changes (would-have-been: builtin -- getting started) In-Reply-To: Message from Christian Tismer of "Sat, 01 Mar 2003 06:55:27 +0100." <3E604B4F.3000902@tismer.com> References: <3E604B4F.3000902@tismer.com> Message-ID: <200303010629.h216TWjL005348@ratthing-b246.strakt.com> 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 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 From pedronis at bluewin.ch Sat Mar 1 10:21:33 2003 From: pedronis at bluewin.ch (Samuele Pedroni) Date: Sat, 1 Mar 2003 10:21:33 +0100 Subject: [pypy-dev] interface changes (would-have-been: builtin -- gettingstarted) References: <3E604B4F.3000902@tismer.com> Message-ID: <003201c2dfd3$f422a580$6d94fea9@newmexico> From: "Christian Tismer" > 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 worried given that it didn't receive any kind of answer, even as short as 'no' ... From lac at strakt.com Sat Mar 1 10:22:47 2003 From: lac at strakt.com (Laura Creighton) Date: Sat, 01 Mar 2003 10:22:47 +0100 Subject: [pypy-dev] interface changes (would-have-been: builtin -- gettingstarted) In-Reply-To: Message from "Samuele Pedroni" of "Sat, 01 Mar 2003 10:21:33 +0100." <003201c2dfd3$f422a580$6d94fea9@newmexico> References: <3E604B4F.3000902@tismer.com> <003201c2dfd3$f422a580$6d94fea9@newmexico> Message-ID: <200303010922.h219MljL005881@ratthing-b246.strakt.com> In a message of Sat, 01 Mar 2003 10:21:33 +0100, "Samuele Pedroni" writes: >From: "Christian Tismer" >> 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 worried >given that it didn't receive any kind of answer, even as short as 'no' > I always envisioned that the final low-level runtime would support multi-dispatching dynamically, but I don't know if that was ever explicitly decided, or if that is just a 'prejudice' or 'habit of thinking' of mine which conceivably nobody else shares and which didn't get examined. Thank you for turning on the flashlight. If we made consensus, that would have been done on the first 2 days of the sprint which I missed, so I don't know. Laura Creighton From pedronis at bluewin.ch Sat Mar 1 11:34:47 2003 From: pedronis at bluewin.ch (Samuele Pedroni) Date: Sat, 1 Mar 2003 11:34:47 +0100 Subject: [pypy-dev] interface changes (would-have-been: builtin -- gettingstarted) References: <3E604B4F.3000902@tismer.com> <003201c2dfd3$f422a580$6d94fea9@newmexico> <200303010922.h219MljL005881@ratthing-b246.strakt.com> Message-ID: <010401c2dfde$2e807720$6d94fea9@newmexico> From: "Laura Creighton" > I always envisioned that the final low-level runtime would support > multi-dispatching dynamically, but I don't know if that was ever > explicitly decided, or if that is just a 'prejudice' or 'habit of > thinking' of mine which conceivably nobody else shares and which > didn't get examined. Thank you for turning on the flashlight. If we > made consensus, that would have been done on the first 2 days of the > sprint which I missed, so I don't know. I was asking because: - dispatch and lookup are part of the skeleton (together with mem mgmt etc) of an implementation, other issues are more local/internal to the single object types - for some possible execution substrates (Java, ObjC) dynamic multi-dispatch at runtime is not "natural" - on this depends how in PyPy support for subclassing of built-in types (class myint(int): ...) should be expressed From mwh at python.net Sat Mar 1 12:02:08 2003 From: mwh at python.net (Michael Hudson) Date: Sat, 01 Mar 2003 11:02:08 +0000 Subject: [pypy-dev] Re: interface changes (would-have-been: builtin -- gettingstarted) References: <3E604B4F.3000902@tismer.com> <003201c2dfd3$f422a580$6d94fea9@newmexico> Message-ID: <2m3cm7xscv.fsf@starship.python.net> "Samuele Pedroni" writes: > 1) I think the project need a checkins mailing list, Yes! People should probably also be more verbose in their checkin comments. Cheers, M. -- First of all, email me your AOL password as a security measure. You may find that won't be able to connect to the 'net for a while. This is normal. The next thing to do is turn your computer upside down and shake it to reboot it. -- Darren Tucker, asr From jum at anubis.han.de Sat Mar 1 13:22:17 2003 From: jum at anubis.han.de (Jens-Uwe Mager) Date: Sat, 1 Mar 2003 13:22:17 +0100 Subject: [pypy-dev] interface changes (would-have-been: builtin -- gettingstarted) In-Reply-To: <003201c2dfd3$f422a580$6d94fea9@newmexico> References: <3E604B4F.3000902@tismer.com> <003201c2dfd3$f422a580$6d94fea9@newmexico> Message-ID: <20030301122217.GA732@ANUBIS> On Sat, Mar 01, 2003 at 10:21 +0100, Samuele Pedroni wrote: > From: "Christian Tismer" > > 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 The script is in place already, but we need a new mailing list in mailman for that. Holger, what about a pypy-checkins mailing list? I have forgotten the mailman admin password. :-( -- Jens-Uwe Mager From tismer at tismer.com Sat Mar 1 19:25:41 2003 From: tismer at tismer.com (Christian Tismer) Date: Sat, 01 Mar 2003 19:25:41 +0100 Subject: [pypy-dev] question In-Reply-To: <013c01c2de4e$dc64bcc0$6d94fea9@newmexico> References: <20030224164413.51465501B@bespin.org><200302261009.h1QA9Jc23764@trixie.triqs.com> <3E5CDEA1.7080401@tismer.com><200302261639.h1QGdoc26254@trixie.triqs.com> <3E5D0B74.7030709@tismer.com> <20030227104435.GA30494@magma.unil.ch> <013c01c2de4e$dc64bcc0$6d94fea9@newmexico> Message-ID: <3E60FB25.2010406@tismer.com> Samuele Pedroni wrote: > I admit for now I have just skimmed over the code. > > I can more or less see how something like classic-style classes can be > implemented. > > Have you already thought on how to implement new-style classes and in > particular built-in types subclassing like in: > > class myint(int): > ... > > e.g. will the implemented multi-dispatching intepreted statically at PyPy > static translation time ... or should the final low-level runtime support it > dynamically? Speaking for myself, I always have wondered how the multimethod approach should be extended above the level of builtin types, since I don't understand how to extend it to derived types, without breaking compatibility to all the established __xxx__ rules in Python. I pointed to this problem on the sprint, but can't remember that this issue was solved. One vague idea could be that derived types by default inherit the multi-method dispatch, but when people override operators, we have to provide some compatible interpretation of things like __add__(self, other), or this would not be Python. Maybe we can find the necessary magic to embed this into multimethod dispatch dynamically, but I have really no clue how this should work. ciao - chris -- Christian Tismer :^) 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/ From tismer at tismer.com Sat Mar 1 20:01:18 2003 From: tismer at tismer.com (Christian Tismer) Date: Sat, 01 Mar 2003 20:01:18 +0100 Subject: [pypy-dev] hash negotiation Message-ID: <3E61037E.3050504@tismer.com> Hi, additional to an integer change, I also saw a change of the hash implementation: def int_hash(space, w_int1): #/* XXX If this is changed, you also need to change the way # Python's long, float and complex types are hashed. */ ## x = w_int1.intval ## if x == -1: ## x = -2 ## return W_IntObject(x) # XXX unlike CPython we have no need to special-case the value -1 return w_int1 I intentionally repeated CPython's implementation, which special cases -1 as an indicator for "no hash computed yet". It may negotiable whether we want to preserve an extra flag in all the hashable objects whether the hash has been computed, or repeat CPython's way to preserve a single value for this. This is a part of CPython's object protocol, and I believe we *have* to decide about this together. It cannot be our style just to remove something without notice. How hashes are computed has two impacts which we need decide upon: - If we aim at CPython compatibilty at some time, we might keep the door open to do exactly the same here. - If we want to provide *functional* compatibility with CPython's hash values, then we need to provide exactly the same values, or programs relying on hash values will behave differently. I have no problem to have different implementations, it might even make sense to add a config variable, how compatible we want to be. But since hash() is an exposed function, we need at least be aware when we change something visible, and we need to express whether we care about that or not. Obviously, my default way of doing things "when in doubt, then do what the C code does" isn't shared by Armin. Creating an almost CPython compatible implementation was one of the targets from the beginning, and I don't remember that we have dispensed of possible targets, already. So I'd like to ask for your opinions about stuff like that. cheers - chris -- Christian Tismer :^) 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/ From tismer at tismer.com Sat Mar 1 20:08:43 2003 From: tismer at tismer.com (Christian Tismer) Date: Sat, 01 Mar 2003 20:08:43 +0100 Subject: [pypy-dev] hash negotiation In-Reply-To: <3E61037E.3050504@tismer.com> References: <3E61037E.3050504@tismer.com> Message-ID: <3E61053B.6000206@tismer.com> On that hash issue: I just changed intobject.py and added two versions of hash(), one strict and one liberal version, just to have it there and remember us that we have to decide how to handle this. Please have a look and tell me what you think. cheers - chris -- Christian Tismer :^) 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/ From robin at reportlab.com Sat Mar 1 20:10:03 2003 From: robin at reportlab.com (Robin Becker) Date: Sat, 1 Mar 2003 19:10:03 +0000 Subject: [pypy-dev] subversion In-Reply-To: <3E60FB25.2010406@tismer.com> References: <20030224164413.51465501B@bespin.org> <200302261009.h1QA9Jc23764@trixie.triqs.com> <3E5CDEA1.7080401@tismer.com> <200302261639.h1QGdoc26254@trixie.triqs.com> <3E5D0B74.7030709@tismer.com> <20030227104435.GA30494@magma.unil.ch> <013c01c2de4e$dc64bcc0$6d94fea9@newmexico> <3E60FB25.2010406@tismer.com> Message-ID: Can someone knowledgeable spend a few moments explaining what people need to do to use subversion? Does it work on windows etc etc? -- Robin Becker From lac at strakt.com Sat Mar 1 20:09:00 2003 From: lac at strakt.com (Laura Creighton) Date: Sat, 01 Mar 2003 20:09:00 +0100 Subject: [pypy-dev] hash negotiation In-Reply-To: Message from Christian Tismer of "Sat, 01 Mar 2003 20:01:18 +0100." <3E61037E.3050504@tismer.com> References: <3E61037E.3050504@tismer.com> Message-ID: <200303011909.h21J90jL008077@ratthing-b246.strakt.com> 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 make that sloppiness less of a problem, but so far, no comments here, except that a checkins list would be a good idea. Right now I would like a bit of guidance from somebody on what would you like me to work on, and some guarantees that when I do it I won't stomp over somebody else's work by mistake and clumbsiness. I'd like help in building a little more order around here, because though I want more order, I don't want to impose my order, because it is anti-social, as well as for the pragmatic reason that I am not sure that my proposed new way of ordering is actually a good idea. I am strongly pro- 'more order, less chaos' and only a tiny bit pro my idea for fixing this. Laura From tismer at tismer.com Sat Mar 1 20:33:18 2003 From: tismer at tismer.com (Christian Tismer) Date: Sat, 01 Mar 2003 20:33:18 +0100 Subject: [pypy-dev] subversion In-Reply-To: References: <20030224164413.51465501B@bespin.org> <200302261009.h1QA9Jc23764@trixie.triqs.com> <3E5CDEA1.7080401@tismer.com> <200302261639.h1QGdoc26254@trixie.triqs.com> <3E5D0B74.7030709@tismer.com> <20030227104435.GA30494@magma.unil.ch> <013c01c2de4e$dc64bcc0$6d94fea9@newmexico> <3E60FB25.2010406@tismer.com> Message-ID: <3E610AFE.7070100@tismer.com> Robin Becker wrote: > Can someone knowledgeable spend a few moments explaining what people > need to do to use subversion? Does it work on windows etc etc? You can find a windows installer here: http://codespeak.net/~jum/ The current command line version is http://codespeak.net/~jum/svn-0.18.0-r4973-2-setup.exe 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 If you are using Windows 2000, you need to install service pack 3 for SVN. To check out the current source trunk, use something like svn co http://codespeak.net:8080/svn/pypy/trunk d:/pypy You can always update using Tortoise or the command line, being in d:/pypy and doing svn up cheers - chris -- Christian Tismer :^) 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/ From tismer at tismer.com Sat Mar 1 21:21:36 2003 From: tismer at tismer.com (Christian Tismer) Date: Sat, 01 Mar 2003 21:21:36 +0100 Subject: [pypy-dev] Re: Base Object library (was: stdobjspace status) In-Reply-To: <20030227212853.J11666@prim.han.de> References: <20030224164413.51465501B@bespin.org> <20030227144128.5EA76502E@bespin.org> <20030227155346.GC1066@magma.unil.ch> <20030227162309.7C8CC5176@bespin.org> <20030227170102.GB2872@magma.unil.ch> <3E5E6577.2020109@tismer.com> <20030227212853.J11666@prim.han.de> Message-ID: <3E611650.4050401@tismer.com> holger krekel wrote: ... > Marshaled (pypy-) code objects would need to serialize > objectspace dependent types. Maybe we should require all > objectspaces to implement interoperable serialization. > This would also provide a means to transfer objects from > one objectspace to another (and to CPython). I think this makes very much sense, as far as we stick with the opcodes as well. It is possible to change that later, or there are situations where we compile away and don't have such a thing like code objects. But for now having them compatible is essential. > However, I am a bit uneasy about tying pypy too deep to > CPython's codeobject layout. We are likely to want to > extend/modify it the future anyway. So maybe we shouldn't > take CPython-comptability down to the code object . There is one simple interface: The fields of the code object that get marshalled. This is not necesssarily related to the internal layout of this object. Think of how Corba marshals objects, and you transfer them between, say, C and Java. > It's the "heart of gold", produced by the compiler and > driving the interpreter. These are areas where we want > maximum flexibility and thus shouldn't think too much > from CPython's code object which really is more of > an implementation detail than anything else. I think it is worthwhile to be able to run a .pyc file like in CPython, at least until we can compile everything alone. I agree that we might do lots of extensions, later, but why should it be a problem to produce a compatible one for the moment? I don't see that we loose something. As said, code objects are like bytecode, they have a given implementation and a defined external representation. How we transform them internally is a completely different story. ciao - chris -- Christian Tismer :^) 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/ From tismer at tismer.com Sun Mar 2 00:51:41 2003 From: tismer at tismer.com (Christian Tismer) Date: Sun, 02 Mar 2003 00:51:41 +0100 Subject: [pypy-dev] Re: hints about contributing to builtins In-Reply-To: <200303010600.h2160XYp005279@ratthing-b246.strakt.com> References: <200303010600.h2160XYp005279@ratthing-b246.strakt.com> Message-ID: <3E61478D.1080509@tismer.com> Laura Creighton wrote: > I would like some :-) Well, it's really hard to give advice. I have my opinions, which you know are sometimes quite different from other's, and the list seems to be quite quiet on the weekend... There are a couple of open issues when looking into builtins. One of these is btw., that we didn't define a module object, yet, which we really need since builtins is a module. Then, by looking at some simple function in builtinmodule, even more questions are raised: static PyObject * builtin_isinstance(PyObject *self, PyObject *args) { PyObject *inst; PyObject *cls; int retval; if (!PyArg_ParseTuple(args, "OO:isinstance", &inst, &cls)) return NULL; retval = PyObject_IsInstance(inst, cls); if (retval < 0) return NULL; return PyInt_FromLong(retval); } What do we have here? First of all, there is the Python calling convention, that every function call has a self argument, may this be used or not. Builtins doesn't use it at all, so you always can ignore self. But then, what about the arg tuple? I didn't find any definition how this is handled. Well, let me look into the interpreter, there they must have some notation of a function call.............. ...back from there. As far as I can see it, we end up being called like this: w_result = f.space.call(w_function, w_arguments, w_keywords) f.valuestack.push(w_result) (from opcode.py) Now let me dive into objectspace :-) Unfortunately, even the trivial space doesn't run under PythonWin or Boa constructor, so I can't use the debugger. Aha, as it looks right now, we do not distinguish different calling conventions, and we have to deal with something like def builtin_isinstance(*args, **kwds): The problem is then that we don't have PyArg_ParseTuple and friends, yet, and we have not settled down where we can find PyObject_IsInstance implemented. Question: To get things going, should we simply use the given function interfaces from CPython, and code some PyArg_ParseTuple away? Question: Where do we put undefined stuff, when we want to write a module like builtins? Sigh... This seems to be a bit too hard for me, tonight. Maybe someone on the list has an idea how to bootstrap all this stuff? good nite - chris -- Christian Tismer :^) 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/ From arigo at tunes.org Sun Mar 2 08:38:32 2003 From: arigo at tunes.org (Armin Rigo) Date: Sun, 2 Mar 2003 08:38:32 +0100 Subject: [pypy-dev] stdobjspace summary? In-Reply-To: <3E603E3A.9050506@tismer.com> References: <20030228195346.7D61C5261@bespin.org> <3E603E3A.9050506@tismer.com> Message-ID: <20030302073832.GA20805@magma.unil.ch> Hello Christian, In short, write whatever implementation you like most. Using lists are very-dump malloc-style blocks of memory is fine. As you said we can always add intermediate layers later if neccesary. On Sat, Mar 01, 2003 at 05:59:38AM +0100, Christian Tismer wrote: > Which are the allowed basic operations assumed to be available? Only the ones for which you can easily think about a C translation. For example, the list += operator could represent the realloc() primitive. > would they be split? Is there one interface file in std, which > configures itself by some global options and some local include, > or would there be a std_c and a java folder? I don?t know exactly, but I think we should put all this into the same std/ folder because the Java-style implementation can also be used to emit C given the proper translator, so that the boundaries are fuzzy. Maybe you can create subdirectories like std/malloc/ that contain the low-level concepts. In all cases write the dependencies explicitely (we?ll see at that point which syntax could be used for that). > of not doing a long implementation at all, but to link against > an external library. This is personal taste which we should > provide space for. Where do you think this space should live? This could be done in std/xxxlong.py if you are using the library xxx, for which we should also find a syntax. Not sure about strings and builtins yet. The meat of the implementation of strings shouldn't change too much anyway, so I suggest you just try them with any low-level representation you like (strings are fine, if you manage never to need to mutate them). A bientot, Armin. From arigo at tunes.org Sun Mar 2 17:09:01 2003 From: arigo at tunes.org (Armin Rigo) Date: Sun, 2 Mar 2003 17:09:01 +0100 Subject: [pypy-dev] interface changes (would-have-been: builtin -- gettingstarted) In-Reply-To: <003201c2dfd3$f422a580$6d94fea9@newmexico> References: <3E604B4F.3000902@tismer.com> <003201c2dfd3$f422a580$6d94fea9@newmexico> Message-ID: <20030302160901.GB26192@magma.unil.ch> Hello Samuele, On Sat, Mar 01, 2003 at 10:21:33AM +0100, Samuele Pedroni wrote: > 2) unless my last email titled 'question' has gone lost, I'm a bit worried > given that it didn't receive any kind of answer, even as short as 'no' Sorry, I?m short on internet time these days. Multidispatch has been discussed at the beginning, and (in my mind) the scheme that we came up with is that the dispatch is based on the "implementation" of an object, not on its type. All objects of any user-defined type are instances of a single W_UserObject class (say). At this point, users cannot dynamically add new implementations (maybe could be changed later). Example: class W_UserObject: def __init__(w_self, w_basepart, w_usertype): def user_any_add(space, w_userobj, w_otherobj): Armin From pedronis at bluewin.ch Sun Mar 2 17:51:43 2003 From: pedronis at bluewin.ch (Samuele Pedroni) Date: Sun, 2 Mar 2003 17:51:43 +0100 Subject: [pypy-dev] interface changes (would-have-been: builtin --gettingstarted) References: <3E604B4F.3000902@tismer.com><003201c2dfd3$f422a580$6d94fea9@newmexico> <20030302160901.GB26192@magma.unil.ch> Message-ID: <051a01c2e0dc$01802f00$6d94fea9@newmexico> From: "Armin Rigo" > All objects of any user-defined type are instances of a single > W_UserObject class (say). At this point, users cannot dynamically add new > implementations (maybe could be changed later). Given Python semantics it's not even clear that dynamical multi-dispatch at runtime would be a good match, OTOH the issue is open for what will correspond to today 3rd party types defined in dynamically loadable C extensions. Apart from a C/native execution substrate, .NET/Java/Smalltalk/ObjC as candidate execution subtrates offer all/are based on single dispatch so a smooth integration with that can be important. > Example: > > class W_UserObject: > def __init__(w_self, w_basepart, w_usertype): > w_self> > > > def user_any_add(space, w_userobj, w_otherobj): > w_usertype, and if not found, calling add() on w_basepart and w_otherobj> OK, that's what my intuition has thought about the purpose of std/usertype.py I haven't looked yet at exactly what kind of multi-dispatch has been implemented. So I have no further comments for the moment. Only thing (don't know if relevant given what is implemented now) is that it should be possible to emulate also this behavior for the built-ins: >>> 1 .__add__(1) 2 >>> 1 .__radd__(1) 2 >>> 1 .__add__(1.0) NotImplemented >>> 1 .__add__(1L) NotImplemented >>> 1L .__add__(1) 2L >>> 1L .__radd__(1) 2L >>> 1L. __add__ (1.0) NotImplemented >>> 1.0 .__add__(1.0) 2.0 >>> 1.0 .__radd__(1L) 2.0 >>> 1.0 .__add__(1) 2.0 From tismer at tismer.com Sun Mar 2 20:14:25 2003 From: tismer at tismer.com (Christian Tismer) Date: Sun, 02 Mar 2003 20:14:25 +0100 Subject: [pypy-dev] Code review possible? Message-ID: <3E625811.8090102@tismer.com> Howdy, as people have seen me struggling quite much to find out how we should do what which way, with not so much success, I came up with Yet Another Fine Idea(TM): Wouldn't it be the right time to do a code review on the C sources? All of them? I'm thinking of some summary about every C module that I know well (these are many). This would be a listing of functions, what they do, their scope, what the external references are, and how I think this might be rewritten in Python. Having a bigger picture might give a better global result, and such work would also open the CPython source to other people. I'm not yet sure how far this will go, but I think, with a bigger picture of what we have, it is easier to talk about what we need. As far as I remember, Tomek did quite much work with Holger on some XML stuff, somehow there was a connection between the Wiki pages and the C source file planned, is that right? I would like to ask about the status of that sub-project, and if it is already usable for me to start the review thing with it? if-you-don't-know-how-to-write-code,-write-about-code :-) cheers - chris -- Christian Tismer :^) 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/ From pedronis at bluewin.ch Sun Mar 2 20:48:56 2003 From: pedronis at bluewin.ch (Samuele Pedroni) Date: Sun, 2 Mar 2003 20:48:56 +0100 Subject: [pypy-dev] Code review possible? References: <3E625811.8090102@tismer.com> Message-ID: <069f01c2e0f4$c313ec20$6d94fea9@newmexico> my 2cts... I think it is important to try to understand how to recode in Python and then re-emit for the various (1 or more) targets the functionality in: abstract.c object.c typeobject.c funcobject.c moduleobject.c etc that means the glue and skeleton of the object model/runtime; I don't think object spaces as such cover already the whole story, OTOH if for the first try the implementations of int,long,dict,tuple... are simply wrappers around the CPython types, is not too much a problem because is local to the single object types and the details are fixable and one can solve the problem one object type at a time. Also I think the important thing is to be able to run tests. But if don't know how to get 1 .__add__ to behave or lookup/dispatch in general or the content of type("").__dict__ etc right, that's a FAR more serious obstacle. regards. From roccomoretti at netscape.net Sun Mar 2 23:22:15 2003 From: roccomoretti at netscape.net (Rocco Moretti) Date: Sun, 02 Mar 2003 17:22:15 -0500 Subject: [pypy-dev] subversion Message-ID: <7AC72553.72155378.9ADE5C6A@netscape.net> Christian Tismer 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 __________________________________________________________________ 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/ From tismer at tismer.com Sun Mar 2 23:25:25 2003 From: tismer at tismer.com (Christian Tismer) Date: Sun, 02 Mar 2003 23:25:25 +0100 Subject: [pypy-dev] subversion In-Reply-To: <7AC72553.72155378.9ADE5C6A@netscape.net> References: <7AC72553.72155378.9ADE5C6A@netscape.net> Message-ID: <3E6284D5.1080906@tismer.com> Rocco Moretti wrote: > Christian Tismer 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? Microsoft installer. And if you don't know what to do with it, then you probably need service pack 3 for Win2k. ciao - chris -- Christian Tismer :^) 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/ From hpk at trillke.net Mon Mar 3 01:36:02 2003 From: hpk at trillke.net (holger krekel) Date: Mon, 3 Mar 2003 01:36:02 +0100 Subject: [pypy-dev] Re: hints about contributing to builtins In-Reply-To: <3E61478D.1080509@tismer.com>; from tismer@tismer.com on Sun, Mar 02, 2003 at 12:51:41AM +0100 References: <200303010600.h2160XYp005279@ratthing-b246.strakt.com> <3E61478D.1080509@tismer.com> Message-ID: <20030303013602.W11666@prim.han.de> [Christian Tismer Sun, Mar 02, 2003 at 12:51:41AM +0100] > Sigh... > This seems to be a bit too hard for me, tonight. > > Maybe someone on the list has an idea how to bootstrap > all this stuff? first a sidenote. i am extremely busy for computer-unrelated reasons for some days so i am not reading/coding/replying much. Generally i think besides asking good questions it's a good approach to make/code constructive suggestions. (of course quite some people including christian do it already). I believe that to get ideas how things might get done it makes sense to look at the code and then reread some postings :-) cheers, holger From vze55z8s at verizon.net Mon Mar 3 03:37:06 2003 From: vze55z8s at verizon.net (logistix) Date: Sun, 2 Mar 2003 21:37:06 -0500 Subject: [pypy-dev] Fork lib and pythonpath? Message-ID: <000001c2e12d$c8afd660$20bba8c0@XP> First off, apologies if this shows up as a dupe post. I posted via gmane.org about 6 hours ago and it never showed up. 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-packages\\Pythonwin', 'C:\\Python22\\lib\\site-pac kages\\win32', 'C:\\Python22\\lib\\site-packages\\win32\\lib', 'C:\\Python22\\li b\\site-packages', 'c:\\python22\\DLLs', 'c:\\python22\\lib', 'c:\\python22\\lib \\lib-tk', 'c:\\python22'] >>> ---END CONSOLE TEXT--- I'm thinking we should fork the whole lib directory into pypy and have the interpreter's pythonpath point there, bypassing Cpython's pythonpath entirely. I'm trying to get the pure-python bytecode compiler package in order. The python distribution already goes 80% of the way. I've got a plugin replacement for parser.pyd. But where do I stick it so it's found before the pyd? I also want to write a interim version of tokenizer.py. The current version uses regexes. This is the way we should ultimately do it, but a pure python DFA would be nice while dependancies are being worked out (although slow as hell). I could just drop that in the lib directory, but then we're running against a patched version of CPython. The only other alternative is to insert something into pythonpath before any of the standard entries so we can stub stuff in there. Still, if the ultimate goal is to have a standalone pypy interpreter, we're going to need to fork sooner or later. Sooner will allow us to flush out some unanticipated dependancies in the early stages. Of course the downside of doing this is that someone will need to monitor CPython's lib directory and port patches across. It might be a little time consuming, but for now the patches on python-commit should be able to be applied easily. From vze55z8s at verizon.net Mon Mar 3 03:44:31 2003 From: vze55z8s at verizon.net (logistix) Date: Sun, 2 Mar 2003 21:44:31 -0500 Subject: [pypy-dev] Pypy frontend/ testall.py Message-ID: <000101c2e12e$d4523de0$20bba8c0@XP> I've written a small script that'll allow you to run .py scripts via pypy. Ultimately, it'll incorporate all of the functionality of calling 'python' from the command-line. Normally, I'd get some more work done before distributing it, but it is enough to run testall.py in the test directory, so I thought it might be of interest. It should be noted that testall.py fails quite spectacularly, as can be expected at this point, and aborts execution. I piped the results to a logfile, but there were enough errors hitting stderr and bypassing the pipe to make the logfile useless. Interested people can download the script at: http://members.bellatlantic.net/~olsongt/python/pypython.py Save it in your pypy directory and then "pypython.py scriptname.py" should run any python script. -logistix From jim at dsdd.org Mon Mar 3 09:39:13 2003 From: jim at dsdd.org (Jim Meier) Date: 03 Mar 2003 00:39:13 -0800 Subject: [pypy-dev] Pypy frontend/ testall.py In-Reply-To: <000101c2e12e$d4523de0$20bba8c0@XP> References: <000101c2e12e$d4523de0$20bba8c0@XP> Message-ID: <1046680753.10438.0.camel@localhost> On Sun, 2003-03-02 at 18:44, logistix wrote: > It should be noted that testall.py fails quite spectacularly, as can be > expected at this point, and aborts execution. I piped the results to a > logfile, but there were enough errors hitting stderr and bypassing the > pipe to make the logfile useless. In bash, cmd 2>&1 > logfile will catch all the stderr output and merge it with stdout into the logfile. -- Jim Meier From logistix at zworg.com Sun Mar 2 23:09:56 2003 From: logistix at zworg.com (logistix) Date: Sun, 2 Mar 2003 17:09:56 -0500 Subject: [pypy-dev] Fork lib? Message-ID: 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-packages\\Pythonwin', 'C:\\Python22\\lib\\site-pac kages\\win32', 'C:\\Python22\\lib\\site-packages\\win32\\lib', 'C:\\Python22\\li b\\site-packages', 'c:\\python22\\DLLs', 'c:\\python22\\lib', 'c:\\python22\\lib \\lib-tk', 'c:\\python22'] >>> ---END CONSOLE TEXT--- I'm thinking we should fork the whole lib directory into pypy and have the interpreter's pythonpath point there. I'm trying to get the pure-python bytecode compiler package in order. The python distribution already goes 80% of the way. I've got a plugin replacement for parser.pyd. But where do I stick it so it's found before the pyd? I also want to write a interim version of tokenizer.py. The current version uses regexes. This is the way we should ultimately do it, but a pure python DFA would be nice while dependancies are being worked out (although slow as hell). I could just drop that in the lib directory, but then we're running against a patched version of CPython. The only other alternative is to insert something into pythonpath before any of the standard entries so we can stub stuff in there. Still, if the ultimate goal is to have a standalone pypy interpreter, we're going to need to fork sooner or later. Sooner will allow us to flush out some unanticipated dependancies in the early stages. Of course the downside of doing this is that someone will need to monitor CPython's lib directory and port patches across. It might be a little time consuming, but for now the patches on python-commit should be able to be applied easily. From pedronis at bluewin.ch Mon Mar 3 11:42:23 2003 From: pedronis at bluewin.ch (Samuele Pedroni) Date: Mon, 3 Mar 2003 11:42:23 +0100 Subject: [pypy-dev] Fork lib and pythonpath? References: <000001c2e12d$c8afd660$20bba8c0@XP> Message-ID: <00c801c2e171$937270e0$6d94fea9@newmexico> > The only other alternative is to insert something into pythonpath before any > of the standard entries so we can stub stuff in there. that's how we develop in Jython > Still, if the > ultimate goal is to have a standalone pypy interpreter, we're going to need > to fork sooner or later. I don't think that's absolutely necessary. > Sooner will allow us to flush out some > unanticipated dependancies in the early stages. > Of course the downside of doing this is that someone will need to monitor > CPython's lib directory and port patches across. It might be a little time > consuming, but for now the patches on python-commit should be able to be > applied easily. with Jython we have some modules (a small number apart all the built-ins one) that are different from CPython: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jython/jython/Lib/ for the rest when developing we setup the path such that our modules override those in an installed CPython, when we build a distribution we copy the shared modules and merge them with ours in one directory (tree) and then we distribute our modules plus the shared ones. From hpk at trillke.net Mon Mar 3 12:09:03 2003 From: hpk at trillke.net (holger krekel) Date: Mon, 3 Mar 2003 12:09:03 +0100 Subject: [pypy-dev] Pypy frontend/ testall.py In-Reply-To: <000101c2e12e$d4523de0$20bba8c0@XP>; from vze55z8s@verizon.net on Sun, Mar 02, 2003 at 09:44:31PM -0500 References: <000101c2e12e$d4523de0$20bba8c0@XP> Message-ID: <20030303120903.Z11666@prim.han.de> [logistix Sun, Mar 02, 2003 at 09:44:31PM -0500] > I've written a small script that'll allow you to run .py scripts via > pypy. Ultimately, it'll incorporate all of the functionality of calling > 'python' from the command-line. Normally, I'd get some more work done > before distributing it, but it is enough to run testall.py in the test > directory, so I thought it might be of interest. > > It should be noted that testall.py fails quite spectacularly, as can be > expected at this point, and aborts execution. I piped the results to a > logfile, but there were enough errors hitting stderr and bypassing the > pipe to make the logfile useless. > > Interested people can download the script at: > > http://members.bellatlantic.net/~olsongt/python/pypython.py i have just checked in trunk/src/pypy/tools/test_all.py that iterates over the tests in "interpreter". It's not finished but a good starting point. just go there and execute "python test_all.py" (tested only on linux). holger From tismer at tismer.com Mon Mar 3 14:41:08 2003 From: tismer at tismer.com (Christian Tismer) Date: Mon, 03 Mar 2003 14:41:08 +0100 Subject: [pypy-dev] Pypy frontend/ testall.py In-Reply-To: <20030303120903.Z11666@prim.han.de> References: <000101c2e12e$d4523de0$20bba8c0@XP> <20030303120903.Z11666@prim.han.de> Message-ID: <3E635B74.6060807@tismer.com> holger krekel wrote: ... > i have just checked in trunk/src/pypy/tools/test_all.py ^ --------------------------------------------/ I don't believe you adhere to your own renaming rules :-) ciao - chris -- Christian Tismer :^) 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/ From arigo at tunes.org Mon Mar 3 14:50:18 2003 From: arigo at tunes.org (Armin Rigo) Date: Mon, 3 Mar 2003 14:50:18 +0100 Subject: [pypy-dev] interface changes (would-have-been: builtin --gettingstarted) In-Reply-To: <051a01c2e0dc$01802f00$6d94fea9@newmexico> References: <20030302160901.GB26192@magma.unil.ch> <051a01c2e0dc$01802f00$6d94fea9@newmexico> Message-ID: <20030303135018.GB8117@magma.unil.ch> Hello Samuele, On Sun, Mar 02, 2003 at 05:51:43PM +0100, Samuele Pedroni wrote: > Apart from a C/native execution substrate, .NET/Java/Smalltalk/ObjC as > candidate execution subtrates offer all/are based on single dispatch so a > smooth integration with that can be important. Actually I would like the dispatch algorithms to remain freely choosable, to match whatever we want to do more naturally. Then this or these algorithms would have one or more corresponding efficient implementations in the target low-level languages. For example, multiple dispatch with a compile-time-fixed number of types can be very efficiently implemented in C with tags, e.g. reserving a couple of bits somewhere to store the type and then using a fixed-size table (this would give much better results for all common types than what we have in CPython, for example). It is also interesting to let us implement other dispatch algorithms at other points. For example, I am currently wondering if it wouldn't be a good way to replace the PyArg_ParseTuple(). For example, instead of PyObject* do_stuff(PyObject* self, PyObject* args) { if (!PyArg_ParseTuple(args, "Oi", &x, &y)) ... } we could have def do_stuff(w_x, y): ... with some extra declaration that corresponds to the previous "Oi", similar to the current StdObjSpace.add.register(...) that serves two purposes: 1) declare that a given function accepts some type of parameters (useful both for method selection and possibly for argument conversion); 2) insert the function into a table, i.e. make it reachable. In the case of module functions, (2) means making the function actually available in the module's namespace. A bientot, Armin. From arigo at tunes.org Mon Mar 3 14:56:42 2003 From: arigo at tunes.org (Armin Rigo) Date: Mon, 3 Mar 2003 14:56:42 +0100 Subject: [pypy-dev] Fork lib and pythonpath? In-Reply-To: <000001c2e12d$c8afd660$20bba8c0@XP> References: <000001c2e12d$c8afd660$20bba8c0@XP> Message-ID: <20030303135642.GC8117@magma.unil.ch> Hello, On Sun, Mar 02, 2003 at 09:37:06PM -0500, logistix wrote: > 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 The trivial object space doesn't wrap the sys module yet, so you actually get the underlying one. Moreover, there is absolutely no module loading code done yet. Where the Python code for the compiler should be put is probably in appspace/, but how you actually link to it is still a completely open issue. A bientot, Armin. From tismer at tismer.com Mon Mar 3 15:14:10 2003 From: tismer at tismer.com (Christian Tismer) Date: Mon, 03 Mar 2003 15:14:10 +0100 Subject: [pypy-dev] Pypy frontend/ testall.py In-Reply-To: <3E635B74.6060807@tismer.com> References: <000101c2e12e$d4523de0$20bba8c0@XP> <20030303120903.Z11666@prim.han.de> <3E635B74.6060807@tismer.com> Message-ID: <3E636332.1000305@tismer.com> Christian Tismer wrote: > holger krekel wrote: > ... > >> i have just checked in trunk/src/pypy/tools/test_all.py Added a small patch that makes it work on Windows. -- Christian Tismer :^) 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/ From arigo at tunes.org Mon Mar 3 17:43:59 2003 From: arigo at tunes.org (Armin Rigo) Date: Mon, 3 Mar 2003 17:43:59 +0100 Subject: [pypy-dev] hash negotiation In-Reply-To: <3E61037E.3050504@tismer.com> References: <3E61037E.3050504@tismer.com> Message-ID: <20030303164359.GB10839@magma.unil.ch> Hello Christian, More about Laura's comments in a next e-mail. Just a couple of pragmatic answers: On Sat, Mar 01, 2003 at 08:01:18PM +0100, Christian Tismer wrote: > It may negotiable whether we want to preserve an extra flag > in all the hashable objects whether the hash has been computed, > or repeat CPython's way to preserve a single value for this. This abuse of -1 was for error passing, and we don't need it, so I thought it should just go away. My point of view is definitely that any "C hack" should go away. For objects like strings that internally use -1 for yet another usage ("not computed yet"), our W_StringObjects are free to repeat that and never actually return a value of -1. That's fine. Regarding CPython compatibility, that can be added later if needed by keeping an explicit track of this kind of changes (hence the XXX in my comments -- but we certainly need a better way to sort this kind of comments). It might be as simple as calling our own hash functions, and then, if that returns -1, translate it into -2 (as this is how all CPython objects work around this special value). Well, again the best solution is probably to have a doc repository for this kind of issues. A bientot, Armin. From hpk at trillke.net Mon Mar 3 17:44:34 2003 From: hpk at trillke.net (holger krekel) Date: Mon, 3 Mar 2003 17:44:34 +0100 Subject: [pypy-dev] Pypy frontend/ testall.py In-Reply-To: <3E635B74.6060807@tismer.com>; from tismer@tismer.com on Mon, Mar 03, 2003 at 02:41:08PM +0100 References: <000101c2e12e$d4523de0$20bba8c0@XP> <20030303120903.Z11666@prim.han.de> <3E635B74.6060807@tismer.com> Message-ID: <20030303174434.D11666@prim.han.de> [Christian Tismer Mon, Mar 03, 2003 at 02:41:08PM +0100] > holger krekel wrote: > ... > > > i have just checked in trunk/src/pypy/tools/test_all.py > ^ > --------------------------------------------/ > > I don't believe you adhere to your own renaming rules :-) actually i did but posted it wrong :-) ciao, holger From tismer at tismer.com Mon Mar 3 18:11:32 2003 From: tismer at tismer.com (Christian Tismer) Date: Mon, 03 Mar 2003 18:11:32 +0100 Subject: [pypy-dev] hash negotiation In-Reply-To: <20030303164359.GB10839@magma.unil.ch> References: <3E61037E.3050504@tismer.com> <20030303164359.GB10839@magma.unil.ch> Message-ID: <3E638CC4.7000605@tismer.com> Hi Armin, ... >>It may negotiable whether we want to preserve an extra flag >>in all the hashable objects whether the hash has been computed, >>or repeat CPython's way to preserve a single value for this. > > This abuse of -1 was for error passing, and we don't need it, so I thought it > should just go away. My point of view is definitely that any "C hack" should > go away. Oh then I misunderstood the code. I thought that -1 was always for "not yet computed". Now I understand: long PyObject_Hash(PyObject *v) { PyTypeObject *tp = v->ob_type; if (tp->tp_hash != NULL) return (*tp->tp_hash)(v); if (tp->tp_compare == NULL && RICHCOMPARE(tp) == NULL) { return _Py_HashPointer(v); /* Use address as hash value */ } /* If there's a cmp but no hash defined, the object can't be hashed */ PyErr_SetString(PyExc_TypeError, "unhashable type"); return -1; } This is an error flag! > For objects like strings that internally use -1 for yet another usage ("not > computed yet"), our W_StringObjects are free to repeat that and never actually > return a value of -1. That's fine. So we basically agreed. Just as a not, about what I just learned by reading all of the hash stuff: All number hashes are required to return the same hash value for the same numerical value. hash(1) == hash(1L) == hash(1.0) :-) > Regarding CPython compatibility, that can be added later if needed by keeping > an explicit track of this kind of changes (hence the XXX in my comments -- but > we certainly need a better way to sort this kind of comments). It might be as > simple as calling our own hash functions, and then, if that returns -1, > translate it into -2 (as this is how all CPython objects work around this > special value). Agreed. ciao - chris -- Christian Tismer :^) 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/ From vze55z8s at verizon.net Mon Mar 3 18:23:57 2003 From: vze55z8s at verizon.net (logistix) Date: Mon, 3 Mar 2003 12:23:57 -0500 Subject: [pypy-dev] Pypy frontend/ testall.py In-Reply-To: <20030303120903.Z11666@prim.han.de> Message-ID: <000001c2e1a9$ad1d33d0$20bba8c0@XP> > -----Original Message----- > From: holger krekel [mailto:hpk at trillke.net] > > > [logistix Sun, Mar 02, 2003 at 09:44:31PM -0500] > > I've written a small script that'll allow you to run .py > scripts via > > pypy. Ultimately, it'll incorporate all of the functionality of > > calling 'python' from the command-line. Normally, I'd get > some more > > work done before distributing it, but it is enough to run > testall.py > > in the test directory, so I thought it might be of interest. > > > > It should be noted that testall.py fails quite > spectacularly, as can > > be expected at this point, and aborts execution. I piped > the results > > to a logfile, but there were enough errors hitting stderr and > > bypassing the pipe to make the logfile useless. > > > > Interested people can download the script at: > > > > http://members.bellatlantic.net/~olsongt/python/pypython.py > > i have just checked in trunk/src/pypy/tools/test_all.py > that iterates over the tests in "interpreter". It's not > finished but a good starting point. just go there and > execute "python test_all.py" (tested only on linux). > > holger > You realize this is the exact opposite of what I'm doing, right? ;-) From hpk at trillke.net Mon Mar 3 18:32:03 2003 From: hpk at trillke.net (holger krekel) Date: Mon, 3 Mar 2003 18:32:03 +0100 Subject: [pypy-dev] Pypy frontend/ testall.py In-Reply-To: <000001c2e1a9$ad1d33d0$20bba8c0@XP>; from vze55z8s@verizon.net on Mon, Mar 03, 2003 at 12:23:57PM -0500 References: <20030303120903.Z11666@prim.han.de> <000001c2e1a9$ad1d33d0$20bba8c0@XP> Message-ID: <20030303183203.H11666@prim.han.de> [logistix Mon, Mar 03, 2003 at 12:23:57PM -0500] > > > > -----Original Message----- > > From: holger krekel [mailto:hpk at trillke.net] > > > > > > [logistix Sun, Mar 02, 2003 at 09:44:31PM -0500] > > > I've written a small script that'll allow you to run .py > > scripts via > > > pypy. Ultimately, it'll incorporate all of the functionality of > > > calling 'python' from the command-line. Normally, I'd get > > some more > > > work done before distributing it, but it is enough to run > > testall.py > > > in the test directory, so I thought it might be of interest. > > > > > > It should be noted that testall.py fails quite > > spectacularly, as can > > > be expected at this point, and aborts execution. I piped > > the results > > > to a logfile, but there were enough errors hitting stderr and > > > bypassing the pipe to make the logfile useless. > > > > > > Interested people can download the script at: > > > > > > http://members.bellatlantic.net/~olsongt/python/pypython.py > > > > i have just checked in trunk/src/pypy/tools/test_all.py > > that iterates over the tests in "interpreter". It's not > > finished but a good starting point. just go there and > > execute "python test_all.py" (tested only on linux). > > > > holger > > > > You realize this is the exact opposite of what I'm doing, right? ;-) no, sorry, i didn't. Then again, i posted that i would be doing this some days ago :-) I'll check into your code as soon as possible. which may take some days because i am currently very occupied. greetings, holger From vze55z8s at verizon.net Tue Mar 4 01:25:25 2003 From: vze55z8s at verizon.net (logistix) Date: Mon, 3 Mar 2003 19:25:25 -0500 Subject: [pypy-dev] Why is there a separate ExecutionContext? Message-ID: <000001c2e1e4$8de78a70$20bba8c0@XP> Okay, Here's a summary of what I'm seeing: An ExecutionContext object is created. This is a stack of frames. A PyFrame is created. This has no knowledge of frames above it on the stack. The ExecutionContext accepts the PyFrame for evaluation, and calls the PyFrame's eval passing itself in as a parameter. The PyFrame's eval method just treats the ExecutionContext as a local var, it isn't stored in the class. PyFrame calls appropriate bytecode implementation functions, passing itself as a parameter. bytecode implementation functions are unaware of the execution context. This causes a few problems. First of all, it's impossible to implement the EXEC_STMT bytecode, because you can't call a PyFrame's eval() from inside a bytecode function since you don't have an executionContext to pass in as a parameter. Also, nested scope references can't be resolved for the same reasons. Trying this in the interactive interpreter dies hard. I'm sure there are other issues as well. So do we eliminate the ExecutionContexts and add a "parent frame" property to PyFrame, or do we store a ref to the ExecutionContext as a PyFrame property, or do something else completely? From roccomoretti at netscape.net Tue Mar 4 03:17:25 2003 From: roccomoretti at netscape.net (Rocco Moretti) Date: Mon, 03 Mar 2003 21:17:25 -0500 Subject: [pypy-dev] Pypy frontend/ testall.py Message-ID: <264DB4F6.23B0EDDF.9ADE5C6A@netscape.net> "logistix" wrote: >I've written a small script that'll allow you to run .py scripts via >pypy. ?Ultimately, it'll incorporate all of the functionality of calling >'python' from the command-line. ? Great! I wanted something like this over the weekend. (Have you been borrowing Guido's time machine?) >Normally, I'd get some more work done >before distributing it, but it is enough to run testall.py in the test >directory, so I thought it might be of interest. N.B. If you look at the implementation of testall.py (at least for 2.2.2) it's just a hack which fiddles with sys.argv and then calls into test.regrtest (I mention this because regrtest.py has different output formating features which look much nicer than the verbose output of testall.py. >It should be noted that testall.py fails quite spectacularly, as can be >expected at this point, and aborts execution. ? That's interesting - Which platform and ObjSpace were you using? When I tried this weekend with TrivialObjSpace under Python 2.2.2 on Win98 the results were encouraging - most of the tests passed (eventually). One MAJOR caveat on that issue is that I had to edit regrtest.py to get it to work. Out of the box all the tests failed miserably with "Module Not Found Errors". regrtest.py assumes that tests are in test_???.py files in the current package level (Lib/test, but the level is implicit). However, when the pypy interpreter runs an import, the import runs local in the Lib/pypy/interpreter package - no test_??? files are found. Additionally, when testing, an "import test" opens the "test" submodule of Lib/pypy/interpreter. If you delete/rename the test directory, and edit regrtest.py such that it does an absolute import: Change: the_module = __import__(test, globals(), locals(), []) to: the_module = __import__("test", globals(), locals(), [test]) then testall/regrtest is happy. (No, I don't think this is a long-term solution to the problem ...) -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/ From vze55z8s at verizon.net Tue Mar 4 03:58:33 2003 From: vze55z8s at verizon.net (logistix) Date: Mon, 3 Mar 2003 21:58:33 -0500 Subject: [pypy-dev] Pypy frontend/ testall.py In-Reply-To: <264DB4F6.23B0EDDF.9ADE5C6A@netscape.net> Message-ID: <000101c2e1f9$f265f670$20bba8c0@XP> > -----Original Message----- > From: Rocco Moretti [mailto:roccomoretti at netscape.net] > Sent: Monday, March 03, 2003 9:17 PM > To: logi.stix at verizon.net; pypy-dev at codespeak.net > Subject: RE: [pypy-dev] Pypy frontend/ testall.py > > > "logistix" wrote: > > > That's interesting - Which platform and ObjSpace were you using? > > When I tried this weekend with TrivialObjSpace under Python > 2.2.2 on Win98 > the results were encouraging - most of the tests passed (eventually). I'm running 2.2.2 on XP. I've attached the fatal traceback to the end of this message if you're interested. There were also some less catastrophic failures in the various tests. > One MAJOR caveat on that issue is that I had to edit > regrtest.py to get it > to work. Out of the box all the tests failed miserably with > "Module Not > Found Errors". regrtest.py assumes that tests are in > test_???.py files in > the current package level (Lib/test, but the level is > implicit). However, > when the pypy interpreter runs an import, the import runs > local in the > Lib/pypy/interpreter package - no test_??? files are found. > I originally had that problem too. I'm running this script outside of the whole pythonpath in a directory called pypy that has all of the pypy source. You'll see some bad voodoo that manually adds the path back in. This lets you execute any script anywhere with "C:\pypy\pypython.py script.py". I just noticed that this only works when you run "pypython.py", and not "python pypython.py". I guess I'll have to hack in something from argv[0] for the latter case? TRACEBACK (for what it's worth) =============================== C:\Python22\Lib\test>c:\pypy\pypython.py testall.py > c:\dummy.txt C:\Python22\Lib\test\test_b1.py:329: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4 and up if len(hex(-1)) != len(hex(sys.maxint)): raise TestFailed, 'len(hex(-1))' C:\Python22\Lib\test\test_b1.py:330: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4 and up if hex(-16) not in ('0xfffffff0', '0xfffffffffffffff0'): C:\Python23\lib\pre.py:94: DeprecationWarning: Please use the 're' module, not t he 'pre' module DeprecationWarning) C:\Python23\lib\Cookie.py:687: DeprecationWarning: SerialCookie class is insecur e; do not use it DeprecationWarning) C:\Python23\lib\Cookie.py:712: DeprecationWarning: Cookie/SmartCookie class is i nsecure; do not use it DeprecationWarning) Traceback (most recent call last): File "c:\pypy\pypython.py", line 57, in ? x.execFile(sys.argv[1]) File "c:\pypy\pypython.py", line 46, in execFile self.execString(f.read()) File "c:\pypy\pypython.py", line 42, in execString self.ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 203, in ca ll return ec.eval_frame(frame) File "C:\Python22\Lib\site-packages\pypy\interpreter\executioncontext.py", lin e 13, in eval_frame result = frame.eval(self) File "C:\pypy\interpreter\pyframe.py", line 49, in eval opcode.dispatch_arg(self, op, oparg) File "C:\pypy\interpreter\opcode.py", line 701, in dispatch_arg fn(f, oparg) File "C:\pypy\interpreter\opcode.py", line 607, in CALL_FUNCTION call_function_extra(f, oparg, False, False) File "C:\pypy\interpreter\opcode.py", line 603, in call_function_extra w_result = f.space.call(w_function, w_arguments, w_keywords) File "C:\Python22\Lib\site-packages\pypy\objspace\trivial.py", line 206, in ca ll return apply(callable, args, kwds) File "c:\python23\lib\profile.py", line 214, in trace_dispatch_i if self.dispatch[event](self, frame,t): File "c:\python23\lib\profile.py", line 280, in trace_dispatch_return assert frame is self.cur[-2].f_back, ("Bad return", self.cur[-3]) AssertionError: ('Bad return', ('profile', 0, 'testfunc()')) C:\Python22\Lib\test> From arigo at tunes.org Tue Mar 4 08:50:02 2003 From: arigo at tunes.org (Armin Rigo) Date: Tue, 4 Mar 2003 08:50:02 +0100 Subject: [pypy-dev] Why is there a separate ExecutionContext? In-Reply-To: <000001c2e1e4$8de78a70$20bba8c0@XP> References: <000001c2e1e4$8de78a70$20bba8c0@XP> Message-ID: <20030304075002.GA19907@magma.unil.ch> Hello Logistix, On Mon, Mar 03, 2003 at 07:25:25PM -0500, logistix wrote: > This causes a few problems. First of all, it's impossible to implement > the EXEC_STMT bytecode, because you can't call a PyFrame's eval() from > inside a bytecode function since you don't have an executionContext to > pass in as a parameter. This has been discussed and argued over at the sprint: the few functions that actually want to come back to the execution context or to the frame can use the getexecutioncontext() method. It was juged preferable to add this hack instead of passing an extra argument to *all* functions around. Consider it as an extra hidden parameter. > Also, nested scope references can't be resolved > for the same reasons. Trying this in the interactive interpreter dies > hard. That's not the main reason why nested scopes don't work. They just haven't been completely implemented yet. There are a couple of issues pending on their subject, regarding how we want them to be done (a la CPython vs. with explicit 'dict cells' that points to a specific value of a parent frame's locals dict vs. with real nested Scope objects). Armin From arigo at tunes.org Tue Mar 4 16:43:04 2003 From: arigo at tunes.org (Armin Rigo) Date: Tue, 4 Mar 2003 16:43:04 +0100 Subject: [pypy-dev] Code review possible? In-Reply-To: <3E625811.8090102@tismer.com> References: <3E625811.8090102@tismer.com> Message-ID: <20030304154304.GB25540@magma.unil.ch> Hello, On Sun, Mar 02, 2003 at 08:14:25PM +0100, Christian Tismer wrote: > As far as I remember, Tomek did quite much work with Holger > on some XML stuff, somehow there was a connection between the > Wiki pages and the C source file planned, is that right? > I would like to ask about the status of that sub-project, > and if it is already usable for me to start the review > thing with it? It might be interesting to have something similar for our own files, too. A number of discussions that will eventually get lost in pypy-dev concern a particular file. It would be nice to be able to document our sources with Wiki pages (instead of large bunches of comments at the start of the sources, which obscure everything if you actually want to reach the sources quickly, in my opinion). There should be a standard way of linking Wiki pages not only with sources (ours + CPython's -- well anything from the svn repository) but only to the issue tracker. Questions and open issues about a particular file should go there, with just a link from the Wiki page. Armin. From arigo at tunes.org Tue Mar 4 16:50:19 2003 From: arigo at tunes.org (Armin Rigo) Date: Tue, 4 Mar 2003 16:50:19 +0100 Subject: [pypy-dev] Code review possible? In-Reply-To: <069f01c2e0f4$c313ec20$6d94fea9@newmexico> References: <3E625811.8090102@tismer.com> <069f01c2e0f4$c313ec20$6d94fea9@newmexico> Message-ID: <20030304155019.GC25540@magma.unil.ch> Hello Samuele, On Sun, Mar 02, 2003 at 08:48:56PM +0100, Samuele Pedroni wrote: > ... > funcobject.c > moduleobject.c > etc > > that means the glue and skeleton of the object model/runtime; I don't think > object spaces as such cover already the whole story, Well, they should cover the whole story apart from the actual translation process, which is I admit a big open point. OTOH object spaces are also the correct place to include special-case translations or translation code about specific object space files, e.g. multimethod.py or Christian's r_int. > OTOH if for the first try the implementations of int,long,dict,tuple... are > simply wrappers around the CPython types, is not too much a problem because > local to the single object types and the details are fixable and one can > solve the problem one object type at a time. That was the idea. The cpythonobject.py is just that. It is quite incomplete in that it will not let most operations pass throught the underlying object (so it's more of a black box right now). > But if don't know how to get 1 .__add__ to behave or lookup/dispatch in > general or the content of type("").__dict__ etc right, that's a FAR more > serious obstacle. I don't think getting this right should be too difficult. Even in CPython it is kind of a hack that makes it work on top of the standard types. A suitable restriction would let us implement 1.__add__ as in CPython. On the other hand, this is a kind of "tricky" behavior in CPython (is it completely formalized in the language reference?) which may go away at some point because the original idea was still that a.__add__(b) should eventually be the same as a+b -- unless I'm mistaken here. A bientot, Armin. From pedronis at bluewin.ch Tue Mar 4 17:21:22 2003 From: pedronis at bluewin.ch (Samuele Pedroni) Date: Tue, 4 Mar 2003 17:21:22 +0100 Subject: [pypy-dev] Code review possible? References: <3E625811.8090102@tismer.com><069f01c2e0f4$c313ec20$6d94fea9@newmexico> <20030304155019.GC25540@magma.unil.ch> Message-ID: <022f01c2e26a$2f597dc0$6d94fea9@newmexico> From: "Armin Rigo" > Hello Samuele, > > On Sun, Mar 02, 2003 at 08:48:56PM +0100, Samuele Pedroni wrote: > > ... > > funcobject.c > > moduleobject.c > > etc > > > > that means the glue and skeleton of the object model/runtime; I don't think > > object spaces as such cover already the whole story, > > Well, they should cover the whole story apart from the actual translation > process, which is I admit a big open point. OTOH object spaces are also the > correct place to include special-case translations or translation code about > specific object space files, e.g. multimethod.py or Christian's r_int. a complete object space should cover ther story, yes, but I don't think you have a working reimplementation of all the semantics of typeobject.c for example ... my point is that that was more difficult/important than how to write listobject impl. > > But if don't know how to get 1 .__add__ to behave or lookup/dispatch in > > general or the content of type("").__dict__ etc right, that's a FAR more > > serious obstacle. > > I don't think getting this right should be too difficult. up to the translation as anything else <.5 wink>. > Even in CPython it > is kind of a hack that makes it work on top of the standard types. A suitable > restriction would let us implement 1.__add__ as in CPython. On the other hand, > this is a kind of "tricky" behavior in CPython (is it completely formalized in > the language reference?) which may go away at some point because the original > idea was still that a.__add__(b) should eventually be the same as a+b -- > unless I'm mistaken here. I doubt it, as long as things are defined in terms of the __add__/__radd__ dance for user objects. From hpk at trillke.net Tue Mar 4 18:15:04 2003 From: hpk at trillke.net (holger krekel) Date: Tue, 4 Mar 2003 18:15:04 +0100 Subject: [pypy-dev] Code review possible? In-Reply-To: <20030304154304.GB25540@magma.unil.ch>; from arigo@tunes.org on Tue, Mar 04, 2003 at 04:43:04PM +0100 References: <3E625811.8090102@tismer.com> <20030304154304.GB25540@magma.unil.ch> Message-ID: <20030304181504.R11666@prim.han.de> [Armin Rigo Tue, Mar 04, 2003 at 04:43:04PM +0100] > Hello, > > On Sun, Mar 02, 2003 at 08:14:25PM +0100, Christian Tismer wrote: > > As far as I remember, Tomek did quite much work with Holger > > on some XML stuff, somehow there was a connection between the > > Wiki pages and the C source file planned, is that right? > > I would like to ask about the status of that sub-project, > > and if it is already usable for me to start the review > > thing with it? > > It might be interesting to have something similar for our own files, too. A > number of discussions that will eventually get lost in pypy-dev concern a > particular file. It would be nice to be able to document our sources with Wiki > pages (instead of large bunches of comments at the start of the sources, which > obscure everything if you actually want to reach the sources quickly, in my > opinion). There should be a standard way of linking Wiki pages not only with > sources (ours + CPython's -- well anything from the svn repository) but only > to the issue tracker. Questions and open issues about a particular file should > go there, with just a link from the Wiki page. Yes, that was the direction we took at the sprint. Hopefully Tomek and me can do some work on this, soon. holger From vze55z8s at verizon.net Tue Mar 4 23:54:44 2003 From: vze55z8s at verizon.net (logistix) Date: Tue, 4 Mar 2003 17:54:44 -0500 Subject: [pypy-dev] Why is there a separate ExecutionContext? In-Reply-To: <20030304075002.GA19907@magma.unil.ch> Message-ID: <000001c2e2a1$0d083950$20bba8c0@XP> > -----Original Message----- > From: pypy-dev-bounces at codespeak.net > [mailto:pypy-dev-bounces at codespeak.net] On Behalf Of Armin Rigo > Sent: Tuesday, March 04, 2003 2:50 AM > To: pypy-dev at codespeak.net > Subject: Re: [pypy-dev] Why is there a separate ExecutionContext? > > > Hello Logistix, > > On Mon, Mar 03, 2003 at 07:25:25PM -0500, logistix wrote: > > This causes a few problems. First of all, it's impossible to > > implement the EXEC_STMT bytecode, because you can't call a > PyFrame's > > eval() from inside a bytecode function since you don't have an > > executionContext to pass in as a parameter. > > This has been discussed and argued over at the sprint: the > few functions that > actually want to come back to the execution context or to the > frame can use > the getexecutioncontext() method. It was juged preferable to > add this hack > instead of passing an extra argument to *all* functions > around. Consider it as > an extra hidden parameter. > Would it be semantically clearer if PyFrames got an executioncontext object in the constructor instead of the space object? Space could still be accessed via frame.ec.space. Frame.space.getexecutioncontext() seems like you're running in circles. From tismer at tismer.com Wed Mar 5 02:28:11 2003 From: tismer at tismer.com (Christian Tismer) Date: Wed, 05 Mar 2003 02:28:11 +0100 Subject: [pypy-dev] Why is there a separate ExecutionContext? In-Reply-To: <000001c2e2a1$0d083950$20bba8c0@XP> References: <000001c2e2a1$0d083950$20bba8c0@XP> Message-ID: <3E6552AB.5010406@tismer.com> logistix wrote: > > -----Original Message----- > From: pypy-dev-bounces at codespeak.net > [mailto:pypy-dev-bounces at codespeak.net] On Behalf Of Armin Rigo > Sent: Tuesday, March 04, 2003 2:50 AM > To: pypy-dev at codespeak.net > Subject: Re: [pypy-dev] Why is there a separate ExecutionContext? > > > Hello Logistix, > > On Mon, Mar 03, 2003 at 07:25:25PM -0500, logistix wrote: > >>This causes a few problems. First of all, it's impossible to >>implement the EXEC_STMT bytecode, because you can't call a > > PyFrame's > >>eval() from inside a bytecode function since you don't have an >>executionContext to pass in as a parameter. > > This has been discussed and argued over at the sprint: the > few functions that > actually want to come back to the execution context or to the > frame can use > the getexecutioncontext() method. It was juged preferable to > add this hack > instead of passing an extra argument to *all* functions > around. Consider it as > an extra hidden parameter. > > > > Would it be semantically clearer if PyFrames got an executioncontext > object in the constructor instead of the space object? Space could > still be accessed via frame.ec.space. Frame.space.getexecutioncontext() > seems like you're running in circles. I think this makes sense. The ec acts somehow like frame.f_tstate . If we call this a threadstate or an executioncontext, it is obviously needed. ciao - chris -- Christian Tismer :^) 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/ From arigo at tunes.org Wed Mar 5 08:13:58 2003 From: arigo at tunes.org (Armin Rigo) Date: Wed, 5 Mar 2003 08:13:58 +0100 Subject: [pypy-dev] Why is there a separate ExecutionContext? In-Reply-To: <3E6552AB.5010406@tismer.com> References: <000001c2e2a1$0d083950$20bba8c0@XP> <3E6552AB.5010406@tismer.com> Message-ID: <20030305071358.GA2620@magma.unil.ch> Hello, On Wed, Mar 05, 2003 at 02:28:11AM +0100, Christian Tismer wrote: > >Would it be semantically clearer if PyFrames got an executioncontext > >object in the constructor instead of the space object? Space could > >still be accessed via frame.ec.space. > The ec acts somehow like frame.f_tstate . If we call this a > threadstate or an executioncontext, it is obviously needed. Makes sense. Maybe not in the constructor of frames, but in their eval() method that could save the incoming executioncontext parameter for the duration of the call. (Might be cleaner for frames corresponding to generators if these are run in different executioncontexts during their lifetime.) > > Frame.space.getexecutioncontext() > >seems like you're running in circles. Yes. The point of getexecutioncontext() was actually to get back to the calling frame or executioncontext when you are in the object space itself, e.g. to implement function call. For the frame opcodes, it is overkill. A bientot, Armin. From roccomoretti at netscape.net Thu Mar 6 03:19:22 2003 From: roccomoretti at netscape.net (Rocco Moretti) Date: Wed, 05 Mar 2003 21:19:22 -0500 Subject: [pypy-dev] Why is there a separate ExecutionContext? Message-ID: <6939105F.795CBC5D.9ADE5C6A@netscape.net> "logistix" wrote: >Would it be semantically clearer if PyFrames got an executioncontext >object in the constructor instead of the space object? ?Space could >still be accessed via frame.ec.space. ?Frame.space.getexecutioncontext() >seems like you're running in circles. Actually, in the interest of generality, I'd argue that ExecutionContexts should not contain a link to the object space - it should be a per frame value. If you think of a future time when multiple ObjSpaces coexist in the same interpreter, a frame in one ObjSpace will be able to call a frame in another ObjSpace. Since a function in one ObjSpace can call a function in a different ObjSpace, the ObjSpace for the ExecutionContext is not constant. The trick in calling across ObjSpaces is marshaling/demarshaling arguments/return values. For now we can deal with it by requiring function calls either to be in the same ObjSpace, or by .wrap()ing and then .unwrap ()ing the values. A more general mechanism can be worked out when we have more than one non-trivial object space. -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/ From vze55z8s at verizon.net Thu Mar 6 07:52:18 2003 From: vze55z8s at verizon.net (logistix) Date: Thu, 6 Mar 2003 01:52:18 -0500 Subject: [pypy-dev] Why is there a separate ExecutionContext? In-Reply-To: <6939105F.795CBC5D.9ADE5C6A@netscape.net> Message-ID: <000101c2e3ac$eeac3b20$20bba8c0@XP> > -----Original Message----- > From: Rocco Moretti [mailto:roccomoretti at netscape.net] > Sent: Wednesday, March 05, 2003 9:19 PM > To: logi.stix at verizon.net; "'Armin Rigo'"; pypy-dev at codespeak.net > Subject: RE: [pypy-dev] Why is there a separate ExecutionContext? > > > "logistix" wrote: > > >Would it be semantically clearer if PyFrames got an executioncontext > >object in the constructor instead of the space object? ?Space could > >still be accessed via frame.ec.space. ? > >Frame.space.getexecutioncontext() seems like you're running > in circles. > > Actually, in the interest of generality, I'd argue that > ExecutionContexts > should not contain a link to the object space - it should be > a per frame > value. If you think of a future time when multiple ObjSpaces > coexist in > the same interpreter, a frame in one ObjSpace will be able to > call a frame > in another ObjSpace. Since a function in one ObjSpace can > call a function > in a different ObjSpace, the ObjSpace for the ExecutionContext is not > constant. > > The trick in calling across ObjSpaces is marshaling/demarshaling > arguments/return values. For now we can deal with it by > requiring function > calls either to be in the same ObjSpace, or by .wrap()ing and > then .unwrap ()ing the values. A more general mechanism can > be worked out when we have > more than one non-trivial object space. > > -Rocco > I would disagree with this. It looks like ExecutionContexts are analogous to threads, so different ec's in the same object space could interact with each other. It'd be cool to be able to interact with other object spaces, but this would be more analogous to a RPC call operating in an entirely different memory space. And that's where marshalling comes in, interaction between different object spaces would be opaque. If you try to let the Execution Context cross spaces, even something as seemingly simple as getting a list of available global variables becomes a nightmare. From arigo at tunes.org Thu Mar 6 07:59:21 2003 From: arigo at tunes.org (Armin Rigo) Date: Thu, 6 Mar 2003 07:59:21 +0100 Subject: [pypy-dev] Why is there a separate ExecutionContext? In-Reply-To: <000101c2e3ac$eeac3b20$20bba8c0@XP> References: <6939105F.795CBC5D.9ADE5C6A@netscape.net> <000101c2e3ac$eeac3b20$20bba8c0@XP> Message-ID: <20030306065921.GA17942@magma.unil.ch> Hello, On Thu, Mar 06, 2003 at 01:52:18AM -0500, logistix wrote: > > Actually, in the interest of generality, I'd argue that > > ExecutionContexts > > should not contain a link to the object space - it should be > > a per frame value. > I would disagree with this. It looks like ExecutionContexts are > analogous to threads, so different ec's in the same object space could > interact with each other. I think that you are both right. Multiple ExecutionContexts can work with the same object space (multithreading), and at the same time a single ExecutionContext could hold frames crossing object spaces (remote calls). A bientot, Armin. From vze55z8s at verizon.net Fri Mar 7 01:01:39 2003 From: vze55z8s at verizon.net (logistix) Date: Thu, 6 Mar 2003 19:01:39 -0500 Subject: [pypy-dev] Feature Request: Use valid python ;-) Message-ID: <000001c2e43c$bc30ca40$20bba8c0@XP> I was processing my pythonpath with parser and it blew up on several pypy files. Here are the details, but I can provide a diff if necessary (and would have if I knew where to): longobject.py - mixes tabs and spaces listobject.py: class W_ListObject: ... should be class W_ListObject:pass iterobject.py is invalid longobject.py should be. def long_getattr(i, attr): if attr == "__class__": return int raise AttributeError#, .... From tismer at tismer.com Fri Mar 7 02:53:52 2003 From: tismer at tismer.com (Christian Tismer) Date: Fri, 07 Mar 2003 02:53:52 +0100 Subject: [pypy-dev] I'm off for wa while... Message-ID: <3E67FBB0.8040601@tismer.com> Hi friends, sorry to tell you so, but I will be away from this project for a while. I'm in trouble with my parent's health, I haven't done my sponsored Stackless work for months and they are about to cancel my contracts, and currently I'm driving myself into a deadlock: I am unable to concentrate on anything. For that reason, I'm drawing a hard decision: I will not work on PyPy until Stackless 3.0 is out. I will cancel my PyCon talk, which is very hard for me. Most probably, I will be back, somewhere in April. My apologies that I kicked this project off, slightly too early. bye for a while, busy feeding a big family -- chris -- Christian Tismer :^) 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/ From arigo at tunes.org Fri Mar 7 08:29:14 2003 From: arigo at tunes.org (Armin Rigo) Date: Fri, 7 Mar 2003 08:29:14 +0100 Subject: [pypy-dev] Feature Request: Use valid python ;-) In-Reply-To: <000001c2e43c$bc30ca40$20bba8c0@XP> References: <000001c2e43c$bc30ca40$20bba8c0@XP> Message-ID: <20030307072914.GA825@magma.unil.ch> Hello Logistix, On Thu, Mar 06, 2003 at 07:01:39PM -0500, logistix wrote: > I was processing my pythonpath with parser and it blew up on several > pypy files. Yes, I know, almost all the files you mention are the almost-empty templates that I quickly wrote during the sprint -- they are essentially empty! Armin From vze55z8s at verizon.net Fri Mar 7 23:34:34 2003 From: vze55z8s at verizon.net (logistix) Date: Fri, 7 Mar 2003 17:34:34 -0500 Subject: [pypy-dev] Feature Request: Use valid python ;-) In-Reply-To: <20030307072914.GA825@magma.unil.ch> Message-ID: <000001c2e4f9$bb309c70$20bba8c0@XP> > -----Original Message----- > From: pypy-dev-bounces at codespeak.net > [mailto:pypy-dev-bounces at codespeak.net] On Behalf Of Armin Rigo > Sent: Friday, March 07, 2003 2:29 AM > To: pypy-dev at codespeak.net > Subject: Re: [pypy-dev] Feature Request: Use valid python ;-) > > > Hello Logistix, > > On Thu, Mar 06, 2003 at 07:01:39PM -0500, logistix wrote: > > I was processing my pythonpath with parser and it blew up > on several > > pypy files. > > Yes, I know, almost all the files you mention are the > almost-empty templates > that I quickly wrote during the sprint -- they are essentially empty! > Yes, I understand, and I know why they're there, but I'd personally rather see someone raising a NotImplementedError in stub code. From arigo at tunes.org Sun Mar 9 19:33:16 2003 From: arigo at tunes.org (Armin Rigo) Date: Sun, 9 Mar 2003 10:33:16 -0800 (PST) Subject: [pypy-dev] "unit" definition Message-ID: <20030309183316.0E9F14F07@bespin.org> Hello everybody, Here is a proposal for organizing our files and particularly putting them in relation. As the Python tests are "unit tests" I suggest the name "unit" for a body of work composed of a couple of related files. A unit is roughly something as big as a Python module, but could also be used for something like built-in types. For example: * 'Builtins module' unit: module/test/test_builtin.py CPython's original unit test file module/builtin.py module/builtin_app.py maybe CPython's __builtin__ module for the interface (docstrings...) * 'Integer object' unit: objspace/std/test/test_integer.py objspace/std/test/test_intobject.py objspace/std/intobject.py objspace/std/intobject_app.py A unit is something explicitely defined somewhere. It starts abstractedly, like with only the tests and the interface of the module (function signatures, docstrings), and it is later "completed", i.e. (possibly incrementially) implemented, with new implementation-specific tests and docs. Example assuming Python syntax, using subclassing for "completing": class BuiltinsModule(pypy.unit.ModuleUnit): "Expected interface for the Python __builtin__ module." modulename = "__builtin__" test1 = pypy.unit.Test("module/test/test_builtin.py") rawinterface = pypy.unit.InterfaceFromCPython("__builtin__") #...and possibly somewhere else... class MyBuiltins(path.to.the.above.BuiltinsModule): impl = pypy.unit.RPythonImplementation("./my_builtin.py") implapp = pypy.unit.PurePythonImplementation("./my_builtin_app.py") impltest = pypy.unit.Test("./test/test_my_builtin.py") maintainer = "arigo" # some tests are known to fail right now # (the following line is done with a __get__ method on pypy.unit.Test # so that we can refer to MyBuiltins' status of test1) MyBuiltins.test1.known_failing += ['test_zip', 'test_unichr'] # some functions I have not implemented right now MyBuiltins.rawinterface.known_missing += ['filter', 'reduce'] # Note that the base BuiltinsModule class has no implementation, # hence tests won't be tested directly on it. # Also note that there are only a couple of magic attribute names, # like 'modulename' and 'maintainer'; all the pypy.unit.Xxx() # instances can be found by enumerating all attributes. The purpose of the classes of pypy.unit is to define the "roles" that each file can assume within that unit. They contains the magic to collect the data together when we actually want to run the tests or pypy itself. For example, RPythonImplementation would search for all functions defined in the specified file and insert them as "built-in function objects" into the proper application-level module (or maybe not all the functions, but only the ones specially tagged, or only the ones that are said to be part of the module interface). Instead of the above Python syntax for the definition of units, it could also be done with a dedicated syntax; here XML: module/builtinsmodule.xml: __builtin__ module/test/test_builtin.py __builtin__ module/arigo/mybuiltins.xml: blah blah blah ./my_builtins.py ./my_builtins_app.py ./test/test_my_builtins.py arigo test_zip test_unichr filter reduce Not too bad either, althought having the power of the Python language to express things like 'known_failing += [...]' is more flexible. Opinions? Opinions on the whole idea are welcome too, of course! As you might have noticed I have located mybuiltins.xml in "module/arigo/", following Laura's idea of separating our in-development files from the main ones. I have not specified here anything about the actual "release" of the files, i.e. the process of moving them from these per-user subdirectories into the mainstream "module/". For now I'd say it could be as easy as moving up the .xml file and the files it links to, and that we'll see later if we need to agree on a more precise policy for that. Also note that contributing a test file that you expect to work on any implementation of a module means just adding a line in the (base) unit corresponding to the empty module interface. We should then precisely define the pypy.unit role classes, e.g. how Test() files are called, what function signatures RPythonImplementation() expect (including how to do the PyArg_ParseTuple() trick more declaratively), and how interfaces and possibly doc files are written. We also probably need another kind of implementation, like LibraryImplementation, a file containing just ctypes-like declarations of library function calls (e.g. for the posix module). I hope that this could give the frame that everybody is waiting for to start the actual work! A bient?t, Armin. From florian.proff.schulze at gmx.net Sun Mar 9 14:56:19 2003 From: florian.proff.schulze at gmx.net (Florian Schulze) Date: Sun, 09 Mar 2003 14:56:19 +0100 Subject: [pypy-dev] Re: subversion In-Reply-To: <3E610AFE.7070100@tismer.com> References: <20030224164413.51465501B@bespin.org> <200302261009.h1QA9Jc23764@trixie.triqs.com> <3E5CDEA1.7080401@tismer.com> <200302261639.h1QGdoc26254@trixie.triqs.com> <3E5D0B74.7030709@tismer.com> <20030227104435.GA30494@magma.unil.ch> <013c01c2de4e$dc64bcc0$6d94fea9@newmexico> <3E60FB25.2010406@tismer.com> <3E610AFE.7070100@tismer.com> Message-ID: > 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 TortoiseSVN-0.6.1 fixes a serious bug. > If you are using Windows 2000, you need to install > service pack 3 for SVN. It works for me with SP2. Florian From arigo at tunes.org Mon Mar 10 10:24:07 2003 From: arigo at tunes.org (Armin Rigo) Date: Mon, 10 Mar 2003 10:24:07 +0100 Subject: [pypy-dev] Pypy frontend/ testall.py In-Reply-To: <264DB4F6.23B0EDDF.9ADE5C6A@netscape.net> References: <264DB4F6.23B0EDDF.9ADE5C6A@netscape.net> Message-ID: <20030310092407.GA11606@magma.unil.ch> Hello, On Mon, Mar 03, 2003 at 09:17:25PM -0500, Rocco Moretti wrote: > Additionally, when testing, an "import test" opens the "test" submodule of > Lib/pypy/interpreter. Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory? We will keep running again and again into this problem. Either none of our test/ subdirectory is a package, or we rename them all (e.g. to testing/) to avoid this confusion. Armin From mwh at python.net Mon Mar 10 12:42:47 2003 From: mwh at python.net (Michael Hudson) Date: Mon, 10 Mar 2003 11:42:47 +0000 Subject: [pypy-dev] Re: Pypy frontend/ testall.py References: <264DB4F6.23B0EDDF.9ADE5C6A@netscape.net> <20030310092407.GA11606@magma.unil.ch> Message-ID: <2m7kb7curs.fsf@starship.python.net> Armin Rigo writes: > Hello, > > On Mon, Mar 03, 2003 at 09:17:25PM -0500, Rocco Moretti wrote: >> Additionally, when testing, an "import test" opens the "test" submodule of >> Lib/pypy/interpreter. ? Shouldn't do, if $PYTHONPATH is pointing at the directory containing the pypy directory. > Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory? Because I wanted to import something from there at some point. > We will keep running again and again into this problem. Why? > Either none of our test/ subdirectory is a package, Bad idea, IMO. > or we rename them all (e.g. to testing/) to avoid this confusion. Better, but should be unecessary. Cheers, M. -- MGM will not get your whites whiter or your colors brighter. It will, however, sit there and look spiffy while sucking down a major honking wad of RAM. -- http://www.xiph.org/mgm/ From arigo at tunes.org Mon Mar 10 13:46:18 2003 From: arigo at tunes.org (Armin Rigo) Date: Mon, 10 Mar 2003 13:46:18 +0100 Subject: [pypy-dev] Re: Pypy frontend/ testall.py In-Reply-To: <2m7kb7curs.fsf@starship.python.net> References: <264DB4F6.23B0EDDF.9ADE5C6A@netscape.net> <20030310092407.GA11606@magma.unil.ch> <2m7kb7curs.fsf@starship.python.net> Message-ID: <20030310124618.GA15860@magma.unil.ch> Hello Michael, On Mon, Mar 10, 2003 at 11:42:47AM +0000, Michael Hudson wrote: > >> Additionally, when testing, an "import test" opens the "test" submodule of > >> Lib/pypy/interpreter. > > ? Shouldn't do, if $PYTHONPATH is pointing at the directory > containing the pypy directory. It does, if the current directory is pypy/interpreter (for example when you run python 'interactive.py'). > > Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory? > Because I wanted to import something from there at some point. Ok, but then: > > We will keep running again and again into this problem. > Why? Because then you have no way to import the standard library 'test' package if you current directory happens to contain a local 'test' package -- which will eventually mean almost any PyPy directory. I had the same problems over and over again with Psyco, which had a 'test.py', until I finally decided to rename it to 'test1.py'. I my humble opinion it might have been a bad idea to give a Python standard library package a name as common as 'test', but well, not everybody is supposed to import it in everyday applications. Armin From mwh at python.net Mon Mar 10 14:04:13 2003 From: mwh at python.net (Michael Hudson) Date: Mon, 10 Mar 2003 13:04:13 +0000 Subject: [pypy-dev] Re: Pypy frontend/ testall.py References: <264DB4F6.23B0EDDF.9ADE5C6A@netscape.net> <20030310092407.GA11606@magma.unil.ch> <2m7kb7curs.fsf@starship.python.net> <20030310124618.GA15860@magma.unil.ch> Message-ID: <2m3clvcr02.fsf@starship.python.net> Armin Rigo writes: > Hello Michael, > > On Mon, Mar 10, 2003 at 11:42:47AM +0000, Michael Hudson wrote: >> >> Additionally, when testing, an "import test" opens the "test" submodule of >> >> Lib/pypy/interpreter. >> >> ? Shouldn't do, if $PYTHONPATH is pointing at the directory >> containing the pypy directory. > > It does, if the current directory is pypy/interpreter (for example when you > run python 'interactive.py'). So don't do that, run $ PYTHONPATH=. python pypy/interperter/interactive.py then. I can see this being tedious, though. interactive.py could remove the cwd from sys.path, but that also might be surprising. >> > Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory? >> Because I wanted to import something from there at some point. > > Ok, but then: > >> > We will keep running again and again into this problem. >> Why? > > Because then you have no way to import the standard library 'test' package I actually realised this bit :-) It's just that if you set up your paths the Right Way(tm) you shouldn't bump into this. Perhaps we should do a mass test -> pypytest (or something) renaming, for simplicity. Cheers, M. (relative imports are evil, have I mentioned this lately?) -- I would hereby duly point you at the website for the current pedal powered submarine world underwater speed record, except I've lost the URL. -- Callas, cam.misc From bokr at oz.net Fri Mar 14 04:04:33 2003 From: bokr at oz.net (Bengt Richter) Date: Thu, 13 Mar 2003 19:04:33 -0800 Subject: [pypy-dev] Re: Pypy frontend/ testall.py In-Reply-To: <2m3clvcr02.fsf@starship.python.net> References: <264DB4F6.23B0EDDF.9ADE5C6A@netscape.net> <20030310092407.GA11606@magma.unil.ch> <2m7kb7curs.fsf@starship.python.net> <20030310124618.GA15860@magma.unil.ch> Message-ID: <5.0.2.1.1.20030313182513.00a71960@mail.oz.net> At 13:04 2003-03-10 +0000, Michael Hudson wrote: >Armin Rigo writes: > >> Hello Michael, >> >> On Mon, Mar 10, 2003 at 11:42:47AM +0000, Michael Hudson wrote: >>> >> Additionally, when testing, an "import test" opens the "test" submodule of >>> >> Lib/pypy/interpreter. >>> >>> ? Shouldn't do, if $PYTHONPATH is pointing at the directory >>> containing the pypy directory. >> >> It does, if the current directory is pypy/interpreter (for example when you >> run python 'interactive.py'). > >So don't do that, run > >$ PYTHONPATH=. python pypy/interperter/interactive.py > >then. I can see this being tedious, though. > >interactive.py could remove the cwd from sys.path, but that also might >be surprising. > >>> > Why is there an __init__.py file in our pypy/interpreter/test/ subdirectory? >>> Because I wanted to import something from there at some point. >> >> Ok, but then: >> >>> > We will keep running again and again into this problem. >>> Why? >> >> Because then you have no way to import the standard library 'test' package > >I actually realised this bit :-) It's just that if you set up your >paths the Right Way(tm) you shouldn't bump into this. > >Perhaps we should do a mass test -> pypytest (or something) renaming, >for simplicity. > >Cheers, >M. >(relative imports are evil, have I mentioned this lately?) I wonder if some kind of aliasing mechanism could solve this kind of problem. E.g., if about to raise an exception for non-existent file/directory, first check for a match to some rewrite patterns in an alias file. They could be simple prefix replacements for paths or more complex regex subs. Then, after rewriting, try the modified path, and only after that fails raise the exception. This would allow creation of platform-independent sys.path name prefixes like, e.g., r"/$$py_lib" and generating, e.g., r"D:\python22\lib" or the unix equivalent as the modified path prefix actually used. All python system files could thus exist under a tree of platform- independent alias prefixes, and pypy could define some for special purposes. There could even be a mechanism for pushing/popping a temporary prefix definition override. Appropriate naming conventions should avoid problems. (I have previously posted about virtualizing part of the file/directory namespace accessed via python's open/file built-ins, and gotten objections that this would not appear to i/o done via the os module or user-written extension modules. I didn't pursue it further, but I still think something platform-independent could be useful.) my .02USD Regards, Bengt Richter (Back from 2 wks on a sunny beach ;-) From bokr at oz.net Fri Mar 14 04:53:10 2003 From: bokr at oz.net (Bengt Richter) Date: Thu, 13 Mar 2003 19:53:10 -0800 Subject: [pypy-dev] Implicit make functionality in pypy? In-Reply-To: <20030309183316.0E9F14F07@bespin.org> Message-ID: <5.0.2.1.1.20030313190600.00a77140@mail.oz.net> Hello. I thought I'd offer this observation: There seems to be a lot of activity between a python source and producing the result of "executing" it. Even in CPython, there are implicitly checks on the environment and for the existence of .pyc files, etc., and conditional compilation based on these. Descriptions of pypy aspirations suggest more complex and conditional behavior in the process of "executing" a python script. As a thought experiment, how do you react to thinking of the total process as controlled by a hidden pypy_make and associated files (python source, default make-file template, etc.)? Even if pypy_make doesn't literally exist, I'm wondering if the make concept (being familiar) would help organize all the activities and dependencies, especially since various targeting options are desired, and various optimization strategies are to be coordinated, etc., etc., including possible use of alternate implementation languages for modules/extensions. I thought maybe the concept of python execution/interpreting via implicit pypy_make might make factoring/modularizing the various functions easier and more flexible than a more monolithic interpreter concept, but this is just a thought. Thus pypy script.py would perhaps act like pypy_make results -f pypy_run.mak -s script.py under the covers, and pypy_run.mak (and script.py.mak if present?) could accumulate the declarative glue to express all the relationships. Maybe scons could be cannibalized, if this were a viable implementation strategy? Anyway, just a thought, FWIW. Regards, Bengt (Back from 2 wks on a sunny beach ;-) From arigo at tunes.org Fri Mar 14 14:54:25 2003 From: arigo at tunes.org (Armin Rigo) Date: Fri, 14 Mar 2003 14:54:25 +0100 Subject: [pypy-dev] Re: Pypy frontend/ testall.py In-Reply-To: <5.0.2.1.1.20030313182513.00a71960@mail.oz.net> References: <264DB4F6.23B0EDDF.9ADE5C6A@netscape.net> <20030310092407.GA11606@magma.unil.ch> <2m7kb7curs.fsf@starship.python.net> <20030310124618.GA15860@magma.unil.ch> <5.0.2.1.1.20030313182513.00a71960@mail.oz.net> Message-ID: <20030314135425.GA17512@magma.unil.ch> Hello Bengt, On Thu, Mar 13, 2003 at 07:04:33PM -0800, Bengt Richter wrote: > I wonder if some kind of aliasing mechanism could solve this kind > of problem. In some point of view we had the opposite problem: importing 'test' finds too many 'test' packages and imports the wrong one. > This would allow creation of platform-independent sys.path name > prefixes like, e.g., r"/$$py_lib" and generating, e.g., r"D:\python22\lib" > or the unix equivalent as the modified path prefix actually used. I think this is interesting, and I need it for the "unit" thing: a platform-independent way to point to a file that can be either 'local', i.e. relative to the directory of the file containing the pointer, or absolute within Python's standard library. Right now I am simply saying that a posix-style name containing at least a '/' is local, and otherwise it is a (possibly dotted) module name from the standard library. Maybe a more general virtual file namespace could be an interesting thing to have. A bient?t, Armin. From arigo at tunes.org Fri Mar 14 15:01:29 2003 From: arigo at tunes.org (Armin Rigo) Date: Fri, 14 Mar 2003 15:01:29 +0100 Subject: [pypy-dev] Implicit make functionality in pypy? In-Reply-To: <5.0.2.1.1.20030313190600.00a77140@mail.oz.net> References: <20030309183316.0E9F14F07@bespin.org> <5.0.2.1.1.20030313190600.00a77140@mail.oz.net> Message-ID: <20030314140129.GB17512@magma.unil.ch> Hello Bengt, On Thu, Mar 13, 2003 at 07:53:10PM -0800, Bengt Richter wrote: > There seems to be a lot of activity between a python source and > producing the result of "executing" it. Even in CPython, there are > implicitly checks on the environment and for the existence of .pyc > files, etc., and conditional compilation based on these. > > Descriptions of pypy aspirations suggest more complex and conditional > behavior in the process of "executing" a python script. Yes, but I am not sure there is a need for a 'make'-based running process. A similar result can be acheived by correctly defining and linking together Python code containing declarative classes, which is what I am trying to do with the "unit" stuff. In other words, as we are using Python to control how parts are tied to each other, we already have much more flexibility than if we were using C (as in CPython). > would perhaps act like > pypy_make results -f pypy_run.mak -s script.py > under the covers, and pypy_run.mak (and script.py.mak if present?) > could accumulate the declarative glue to express all the relationships. I would prefer this glue to be written in a form that is easily accessible to Python algorithms. The SCons project could be useful here, too; I think I will more seriously look at it and see if it could be used to declare what I have in mind for "units", namely extensible bags of files, each playing a parametrizable role within the unit. A bient?t, Armin. From roccomoretti at netscape.net Tue Mar 18 04:49:14 2003 From: roccomoretti at netscape.net (Rocco Moretti) Date: Mon, 17 Mar 2003 22:49:14 -0500 Subject: [pypy-dev] Why is there a separate ExecutionContext? Message-ID: <02C7F147.3F22EF25.9ADE5C6A@netscape.net> Sorry for the weeks of radio silence, life has a way of taking up your time. >> > Actually, in the interest of generality, I'd argue that >> > ExecutionContexts >> > should not contain a link to the object space - it should be >> > a per frame value. There seems to be confusion on what I mean, so let me see if I can clarify. I hope we all agree that one of the powers of the ObjectSpace concept is the possibility of using multiple ObjectSpaces in the same program. We already have this implicitly with Python objects and C language objects. We could have an ObjectSpace for Psyco-ized code, or allow legacy ObjectSpaces - run 1.5.2 semantic objects in otherwise 2.5.3 codebase. So in this use of multiple ObjectSpaces, I'm mostly thinking in terms of libraries. You, personally, would likely stick to one ObjectSpace, but you may need to call into a library that uses a 1.5.2 object space, or a Prolog object space. Thus arises the concept that a function in one object space would have to call a function in another object space. But this meams that the Execution Context is not in a stable object space. In the parent function it has one object space, and when the library function is called, a function with a different object space is pushed onto the frame stack. Unless ... execution contexts can be nested. The calling function is in one execution context, and that spawns a daughter execution context in a different objectspace that handles the called function. The concept change (at least for me) is from that of a monolithic execution context that has global scope and static duration to more flexible execution contexts that have a more fleeting existence. In any case, the trick is interfacing between the different object spaces. A Prolog list does not behave like a Python list, so what happens when you try to concatanate them? This exchange of object spaces can happen in two locations - argument/return value passing and global values. I'm not sure how this should be handled. I'd advocate delaying the descision until we have two or more substantial object spaces we want to interface. But for initial musings, I'd probably caution against a mixed approach where each object retains it's semantics when it traverses into a different object space. It probably would get too confusing to track down bugs and dependancies, and the possible interactions would increase exponentially. (As well as defeting the purpouse of having seperate Object Spaces). I'd probably advocate for an interface based approach. As arguments are passed into a different object space, there are conversion routines which define how a particular object from one object space is converted into a native object in the other object space. The same happens in the reverse direction. If a cross-ObjectSpace global lookup occurs, the interpreter catches it and does the appropriate conversion. If it is nonsensical or impossible to convert the object, an exception is raised. A problem that immediately comes to mind is what to do about mutable objects which are passed to the function and then altered. How are they passed back? (What if the parent object space doesn't have "mutable" objects, but the called one does?) I hope that clears things up, -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?promos=380455 From lac at ratthing-b246.strakt.com Sun Mar 30 21:35:07 2003 From: lac at ratthing-b246.strakt.com (Laura Creighton) Date: Sun, 30 Mar 2003 21:35:07 +0200 Subject: [pypy-dev] I am back from 1 months' raod show. Message-ID: <200303301935.h2UJZ74v017833@ratthing-b246.strakt.com> Has this list gone dead? I went to reenable mail, and it seems I never disabled it. But I have received no mail on this in a month. I would like an irc meeting with pypy people at some time. When? I am back in europe now, and mornings and afternoons are both good for me though I will be going to python-uk next week. Laura From hpk at trillke.net Sun Mar 30 21:47:25 2003 From: hpk at trillke.net (holger krekel) Date: Sun, 30 Mar 2003 21:47:25 +0200 Subject: [pypy-dev] I am back from 1 months' raod show. In-Reply-To: <200303301935.h2UJZ74v017833@ratthing-b246.strakt.com>; from lac@ratthing-b246.strakt.com on Sun, Mar 30, 2003 at 09:35:07PM +0200 References: <200303301935.h2UJZ74v017833@ratthing-b246.strakt.com> Message-ID: <20030330214725.V21861@prim.han.de> [Laura Creighton Sun, Mar 30, 2003 at 09:35:07PM +0200] > Has this list gone dead? I went to reenable mail, and it seems I > never disabled it. But I have received no mail on this in a month. Yes, i think it has been quiet. ASFAIK Christian and me dropped out for complely external reasons and for my part, i haven't read much mail at all. I hopefully recover in two or three weeks and then also intend to resume work at pypy. So i would be interested to hear the current state of affairs, too. cheers, holger From lac at strakt.com Mon Mar 31 19:21:57 2003 From: lac at strakt.com (Laura Creighton) Date: Mon, 31 Mar 2003 19:21:57 +0200 Subject: [pypy-dev] I want to get PyPy EU funding Message-ID: <200303311721.h2VHLvXV023994@ratthing-b246.strakt.com> http://fp6.cordis.lu/fp6/call_details.cfm?CALL_ID=1 Can we schedule a meeting on irc some time to discuss doing this? Time is getting a bit short with an April deadline for next batch of proposals. I am at Python-UK next week, but will try to keep in touch. Laura From lac at strakt.com Mon Mar 31 19:25:26 2003 From: lac at strakt.com (Laura Creighton) Date: Mon, 31 Mar 2003 19:25:26 +0200 Subject: [pypy-dev] Alisair Burt on getting EU funding. Message-ID: <200303311725.h2VHPQnc024018@ratthing-b246.strakt.com> I say polish off our academic credentials, and also make the 'alternative to java for business' pitch and whatever else we can come up with as a good idea. Laura ------- Forwarded Message Return-Path: burt at dfki.de Sender: burt at dfki.de To: Laura Creighton Cc: lac at strakt.com Subject: EU Projects and Python From: Alastair Burt Date: Mon, 31 Mar 2003 18:10:34 +0200 Laura Creighton (2003-03-31): > I am interested in acquiring EU funding for Python in general, and the > PyPy project in particular. I realise that it is a long, involved, slow > process which takes years. (I've worked on EU projects before, just > never on the funding it end). I am here for the duration, but I need to > get taught what to do. Is this something that you would be willing to > teach me? If this teaching is something that you do professionally, I > would be most interested in taking a course, tutorial, or whatever else > it is that you do. I have some funding now, and matching funding is > something I want to investigate. Also I would be interested in doing > this via the Python Business Forum, where I am the Treasurer. I am not sure that I am the fountain of information that Nicolas thinks I am, and, to a large extent, I benefit from the infrastructure here at the DFKI. Here are some general points: - There are far more sources of EU funding than I know about. The main one for computing is the current IST call: http://fp6.cordis.lu/fp6/call_details.cfm?CALL_ID=1 You are probably too late for the April deadline but another one in October should be fine. There are other sources of funding for e-learning, cross border cooperation between neighbours (Interreg), e-content generation, e-government (from IDA). But I do not have more exact pointers to hand, or much experience in submission to them. - The EU is not going to fund simple application development per se. So somehow you are going to have to show that you innovating in the direction that the EU is explicitly funding, and you will probably want to work with a consortium whose goals are more general than language implementation. I think if were trying to get PyPy funded, I would try to build some bridges with academic research, and I would make it clear how PyPy fits in with the big ideas that the EU is funding, such as ambient computing. In as much as PyPy would seem to make Python more portable and implementable on small devices, I think you could make a good case here. - I guess having EU project administration experience in the consortium would not hurt. The DFKI could do this, but there are actually many small firms these days that specialise in this. You could use one of them and let them handle the paper work. - Whatever you do, having a trustworthy, balanced consortium is the key to a good proposal and successful execution. - The EU themselves are helpful. If you see an EU call that looks fruitful, email the project officer. They will give you pointers. I would like to see Python be advanced by EU funding. I am not sure how much help I can be, but if you have specific questions, just ask. - --- Alastair - --- - ---- Alastair Burt German Centre for AI (DFKI), Stuhlsatzenhausweg 3 Saarbr?cken 66123, Germany Email: burt at dfki.de Tel: +49 681 302 2565 Fax: +49 681 302 2235 http://www.aswad-project.org/ ------- End of Forwarded Message From hpk at trillke.net Mon Mar 31 20:30:25 2003 From: hpk at trillke.net (holger krekel) Date: Mon, 31 Mar 2003 20:30:25 +0200 Subject: [pypy-dev] I want to get PyPy EU funding In-Reply-To: <200303311721.h2VHLvXV023994@ratthing-b246.strakt.com>; from lac@strakt.com on Mon, Mar 31, 2003 at 07:21:57PM +0200 References: <200303311721.h2VHLvXV023994@ratthing-b246.strakt.com> Message-ID: <20030331203025.C21861@prim.han.de> [Laura Creighton Mon, Mar 31, 2003 at 07:21:57PM +0200] > http://fp6.cordis.lu/fp6/call_details.cfm?CALL_ID=1 > > Can we schedule a meeting on irc some time to discuss doing this? > Time is getting a bit short with an April deadline for next batch > of proposals. I am at Python-UK next week, but will try to keep > in touch. We talked about this at the last sprint already and i am interested. I still have no time to do much stuff relating to computers. If you could stop the war that would probably help a bit. greetings, holger From lac at strakt.com Mon Mar 31 20:35:31 2003 From: lac at strakt.com (Laura Creighton) Date: Mon, 31 Mar 2003 20:35:31 +0200 Subject: [pypy-dev] I want to get PyPy EU funding In-Reply-To: Message from holger krekel of "Mon, 31 Mar 2003 20:30:25 +0200." <20030331203025.C21861@prim.han.de> References: <200303311721.h2VHLvXV023994@ratthing-b246.strakt.com> <20030331203025.C21861@prim.han.de> Message-ID: <200303311835.h2VIZVnc024936@ratthing-b246.strakt.com> In a message of Mon, 31 Mar 2003 20:30:25 +0200, holger krekel writes: >[Laura Creighton Mon, Mar 31, 2003 at 07:21:57PM +0200] >> http://fp6.cordis.lu/fp6/call_details.cfm?CALL_ID=1 >> >> Can we schedule a meeting on irc some time to discuss doing this? >> Time is getting a bit short with an April deadline for next batch >> of proposals. I am at Python-UK next week, but will try to keep >> in touch. > >We talked about this at the last sprint already and i am >interested. > >I still have no time to do much stuff relating to >computers. If you could stop the war that would probably >help a bit. > >greetings, > > holger Oh Holger, if I _could_, I _would_ already .... Laura From arigo at tunes.org Mon Mar 31 22:52:51 2003 From: arigo at tunes.org (Armin Rigo) Date: Mon, 31 Mar 2003 12:52:51 -0800 (PST) Subject: [pypy-dev] Re: we need to discuss setting up a PyPy foundation and how In-Reply-To: <200303311528.h2VFSxc1023464@ratthing-b246.strakt.com>; from lac@strakt.com on Mon, Mar 31, 2003 at 05:28:59PM +0200 References: <200303311528.h2VFSxc1023464@ratthing-b246.strakt.com> Message-ID: <20030331205251.227645292@bespin.org> Hi Laura, On Mon, Mar 31, 2003 at 05:28:59PM +0200, Laura Creighton wrote: > to fund it. I have starter capital now. This is going to work. > We need a board so we can decide how to spend money. Oh oh. I see that you are trying to pull me into a money thing. All right, but I guess you are aware that I have no experience in the domain. But I would be glad to give directions on what I think could be interesting to finance. In fact I believe it would be very exciting to get funding for Python in general and PyPy in particular. Alisair talked about getting academic support and linking PyPy's potentially small footprint with embedded devices -- these are exactly the two areas where I can help. The EU project I'm part of since tomorrow is all about specialization (Psyco) for embedded devices. This gives strong links, even to the point that we could consider active collaboration between the two projects, and maybe use the existing EU project to financially spawn the PyPy project. Armin From lac at strakt.com Mon Mar 31 23:13:25 2003 From: lac at strakt.com (Laura Creighton) Date: Mon, 31 Mar 2003 23:13:25 +0200 Subject: [pypy-dev] Re: we need to discuss setting up a PyPy foundation and how In-Reply-To: Message from Armin Rigo of "Mon, 31 Mar 2003 12:52:51 -0800." <20030331205251.227645292@bespin.org> References: <200303311528.h2VFSxc1023464@ratthing-b246.strakt.com> <20030331205251.227645292@bespin.org> Message-ID: <200303312113.h2VLDPDa027943@theraft.strakt.com> In a message of Mon, 31 Mar 2003 12:52:51 -0800, Armin Rigo writes: >Hi Laura, > >On Mon, Mar 31, 2003 at 05:28:59PM +0200, Laura Creighton wrote: >> to fund it. I have starter capital now. This is going to work. >> We need a board so we can decide how to spend money. > >Oh oh. I see that you are trying to pull me into a money thing. All right, but >I guess you are aware that I have no experience in the domain. But I would be >glad to give directions on what I think could be interesting to finance. Cool. What we mostly need is your credentials. One of the reasons why we can tell the EU that it is not going to waste its money by giving us some is that your Psyco experience is exactly what they want. So we need to read them well enough that we can thoroughly answer the question 'what is it that the EU wants that we have got?'. Then you write that up, in painstaking detail, and call it a funding proposal. I have done this many times before, and this is the trick to getting funded. Answer the question 'what is it that you want that I have got' and then write that up. If you try to foolthem with promising them things they want but you do not have, then things go to hell quickly. But I think things are great for us. We only have to ask for money to do what we want to do, because they want us to do that. We just have to ask in such a way that makes it clear that we have common interest here. > >In fact I believe it would be very exciting to get funding for Python in >general and PyPy in particular. Alisair talked about getting academic sup >port >and linking PyPy's potentially small footprint with embedded devices -- t >hese >are exactly the two areas where I can help. The EU project I'm part of si >nce >tomorrow is all about specialization (Psyco) for embedded devices. This g >ives >strong links, even to the point that we could consider active collaborati >on >between the two projects, and maybe use the existing EU project to financ >ially >spawn the PyPy project. > > >Armin Sounds perfect to me. Laura