From lac at strakt.com Mon Jan 3 23:15:31 2005 From: lac at strakt.com (Laura Creighton) Date: Mon, 3 Jan 2005 23:15:31 +0100 Subject: [pypy-dev] Think we can stomach some Perl? Message-ID: <200501032215.j03MFVEh024258@ratthing-b246.strakt.com> Jordan Hayes has hacked together SWISH-E and Mailman. The result is Mailman archives you can search. I like this very much. He mentioned this on another list. There doesn't seem to be a way, currently, to restrict your search to between certain dates, but it seems an improvement on hunting through the archives by hand. Laura oh, yes: start here: http://infothecary.org/jordan/mailman.html Laura From hpk at trillke.net Tue Jan 4 13:24:49 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 4 Jan 2005 13:24:49 +0100 Subject: [pypy-dev] Leysin sprint / Squeak / CCC conference Message-ID: <20050104122449.GB32217@solar.trillke.net> Hi pypy-dev, on the last chaos communication congress (CCC 2004 in Berlin) i thankfully got to know Markus Denker from the University of Bern in Switzerland. He is involved with Squeak (http://www.squeak.org) and gave IMHO one of the most interesting "pypy-related" talks at the conference. He also saw my "getting EU funding for a FOSS project" talk and so we stood together a lot during the conference, talking about PyPy, Squeak, higher level languages being faster than C, EU funding and what not. (Btw, at http://codespeak.net/~hpk/2004-pypy-eu.pdf you'll find my Funding talk). However, Markus' talk was not only about Squeak, a smalltalk implementation written in a subset of smalltalk, but also about "Croquet" (http://www.opencroquet.org/) which is headed by Alan Kay, one of the fathers of object oriented programming. (see http://en.wikipedia.org/wiki/Alan_Kay for more info). Many of the features of Squeak/Croquet have been discussed during PyPy development and i am sure both sides can and may want to learn from each other. So i asked Markus if he would like to come to the PyPy sprint in Leysin for an afternoon, as it is pretty close to where he lives and works. He does! So what do you (especially sprint attendants) think about inviting him and letting him redo the talk about Squeak/Croquet and then we can then go into some deeper discussion over a beer or so? I am sure you will enjoy it as it arguably presents a vision of programming that is something like 5 years ahead of the mainstream in some ways. I'd like to tell you not too much before the sprint to allow you the same kind of suprises i had during Markus' talk :-) It would be great though, to be able to have a beamer at least for that day. He would probably also go a bit into explaining "Seaside", a continuation based web-framework that received some publicity lately (also on c.l.py). OK, now i am going to tell a bit more about the CCC-2004 conference and my impressions, while i am at it. This is not directly pypy-related so you may stop reading here :-) *** personal impressions from the CCC 2004 conference *** This year's conference broke all records: around 300 talks plus all kinds of workshops and sessions and 3500 (!) attendants mostly from security/network/system related areas but also quite a number of people from FOSS-projects such as MySQL, Apache, PHP, Ruby and what not. (As always, not a lot from the Python world, though). Moreover, Wikipedia held their annual meeting at the conference and presented some nice background talks ("Scaling above 1 Million"). Various BSD and Linux communities gathered in the cellar, around 500 people with laptops, called the "tiger" room :-) The schedule. It usually started at 11am and went on to 4am (AM i say). Food, Drinks and network was there 24 hours. There were no real breaks whatsoever which made sense considering that having 3000 people going for lunch would presumably lead to race conditions. A central room with lots of video installations (done by "Video Jockeys" doing their own track) provided a nice meeting place. We also played the game of "Go" there. There were tons of interesting talks, here is a selection of the ones i visited: "Practical OSX insecurities", which presented some funny security holes. Apple mailed the speaker in the morning to prevent him to disclose the holes, but it was too late :-) The guy lastly presented the first workable Mail-Worm on OSX, fully equipped with a scripted SMTP-engine and hiding itself as quite regular PDF-document attachment. "Hacking embedded devices" dealt with reverse-engeneering a 3COM 3300 switch, which is 68020 based and has it's own custom scripting language (!), 4 MB of RAM, a small operating system and what not. A nice target for running PyPy in it :-) "OpenBGP / ntpd", Henning Brauer from OpenBSD-fame gave a very quick and thorough talk on how development of production-quality software in OpenBSD-land takes place. "Bluetooth hacks: full disclosure". Many of you may know that since a year or so Adam Laury and his co-hackers found glazing holes in bluetooth implementations in mobile phones. At the time, some 50-70 percent of mobile phones were completly hackable, including modifying the address book, making GPRS calls, listening to your calls and what not. At the conference Adam provided a full disclosure including source code. "Old Skewl Hacking: Infra Red". Adam Laury gave another talk about his experiences hacking infra-reds of garage door systems, hotel information/minbar/TV systems, cars and what not. Very simple, very effective, very funny. My favorite quote of his revealing talk was "presumably it's strange hearing the sound of a 100 cars opening at the same time". Meanwhile, the german championship in lock-picking took place and, along with the "physical security" talk, it became obvious that even a 2000 Euro lock is far from unbreakable. A 12 year old kid managed to visit his first lock-picking workshop and be so successfull that he directly participated in the championship :-) "High-Speed Computing & Co-Processing with FPGAs" dealt with how to dynamically program hardware to carry out specialized tasks, providing speedups of up to a 100-times of a modern PC. You can get simple programmable arrays as a PCMCIA card or a full-blown PCI card with multiple parallel engines. The talker, David Hulton, actually comes from a company that tries to connect OpenSource and FPGAs. Sure interesting stuff, maybe also as a target for PyPy. The chaos conference also saw a number of political talks, regarding e.g. biometry, software patents or general foreign politics. It was interesting to see that more and more geeks are becoming politically aware and active these days. Well, that's it for now. During January, the Chaos Computer Club intends to make all talks available as Video/Audio as all talks (not workshops, though) were filmed and recorded. have fun & a nice new year, holger From lac at strakt.com Tue Jan 4 14:55:42 2005 From: lac at strakt.com (Laura Creighton) Date: Tue, 04 Jan 2005 14:55:42 +0100 Subject: [pypy-dev] Re: [pypy-sprint] Leysin sprint / Squeak / CCC conference In-Reply-To: Message from hpk@trillke.net (holger krekel) of "Tue, 04 Jan 2005 13:24:49 +0100." <20050104122449.GB32217@solar.trillke.net> References: <20050104122449.GB32217@solar.trillke.net> Message-ID: <200501041355.j04Dthgb004226@ratthing-b246.strakt.com> I think having Marcus Denker sounds terrific. Laura From hpk at trillke.net Thu Jan 6 11:47:58 2005 From: hpk at trillke.net (holger krekel) Date: Thu, 6 Jan 2005 11:47:58 +0100 Subject: [pypy-dev] [hpk@trillke.net: [codespeak-ann] server move - thursday (6th Jan. 2005)] Message-ID: <20050106104758.GB7439@solar.trillke.net> Hi pypy-dev, i figure that a number of maybe-interested people are not subscribed to the codespeak announce list, so here i forward an announcement which talks about server-moves/works later today. If you want to receive such news then subscribe to http://codespeak.net/mailman/listinfo/codespeak-ann cheers, holger ----- Forwarded message from holger krekel ----- Date: Mon, 3 Jan 2005 16:33:40 +0100 To: codespeak-ann at codespeak.net From: holger krekel Subject: [codespeak-ann] server move - thursday (6th Jan. 2005) X-Spambayes-Classification: ham; 0.00 Hello codespeak developers and users, next thursday, 6th of January 2005, Jens-Uwe Mager and me plan to move over codespeak services to a new dual-amd64 more failsafe machine, largely donated by Infrae from the Netherlands. Thanks! Also thanks to Helios from Germany who will continue to provide us with free hosting in their computing center. With a gentoo-setup built from scratch with NPTL (New Posix Thread Library) and some other enhancements we hope that especially the subversion setup stabilizes some more. We are going to deploy the subversion 1.1 series but we'll stay with the bsd-db backend (for various reasons). Please note: - We are not going much at new features during this move but rather for consistently mirroring and upgrading the current setup. - ssh-logins will probably see a modified host-key and thus you may receive a warning from your ssh-client. - We don't expect any large downtime but your mileage may vary, especially with respect to DNS-caching. - we may miss small bits and pieces, please bear with us and tell admin at codespeak.net about problems! If we don't fully complete the move on thursday we are going to spend the sunday (9th January) as well. cheers, holger _______________________________________________ codespeak-ann at codespeak.net http://codespeak.net/mailman/listinfo/codespeak-ann ----- End forwarded message ----- From arigo at tunes.org Thu Jan 6 20:42:45 2005 From: arigo at tunes.org (Armin Rigo) Date: Thu, 6 Jan 2005 19:42:45 +0000 Subject: [pypy-dev] Upcoming PyPy sprint In-Reply-To: <8773697B-6012-11D9-80F8-000A95909800@cern.ch> References: <20041225202303.GA16023@vicky.ecs.soton.ac.uk> <8773697B-6012-11D9-80F8-000A95909800@cern.ch> Message-ID: <20050106194245.GA14726@vicky.ecs.soton.ac.uk> Hi Jacek, On Thu, Jan 06, 2005 at 07:41:08PM +0100, Jacek Generowicz wrote: > I would like to come, but the timing is rather unfortunate and it looks > like I would not be able to attend the whole event. However, I would be > able to commute (from Geneva) on a few of the days. > > Would I be able to pick up some knowledge of PyPy by attending a few > days, or would it be a complete waste of everybody's time? Would you be able to attend the beginning of the sprint? I fear that near the end we might all be in "quickly-hack-a-bit-more-we-want-this-to-work" mode... but the beginning should definitely be interesting, and you are most welcome! Armin From arigo at tunes.org Thu Jan 6 20:57:11 2005 From: arigo at tunes.org (Armin Rigo) Date: Thu, 6 Jan 2005 19:57:11 +0000 Subject: [pypy-dev] Re: [pypy-sprint] Leysin sprint / Squeak / CCC conference In-Reply-To: <200501041355.j04Dthgb004226@ratthing-b246.strakt.com> References: <20050104122449.GB32217@solar.trillke.net> <200501041355.j04Dthgb004226@ratthing-b246.strakt.com> Message-ID: <20050106195711.GB14726@vicky.ecs.soton.ac.uk> Hi, On Tue, Jan 04, 2005 at 02:55:42PM +0100, Laura Creighton wrote: > I think having Marcus Denker sounds terrific. So do I :-) Sorry for the delay, skiing and snowboarding is quite a lot of fun here :-) Armin From schliep at molgen.mpg.de Fri Jan 7 12:04:10 2005 From: schliep at molgen.mpg.de (Alexander Schliep) Date: Fri, 7 Jan 2005 12:04:10 +0100 (MET) Subject: [pypy-dev] Running Python in reverse Message-ID: Hi everyone, Christian Tismer encouraged me to post the following directly to the pypy mailing list. My main Python project is Gato, a software for visualizing (or animating) graph algorithms; see http://gato.sourceforge.net/wiki/pmwiki.php/Main/Screenshots. The main ingredients of Gato are a debugger subclass, some GUI elements and code for drawing graphs. The goal is to have an interactive, dynamic version of the classical comp.sci. text book, where, typically, some graph algorithm is given as pseudo code and you see (at best) a before, during, and after snapshot picture of its working on some graph. Python is a perfectly fine replacement for pseudo code and the execution and directly coupled visualization, which you can control just like a debugger, convey much more than static pictures. Winfried Hochstaettler, some university colleagues, and myself have used this for teaching discrete math, combinatorial optimization and comp.sci.classes with quite favorable comments from everyone involved. The number one request was always the ability to track back. I started to implement an instant replay of the last visualization effect (change of color, blink etc.) and started to think about a proper way of supporting the ability to step back in time. This essentially boils down to implementing one of the classical design patterns for supporting unlimited undo (and redo), treating the visualization effects as commands. This decouples the state (values of all variables used) of the algorithm from the state of the visualization, hence running the algorithm after a couple of Undos is not possible (One could fake that by Redoing everything and then continuing execution). Supporting an update of all variables gets kind of messy in standard Python. A cleaner approach would be to have a Python interpreter which can run backwards. Christian thinks it would be feasible in PyPy. This actually would be extremely nice for a number of applications - teaching Python - teaching algorithms with Python - debugging in general I am somewhat embarrassed to ask for a feature without much to offer. But realistically, I cannot promise more than to be a tester and happy user. Best, Alexander PS: Gato is LGPL. The algorithms we have are copyright Springer, as we have a textbook & software package coming out this year. PPS: There is a C-syntax-based tool which can run backwards: http://www.dis.uniroma1.it/~demetres/Leonardo/Leonardo.html -- schliep at molgen.mpg.de http://algorithmics.molgen.mpg.de From hpk at trillke.net Fri Jan 7 12:28:31 2005 From: hpk at trillke.net (holger krekel) Date: Fri, 7 Jan 2005 12:28:31 +0100 Subject: [pypy-dev] Running Python in reverse In-Reply-To: References: Message-ID: <20050107112831.GL7439@solar.trillke.net> Hi Alexander, On Fri, Jan 07, 2005 at 12:04 +0100, Alexander Schliep wrote: > Christian Tismer encouraged me to post the following directly to the > pypy mailing list. > > My main Python project is Gato, a software for visualizing (or > animating) graph algorithms; see > http://gato.sourceforge.net/wiki/pmwiki.php/Main/Screenshots. The > main ingredients of Gato are a debugger subclass, some GUI elements > and code for drawing graphs. Looks really nice! > The goal is to have an interactive, dynamic version of the classical > comp.sci. text book, where, typically, some graph algorithm is given > as pseudo code and you see (at best) a before, during, and after > snapshot picture of its working on some graph. makes sense! > Python is a perfectly fine replacement for pseudo code and the > execution and directly coupled visualization, which you can control > just like a debugger, convey much more than static pictures. Winfried > Hochstaettler, some university colleagues, and myself have used this > for teaching discrete math, combinatorial optimization and > comp.sci.classes with quite favorable comments from everyone involved. > > The number one request was always the ability to track back. I started > to implement an instant replay of the last visualization effect > (change of color, blink etc.) and started to think about a proper way > of supporting the ability to step back in time. This essentially boils > down to implementing one of the classical design patterns for > supporting unlimited undo (and redo), treating the visualization > effects as commands. > > This decouples the state (values of all variables used) of the > algorithm from the state of the visualization, hence running the > algorithm after a couple of Undos is not possible (One could fake that > by Redoing everything and then continuing execution). Supporting an > update of all variables gets kind of messy in standard Python. Yes, i see the problem. At EuroPython 2004 there also was Michael Salib who also presented his wish to have a "time warp" debugger that allows to arbitrarily move within execution time of your program and see all the state. And IIRC, we have been discussing this between PyPy developers a bit sometimes under the term "History Object Space". An object space in PyPy encapsulates and manages all state of Python objects and all accesses and modifications take place through calling methods on such "Space" objects. > A cleaner approach would be to have a Python interpreter which can run > backwards. Christian thinks it would be feasible in PyPy. Rightfully so. I wouldn't call it "run backwards" though but to jump arbitrarily in execution and object states. > This actually would be extremely nice for a number of applications > - teaching Python > > - teaching algorithms with Python > > - debugging in general Yes, although for debugging in general there is the problem of "side effects" like dealing with files & sockets, databases etc.pp. > I am somewhat embarrassed to ask for a feature without much to offer. > But realistically, I cannot promise more than to be a tester and happy > user. Well, the question is if we could tackle the "History Space" (working title) at some sprint and you would attend and we would together incorporate the functionality into your application for the fun of it. I imagine a "time slider" that you can arbitrarily move forward and backward which should be feasible especially for pure algorithms like the ones you show on your Gato webpage. With such functionality you would not need to worry about limited "visualization undo" at all because you could just cleanly redraw. cheers, holger From hpk at trillke.net Fri Jan 7 12:39:41 2005 From: hpk at trillke.net (holger krekel) Date: Fri, 7 Jan 2005 12:39:41 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8078 - pypy/trunk/src/pypy/interpreter In-Reply-To: <20050105163548.30CFC5ACEF@thoth.codespeak.net> References: <20050105163548.30CFC5ACEF@thoth.codespeak.net> Message-ID: <20050107113941.GM7439@solar.trillke.net> On Wed, Jan 05, 2005 at 17:35 +0100, tismer at codespeak.net wrote: > Author: tismer > Date: Wed Jan 5 17:35:47 2005 > New Revision: 8078 > > Modified: > pypy/trunk/src/pypy/interpreter/pyopcode.py > Log: > changed LOAD_GLOBAL to support the flow space better. > In case of a NameError, where the space does not define NameError, > we raise a real NameError with a message. > > Modified: pypy/trunk/src/pypy/interpreter/pyopcode.py > ============================================================================== > --- pypy/trunk/src/pypy/interpreter/pyopcode.py (original) > +++ pypy/trunk/src/pypy/interpreter/pyopcode.py Wed Jan 5 17:35:47 2005 > @@ -525,8 +525,13 @@ > if not e.match(f.space, f.space.w_KeyError): > raise > message = "global name '%s' is not defined" % varname > - w_exc_type = f.space.w_NameError > - w_exc_value = f.space.wrap(message) > + try: > + w_exc_type = f.space.w_NameError > + w_exc_value = f.space.wrap(message) > + except AttributeError: > + # object space does not support it, so crash really > + raise NameError, (message + > + ", but %s has no NameError!" % f.space) > raise OperationError(w_exc_type, w_exc_value) > f.valuestack.push(w_value) I don't understand this change. Why is raising a NameError for not finding space.w_NameError better than just an AttributeError? This seems to me like mixing different levels (application level and interpreter level). It seems the flow object space could easily provide its own w_NameError and then you can check the usual way, catching an OperationError and then for e.match(space, space.w_NameError) without changing the interpreter. cheers (and happy new year to you, christian!), holger From arigo at tunes.org Fri Jan 7 18:31:13 2005 From: arigo at tunes.org (Armin Rigo) Date: Fri, 7 Jan 2005 17:31:13 +0000 Subject: [pypy-dev] Upcoming PyPy sprint In-Reply-To: <20050107115404.GA7062@logilab.fr> References: <20041225202303.GA16023@vicky.ecs.soton.ac.uk> <8773697B-6012-11D9-80F8-000A95909800@cern.ch> <20050106194245.GA14726@vicky.ecs.soton.ac.uk> <20050107115404.GA7062@logilab.fr> Message-ID: <20050107173113.GA1420@vicky.ecs.soton.ac.uk> Hi, On Fri, Jan 07, 2005 at 12:54:04PM +0100, Adrien Di Mascio wrote: > Ludovic and I won't be able to be there before the 24th. Is it be > possible for you (Pypy team) to keep some of the "Introducing PyPy" > part for Monday and Tuesday ? Yes, I guess so. Armin From arigo at tunes.org Fri Jan 7 19:09:24 2005 From: arigo at tunes.org (Armin Rigo) Date: Fri, 7 Jan 2005 18:09:24 +0000 Subject: [pypy-dev] Re: [pypy-svn] r8078 - pypy/trunk/src/pypy/interpreter In-Reply-To: <20050107113941.GM7439@solar.trillke.net> References: <20050105163548.30CFC5ACEF@thoth.codespeak.net> <20050107113941.GM7439@solar.trillke.net> Message-ID: <20050107180924.GA9960@vicky.ecs.soton.ac.uk> Hi, On Fri, Jan 07, 2005 at 12:39:41PM +0100, holger krekel wrote: > > Log: > > changed LOAD_GLOBAL to support the flow space better. > > In case of a NameError, where the space does not define NameError, > > we raise a real NameError with a message. > > (...). It seems the flow > object space could easily provide its own w_NameError and > then you can check the usual way, catching an OperationError and > then for e.match(space, space.w_NameError) without changing > the interpreter. I guess the goal is to have the problem crash the program with a meaningful error message. If the flow objspace provided a w_NameError, then it would become a normal exception within the flow graph, and you would end up compiling a program that contains an explicit "raise NameError". In this case it's better just to crash the flow objspace clearly. Maybe a nicer hack than Christian's can be found for this purpose, e.g. setting w_NameError to a special value that would trigger an (interp-level) AssertionError in the constructor of OperationError -- the advantage is that the AssertionError can provide the meaningful bit of information: the intended message of the faulty w_NameError. A bientot, Armin From hpk at trillke.net Fri Jan 7 19:40:09 2005 From: hpk at trillke.net (holger krekel) Date: Fri, 7 Jan 2005 19:40:09 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8078 - pypy/trunk/src/pypy/interpreter In-Reply-To: <20050107180924.GA9960@vicky.ecs.soton.ac.uk> References: <20050105163548.30CFC5ACEF@thoth.codespeak.net> <20050107113941.GM7439@solar.trillke.net> <20050107180924.GA9960@vicky.ecs.soton.ac.uk> Message-ID: <20050107184009.GQ7439@solar.trillke.net> On Fri, Jan 07, 2005 at 18:09 +0000, Armin Rigo wrote: > On Fri, Jan 07, 2005 at 12:39:41PM +0100, holger krekel wrote: > > > Log: > > > changed LOAD_GLOBAL to support the flow space better. > > > In case of a NameError, where the space does not define NameError, > > > we raise a real NameError with a message. > > > > (...). It seems the flow > > object space could easily provide its own w_NameError and > > then you can check the usual way, catching an OperationError and > > then for e.match(space, space.w_NameError) without changing > > the interpreter. > > I guess the goal is to have the problem crash the program with a meaningful > error message. If the flow objspace provided a w_NameError, then it would > become a normal exception within the flow graph, and you would end up > compiling a program that contains an explicit "raise NameError". In this case > it's better just to crash the flow objspace clearly. Probably, it depends on the exact context. But forgetting about this detail, I don't yet see the point of throwing a NameError instead of an AttributeError here with a slightly modified message. I mean if you see the lines like ... w_exc_type = f.space.w_NameError AtttributeError: 'FlowObjSpace' object has no attribute 'w_NameError' you'll now see (approximately): ... raise NameError, (message + ", but %s has no NameError!" % f.space) NameError: global name w_NameError is not defined, but FlowObjSpace has no NameError! why is the latter more helpful? > Maybe a nicer hack than Christian's can be found for this purpose, e.g. > setting w_NameError to a special value that would trigger an (interp-level) > AssertionError in the constructor of OperationError -- the advantage is that > the AssertionError can provide the meaningful bit of information: the intended > message of the faulty w_NameError. Makes sense. cheers, holger From arigo at tunes.org Fri Jan 7 20:10:29 2005 From: arigo at tunes.org (Armin Rigo) Date: Fri, 7 Jan 2005 19:10:29 +0000 Subject: [pypy-dev] Re: [pypy-svn] r8078 - pypy/trunk/src/pypy/interpreter In-Reply-To: <20050107184009.GQ7439@solar.trillke.net> References: <20050105163548.30CFC5ACEF@thoth.codespeak.net> <20050107113941.GM7439@solar.trillke.net> <20050107180924.GA9960@vicky.ecs.soton.ac.uk> <20050107184009.GQ7439@solar.trillke.net> Message-ID: <20050107191029.GA13970@vicky.ecs.soton.ac.uk> Hi Holger, On Fri, Jan 07, 2005 at 07:40:09PM +0100, holger krekel wrote: > you'll now see (approximately): > NameError: global name w_NameError is not defined, but FlowObjSpace > has no NameError! No, the point is that you'll now see: NameError: global name xyzzy is not defined, but FlowObjSpace has no NameError! where 'xyzzy' is the name of the particular variable in the user source code that is not defined. Armin From hpk at trillke.net Fri Jan 7 20:30:45 2005 From: hpk at trillke.net (holger krekel) Date: Fri, 7 Jan 2005 20:30:45 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8078 - pypy/trunk/src/pypy/interpreter In-Reply-To: <20050107191029.GA13970@vicky.ecs.soton.ac.uk> References: <20050105163548.30CFC5ACEF@thoth.codespeak.net> <20050107113941.GM7439@solar.trillke.net> <20050107180924.GA9960@vicky.ecs.soton.ac.uk> <20050107184009.GQ7439@solar.trillke.net> <20050107191029.GA13970@vicky.ecs.soton.ac.uk> Message-ID: <20050107193045.GZ7439@solar.trillke.net> Hi Armin, On Fri, Jan 07, 2005 at 19:10 +0000, Armin Rigo wrote: > On Fri, Jan 07, 2005 at 07:40:09PM +0100, holger krekel wrote: > > you'll now see (approximately): > > NameError: global name w_NameError is not defined, but FlowObjSpace > > has no NameError! > > No, the point is that you'll now see: > > NameError: global name xyzzy is not defined, but FlowObjSpace > has no NameError! > > where 'xyzzy' is the name of the particular variable in the user source code > that is not defined. ah ok, right. But your suggestion of providing a specific w_NameError (maybe just None) and an appropriate assertion in OperationError.__init__ still sounds nicer and more generic. holger From adimasci at gmail.com Fri Jan 7 21:16:27 2005 From: adimasci at gmail.com (Adrien Di Mascio) Date: Fri, 7 Jan 2005 21:16:27 +0100 Subject: [pypy-dev] Common Lisp translation broken Message-ID: <437de85005010712166848baba@mail.gmail.com> Hi all, I'm just beginning to play around with PyPy, and I got a traceback when trying to translate Python code to CL code. Here's the traceback : ######### >>> t = Translator(test.if_then_else) >>> t.cl() Traceback (most recent call last): File "", line 1, in ? File "translator.py", line 165, in cl return self.generatecode(GenCL, input_arg_types, func) File "translator.py", line 184, in generatecode self.entrypoint, ann)] File "translator.py", line 205, in generatecode1 return g.emitcode(public) TypeError: emitcode() takes exactly 1 argument (2 given) >>> ######### A quick and dirty (partial) fix could be to add a "public=True" argument to the GenCL.emitcode() method, but I'm just a PyPy newbie for now, I don't really know how everything works and I'm not a Lisp Expert, so ... I just raise up the error here :-) Cheers, Adrien. From Adrien.DiMascio at logilab.fr Thu Jan 6 22:02:17 2005 From: Adrien.DiMascio at logilab.fr (Adrien Di Mascio) Date: Thu, 6 Jan 2005 22:02:17 +0100 Subject: [pypy-dev] Upcoming PyPy sprint In-Reply-To: <20050106194245.GA14726@vicky.ecs.soton.ac.uk> References: <20041225202303.GA16023@vicky.ecs.soton.ac.uk> <8773697B-6012-11D9-80F8-000A95909800@cern.ch> <20050106194245.GA14726@vicky.ecs.soton.ac.uk> Message-ID: <20050106210217.GA1157@crater.logilab.fr> Hi there, [Sorry, this should probably not be sent to pypy-dev, but I'm just answering Armin's mail] On Thu, Jan 06, 2005 at 07:42:45PM +0000, Armin Rigo wrote: > > Would I be able to pick up some knowledge of PyPy by attending a few > > days, or would it be a complete waste of everybody's time? > > Would you be able to attend the beginning of the sprint? I fear that near the > end we might all be in "quickly-hack-a-bit-more-we-want-this-to-work" > mode... but the beginning should definitely be interesting, and you are most > welcome! Ludovic and I won't be able to be there before the 24th. Is it be possible for you (Pypy team) to keep some of the "Introducing PyPy" part for Monday and Tuesday ? It not, well ..., we'll try to hack on PyPy as best as we can, but you'll have to be lenient with us ;-) Cheers, Adrien. -- Adrien Di Mascio LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org From tismer at stackless.com Sun Jan 9 23:15:18 2005 From: tismer at stackless.com (Christian Tismer) Date: Sun, 09 Jan 2005 23:15:18 +0100 Subject: [pypy-dev] genrpy is ready so far. Message-ID: <41E1ACF6.8090605@stackless.com> Hi Armin, all, I've put quite some work into genrpy.py in the last few weeks. It seems to produce usefulcode, although it could of course be nicer with some more effort. The speed effect appears to be somewhere around 40% over interpreted appspace code, not really disappointing, but also not really overwhelming. The real effect of such translation lies probably in opening things to further optimization in a later code generation step. The code works fine with _formatting.py, md5.py and strutil.py. These all appear to obey RPython restrictions, as probably many others. There are some enhancements possible: Right now, I'm using the flow space as it is, but I do not try to create specialized functions for constant arguments. Flow space provides some way to do this, but translator doesn't allow it. I'm thinking to play with this. It would make much sense in the md5 module, where many small functions with constant arguments could be curryfied. In effect, with some more support, the flowspace could identify more constants than it does now. The way I'm creating the function interfaces is working, but less than optimum. I stupidly followed the pattern that Armin used for C code generation. Later on I figured out that I could create functions with names and default arguments directly. Armin, I'm referring to the distinction of f_ and fastf_. Instead of using the pattern def f_(space, *args_w) and later plumbing the defaults in, I could have done it in the function header, directly. I will enhance this later, provided that we want to use this module at all. How do we want to integrate this stuff? First I think it needs a different name. Then, there is the question whether there should be one huge module generated from the union of all app-space implementations, or if there should be onefile for every app-spacemodule part? I thought of acontainerlike pypy.appspace.generated where all stuff could be accumulated. Do we want togenerate stuff on demand, based upon modification time of modules, or better do it by hand? Another questio is if it is so good to loose all the local names early,or if I should try to regenerate local names wherever possible? Another thing I was considering is not to create all these goto blocks, but to turn them into simple functions. This would give us massive recursion, but if we add a tail recursion feature to pypy, this would show up quite nicely. It would make the source shorter and would really allow to use given local names, because each code block has its own closure, then. I have done a lot of local tests. The test code is still sitting in the module and should go elsewhere. I did not yet tryto integrate it into the app space calls of stdobjspace. This is easy to do,but I need consensus how wewant this to happen. Please review. You can select a few test functions by changing line 1084. For the current main function, you need to create an importable appspace/generated folder. You also will needto change the temp output file for your needs, at the moment this is "d:/tmp/look.py" :-) I will supply a real entrypoint and a cleaner interface when I have some feedback. all the best -- chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Sun Jan 9 23:21:42 2005 From: tismer at stackless.com (Christian Tismer) Date: Sun, 09 Jan 2005 23:21:42 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8078 - pypy/trunk/src/pypy/interpreter In-Reply-To: <20050107180924.GA9960@vicky.ecs.soton.ac.uk> References: <20050105163548.30CFC5ACEF@thoth.codespeak.net> <20050107113941.GM7439@solar.trillke.net> <20050107180924.GA9960@vicky.ecs.soton.ac.uk> Message-ID: <41E1AE76.5020801@stackless.com> Armin Rigo wrote: > Hi, > > On Fri, Jan 07, 2005 at 12:39:41PM +0100, holger krekel wrote: > >>>Log: >>>changed LOAD_GLOBAL to support the flow space better. >>>In case of a NameError, where the space does not define NameError, >>>we raise a real NameError with a message. >> >>(...). It seems the flow >>object space could easily provide its own w_NameError and >>then you can check the usual way, catching an OperationError and >>then for e.match(space, space.w_NameError) without changing >>the interpreter. No, I tried that in the last sprint, but Armin hit my fingers and said "no no, we *want* to crash here!", which is correct. So I thought to crash with a useful message, instead. > I guess the goal is to have the problem crash the program with a meaningful > error message. If the flow objspace provided a w_NameError, then it would > become a normal exception within the flow graph, and you would end up > compiling a program that contains an explicit "raise NameError". In this case > it's better just to crash the flow objspace clearly. Exactly. An errorof this kind is usually a bug in the source code, and actually I found one in _formatting. > Maybe a nicer hack than Christian's can be found for this purpose, e.g. > setting w_NameError to a special value that would trigger an (interp-level) > AssertionError in the constructor of OperationError -- the advantage is that > the AssertionError can provide the meaningful bit of information: the intended > message of the faulty w_NameError. Sure, there are better ways. For me, having the real name error instead of a simple crash was extremely helpful, because I finally wanted to get that translation out of the door. :-) But don't allow a NameError, because that is a violation of the flow space's contract: Global names are constants and must exist. ciao - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From jacek.generowicz at cern.ch Sun Jan 9 20:24:44 2005 From: jacek.generowicz at cern.ch (Jacek Generowicz) Date: Sun, 9 Jan 2005 20:24:44 +0100 Subject: [pypy-dev] Upcoming PyPy sprint In-Reply-To: <20050106194245.GA14726@vicky.ecs.soton.ac.uk> References: <20041225202303.GA16023@vicky.ecs.soton.ac.uk> <8773697B-6012-11D9-80F8-000A95909800@cern.ch> <20050106194245.GA14726@vicky.ecs.soton.ac.uk> Message-ID: <1E1FD05E-6274-11D9-80F8-000A95909800@cern.ch> On 6 Jan 2005, at 20:42, Armin Rigo wrote: > Would you be able to attend the beginning of the sprint? Yes. Thursday 27th is impossible for me, otherwise it's a question of how much time I can permit myself to take off work right now. I could probably come Sun-Wed. Which day were you planning for the winter sports? From arigo at tunes.org Mon Jan 10 12:00:23 2005 From: arigo at tunes.org (Armin Rigo) Date: Mon, 10 Jan 2005 11:00:23 +0000 Subject: [pypy-dev] Upcoming PyPy sprint In-Reply-To: <1E1FD05E-6274-11D9-80F8-000A95909800@cern.ch> References: <20041225202303.GA16023@vicky.ecs.soton.ac.uk> <8773697B-6012-11D9-80F8-000A95909800@cern.ch> <20050106194245.GA14726@vicky.ecs.soton.ac.uk> <1E1FD05E-6274-11D9-80F8-000A95909800@cern.ch> Message-ID: <20050110110023.GA8206@vicky.ecs.soton.ac.uk> Hi, On Sun, Jan 09, 2005 at 08:24:44PM +0100, Jacek Generowicz wrote: > Which day were you planning for the winter sports? This is not fixed yet, but should be near the middle of the sprint. As you're so far the only person leaving Wednesday, we can move it to Wednesday or Thursday depending on whether you'd like to participate or not. Armin From jacek.generowicz at cern.ch Mon Jan 10 12:56:51 2005 From: jacek.generowicz at cern.ch (Jacek Generowicz) Date: Mon, 10 Jan 2005 12:56:51 +0100 Subject: [pypy-dev] Upcoming PyPy sprint In-Reply-To: <20050110110023.GA8206@vicky.ecs.soton.ac.uk> References: <20041225202303.GA16023@vicky.ecs.soton.ac.uk> <8773697B-6012-11D9-80F8-000A95909800@cern.ch> <20050106194245.GA14726@vicky.ecs.soton.ac.uk> <1E1FD05E-6274-11D9-80F8-000A95909800@cern.ch> <20050110110023.GA8206@vicky.ecs.soton.ac.uk> Message-ID: On 10 Jan 2005, at 12:00, Armin Rigo wrote: > Hi, > > On Sun, Jan 09, 2005 at 08:24:44PM +0100, Jacek Generowicz wrote: > > Which day were you planning for the winter sports? > > This is not fixed yet, but should be near the middle of the sprint.? > As you're > so far the only person leaving Wednesday, we can move it to Wednesday > or > Thursday depending on whether you'd like to participate or not. I'd like to participate ... but I can't afford to take a day off just to go skiing, at this time. So I must, reluctantly, vote for it being on Thursday :-( From pedronis at strakt.com Mon Jan 10 18:58:28 2005 From: pedronis at strakt.com (Samuele Pedroni) Date: Mon, 10 Jan 2005 18:58:28 +0100 Subject: [pypy-dev] tests porting status Message-ID: <41E2C244.80607@strakt.com> All tests apart appspace tests and some tests in tool/test are ported to py.test. The tool/test are easy to address. Given that appspace tests are currently run through CPython I wonder whether it would make sense to merge the branch, porting the few tests that were added to the head after the branch creation and think how to address exactly the appspace tests issue after that directly on the head. This would allow whatever work is going to happen on the head between now and the sprint to use py.test tests. Samuele. From hpk at trillke.net Mon Jan 10 19:13:23 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 10 Jan 2005 19:13:23 +0100 Subject: [pypy-dev] tests porting status In-Reply-To: <41E2C244.80607@strakt.com> References: <41E2C244.80607@strakt.com> Message-ID: <20050110181323.GI7439@solar.trillke.net> Hi Samuele, On Mon, Jan 10, 2005 at 18:58 +0100, Samuele Pedroni wrote: > All tests apart appspace tests and some tests in tool/test are ported to > py.test. great. > The tool/test are easy to address. > > Given that appspace tests are currently run through CPython I wonder > whether it would make sense to merge the branch, porting the few tests > that were added to the head after the branch creation and think how to > address exactly the appspace tests issue after that directly on the head. I have done some work on the appspace tests to let them run under PyPy. I may try to get my fixes and extensions to appspace-tests in but we don't need to wait with the trunk-merge for that. But, to be honest, our whole "appspace" organization is is kind of broken. I suggest that we try to integrate CPython's regression tests in a more automateable and more systematic way. > This would allow whatever work is going to happen on the head between > now and the sprint to use py.test tests. I generally agree. However, i don't know how well py.test works on Windows, yet. There are apparently people using it on windows but i haven't checked myself and don't know a complete status. It would be good to check that PyPy's py-tests do run on Win32 before merging with the branch. (The tests apparently work under OSX and linux at least). cheers, holger From tismer at stackless.com Mon Jan 10 19:46:54 2005 From: tismer at stackless.com (Christian Tismer) Date: Mon, 10 Jan 2005 19:46:54 +0100 Subject: [pypy-dev] flow space and UnboundLocalError! Eek! Message-ID: <41E2CD9E.9000004@stackless.com> Hi friends, I was playing with generated RPy functions, and just for fun, I ran my generator over its output. That should give an RPython interpreter for the whole pypy implementation. Not too useful, but nice to look at, better than disassembly :-) Here *the problem*: When I run flow space over my attached generated function, it crashes with an UnboundLocalError: w_26. This *is not* an error, because all the paths can only be walked in the order enforced by the big goto loop. But the flow space seems to step into a problem here. Well, flow space tries every branch, and most probably without looking at the data. Question: Is it possible to change the flow space to just ignore unbound variables? Or is this kind of code to be defined as NOT_RPYTHON ? The latter would be very bad, since I'm trying to create RPython, so it should be. An ugly solution would be to initialize all variables to some default. Please let me know ASAP -- ciao - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: look.py URL: From mwh at python.net Tue Jan 11 12:31:06 2005 From: mwh at python.net (Michael Hudson) Date: Tue, 11 Jan 2005 11:31:06 +0000 Subject: [pypy-dev] Re: genrpy is ready so far. References: <41E1ACF6.8090605@stackless.com> Message-ID: <2mk6qkfbid.fsf@starship.python.net> Christian Tismer writes: > Hi Armin, all, > > I've put quite some work into genrpy.py in the last > few weeks. It seems to produce usefulcode, although > it could of course be nicer with some more effort. > > The speed effect appears to be somewhere around 40% > over interpreted appspace code, not really disappointing, > but also not really overwhelming. > > The real effect of such translation lies probably in > opening things to further optimization in a later > code generation step. > > The code works fine with > _formatting.py, md5.py and strutil.py. These all > appear to obey RPython restrictions, as probably > many others. Hmm! Could we use this to make an interpreter-level implementation of the argument parsing code from a nice clear application level implementation? Or does this still result in hideous circularities? Probably. Oh well. Cheers, mwh -- Lisp does badly because we refuse to lie. When people ask us if we can solve insoluble problems we say that we can't, and because they expect us to lie to them, they find some other language where the truth is less respected. -- Tim Bradshaw, comp.lang.lisp From tismer at stackless.com Tue Jan 11 13:43:27 2005 From: tismer at stackless.com (Christian Tismer) Date: Tue, 11 Jan 2005 13:43:27 +0100 Subject: [pypy-dev] Re: genrpy is ready so far. In-Reply-To: <2mk6qkfbid.fsf@starship.python.net> References: <41E1ACF6.8090605@stackless.com> <2mk6qkfbid.fsf@starship.python.net> Message-ID: <41E3C9EF.3040003@stackless.com> Michael Hudson wrote: ... > Hmm! Could we use this to make an interpreter-level implementation of > the argument parsing code from a nice clear application level > implementation? Or does this still result in hideous circularities? > Probably. Oh well. I think we could try this. We can look at circularities quite easily. Just for fun, I have run genrpy twice over a function. That creates the whole interpreter as a nice single huge Python source file. Although this doesn't make too much sense for producing the 'real' code, it procides a new way to do source analysis. You know that everything is in the file, the whole interpreter, you can single step, add debug calls, whatsoever, without having to hack around in the real sources. well, I'll continue with this. Would like to run the huge file. At the moment, I have real trouble with old-style class instances. No idea how to create them, they seem to be not correctly wrapped. cheers - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From hpk at trillke.net Tue Jan 11 14:11:22 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 11 Jan 2005 14:11:22 +0100 Subject: [pypy-dev] Re: genrpy is ready so far. In-Reply-To: <2mk6qkfbid.fsf@starship.python.net> References: <41E1ACF6.8090605@stackless.com> <2mk6qkfbid.fsf@starship.python.net> Message-ID: <20050111131122.GS7439@solar.trillke.net> On Tue, Jan 11, 2005 at 11:31 +0000, Michael Hudson wrote: > Christian Tismer writes: > > > Hi Armin, all, > > > > I've put quite some work into genrpy.py in the last > > few weeks. It seems to produce usefulcode, although > > it could of course be nicer with some more effort. > > > > The speed effect appears to be somewhere around 40% > > over interpreted appspace code, not really disappointing, > > but also not really overwhelming. > > > > The real effect of such translation lies probably in > > opening things to further optimization in a later > > code generation step. > > > > The code works fine with > > _formatting.py, md5.py and strutil.py. These all > > appear to obey RPython restrictions, as probably > > many others. > > Hmm! Could we use this to make an interpreter-level implementation of > the argument parsing code from a nice clear application level > implementation? Or does this still result in hideous circularities? > Probably. Oh well. We decided that we had enough of hideous circularities in this area some time ago :-) So we don't have app-level code for argument parsing anymore, i think. It turned out that the interp-level code wasn't really that bad (in interpreter/argument.py). cheers, holger From mwh at python.net Tue Jan 11 14:54:19 2005 From: mwh at python.net (Michael Hudson) Date: Tue, 11 Jan 2005 13:54:19 +0000 Subject: [pypy-dev] Re: genrpy is ready so far. References: <41E1ACF6.8090605@stackless.com> <2mk6qkfbid.fsf@starship.python.net> <20050111131122.GS7439@solar.trillke.net> Message-ID: <2mfz18f4vo.fsf@starship.python.net> hpk at trillke.net (holger krekel) writes: > We decided that we had enough of hideous circularities in this > area some time ago :-) So we don't have app-level code for argument > parsing anymore, i think. It turned out that the interp-level > code wasn't really that bad (in interpreter/argument.py). Yes, but that arguably isn't RPythonic in the way it uses dictionaries. Cheers, mwh -- This makes it possible to pass complex object hierarchies to a C coder who thinks computer science has made no worthwhile advancements since the invention of the pointer. -- Gordon McMillan, 30 Jul 1998 From tismer at stackless.com Tue Jan 11 15:56:23 2005 From: tismer at stackless.com (Christian Tismer) Date: Tue, 11 Jan 2005 15:56:23 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8201 - pypy/trunk/src/pypy/appspace In-Reply-To: <20050111075841.478E327BB3@code1.codespeak.net> References: <20050111075841.478E327BB3@code1.codespeak.net> Message-ID: <41E3E917.1080103@stackless.com> ale at codespeak.net wrote: > Author: ale > Date: Tue Jan 11 08:58:40 2005 > New Revision: 8201 > > Added: > pypy/trunk/src/pypy/appspace/struct.py > Log: > Added the start of a struct module. It is not quite finished yet. > > The structure of the code is basically as in structmodule.c. > But some python goodies has been used - if that makes the > module less RPython I don't know. No, I think this is absolutely fine. I could translate it to RPython, and it works. See attached module. (The implementation will improve, but this is at least a proof that you wrote RPython) ciao - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Tue Jan 11 15:59:10 2005 From: tismer at stackless.com (Christian Tismer) Date: Tue, 11 Jan 2005 15:59:10 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8201 - pypy/trunk/src/pypy/appspace In-Reply-To: <20050111075841.478E327BB3@code1.codespeak.net> References: <20050111075841.478E327BB3@code1.codespeak.net> Message-ID: <41E3E9BE.80305@stackless.com> ale at codespeak.net wrote: > Author: ale > Date: Tue Jan 11 08:58:40 2005 > New Revision: 8201 > > Added: > pypy/trunk/src/pypy/appspace/struct.py > Log: > Added the start of a struct module. It is not quite finished yet. > > The structure of the code is basically as in structmodule.c. > But some python goodies has been used - if that makes the > module less RPython I don't know. No, I think this is absolutely fine. I could translate it to RPython, and it works. See attached module. (The implementation will improve, but this is at least a proof that you wrote RPython) ciao - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Tue Jan 11 16:01:25 2005 From: tismer at stackless.com (Christian Tismer) Date: Tue, 11 Jan 2005 16:01:25 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8201 - pypy/trunk/src/pypy/appspace In-Reply-To: <41E3E9BE.80305@stackless.com> References: <20050111075841.478E327BB3@code1.codespeak.net> <41E3E9BE.80305@stackless.com> Message-ID: <41E3EA45.4010702@stackless.com> Christian Tismer wrote: > ale at codespeak.net wrote: > >> Author: ale >> Date: Tue Jan 11 08:58:40 2005 >> New Revision: 8201 >> >> Added: >> pypy/trunk/src/pypy/appspace/struct.py >> Log: >> Added the start of a struct module. It is not quite finished yet. >> >> The structure of the code is basically as in structmodule.c. >> But some python goodies has been used - if that makes the >> module less RPython I don't know. > > > No, I think this is absolutely fine. > I could translate it to RPython, and it works. > See attached module. (The implementation will improve, > but this is at least a proof that you wrote RPython) Eeek, I don't get an attached zip file through the list. should I put a file somewhere in the repos? Where? ciao - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From hpk at trillke.net Tue Jan 11 16:10:35 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 11 Jan 2005 16:10:35 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8201 - pypy/trunk/src/pypy/appspace In-Reply-To: <41E3EA45.4010702@stackless.com> References: <20050111075841.478E327BB3@code1.codespeak.net> <41E3E9BE.80305@stackless.com> <41E3EA45.4010702@stackless.com> Message-ID: <20050111151035.GU7439@solar.trillke.net> On Tue, Jan 11, 2005 at 16:01 +0100, Christian Tismer wrote: > Christian Tismer wrote: > >ale at codespeak.net wrote: > > > >>Author: ale > >>Date: Tue Jan 11 08:58:40 2005 > >>New Revision: 8201 > >> > >>Added: > >> pypy/trunk/src/pypy/appspace/struct.py > >>Log: > >>Added the start of a struct module. It is not quite finished yet. > >> > >>The structure of the code is basically as in structmodule.c. > >>But some python goodies has been used - if that makes the > >>module less RPython I don't know. > > > > > >No, I think this is absolutely fine. > >I could translate it to RPython, and it works. > >See attached module. (The implementation will improve, > >but this is at least a proof that you wrote RPython) > > Eeek, I don't get an attached zip file through the list. > should I put a file somewhere in the repos? Where? In this case I'd probably put just it somewhere on the web, for example in your public_html directory on codespeak so that it becomes available as http://codespeak.net/~tismer/... cheers, holger From tismer at stackless.com Tue Jan 11 16:18:33 2005 From: tismer at stackless.com (Christian Tismer) Date: Tue, 11 Jan 2005 16:18:33 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8201 - pypy/trunk/src/pypy/appspace In-Reply-To: <20050111151035.GU7439@solar.trillke.net> References: <20050111075841.478E327BB3@code1.codespeak.net> <41E3E9BE.80305@stackless.com> <41E3EA45.4010702@stackless.com> <20050111151035.GU7439@solar.trillke.net> Message-ID: <41E3EE49.8040604@stackless.com> Hi Holger, >>Eeek, I don't get an attached zip file through the list. >>should I put a file somewhere in the repos? Where? > > > In this case I'd probably put just it somewhere on the web, > for example in your public_html directory on codespeak so > that it becomes available as http://codespeak.net/~tismer/... Ah, great! The ugly file can be read here: http://codespeak.net/~tismer/struct.genrpy.py I swear to produce nicer code in the future, maybe by using small tail-called functions instead og goto blocks. ciao - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From schliep at molgen.mpg.de Tue Jan 11 16:51:54 2005 From: schliep at molgen.mpg.de (Alexander Schliep) Date: Tue, 11 Jan 2005 16:51:54 +0100 (MET) Subject: [pypy-dev] Running Python in reverse In-Reply-To: <20050107201633.794FB27B99@code1.codespeak.net> Message-ID: On Fri, 7 Jan 2005 hpk at trillke.net (holger krekel) wrote: > ... > Yes, i see the problem. At EuroPython 2004 there also was Michael Salib > who also presented his wish to have a "time warp" debugger that allows > to arbitrarily move within execution time of your program and see all > the state. And IIRC, we have been discussing this between PyPy developers This sounds like the same general idea. > ... > Rightfully so. I wouldn't call it "run backwards" though but to jump > arbitrarily in execution and object states. The visualization would look like running backwards; technically you are correct. > Yes, although for debugging in general there is the problem of > "side effects" like dealing with files & sockets, databases etc.pp. Fortunately, this is not a problem for me. > Well, the question is if we could tackle the "History Space" (working > title) at some sprint and you would attend and we would together incorporate It will be really difficult for me to attend sprints, I already travel way too much. I'd be glad though to start to code towards extending Gato. Does it make it a lot of sense to run the whole tkinter app in pypy, or would we just have an embedded pypy-interpreter for the algorithm? Do you have suggestions how to setup the whole thing? Right now I just execfile the algorithm under debugger control. The algorihms calls the visualisation commands as side effects when doing interesting stuff (put a vertex on a queue). The debugger calls the idle_task etc. to keep the GUI alive, whenever something happens. > the functionality into your application for the fun of it. I imagine > a "time slider" that you can arbitrarily move forward and backward > ... Basically like VCR controls. I'd add "run backwards" or so. Best, Alexander From arigo at tunes.org Tue Jan 11 17:23:45 2005 From: arigo at tunes.org (Armin Rigo) Date: Tue, 11 Jan 2005 16:23:45 +0000 Subject: [pypy-dev] Common Lisp translation broken In-Reply-To: <437de85005010712166848baba@mail.gmail.com> References: <437de85005010712166848baba@mail.gmail.com> Message-ID: <20050111162345.GA30261@vicky.ecs.soton.ac.uk> Hi Adrien, On Fri, Jan 07, 2005 at 09:16:27PM +0100, Adrien Di Mascio wrote: > TypeError: emitcode() takes exactly 1 argument (2 given) > > A quick and dirty (partial) fix could be to add a "public=True" > argument to the GenCL.emitcode() method, but I'm just a PyPy newbie > for now, I don't really know how everything works and I'm not a Lisp > Expert, so ... I just raise up the error here :-) I checked this fix in. It seems that "public" was needed by the Pyrex generator, but the CL generator doesn't know what to do with that (at least for now), so it should just ignore it. Armin From hpk at trillke.net Tue Jan 11 19:04:26 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 11 Jan 2005 19:04:26 +0100 Subject: [pypy-dev] Running Python in reverse In-Reply-To: References: <20050107201633.794FB27B99@code1.codespeak.net> Message-ID: <20050111180426.GW7439@solar.trillke.net> Hi Aleanxder, On Tue, Jan 11, 2005 at 16:51 +0100, Alexander Schliep wrote: > On Fri, 7 Jan 2005 hpk at trillke.net (holger krekel) wrote: > > Well, the question is if we could tackle the "History Space" (working > > title) at some sprint and you would attend and we would together incorporate > > It will be really difficult for me to attend sprints, I already travel way > too much. I'd be glad though to start to code towards extending Gato. > > Does it make it a lot of sense to run the whole tkinter app in pypy, not yet and not for quite some time, i guess. > or would we just have an embedded pypy-interpreter for the algorithm? This is possible although it will not be very fast (unless PyPy can already translate your functions to C, possibly even with type inference in which case it might run at C-speed). > Do you have suggestions how to setup the whole thing? Running a module or some function through PyPy (on top of a CPython version) is rather easy. The work starts at the need to implement the history funcionality. This is likely doable during (part of) a sprint, especially since we already have the TraceObjectSpace which does something similar. However, it would be interesting if we discuss a higher level API that you would like to have in order to integrate it into Gato. cheers, holger From arigo at tunes.org Tue Jan 11 19:07:21 2005 From: arigo at tunes.org (Armin Rigo) Date: Tue, 11 Jan 2005 18:07:21 +0000 Subject: [pypy-dev] Re: genrpy is ready so far. In-Reply-To: <41E1ACF6.8090605@stackless.com> References: <41E1ACF6.8090605@stackless.com> Message-ID: <20050111180721.GB30261@vicky.ecs.soton.ac.uk> Hi Christian, Very nice work ! > First I think it needs a different name. geninterplevel.py maybe ..? Here's some more feedback on the questions as you put them in the source... > - do we want to auto-generate stuff? > - do we wantamoduleperapp-spaceoperation? We should probably auto-generate the stuff, using the py.tool.cache mecanisms. If we do so, then the files we generate should have a corresponding granularity. I think that we can easily list all app-level helpers of the same module (gateways know each others to be able to call each others). Then we could translate one-module-at-a-time. With md5 checksums or whatever :-) > - do we want to create code that is more similar to the app code? I have mixed feelings about this. My initial reaction is "no" but then there are use cases for the object space knowing a bit more about the names that the interpreter gives to the objects... for example, for a debugging "history object space" it would be convenient to record the movements within the local variables too. Not sure how to do that or if the same thing can be reused for the flow object space. > - do we want to create specialized code for constants? > - do we want to inline small functions? I'd say no. That's the job of a future optimization pass. > - do we want to use small tail-functions instead of goto? Ack. You want to blow CPython up or force us to use Stackless to test genrpy :-) But clearly, the ability to generate such code will be nice in the future. > - do we want to translate non-rpythonic code as well? Tough one :-) Maybe, using non-constant global dicts... but we need anyway now to pin down precisely all simplifying assumptions that the flow object space is based on, and document this as R-Python. This can be done independently of the type-inferencing assumptions which are still in an fuzzy state, but not related to genrpy. A bientot, Armin. From pedronis at strakt.com Fri Jan 14 12:46:59 2005 From: pedronis at strakt.com (Samuele Pedroni) Date: Fri, 14 Jan 2005 12:46:59 +0100 Subject: [pypy-dev] new branch src-typedunwrap Message-ID: <41E7B133.9060903@strakt.com> After discussing with Armin and Holger, I have created a new branch to explore typed unwrapping. This was touched and discussed also in the past, we would like to move away from the current generic unwrap to typed versions thereof, also because is a reasonable way to express type information about parameters that enters functions (for example builtin function implementations) as just generic object and then get unwrapped. As first step we will introduce str_w and int_w space operations, that are type specific unwraps for string and integers. Removing generic unwrapping of lists and tuples (probably up to their usage in tests) makes also sense, because in mixed type cases they are problematic as RPython operations. After this we discussed about supplying the gateways with specifier so that can also carry out unwrapping and argument type checking int the spirit of CPython ParseTuple* operations. For that we will likely need typed unwrapping for more types and to think about the issues of unwrapping vs. going first through the various __int__, __str__ conversion special methods. Samuele. From hpk at trillke.net Sat Jan 15 11:54:36 2005 From: hpk at trillke.net (holger krekel) Date: Sat, 15 Jan 2005 11:54:36 +0100 Subject: [pypy-dev] new branch src-typedunwrap In-Reply-To: <41E82159.8070402@stackless.com> References: <41E7B133.9060903@strakt.com> <41E82159.8070402@stackless.com> Message-ID: <20050115105436.GA14660@solar.trillke.net> On Fri, Jan 14, 2005 at 20:45 +0100, Christian Tismer wrote: > Samuele Pedroni wrote: > >After discussing with Armin and Holger, I have created a new branch to > >explore typed unwrapping. > > Oh, did I miss an IRC discussion? i guess so. We are actually discussing things on #pypy quite a bit these days. It would be great if you keep an eye on it :-) > Does somebody happen to have a log file of the session? > I'm just curious to follow the reasoning, and to see > if I can help something. Sure, below you'll find the chat session. I just cut the log at the start and the end but not in between. Also there was an earlier (shorter) discussion which i didn't recover. But almost all of the arguments are recapped in the discussion below ... cheers, holger Jan 14 11:05:32 should we also really rename is_true to true_w Jan 14 11:05:43 IMO: yes Jan 14 11:05:55 we may do that in a branch as well Jan 14 11:06:05 and warn on pypy-dev Jan 14 11:06:10 good points Jan 14 11:06:12 I can create a branch Jan 14 11:06:18 i don't know e.g. if Christian's translator breaks etc.pp. Jan 14 11:06:29 although global replace works fairly well i guess Jan 14 11:06:52 (but christian's translator is special because it targets interp-level python) Jan 14 11:07:14 well, it also depends what we do with the generic unwrap Jan 14 11:07:24 if we remove it, rename it Jan 14 11:07:54 I think some other translator stuff may break and need changes Jan 14 11:08:02 * hpk is off for an hour to do tax declaration work (argl!) Jan 14 11:08:48 pedronis: I rediscovered unwrap_builtin() Jan 14 11:08:56 I saw that too Jan 14 11:09:14 I'd believe that we only need that and the int_w&co Jan 14 11:09:32 probably yes Jan 14 11:09:50 I don't think we want to keep lists and tuple unwrappable Jan 14 11:09:59 no it doesn't really make sense Jan 14 11:09:59 I mean directly unwrappable Jan 14 11:10:17 because of the mixed type cases Jan 14 11:10:19 it's only used in some tests Jan 14 11:10:36 I think code objects use them Jan 14 11:10:43 to unwrap tuples of strings Jan 14 11:10:50 but it can be done differently Jan 14 11:10:55 yes Jan 14 11:11:30 should str_w, int_w be multimethods in the std objspace Jan 14 11:11:39 if we consider multiple impl of types Jan 14 11:11:44 maybe yes Jan 14 11:13:07 is_true() is no longer a MM Jan 14 11:13:45 yes, it's a bit of special case Jan 14 11:13:56 right Jan 14 11:14:03 because it corresponds also to __nonzero__ Jan 14 11:14:11 well we have __int__, __str__ etc Jan 14 11:14:12 so it goes through descrops Jan 14 11:14:30 yes but I don't think we want int_w to correspond to __int__ Jan 14 11:14:38 or maybe yes Jan 14 11:14:41 I thought so Jan 14 11:15:21 --> lypanov (~alex at a80-126-190-213.adsl.xs4all.nl) has joined #pypy Jan 14 11:15:47 well but for str_w in often does not make sense, some function takes a string not everything that defines __str__ Jan 14 11:16:00 s/takes/takes just Jan 14 11:16:13 hum, right Jan 14 11:16:35 we already have space.int Jan 14 11:16:37 should it be readbuf_w()? (argh) Jan 14 11:16:37 btw Jan 14 11:17:12 that means that in parse_w we could have specifier both behaviors Jan 14 11:17:25 that menas something that implements the buffer intf Jan 14 11:17:32 s/menas/means Jan 14 11:18:16 raah, trying to figure out what CPython really does is messy Jan 14 11:18:29 suppose x.__class__ has an __int__ Jan 14 11:18:36 then you can do range(x) but not float(x) Jan 14 11:18:55 I think it is easier to have both kind of primitive op Jan 14 11:18:58 ops Jan 14 11:19:17 both unwrap only if of the "right" type or invoke the __xxx__ method Jan 14 11:19:28 and then be clever at parse_w level Jan 14 11:19:31 (you can't do 1+x either, btw) Jan 14 11:20:05 yup Jan 14 11:20:18 ouack Jan 14 11:20:21 so we need int_w which is different from int Jan 14 11:20:29 "abcdef"[1:x] -> TypeError Jan 14 11:20:33 "abcdef".__getslice__(1,x) Jan 14 11:20:34 'bcdef' Jan 14 11:21:17 I think right now it is more worth to concetrate Jan 14 11:21:31 moving away from the generic unwrap to typed versions thereof Jan 14 11:21:55 sorting the mess what CPython accepts here and there Jan 14 11:22:03 is a slightly different issue Jan 14 11:22:14 so we define int_w and str_w as only accepting the real type? Jan 14 11:22:23 yes Jan 14 11:22:37 you have space.int and space.str Jan 14 11:22:43 for the other behavior Jan 14 11:23:18 that's why I'm not sure that space.is_true should become true_w Jan 14 11:23:24 I see Jan 14 11:23:26 true_w would just work with boolean Jan 14 11:23:53 although I think there's not much in CPython that behaves that way Jan 14 11:24:04 with bool args Jan 14 11:24:53 it starts to look messy again, with a lot of xxx_w() MMs for each way we'd like to unwrap objects Jan 14 11:25:04 readbuf_w(), writebuf_w(), ...? Jan 14 11:25:36 well, the othe option is to pass a 2nd type arg to unwrap Jan 14 11:26:41 but it gets tricky to express that as true RPython Jan 14 11:26:53 --> Eventh (evenwiik at v201a.studby.ntnu.no) has joined #pypy Jan 14 11:27:05 float_w should accept an int, I guess Jan 14 11:28:04 well, if they are multimethods at least in the std objspace Jan 14 11:28:10 it easy to tweak that Jan 14 11:28:49 I'm more trying to understand what we really want... Jan 14 11:30:06 right now a big parts of our unwraps Jan 14 11:30:12 are about ints and strings Jan 14 11:31:01 so at least int_w and str_w seem to make sense Jan 14 11:31:35 ok Jan 14 11:31:54 parse_w will also make sense Jan 14 11:32:10 so I think creating a branch Jan 14 11:32:26 and introducing int_w and str_w as first step Jan 14 11:32:46 looks good Jan 14 11:32:58 then I think it is easier to see what we need beyond that Jan 14 11:33:04 from parse_w point of view Jan 14 11:33:12 ok. Jan 14 11:36:38 I will create a src-typedunwrap branch Jan 14 11:36:43 and mail pypy-dev Jan 14 11:36:57 now I'm going to have lunch Jan 14 11:37:03 --- pedronis is now known as pedronis_lunch Jan 14 11:55:42 <-- arigo has quit ("Leaving") Jan 14 12:15:09 <-- thingie24 has quit (leguin.freenode.net irc.freenode.net) Jan 14 12:15:09 <-- dlk has quit (leguin.freenode.net irc.freenode.net) Jan 14 12:15:09 <-- etrepum has quit (leguin.freenode.net irc.freenode.net) Jan 14 12:20:20 --> thingie24 (~rmt38 at valhalla.ccp.cc) has joined #pypy Jan 14 12:20:20 --> dlk (~dlk at walter.ita.chalmers.se) has joined #pypy Jan 14 12:20:20 --> etrepum (bob at ayunami.redivi.com) has joined #pypy Jan 14 12:22:56 --> arigo (~arigo at d83-176-50-66.cust.tele2.ch) has joined #pypy Jan 14 12:26:30 --- pedronis_lunch is now known as pedronis Jan 14 12:47:44 <-- adim (~adim at logilab.net2.nerim.net) has left #pypy Jan 14 12:57:18 afternoon Jan 14 12:59:42 hi Jan 14 12:59:57 afternoon Jan 14 13:08:07 afternoon Jan 14 13:22:27 afternoon Jan 14 13:22:32 --- lac-sleeps is now known as lac Jan 14 13:27:54 nothing else to say, i'm afraid :) Jan 14 13:31:46 :-) Jan 14 14:05:57 arigo: i hope people read and take notice of your python-dev interface post Jan 14 14:07:54 i hesitated Jan 14 14:08:08 it's a bit lost in the thread but i don't want to insist more, specially to avoid flooding python-dev again Jan 14 14:10:38 well, i think the idea that strings represent >1 concept is illuminating Jan 14 14:14:32 --> adim (~adim at logilab.net2.nerim.net) has joined #pypy Jan 14 14:59:59 I am going to work now. With a bottle of champaigne. Jan 14 15:00:04 hehe Jan 14 15:00:05 --- lac is now known as lac-work Jan 14 15:12:19 arigo, mwh: indeed i find "global adapter registries" scary Jan 14 15:14:35 another serious concern which i haven't seen mentioned is debugging, btw Jan 14 15:15:16 for example, how will a traceback involving adapations on arguments look like? Jan 14 15:21:29 if there is an exception while adapting? Jan 14 15:22:17 you'll probably see the "def f(x: y)" line in the traceback, which is a good hint that it's during adaptation Jan 14 15:34:57 <-- idnar has quit ("kbye") Jan 14 16:07:41 i am pretty sure that it will make things harder to debug, anyway Jan 14 16:15:37 <-- dlk has quit (Read error: 104 (Connection reset by peer)) Jan 14 16:23:31 the global registry is dangerous Jan 14 16:23:49 __conform__() and __adapt__() should be reasonable, though Jan 14 16:24:21 as methods on objects? (i didn't follow python-dev closely on all this) Jan 14 16:24:55 I think the idea is that the built-in adapt() function just calls __conform__() and __adapt__() Jan 14 16:25:13 a bit like "a+b" calls __add__() and __radd__(), btw Jan 14 16:25:57 arigo: unrelated, I'm thinking what to do about co_consts Jan 14 16:26:33 I rediscovered the fact that our code objects are supposed to be space indipendent Jan 14 16:26:48 but that means they must store co_consts unwrapped Jan 14 16:27:00 yes Jan 14 16:27:31 but that exactly a mixed type tuple Jan 14 16:27:49 oups Jan 14 16:28:11 so we would like co_consts_w Jan 14 16:28:34 but the the code objects are really designed to be space indipendent Jan 14 16:29:15 although i am not sure this design decision is neccessary Jan 14 16:30:15 what does it buy us? Jan 14 16:30:16 probably not, but is is quite pervasive Jan 14 16:30:28 yes, and Armin had good arguments Jan 14 16:31:24 because the gateways are also space independent Jan 14 16:31:47 it's all a bit messy Jan 14 16:32:26 I have converted most of interpreter/* to use just int_w,str_w and unwrap_builtin Jan 14 16:32:54 there are really two approaches that exist in practice: Jan 14 16:32:59 althoug unwrap_builtin could probably have a better name Jan 14 16:33:05 in CPython we have real objects in co_consts Jan 14 16:33:30 in many other VMs the literals are stored in some bytecodeish compact format Jan 14 16:33:46 and expanded into real objects by the equivalent of LOAD_CONST Jan 14 16:34:05 e.g. LOAD_STRING n, where n somehow points to raw string data Jan 14 16:34:32 so far PyPy does the latter, with LOAD_CONST n meaning wrap the "raw" co_consts[n] Jan 14 16:35:22 a the nice property is that we don't have to preprocess code objects: the interpreter could theoretically just run off mmaped .pyc files Jan 14 16:36:20 ah but then our co_const would be in marshal format Jan 14 16:37:11 yes, note that the marhsal format is similar to whatever format we'd have to invent to represent a mixed type tuple anyway Jan 14 16:38:09 well, for now I keep the unwrap and unwrap Jan 14 16:38:33 in theory, we could tell the translator that the Code class and its attributes are implemented as a "view" over read-only packed data in marshal format Jan 14 16:38:45 and *if* we remove direct tuple list wrapping/unwrapping Jan 14 16:38:52 and get a version of the interpreter that really handles only marshal data, never "real" Code instances Jan 14 16:39:18 yes Jan 14 16:39:58 probably Jan 14 16:40:12 well it's messy anyway, because of long or complex literals that are maybe not R-Python types Jan 14 16:40:38 I mean, literals of type long or complex Jan 14 16:41:33 also true Jan 14 16:41:50 well with marshal approach Jan 14 16:42:20 that's not an issue Jan 14 16:42:37 but those wrap and unwrap need to be spelled in a special way Jan 14 16:43:13 hum, it looks like a marshaled object is an object is the MarshalObjSpace :-) Jan 14 16:43:35 well that's still a special way Jan 14 16:43:40 then those wrap and unwrap become sending objects across spaces Jan 14 16:43:42 because it's a different space Jan 14 16:43:49 precisely. Jan 14 16:43:55 arigo: i suspect you might be getting ahead of yourself here? Jan 14 16:44:02 :) Jan 14 16:44:13 oh, he is probably thinking of making use of adapt() :-) Jan 14 16:44:26 (not really) Jan 14 16:44:33 for now I will leave the wrap and unwrap Jan 14 16:44:36 hpk: not that I am fully aware of :-) Jan 14 16:44:39 adapt(1, ApplicationLevel) ? Jan 14 16:44:40 anyway I have not disabled Jan 14 16:44:52 adapt(1, IApplicationLevelThingie), rather Jan 14 16:44:56 the wrap/unwrap functionality for tuples or lists Jan 14 16:45:00 if I do that Jan 14 16:45:01 let's use a decorator too! Jan 14 16:45:08 pedronis: ok Jan 14 16:45:15 I will use some special names for those cases Jan 14 16:45:18 mwh: :-) Jan 14 16:47:08 well it's all fuzzy, e.g. what should a built-in compiler produce? Code objects with what in the co_consts? It looks like it shouldn't depend on a space... Jan 14 16:48:01 well, indeed Jan 14 16:49:28 yes, but I don't see a problem in finding a suitable space independent format for co_consts Jan 14 16:49:51 the fact that we want to have a space-independent repr of a code object does not imply that PyPy's internal code objects could not be space-dependent Jan 14 16:50:15 (sorry for the negation-complexity here :^) Jan 14 16:52:54 ok Jan 14 16:53:25 that's quite possible after all... Jan 14 16:54:15 also it seems that apart from LOAD_CONST we hardly have "generic" wraps in interpreter/ Jan 14 16:54:43 yup Jan 14 16:54:44 most of them are wraps of obvious strings or integers, i think Jan 14 16:55:01 yes, mostly wraps of messages, filenames, varnames Jan 14 16:55:35 as I said the generic unwrap is also the one of co_consts Jan 14 16:55:42 s/the/the only Jan 14 16:56:43 there must be a generic wrap for default args of gateways Jan 14 16:57:53 yes, I said unwrap Jan 14 16:58:22 app2interp.getdefaults() does the generic wrap, right Jan 14 16:58:28 it's also marked as NOT_RPYTHON Jan 14 16:58:33 yes :-) Jan 14 16:58:36 and happens at bootstrap Jan 14 16:58:47 ok ok :-) Jan 14 17:00:56 if we want to allow things like new.code(...., co_consts=(AnyThing(),), ...) Jan 14 17:01:03 to be done by the user Jan 14 17:01:13 then we have no choice but keep the object wrapped Jan 14 17:01:37 true Jan 14 17:03:16 the same regarding func_defaults Jan 14 17:03:25 it works in CPython (to override func_defaults) Jan 14 17:03:28 but doesn't in PyPy apparently Jan 14 17:04:15 no? Jan 14 17:04:39 you can say def f(x=AnyThing()) Jan 14 17:04:48 so you can create func_defaults with anything at all Jan 14 17:05:01 yes, maybe the current limitation is just shallow Jan 14 17:05:02 (even though we might not support assigning to .func_defaults) Jan 14 17:05:19 Functions are space depedent Jan 14 17:05:21 that's quite different, func_defaults are not a syntactic property Jan 14 17:05:31 in fact they store defaults as defs_w Jan 14 17:06:07 it's code objects and gateways that are space independent Jan 14 17:10:54 looking further maybe it's not too hard to make code objects space depedent if we want to Jan 14 17:11:42 it seems gateways just need to become even more lazy Jan 14 17:12:26 could BuiltinCode remain space-independent, and PyCode be space-dependent? Jan 14 17:13:53 I think so Jan 14 17:14:08 it should be possible Jan 14 17:15:00 BuiltinCode is constructing a PyCode just to be able to use .signature Jan 14 17:15:15 but can be done in some other way Jan 14 17:15:35 i guess we should untangle the cases more Jan 14 17:15:55 maybe we tried too hard to reuse code for BuiltinCode/PyCode cases Jan 14 17:17:37 the question is, do we want PyCode to be space depedent, it probably has to because of what we found Jan 14 17:18:19 I guess so Jan 14 17:18:43 I can do the change Jan 14 17:19:16 on the branch? Jan 14 17:19:31 makes sense i think Jan 14 17:20:27 I'm going first to check in what I did so far Jan 14 17:23:48 ok :-) From hpk at trillke.net Sat Jan 15 13:03:31 2005 From: hpk at trillke.net (holger krekel) Date: Sat, 15 Jan 2005 13:03:31 +0100 Subject: [pypy-dev] new repolayout proposal In-Reply-To: <20050115115523.A4A1927B82@code1.codespeak.net> References: <20050115115523.A4A1927B82@code1.codespeak.net> Message-ID: <20050115120331.GC14660@solar.trillke.net> Hello, please find a draft of an envisioned new PyPy repository layout here: http://codespeak.net/pypy/index.cgi?doc/newrepolayout.html i plan to implement this new scheme early next week when we discussed and possibly modified it some. It does not try to prescribe the complete structure of all directories yet. Note that probably any new layout will very likely be incompatible with the old one so everyone will have to adjust checkouts accordingly. If you'd like to come up with completely other ideas then please add your proposal to the doc/newrepolayout.txt file by appending e.g. a section "new repo layout proposal No. 2". If you have slight modifications then just edit the current proposal accordingly or post them here. Of course, we can discuss general questions/considerations here on pypy-dev but let's try to keep the discussion as concrete as possible :-) cheers, holger On Sat, Jan 15, 2005 at 12:55 +0100, hpk at codespeak.net wrote: > Author: hpk > Date: Sat Jan 15 12:55:23 2005 > New Revision: 8293 > > Added: > pypy/trunk/doc/newrepolayout.txt > Log: > a repo layout proposal > > Added: pypy/trunk/doc/newrepolayout.txt > ============================================================================== > --- (empty file) > +++ pypy/trunk/doc/newrepolayout.txt Sat Jan 15 12:55:23 2005 > @@ -0,0 +1,75 @@ > +=========================================== > +Proposition: new svn repository layout > +=========================================== > + > +Motivation > +---------- > + > +The `PyPy repository layout`_ has evolved for two > +years into something that needs some refactoring > +to become more practical. > + > +For example, the `trunk/doc`_ directory was originally intended > +to hold developer documentation but nowadays it contains > +funding, negotiations, mails and misc-other-stuff documents. It is > +not easy and obvious anymore to know which files are relevant. > +Moreover, `trunk/doc`_ is too far away from the source code: > +developers currently checkout the 'trunk/src' directory and > +don't even get the documentation. This also makes it more > +difficult to keep the documentation up-to-date. > + > +.. _`trunk/doc`: http://codespeak.net/svn/pypy/trunk/doc > +.. _`PyPy repository layout`: http://codespeak.net/svn/pypy/ > + > +New repo layout proposal Nr. 1 > +------------------------------ > + > +Based on experiences in various repositories here is a > +new proposition describing a possible new structure > +(starting at /svn/pypy):: > + > + branch # holds branches > + tag # holds tagged dist-versions > + > + dist # holds current development > + pypy # current trunk/src/pypy > + documentation # developer documentation (inside pypy!) > + py # and other 'externals' > + setup.py # should be there at some point > + README.txt # tell how to run PyPy, the translator, tests > + LICENSE.txt # copyright notices for tree parts including pypy > + > + doc # non-dist documentations (papers etc.pp.) > + talk # various pypy-talks > + paper # various pypy-related papers (including our own) > + sprint # sprint related information (reports etc.pp.) > + irclog # IRC logs (snipped appropriately) > + > + www # website-related stuff (needs its own reconsideration) > + > + funding # funding related documents > + eu-info # official information from the EU > + contract # contract material (EU-contract, amendments) > + eu-report # eu reports (time/cost/budget) > + ... # probably more, we'll see later > + > +The idea is that developers can use a simple url:: > + > + svn co https://codespeak.net/svn/pypy/dist dist-pypy > + > +in order to get everything neccessary for sourcecode, documentation > +and test development. Obviously, if you care about the funding > +or web site application/contents you can do an appropriate checkout > +as well. > + > +Note, that having documentation inside the source tree will help > +with keeping a closer eye on documentation - especially when we > +have special ref-integrity tests for the documentation (which itself > +should reference real source-code/functions at some point). For > +example, the refactoring of unitest.py-style tests to `py.test`_ based ones > +"forgot" to modify our test-documentation in the too-far-away doc-folder. > +We should move to a scheme where such an omission will raise real > +test errors. > + > +.. _`py.test`: http://codespeak.net/py/current/doc/test.html > + > _______________________________________________ > pypy-svn mailing list > pypy-svn at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn > From lac at strakt.com Sat Jan 15 15:56:03 2005 From: lac at strakt.com (Laura Creighton) Date: Sat, 15 Jan 2005 15:56:03 +0100 Subject: [pypy-dev] new repolayout proposal In-Reply-To: Message from hpk@trillke.net (holger krekel) of "Sat, 15 Jan 2005 13:03:31 +0100." <20050115120331.GC14660@solar.trillke.net> References: <20050115115523.A4A1927B82@code1.codespeak.net> <20050115120331.GC14660@solar.trillke.net> Message-ID: <200501151456.j0FEu3w4028420@ratthing-b246.strakt.com> Where should we put documentation about py? dist/py/doc ? I think dist/pypy/documentation should be dist/pypy/doc also, for brevity. Laura From hpk at trillke.net Sat Jan 15 16:09:11 2005 From: hpk at trillke.net (holger krekel) Date: Sat, 15 Jan 2005 16:09:11 +0100 Subject: [pypy-dev] new repolayout proposal In-Reply-To: <200501151456.j0FEu3w4028420@ratthing-b246.strakt.com> References: <20050115115523.A4A1927B82@code1.codespeak.net> <20050115120331.GC14660@solar.trillke.net> <200501151456.j0FEu3w4028420@ratthing-b246.strakt.com> Message-ID: <20050115150911.GH14660@solar.trillke.net> On Sat, Jan 15, 2005 at 15:56 +0100, Laura Creighton wrote: > > Where should we put documentation about py? > > dist/py/doc ? the documentation is at "py/documentation" but this is unrelated to PyPy's layout (we have py as an external in the PyPy tree). > I think dist/pypy/documentation should be dist/pypy/doc also, for brevity. maybe. Btw, this is not intended to be checked out directly anyway (see the proposal for details) although you can do it if you like it. cheers, holger From lac at strakt.com Sat Jan 15 16:49:51 2005 From: lac at strakt.com (Laura Creighton) Date: Sat, 15 Jan 2005 16:49:51 +0100 Subject: [pypy-dev] new repolayout proposal In-Reply-To: Message from holger krekel of "Sat, 15 Jan 2005 16:09:11 +0100." <20050115150911.GH14660@solar.trillke.net> References: <20050115115523.A4A1927B82@code1.codespeak.net> <20050115120331.GC14660@solar.trillke.net> <200501151456.j0FEu3w4028420@ratthing-b246.strakt.com> <20050115150911.GH14660@solar.trillke.net> Message-ID: <200501151549.j0FFnpUe029225@ratthing-b246.strakt.com> In a message of Sat, 15 Jan 2005 16:09:11 +0100, holger krekel writes: >> I think dist/pypy/documentation should be dist/pypy/doc also, for brevi >ty. > >maybe. Btw, this is not intended to be checked out directly >anyway (see the proposal for details) although you can do it >if you like it. I was more worried about really-long-filenames. Perhaps this doesn't matter as much. Laura > >cheers, > > holger >_______________________________________________ >pypy-dev at codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev From tismer at stackless.com Sat Jan 15 22:44:53 2005 From: tismer at stackless.com (Christian Tismer) Date: Sat, 15 Jan 2005 22:44:53 +0100 Subject: [pypy-dev] new branch src-typedunwrap In-Reply-To: <20050115105436.GA14660@solar.trillke.net> References: <41E7B133.9060903@strakt.com> <41E82159.8070402@stackless.com> <20050115105436.GA14660@solar.trillke.net> Message-ID: <41E98ED5.5010907@stackless.com> holger krekel wrote: > On Fri, Jan 14, 2005 at 20:45 +0100, Christian Tismer wrote: > >>Samuele Pedroni wrote: >> >>>After discussing with Armin and Holger, I have created a new branch to >>>explore typed unwrapping. >> >>Oh, did I miss an IRC discussion? > > > i guess so. We are actually discussing things on #pypy quite > a bit these days. It would be great if you keep an eye on it :-) Thanks a lot! Yes, I failed to use IRC, regularily. Will do so from now on. Al the best - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From abkhd at hotmail.com Mon Jan 17 03:29:27 2005 From: abkhd at hotmail.com (A.B., Khalid) Date: Mon, 17 Jan 2005 02:29:27 +0000 Subject: [pypy-dev] test_file fails, hard-coded tmp dir to blame? Message-ID: Hello, test_file fails at this end. It seems that it tries to create a '/tmp/tt' file, but it fails. This is so because my temp directory is at '/windows/temp' not '/tmp'. If I correctly understand this problem, then find attached a fix that got the test to pass. Hope that helps. Regards, Khalid PS. In case the developers here are interested to know, all the tests pass now on this box, including the JAVA and LISP ones which are made to use Jikes (version 1.20) and GNU CLISP (version 2.33) on Win98, MinGW built Python 2.3.5.0 (from CVS), and GCC 3.4.2 (MinGW special). Index: pypy/appspace/test/test_file.py =================================================================== --- pypy/appspace/test/test_file.py (revision 8317) +++ pypy/appspace/test/test_file.py (working copy) @@ -16,8 +16,10 @@ assert self.fd.tell() == 0 def test_case_readonly(self): - f=_file.file_('/tmp/tt', 'w') - assert f.name == '/tmp/tt' + from tempfile import mktemp + fn = mktemp() + f=_file.file_(fn, 'w') + assert f.name == fn assert f.mode == 'w' assert f.closed == False assert f.encoding == None # Fix when we find out what this is _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From lac at strakt.com Mon Jan 17 10:31:43 2005 From: lac at strakt.com (Laura Creighton) Date: Mon, 17 Jan 2005 10:31:43 +0100 Subject: [pypy-dev] test_file fails, hard-coded tmp dir to blame? In-Reply-To: Message from "A.B., Khalid" of "Mon, 17 Jan 2005 02:29:27 GMT." References: Message-ID: <200501170931.j0H9VhqV029849@ratthing-b246.strakt.com> In a message of Mon, 17 Jan 2005 02:29:27 GMT, "A.B., Khalid" writes: >Hello, > > >test_file fails at this end. It seems that it tries to create a '/tmp/tt' > >file, but it fails. This is so because my temp directory is at >'/windows/temp' not '/tmp'. > >If I correctly understand this problem, then find attached a fix that got > >the test to pass. Hope that helps. > >Regards, >Khalid Thank you very much for the patch, which is in now. >PS. In case the developers here are interested to know, all the tests pass >now on this box, including the JAVA and LISP ones which are made to use >Jikes (version 1.20) and GNU CLISP (version 2.33) on Win98, MinGW built >Python 2.3.5.0 (from CVS), and GCC 3.4.2 (MinGW special). _Great_ to hear, thank you very much! Laura From hpk at trillke.net Mon Jan 17 10:37:06 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 17 Jan 2005 10:37:06 +0100 Subject: [pypy-dev] test_file fails, hard-coded tmp dir to blame? In-Reply-To: References: Message-ID: <20050117093706.GM14660@solar.trillke.net> Hi Khalid, On Mon, Jan 17, 2005 at 02:29 +0000, A.B., Khalid wrote: > test_file fails at this end. It seems that it tries to create a '/tmp/tt' > file, but it fails. This is so because my temp directory is at > '/windows/temp' not '/tmp'. Yes, this hardcoded temp path is wrong. > If I correctly understand this problem, then find attached a fix that got > the test to pass. Hope that helps. It fixes the problem but it will create more and more temporary directories. In PyPy, we have a "pypy.tool.udir.udir" which gets globally created for every test run. Older test session directories will get removed so we don't clutter temp-directories so much .... i just fixed it accordingly. > PS. In case the developers here are interested to know, all the tests pass > now on this box, including the JAVA and LISP ones which are made to use > Jikes (version 1.20) and GNU CLISP (version 2.33) on Win98, MinGW built > Python 2.3.5.0 (from CVS), and GCC 3.4.2 (MinGW special). Ah, that sounds good! Yesterday i spent some time to get the tests to fail more nicely if java/lisp/C cannot be found. So we have covered both ends :-) cheers, holger From arigo at tunes.org Mon Jan 17 17:00:59 2005 From: arigo at tunes.org (Armin Rigo) Date: Mon, 17 Jan 2005 16:00:59 +0000 Subject: [pypy-dev] Re: [pypy-svn] r8324 - pypy/trunk/src/pypy/translator/test In-Reply-To: <20050116230801.8E14527B55@code1.codespeak.net> References: <20050116230801.8E14527B55@code1.codespeak.net> Message-ID: <20050117160059.GA6688@vicky.ecs.soton.ac.uk> Hi Holger, On Mon, Jan 17, 2005 at 12:08:01AM +0100, hpk at codespeak.net wrote: > Log: > skip tests if underlying system features (c-compiler mostly) > are not present. > - return t.ccompile() > + return py.test.skip_on_error(t.ccompile) Ahem! This looks like it is saying "run the difficult part that we are testing, but if anything goes wrong, just skip the test". The test *is* that t.ccompile() works correctly, and only additionally that calling the compiled function works. In practice it's more common that there is an exception-raising bug in genc.py, which is called by t.ccompile(). Armin From hpk at trillke.net Mon Jan 17 17:26:41 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 17 Jan 2005 17:26:41 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8324 - pypy/trunk/src/pypy/translator/test In-Reply-To: <20050117160059.GA6688@vicky.ecs.soton.ac.uk> References: <20050116230801.8E14527B55@code1.codespeak.net> <20050117160059.GA6688@vicky.ecs.soton.ac.uk> Message-ID: <20050117162641.GA14660@solar.trillke.net> Hi Armin, On Mon, Jan 17, 2005 at 16:00 +0000, Armin Rigo wrote: > On Mon, Jan 17, 2005 at 12:08:01AM +0100, hpk at codespeak.net wrote: > > Log: > > skip tests if underlying system features (c-compiler mostly) > > are not present. > > > - return t.ccompile() > > + return py.test.skip_on_error(t.ccompile) > > Ahem! This looks like it is saying "run the difficult part that we are > testing, but if anything goes wrong, just skip the test". :-) Well, i tested on platforms where these invocations miserably fail because there was no matching C-compiler available and then they give long obnoxious tracebacks from within distutils somewhere. > The test *is* that t.ccompile() works correctly, and only additionally that > calling the compiled function works. In practice it's more common that there > is an exception-raising bug in genc.py, which is called by t.ccompile(). OK, from the containing "build_cfunc" function i didn't guess that the call to t.ccompile() was supposed to be a test by itself. I guess that either the Genc() part should be called separatedly or we should have our distutils invocations fail more cleanly and extend "skip_on_error" to require specifying an explicit Exception class. then the above could turn into py.test.skip_on_error(SystemExit, t.ccompile) which - hopefully - GenC() does not raise :-) cheers, holger From hpk at trillke.net Mon Jan 17 18:15:21 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 17 Jan 2005 18:15:21 +0100 Subject: [pypy-dev] new repolayout proposal In-Reply-To: <20050115120331.GC14660@solar.trillke.net> References: <20050115115523.A4A1927B82@code1.codespeak.net> <20050115120331.GC14660@solar.trillke.net> Message-ID: <20050117171521.GD14660@solar.trillke.net> On Sat, Jan 15, 2005 at 13:03 +0100, holger krekel wrote: > Hello, > > please find a draft of an envisioned new PyPy repository layout here: > > http://codespeak.net/pypy/index.cgi?doc/newrepolayout.html > > i plan to implement this new scheme early next week when we discussed > and possibly modified it some. It does not try to prescribe > the complete structure of all directories yet. OK, i got positive feedback so far. So i think i am going to start implementing the new scheme tomorrow morning. It will be a multi-step process but i will take care that especially the busy development-tree has no downtime (once trunk/src stops working you should just issue svn switch http://codespeak.net/svn/pypy/dist to switch your local checkout to the upcoming "trunk".) People working on e.g. pypy/branch/src-typedunwrap need _not_ change anything if i see it correctly. Of course, we need to take care when we merge back the changes into dist. I will probably be available on IRC #pypy if you encounter problems. cheers, holger From hpk at trillke.net Tue Jan 18 12:00:27 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 18 Jan 2005 12:00:27 +0100 Subject: [pypy-dev] new repolayout in place Message-ID: <20050118110026.GJ14660@solar.trillke.net> Hi pypy-dev, it seems the basic move to the new repo layout is complete. There are likely some broken web links here and there but i tried to take care that most of the existing links out in the wild still work. If you have a "pypy/trunk/src" checkout then you should go to that directory and issue svn switch http://codespeak.net/svn/pypy/dist The next step probably is to consolidate developer documentation into fewer files with sections and subsections and generally complete the steps mentioned in http://codespeak.net/pypy/index.cgi?doc/newrepolayout.html take care, holger From pedronis at strakt.com Thu Jan 20 19:41:58 2005 From: pedronis at strakt.com (Samuele Pedroni) Date: Thu, 20 Jan 2005 19:41:58 +0100 Subject: [pypy-dev] is codespeak svn down? Message-ID: <41EFFB76.108@strakt.com> I get this Could not open the requested SVN filesystem trying to access trhough the web, same kind of error trying svn client. Samuele From jum at anubis.han.de Thu Jan 20 19:58:03 2005 From: jum at anubis.han.de (Jens-Uwe Mager) Date: Thu, 20 Jan 2005 19:58:03 +0100 Subject: [pypy-dev] is codespeak svn down? In-Reply-To: <41EFFB76.108@strakt.com> References: <41EFFB76.108@strakt.com> Message-ID: <20050120185802.GE1616@anubis.han.de> On Thu, Jan 20, 2005 at 19:41 +0100, Samuele Pedroni wrote: > I get this > > > > > Could not open the requested SVN filesystem > > > > trying to access trhough the web, same kind of error trying svn client. Appears to work again. We should look who did use the svn db directly via file access around 19:29 as user root, may be we can find what went wrong. -- Jens-Uwe Mager From arigo at tunes.org Fri Jan 21 11:50:29 2005 From: arigo at tunes.org (Armin Rigo) Date: Fri, 21 Jan 2005 10:50:29 +0000 Subject: [pypy-dev] [pycon@python.org: [Python-Dev] PyCon Preliminary Program Announced!] Message-ID: <20050121105029.GA18753@vicky.ecs.soton.ac.uk> Hi all, PyCon is ready for registration, and the early bird rates end in one week. We've got a PyPy talk, "PyPy and Type Inference". Armin ----- Forwarded message from Steve Holden ----- Date: Fri, 21 Jan 2005 01:06:05 +0100 (CET) From: Steve Holden To: python-dev at python.org Subject: [Python-Dev] PyCon Preliminary Program Announced! Message-Id: <20050121000605.AAC3C1E400F at bag.python.org> Reply-To: PyCON at python.org List-Id: Python core developers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: python-dev-bounces+arigo=tunes.org at python.org Errors-To: python-dev-bounces+arigo=tunes.org at python.org Dear Python Colleague: You will be happy to know that the PyCon Program Committee, after lengthy deliberations, has now finalized the program for PyCon DC 2005. I can tell you that the decision-making was very difficult, as the standard of submissions was even higher than last year. You can see the preliminary program at http://www.python.org/pycon/2005/schedule.html and it's obvious that this year's PyCon is going to be even fuller than the last. On innovation is that there will be activities of a more social nature on the Wednesday (and perhaps the Thursday) evening, as well as keynote speeches from Guido and two other luminaries. Remember that the early bird registration rates end in just over a week, so hurry on down to http://www.python.org/pycon/2005/register.html to be sure of your place in what will surely be the premier Python event of the year. As always, I would appreciate your help in getting the word out. Please forward this message to your favorite mailing lists and newsgroups to make sure that everyone has a chance to join in the fun! regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/arigo%40tunes.org ----- End forwarded message ----- From hpk at trillke.net Fri Jan 21 23:41:00 2005 From: hpk at trillke.net (holger krekel) Date: Fri, 21 Jan 2005 23:41:00 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8426 - in pypy/branch/src-typedunwrap/pypy: interpreter/test objspace In-Reply-To: <20050119193437.6561F27B62@code1.codespeak.net> References: <20050119193437.6561F27B62@code1.codespeak.net> Message-ID: <20050121224100.GB467@solar.trillke.net> Hi Samuele, i think in the tests you checked in there are "assert"s missing ... for example, On Wed, Jan 19, 2005 at 20:34 +0100, pedronis at codespeak.net wrote: > Author: pedronis > Date: Wed Jan 19 20:34:37 2005 > New Revision: 8426 > > Modified: > pypy/branch/src-typedunwrap/pypy/interpreter/test/test_gateway.py > pypy/branch/src-typedunwrap/pypy/objspace/trivial.py > + def g3(space, w_a, w_b): > + return space.add(w_a, w_b) > + app_g3 = gateway.interp2app_temp(g3, > + unwrap_spec=[gateway.ObjSpace, > + gateway.W_Root, > + gateway.W_Root]) > + w_app_g3 = space.wrap(app_g3) > + self.space.eq_w( > + space.call(w_app_g3, > + space.newtuple([w('foo'), w('bar')]), > + space.newdict([])), > + w('foobar')) this does not test equality (but it at least checks that it doesn't raise an unexpected exception :-) cheers, holger From arigo at tunes.org Mon Jan 24 09:58:24 2005 From: arigo at tunes.org (Armin Rigo) Date: Mon, 24 Jan 2005 08:58:24 +0000 Subject: [pypy-dev] VEE conference Message-ID: <20050124085824.GA24465@vicky.ecs.soton.ac.uk> Hi, A quick note: we should consider if we should propose a talk on PyPy at the new "Future of Virtual Execution Environmnents" conference, a conference-style follow-up of a closed workshop held last September in New York where I met a lot of interesting people. The focus is on anything about virtual machines. The first more specific area listed on the Call for Papers is "Dynamic and high-level languages". http://www.veeconference.org Armin From olivier.dormond at gmail.com Mon Jan 24 14:10:24 2005 From: olivier.dormond at gmail.com (Olivier Dormond) Date: Mon, 24 Jan 2005 14:10:24 +0100 Subject: [pypy-dev] [patch] fix for dot bad string generation Message-ID: Here is a patch to fix dot producing label surounded by <> instead of "" From hpk at trillke.net Mon Jan 24 16:50:51 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 24 Jan 2005 16:50:51 +0100 Subject: [pypy-dev] [patch] fix for dot bad string generation In-Reply-To: References: Message-ID: <20050124155051.GS467@solar.trillke.net> On Mon, Jan 24, 2005 at 14:10 +0100, Olivier Dormond wrote: > Here is a patch to fix dot producing label surounded by <> instead of "" hi olivier, I am not sure there is a patch attached here :-) what about you get an account and checkin your fix? cheers, holger From olivier.dormond at gmail.com Mon Jan 24 18:00:23 2005 From: olivier.dormond at gmail.com (Olivier Dormond) Date: Mon, 24 Jan 2005 18:00:23 +0100 Subject: [pypy-dev] [patch] fix for dot bad string generation In-Reply-To: <20050124155051.GS467@solar.trillke.net> References: <20050124155051.GS467@solar.trillke.net> Message-ID: Hi, On Mon, 24 Jan 2005 16:50:51 +0100, holger krekel wrote: > I am not sure there is a patch attached here :-) > what about you get an account and checkin your fix? Looks like gmail eat my attachment. :-( You can find it at http://codespeak.net/~odie Cheers, Odie From hpk at trillke.net Tue Jan 25 06:09:42 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 25 Jan 2005 06:09:42 +0100 Subject: [pypy-dev] [patch] fix for dot bad string generation In-Reply-To: References: <20050124155051.GS467@solar.trillke.net> Message-ID: <20050125050942.GY467@solar.trillke.net> Hi Odie, On Mon, Jan 24, 2005 at 18:00 +0100, Olivier Dormond wrote: > On Mon, 24 Jan 2005 16:50:51 +0100, holger krekel wrote: > > I am not sure there is a patch attached here :-) > > what about you get an account and checkin your fix? > > Looks like gmail eat my attachment. :-( Or mailman ate it. (basically mailman doesn't like attachments other than text/plain). > You can find it at http://codespeak.net/~odie Ah now i understand, i thought you were refering to a pypy-patch :-) We should probably direct your patch at the graphviz maintainers. and sorry for forgetting that you already had a fresh account anyway. busy day yesterday ... have a nice week, hopefully until saturday, holger From olivier.dormond at gmail.com Tue Jan 25 11:38:04 2005 From: olivier.dormond at gmail.com (Olivier Dormond) Date: Tue, 25 Jan 2005 11:38:04 +0100 Subject: [pypy-dev] [patch] fix for dot bad string generation In-Reply-To: <20050125050942.GY467@solar.trillke.net> References: <20050124155051.GS467@solar.trillke.net> <20050125050942.GY467@solar.trillke.net> Message-ID: Hi Holger, On Tue, 25 Jan 2005 06:09:42 +0100, holger krekel wrote: > Ah now i understand, i thought you were refering to > a pypy-patch :-) We should probably direct your patch > at the graphviz maintainers. Actually that was done before I sent it to the list. Cheers, Odie From bauflo3 at web.de Tue Jan 25 20:35:39 2005 From: bauflo3 at web.de (Florian Bauer) Date: Tue, 25 Jan 2005 20:35:39 +0100 Subject: [pypy-dev] module writing In-Reply-To: References: Message-ID: <200501252035.39076.bauflo3@web.de> Hey Doug, I don't know exactly. Isn't there a pure python implementation for quoted printable in the python sources (I think in quopri.py or something). I would just use this code. Another thing: I don't have much time at the moment to finish my binascii code. Perhaps it's best if I pass my code to you, so you can have a look at it and perhaps merge it with yours and check it in? What do you think? Cheers Flo From mcneil at astro.queensu.ca Tue Jan 25 20:47:51 2005 From: mcneil at astro.queensu.ca (Douglas McNeil) Date: Tue, 25 Jan 2005 14:47:51 -0500 (EST) Subject: [pypy-dev] module writing In-Reply-To: <200501252035.39076.bauflo3@web.de> Message-ID: > I don't know exactly. Isn't there a pure python implementation for quoted > printable in the python sources (I think in quopri.py or something). I would > just use this code. I would except that testing revealed the two have surprisingly different behaviour for all sorts of inputs, and I thought the goal (at the moment, at least) is to have the pypy stdlib give exactly the same results (at least on non-architecture-dependent stuff.) > Another thing: I don't have much time at the moment to finish my > binascii code. Perhaps it's best if I pass my code to you, so you can > have a look at it and perhaps merge it with yours and check it in? What > do you think? Sure, that's fine. Thesis work is always less interesting than anything else. :) BTW, all, a few weeks ago I gave a talk at a conference on high-performance computation in astrophysics, and got to plug the pypy project as an example of future coolness. In discussions afterwards it was widely agreed that if a dynamic high-level language could get within 25% of C without much boilerplate the productivity gains would be well worth the runtime cost, even at the extreme end of HPC. Doug -- Queen's University Astronomy Research Group Planetary Dynamics Division "We create worlds." From jacek.generowicz at cern.ch Sat Jan 22 10:32:48 2005 From: jacek.generowicz at cern.ch (Jacek Generowicz) Date: Sat, 22 Jan 2005 10:32:48 +0100 Subject: [pypy-dev] codespeak.net/pypy problem Message-ID: <941E8DCE-6C58-11D9-A110-000A95909800@cern.ch> There seems to be a problem with the PyPy pages. This is what I get when I try to access any of them: A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. ?/www/codespeak.net/htdocs/pypy/index.cgi ????7?basedir?=?os.path.dirname(os.path.dirname(real)) ????8?sys.path.insert(0,?basedir) ????9? ???10?from?pypywww?import?cgi ???11?cgi.main(basedir) pypywww undefined, cgi undefined SyntaxError: invalid syntax (cgi.py, line 29) ??????args?= ('invalid syntax', ('/projects/pypy/www/pypywww/cgi.py', 29, 9, ' : \n')) ??????filename?= '/projects/pypy/www/pypywww/cgi.py' ??????lineno?= 29 ??????msg?= 'invalid syntax' ??????offset?= 9 ??????print_file_and_line?= None ??????text?= ' : \n' From hpk at trillke.net Wed Jan 26 09:34:12 2005 From: hpk at trillke.net (holger krekel) Date: Wed, 26 Jan 2005 09:34:12 +0100 Subject: [pypy-dev] codespeak.net/pypy problem In-Reply-To: <941E8DCE-6C58-11D9-A110-000A95909800@cern.ch> References: <941E8DCE-6C58-11D9-A110-000A95909800@cern.ch> Message-ID: <20050126083412.GH467@solar.trillke.net> Hi Jacek, On Sat, Jan 22, 2005 at 10:32 +0100, Jacek Generowicz wrote: > There seems to be a problem with the PyPy pages. This is what I get > when I try to access any of them: (... detailed info ...) thanks for the detailed info. It's often a good idea to just mail "root at codespeak.net" on problems like this. This case was actually fixed on the same day (a wrong update was the cause). holger From jacek.generowicz at cern.ch Wed Jan 26 19:40:02 2005 From: jacek.generowicz at cern.ch (Jacek Generowicz) Date: Wed, 26 Jan 2005 19:40:02 +0100 Subject: [pypy-dev] codespeak.net/pypy problem In-Reply-To: <20050126083412.GH467@solar.trillke.net> References: <941E8DCE-6C58-11D9-A110-000A95909800@cern.ch> <20050126083412.GH467@solar.trillke.net> Message-ID: On 26 Jan 2005, at 09:34, holger krekel wrote: > This case was actually fixed on the same day (a wrong update was the > cause). I must apologize on behalf of my mail server: I sent this _before_ I went to the sprint ... and my mail server refused to send it on until I reconnected my machine at CERN. From tismer at stackless.com Fri Jan 28 02:32:43 2005 From: tismer at stackless.com (Christian Tismer) Date: Fri, 28 Jan 2005 02:32:43 +0100 Subject: [pypy-dev] Re: [pypy-svn] r8642 - pypy/dist/pypy/objspace/std In-Reply-To: <20050127170627.09D1727B95@code1.codespeak.net> References: <20050127170627.09D1727B95@code1.codespeak.net> Message-ID: <41F9963B.5040101@stackless.com> ludal at codespeak.net wrote: > Author: ludal > Date: Thu Jan 27 18:06:26 2005 > New Revision: 8642 > > Modified: > pypy/dist/pypy/objspace/std/stringobject.py > Log: > keep a cache of the hash value of strings like CPython does Hi! I think it is a fine idea to do the hash cache. Just a comment...: > Modified: pypy/dist/pypy/objspace/std/stringobject.py ... > def hash__String(space, w_str): > - return W_IntObject(space, hash(w_str._value)) > + w_hash = w_str.w_hash > + if w_hash is None: > + w_hash = W_IntObject(space, hash(w_str._value)) > + w_str.w_hash = w_hash > + return w_hash I don't see the point why the hash should be stored as a wrapped value. IMHO, the main use of the hash is inside of dict objects. Wouldn't it make more sense to cache the unwrapped value, since we (as I think) do the hashing in a dict with an unwrapped integer, anyway? It is also more conformant with CPython, where the hash is an internal implementation detail. Maybe I just missed something, so anyway - good night! (Ludovic, I don't have your email contact) cheers - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From arigo at tunes.org Fri Jan 28 13:15:59 2005 From: arigo at tunes.org (Armin Rigo) Date: Fri, 28 Jan 2005 12:15:59 +0000 Subject: [pypy-dev] Re: [pypy-svn] r8642 - pypy/dist/pypy/objspace/std In-Reply-To: <41F9963B.5040101@stackless.com> References: <20050127170627.09D1727B95@code1.codespeak.net> <41F9963B.5040101@stackless.com> Message-ID: <20050128121559.GA12403@vicky.ecs.soton.ac.uk> Hi Christian, On Fri, Jan 28, 2005 at 02:32:43AM +0100, Christian Tismer wrote: > I don't see the point why the hash should be stored as a wrapped > value. That's because hash__Str() must return a wrapped value, as space.hash(), and as the W_DictObject expects it. Of course it would be more efficient if somehow we passed unwrapped hash values around, but that's a kind of small optimization that doesn't really pay off the price of making Yet Another Oddity in the public methods of spaces... That said, it would also be ok to move the hack into W_DictObject instead of W_StringObject, by special-casing strings and storing an unwrapped hash cache into W_StringObject. Armin From tinuviel at sparcs.kaist.ac.kr Mon Jan 31 05:39:18 2005 From: tinuviel at sparcs.kaist.ac.kr (Seo Sanghyeon) Date: Mon, 31 Jan 2005 13:39:18 +0900 Subject: [pypy-dev] Regular Expression in PyPy Message-ID: <20050131043918.GA31503@sparcs.kaist.ac.kr> In the checkin message of r8719, hpk wrote: > Ok, it seems we had a mix of python 2.4 and 2.3 moduels with > slight changes and were borrowing _sre from CPython anyway. > So let's back out our changes in pypy/lib and see how far we > get (if nobody minds, Seo?) But I mind! Let me explain this... Just before the checkin (r8718), there were following files in pypy/lib related to regular expression: re.py, dumbre.py, plexre.py, sre_adapt.py, sre_parse.py. You deleted re.py, sre_adapt.py, sre_parse.py. re.py contained (intended to contain) backend-neutral interface and utilities, like this: def match(pattern, string, flags=0): return compile(pattern, flags).match(string) And compile() does memoizing, just as CPython, etc. And re.escape() copied from CPython. These are backend-neutral. re.py imported Pattern class from the backend. Pattern's initializer has signature __init__(self, pattern, flags), and has methods of C type _sre.SRE_Pattern, like match, search, etc. And there were three backends (draft of backends) providing this Pattern class: dumbre.py, plexre.py, sre_adapt.py. Only sre_adapt.py imports CPython's _sre, others don't! You can read dumbre.py and plexre.py now, since you didn't delete them by mistake. :-) See, "dumbre.py" is exactly what you're referring as "see how far we get". It exits as soon as regular expression is used, and reports what was used. And this was the default re.py imported. (see below) "plexre.py" is more interesting, and it uses Plex to implement (for now) match(), but returns bool rather than full Match object. This is sufficient for all "if re.match(pattern, string):" tests, and this let pickle import and run, unmodified. (As I wrote in the log of r8636...) pickle uses regular expression only once, as following: __all__.extend([x for x in dir() if re.match("[A-Z][A-Z0-9_]+$",x)]) This also means PyPy interprets all of Plex just fine. Since Plex does regular expression parsing, NFA->DFA transformation, state machine all in pure Python, this is actually quite cool. "sre_adapt.py" is, as you see, cheating. It contains a single line: Pattern = sre_compile.compile And this does not work. Currently C types are not succesfully faked, so _sre.SRE_Pattern instances are created (well, see below) but all method calls will result in long traceback. I asked why is this on IRC long time ago, and I heard that it's because this C type lacks __dict__. Same applies for _random.Random, I think. That's why we have pure Python random.py from 2.2.3 in lib directory now. And why is sre_parse.py patched? Because, without those, no _sre.SRE_Pattern instances will be created, because PyPy fails to interpret some part of sre_parse.py. How to reproduce this problem: (with current PyPy) >>>> re.compile('a*') Traceback (application level): (snip) AttributeError: getwidth Why is this? I wrote my reasoning on the log of this file... r3332 and r3456. To show what's going on, I will give an example: class A: def getwidth(self): print 'hahaha' class B: def getwidth(self): print 'lalala' class C: def __getitem__(self, index): return A() def __getslice__(self, start, stop): return B() c = C() c[0].getwidth() c[0:1].getwidth() CPython prints hahaha and lalala. PyPy prints both hahaha. And sre_parse uses __getslice__... And this is the only place getslice is used, in entire Python standard library! (except those in UserList and UserString) And getslice is deprecated since release 2.0, as officially announced in Language Reference 3.3.6. Okay, can I back your deletion now? :-) Seo Sanghyeon From tinuviel at sparcs.kaist.ac.kr Mon Jan 31 03:19:17 2005 From: tinuviel at sparcs.kaist.ac.kr (Seo Sanghyeon) Date: Mon, 31 Jan 2005 11:19:17 +0900 Subject: [pypy-dev] Regular Expression in PyPy Message-ID: <20050131021917.GA13500@sparcs.kaist.ac.kr> In the checkin message of r8719, hpk wrote: > Ok, it seems we had a mix of python 2.4 and 2.3 moduels with > slight changes and were borrowing _sre from CPython anyway. > So let's back out our changes in pypy/lib and see how far we > get (if nobody minds, Seo?) But I mind! Let me explain this... Just before the checkin (r8718), there were following files in pypy/lib related to regular expression: re.py, dumbre.py, plexre.py, sre_adapt.py, sre_parse.py. You deleted re.py, sre_adapt.py, sre_parse.py. re.py contained (intended to contain) backend-neutral interface and utilities, like this: def match(pattern, string, flags=0): return compile(pattern, flags).match(string) And compile() does memoizing, just as CPython, etc. And re.escape() copied from CPython. These are backend-neutral. re.py imported Pattern class from the backend. Pattern's initializer has signature __init__(self, pattern, flags), and has methods of C type _sre.SRE_Pattern, like match, search, etc. And there were three backends (draft of backends) providing this Pattern class: dumbre.py, plexre.py, sre_adapt.py. Only sre_adapt.py imports CPython's _sre, others don't! You can read dumbre.py and plexre.py now, since you didn't delete them by mistake. :-) See, "dumbre.py" is exactly what you're referring as "see how far we get". It exits as soon as regular expression is used, and reports what was used. And this was the default re.py imported. (see below) "plexre.py" is more interesting, and it uses Plex to implement (for now) match(), but returns bool rather than full Match object. This is sufficient for all "if re.match(pattern, string):" tests, and this let pickle import and run, unmodified. (As I wrote in the log of r8636...) pickle uses regular expression only once, as following: __all__.extend([x for x in dir() if re.match("[A-Z][A-Z0-9_]+$",x)]) This also means PyPy interprets all of Plex just fine. Since Plex does regular expression parsing, NFA->DFA transformation, state machine all in pure Python, this is actually quite cool. "sre_adapt.py" is, as you see, cheating. It contains a single line: Pattern = sre_compile.compile And this does not work. Currently C types are not succesfully faked, so _sre.SRE_Pattern instances are created (well, see below) but all method calls will result in long traceback. I asked why is this on IRC long time ago, and I heard that it's because this C type lacks __dict__. Same applies for _random.Random, I think. That's why we have pure Python random.py from 2.2.3 in lib directory now. And why is sre_parse.py patched? Because, without those, no _sre.SRE_Pattern instances will be created, because PyPy fails to interpret some part of sre_parse.py. How to reproduce this problem: (with current PyPy) >>>> re.compile('a*') Traceback (application level): (snip) AttributeError: getwidth Why is this? I wrote my reasoning on the log of this file... r3332 and r3456. To show what's going on, I will give an example: class A: def getwidth(self): print 'hahaha' class B: def getwidth(self): print 'lalala' class C: def __getitem__(self, index): return A() def __getslice__(self, start, stop): return B() c = C() c[0].getwidth() c[0:1].getwidth() CPython prints hahaha and lalala. PyPy prints both hahaha. And sre_parse uses __getslice__... And this is the only place getslice is used, in entire Python standard library! (except those in UserList and UserString) And getslice is deprecated since release 2.0, as officially announced in Language Reference 3.3.6. Okay, can I back your deletion now? :-) Seo Sanghyeon From hpk at trillke.net Mon Jan 31 10:04:24 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 31 Jan 2005 10:04:24 +0100 Subject: [pypy-dev] Regular Expression in PyPy In-Reply-To: <20050131043918.GA31503@sparcs.kaist.ac.kr> References: <20050131043918.GA31503@sparcs.kaist.ac.kr> Message-ID: <20050131090424.GE9235@solar.trillke.net> Hi Seo, On Mon, Jan 31, 2005 at 13:39 +0900, Seo Sanghyeon wrote: > In the checkin message of r8719, hpk wrote: > > Ok, it seems we had a mix of python 2.4 and 2.3 moduels with > > slight changes and were borrowing _sre from CPython anyway. > > So let's back out our changes in pypy/lib and see how far we > > get (if nobody minds, Seo?) > > But I mind! Let me explain this... > ... Thanks for the explanation. I have to admit that i am still somewhat confused by the situation :-) > ... > Okay, can I back your deletion now? :-) Sure, go ahead. It would make a lot of sense, i think, if you paste your reasoning in your mail into a "README.txt" file in pypy/lib under the section "regular expression related modules in PyPy" with date and author :-) I remember that Anders had better success regarding some regression tests by just using the plain CPython re.py, maybe he can mention here some details as well. cheers, holger