From stephan.diehl at gmx.net Mon Mar 3 16:48:16 2008 From: stephan.diehl at gmx.net (Stephan Diehl) Date: Mon, 3 Mar 2008 16:48:16 +0100 Subject: [pypy-dev] Tim Bray Blog Message-ID: <200803031648.16761.stephan.diehl@gmx.net> Hi all, just found this (at reddit, what a time waster :-) ): http://www.tbray.org/ongoing/When/200x/2008/03/03/Python-at-Sun At the end, he's saying: "Quick Python trivia question: Near as I can tell, Guido works half-time on Python over at Google. Is there anyone in the world, aside from Frank and Ted, getting paid to work full-time on Python?" Within pypy, there are several people to work full time on python, aren't there? Stephan From cfbolz at gmx.de Mon Mar 3 17:04:38 2008 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 03 Mar 2008 17:04:38 +0100 Subject: [pypy-dev] Tim Bray Blog In-Reply-To: <200803031648.16761.stephan.diehl@gmx.net> References: <200803031648.16761.stephan.diehl@gmx.net> Message-ID: <47CC2196.3020100@gmx.de> Stephan Diehl wrote: > Hi all, > > just found this (at reddit, what a time waster :-) ): > http://www.tbray.org/ongoing/When/200x/2008/03/03/Python-at-Sun > At the end, he's saying: > "Quick Python trivia question: Near as I can tell, Guido works half-time on > Python over at Google. Is there anyone in the world, aside from Frank and > Ted, getting paid to work full-time on Python?" > Within pypy, there are several people to work full time on python, aren't > there? Not since the EU project ended, no. Cheers, Carl Friedrich From lac at openend.se Mon Mar 3 19:05:27 2008 From: lac at openend.se (Laura Creighton) Date: Mon, 03 Mar 2008 19:05:27 +0100 Subject: [pypy-dev] Tim Bray Blog In-Reply-To: Message from Stephan Diehl of "Mon, 03 Mar 2008 16:48:16 +0100." <200803031648.16761.stephan.diehl@gmx.net> References: <200803031648.16761.stephan.diehl@gmx.net> Message-ID: <200803031805.m23I5RZj012230@theraft.openend.se> In a message of Mon, 03 Mar 2008 16:48:16 +0100, Stephan Diehl writes: >Hi all, > >just found this (at reddit, what a time waster :-) ): >http://www.tbray.org/ongoing/When/200x/2008/03/03/Python-at-Sun >At the end, he's saying: >"Quick Python trivia question: Near as I can tell, Guido works half-time >on >Python over at Google. Is there anyone in the world, aside from Frank and > >Ted, getting paid to work full-time on Python?" >Within pypy, there are several people to work full time on python, aren't > >there? > >Stephan There was as one time, and we hope there will be again. But our EU funding ran out last year. Laura From arigo at tunes.org Wed Mar 5 19:13:44 2008 From: arigo at tunes.org (Armin Rigo) Date: Wed, 5 Mar 2008 19:13:44 +0100 Subject: [pypy-dev] buffer protocol. In-Reply-To: <47B0711D.1030402@genesilico.pl> References: <47B0711D.1030402@genesilico.pl> Message-ID: <20080305181344.GA13311@code0.codespeak.net> Hi Maciek, On Mon, Feb 11, 2008 at 05:00:29PM +0100, Maciek Fijalkowski wrote: > I feel a bit clueless about buffer protocol. Current implemntation in > pypy is purely app-level, which means it's slow, but more importantly, > one cannot get raw, C-level address of it. I've tried approaching the > problem, but it seems that there are several serious issues. > > * what's the future of buffer protocol? > * do people use that? ctypes tests are relying on it. anybody knows > ctypes module implementation that relies on it? > * testing suite sucks. we've got two tests, cpython is not any better in > this regard. > > where to proceed? The future of the buffer protocol, in Python 3000, is to be a bit cleaned up and then made considerably more complicated and powerful (being in this respect similar to most changes in Python 3000). The PEP is here: http://svn.python.org/projects/peps/trunk/pep-3118.txt I think we could still use this as a basis for thought. An interesting thing is that for any object supporting the buffer protocol, a Python object of the new type "memoryview" can be built. This is similar to the existing "buffer" Python type but cleaner in the sense that it is equivalent to the internal data structures -- in fact I'm not sure why Python 3000 needs both an internal data structure and the memoryview object type. What we could do is thus add an interp-level class MemoryView which is a subclass of Wrappable with an API to allow interp-level accesses. To get such a MemoryView from any Python object we'd use a space method, space.memoryview_w(). A trivial extension to Python would be to have a special method name associated to this, like '__memoryview__()', allowing any Python type (built-in or user-defined) to return a MemoryView for itself. The API of MemoryView could be loosely based on (but much much simpler than) the one in the PEP. A bientot, Armin. From jgustak at gmail.com Fri Mar 7 14:46:13 2008 From: jgustak at gmail.com (Jakub Gustak) Date: Fri, 7 Mar 2008 14:46:13 +0100 Subject: [pypy-dev] summer of code 2008 Message-ID: Hello. I am wondering if pypy is going to take part in Google Summer of Code this year. I have an idea, which I would like to hack on (and already talked a little about it with Armin). But I sill am not sure if it makes much sense. I will paste what I send to Armin some time ago: msg << EOM I have this weird idea of creating (yet another) scheme dialect on top of pypy scheme interpreter. Main features of this dialect would be: * strict (in definition) distinction between pure functions, and functions with side-effect. * parallelism support: * e.g. (parallel (f1 ...) (f2 ...)) would compute functions f1 and f2 on different processors (if available) and return list of results. of course, f1 and f2 have to be pure functions in this case. * interpreter would start as many processes as processors available and parallel should schedule functions computation on this "nodes". * communication between nodes should be as much transparent as possible, so we can create nodes on different machines. * there is also another interesting pattern: map-reduce, or scatter-gather, which would be nice to have, if parallel back-end would be capable of this. We could go further, and even avoid using (parallel) construction, and parallelize every pure function. Of course that will make sense, if computation cost is greater than cost of spawning. I am interested, in this, because lot of people are talking, that functional programming is to control parallelism/concurrency, but i haven't seen any functional language where programming "parallel applications" is like eating cream and butter. Similar idea is implemented in haskell, but haskell is lazy, and it works somehow different: http://www.haskell.org/ghc/docs/latest/html/users_guide/lang-parallel.html http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parallel.html EOM Cheers, Jakub Gustak From niko at alum.mit.edu Sat Mar 8 15:07:02 2008 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 8 Mar 2008 15:07:02 +0100 Subject: [pypy-dev] SPy (almost) works in the JVM Message-ID: Just wanted to mention that I fixed several bugs holding SPy [Smalltalk in PyPy] back from working in the JVM. The "mini.image" code now runs, but I'm not sure it does precisely the right thing, as the number of hash marks ("#") that are output differs in the JVM and CLI. The biggest error was the fact that we were converting byte arrays into Java Strings using the default encoding, which I think is UTF-8 (or something). The end result was that we did not read binary files correctly (hence the assertion errors in image decoding). Here is the output of the JVM and the CLI on my machine: ;./targetimageloadingsmalltalk-jvm ../../lang/smalltalk/mini.image ################ Going to execute 78 toplevel bytecodes #####################################################################################################################################994035 bytecodes/sec; 70776 sends/sec ;./targetimageloadingsmalltalk-cli ../../lang/smalltalk/mini.image ################ Going to execute 78 toplevel bytecodes #################################################################################################################################################################################################2418379 bytecodes/sec; 106874 sends/sec Anyway, getting closer... Niko From lac at openend.se Sun Mar 9 10:24:21 2008 From: lac at openend.se (Laura Creighton) Date: Sun, 09 Mar 2008 10:24:21 +0100 Subject: [pypy-dev] Possibly of use in the quest to parse pypy better Message-ID: <200803090924.m299OL8x004075@theraft.openend.se> ------- Forwarded Message From: Andrew Dalke Date: Sun, 9 Mar 2008 03:29:29 +0100 To: testing-in-python at lists.idyll.org X-Mailer: Apple Mail (2.753) Subject: Re: [TIP] branch coverage In late January I mentioned I was working on a parser for Python using PLY as the parser engine. I wanted to experiment with branch coverage in Python by reading the source .py file, building a parse tree, adding instrumentation to the AST, and saving .pyc files with the instrumentation. Then run the regression tests and see which branches weren't covered. I'm not there yet. What I have done is write a Python parser using PLY. It's called "python4ply" and is available at: http://dalkescientific.com/Python/python4ply.html What took even longer than writing the code was writing the tutorial. It shows examples of how to change the lexer, parser, AST, and bytecode generation. I worked through two examples where I instrumented the code to improve testing. The first of these assumes there are problems like this assert 0 not in results, "problem in: %r" % data where the "data" variable should be "results". Assert statements are rarely fully tested and so prone to failure if they ever occur. My example transforms the code to something like _$assert = Y assert X, _$assert where '$' is something that normal Python code can't generate but AST manipulation code can. Details at: http://dalkescientific.com/Python/python4ply- tutorial.html#assert The second shows a way to add statement coverage without using settrace. Details at: http://dalkescientific.com/Python/python4ply-tutorial.html#coverage I didn't get to the point where I could do branch coverage. I didn't have a good enough use cases so wasn't sure what I should implement. Perhaps you've got an idea of how to do it, or something else involving parsing Python code? (If so, take a look at the _ast module from the standard library. It's probably a better solution.) If so, I hope this grammar and code helps. Download: http://dalkescientific.com/Python/python4ply.html Tutorial: http://dalkescientific.com/Python/python4ply-tutorial.html Andrew dalke at dalkescientific.com ------- End of Forwarded Message From verwaest at iam.unibe.ch Mon Mar 10 00:53:26 2008 From: verwaest at iam.unibe.ch (Toon Verwaest) Date: Mon, 10 Mar 2008 00:53:26 +0100 Subject: [pypy-dev] module SomeObject setattr. Message-ID: <20080310005326.teyya1pbwkc4g8g4@www.iam.unibe.ch> Hi, I'm not yet fully comfortable with the PyPy code so I just lay it out here: I have written the following code in the Squeak VM (should change in the future but its just to show the "problem"): objects = [] objtable.objects += [objofspecifictype] This seems not to be translatable since this is translated to: vX = setattr(objtable-module, 'objects', vY). generally setattr are done on SomeInstance which nicely returns None -> SomeImpossibleValue -> the annotator is happy. However, modules appear to be instances of SomeObject on which setattr returns a SomeObject -> type of vX gets broken. (and the bug received is not very obvious since it says that the original type was (none)...) cheers, Toon ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From micahel at gmail.com Mon Mar 10 01:02:44 2008 From: micahel at gmail.com (Michael Hudson) Date: Mon, 10 Mar 2008 13:02:44 +1300 Subject: [pypy-dev] Fwd: module SomeObject setattr. In-Reply-To: References: <20080310005326.teyya1pbwkc4g8g4@www.iam.unibe.ch> Message-ID: This was supposed to go to the list too... ---------- Forwarded message ---------- From: Michael Hudson Date: 10 Mar 2008 13:02 Subject: Re: [pypy-dev] module SomeObject setattr. To: Toon Verwaest On 10/03/2008, Toon Verwaest wrote: > Hi, > > I'm not yet fully comfortable with the PyPy code so I just lay it out here: > > I have written the following code in the Squeak VM (should change in > the future but its just to show the "problem"): > > > objects = [] > > > objtable.objects += [objofspecifictype] > > This seems not to be translatable since this is translated to: > vX = setattr(objtable-module, 'objects', vY). > > generally setattr are done on SomeInstance which nicely returns None -> > SomeImpossibleValue -> the annotator is happy. > However, modules appear to be instances of SomeObject This is, already, your problem: modules are not supported by RPython (anything that ends up as SomeObject() means translation is not going to work). It's a bit peculiar I guess that the module gets examined here, though I can see why it happens. I think if you write objtable.objects.extend(...) you'll be happier. > on which setattr > returns a SomeObject -> type of vX gets broken. If anything, this should break even more noisily. > (and the bug received is not very obvious since it says that the > original type was (none)...) I can believe this part :/ Cheers, mwh From arigo at tunes.org Mon Mar 10 22:24:33 2008 From: arigo at tunes.org (Armin Rigo) Date: Mon, 10 Mar 2008 22:24:33 +0100 Subject: [pypy-dev] SPy (almost) works in the JVM In-Reply-To: References: Message-ID: <20080310212433.GA26040@code0.codespeak.net> Hi Niko, On Sat, Mar 08, 2008 at 03:07:02PM +0100, Niko Matsakis wrote: > the number of hash marks ("#") that are output differs in the JVM and > CLI. That's fine: the Smalltalk code in mini.image is a benchmark that runs until some total amount of time is elapsed, so the number of iterations (and #'s) varies according to the performance. A bientot, Armin From arigo at tunes.org Mon Mar 10 22:34:39 2008 From: arigo at tunes.org (Armin Rigo) Date: Mon, 10 Mar 2008 22:34:39 +0100 Subject: [pypy-dev] module SomeObject setattr. In-Reply-To: <20080310005326.teyya1pbwkc4g8g4@www.iam.unibe.ch> References: <20080310005326.teyya1pbwkc4g8g4@www.iam.unibe.ch> Message-ID: <20080310213439.GB26040@code0.codespeak.net> Hi Toon, On Mon, Mar 10, 2008 at 12:53:26AM +0100, Toon Verwaest wrote: > > objects = [] > > > objtable.objects += [objofspecifictype] You cannot mutate global lists in RPython code. (It's fine to do it outside the RPython-compiled function, of course.) If you need global state it should be put on a prebuilt global instance of a class that you defined. Note btw that the Smalltalk interpreter in PyPy should probably be modified to have a 'space' object passed around; the 'space' would play precisely the role of the global state. That's far cleaner than what we came up with during the Bern sprint, which is to patch module-global objects from various places. For example, all the globals in objspace.py should go on such a 'space', and the 'space' would be populated either by the image loader or manually for smaller tests. A bientot, Armin. From arigo at tunes.org Thu Mar 13 09:39:32 2008 From: arigo at tunes.org (Armin Rigo) Date: Thu, 13 Mar 2008 09:39:32 +0100 Subject: [pypy-dev] Next sprints Message-ID: <20080313083931.GA8571@code0.codespeak.net> Hi all, This e-mail is about starting the discussion for ideas and plans about the next sprints. What we have planned at the moment: * The next PyPy sprint is going to be a small one at PyCon (http://us.pycon.org/2008/sprints/projects/#pypy). * In Leysin, beginning of April, will probably be held a "Paper writing" sprint. Confirmation and more details should come soon (from Michael Leuschel and Carl Friedrich). Another idea I now about is a follow-up Smalltalk-in-RPython (SPy) sprint (nothing concrete though). It seems that we could starting planning for a regular PyPy development sprint soon. I'm never tired of inviting people to Leysin but I guess we could pick another location now (additionally, there are many places where Spring is a nice season, but Leysin is not one of them). A bientot, Armin From fijal at genesilico.pl Fri Mar 14 01:39:07 2008 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 14 Mar 2008 01:39:07 +0100 Subject: [pypy-dev] Next sprints In-Reply-To: <20080313083931.GA8571@code0.codespeak.net> References: <20080313083931.GA8571@code0.codespeak.net> Message-ID: <47D9C92B.5090407@genesilico.pl> Armin Rigo wrote: > Hi all, > > This e-mail is about starting the discussion for ideas and plans about > the next sprints. > > What we have planned at the moment: > > * The next PyPy sprint is going to be a small one at PyCon > (http://us.pycon.org/2008/sprints/projects/#pypy). > > * In Leysin, beginning of April, will probably be held a "Paper writing" > sprint. Confirmation and more details should come soon (from Michael > Leuschel and Carl Friedrich). > > Another idea I now about is a follow-up Smalltalk-in-RPython (SPy) > sprint (nothing concrete though). > > It seems that we could starting planning for a regular PyPy development > sprint soon. I'm never tired of inviting people to Leysin but I guess > we could pick another location now (additionally, there are many places > where Spring is a nice season, but Leysin is not one of them). > I've got an idea of organizing sprint in Poland. Ideal would be summer holiday (easier to organize a room on any uni). I can always organize something in Warsaw, but I think I'll look for different places (next to my climbing place sounds like a perfect hit). Cheers, fijal :. From niko at alum.mit.edu Fri Mar 14 18:41:55 2008 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 14 Mar 2008 18:41:55 +0100 Subject: [pypy-dev] summer of code 2008 In-Reply-To: References: Message-ID: <9AD5C127-5A97-4D9D-9012-FFABFDA97B70@alum.mit.edu> > I have an idea, which I would like to hack on (and already talked a > little about it with Armin). > But I sill am not sure if it makes much sense. I'm not sure about the technical details, but it sounds like a great idea. I think PyPy could benefit from more projects that explore parallelism. Niko From cfbolz at gmx.de Mon Mar 17 17:23:55 2008 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 17 Mar 2008 17:23:55 +0100 Subject: [pypy-dev] Summer of Code Message-ID: <47DE9B1B.3070104@gmx.de> Hi all, there was some discussion about possible Summer of Code topics on the #pypy channel today. We had several project ideas: - work on the JIT assembler backends. There are several possible projects here, like writing a much simpler i386 backend and adding float support to that; or writing a x64 backend; or writing a new i386 backend that uses the more modern bits of the processor for arithmetic (like SSE and friends). - support ctypes on more backends. right now ctypes is supported only when compiling PyPy to C. A nice project would be to support it when compiling to .NET. That's not too hard, the only thing needed is to port a small module that does the actual invocation of external libraries (a related project would be to port this module to Jython or IronPython to get support for ctypes there). - support some of the more recent features of CPython. A nice project would be to support all of the remaining CPython 2.5 features and port over the changes to the standard library (which includes re-writing some of the C-coded modules in RPython or pure Python). Another possibility would be to even start looking into the 2.6 features. - Anto proposed to make the javascript backendopt more useful by turning it into something more frameworkish. I am sceptical of the viability of the task, it would need a very clever student and probably a lot of work too. What do you all think of these ideas? Are there other ideas around? I know that Jakub posted something a while ago (haven't looked in detail yet, though). In my opinion we should try to avoid "yet another incomplete interpreter implentation" for this year. The timeplan is to collect some more ideas, then write a better description of them and make a blog post about it (say around Thursday). Sounds like a plan? Cheers, Carl Friedrich From cfbolz at gmx.de Mon Mar 17 17:35:56 2008 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 17 Mar 2008 17:35:56 +0100 Subject: [pypy-dev] Summer of Code In-Reply-To: <47DE9B1B.3070104@gmx.de> References: <47DE9B1B.3070104@gmx.de> Message-ID: <47DE9DEC.1000007@gmx.de> Carl Friedrich Bolz wrote: > - Anto proposed to make the javascript backendopt more useful by ^ should be "backend", From anto.cuni at gmail.com Mon Mar 17 21:31:01 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 17 Mar 2008 21:31:01 +0100 Subject: [pypy-dev] Summer of Code In-Reply-To: <47DE9B1B.3070104@gmx.de> References: <47DE9B1B.3070104@gmx.de> Message-ID: <47DED505.6030303@gmail.com> Carl Friedrich Bolz wrote: > What do you all think of these ideas? Are there other ideas around? maybe another possible task could be to port an existing external library to pypy, either by writing a mixed module or by using ctypes; possible choices are pygtk, postgresql/mysql DB API, pygame, etc. I don't know whether they are small enough to fit into SoC, though. ciao Anto From tjreedy at udel.edu Mon Mar 17 23:15:55 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 17 Mar 2008 18:15:55 -0400 Subject: [pypy-dev] Summer of Code References: <47DE9B1B.3070104@gmx.de> Message-ID: "Carl Friedrich Bolz" wrote in message news:47DE9B1B.3070104 at gmx.de... || Another possibility would be to even start looking into the 2.6 | features. As near as I can tell, 2.6 is pretty much the union of 2.5 and 3.0. Most of the new features that do not change old code have been backported. Many (most?) of the changes that do will be available as future imports. So a feature-complete 3.0 might be easier than a feature-complete 2.6. tjr From santagada at gmail.com Mon Mar 17 23:30:13 2008 From: santagada at gmail.com (Leonardo Santagada) Date: Mon, 17 Mar 2008 19:30:13 -0300 Subject: [pypy-dev] Summer of Code In-Reply-To: <47DE9B1B.3070104@gmx.de> References: <47DE9B1B.3070104@gmx.de> Message-ID: <0833D64F-B872-43EA-8610-518D9C70E708@gmail.com> On 17/03/2008, at 13:23, Carl Friedrich Bolz wrote: > What do you all think of these ideas? Are there other ideas around? I > know that Jakub posted something a while ago (haven't looked in detail > yet, though). In my opinion we should try to avoid "yet another > incomplete interpreter implentation" for this year. - Threads using the new gc seems pretty important - Numeric on pypy - the scientific comunity could use pypy because they don't need many extensions, mostly scipy wich numeric is the center - Porting ZODB to pypy - this might show a lot of bugs of pypy as it is a really complex extension. []'s -- Leonardo Santagada From stephan.diehl at gmx.net Tue Mar 18 08:23:39 2008 From: stephan.diehl at gmx.net (Stephan Diehl) Date: Tue, 18 Mar 2008 08:23:39 +0100 Subject: [pypy-dev] Summer of Code In-Reply-To: <47DE9B1B.3070104@gmx.de> References: <47DE9B1B.3070104@gmx.de> Message-ID: <200803180823.39315.stephan.diehl@gmx.net> Am Montag, 17. M?rz 2008 17:23:55 schrieb Carl Friedrich Bolz: [...] > > What do you all think of these ideas? Are there other ideas around? I > know that Jakub posted something a while ago (haven't looked in detail > yet, though). In my opinion we should try to avoid "yet another > incomplete interpreter implentation" for this year. > Maybe Jakub could be persuaded to implement his ideas as a python extension. Just my 2c Stephan From cfbolz at gmx.de Tue Mar 18 10:53:46 2008 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 18 Mar 2008 10:53:46 +0100 Subject: [pypy-dev] Summer of Code In-Reply-To: <0833D64F-B872-43EA-8610-518D9C70E708@gmail.com> References: <47DE9B1B.3070104@gmx.de> <0833D64F-B872-43EA-8610-518D9C70E708@gmail.com> Message-ID: <47DF912A.7070501@gmx.de> Leonardo Santagada wrote: > On 17/03/2008, at 13:23, Carl Friedrich Bolz wrote: >> What do you all think of these ideas? Are there other ideas around? I >> know that Jakub posted something a while ago (haven't looked in detail >> yet, though). In my opinion we should try to avoid "yet another >> incomplete interpreter implentation" for this year. > > > - Threads using the new gc seems pretty important That's true, but I fear that this is a very hard (probably too hard) task. > - Numeric on pypy - the scientific comunity could use pypy because > they don't need many extensions, mostly scipy wich numeric is the center > - Porting ZODB to pypy - this might show a lot of bugs of pypy as it > is a really complex extension. Both of these are potentially very annoying. Either you write a PyPy-specific extension module (using rffi), then you have tons of fun because we don't have separate compilation yet. Or you do this with ctypes, which probably has way too much overhead for computation-bound applications, especially with our slow implementation. I guess rewriting big projects in ctypes should only be done for projects where it seems likely that the original authors of the project will later care for the ctypes rewrite. Otherwise you get the effect that now happens for pygame: the ctypes rewrite of it is more or less abandoned. Cheers, Carl Friedrich From jgustak at gmail.com Tue Mar 18 15:34:05 2008 From: jgustak at gmail.com (Jakub Gustak) Date: Tue, 18 Mar 2008 15:34:05 +0100 Subject: [pypy-dev] Summer of Code In-Reply-To: <47DE9B1B.3070104@gmx.de> References: <47DE9B1B.3070104@gmx.de> Message-ID: > What do you all think of these ideas? Are there other ideas around? I > know that Jakub posted something a while ago (haven't looked in detail > yet, though). In my opinion we should try to avoid "yet another > incomplete interpreter implentation" for this year. I fully agree. Still, what I proposed was not attempt to create another one, but keep existing one alive. It is bothering me, that scheme interpreter is incomplete, but the problem is, i could not find a use case for it (except of Thousand Parsecs internal scripting language - if none other - faster - scheme implementation available). So if PyPy is such a nice platform to experiment, let's do it, and play with different approaches to implement parallel paradigms, or whatsoever. There is no need for yet another scheme interpreter (even complete) if it doesn't have any interesting features. That's my 3 cents for now. Cheers, Jakub Gustak From paul.degrandis at gmail.com Tue Mar 18 15:57:00 2008 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Tue, 18 Mar 2008 10:57:00 -0400 Subject: [pypy-dev] Summer of Code In-Reply-To: <9c0bb8a00803180756i5988842fyc3d5e18d806bdba3@mail.gmail.com> References: <47DE9B1B.3070104@gmx.de> <9c0bb8a00803180756i5988842fyc3d5e18d806bdba3@mail.gmail.com> Message-ID: <9c0bb8a00803180757u2e35d356t76131f0e7f8a7c8f@mail.gmail.com> I agree that new approaches to concurrency would be cool. Possible SoCers might start by looking at PARELY (an actor model impl for python that runs on PyPy as is). http://osl.cs.uiuc.edu/parley/ Regards, Paul On 3/18/08, Jakub Gustak wrote: > > What do you all think of these ideas? Are there other ideas around? I > > know that Jakub posted something a while ago (haven't looked in detail > > yet, though). In my opinion we should try to avoid "yet another > > incomplete interpreter implentation" for this year. > > > I fully agree. > > Still, what I proposed was not attempt to create another one, but keep > existing one alive. > It is bothering me, that scheme interpreter is incomplete, but the > problem is, i could not > find a use case for it (except of Thousand Parsecs internal scripting > language - if none > other - faster - scheme implementation available). > > So if PyPy is such a nice platform to experiment, let's do it, and > play with different > approaches to implement parallel paradigms, or whatsoever. There is no > need for yet another > scheme interpreter (even complete) if it doesn't have any interesting features. > That's my 3 cents for now. > > Cheers, > > Jakub Gustak > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From arigo at tunes.org Tue Mar 18 19:45:06 2008 From: arigo at tunes.org (Armin Rigo) Date: Tue, 18 Mar 2008 19:45:06 +0100 Subject: [pypy-dev] Summer of Code In-Reply-To: <47DF912A.7070501@gmx.de> References: <47DE9B1B.3070104@gmx.de> <0833D64F-B872-43EA-8610-518D9C70E708@gmail.com> <47DF912A.7070501@gmx.de> Message-ID: <20080318184506.GA29606@code0.codespeak.net> Hi Carl, On Tue, Mar 18, 2008 at 10:53:46AM +0100, Carl Friedrich Bolz wrote: > > - Threads using the new gc seems pretty important > > That's true, but I fear that this is a very hard (probably too hard) > task. No, the basic task is only to ensure that threads and our new GCs can be used in the same pypy-c. This doesn't mean that the GCs should be multithreaded or even thread-safe, if we take care of only allocating objects when the GIL is held (Global Interpreter Lock). A fully multithreaded GC is step two. It would be good for RPython programs that are more freely multithreaded, like Alexander's attempt to just remove the GIL from pypy-c and not care about crashes (using explicit locks at application-level to prevent them). Getting there is more work indeed. Any student with JikesRVM MMTk experience around? :-) A bientot, Armin. From anto.cuni at gmail.com Sun Mar 23 11:01:54 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sun, 23 Mar 2008 11:01:54 +0100 Subject: [pypy-dev] Problems with modified socket.py In-Reply-To: <6815022a0803221535k2b186650l5c9a77f07d6f9770@mail.gmail.com> References: <6815022a0803221535k2b186650l5c9a77f07d6f9770@mail.gmail.com> Message-ID: <47E62A92.3020606@gmail.com> Leandro Lameiro wrote: > Hi Antonio. > > My name is Leandro Lameiro and I've been a long time observer of PyPy. > This weekend I tried to see where I could contribute to PyPy, so I > decided to try and run some apps and see what is missing. Hi Leandro. Thank you for your interest in PyPy; every contribution is welcome, either patches or bug report! I'm CCing pypy-dev, so that other developers can read it as well. > The first thing I tried to run was ez_setup.py ( > http://peak.telecommunity.com/dist/ez_setup.py ), a simple script that > downloads and installs setuptools. It is a really short script but it > uses various modules such as md5, socket, urllib, os etc. > > After translating PyPy (with allworkingmodules and socket switches) I > found that ez_setup.py will raise and exception in PyPy but not in > CPython (tried with 2.4 and 2.5). > > Here is the traceback: > > (virtualenv)lameiro at liria:~/projetos/ez_setup$ python ez_setup.py > Downloading > http://pypi.python.org/packages/2.4/s/setuptools/setuptools-0.6c8-py2.4.egg > Traceback (most recent call last): > File "?", line 34, in run_toplevel > File "ez_setup.py", line 267, in > main(sys.argv[1:]) > File "ez_setup.py", line 204, in main > os.unlink(egg) > File "ez_setup.py", line 198, in main > egg = download_setuptools(version, delay=0) > File "ez_setup.py", line 152, in download_setuptools > if src: src.close() > File "/home/lameiro/projetos/pypy-dist/lib-python/2.4.1/urllib.py", > line 804, in close > if self.fp: self.fp.close() > File > "/home/lameiro/projetos/pypy-dist/lib-python/modified-2.4.1/socket.py", > line 242, in close > s._drop() > AttributeError: 'HTTPResponse' object has no attribute '_drop' > (virtualenv)lameiro at liria:~/projetos/ez_setup$ > > After investigating a little, I found that you modified socket.py and > introduced this _drop call and also defined it in socket._closedsocket > class (an empty method), but that doesn't seem to be enough since other > types are going there (in this case HTTPResponse, but maybe others too). indeed, you are right; the relevant _drop method is defined in pypy-dist/pypy/module/_socket/interp_socket.py (it's called _drop_w), but I guess we should take care of cases like this in which the object doesn't provide a _drop method. > The revision in which this modification was introduced is > https://codespeak.net/viewvc/pypy/dist/lib-python/modified-2.4.1/socket.py?r1=16842&r2=34429 > > , and I suppose it was you because the commiter login is "ac". :) sorry, your guess is wrong :-). My login name is "antocuni", "ac" stands for Anders Chrigstr?m. That's also why I don't know much about this and I'm CCing pypy-dev :-) > Anyway, thanks for the great work and I hope the next time I can > contribute a patch instead of a bug report. thank to you again for the help! Feel free to come to #pypy on freenode if you want to talk with us by IRC. ciao, Anto From jgustak at gmail.com Wed Mar 26 15:04:27 2008 From: jgustak at gmail.com (Jakub Gustak) Date: Wed, 26 Mar 2008 15:04:27 +0100 Subject: [pypy-dev] summer of code 2008 In-Reply-To: References: <9AD5C127-5A97-4D9D-9012-FFABFDA97B70@alum.mit.edu> Message-ID: > I'm not sure about the technical details, but it sounds like a grea > idea. I think PyPy could benefit from more projects that explore > parallelism. Still. No sign of PyPy at the PSF ideas page. Is there any chance, PyPy will participate? __ Jakub Gustak From fijal at genesilico.pl Fri Mar 28 06:01:50 2008 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 28 Mar 2008 06:01:50 +0100 Subject: [pypy-dev] enchancing flow objspace Message-ID: <47EC7BBE.30400@genesilico.pl> what about making flow objspace understand xxx and XXX as global variables that always raise XxxError() instead of exploding? would simplify translation greatly. :. From cfbolz at gmx.de Fri Mar 28 10:32:55 2008 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 28 Mar 2008 10:32:55 +0100 Subject: [pypy-dev] summer of code 2008 In-Reply-To: References: <9AD5C127-5A97-4D9D-9012-FFABFDA97B70@alum.mit.edu> Message-ID: <47ECBB47.3040307@gmx.de> Hi Jakub, Jakub Gustak wrote: >> I'm not sure about the technical details, but it sounds like a grea >> idea. I think PyPy could benefit from more projects that explore >> parallelism. > > Still. No sign of PyPy at the PSF ideas page. > Is there any chance, PyPy will participate? Sorry, due to some extreme disorganization we haven't done much for SoC this year. However, if you have a good proposal it seems likely that one of us will mentor it, if you register. We also updated the project ideas page a bit: http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html We should probably put a link to that to the PSF wiki page. Cheers, Carl Friedrich From cfbolz at gmx.de Fri Mar 28 10:42:01 2008 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 28 Mar 2008 10:42:01 +0100 Subject: [pypy-dev] enchancing flow objspace In-Reply-To: <47EC7BBE.30400@genesilico.pl> References: <47EC7BBE.30400@genesilico.pl> Message-ID: <47ECBD69.90304@gmx.de> Maciek Fijalkowski wrote: > what about making flow objspace understand xxx and XXX as global > variables that always raise XxxError() instead of exploding? would > simplify translation greatly. weeeeeell. That sounds like an extreme hack to me. Maybe we should do something else, like 'assert 0, "XXX"' instead of just putting XXXs everywhere. Cheers, Carl Friedrich From anto.cuni at gmail.com Fri Mar 28 10:53:58 2008 From: anto.cuni at gmail.com (Antonio Cuni) Date: Fri, 28 Mar 2008 10:53:58 +0100 Subject: [pypy-dev] enchancing flow objspace In-Reply-To: <47ECBD69.90304@gmx.de> References: <47EC7BBE.30400@genesilico.pl> <47ECBD69.90304@gmx.de> Message-ID: <47ECC036.8000207@gmail.com> Carl Friedrich Bolz wrote: > weeeeeell. That sounds like an extreme hack to me. Maybe we should do > something else, like 'assert 0, "XXX"' instead of just putting XXXs > everywhere. +1 From grobinson at goombah.com Fri Mar 28 15:33:49 2008 From: grobinson at goombah.com (Gary Robinson) Date: Fri, 28 Mar 2008 10:33:49 -0400 Subject: [pypy-dev] JIT SoC Message-ID: <20080328103349439579.a77430c3@goombah.com> I saw the suggestion "A good project would be to give the 386 backend a good refactoring, simplifying it, then add support for missing features like floating-point arithmetic." on the list of PyPy independent project suggestions. I'm wondering two things: 1) Is it realistically possible that after the SoC, if that work was taken on by someone, PyPy would be usable in an environment where high-speed floating-point calcs were needed? (The environment I have in mind wouldn't be putting much other stress on python -- it doesn't need a GUI, etc.) It sounds to me like it's far too big a project, but I don't know the existing code at all so I don't want to assume -- it would be great if it could be done. 2) I understand Google is suppling $5000 per project ($4500 for the student). Is there any reason an outside company can't throw a little extra money into the pot for a particular task to sweeten the motivation for that task to be done in the SoC? -- Gary Robinson CTO Emergent Music, LLC grobinson at goombah.com 207-942-3463 Company: http://www.goombah.com Blog: http://www.garyrobinson.net From cfbolz at gmx.de Fri Mar 28 15:42:53 2008 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 28 Mar 2008 15:42:53 +0100 Subject: [pypy-dev] JIT SoC In-Reply-To: <20080328103349439579.a77430c3@goombah.com> References: <20080328103349439579.a77430c3@goombah.com> Message-ID: <47ED03ED.7060408@gmx.de> Gary Robinson wrote: > I saw the suggestion "A good project would be to give the 386 backend > a good refactoring, simplifying it, then add support for missing > features like floating-point arithmetic." on the list of PyPy > independent project suggestions. > > I'm wondering two things: > > 1) Is it realistically possible that after the SoC, if that work was > taken on by someone, PyPy would be usable in an environment where > high-speed floating-point calcs were needed? (The environment I have > in mind wouldn't be putting much other stress on python -- it doesn't > need a GUI, etc.) It sounds to me like it's far too big a project, > but I don't know the existing code at all so I don't want to assume > -- it would be great if it could be done. That really depends. In the mid-term this should be possible, and one of the things missing is indeed a better assembler backend (since right now we have no float support at all). Note however that PyPy doesn't support Numeric Python, so depending what you want to do this might be a problem. > 2) I understand Google is suppling $5000 per project ($4500 for the > student). Is there any reason an outside company can't throw a little > extra money into the pot for a particular task to sweeten the > motivation for that task to be done in the SoC? I guess there is no reason, apart from the fact that it sounds a bit unfair to other students participating in SoC. What I could imagine is having a sprint during the SoC-period and asking that company to pay for the travel of the student or something similar. If you are concretely interested, you might want to take it off-list and discuss with the caretaker group: pypy-ct at codespeak.net Cheers, Carl Friedrich From lac at openend.se Fri Mar 28 17:09:14 2008 From: lac at openend.se (Laura Creighton) Date: Fri, 28 Mar 2008 17:09:14 +0100 Subject: [pypy-dev] JIT SoC In-Reply-To: Message from Carl Friedrich Bolz of "Fri, 28 Mar 2008 15:42:53 +0100." <47ED03ED.7060408@gmx.de> References: <20080328103349439579.a77430c3@goombah.com> <47ED03ED.7060408@gmx.de> Message-ID: <200803281609.m2SG9Er7009372@theraft.openend.se> In a message of Fri, 28 Mar 2008 15:42:53 +0100, Carl Friedrich Bolz writes: >Gary Robinson wrote: >> 2) I understand Google is suppling $5000 per project ($4500 for the >> student). Is there any reason an outside company can't throw a little >> extra money into the pot for a particular task to sweeten the >> motivation for that task to be done in the SoC? Another thing to note -- it is possible to fund the PyPy project directly. If the idea of paying the people who are already working on the project -- but aren't students -- to do things you would like done has appeal, we can probably work something out. Laura Creighton From brunogola at gmail.com Sat Mar 29 04:30:54 2008 From: brunogola at gmail.com (Bruno Gola) Date: Sat, 29 Mar 2008 00:30:54 -0300 Subject: [pypy-dev] PyPy GSoC Application: Supporting Python 2.5 features in PyPy Message-ID: Hi, I'm a under-grad student (3th year) from "Centro Universit?rio SENAC" from S?o Palo, Brazil. I'm very interested in the PyPy project and since last year I have been planning to get involved. Well, this plans has transformed into my graduation project that I'll start working next semester. My graduation project idea is to study two different implementations (CPython (C/Static/lower-level) and Pypy (Python/Dynamic/higher-level)) of a programming language (Python) and compare the difficult to hack both. I intend to study both and suggest optimizations to the implementations and show that it is easier to modify the higher-level implementation. Well, I told you this because my GSoC application is all about the Pypy interpreter (or the Pypy implementation of Python ) ;). I wrote some ideas to the project, so I ask if anyone could review it. PROPOSAL: Support new features of Python 2.5 in PyPy ========================================== * Motivation and goal Pypy's interpreter currently supports some of the "new" Python features introduced in Python 2.5. Also, the Python 2.5 changes to standard library have not been ported yet. This proposal goal is to bring 2.5 features and changes to Pypy interpreter. * Features Some features are already supported (for example __index__). I'm proposing to make Pypy support all the remaining features from 2.5. There are changes made to the python standard library[1] that haven't been ported yet because of the lack of 2.5 features, so I'm proposing to port this changes (some major modules added are sqlite3, ctypes and ElementTree) too. So, what I'm proposing: * Support all Python 2.5 features * "Sync" PyPy's standard library with CPython [1] http://docs.python.org/whatsnew/modules.html * Coding I started looking into the list of what is new in Python 2.5 to see if any new feature would need a special attention. My plans are to start coding the changes to the language (not to the stdlib) because I think it doesn't make much sense to implement the stdlib without full language support and it seems that porting the stdlib will not be much trouble (not as much as supporting some features :-)). I intend to start coding some simple feature (like PEP-342 that seems easy to support) so I can study the PyPy interpreter better. Then I'll code the other features (PEPs 314[is this really needed in Pypy?]], 328, 342, 343[or what is missing] and 352). [am I missing any other feature?]. With all features supported (and tested :-)) I'll code the stdlib changes. At this point I think I'll be familiar with the interpreter code so I pretend to port first the sqlite3 module. I like follow TDD (Test-driven development) so tests will not be a problem (I mean, it will be part of the final code, of course :)). PROPOSAL END. Thanks, -- Bruno Fialho Marques Gola bgola` @ irc.freenode.org http://www.brunogola.com.br Cel: (11) 9294-5883 From brunogola at gmail.com Sat Mar 29 04:33:09 2008 From: brunogola at gmail.com (Bruno Gola) Date: Sat, 29 Mar 2008 00:33:09 -0300 Subject: [pypy-dev] PyPy GSoC Application: Supporting Python 2.5 features in PyPy In-Reply-To: References: Message-ID: ta ai On Sat, Mar 29, 2008 at 12:30 AM, Bruno Gola wrote: > Hi, > > I'm a under-grad student (3th year) from "Centro Universit?rio SENAC" > from S?o Palo, Brazil. I'm very interested in the PyPy project and > since last year I have been planning to get involved. Well, this plans > has transformed into my graduation project that I'll start working > next semester. My graduation project idea is to study two different > implementations (CPython (C/Static/lower-level) and Pypy > (Python/Dynamic/higher-level)) of a programming language (Python) and > compare the difficult to hack both. I intend to study both and suggest > optimizations to the implementations and show that it is easier to > modify the higher-level implementation. > > Well, I told you this because my GSoC application is all about the > Pypy interpreter (or the Pypy implementation of Python ) ;). > > I wrote some ideas to the project, so I ask if anyone could review it. > > > PROPOSAL: > > Support new features of Python 2.5 in PyPy > ========================================== > > * Motivation and goal > > Pypy's interpreter currently supports some of the "new" Python > features introduced in Python 2.5. Also, the Python 2.5 changes to > standard library have not been ported yet. > > This proposal goal is to bring 2.5 features and changes to Pypy interpreter. > > * Features > > Some features are already supported (for example __index__). I'm > proposing to make Pypy support all the remaining features from 2.5. > > There are changes made to the python standard library[1] that haven't > been ported yet because of the lack of 2.5 features, so I'm proposing > to port this changes (some major modules added are sqlite3, ctypes and > ElementTree) too. > > So, what I'm proposing: > * Support all Python 2.5 features > * "Sync" PyPy's standard library with CPython > > [1] http://docs.python.org/whatsnew/modules.html > > * Coding > > I started looking into the list of what is new in Python 2.5 to see > if any new feature would need a special attention. My plans are to > start coding the changes to the language (not to the stdlib) because I > think it doesn't make much sense to implement the stdlib without full > language support and it seems that porting the stdlib will not be much > trouble (not as much as supporting some features :-)). > > I intend to start coding some simple feature (like PEP-342 that seems > easy to support) so I can study the PyPy interpreter better. Then I'll > code the other features (PEPs 314[is this really needed in Pypy?]], > 328, 342, 343[or what is missing] and 352). [am I missing any other > feature?]. > > With all features supported (and tested :-)) I'll code the stdlib > changes. At this point I think I'll be familiar with the interpreter > code so I pretend to port first the sqlite3 module. > > I like follow TDD (Test-driven development) so tests will not be a > problem (I mean, it will be part of the final code, of course :)). > > PROPOSAL END. > > Thanks, > -- > Bruno Fialho Marques Gola > bgola` @ irc.freenode.org > http://www.brunogola.com.br > Cel: (11) 9294-5883 > -- Bruno Fialho Marques Gola http://www.brunogola.com.br Cel: (11) 9294-5883 From lac at openend.se Sat Mar 29 07:48:18 2008 From: lac at openend.se (Laura Creighton) Date: Sat, 29 Mar 2008 07:48:18 +0100 Subject: [pypy-dev] Looks like Macij's talk was a hit with the attendees Message-ID: <200803290648.m2T6mI2H005271@theraft.openend.se> Alas, I still cannot get them to remove my name from the list of presenters. Forward from Python-organisers From: Brian Ray To: pycon-organizers Pycon-Organizers Since we are nearing the 50% participation mark on survey collection, I think it is fair to start analyzing the results. Once the paper forms are hand entered, I am happy to say, we will pass 50% user participation in the survey. This alone, speaks volumes. Here is a link, if you prefer raw data view: OVERVIEW ======== On the highest level, here are some comparisons between the last year data (found here ): - 500+ Surveys were filled out this time, versus 150, last time - There were slightly more first timers this year 60.6% than last year 56% - Overall satisfaction dropped slightly from 3.62/4 to 3.28/4 - Satisfaction with keynotes dropped from 3.28/4 to 2.78/4 - Satisfaction with talks dropped from 3.12/4 to 2.81/4 - Satisfaction with the network dropped sharply from 3.01/4 to 2.19/4 - Satisfaction with the food dropped from 3.0/4 to 2.61/4 - Likelihood of attending next year dropped from 3.4/4 to 3.26/4 - There was an increase of attendance of tutorials from 31.1% to 44.4% The results on preference of Only weekdays, including one weekend days, and including two weekend days, remained about the same. The top 5 talks (including keynotes) were: - Keynote: Guido van Rossum 41.4% 173 - Core Python Containers -- Under the Hood Mr. Raymond D Hettinger 20.1% 84 - Keynote: Brian 'Fitz' Fitzpatrick 18.9% 79 - The State of Django Adrian Holovaty 17.7% 74 - Keynote: Van Lindberg 16.3% 68 The top 10 talks not including keynotes: - Core Python Containers -- Under the Hood Mr. Raymond D Hettinger 20.1% 84 - The State of Django Adrian Holovaty 17.7% 74 - Sights and sounds with pyglet Mr. Alex Holkner 14.8% 62 - The State of PyPy Maciej Fijalkowski (merlinux GmbH) ; Ms. Laura A Creighton (Open End AB) 13.6% 57 - SQLAlchemy 0.4 and Beyond Mike Bayer 13.2% 55 - Using PyGame and PySight to Create an Interactive Halloween Activity Mr. John Harrison (Insight Industries) 12.9% 54 - Consuming HTML Ian Bicking (The Open Planning Project) 11.2% 47 - nose: testing for the lazy coder Jason Pellerin (Leapfrog Online) 10.5% 44 - IronPython: The Road Ahead Mr. Jim Hugunin (Microsoft) 10.5% 44 - Tahoe: A Robust Distributed Secure Filesystem Brian Warner 10.3% 43 ------- End of Forwarded Message From lac at openend.se Sat Mar 29 07:49:59 2008 From: lac at openend.se (Laura Creighton) Date: Sat, 29 Mar 2008 07:49:59 +0100 Subject: [pypy-dev] Looks like Macij's talk was a hit with the attendees In-Reply-To: Message from Laura Creighton of "Sat, 29 Mar 2008 07:48:18 +0100." <200803290648.m2T6mI2H005271@theraft.openend.se> References: <200803290648.m2T6mI2H005271@theraft.openend.se> Message-ID: <200803290649.m2T6nx8N005375@theraft.openend.se> And looks like I cannot spell this morning, sorry about that Maciej Laura From 2007b at usenet.alexanderweb.de Sat Mar 29 14:41:09 2008 From: 2007b at usenet.alexanderweb.de (Alexander Schremmer) Date: Sat, 29 Mar 2008 14:41:09 +0100 Subject: [pypy-dev] PyPy GSoC Application: Supporting Python 2.5 features in PyPy References: Message-ID: Bruno Gola wrote: > Pypy's interpreter currently supports some of the "new" Python > features introduced in Python 2.5. Also, the Python 2.5 changes to > standard library have not been ported yet. There is a complete list of missing things here (see Catch up with CPython 2.5/2.6"): http://codespeak.net/pypy/extradoc/planning/roadmap/goal_cpython_replacement.html I guess it would be wise to refer to the tasks in your application. Kind regards, Alexander From fijal at genesilico.pl Mon Mar 31 17:23:52 2008 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 31 Mar 2008 17:23:52 +0200 Subject: [pypy-dev] [pypy-svn] r53194 - pypy/branch/jit-hotpath/pypy/tool In-Reply-To: <20080331085144.9C0EA1684DA@codespeak.net> References: <20080331085144.9C0EA1684DA@codespeak.net> Message-ID: <47F10208.2030500@genesilico.pl> arigo at codespeak.net wrote: > Author: arigo > Date: Mon Mar 31 10:51:44 2008 > New Revision: 53194 > > Modified: > pypy/branch/jit-hotpath/pypy/tool/udir.py > Log: > This logic seems slightly broken - I end up with tons of different > usession names in my /tmp, not just branch names. Anyway I prefer > the old behavior by far, so with this checkin I can set > PYPY_USESSION_BASENAME to a simple '-' and get it back. > > > Modified: pypy/branch/jit-hotpath/pypy/tool/udir.py > ============================================================================== > --- pypy/branch/jit-hotpath/pypy/tool/udir.py (original) > +++ pypy/branch/jit-hotpath/pypy/tool/udir.py Mon Mar 31 10:51:44 2008 > @@ -17,9 +17,11 @@ > else: > return basename.split('/')[-2] > > -try: > - basename = '-' + svn_info(py.path.svnwc(py.magic.autopath().dirpath()).info().url) + '-' > -except: > - basename = '-' > +basename = os.environ.get('PYPY_USESSION_BASENAME') > +if not basename: > + try: > + basename = '-' + svn_info(py.path.svnwc(py.magic.autopath().dirpath()).info().url) + '-' > + except: > + basename = '-' > > udir = local.make_numbered_dir(prefix='usession' + basename, keep=3) > _______________________________________________ > pypy-svn mailing list > pypy-svn at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn > > :. > > That's because it contained tons of bugs and over checkins you got different dirs :-( I hope it's fixed by now :.