From arigo at tunes.org Sat May 1 09:11:40 2004 From: arigo at tunes.org (Armin Rigo) Date: Sat, 1 May 2004 08:11:40 +0100 Subject: [pypy-dev] Brainstorming at Python UK In-Reply-To: <20040427211550.GA6262@vicky.ecs.soton.ac.uk> References: <20040427211550.GA6262@vicky.ecs.soton.ac.uk> Message-ID: <20040501071140.GA10381@vicky.ecs.soton.ac.uk> Hi, On Tue, Apr 27, 2004 at 10:15:50PM +0100, Armin Rigo wrote: > The general idea is to leverage what we have already built for translation, > including the annotation-propagation framework, but replace the annotations > themselves with something more reasonable. I experimented in this direction at: http://codespeak.net/svn/pypy/branch/typeinference/ annotation.model contains the basic Some* classes annotation.binaryop has the logic for the union, plus other binary ops annotation.test.test_model Together they replace the horribly obscure annotation.annset and its merge nightmare, which is gone together with its test suite. annotation.factory factories remember how to create mutable objects The rest (in pypy/translator) is in a no-test-passing state, but very simple functions like simple_func (i -> i+1) can already be successfully analysed and Pyrexed with translator/translator.py. Armin From hpk at trillke.net Wed May 5 18:42:37 2004 From: hpk at trillke.net (holger krekel) Date: Wed, 5 May 2004 18:42:37 +0200 Subject: [pypy-dev] new autopath logic? Message-ID: <20040505164237.GO19909@solar.trillke> Hi, as many of you may know, we are using copies of pypy/tool/autopath.py in a couple of places in order to insert a correct Python search path for 'import pypy.xxx.yyy' to succeed. With "import autopath" as the first line all the test_*.py can be invoked directly from the commandline and directly run. However, autopath.py needs the information about the top-directory ('pypy' in our case) to be encoded. It would be nicer to have an autopath.py that is independent from a particular project. So what about trying to automize it completly like this: Start from the directory where the invoked script/test is in and look upwards for a directory *not* containing __init__.py anymore: This would be the directory that needs to be ensured to be in sys.path. The last one would we the autopath.projectdir so you can reference non-python resource files in the project. I checked a bit and for pypy this should work as well as for the other projects that use a clone of autopath.py. Opinions? cheers, holger From lac at strakt.com Wed May 5 18:44:21 2004 From: lac at strakt.com (Laura Creighton) Date: Wed, 05 May 2004 18:44:21 +0200 Subject: [pypy-dev] new autopath logic? In-Reply-To: Message from holger krekel of "Wed, 05 May 2004 18:42:37 +0200." <20040505164237.GO19909@solar.trillke> References: <20040505164237.GO19909@solar.trillke> Message-ID: <200405051644.i45GiLPc031726@ratthing-b246.strakt.com> In a message of Wed, 05 May 2004 18:42:37 +0200, holger krekel writes: >Hi, > >as many of you may know, we are using copies of pypy/tool/autopath.py in >a couple of places in order to insert a correct Python search path for >'import pypy.xxx.yyy' to succeed. With "import autopath" as the first li >ne >all the test_*.py can be invoked directly from the commandline and >directly run. However, autopath.py needs the information about the >top-directory ('pypy' in our case) to be encoded. It would be nicer >to have an autopath.py that is independent from a particular project. > >So what about trying to automize it completly like this: Start from the >directory where the invoked script/test is in and look upwards for a >directory *not* containing __init__.py anymore: This would be the >directory that needs to be ensured to be in sys.path. The last >one would we the autopath.projectdir so you can reference non-python >resource files in the project. > >I checked a bit and for pypy this should work as well as for >the other projects that use a clone of autopath.py. Opinions? > >cheers, > > holger Sounds good. Maybe we write a PEP and get it into the standard library, too. Laura From hpk at trillke.net Wed May 5 18:46:39 2004 From: hpk at trillke.net (holger krekel) Date: Wed, 5 May 2004 18:46:39 +0200 Subject: [pypy-dev] new autopath logic? In-Reply-To: <200405051644.i45GiLPc031726@ratthing-b246.strakt.com> References: <20040505164237.GO19909@solar.trillke> <200405051644.i45GiLPc031726@ratthing-b246.strakt.com> Message-ID: <20040505164639.GP19909@solar.trillke> [Laura Creighton Wed, May 05, 2004 at 06:44:21PM +0200] > In a message of Wed, 05 May 2004 18:42:37 +0200, holger krekel writes: > >Hi, > > > >as many of you may know, we are using copies of pypy/tool/autopath.py in > >a couple of places in order to insert a correct Python search path for > >'import pypy.xxx.yyy' to succeed. With "import autopath" as the first li > >ne > >all the test_*.py can be invoked directly from the commandline and > >directly run. However, autopath.py needs the information about the > >top-directory ('pypy' in our case) to be encoded. It would be nicer > >to have an autopath.py that is independent from a particular project. > > > >So what about trying to automize it completly like this: Start from the > >directory where the invoked script/test is in and look upwards for a > >directory *not* containing __init__.py anymore: This would be the > >directory that needs to be ensured to be in sys.path. The last > >one would we the autopath.projectdir so you can reference non-python > >resource files in the project. > > > >I checked a bit and for pypy this should work as well as for > >the other projects that use a clone of autopath.py. Opinions? > > > >cheers, > > > > holger > > Sounds good. Maybe we write a PEP and get it into the standard library, > too. wow, that took 2 minutes roundtrip :-) Yes, putting it in a standard place would be nicer than having to distribute it all over the project. For the time beeing this needs to be done, though. cheers, holger From arigo at tunes.org Fri May 7 00:33:32 2004 From: arigo at tunes.org (Armin Rigo) Date: Thu, 6 May 2004 23:33:32 +0100 Subject: [pypy-dev] Brainstorming at Python UK In-Reply-To: <20040501071140.GA10381@vicky.ecs.soton.ac.uk> References: <20040427211550.GA6262@vicky.ecs.soton.ac.uk> <20040501071140.GA10381@vicky.ecs.soton.ac.uk> Message-ID: <20040506223332.GA16288@vicky.ecs.soton.ac.uk> Hello all, On Sat, May 01, 2004 at 08:11:40AM +0100, Armin Rigo wrote: > http://codespeak.net/svn/pypy/branch/typeinference/ The branch has been merged back to the trunk. All tests pass (minus one in pypy/interpreter that didn't pass before), and there are a few new tests too. A good starting point to understand annotation: pypy/annotation/model.py Enjoy! Armin From lac at strakt.com Fri May 7 15:26:32 2004 From: lac at strakt.com (Laura Creighton) Date: Fri, 7 May 2004 15:26:32 +0200 Subject: [pypy-dev] I just unpacked a Mimio XI electronic portable whiteboard. Message-ID: <200405071326.i47DQVTZ007285@ratthing-b246.strakt.com> http://www.mimio.com/ It is supposed to work with Linux, but all I got was a windows driver. Working on getting that fixed now. But seems a fund toy for Sprints. Laura From lac at strakt.com Fri May 7 16:43:29 2004 From: lac at strakt.com (Laura Creighton) Date: Fri, 07 May 2004 16:43:29 +0200 Subject: [pypy-dev] Re: I just unpacked a Mimio XI electronic portable whiteboard. In-Reply-To: Message from Laura Creighton of "Fri, 07 May 2004 15:26:32 +0200." <200405071326.i47DQVTZ007285@ratthing-b246.strakt.com> References: <200405071326.i47DQVTZ007285@ratthing-b246.strakt.com> Message-ID: <200405071443.i47EhTw3007838@ratthing-b246.strakt.com> In a message of Fri, 07 May 2004 15:26:32 +0200, Laura Creighton writes: >http://www.mimio.com/ > >It is supposed to work with Linux, but all I got was a windows driver. >Working on getting that fixed now. But seems a fund toy for Sprints. > >Laura A _fun_ toy even .... Laura From arigo at tunes.org Sat May 8 22:10:47 2004 From: arigo at tunes.org (Armin Rigo) Date: Sat, 8 May 2004 21:10:47 +0100 Subject: [pypy-dev] svn up: "object with the same name already exists" Message-ID: <20040508201047.GA15400@vicky.ecs.soton.ac.uk> Hello, If you do an "svn up" it is going to fail. To solve that, delete the following two directories from your working copy: Pyrex Plex (These directories are at the same level as the one called "pypy".) Then do svn up again. The cause is that we switched to a new version of Pyrex and reorganized the repository to make it easier to switch to new versions in the future: Pyrex is now tracked in http://codespeak.net/svn/vendor/Pyrex/. It is copied from there and modified as needed for PyPy. See the svn commit message for details. As a result, the directory pypy/trunk/src/Pyrex, which used to be an external link, is now a real directory. Subversion doesn't realize the external link is gone before it tries to create the directory, and complains because a directory of the same name already exists in your working copy. Armin From arigo at tunes.org Tue May 11 21:56:37 2004 From: arigo at tunes.org (Armin Rigo) Date: Tue, 11 May 2004 20:56:37 +0100 Subject: [pypy-dev] Pygame graph viewer Message-ID: <20040511195637.GA25476@vicky.ecs.soton.ac.uk> Hello, I've been hacking on a Pygame-based viewer for the control flow graphs. See pypy/translator/tool/pygame/graphviewer.py. The idea is to display the graph as computed by 'dot', but more interactively. The hard part was to figure out where, in the image, each variable name actually is on the screen; now you can move the mouse around and when it is over a variable name you see the corresponding annotation, inferred by the new stuff in pypy/annotation/. The goal is to clean up and link it to the annotator a bit more, so that you can see it while it progresses (as if doing a step-by-step debugging). I guess it would be quite a useful debugging tool, aside from being presentation-friendly :-) A bientot, Armin. From lac at strakt.com Fri May 14 11:49:28 2004 From: lac at strakt.com (Laura Creighton) Date: Fri, 14 May 2004 11:49:28 +0200 Subject: [pypy-dev] Is Rocco Moretti coming to EuroPython? Message-ID: <200405140949.i4E9nSmj029522@ratthing-b246.strakt.com> Haven't heard anything from him recently. I was hoping he would be around for some Sprinting ... Laura From roccomoretti at hotpop.com Fri May 14 15:54:44 2004 From: roccomoretti at hotpop.com (Rocco Moretti) Date: Fri, 14 May 2004 08:54:44 -0500 Subject: [pypy-dev] Is Rocco Moretti coming to EuroPython? In-Reply-To: <200405140949.i4E9nSmj029522@ratthing-b246.strakt.com> References: <200405140949.i4E9nSmj029522@ratthing-b246.strakt.com> Message-ID: <40A4CFA4.4090006@hotpop.com> Laura Creighton wrote: > Haven't heard anything from him recently. I was hoping he would be around for > some Sprinting ... > > Laura I must say I'm touched. I've been incommunicado so long, I'd have guessed you would have thought that I've abandoned you. No, it's just that I've been incredibly busy recently. Hopefully, I'll have some free time in the coming months to lend to PyPy, but unfortunately EuroPython won't be one of them. You're in my heart, if not on my immediate list of things to do. -Rocco From roccomoretti at hotpop.com Fri May 14 16:04:02 2004 From: roccomoretti at hotpop.com (Rocco Moretti) Date: Fri, 14 May 2004 09:04:02 -0500 Subject: [pypy-dev] new autopath logic? In-Reply-To: <20040505164639.GP19909@solar.trillke> References: <20040505164237.GO19909@solar.trillke> <200405051644.i45GiLPc031726@ratthing-b246.strakt.com> <20040505164639.GP19909@solar.trillke> Message-ID: <40A4D1D2.1020302@hotpop.com> holger krekel wrote: > [Laura Creighton Wed, May 05, 2004 at 06:44:21PM +0200] > >>Sounds good. Maybe we write a PEP and get it into the standard library, >>too. > > wow, that took 2 minutes roundtrip :-) > > Yes, putting it in a standard place would be nicer than having to > distribute it all over the project. For the time beeing this needs > to be done, though. Well, until it gets into the standard library, you could spin it out as a separate project. Set up a quick distutils script to install it into the library path, and it's like it's in the standard library - and this would work with existing versions of Python too. This would add a dependency to PyPy, but as long as it is small and doesn't update too often, this shouldn't be too onerous. -Rocco From hpk at trillke.net Fri May 14 16:42:11 2004 From: hpk at trillke.net (holger krekel) Date: Fri, 14 May 2004 16:42:11 +0200 Subject: [pypy-dev] new autopath logic? In-Reply-To: <40A4D1D2.1020302@hotpop.com> References: <20040505164237.GO19909@solar.trillke> <200405051644.i45GiLPc031726@ratthing-b246.strakt.com> <20040505164639.GP19909@solar.trillke> <40A4D1D2.1020302@hotpop.com> Message-ID: <20040514144210.GM9281@solar.trillke> Hi Rocco, [Rocco Moretti Fri, May 14, 2004 at 09:04:02AM -0500] > holger krekel wrote: > > >[Laura Creighton Wed, May 05, 2004 at 06:44:21PM +0200] > > > >>Sounds good. Maybe we write a PEP and get it into the standard library, > >>too. > > > >wow, that took 2 minutes roundtrip :-) > > > >Yes, putting it in a standard place would be nicer than having to > >distribute it all over the project. For the time beeing this needs > >to be done, though. > > Well, until it gets into the standard library, you could spin it out as > a separate project. Set up a quick distutils script to install it into > the library path, and it's like it's in the standard library - and this > would work with existing versions of Python too. Yes, this would work but we want to avoid dependencies on stuff other than distributed in .../pypy/src as long as possible. The main point was that i want to have one single unmodified version of 'autopath.py' that can be used verbatim in multiple projects. I have meanwhile implemented such a version (based on looking for __init__.py upwards) and it works reasonably well with some obvious restrictions. With the upcoming 'std' library (containing Armin's and my new 'utest' packge) you will be able to do from std.magic import autopath with the kind-of-same desired effect. However, with the strict dependency rule above we cannot use this as 'std' is not guaruanteed to be in the path. > This would add a dependency to PyPy, but as long as it is small and > doesn't update too often, this shouldn't be too onerous. Let's at least try to keep the number of pre-installed dependencies at zero as along as we can :-) cheers, holger From arigo at tunes.org Mon May 24 22:02:42 2004 From: arigo at tunes.org (Armin Rigo) Date: Mon, 24 May 2004 21:02:42 +0100 Subject: [pypy-dev] Re: [pypy-sprint] sprint quickly approaching In-Reply-To: <20040524094506.GD7763@solar.trillke> References: <20040524094506.GD7763@solar.trillke> Message-ID: <20040524200242.GA15854@vicky.ecs.soton.ac.uk> Hello, Here are some info about the state of PyPy and what we expect to work on during the upcoming sprint. On annotations -------------- There isn't much more than already described on the "Brainstorming" thread. The annotations are implemented just as I wrote they should be. It just works, basically. There are a few more SomeXxx classes than described in the e-mails, like SomeClass, SomeInstance, and SomeMethod to analyse OOP programs. It should be quite easy to have an overview of what these mean just by reading pypy.annotation.model. So the current status is that we can analyse simple RPython programs. The next two things do be done in this direction and that should be put on the sprint's schedule are: * complete the Pyrex code writer; we are in the unlikely state where we can analyse more stuff than we can actually write code for (e.g. methods in classes). * try to analyse larger programs, seeing if the time we need for the analysis remains reasonable or explodes. We should give a try at analysing py.py's entry point itself and moving on as numerous hard and unexpected problems pop up. For example, we'll need a way to tell the analysis/translator that some bits of PyPy are only lazy computations of stuff that gets cached into a dictionary after the first use (so that the translator should trigger the computation and just pick the value from the cache instead of analysing the cache-populating code). On objspace.std --------------- The other thing we might put on our agenda is refactoring the object model (i.e. objspace.std). The multimethod thing is great but really hard to match to the Python semantics of new-style classes and descriptors. As far as I can see, a reasonable way to rethink the problem would be to start from the usual type-based semantics of Python, e.g. really defining a+b to mean a.__add__(b) or if it fails b.__radd__(a). The multimethod declarations would not be used for dispatching, but only to initialize the proper __add__ and __radd__ methods on the proper classes. This would give the cleanest result. This would probably be slower than the current multimethod dispatch hack, but being able to remove multimethod.py altogether is no small achievement in the direction of clarity :-) Then we could consider if we could reintroduce direct multimethod-style dispatching as an optional optimization. Well, just a thought. Maybe it's not worth the effort right now. There are only a few constructs missing to be able to run most "common" programs, for example super(). Defining super() at app-level Python should be possible, but is not currently because the required details don't work as expected. But we could define super() at interp-level and just forget about the whole issue for some time. On modules ---------- As always there is the open goal of implementing more built-in functions and modules, and making sure that more of the implemented features actually work. As always, we have two big missing features: the bytecode compiler and the import mechanism. Note that an easy but interesting goal would be to isolate a version of py.py that can be moved anywhere (as long as pypy is in the PYTHONPATH) and used as a replacement for the python executable. The first thing that usually fails whenever I try to start py.py on some program is an import statement. I'm not sure what the state of sys.path & co is. On everything I forget ---------------------- There are a lot of areas to work on too. For example writing docs, the trace object space, writing docs, more debugging support (kill these huge tracebacks!), porting the tests to 'std.utest' (I'll let Holger introduce this one to pypy-dev), organizing docs, cleaning up the wiki and replacing it with ReST docs ... A bient?t, Armin From hpk at trillke.net Tue May 25 01:33:30 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 25 May 2004 01:33:30 +0200 Subject: [pypy-dev] Re: [pypy-sprint] sprint quickly approaching In-Reply-To: <20040524200242.GA15854@vicky.ecs.soton.ac.uk> References: <20040524094506.GD7763@solar.trillke> <20040524200242.GA15854@vicky.ecs.soton.ac.uk> Message-ID: <20040524233330.GK7763@solar.trillke> Hi all, [Armin Rigo Mon, May 24, 2004 at 09:02:42PM +0100] > There are a lot of areas to work on too. For example writing docs, the trace > object space, writing docs, more debugging support (kill these huge > tracebacks!), porting the tests to 'std.utest' (I'll let Holger introduce this > one to pypy-dev), organizing docs, cleaning up the wiki and replacing it with > ReST docs ... Here we go. The basic means of doing tests in 'std.utest' is the assert statement. So instead of e.g. self.assertEquals(x,y) one does assert x == y and you will see nice output in case of a failure, i.e. the values of x and y. Porting interpreter-level tests should obviously be fairly easy and increase readability quite a bit especially as statements like 'assert isinstance(x, Y)' also print nicely. However, application levels tests are a different story that need more consideration. Under the hood, std.utest deploys a mini-interpreter to 'reinterpret' the expression from the assert statement. It's probably a nice exercise to rewrite this mini-interpreter to use an objectspace to extract and compute values. I think the conversion of the tests is a nice sprint task but should probably happen on a branch for some time to not disrupt testing for the other participants. There are also some other details of pypy's current way of doing tests to consider but nothing crucial as far as see. cheers, holger From hpk at trillke.net Wed May 26 22:06:06 2004 From: hpk at trillke.net (holger krekel) Date: Wed, 26 May 2004 22:06:06 +0200 Subject: [pypy-dev] mailman upgrade train Message-ID: <20040526200606.GS12594@solar.trillke> hi folks, I am going to do some upgrading on mailman (to 2.1.5), so please stand by while the train is approaching ... holger From bernstorff_lehmann at mail.tele.dk Wed May 12 22:57:22 2004 From: bernstorff_lehmann at mail.tele.dk (Anders Lehmann) Date: Wed, 12 May 2004 22:57:22 +0200 Subject: [pypy-dev] Re: Pygame graph viewer References: <20040511195637.GA25476@vicky.ecs.soton.ac.uk> Message-ID: In order to make Graphviewer work on windows I had to make some changes, concerning handling of binary files. I have attached a patch. I dont want to check it in because I dont think it is the right solution, and it doesnt work on linux. Great and fun work Armin Anders Lehmann "Armin Rigo" wrote in message news:20040511195637.GA25476 at vicky.ecs.soton.ac.uk... > Hello, > > I've been hacking on a Pygame-based viewer for the control flow graphs. > See pypy/translator/tool/pygame/graphviewer.py. The idea is to display the > graph as computed by 'dot', but more interactively. The hard part was to > figure out where, in the image, each variable name actually is on the screen; > now you can move the mouse around and when it is over a variable name you see > the corresponding annotation, inferred by the new stuff in pypy/annotation/. > > The goal is to clean up and link it to the annotator a bit more, so that you > can see it while it progresses (as if doing a step-by-step debugging). I > guess it would be quite a useful debugging tool, aside from being > presentation-friendly :-) > > > A bientot, > > Armin. > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > begin 666 grapviewer_win.patch M26YD97 at Z('-R8R]P>7!Y+W1R86YS;&%T;W(O=&]O;"]M86ME7V1O="YP>0T* M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/0T*+2TM('-R8R]P>7!Y+W1R86YS;&%T M;W(O=&]O;"]M86ME7V1O="YP>0DH2]T2D-"D! ("TQ-C L." K,38P+#$R($! #0H@(" @("-P&5C M7V-M9"@G9&]T("U4)7,@)7,G("4@*'1A Message-ID: <000d01c4391c$5d3b6e60$3b5ca8d5@Lieschen2> > Hello, > > I've been hacking on a Pygame-based viewer for the control flow graphs. > See pypy/translator/tool/pygame/graphviewer.py. The idea is to display the > graph as computed by 'dot', but more interactively. The hard part was to > figure out where, in the image, each variable name actually is on the screen; > now you can move the mouse around and when it is over a variable name you see > the corresponding annotation, inferred by the new stuff in pypy/annotation/. > > The goal is to clean up and link it to the annotator a bit more, so that you > can see it while it progresses (as if doing a step-by-step debugging). I > guess it would be quite a useful debugging tool, aside from being > presentation-friendly :-) > > > A bientot, > > Armin. Hello Armin, it's a pity, that I will not be at Europython this year. I think your presentation will be a highlight of this conference! For text output and user interfaces on top of Pygame take a look at Sean Riley's PyUI http://pyui.sourceforge.net/ However, it seems, that the latest development is for the Windows platform only. Actually I did not use PyUI. I only read the description in Sean Riley. Game Programming with Python http://www.amazon.co.uk/exec/obidos/ASIN/1584502584/ref=ase_lowthcom-21/202-6545448-9339031 Seems to be a great book. Guenter From hpk at trillke.net Wed May 26 23:26:30 2004 From: hpk at trillke.net (holger krekel) Date: Wed, 26 May 2004 23:26:30 +0200 Subject: [pypy-dev] mailman upgrade train In-Reply-To: <20040526200606.GS12594@solar.trillke> References: <20040526200606.GS12594@solar.trillke> Message-ID: <20040526212630.GU12594@solar.trillke> [holger krekel Wed, May 26, 2004 at 10:06:06PM +0200] > hi folks, > > I am going to do some upgrading on mailman (to 2.1.5), so please > stand by while the train is approaching ... ... which just arrived. i dis- and recovered some non-spam mails (from 12th and 13th of may actually) and they were now send. Send me a private mail if you notice problems ... cheers, holger From arigo at tunes.org Thu May 27 12:02:31 2004 From: arigo at tunes.org (Armin Rigo) Date: Thu, 27 May 2004 11:02:31 +0100 Subject: [pypy-dev] Re: Pygame graph viewer In-Reply-To: References: <20040511195637.GA25476@vicky.ecs.soton.ac.uk> Message-ID: <20040527100231.GA2584@vicky.ecs.soton.ac.uk> Hello Anders, On Wed, May 12, 2004 at 10:57:22PM +0200, Anders Lehmann wrote: > In order to make Graphviewer work on windows I had to make some changes, > concerning handling of binary files. I have attached a patch. I guess you forgot to include the patch for vpath.adapter.process? It looks like your patch needs the exec_cmd() to accept an extra 'b'inary/'t'ext argument. If I'm right then the Linux fix should be to add (and ignore) the same argument to posix_exec_cmd(). Armin From hpk at trillke.net Fri May 28 11:26:42 2004 From: hpk at trillke.net (holger krekel) Date: Fri, 28 May 2004 11:26:42 +0200 Subject: [pypy-dev] new mailman / spam configuration Message-ID: <20040528092642.GM12594@solar.trillke> Hi, eventually codespeak.net's mailman 2.1.5 is now using spambayes 1.0_rc1 to drop spams to all mailing lists. This is done by a small patch of mine and with a 1-year trained database from Michael Hudson (thanks!). If anything goes wrong, that will be my fault so please mail me privately, or better yet, always mail root at codespeak.net in case of problems with codespeak. It would also be nice to get feedback from list admins that everything works well. Hope to see you all at EuroPython, where I will be looking for additional admins (currently it's Jens-Uwe Mager and me) not the least because there are a number of projects interested to move to codespeak ... cheers, holger From arigo at tunes.org Fri May 28 12:51:02 2004 From: arigo at tunes.org (Armin Rigo) Date: Fri, 28 May 2004 11:51:02 +0100 Subject: [pypy-dev] Debugging aid Message-ID: <20040528105101.GA12952@vicky.ecs.soton.ac.uk> Hello, There are a few "para-PyPy" tasks that we should consider for the near future too (like, during the sprint): it would be extremely helpful for example to have better debugging tools. A PyPy traceback is, as you know, a lots of pages of unhelpful data. The kind of thing that would help is a shell-like window into which the debugged program can "print" quite a lot of information, which can be expanded or contracted by a mouse click or keystroke; e.g. only show the app-level traceback, but each step in there can expand to the corresponding interp-level traceback; each step in there expands in the local variables, the objects expand into their attributes, etc... I'm sure this already exists, but there is still a bit of work to integrate something like that with PyPy (e.g. know about the two app- and interp- levels). It should also get integrated with the (new) test suite, to directly inspect failing tests. If you are more graphically oriented, there is the control flow viewer at pypy.translator.tool.pygame.graphviewer that needs more work. I am pretty sure we will need a good debugging tool to understand what is going on when we start annotating larger programs. I bet it should have a history, e.g. record all the annotation steps as they progress and redo previous blocks and allow browsing through these "revisions". It should also have "zooming", at least to switch between a program-wide view of the function call graph and the control flow graph inside of a particular function. These are at least the basic tools that would help quite a bit in PyPy debugging... A bient?t, Armin. From lac at strakt.com Sat May 29 10:06:06 2004 From: lac at strakt.com (Laura Creighton) Date: Sat, 29 May 2004 10:06:06 +0200 Subject: [pypy-dev] From Jiwon -- what is not getting to pypy-dev Message-ID: <200405290806.i4T866cN011336@ratthing-b246.strakt.com> What he would like as a patch Index: module/__builtin__module.py =================================================================== --- module/__builtin__module.py (revision 4699) +++ module/__builtin__module.py (working copy) @@ -427,7 +427,7 @@ from __interplevel__ import hash, oct, hex, round from __interplevel__ import getattr, setattr, delattr, iter, hash, id from __interplevel__ import issubclass, _pypy_get -from __interplevel__ import compile +from __interplevel__ import compile, eval from __interplevel__ import globals, locals, _caller_globals, _caller_locals from __interplevel__ import file Index: module/__builtin__interp.py =================================================================== --- module/__builtin__interp.py (revision 4699) +++ module/__builtin__interp.py (working copy) @@ -92,7 +92,26 @@ raise OperationError(space.w_TypeError,space.wrap(str(e))) return space.wrap(PyCode()._from_code(c)) +def eval(w_source, w_globals=None, w_locals=None): + w_codeobj = None + w = space.wrap + if space.type(w_source) == space.w_str: + w_codeobj = compile(w_source, w(""), w("eval")) + elif type(space.unwrap(w_source)) == PyCode: + w_codeobj = w_source + else: + raise OperationError(space.w_TypeError, + w('eval() arg 1 must be a string or code object')) + + if w_globals == None: + w_globals = globals() + w_locals = locals() + elif w_locals == None: + w_locals = w_globals + + return space.unwrap(w_codeobj).exec_code(space, w_globals, w_locals) + def abs(w_val): return space.abs(w_val) From lac at strakt.com Sat May 29 10:18:36 2004 From: lac at strakt.com (Laura Creighton) Date: Sat, 29 May 2004 10:18:36 +0200 Subject: [pypy-dev] Jiwon's new __builtin__interp.py file Message-ID: <200405290818.i4T8Ia93011420@ratthing-b246.strakt.com> """ Implementation of interpreter-level builtins. """ import os from pypy.interpreter.module import Module from pypy.interpreter.pycode import PyCode from pypy.interpreter.error import OperationError _noarg = object() import __builtin__ as cpy_builtin w_file = space.wrap(cpy_builtin.file) # import useful app-level functions from __applevel__ import execfile, callable, _iter_generator def _actframe(position=0): return space.getexecutioncontext().framestack.top(position) def globals(): return _actframe().w_globals def locals(): return _actframe().getdictscope() def _caller_globals(w_index=None): position = space.unwrapdefault(w_index, 1) return _actframe(position).w_globals def _caller_locals(w_index=None): position = space.unwrapdefault(w_index, 1) return _actframe(position).getdictscope() def __import__(w_modulename, w_globals=None, w_locals=None, w_fromlist=None): modulename = space.unwrap(w_modulename) if not isinstance(modulename, str): try: helper = ', not ' + modulename.__class__.__name__ except AttributeError: helper = '' raise OperationError(space.w_TypeError, space.wrap("__import__() argument 1 must be string" + helper)) w = space.wrap try: w_mod = space.getitem(space.sys.w_modules, w_modulename) except OperationError,e: pass else: return w_mod if not e.match(space, space.w_KeyError): raise w_mod = space.get_builtin_module(modulename) if w_mod is not None: return w_mod import os for path in space.unpackiterable(space.sys.w_path): f = os.path.join(space.unwrap(path), modulename + '.py') if os.path.exists(f): w_mod = space.wrap(Module(space, w_modulename)) space.sys.setmodule(w_mod) space.setattr(w_mod, w('__file__'), w(f)) w_dict = space.getattr(w_mod, w('__dict__')) execfile(w(f), w_dict, w_dict) return w_mod w_exc = space.call_function(space.w_ImportError, w_modulename) raise OperationError(space.w_ImportError, w_exc) def compile(w_str, w_filename, w_startstr, w_supplied_flags=None, w_dont_inherit=None): str_ = space.unwrap(w_str) filename = space.unwrap(w_filename) startstr = space.unwrap(w_startstr) supplied_flags = space.unwrapdefault(w_supplied_flags, 0) dont_inherit = space.unwrapdefault(w_dont_inherit, 0) #print (str_, filename, startstr, supplied_flags, dont_inherit) # XXX we additionally allow GENERATORS because compiling some builtins # requires it. doesn't feel quite right to do that here. try: c = cpy_builtin.compile(str_, filename, startstr, supplied_flags|4096, dont_inherit) # It would be nice to propagate all exceptions to app level, # but here we only propagate the 'usual' ones, until we figure # out how to do it generically. except ValueError,e: raise OperationError(space.w_ValueError,space.wrap(str(e))) except TypeError,e: raise OperationError(space.w_TypeError,space.wrap(str(e))) return space.wrap(PyCode()._from_code(c)) def eval(w_source, w_globals=None, w_locals=None): w_codeobj = None w = space.wrap if space.type(w_source) == space.w_str: w_codeobj = compile(w_source, w(""), w("eval")) elif type(space.unwrap(w_source)) == PyCode: w_codeobj = w_source else: raise OperationError(space.w_TypeError, w('eval() arg 1 must be a string or code object')) if w_globals == None: w_globals = globals() w_locals = locals() elif w_locals == None: w_locals = w_globals return space.unwrap(w_codeobj).exec_code(space, w_globals, w_locals) def abs(w_val): return space.abs(w_val) def chr(w_ascii): w_character = space.newstring([w_ascii]) return w_character def len(w_obj): return space.len(w_obj) def delattr(w_object, w_name): space.delattr(w_object, w_name) return space.w_None def getattr(w_object, w_name, w_defvalue = _noarg): try: return space.getattr(w_object, w_name) except OperationError, e: if e.match(space, space.w_AttributeError): if w_defvalue is not _noarg: return w_defvalue raise def hash(w_object): return space.hash(w_object) def oct(w_val): # XXX does this need to be a space operation? return space.oct(w_val) def hex(w_val): return space.hex(w_val) def round(w_val, w_n=None): if w_n is None: w_n = space.wrap(0) return space.round(w_val, w_n) def id(w_object): return space.id(w_object) #XXX works only for new-style classes. #So we have to fix it, when we add support for old-style classes def issubclass(w_cls1, w_cls2): return space.issubtype(w_cls1, w_cls2) def iter(w_collection_or_callable, w_sentinel = _noarg): if w_sentinel is _noarg: return space.iter(w_collection_or_callable) else: if not space.is_true(callable(w_collection_or_callable)): raise OperationError(space.w_TypeError, space.wrap('iter(v, w): v must be callable')) return _iter_generator(w_collection_or_callable, w_sentinel) def ord(w_val): return space.ord(w_val) def pow(w_base, w_exponent, w_modulus=None): if w_modulus is None: w_modulus = space.w_None return space.pow(w_base, w_exponent, w_modulus) def repr(w_object): return space.repr(w_object) def setattr(w_object, w_name, w_val): space.setattr(w_object, w_name, w_val) return space.w_None def _pypy_get(w_value, w_self, w_class=None): # XXX temporary if w_class is None: w_class = space.w_None return space.get(w_value, w_self, w_class)