From simon at arrowtheory.com Tue Oct 2 20:54:07 2007 From: simon at arrowtheory.com (Simon Burton) Date: Tue, 2 Oct 2007 11:54:07 -0700 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <20070930120617.77D9680F5@code0.codespeak.net> References: <20070930120617.77D9680F5@code0.codespeak.net> Message-ID: <20071002115407.3c293280.simon@arrowtheory.com> Well, I still want to defend this approach... The idea is: * "ctypes" is the API for interfacing with external objects * genrffi constructs rffi objects by introspecting the ctypes objects It has nothing to do with rctypes (although it uses ctypes_platform to find the libraries). I would at least like people to understand what this is, before they put it on a clean-up list. Simon. On Sun, 30 Sep 2007 14:06:17 +0200 (CEST) fijal at codespeak.net wrote: > Author: fijal > Date: Sun Sep 30 14:06:16 2007 > New Revision: 47040 > > Modified: > pypy/dist/pypy/doc/cleanup-todo.txt > Log: > Add rsdl and rcairo, remove errno as it does not use rctypes. > > > Modified: pypy/dist/pypy/doc/cleanup-todo.txt > ============================================================================== > --- pypy/dist/pypy/doc/cleanup-todo.txt (original) > +++ pypy/dist/pypy/doc/cleanup-todo.txt Sun Sep 30 14:06:16 2007 > @@ -37,11 +37,12 @@ > - crypt > - _demo > - _ssl > - - errno > - fcntl > - mmap > - rctime > - readline > - signal > + - rsdl > + - rcairo > > - rewrite or kill the extcompiler > _______________________________________________ > pypy-svn mailing list > pypy-svn at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn From fijal at genesilico.pl Wed Oct 3 13:59:03 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Wed, 03 Oct 2007 13:59:03 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <20071002115407.3c293280.simon@arrowtheory.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> Message-ID: <47038407.5010000@genesilico.pl> Simon Burton wrote: > Well, I still want to defend this approach... > The idea is: > * "ctypes" is the API for interfacing with external objects > * genrffi constructs rffi objects by introspecting the ctypes objects > > It has nothing to do with rctypes (although it uses ctypes_platform > to find the libraries). I would at least like people to understand > what this is, before they put it on a clean-up list. > > Simon. > This is exactly my concern. Because it uses ctypes_platform, it's keeping alive code, which I would like to get rid off. Also, given ll2ctypes working it's now possible to test rffi version on top of cpython, hence I see no point in keeping ctypes version available. Please state your concerns, why this cannot be moved to rffi in source code. Cheers, fijal :. From tismer at stackless.com Wed Oct 3 17:55:12 2007 From: tismer at stackless.com (Christian Tismer) Date: Wed, 03 Oct 2007 17:55:12 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <47038407.5010000@genesilico.pl> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> Message-ID: <4703BB60.60902@stackless.com> Maciek Fijalkowski wrote: > Simon Burton wrote: >> Well, I still want to defend this approach... >> The idea is: >> * "ctypes" is the API for interfacing with external objects >> * genrffi constructs rffi objects by introspecting the ctypes objects >> >> It has nothing to do with rctypes (although it uses ctypes_platform >> to find the libraries). I would at least like people to understand >> what this is, before they put it on a clean-up list. >> >> Simon. >> > This is exactly my concern. Because it uses ctypes_platform, it's > keeping alive code, which I would like to get rid off. Also, given > ll2ctypes working it's now possible to test rffi version on top of > cpython, hence I see no point in keeping ctypes version available. > Please state your concerns, why this cannot be moved to rffi in source code. Hi friends, to what extent has this been discussed? If this change is not commonly approved, then I'm asking you to change it to a proposed addition to the cleanup list, but open for discussion. This is public information, and before things are decided upon, I dislike to see misleading statements, which might turn into truth just by pretending they were true. ceterum censeo carthaginem esse delendam - ly yr's -- 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 simon at arrowtheory.com Wed Oct 3 18:11:10 2007 From: simon at arrowtheory.com (Simon Burton) Date: Wed, 3 Oct 2007 09:11:10 -0700 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <4703BB60.60902@stackless.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> Message-ID: <20071003091110.5b0878da.simon@arrowtheory.com> On Wed, 03 Oct 2007 17:55:12 +0200 Christian Tismer wrote: > > Hi friends, > > to what extent has this been discussed? Maciek and I had a chat on pypy-irc about it: we did not seem to agree entirely. Also, this ctypes-up-front approach was my original suggestion (perhaps badly communicated) at the start of the ep-2007 sprint. I have not had the motivation to fully explore the technical merits of the two approaches. If ll2ctypes turns out to work as advertised, perhaps I will succumb. Simon. From fijal at genesilico.pl Wed Oct 3 18:55:50 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Wed, 03 Oct 2007 18:55:50 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <4703BB60.60902@stackless.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> Message-ID: <4703C996.5090606@genesilico.pl> > Hi friends, > > to what extent has this been discussed? > If this change is not commonly approved, > then I'm asking you to change it to a proposed > addition to the cleanup list, but open for > discussion. > This is public information, and before things > are decided upon, I dislike to see misleading > statements, which might turn into truth just > by pretending they were true. > > ceterum censeo carthaginem esse delendam - ly yr's -- chris > Excuse me, if I sounded unfriendly. As far as I remember concern regarding moving entirely into rffi was about whether ll2ctypes works. At the EP sprint, ll2ctypes was not working to it's full extend, and probably contains bugs till this day. So this is just a next step, as circumstances have changed. Also we agreed, that we should not depend on ctypes if possible, for various reasons, including artificially keeping alive code, which is not used by everything else. Cheers, fijal :. From cfbolz at gmx.de Wed Oct 3 18:56:36 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 3 Oct 2007 18:56:36 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <4703BB60.60902@stackless.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> Message-ID: <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> Hi Christian, 2007/10/3, Christian Tismer : > to what extent has this been discussed? > If this change is not commonly approved, > then I'm asking you to change it to a proposed > addition to the cleanup list, but open for > discussion. > This is public information, and before things > are decided upon, I dislike to see misleading > statements, which might turn into truth just > by pretending they were true. RCTypes is causing problems since quite a while, I think it's not too much to say that it seriously slowed PyPy's progress. Maybe it was a necessary mistake to make to reach the rffi-solution we have now, of which we think that it is a good one. rffi solves many of the problems that rctypes had, and has mostly the same benefits: It's testable on top of CPython, for example. That RCTypes poses a problem is known since a long time. For a while they were considered solvable, but that turned out to be very hard (if not impossible). This was communicated in numerous ways, for example this mail in August: http://codespeak.net/pipermail/pypy-dev/2007q3/003995.html to which nobody replied about the RCTypes issue. Note that I think it is fine to discuss the issue even now. But it is very strange in my opinion to say now that it was never discussed. Cheers, Carl Friedrich From simon at arrowtheory.com Wed Oct 3 19:06:27 2007 From: simon at arrowtheory.com (Simon Burton) Date: Wed, 3 Oct 2007 10:06:27 -0700 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> Message-ID: <20071003100627.092b6a64.simon@arrowtheory.com> On Wed, 3 Oct 2007 18:56:36 +0200 "Carl Friedrich Bolz" wrote: > > to which nobody replied about the RCTypes issue. > > Note that I think it is fine to discuss the issue even now. But it is > very strange in my opinion to say now that it was never discussed. No, I'm not talking about rctypes i'm talking about ctypes. I am fine with rm'ing all rctypes code. I just use a function from rctypes to find a library, i think rffi has such a function now.. Do people realize that genrffi allows ctypes (nothing to do with rctypes) to be used as a front-end to rffi ? Ie. instead of using ctypes (in ll2ctypes) as a backend to rffi. Simon. From arigo at tunes.org Wed Oct 3 20:01:21 2007 From: arigo at tunes.org (Armin Rigo) Date: Wed, 3 Oct 2007 20:01:21 +0200 Subject: [pypy-dev] PyPy progress report Message-ID: <20071003180121.GA13961@code0.codespeak.net> Hi all, A quick note to tell you some new things that PyPy can do since the 1.0 release: more built-in modules, PyPy-on-Java-VMs, and secure sandboxing for Python. In more details: * Threads and weakrefs are now working properly. (There is a GIL - global lock - just like in CPython for now.) (As in the 1.0 release, you can also have stackless & greenlets instead of threads.) * Some missing built-in modules have been written, like zlib. The complete list of known-to-be-working built-in modules is: _codecs, gc, _weakref, array, marshal, errno, math, _sre (regular expressions), operator, symbol, _random, _socket, unicodedata, mmap, fcntl, time, select, crypt, signal, readline (only readline.readline()), termios, zlib, struct, md5, sha Of course, all the standard library of Python 2.4, written in Python, works out of the box. Also, the following modules have a working pure Python implementation in PyPy: binascii, cPickle, cStringIO, cmath, collections, datetime, functional, imp, itertools. * These two facts together mean that pypy-c can now run some very serious programs, like the server for the bub-n-bros game :-) I've also successfully used py.execnet for a while. * Antonio and Niko are doing some very good work on the Java backend. With minor tweaks we can now build a pypy-jvm. FWIW it seems to give better performance than Jython. It's not 100% comparable because pypy-jvm is not thread-aware or thread-safe yet, while Jython gives you free threading; OTOH pypy-jvm doesn't generate Java bytecodes on-the-fly (although it might do so in the future). All in all pypy-jvm is still experimental, but stay tuned :-) * Sandboxing: it is possible to compile a version of pypy-c that runs fully "virtualized", i.e. where an external process controls all input/output. Such a pypy-c is a secure sandbox: it is safe to run any untrusted Python code with it. The Python code cannot see or modify any local file except via interaction with the external process. It is also impossible to do any other I/O or consume more than some amount of RAM or CPU time or real time. This works with no OS support at all - just ANSI C code generated in a careful way. It's the kind of thing you could embed in a browser plug-in, for example (it would be safe even if it wasn't run as a separate process, actually). For comparison, trying to plug CPython into a special virtualizing C library is not only OS-specific, but unsafe, because one of the known ways to segfault CPython could be used by an attacker to trick CPython into issuing malicious system calls directly. The C code generated by PyPy is not segfaultable, as long as our code generators are correct - that's a lower number of lines of code to trust. For the paranoid, in this case we also generate systematic run-time checks against buffer overflows. For more information on this topic please see: http://codespeak.net/pypy/dist/pypy/doc/sandbox.html Thanks, Armin & cfbolz around From paul.degrandis at gmail.com Wed Oct 3 20:34:23 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Wed, 3 Oct 2007 14:34:23 -0400 Subject: [pypy-dev] PyPy progress report In-Reply-To: <20071003180121.GA13961@code0.codespeak.net> References: <20071003180121.GA13961@code0.codespeak.net> Message-ID: <9c0bb8a00710031134x119ae881g923923f3f575b0fa@mail.gmail.com> Good news all around! Thanks for sending this out guys. Paul On 10/3/07, Armin Rigo wrote: > > Hi all, > > A quick note to tell you some new things that PyPy can do since the 1.0 > release: more built-in modules, PyPy-on-Java-VMs, and secure sandboxing > for Python. > > In more details: > > > * Threads and weakrefs are now working properly. (There is a GIL - > global lock - just like in CPython for now.) (As in the 1.0 release, > you can also have stackless & greenlets instead of threads.) > > > * Some missing built-in modules have been written, like zlib. > The complete list of known-to-be-working built-in modules is: > > _codecs, gc, _weakref, array, marshal, errno, > math, _sre (regular expressions), operator, symbol, _random, > _socket, unicodedata, mmap, fcntl, time, select, > crypt, signal, readline (only readline.readline()), > termios, zlib, struct, md5, sha > > Of course, all the standard library of Python 2.4, written in Python, > works out of the box. Also, the following modules have a working pure > Python implementation in PyPy: binascii, cPickle, cStringIO, cmath, > collections, datetime, functional, imp, itertools. > > > * These two facts together mean that pypy-c can now run some very > serious programs, like the server for the bub-n-bros game :-) > I've also successfully used py.execnet for a while. > > > * Antonio and Niko are doing some very good work on the Java backend. > With minor tweaks we can now build a pypy-jvm. FWIW it seems to give > better performance than Jython. It's not 100% comparable because > pypy-jvm is not thread-aware or thread-safe yet, while Jython gives > you free threading; OTOH pypy-jvm doesn't generate Java bytecodes > on-the-fly (although it might do so in the future). All in all > pypy-jvm is still experimental, but stay tuned :-) > > > * Sandboxing: it is possible to compile a version of pypy-c that runs > fully "virtualized", i.e. where an external process controls all > input/output. Such a pypy-c is a secure sandbox: it is safe to run > any untrusted Python code with it. The Python code cannot see or > modify any local file except via interaction with the external > process. It is also impossible to do any other I/O or consume more > than some amount of RAM or CPU time or real time. This works with no > OS support at all - just ANSI C code generated in a careful way. It's > the kind of thing you could embed in a browser plug-in, for example > (it would be safe even if it wasn't run as a separate process, > actually). > > For comparison, trying to plug CPython into a special virtualizing C > library is not only OS-specific, but unsafe, because one of the known > ways to segfault CPython could be used by an attacker to trick CPython > into issuing malicious system calls directly. The C code generated by > PyPy is not segfaultable, as long as our code generators are correct - > that's a lower number of lines of code to trust. For the paranoid, in > this case we also generate systematic run-time checks against buffer > overflows. > > For more information on this topic please see: > http://codespeak.net/pypy/dist/pypy/doc/sandbox.html > > > Thanks, > > Armin & cfbolz around > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tismer at stackless.com Thu Oct 4 03:20:51 2007 From: tismer at stackless.com (Christian Tismer) Date: Thu, 04 Oct 2007 03:20:51 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> Message-ID: <47043FF3.8030803@stackless.com> Hi Carl, Carl Friedrich Bolz wrote: > Hi Christian, > > 2007/10/3, Christian Tismer : >> to what extent has this been discussed? >> If this change is not commonly approved, >> then I'm asking you to change it to a proposed >> addition to the cleanup list, but open for >> discussion. >> This is public information, and before things >> are decided upon, I dislike to see misleading >> statements, which might turn into truth just >> by pretending they were true. > > RCTypes is causing problems since quite a while, I think it's not too > much to say that it seriously slowed PyPy's progress. Maybe it was a > necessary mistake to make to reach the rffi-solution we have now, of > which we think that it is a good one. rffi solves many of the problems > that rctypes had, and has mostly the same benefits: It's testable on > top of CPython, for example. I do know every bit of that. This is not about the details. It is about how we handle a concern/veto from a valuated member. And this annoys me, the way how we handle it. > That RCTypes poses a problem is known since a long time. For a while > they were considered solvable, but that turned out to be very hard (if > not impossible). This was communicated in numerous ways, for example > this mail in August: > > http://codespeak.net/pipermail/pypy-dev/2007q3/003995.html > > to which nobody replied about the RCTypes issue. > > Note that I think it is fine to discuss the issue even now. But it is > very strange in my opinion to say now that it was never discussed. I think I just asked whether it was discussed at all. Please refrain from putting things into my mouth that I did not say. And I agree that it is fine to discuss the issue even now. I just think it is very strange if people appear to drive decisions for the whole consortium, when there is a complaint and no common sense in sight. That's why I asked if I missed a discussion and a general agreement, which is very possible. At least as long as I'm considered to belong to this consortium, I will always keep an eye on matters like these. (while this consideration is questionable as well) leaded a works committee for many years -- 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 cfbolz at gmx.de Thu Oct 4 09:11:08 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 4 Oct 2007 09:11:08 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <20071003100627.092b6a64.simon@arrowtheory.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> <20071003100627.092b6a64.simon@arrowtheory.com> Message-ID: <348899050710040011j43db20d9rc90e420f4bb1b3c8@mail.gmail.com> Hi Simon, 2007/10/3, Simon Burton : > On Wed, 3 Oct 2007 18:56:36 +0200 > "Carl Friedrich Bolz" wrote: > > > > > to which nobody replied about the RCTypes issue. > > > > Note that I think it is fine to discuss the issue even now. But it is > > very strange in my opinion to say now that it was never discussed. > > No, I'm not talking about rctypes i'm talking about ctypes. > I am fine with rm'ing all rctypes code. > I just use a function from rctypes to find a library, i think > rffi has such a function now.. Then it should be possible to use the function that rffi provides? > Do people realize that genrffi allows ctypes (nothing to do with rctypes) > to be used as a front-end to rffi ? Ie. instead of using ctypes > (in ll2ctypes) as a backend to rffi. No, I was not aware of this. There never was neither a mail to this list about this, nor a sprint report about the Vilnius sprint, so how should people that didn't go there know? Cheers, Carl Friedrich From cfbolz at gmx.de Thu Oct 4 09:26:41 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 4 Oct 2007 09:26:41 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <47043FF3.8030803@stackless.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> <47043FF3.8030803@stackless.com> Message-ID: <348899050710040026o5923991cp6a4943fa3533ca6@mail.gmail.com> Hi Christian, 2007/10/4, Christian Tismer : > Carl Friedrich Bolz wrote: > > RCTypes is causing problems since quite a while, I think it's not too > > much to say that it seriously slowed PyPy's progress. Maybe it was a > > necessary mistake to make to reach the rffi-solution we have now, of > > which we think that it is a good one. rffi solves many of the problems > > that rctypes had, and has mostly the same benefits: It's testable on > > top of CPython, for example. > > I do know every bit of that. This is not about the > details. It is about how we handle a concern/veto > from a valuated member. And this annoys me, the way how > we handle it. I see. Well, I have to say that I was (until Simon's mail) completely unaware of what genrffi does. And judging from what he is saying it is not a "concern/veto" against rctypes at all, so I don't know what the problem here is. Besides the "concern/veto" was to my knowledge never voiced on the mailing list, so how could we have handled it? > > That RCTypes poses a problem is known since a long time. For a while > > they were considered solvable, but that turned out to be very hard (if > > not impossible). This was communicated in numerous ways, for example > > this mail in August: > > > > http://codespeak.net/pipermail/pypy-dev/2007q3/003995.html > > > > to which nobody replied about the RCTypes issue. > > > > Note that I think it is fine to discuss the issue even now. But it is > > very strange in my opinion to say now that it was never discussed. > > I think I just asked whether it was discussed at all. Please refrain > from putting things into my mouth that I did not say. > > And I agree that it is fine to discuss the issue even now. > > I just think it is very strange if people appear to drive > decisions for the whole consortium, when there is a complaint > and no common sense in sight. That's why I asked if I missed > a discussion and a general agreement, which is very possible. Sorry, but the complaint wasn't even visible to me until Simon's mail. I can only react to complaints I know about. Thus I find it strange that you say stuff like "there is no common sense in sight". It's possible that you knew about genrffi longer, but I didn't and I am not sure how I am supposed to have known about it. Cheers, Carl Friedrich From lac at openend.se Thu Oct 4 09:55:25 2007 From: lac at openend.se (Laura Creighton) Date: Thu, 04 Oct 2007 09:55:25 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: Message from "Carl Friedrich Bolz" of "Thu, 04 Oct 2007 09:26:41 +0200." <348899050710040026o5923991cp6a4943fa3533ca6@mail.gmail.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> <47043FF3.8030803@stackless.com> <348899050710040026o5923991cp6a4943fa3533ca6@mail.gmail.com> Message-ID: <200710040755.l947tPor023519@theraft.openend.se> In a message of Thu, 04 Oct 2007 09:26:41 +0200, "Carl Friedrich Bolz" writes: >Hi Christian, >> I just think it is very strange if people appear to drive >> decisions for the whole consortium, when there is a complaint >> and no common sense in sight. That's why I asked if I missed >> a discussion and a general agreement, which is very possible. > >Sorry, but the complaint wasn't even visible to me until Simon's mail. >I can only react to complaints I know about. Thus I find it strange >that you say stuff like "there is no common sense in sight". It's >possible that you knew about genrffi longer, but I didn't and I am not >sure how I am supposed to have known about it. > >Cheers, > >Carl Friedrich I think that here we have a potential problem in that Carl Friedrich is thinking of "common sense" as the English phrase which means roughly 'reasonableness' or 'generally and practically well known', as in 'a common sense belief' -- while all I think Christian was meaning was 'we sure have a whole lot of attempts to make C extensions' -- i.e. no common belief, or sense that one way ought to be the only way to do it. (Or rather, everybody thinks that there ought only to be one way, but we don't have consensus as to what way that one should be.) But I may be misunderstanding totally, of course. I have my own question. I think I know why Miciek wants to get rid of ctypes_platform. I don't know why Simon wants it to stay, and if we can get him what he wants it for some other way. Is there something special about ctypes_platform that I am missing? Laura From tismer at stackless.com Thu Oct 4 14:17:37 2007 From: tismer at stackless.com (Christian Tismer) Date: Thu, 04 Oct 2007 14:17:37 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <348899050710040026o5923991cp6a4943fa3533ca6@mail.gmail.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> <47043FF3.8030803@stackless.com> <348899050710040026o5923991cp6a4943fa3533ca6@mail.gmail.com> Message-ID: <4704D9E1.60905@stackless.com> Carl Friedrich Bolz wrote: > Sorry, but the complaint wasn't even visible to me until Simon's mail. > I can only react to complaints I know about. Thus I find it strange > that you say stuff like "there is no common sense in sight". It's > possible that you knew about genrffi longer, but I didn't and I am not > sure how I am supposed to have known about it. Sorry, I meant "common consent". No, I still have no idea what genrffi exactly does, but I saw two people talking about this revision of the todo list. Not sure if you could follow the original mails, this should clarify things. Should be in the archive. I don't have any opinion myself right now, I just thought something needed attention. And this entry on the todo list was not agreed upon, that's all about it. cheers and greets - 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 simon at arrowtheory.com Thu Oct 4 16:13:30 2007 From: simon at arrowtheory.com (Simon Burton) Date: Thu, 4 Oct 2007 07:13:30 -0700 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <348899050710040011j43db20d9rc90e420f4bb1b3c8@mail.gmail.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> <20071003100627.092b6a64.simon@arrowtheory.com> <348899050710040011j43db20d9rc90e420f4bb1b3c8@mail.gmail.com> Message-ID: <20071004071330.eee69f08.simon@arrowtheory.com> On Thu, 4 Oct 2007 09:11:08 +0200 "Carl Friedrich Bolz" wrote: > Hi Simon, > > 2007/10/3, Simon Burton : ... > > I just use a function from rctypes to find a library, i think > > rffi has such a function now.. > > Then it should be possible to use the function that rffi provides? It's likely. > > > Do people realize that genrffi allows ctypes (nothing to do with rctypes) > > to be used as a front-end to rffi ? Ie. instead of using ctypes > > (in ll2ctypes) as a backend to rffi. > > No, I was not aware of this. There never was neither a mail to this > list about this, nor a sprint report about the Vilnius sprint, so how > should people that didn't go there know? Well, this is what I wrote: http://codespeak.net/pipermail/pypy-dev/2007q3/003920.html Should I have written more ? I did not want to "conclude" anything at that point in time. Simon. From cfbolz at gmx.de Thu Oct 4 23:02:55 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 4 Oct 2007 23:02:55 +0200 Subject: [pypy-dev] [pypy-svn] r47040 - pypy/dist/pypy/doc In-Reply-To: <20071004071330.eee69f08.simon@arrowtheory.com> References: <20070930120617.77D9680F5@code0.codespeak.net> <20071002115407.3c293280.simon@arrowtheory.com> <47038407.5010000@genesilico.pl> <4703BB60.60902@stackless.com> <348899050710030956o2772f772r361ec575e886b2c3@mail.gmail.com> <20071003100627.092b6a64.simon@arrowtheory.com> <348899050710040011j43db20d9rc90e420f4bb1b3c8@mail.gmail.com> <20071004071330.eee69f08.simon@arrowtheory.com> Message-ID: <348899050710041402k549e07f6rf2431445289c3a21@mail.gmail.com> Hi Simon, 2007/10/4, Simon Burton : > On Thu, 4 Oct 2007 09:11:08 +0200 > "Carl Friedrich Bolz" wrote: > > > Hi Simon, > > > > 2007/10/3, Simon Burton : > ... > > > I just use a function from rctypes to find a library, i think > > > rffi has such a function now.. > > > > Then it should be possible to use the function that rffi provides? > > It's likely. That's great. Then we should probably think about doing that so that everybody is happy: one step closer to killing rctypes and (maybe) a way to reuse all that ctypes stuff while still using rffi. > > > Do people realize that genrffi allows ctypes (nothing to do with rctypes) > > > to be used as a front-end to rffi ? Ie. instead of using ctypes > > > (in ll2ctypes) as a backend to rffi. > > > > No, I was not aware of this. There never was neither a mail to this > > list about this, nor a sprint report about the Vilnius sprint, so how > > should people that didn't go there know? > > Well, this is what I wrote: > http://codespeak.net/pipermail/pypy-dev/2007q3/003920.html > > Should I have written more ? I did not want to "conclude" anything > at that point in time. hum, it seems I have actually forgotten that mail (I am pretty sure I saw it at one point, I wrote the post asking for a sprint report after all), sorry for the above then. However, it definitely wasn't clear to me that the tool was meant for more than for transitioning the existing rctypes code and also not that it didn't depend on rctypes. Anyway, I think we have reached a conclusion and get back to coding. Cheers, Carl Friedrich From fijal at genesilico.pl Fri Oct 5 11:26:03 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 05 Oct 2007 11:26:03 +0200 Subject: [pypy-dev] Moving to rffi Message-ID: <4706032B.3090106@genesilico.pl> Just to let you know, I've moved some modules from rctypes to rffi. Tests are passing, building should work, but some might encounter strange issues when using these modules, because not everything is well tested I think. I plan to move some other modules, like mmap and _ssl, if noone will stop me. Also next step would be to try approach for app-level ctypes. Any obstacles in sight? Cheers, fijal :. From pommereau at univ-paris12.fr Fri Oct 5 21:24:48 2007 From: pommereau at univ-paris12.fr (Franck Pommereau) Date: Fri, 05 Oct 2007 21:24:48 +0200 Subject: [pypy-dev] Customized parser Message-ID: <47068F80.40305@univ-paris12.fr> Dear PyPy developpers, I'd like to build a CPython program that would include a parser for a Python-like language. My idea was to start from PyPy's parser that is already written in pure Python. All I need is a parser that builds an AST or something equivalent. This is the idea. But from now on, I'm lost in PyPy's sources. I did not even figure out how to call the parser correctly... Does any one has an example that could guide me? The changes to the languages I need are removing some statements and adding few ones like: parallel: suite and: suite Thank you in advance for any help. Franck From njriley at uiuc.edu Sat Oct 6 02:29:33 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Fri, 5 Oct 2007 19:29:33 -0500 Subject: [pypy-dev] pypy-jvm translating magic? In-Reply-To: <20071003180121.GA13961@code0.codespeak.net> References: <20071003180121.GA13961@code0.codespeak.net> Message-ID: <20071006002933.GA12843@uiuc.edu> On Wed, Oct 03, 2007 at 08:01:21PM +0200, Armin Rigo wrote: > * Antonio and Niko are doing some very good work on the Java backend. > With minor tweaks we can now build a pypy-jvm. FWIW it seems to give > better performance than Jython. It's not 100% comparable because > pypy-jvm is not thread-aware or thread-safe yet, while Jython gives > you free threading; OTOH pypy-jvm doesn't generate Java bytecodes > on-the-fly (although it might do so in the future). All in all > pypy-jvm is still experimental, but stay tuned :-) I've been doing some Jython performance investigation recently so I was intrigued by the above statement. I tried: % python translate.py -b jvm --batch targetpypystandalone.py which failed at: Invoking jasmin on ['/tmp/usession-0/pypy/pypy/issubclass_3989.j', '/tmp/usession-0/pypy/pypy/_mm_int_intS0_perform_call_19609.j', '/tmp/usession-0/pypy/pypy/pypy/interpreter/astcompiler/ast/Sliceobj_meta_11152.j', '/tmp/usession-0/pypy/pypy/dict_mth_mm_items_perform_call_3231.j', '/tmp/usession-0/pypy/pypy/_mm_repr_sliceS0_perform_call_4133.j', '/tmp/usession-0/pypy/pypy/interp_w__AssTuple_27444.j', '/tmp/usession-0/pypy/pypy/hash_w_delegate_9102.j', '/tmp/usession-0/pypy/pypy/pypy/interpreter/gateway/BuiltinActivation_UwS_PyFrame_ObjSpace_W_Root_meta_20393.j', '/tmp/usession-0/pypy/pypy/str_mth_mm_ljust_perform_call_2415.j', '/tmp/usession-0/pypy/pypy/mod__Long_Long_25422.j', '/tmp/usession-0/pypy/pypy/all_delegate_1535.j', '/tmp/usession-0/pypy/pypy/pypy/interpreter/gateway/BuiltinActivation_UwS_ObjSpace_STType_int_meta_15329.j', '/tmp/usession-0/pypy/pypy/eq_w_delegate_18069.j', '/tmp/usession-0/pypy/pypy/and__delegate_16652.j', '/tmp/usession-0/pypy/pypy/boundmethod_int_w_star1_24850.j', '/tmp/usession-0/pypy/pypy/_mm_floordiv_floatS0_perform_call_5681.j', '/tmp/usession-0/pypy/pypy/descr_typecheck_fget_node_delegate_11750.j', '/tmp/usession-0/pypy/pypy/descr_typecheck_fset_else__0_delegate_11298.j', '/tmp/usession-0/pypy/pypy/pypy/rlib/rbigint/rbigint_63.j', '/tmp/usession-0/pypy/pypy/Function/descr_function_repr_27175.j', '/tmp/usession-0/pypy/pypy/_mm_pow_longS1_perform_call_delegate_20674.j', '/tmp/usession-0/pypy/pypy/descr_Compare_new_13737.j', '/tmp/usession-0/pypy/pypy/_mm_xor_longS1_perform_call_20791.j'] [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "translate.py", line 272, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/home/zilles/njriley/zilles/pypy-dist/pypy/translator/driver.py", line 754, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/home/zilles/njriley/zilles/pypy-dist/pypy/translator/tool/taskengine.py", line 112, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/home/zilles/njriley/zilles/pypy-dist/pypy/translator/driver.py", line 265, in _do [translation:ERROR] res = func() [translation:ERROR] File "/home/zilles/njriley/zilles/pypy-dist/pypy/translator/driver.py", line 728, in task_compile_jvm [translation:ERROR] self.jvmsource.compile() [translation:ERROR] File "/home/zilles/njriley/zilles/pypy-dist/pypy/translator/jvm/genjvm.py", line 165, in compile [translation:ERROR] self._invoke(jascmd + files, False) [translation:ERROR] File "/home/zilles/njriley/zilles/pypy-dist/pypy/translator/jvm/genjvm.py", line 107, in _invoke [translation:ERROR] raise JvmSubprogramError(res, args, stdout, stderr) [translation:ERROR] JvmSubprogramError: Error code 0 running ['jasmin', '-d', '/tmp/usession-0/pypy', '/tmp/usession-0/pypy/pypy/issubclass_3989.j', '/tmp/usession-0/pypy/pypy/_mm_int_intS0_perform_call_19609.j', '/tmp/usession-0/pypy/pypy/pypy/interpreter/astcompiler/ast/Sliceobj_meta_11152.j', '/tmp/usession-0/pypy/pypy/dict_mth_mm_items_perform_call_3231.j', '/tmp/usession-0/pypy/pypy/_mm_repr_sliceS0_perform_call_4133.j', '/tmp/usession-0/pypy/pypy/interp_w__AssTuple_27444.j', '/tmp/usession-0/pypy/pypy/hash_w_delegate_9102.j', '/tmp/usession-0/pypy/pypy/pypy/interpreter/gateway/BuiltinActivation_UwS_PyFrame_ObjSpace_W_Root_meta_20393.j', '/tmp/usession-0/pypy/pypy/str_mth_mm_ljust_perform_call_2415.j', '/tmp/usession-0/pypy/pypy/mod__Long_Long_25422.j', '/tmp/usession-0/pypy/pypy/all_delegate_1535.j', '/tmp/usession-0/pypy/pypy/pypy/interpreter/gateway/BuiltinActivation_UwS_ObjSpace_STType_int_meta_15329.j', '/tmp/usession-0/pypy/pypy/eq_w_delegate_18069.j', '/tmp/usession-0/pypy/pypy/and__delegate_16652.j', '/tmp/usession-0/pypy/pypy/boundmethod_int_w_star1_24850.j', '/tmp/usession-0/pypy/pypy/_mm_floordiv_floatS0_perform_call_5681.j', '/tmp/usession-0/pypy/pypy/descr_typecheck_fget_node_delegate_11750.j', '/tmp/usession-0/pypy/pypy/descr_typecheck_fset_else__0_delegate_11298.j', '/tmp/usession-0/pypy/pypy/pypy/rlib/rbigint/rbigint_63.j', '/tmp/usession-0/pypy/pypy/Function/descr_function_repr_27175.j', '/tmp/usession-0/pypy/pypy/_mm_pow_longS1_perform_call_delegate_20674.j', '/tmp/usession-0/pypy/pypy/descr_Compare_new_13737.j', '/tmp/usession-0/pypy/pypy/_mm_xor_longS1_perform_call_20791.j'] I was able to translate targetnopstandalone to Java so it seems to work a little, but obviously there is a big difference between that and PyPy. :) Trawling the IRC logs I found: [20:39] fijal: unfortunately pypy-jvm does not compile out of the box [20:39] you have to manually patch two lines in rbigint Is this still true? Is the patch available somewhere? -- Nicholas Riley | From anto.cuni at gmail.com Sat Oct 6 12:48:51 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Sat, 06 Oct 2007 12:48:51 +0200 Subject: [pypy-dev] pypy-jvm translating magic? In-Reply-To: <20071006002933.GA12843@uiuc.edu> References: <20071003180121.GA13961@code0.codespeak.net> <20071006002933.GA12843@uiuc.edu> Message-ID: <47076813.9010001@gmail.com> Hi Nicholas, Nicholas Riley wrote: > I was able to translate targetnopstandalone to Java so it seems to > work a little, but obviously there is a big difference between that > and PyPy. :) Trawling the IRC logs I found: > > [20:39] fijal: unfortunately pypy-jvm does not compile > out of the box > [20:39] you have to manually patch two lines in rbigint > > Is this still true? Is the patch available somewhere? yes, it's still true; the patch is very little and simple: Index: rlib/rbigint.py =================================================================== --- rlib/rbigint.py (revision 47111) +++ rlib/rbigint.py (working copy) @@ -176,7 +176,8 @@ return _AsLong(self) def tolonglong(self): - return _AsLongLong(self) + raise OverflowError # XXX + #return _AsLongLong(self) def tobool(self): return self.sign != 0 With this, you should be able to translate and compile pypy-jvm. About performances, there are a lot of factors that could affect them. For example, I found that if we inline too much, performances are worse, probably because jvm's JIT compiles again and again the same code. Moreover, PyPy provides also a number of optimizations to the interpreter which can greatly improve the efficiency: there is a --faassen option that includes all the optimizations known to be good for pypy-c, but I found that maybe not all of them are also good for pypy-jvm. For example, I got better results with shadowtracking and methodcache disabled than with the full --fassen; I don't know why, it's probably worth of being investigated. To conclude, you should try with the following command line to get best results: ./translate.py -b jvm --inline-threshold 0 targetpypystandalone.py --faassen --no-objspace-std-withshadowtracking --no-objspace-std-withmethodcache You can also try to use only --fassen to see if the performances are worse also for you. Any other experiment with the options is very welcome, of course :-). ciao Anto From tismer at stackless.com Sun Oct 7 04:10:46 2007 From: tismer at stackless.com (Christian Tismer) Date: Sun, 07 Oct 2007 04:10:46 +0200 Subject: [pypy-dev] Where's the Starship's crew? In-Reply-To: <1191576398.250642.71010@w3g2000hsg.googlegroups.com> References: <1191576398.250642.71010@w3g2000hsg.googlegroups.com> Message-ID: <47084026.3090608@stackless.com> exhuma.twn wrote: > On Oct 5, 10:31 am, Dick Moores wrote: >> >> >> I didn't check on all of them, but the only one I found was Mark >> Hammond . >> >> Dick Moores > > Doing 6 random clicks, revealed: > > http://starship.python.net/crew/hooft/ > > all the others are dead links. I realised this fact as well some time > ago already. I thought the page itself was still "in development" and > did not find a single one page. These two obviously eluded me ;) There are actually 20 active links, different from the error default. Ok, this is not the best result for a total of 273 members. > Strange to see that the situation did not yet improve. But then again, > we all probably know how much of a hassle it is to keep 10 different > web-pages with personal info's up-to-date. I suppose that the starship > crew all have som homes elsewhere and don't find the time to update > yet another page. No, I think the Starship lost a lot of its popularity after a couple of havaries, and its initiator failed to lead it and to push it further. I think this is something that needs to be done by somebody. There was a couple of very helpful supporters, but they were all on their own, and the originally driving person did not care any longer for many years. This has changed. > I myself don't even bother anymore at all. I have > about 2 hours of free time per day (given that I like to sleep a > lot!). What makes things worse, the network at work is completely cut > off from the rest of the world for security reasons. I am happy that I > at least can access usenet by using google-groups *sigh*. So you have HTTP access? Then ask the starship to support that! I will take care! > An interesting task might be to find the homes of the starship crew, > and post them here? Maybe? If lucky, the right person picks this up > and updates the crew-quarter labels of the starship. Or would > "Turbolift Buttons" be a better analogy for hyperlinks? Args. > Supposing, that these turbolifts *do* have buttons. How retro! ;) The Starship has gone through quite some problems and different hands. They all were good, and I wish to thank Stefan Drees especially for hosting it alone for four years from his personal budget. Not to forget the years where we were hosted by zope.org, and beopen.com, and some Service created by Mike Mc. Lay before. Please excuse me, the I don't remember all the details, this will go into a history page or blog ASAP. After a long journey through space and time, I am getting back at my roots, and I want to fill the gap of a driving person, again. This is not selfish in any way, and not saying that it must be me at all, but somehow I feel the wish to bring something to a working future that I started long time ago. I invented, created and hosted the Starship, ten years ago. Now I think, after spending a lot of time with other projects like Stackless Python and PyPy, time has come to redo the Starship idea, which was my first contribution for the Python community, a time where I was not able to really contribute by code. Especially, I could not work on the Python core because I was no C programmer. So I created Starship, learned C, understood all the internals and invented Stackless. But after all, I think I owe the Starship a lot, and I want it to continue, and to become a valued resource, again. As a starter, I moved the ship to my stackless server, this time using OpenVZ. This transfer worked much smoother than expected; I consider OpenVZ a great piece of software. The Starship is therefore right now not very different from its outside view, it was just moved and upgraded. That is just the beginning. To turn it into a resource of desire, again, a row of improvements are necessary. My personal vision, amoung new projects, is to split my time between Starship, Stackless and PyPy. If that works depends on the goodwill of sponsors. But it has worked, so I believe it will work, again. -- Here is an incomplete list of things that I want to do or initiate. First, I want to revive as many as crew homes that are archived. This will fill the tiny list from above, reasonably, and probably it will result in people updating their outdated pages. Then, I want to split the Starship into many sub-sites, first on my server, then by using a lot of more servers. I am seeking for sponsors who are willing to support this. In the end, my vision is turning python.net into a real network of many servers, each running a very small number of services through openVZ. Python.net should be something like a server farm, which runs everything available in Python. Really everything, including the myriads of possible PyPy builds. I want to separate all of these things by utilizing OpenVZ, as fine-grained as makes sense. I am investigating this these days. Right now, the Starship is a single VE. It will turn into a growing set of smaller VE's in the next weeks. And as soon as we get sponsorship, python.net will split itself over multiple machines. After all, my vision is to create the ultimate Python showdown, running everything possible in isolated environments and allowing people to play with different configurations. python.net should become the ultimate python resource site for interactive playing and trying, and providing a home for people to show their development. I will also try to get the PSF interested in that; maybe there is also some PSF funding possible. But this is an option, I will continue Starship without support as well. I believe I can do that, with your help. feeling stronger than before that stroke attack -- sincerely - chris -- This is much more work than I can do alone. Therefore, I am asking for people to help me with this. I also don't want to miss any of the current supporters, and we will name them all on the revised contributors pages to come. In order to support really many Python projects, we will need not only sponsors, but probably the support of the individual project maintainers as well. I am open to make this my goal of life, if there are enough people interested. But they will, I know it. I do believe in Python, Starship, PyPy and Stackless. Please help me to make this life-dream into reality. happily being back to the roots -- 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 paul.degrandis at gmail.com Mon Oct 8 06:49:38 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Mon, 8 Oct 2007 00:49:38 -0400 Subject: [pypy-dev] Where's the Starship's crew? In-Reply-To: <47084026.3090608@stackless.com> References: <1191576398.250642.71010@w3g2000hsg.googlegroups.com> <47084026.3090608@stackless.com> Message-ID: <9c0bb8a00710072149o52842ce3yc831c5c3e9619cfd@mail.gmail.com> Chris, I think your vision is awesome and admirable. Welcome home. Please feel free to contact me about any services I or Drexel University can offer you. I am finishing up an Autonomic Toolkit and Framework that uses decorators as the primary way to make self-aware and self-healing software. I'd like to see it gain more widespread adoption across all Python developers. Perhaps annoucing the inclusions of new projects, like mine and pypy, with the rebirth of the starship and the python.net network, will help sell the idea and bring more hands to help push the work forward. Either way, as stated before, let me know how I can help. Paul On 10/6/07, Christian Tismer wrote: > > exhuma.twn wrote: > > On Oct 5, 10:31 am, Dick Moores wrote: > >> > >> > >> I didn't check on all of them, but the only one I found was Mark > >> Hammond . > >> > >> Dick Moores > > > > Doing 6 random clicks, revealed: > > > > http://starship.python.net/crew/hooft/ > > > > all the others are dead links. I realised this fact as well some time > > ago already. I thought the page itself was still "in development" and > > did not find a single one page. These two obviously eluded me ;) > > There are actually 20 active links, different from the error default. > Ok, this is not the best result for a total of 273 members. > > > Strange to see that the situation did not yet improve. But then again, > > we all probably know how much of a hassle it is to keep 10 different > > web-pages with personal info's up-to-date. I suppose that the starship > > crew all have som homes elsewhere and don't find the time to update > > yet another page. > > No, I think the Starship lost a lot of its popularity after a couple > of havaries, and its initiator failed to lead it and to push it > further. I think this is something that needs to be done by somebody. > There was a couple of very helpful supporters, but they were all > on their own, and the originally driving person did not care > any longer for many years. This has changed. > > > I myself don't even bother anymore at all. I have > > about 2 hours of free time per day (given that I like to sleep a > > lot!). What makes things worse, the network at work is completely cut > > off from the rest of the world for security reasons. I am happy that I > > at least can access usenet by using google-groups *sigh*. > > So you have HTTP access? > Then ask the starship to support that! > I will take care! > > > An interesting task might be to find the homes of the starship crew, > > and post them here? Maybe? If lucky, the right person picks this up > > and updates the crew-quarter labels of the starship. Or would > > "Turbolift Buttons" be a better analogy for hyperlinks? Args. > > Supposing, that these turbolifts *do* have buttons. How retro! ;) > > The Starship has gone through quite some problems and different hands. > They all were good, and I wish to thank Stefan Drees especially > for hosting it alone for four years from his personal budget. > Not to forget the years where we were hosted by zope.org, and > beopen.com, and some Service created by Mike Mc. Lay before. > Please excuse me, the I don't remember all the details, this > will go into a history page or blog ASAP. > > After a long journey through space and time, I am getting back at > my roots, and I want to fill the gap of a driving person, again. > This is not selfish in any way, and not saying that it must be > me at all, but somehow I feel the wish to bring something to > a working future that I started long time ago. > > I invented, created and hosted the Starship, ten years ago. > Now I think, after spending a lot of time with other projects > like Stackless Python and PyPy, time has come to redo the Starship > idea, which was my first contribution for the Python community, > a time where I was not able to really contribute by code. > Especially, I could not work on the Python core because I was no > C programmer. So I created Starship, learned C, understood all > the internals and invented Stackless. > > But after all, I think I owe the Starship a lot, and I want it to > continue, and to become a valued resource, again. As a starter, > I moved the ship to my stackless server, this time using OpenVZ. > > This transfer worked much smoother than expected; I consider > OpenVZ a great piece of software. > > The Starship is therefore right now not very different from its > outside view, it was just moved and upgraded. That is just the > beginning. To turn it into a resource of desire, again, a row > of improvements are necessary. > > My personal vision, amoung new projects, is to split my time > between Starship, Stackless and PyPy. If that works depends > on the goodwill of sponsors. But it has worked, so I believe it > will work, again. > > -- > > Here is an incomplete list of things that I want to do or initiate. > > First, I want to revive as many as crew homes that are archived. > This will fill the tiny list from above, reasonably, and probably > it will result in people updating their outdated pages. > > Then, I want to split the Starship into many sub-sites, first > on my server, then by using a lot of more servers. I am seeking > for sponsors who are willing to support this. > > In the end, my vision is turning python.net into a real network > of many servers, each running a very small number of services > through openVZ. Python.net should be something like a server farm, > which runs everything available in Python. Really everything, > including the myriads of possible PyPy builds. > > I want to separate all of these things by utilizing OpenVZ, > as fine-grained as makes sense. I am investigating this these days. > Right now, the Starship is a single VE. It will turn into a growing > set of smaller VE's in the next weeks. And as soon as we get > sponsorship, python.net will split itself over multiple machines. > > After all, my vision is to create the ultimate Python showdown, > running everything possible in isolated environments and allowing > people to play with different configurations. > > python.net should become the ultimate python resource site > for interactive playing and trying, and providing a home for > people to show their development. > > I will also try to get the PSF interested in that; maybe there > is also some PSF funding possible. But this is an option, I > will continue Starship without support as well. > > I believe I can do that, with your help. > > feeling stronger than before that stroke attack -- sincerely - chris > > -- > > This is much more work than I can do alone. Therefore, I am asking > for people to help me with this. > I also don't want to miss any of the current supporters, and we will > name them all on the revised contributors pages to come. > In order to support really many Python projects, we will need > not only sponsors, but probably the support of the individual > project maintainers as well. I am open to make this my goal > of life, if there are enough people interested. > But they will, I know it. > > I do believe in Python, Starship, PyPy and Stackless. > Please help me to make this life-dream into reality. > > happily being back to the roots -- 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/ > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lac at openend.se Mon Oct 8 16:57:13 2007 From: lac at openend.se (Laura Creighton) Date: Mon, 8 Oct 2007 16:57:13 +0200 Subject: [pypy-dev] Anybody been following the Open Mono project? Message-ID: <200710081457.l98EvD2o030995@theraft.openend.se> It is here: http://wiki.openmoko.org/wiki/Main_Page On their wishlist: http://wiki.openmoko.org/wiki/Wish_List They say that they are looking for a scripting language. Python is liked, but they fear it is too big. see: http://wiki.openmoko.org/wiki/Wish_List#Built-in_Scripting_Language It seems to me that they would like PyPy if we built a small version for them. It also seems as if a really old friend of mine (Ian Darwin) is involved enough in the project to be presenting it to linux Ontario this October. I wonder if some of the ideas we had 20 years ago about lightweight processes and tinier-than-v7 os's have made it into open moko? I wonder if it would be worth it to get a few of the experimental phones? Laura From fijal at genesilico.pl Mon Oct 8 17:23:37 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 08 Oct 2007 17:23:37 +0200 Subject: [pypy-dev] Anybody been following the Open Mono project? In-Reply-To: <200710081457.l98EvD2o030995@theraft.openend.se> References: <200710081457.l98EvD2o030995@theraft.openend.se> Message-ID: <470A4B79.4040002@genesilico.pl> Laura Creighton wrote: > It is here: > http://wiki.openmoko.org/wiki/Main_Page > > On their wishlist: > http://wiki.openmoko.org/wiki/Wish_List > > They say that they are looking for a scripting language. Python > is liked, but they fear it is too big. > > see: http://wiki.openmoko.org/wiki/Wish_List#Built-in_Scripting_Language > > It seems to me that they would like PyPy if we built a > small version for them. It also seems as if a really old friend of > mine (Ian Darwin) is involved enough in the project to be presenting > it to linux Ontario this October. I wonder if some of the ideas we had > 20 years ago about lightweight processes and tinier-than-v7 os's > have made it into open moko? > > I wonder if it would be worth it to get a few of the experimental phones? > > Laura > Of course it makes sense :) They might be interested in our translation toolchain as something providing relatively high-level abstraction (gc, python-alike) which we can tailor to whatever. It's also quite designed for implementing interpreters, disregarding whether it's python or not. On the other hand, having full python might be quite heavy. Cheers, fijal :. From arigo at tunes.org Tue Oct 9 11:05:08 2007 From: arigo at tunes.org (Armin Rigo) Date: Tue, 9 Oct 2007 11:05:08 +0200 Subject: [pypy-dev] Customized parser In-Reply-To: <47068F80.40305@univ-paris12.fr> References: <47068F80.40305@univ-paris12.fr> Message-ID: <20071009090508.GA19177@code0.codespeak.net> Hi Franck, On Fri, Oct 05, 2007 at 09:24:48PM +0200, Franck Pommereau wrote: > I'd like to build a CPython program that would include a parser for a > Python-like language. My idea was to start from PyPy's parser that is > already written in pure Python. All I need is a parser that builds an > AST or something equivalent. > > This is the idea. But from now on, I'm lost in PyPy's sources. I did not > even figure out how to call the parser correctly... > > Does any one has an example that could guide me? PyPy itself has optionally the ability to modify its own grammar at run-time. You have to translate it with --withmod-dyngram (or --allworkingmodules) to enable the 'dyngram' module. See a usage example in pypy/module/recparser/test/test_dyn_grammarrules (I didn't try to run this code myself on a pypy-c though). That's not really answering your question, though, which was how to grab PyPy's bytecode compiler and start playing with it. Unfortunately I cannot really answer this question, as it seems that nobody is left around here which really cares about this part of the code. But you should be able to get started by looking at the helper function source2ast() in pypy/interpreter/pyparser/test/test_astbuilder. A bientot, Armin From amauryfa at gmail.com Wed Oct 10 19:30:29 2007 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Wed, 10 Oct 2007 19:30:29 +0200 Subject: [pypy-dev] [pypy-svn] r47380 - pypy/dist/pypy/translator/c/test Message-ID: Hello, > Modified: > pypy/dist/pypy/translator/c/test/test_typed.py > Log: > this test breaks the c backend in a curious way I think I found the reason: in gen_assignments(), variable names are compared by reference, but source and destination names are are constructed in different ways. I propose the following patch: Index: pypy/translator/c/support.py =================================================================== --- pypy/translator/c/support.py (revision 47380) +++ pypy/translator/c/support.py (working copy) @@ -205,7 +205,7 @@ startingpoint = dst tmpdecl = cdecl(typename, 'tmp') code = ['{ %s = %s;' % (tmpdecl, dst)] - while src is not startingpoint: + while src != startingpoint: code.append('%s = %s;' % (dst, src)) dst = src src, typename = dest2src.pop(dst) -- Amaury Forgeot d'Arc From ondrej at certik.cz Fri Oct 12 02:29:23 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Fri, 12 Oct 2007 02:29:23 +0200 Subject: [pypy-dev] py.test bisection algorithm Message-ID: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> Hi, we are using py.test in SymPy and unfortunately, we have some bugs in SymPy, that occurs when certain tests are run and don't occur when the tests are run in different order. It's very time consuming to determine which tests cause the problem (I did that several times by hand). It occured to me that it should be possible to enhance py.test by this facility to do it automatically. Example: 1) This passes: $ py.test sympy/series/tests/test_series.py -k issue409 This doesn't 2) $ py.test One problem is, that 2) runs for several minutes, another problem is that I need to specify all tests on the command line and then deleting some of them it see if it still fails, until I narrow the issue down, usually quite nicely. Then I need to play with the "-k" parameter to try different test cases in the file, until I determine the minimal set of tests that, when executed in order, produce the error. This can by done automatically - the py.test will be given a set of files (or just tests) that pass and another set that fails and it will narrow the problem down, by bisecting. I would like to implement this in py.test. So I'll try my best and send you a patch. If you have some ideas, that could help me, I am interested. Thanks a lot, Ondrej From anto.cuni at gmail.com Fri Oct 12 10:44:52 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Fri, 12 Oct 2007 10:44:52 +0200 Subject: [pypy-dev] pypy-jvm translating magic? In-Reply-To: References: <20071003180121.GA13961@code0.codespeak.net> <20071006002933.GA12843@uiuc.edu> <47076813.9010001@gmail.com> <470DDA82.2080808@gmail.com> Message-ID: <470F3404.6080706@gmail.com> Niko Matsakis wrote: > So, I see the bug, it's a bit odd. It seems to have to do with the > constant 9223372036854775808L, which gets serialized incorrectly into > the jasmin code. However, the Python code looks ok, so I am not sure > where the problem is. > > I tried to create a unit test to reproduce the error, but I am running > into a seemingly different problem that has to do with a (builtin?) > function PyLong_FromUnsignedLongLong. The oosupport direct_call opcode > fails to handle it properly, whatever it is. Hi Niko! Thanks to Carl Friedrich, I found that the problem with that test is that you must to annotate it explicitly with r_ulonglong, else the annotation degenerates to SomeObject and the rtyper assign it the PyObject* type. I checked in the test in oosupport.test_template.operations.test_compare_big_ullongs; now the test passes in gencli but fails in genjvm with the same error as the full translation. Moreover, I also addedd a new failing test to oosupport.test_template.runtest.test_big_ullong. I don't know if I will find the time to look at them today, though. ciao Anto From niko at alum.mit.edu Fri Oct 12 11:44:16 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 12 Oct 2007 11:44:16 +0200 Subject: [pypy-dev] pypy-jvm translating magic? In-Reply-To: <470F3404.6080706@gmail.com> References: <20071003180121.GA13961@code0.codespeak.net> <20071006002933.GA12843@uiuc.edu> <47076813.9010001@gmail.com> <470DDA82.2080808@gmail.com> <470F3404.6080706@gmail.com> Message-ID: > I checked in the test in > oosupport.test_template.operations.test_compare_big_ullongs; now > the test passes in gencli but fails in genjvm with the same error > as the full translation. Moreover, I also addedd a new failing test > to oosupport.test_template.runtest.test_big_ullong. > > I don't know if I will find the time to look at them today, though. I will take a look at least at the JVM problem today, and hopefully the others. Thanks dudes! Niko From rajb at rice.edu Sun Oct 14 15:18:41 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Sun, 14 Oct 2007 08:18:41 -0500 Subject: [pypy-dev] Pypy-c error on windows Message-ID: <6264EDF7-AB4F-4E39-ADD8-8CE0E1636C6D@rice.edu> Hi there I'm new to trying out pypy, and I hope this is the right list to ask questions. I just installed the pypy version for Windows on a Windows XP/Intel platform. However, I get errors when I start it up > pypy-c -------------------- Python 2.4.1.... Type "help".... Error calling sys.excepthook: debug: OperationError debug: operrortype: ImportError debug: operror-value: No module named traceback --------------------- Any idea what's going on? I'd appreciate getting this working. Thanks Raj From lac at openend.se Sun Oct 14 15:51:29 2007 From: lac at openend.se (Laura Creighton) Date: Sun, 14 Oct 2007 15:51:29 +0200 Subject: [pypy-dev] Pypy-c error on windows In-Reply-To: Message from Raj Bandyopadhyay of "Sun, 14 Oct 2007 08:18:41 CDT." <6264EDF7-AB4F-4E39-ADD8-8CE0E1636C6D@rice.edu> References: <6264EDF7-AB4F-4E39-ADD8-8CE0E1636C6D@rice.edu> Message-ID: <200710141351.l9EDpTHj021779@theraft.openend.se> In a message of Sun, 14 Oct 2007 08:18:41 CDT, Raj Bandyopadhyay writes: >Hi there > >I'm new to trying out pypy, and I hope this is the right list to ask >questions. >I just installed the pypy version for Windows on a Windows XP/Intel >platform. > >However, I get errors when I start it up > > > pypy-c > >-------------------- >Python 2.4.1.... >Type "help".... > >Error calling sys.excepthook: >debug: OperationError >debug: operrortype: ImportError >debug: operror-value: No module named traceback >--------------------- > > >Any idea what's going on? I'd appreciate getting this working. > >Thanks >Raj This is the right place to ask questions. #pypy on freenode.net is another good place. I don't have a windows installation, but this looks to me as if you need to set your PYTHONPATH to point to wherever the modules are. But without a windows to install, I cannot check and see if I am completely wrong. Sorry about that, Laura From cfbolz at gmx.de Sun Oct 14 16:31:42 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 14 Oct 2007 16:31:42 +0200 Subject: [pypy-dev] Pypy-c error on windows In-Reply-To: <6264EDF7-AB4F-4E39-ADD8-8CE0E1636C6D@rice.edu> References: <6264EDF7-AB4F-4E39-ADD8-8CE0E1636C6D@rice.edu> Message-ID: <4712284E.7050207@gmx.de> Hi Raj, Raj Bandyopadhyay wrote: > Hi there > > I'm new to trying out pypy, and I hope this is the right list to ask > questions. > I just installed the pypy version for Windows on a Windows XP/Intel > platform. > > However, I get errors when I start it up > > > pypy-c > > -------------------- > Python 2.4.1.... > Type "help".... > > Error calling sys.excepthook: > debug: OperationError > debug: operrortype: ImportError > debug: operror-value: No module named traceback > --------------------- how exactly did you install pypy? Did you get one of the prebuilt binaries? Then you need to download the source too, since the std library is in it. Or did you build pypy yourself? Cheers, Carl Friedrich From rajb at rice.edu Sun Oct 14 16:38:41 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Sun, 14 Oct 2007 09:38:41 -0500 Subject: [pypy-dev] Pypy-c error on windows In-Reply-To: <4712284E.7050207@gmx.de> References: <6264EDF7-AB4F-4E39-ADD8-8CE0E1636C6D@rice.edu> <4712284E.7050207@gmx.de> Message-ID: <7059B639-7618-45E4-AB8A-6A3ECC34C78D@rice.edu> Thanks, Carl I did install the pre-built binary. I guess I'll download the source too and try. Do I have to compile the source again to get the std library, or install it in a specific location? Thanks Raj On Oct 14, 2007, at 9:31 AM, Carl Friedrich Bolz wrote: > Hi Raj, > > Raj Bandyopadhyay wrote: >> Hi there >> I'm new to trying out pypy, and I hope this is the right list to >> ask questions. >> I just installed the pypy version for Windows on a Windows XP/ >> Intel platform. >> However, I get errors when I start it up >> > pypy-c >> -------------------- >> Python 2.4.1.... >> Type "help".... >> Error calling sys.excepthook: >> debug: OperationError >> debug: operrortype: ImportError >> debug: operror-value: No module named traceback >> --------------------- > > how exactly did you install pypy? Did you get one of the prebuilt > binaries? Then you need to download the source too, since the std > library is in it. Or did you build pypy yourself? > > Cheers, > > Carl Friedrich -- I never predict anything, and I never will. -- Paul Gascoigne From cfbolz at gmx.de Sun Oct 14 16:43:26 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 14 Oct 2007 16:43:26 +0200 Subject: [pypy-dev] Pypy-c error on windows In-Reply-To: <7059B639-7618-45E4-AB8A-6A3ECC34C78D@rice.edu> References: <6264EDF7-AB4F-4E39-ADD8-8CE0E1636C6D@rice.edu> <4712284E.7050207@gmx.de> <7059B639-7618-45E4-AB8A-6A3ECC34C78D@rice.edu> Message-ID: <47122B0E.5010806@gmx.de> Raj Bandyopadhyay wrote: > Thanks, Carl > > I did install the pre-built binary. I guess I'll download the source too > and try. > Do I have to compile the source again to get the std library, or install > it in a specific > location? then I can maybe help you :-). Download the source and try to put the binary into the directory pypy/translator/goal in the source directory. then the binary should pick up the standard-lib correctly. Cheers, Carl Friedrich From rajb at rice.edu Sun Oct 14 16:54:50 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Sun, 14 Oct 2007 09:54:50 -0500 Subject: [pypy-dev] Pypy-c error on windows In-Reply-To: <47122B0E.5010806@gmx.de> References: <6264EDF7-AB4F-4E39-ADD8-8CE0E1636C6D@rice.edu> <4712284E.7050207@gmx.de> <7059B639-7618-45E4-AB8A-6A3ECC34C78D@rice.edu> <47122B0E.5010806@gmx.de> Message-ID: <23780786-E07A-4FBC-A07F-57DAA82930CF@rice.edu> Hi Carl, I moved the binary over. Didn't work :( Same error. It looks like it might be a path problem after all, as Laura suggested. I just found that pypy-c runs fine when I start it up its own original installation directory. However, I'd like to figure out how to run it from my own directory. I'd like to avoid changing any environment variables, if possible, so that I don't break any of my other Python installations. Thanks, guys! Raj On Oct 14, 2007, at 9:43 AM, Carl Friedrich Bolz wrote: > Raj Bandyopadhyay wrote: >> Thanks, Carl >> I did install the pre-built binary. I guess I'll download the >> source too and try. >> Do I have to compile the source again to get the std library, or >> install it in a specific >> location? > > then I can maybe help you :-). Download the source and try to put > the binary into the directory pypy/translator/goal in the source > directory. then the binary should pick up the standard-lib correctly. > > Cheers, > > Carl Friedrich From len-l at telus.net Sun Oct 14 19:43:37 2007 From: len-l at telus.net (Lenard Lindstrom) Date: Sun, 14 Oct 2007 10:43:37 -0700 Subject: [pypy-dev] Pypy-c error on windows In-Reply-To: <23780786-E07A-4FBC-A07F-57DAA82930CF@rice.edu> References: <6264EDF7-AB4F-4E39-ADD8-8CE0E1636C6D@rice.edu> <4712284E.7050207@gmx.de> <7059B639-7618-45E4-AB8A-6A3ECC34C78D@rice.edu> <47122B0E.5010806@gmx.de> <23780786-E07A-4FBC-A07F-57DAA82930CF@rice.edu> Message-ID: <47125549.4070504@telus.net> I have the pre-compiled pypy-1.0.0 Windows binaries. The .exe files are in the top level pypy-1.0.0 directory. The Standard Python Library is in subdirectory share\pypy-1.0\lib-python\2.4.1 Lenard Raj Bandyopadhyay wrote: > Hi > > Carl, I moved the binary over. Didn't work :( Same error. > > It looks like it might be a path problem after all, as Laura > suggested. I just found that pypy-c runs fine when I start it up its > own original installation directory. However, I'd > like to figure out how to run it from my own directory. > > I'd like to avoid changing any environment variables, if possible, so > that I don't break any of my other Python installations. > > Thanks, guys! > Raj > > > On Oct 14, 2007, at 9:43 AM, Carl Friedrich Bolz wrote: > > >> Raj Bandyopadhyay wrote: >> >>> Thanks, Carl >>> I did install the pre-built binary. I guess I'll download the >>> source too and try. >>> Do I have to compile the source again to get the std library, or >>> install it in a specific >>> location? >>> >> then I can maybe help you :-). Download the source and try to put >> the binary into the directory pypy/translator/goal in the source >> directory. then the binary should pick up the standard-lib correctly. >> >> Cheers, >> >> Carl Friedrich >> > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From cfbolz at gmx.de Mon Oct 15 01:13:27 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 15 Oct 2007 01:13:27 +0200 Subject: [pypy-dev] some GC statistics Message-ID: <4712A297.30300@gmx.de> Hi all! I did some statistics of the memory pypy-c uses when running pystone. Some results below: - objects allocated: 14228349 - size allocated: 314.25MB - average object size: 23.16 bytes - average object life time: 1.17MB allocated - 0.3615% of objects lifes longer die before 8MB are allocated (which is the default heap size (it's very similar for number of objects) in this setting, a collection happened every 50KB allocated, so this is about the error on life time numbers. top ten allocated types: GcStruct W_IntObject { super, inst_intval } 104.6MB GcStruct StdObjSpaceFrame { super } 77.9MB GcArray of * GcStruct object { typeptr } 62.9MB GcStruct list { length, items } 27.5MB GcArray of dictentry { key: * GcStruct W_Root { super }, f_everused: Bool, value: * GcStruct W_Root { super }, f_hash: Signed } 6.7MB GcStruct LoopBlock { super } 5.7MB GcStruct rpy_string { hash, chars } 3.7MB GcStruct ArgumentsPrepended { super, inst_args, inst_w_firstarg } 3.5MB GcArray of Char 3.2MB GcStruct W_StringObject { super, inst__value } 3.1 MB there are also some more or less useful graphs here: http://codespeak.net/~cfbolz/gcstats/pystone.pdf This is not easily repeatable with richards, just because there is too much data :-). Cheers, Carl Friedrich From niko at alum.mit.edu Mon Oct 15 23:41:20 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 15 Oct 2007 23:41:20 +0200 Subject: [pypy-dev] PyPy JVM builds "out of the box" Message-ID: <81ADED9E-8636-4884-AC3C-025AF86C223C@alum.mit.edu> It is no longer necessary to apply any patches to get PyPy JVM to build. It should work "out of the box" now (does for me, anyhow). There are a still a few external functions unimplemented, though I have some partial implementations hanging around. Niko From paul.degrandis at gmail.com Mon Oct 15 23:46:39 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Mon, 15 Oct 2007 17:46:39 -0400 Subject: [pypy-dev] PyPy JVM builds "out of the box" In-Reply-To: <81ADED9E-8636-4884-AC3C-025AF86C223C@alum.mit.edu> References: <81ADED9E-8636-4884-AC3C-025AF86C223C@alum.mit.edu> Message-ID: <9c0bb8a00710151446t62aa75f4m4c740ab0b9f4d235@mail.gmail.com> Niko, That's amazing. I just saw news about OCaml's ability to use JSR223 Scripting interface on Java6, soon I hope to make the same claim on PyPy-JVM. Thank you and Antonio for your work on this to allow me to do the bindings. Paul On 10/15/07, Niko Matsakis wrote: > > It is no longer necessary to apply any patches to get PyPy JVM to > build. It should work "out of the box" now (does for me, anyhow). > There are a still a few external functions unimplemented, though I > have some partial implementations hanging around. > > > Niko > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anto.cuni at gmail.com Tue Oct 16 00:34:16 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Tue, 16 Oct 2007 00:34:16 +0200 Subject: [pypy-dev] PyPy JVM builds "out of the box" In-Reply-To: <81ADED9E-8636-4884-AC3C-025AF86C223C@alum.mit.edu> References: <81ADED9E-8636-4884-AC3C-025AF86C223C@alum.mit.edu> Message-ID: <4713EAE8.9040004@gmail.com> Niko Matsakis wrote: > It is no longer necessary to apply any patches to get PyPy JVM to > build. It should work "out of the box" now (does for me, anyhow). > There are a still a few external functions unimplemented, though I > have some partial implementations hanging around. Wow, that's extremely cool! Thanks for your work and for this very good news, Niko :-). ciao Anto From ondrej at certik.cz Tue Oct 16 03:54:28 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Tue, 16 Oct 2007 03:54:28 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <20070925090542.GB28896@code0.codespeak.net> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <85b5c3130709150623p5de74662j107cccc39c65db8c@mail.gmail.com> <46EE8CFA.2080209@gmx.de> <85b5c3130709170732m3c32dd1co7aa7351c7762aa81@mail.gmail.com> <20070919115814.GA8402@code0.codespeak.net> <85b5c3130709190522u6cd98510o83ea4adcd0a0d2f4@mail.gmail.com> <20070925090542.GB28896@code0.codespeak.net> Message-ID: <85b5c3130710151854r452d070evab90ef38129929a6@mail.gmail.com> Hi Armin, > Yes, os.tmpfile() was added in the meantime. I personally don't see > much the point of making Debian packages of PyPy at the moment, given > that we're in a state where you are almost always better off if you > start from our Subversion repository instead of from a release a few > months old. We're not "user-ready" and this situation will not change > before some more months, maybe 1 year. I'd really recommend starting > from our 'getting-started' document on the web site instead of the > Debian packages. Thanks for the explanation. I know how to use it from svn, I was compiling pypy from svn from the first version, that translated itself, just for fun. But I thought that since you released the 1.0 version, I could simply start using the Debian package. Ondrej From tismer at stackless.com Tue Oct 16 14:52:54 2007 From: tismer at stackless.com (Christian Tismer) Date: Tue, 16 Oct 2007 14:52:54 +0200 Subject: [pypy-dev] rffi and rpython layer consistency Message-ID: <4714B426.9060206@stackless.com> [a lengthy brain dump from last night which was meant for pypy-dev] [today I would be much more concise, but well, it is like it is] Dear Friends, I am talking about different layers of RPython and how coherently they respond. ATM, they don't. --------------------------------------------------- I am writing because I feel the need for it. We (you) have reached quite some state with PyPy and RPython. At the current state, I digged in and worked with the windows branch of Maciey's rmmap implementation. It went quite smooth, until I followed some XXX saying that the native windows types should be used. Not sure if they should be used, but I wanted to be consistent, and to try a show-case. And this caused me grief! Internal reasons for the trouble --------------------------------- Unfortunately, there are different flavors of the windows API. Most of them are consistent, having an agreement on what a HANDLE should be, for instance. But there are lower-level, also public functions with no general equivalent, which simply define a Handle as an int. This is not nice, but given by the gods of MS. Now I wanted to use exactly those inconsistent declarations with RFFI. Exactly! Why did I want this? --------------------- Well, ideally an extension writer should not bother about any types, just use them and pass them around as necessary. But there is this inconsistency. In order to make functions compatible, I tried to insert casts, a bad thing, I know. But how are casts worse that modifying an original definition? I wanted to provide a clean interface, as clean as can be, with no modifications. But rffi stopped me doing this. Putting it short: ------------------ I don't want to have cast restrictions in llinterp, which don't exist in ctypes and low level modes. After trying this for hours and already days, I came up with the following limitations of our type system: 1) things are running fine on top of cpython, with the ctypes emulation in place 2) things do not run well with llinterp in place. llinterp has grown into a large handler of different cases, no objection, but it does not do what it should do in this particular case. 3) things in a full translation are behaving like expected. We should move away from a full trabslation requirement as a proof of concept. What I can agree with would be a strong hierarchy, getting more restrictive as we become more specific. But the current situation just feels badly inconsistent and unsorted. rffi has a cast operation, which is implemented by force_cast. This should be unconditional. For every mode of interpretation or translatition. But it is not. Good but then bad: Using ctypes, everything works great. This should be the point of trust: it ctypes takes it, there should be no more testing needed. Worse, much worse: llinterp barfs at me, moaning that it is only able to cast an odd int. Hey why that!!! Crazy, in the end: I can produce a perfect extension to PyPy. Yes, I know, this was a contribution for testing tagged pointers. I do hate this argument. This is not PyPy. We do not implement something that is needed in some place. It is either explicitly enabled and used in a controlled manner, or it is disabled. So what I'm saying is this: ---------------------------- We should not support casting to any odd pointers at all, unless we are doing a tagged pointer implementation. By default, these operations should be hidden. If we do so, then we should emit a special operation for all pointers in that domain, and it should not be value dependent, but type dependent, only for that domain (whatever a domain should be, in this context). We also should not support casting to any pointer at all but for good reasons. If we have to cast, then for inconsistent, given annotations. That is just the case for rffi! I just want it there -- rffi.cast does a cast. Maybe restricted to raw, no idea. But it should be there, and only there! ------------------ Conclusion: This is what I'd like to do. - make pointer coercion functions as restrictive as possible - drop the llinterp odd pointer rule; instead - implement tagging exactly for those kinds of pointers where we want to support pointer tagging - make casting rules consistent through all layers of abstraction. If interpreted pypy allows/forbids casts, llinterp must adhere to it, and backends must follow the rules, too. - testing should have a defined hierarchy of things that may break when moving from one layer to the other. Ideally, they all would be the same. But they should be monotone: If a passes level 3, it also should pass level 1 and 2. - I would like to add tests for these meta-test levels, if seems appropriate. Yes, this was what I wanted to communicate since days. I'm open to work on these things, while I hope that these issues are not just my problem, after some thought ouf your's. You will know. G'nite -- 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 rajb at rice.edu Tue Oct 16 15:49:40 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Tue, 16 Oct 2007 08:49:40 -0500 Subject: [pypy-dev] pypy-c and JIT Message-ID: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> Hi I am currently running pypy-c on Windows and I was wondering what the default mode of execution is. Is it a bytecode interpreter or is it doing a JIT compilation? Is there a native code option and how can I invoke it? Thanks Raj From tismer at stackless.com Tue Oct 16 16:10:00 2007 From: tismer at stackless.com (Christian Tismer) Date: Tue, 16 Oct 2007 16:10:00 +0200 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> Message-ID: <4714C638.5000403@stackless.com> Raj Bandyopadhyay wrote: > Hi > > I am currently running pypy-c on Windows and I was wondering what the > default mode of execution is. Is it a bytecode interpreter or is it > doing > a JIT compilation? Is there a native code option and how can I invoke > it? Before asking new questions, I would like to ask you for the solution of your previous problem, to share it with others. It is a bytecode interpreter. For trying Jit and other flavors of PyPy, you need to check out the svn repository and do your own PyPy build, at the moment. 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 rajb at rice.edu Tue Oct 16 18:30:56 2007 From: rajb at rice.edu (Raj) Date: Tue, 16 Oct 2007 11:30:56 -0500 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: <4714C638.5000403@stackless.com> References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> Message-ID: <1192552256.4714e74018eec@webmail.mail.rice.edu> Well, for my previous problem, pypy-c on windows worked only when I ran it in the installation directory, so I did copped out and ran my programs by copying them over. Didn't really find a proper solution to the problem, but I assume it involves setting some path variables. Thanks! Raj Quoting Christian Tismer : > Before asking new questions, I would like to ask you for > the solution of your previous problem, to share it with > others. > > It is a bytecode interpreter. > For trying Jit and other flavors of PyPy, > you need to check out the svn repository and > do your own PyPy build, at the moment. > > cheers - chris > > -- From elmo13 at jippii.fi Wed Oct 17 21:53:26 2007 From: elmo13 at jippii.fi (=?UTF-8?B?RWxtbyBNw6RudHluZW4=?=) Date: Wed, 17 Oct 2007 22:53:26 +0300 Subject: [pypy-dev] Some issues with the testing framework Message-ID: <47166836.50100@jippii.fi> Using --tb=short has propably always crashed (with a failing test). Attached is a file demonstrating a few issues with pypys applevel testing framework, of which some might be 'won't fix' Elmo -------------- next part -------------- A non-text attachment was scrubbed... Name: test_tmp.py Type: text/x-python Size: 1335 bytes Desc: not available URL: From elmo13 at jippii.fi Wed Oct 17 23:02:57 2007 From: elmo13 at jippii.fi (=?UTF-8?B?RWxtbyBNw6RudHluZW4=?=) Date: Thu, 18 Oct 2007 00:02:57 +0300 Subject: [pypy-dev] Some issues with the testing framework In-Reply-To: <47166836.50100@jippii.fi> References: <47166836.50100@jippii.fi> Message-ID: <47167881.5050902@jippii.fi> Of course, now I py.test behaves with --tb=short, might have been my fault after all:). Apparently, all of the stuff below but the first aren't bugs. Elmo Elmo M?ntynen wrote: > Using --tb=short has propably always crashed (with a failing test). > > Attached is a file demonstrating a few issues with pypys applevel > testing framework, of which some might be > 'won't fix' > > > Elmo > > ------------------------------------------------------------------------ > > from pypy.conftest import gettestobjspace > > class BaseAppTestInheritance: > def setup_class(cls): > pass > > def test_foo(self): > pass > > class AppTest(BaseAppTestInheritance): > def setup_class(cls): > BaseAppTestInheritance.setup_class(cls) > > > #Demonstrates the workaround I had to use instead of the former way: > class BaseAppTestWorkaround: > def setup_class(cls): > self._setup_class(cls) > > > @staticmethod > def _setup_class(cls): > pass > > def test_foo(self): > pass > > class AppTestWorkaround(BaseAppTestWorkaround): > def setup_class(cls): > BaseAppTestWorkaround._setup_class(cls) > > #Should this work? I don't specifically need this 'cause I found a better way... > class AppTestFoo: > def setup_class(cls): > cls.space = gettestobjspace() > cls.w_func = cls.space.appexec([cls.space.wrap(cls)], """(cls): > def f(): > print cls.var > return f > """) > cls.w_var='foo' > > def test_foo(self): > self.func() > > class AppTestBar: > def setup_class(cls): > cls.space = gettestobjspace() > cls.w_func = cls.space.appexec((), """(): > import py.test > def f(): > py.test.skip() > return f > """) > > def test_foo(self): > self.func() > > ------------------------------------------------------------------------ > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From fijal at genesilico.pl Wed Oct 17 23:42:24 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Wed, 17 Oct 2007 23:42:24 +0200 Subject: [pypy-dev] Some issues with the testing framework In-Reply-To: <47167881.5050902@jippii.fi> References: <47166836.50100@jippii.fi> <47167881.5050902@jippii.fi> Message-ID: <471681C0.1050004@genesilico.pl> Elmo M?ntynen wrote: Solution to the first problem: class BaseAppTestInheritance: def setup_class(cls): pass def test_foo(self): pass class AppTest(BaseAppTestInheritance): def setup_class(cls): BaseAppTestInheritance.setup_class.im_func(cls) (im_func is here a trick). That's python fault/feature in my opinion. Cheers, fijal :. From elmo13 at jippii.fi Thu Oct 18 00:09:25 2007 From: elmo13 at jippii.fi (=?UTF-8?B?RWxtbyBNw6RudHluZW4=?=) Date: Thu, 18 Oct 2007 01:09:25 +0300 Subject: [pypy-dev] Some issues with the testing framework In-Reply-To: <47167881.5050902@jippii.fi> References: <47166836.50100@jippii.fi> <47167881.5050902@jippii.fi> Message-ID: <47168815.40906@jippii.fi> Now I got that traceback I have gotten so many times: Traceback (most recent call last): File "/home/drayko/Workfolder/Security/Python/cvs/py-dist/py/bin/py.test", line 4, in ? py.test.cmdline.main() File "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/cmdline.py", line 15, in main failures = session.main() File "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/session.py", line 67, in main self.footer(colitems) File "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/terminal/terminal.py", line 167, in footer self.failures() File "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/terminal/terminal.py", line 262, in failures self.repr_failure(colitem, outcome) File "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/terminal/terminal.py", line 280, in repr_failure handler(item, excinfo, traceback, lambda : self.repr_out_err(item)) File "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/representation.py", line 146, in repr_failure_tbshort self.out.line(' File "%s", line %d, in %s' % ( File "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/code/traceback2.py", line 94, in name return self.frame.code.raw.co_name AttributeError: 'str' object has no attribute 'co_name' Elmo M?ntynen wrote: > Of course, now I py.test behaves with --tb=short, might have been my > fault after all:). > > Apparently, all of the stuff below but the first aren't bugs. > > Elmo > > Elmo M?ntynen wrote: > >> Using --tb=short has propably always crashed (with a failing test). >> >> ... >> From elmo13 at jippii.fi Thu Oct 18 00:37:55 2007 From: elmo13 at jippii.fi (=?UTF-8?B?RWxtbyBNw6RudHluZW4=?=) Date: Thu, 18 Oct 2007 01:37:55 +0300 Subject: [pypy-dev] Some issues with the testing framework In-Reply-To: <47168815.40906@jippii.fi> References: <47166836.50100@jippii.fi> <47167881.5050902@jippii.fi> <47168815.40906@jippii.fi> Message-ID: <47168EC3.3030406@jippii.fi> I get the crash if the first test in a bunch fails. Elmo M?ntynen wrote: > Now I got that traceback I have gotten so many times: > > Traceback (most recent call last): > File > "/home/drayko/Workfolder/Security/Python/cvs/py-dist/py/bin/py.test", > line 4, in ? > py.test.cmdline.main() > File > "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/cmdline.py", > line 15, in main > failures = session.main() > File > "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/session.py", > line 67, in main > self.footer(colitems) > File > "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/terminal/terminal.py", > line 167, in footer > self.failures() > File > "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/terminal/terminal.py", > line 262, in failures > self.repr_failure(colitem, outcome) > File > "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/terminal/terminal.py", > line 280, in repr_failure > handler(item, excinfo, traceback, lambda : self.repr_out_err(item)) > File > "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/test/representation.py", > line 146, in repr_failure_tbshort > self.out.line(' File "%s", line %d, in %s' % ( > File > "/home/drayko/Workfolder/Security/Python/pypy/pypy-dist2/py/code/traceback2.py", > line 94, in name > return self.frame.code.raw.co_name > AttributeError: 'str' object has no attribute 'co_name' > > Elmo M?ntynen wrote: > >> Of course, now I py.test behaves with --tb=short, might have been my >> fault after all:). >> >> Apparently, all of the stuff below but the first aren't bugs. >> >> Elmo >> >> Elmo M?ntynen wrote: >> >> >>> Using --tb=short has propably always crashed (with a failing test). >>> >>> ... >>> >>> > > From fijal at genesilico.pl Thu Oct 18 22:40:14 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Thu, 18 Oct 2007 22:40:14 +0200 Subject: [pypy-dev] py.test bisection algorithm In-Reply-To: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> References: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> Message-ID: <4717C4AE.4070201@genesilico.pl> Ondrej Certik wrote: > Hi, > > we are using py.test in SymPy and unfortunately, we have some bugs in > SymPy, that occurs when certain tests are run and don't occur when the > tests are run in different order. It's very time consuming to > determine which tests cause the problem (I did that several times by > hand). It occured to me that it should be possible to enhance py.test > by this facility to do it automatically. > > Example: > > 1) This passes: > > $ py.test sympy/series/tests/test_series.py -k issue409 > > This doesn't > > 2) $ py.test > > One problem is, that 2) runs for several minutes, another problem is > that I need to specify all tests on the command line and then deleting > some of them it see if it still fails, until I narrow the issue down, > usually quite nicely. Then I need to play with the "-k" parameter to > try different test cases in the file, until I determine the minimal > set of tests that, when executed in order, produce the error. > > This can by done automatically - the py.test will be given a set of > files (or just tests) that pass and another set that fails and it will > narrow the problem down, by bisecting. > > I would like to implement this in py.test. So I'll try my best and > send you a patch. If you have some ideas, that could help me, I am > interested. > > Thanks a lot, > Ondrej Hi Ondrej. Sorry for late reply. This mail should go to py-dev instead or at least also. This would cause faster reply (still my fault, I was offline for a while :) Anyway - very nice idea. The long-term goal for py.test is to support this algorithm ie. in respect to revisions (give me revision that broke test X) etc. So if you go for implementing this, would be very cool for many things. Lately I didn't invest too much time in py.test developement, but I would be really happy to review your patches and/or help you. You can find help most of the time on #pylib somehow (#pypy might work as well in case noone hangs around #pylib). Cheers, fijal :. From fijal at genesilico.pl Thu Oct 18 22:41:47 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Thu, 18 Oct 2007 22:41:47 +0200 Subject: [pypy-dev] py.test bisection algorithm In-Reply-To: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> References: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> Message-ID: <4717C50B.2080404@genesilico.pl> Ondrej Certik wrote: > > > Oh, and by the way. We've got boxed version of py.test (--box or sth, read --help), which forks for every test, so you're sure that every test is run in separate environment. (That doesn't solve your problem, but helps the other way around, when tests are run ok only when they're together). Cheers, fijal :. From ondrej at certik.cz Thu Oct 18 23:38:19 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Thu, 18 Oct 2007 23:38:19 +0200 Subject: [pypy-dev] py.test bisection algorithm In-Reply-To: <4717C50B.2080404@genesilico.pl> References: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> <4717C50B.2080404@genesilico.pl> Message-ID: <85b5c3130710181438q1ad40f22q8f48de328f886dc6@mail.gmail.com> Awesome, thanks a lot. Let's do it soon. There are more things - Kirill (another developer of SymPy) implemented a new feature: http://code.google.com/p/sympy/issues/detail?id=389 the relevant file is here: http://sympy.googlecode.com/svn/trunk/sympy/utilities/pytest.py and we would like to get it integrated to py.test. It works really well for us in the serial mode, but it doesn't yet work in the "py.test -d" mode. And now I found it doesn't work in the boxed mode, so it still needs some work. Another problem: "py.test -w" doesn't work in Debian, I reported a bug long time ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434226 But got no response. I am CCing to the Debian maintainer - if you don't have time to maintain the package, I can take over it, I have several python related packages in Debian already and I need the py.test to work correctly if possible. Another problem with "py.test -d" is that it fails for sympy, but "py.test" only works. This is related to my last email, so by implementing bisect at least in serial mode should help me to trace all those nasty bugs in sympy down. One nice feature would be for py.test to remember the order of tests in "py.test -d" - and if it fails, but succeeds in the serial mode, it should automatically bisect and tell me - hey, this test works fine, but if executed just after that test, it fails. Ondrej On 10/18/07, Maciek Fijalkowski wrote: > Ondrej Certik wrote: > > Hi, > > > > we are using py.test in SymPy and unfortunately, we have some bugs in > > SymPy, that occurs when certain tests are run and don't occur when the > > tests are run in different order. It's very time consuming to > > determine which tests cause the problem (I did that several times by > > hand). It occured to me that it should be possible to enhance py.test > > by this facility to do it automatically. > > > > Example: > > > > 1) This passes: > > > > $ py.test sympy/series/tests/test_series.py -k issue409 > > > > This doesn't > > > > 2) $ py.test > > > > One problem is, that 2) runs for several minutes, another problem is > > that I need to specify all tests on the command line and then deleting > > some of them it see if it still fails, until I narrow the issue down, > > usually quite nicely. Then I need to play with the "-k" parameter to > > try different test cases in the file, until I determine the minimal > > set of tests that, when executed in order, produce the error. > > > > This can by done automatically - the py.test will be given a set of > > files (or just tests) that pass and another set that fails and it will > > narrow the problem down, by bisecting. > > > > I would like to implement this in py.test. So I'll try my best and > > send you a patch. If you have some ideas, that could help me, I am > > interested. > > > > Thanks a lot, > > Ondrej > Hi Ondrej. > > Sorry for late reply. This mail should go to py-dev instead or at least > also. This would cause faster reply (still my fault, I was offline for a > while :) > > Anyway - very nice idea. The long-term goal for py.test is to support > this algorithm ie. in respect to revisions (give me revision that broke > test X) etc. So if you go for implementing this, would be very cool for > many things. Lately I didn't invest too much time in py.test > developement, but I would be really happy to review your patches and/or > help you. You can find help most of the time on #pylib somehow (#pypy > might work as well in case noone hangs around #pylib). > > Cheers, > fijal > > > :. > > On 10/18/07, Maciek Fijalkowski wrote: > Ondrej Certik wrote: > > > > > > > > Oh, and by the way. We've got boxed version of py.test (--box or sth, > read --help), which forks for every test, so you're sure that every test > is run in separate environment. (That doesn't solve your problem, but > helps the other way around, when tests are run ok only when they're > together). > > Cheers, > fijal > > > :. > > From fijal at genesilico.pl Fri Oct 19 09:37:58 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 19 Oct 2007 09:37:58 +0200 Subject: [pypy-dev] py.test bisection algorithm In-Reply-To: <85b5c3130710181438q1ad40f22q8f48de328f886dc6@mail.gmail.com> References: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> <4717C50B.2080404@genesilico.pl> <85b5c3130710181438q1ad40f22q8f48de328f886dc6@mail.gmail.com> Message-ID: <47185ED6.70003@genesilico.pl> Ondrej Certik wrote: > Awesome, thanks a lot. Let's do it soon. There are more things - > Kirill (another developer of SymPy) implemented a new feature: > > http://code.google.com/p/sympy/issues/detail?id=389 > > the relevant file is here: > > http://sympy.googlecode.com/svn/trunk/sympy/utilities/pytest.py > > and we would like to get it integrated to py.test. It works really > well for us in the serial mode, but it doesn't yet work in the > "py.test -d" mode. And now I found it doesn't work in the boxed mode, > so it still needs some work. > > Another problem: "py.test -w" doesn't work in Debian, I reported a bug > long time ago: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434226 > > But got no response. I am CCing to the Debian maintainer - if you > don't have time to maintain the package, I can take over it, I have > several python related packages in Debian already and I need the > py.test to work correctly if possible. > > Another problem with "py.test -d" is that it fails for sympy, but > "py.test" only works. This is related to my last email, so by > implementing bisect at least in serial mode should help me to trace > all those nasty bugs in sympy down. One nice feature would be for > py.test to remember the order of tests in "py.test -d" - and if it > fails, but succeeds in the serial mode, it should automatically bisect > and tell me - hey, this test works fine, but if executed just after > that test, it fails. > > Ondrej Ok, I'll take a look. Would be cool to have nice and working debian package, but indeed we're not good in packaging. Also, we would like to do 1.0 release at some point. The main blocker is some refactorings to-be-done (some internal unification) and eventually unittest support and/or cross-platform testing (like -d, but run every test per every platform). Cheers, fijal :. From ondrej at certik.cz Fri Oct 19 09:44:56 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Fri, 19 Oct 2007 09:44:56 +0200 Subject: [pypy-dev] py.test bisection algorithm In-Reply-To: <47185ED6.70003@genesilico.pl> References: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> <4717C50B.2080404@genesilico.pl> <85b5c3130710181438q1ad40f22q8f48de328f886dc6@mail.gmail.com> <47185ED6.70003@genesilico.pl> Message-ID: <85b5c3130710190044v182db0fem41b08d0ed6ee8288@mail.gmail.com> > Ok, I'll take a look. Would be cool to have nice and working debian > package, but indeed we're not good in packaging. Also, we would like to > do 1.0 release at some point. The main blocker is some refactorings > to-be-done (some internal unification) and eventually unittest support > and/or cross-platform testing (like -d, but run every test per every > platform). Guilherme wrote me that he orphaned the package, which means I can adopt it. So I'll try the svn and see if what works and what doesn't and then either I can package the svn version in Debian, or (preferably) you make a new release and I'll package that. Ondrej From fijal at genesilico.pl Fri Oct 19 09:52:11 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 19 Oct 2007 09:52:11 +0200 Subject: [pypy-dev] py.test bisection algorithm In-Reply-To: <85b5c3130710190044v182db0fem41b08d0ed6ee8288@mail.gmail.com> References: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> <4717C50B.2080404@genesilico.pl> <85b5c3130710181438q1ad40f22q8f48de328f886dc6@mail.gmail.com> <47185ED6.70003@genesilico.pl> <85b5c3130710190044v182db0fem41b08d0ed6ee8288@mail.gmail.com> Message-ID: <4718622B.60401@genesilico.pl> Ondrej Certik wrote: >> Ok, I'll take a look. Would be cool to have nice and working debian >> package, but indeed we're not good in packaging. Also, we would like to >> do 1.0 release at some point. The main blocker is some refactorings >> to-be-done (some internal unification) and eventually unittest support >> and/or cross-platform testing (like -d, but run every test per every >> platform). >> > > Guilherme wrote me that he orphaned the package, which means I can > adopt it. So I'll try the svn and see if what works and what doesn't > and then either I can package the svn version in Debian, or > (preferably) you make a new release and I'll package that. > > Ondrej > > :. > Not sure what is in the package, but the last release is 0.9 (I think package is like 0.7). Which means most of the stuff should work. I would not like to have svn package, we can always do 0.9.1 if you find nice stuff which works in svn, but doesn't in 0.9. But having 0.9 is still an improvement :-) Also we need to wait for holger to come back (should be soon). Cheers, fijal :. From ondrej at certik.cz Fri Oct 19 09:55:51 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Fri, 19 Oct 2007 09:55:51 +0200 Subject: [pypy-dev] py.test bisection algorithm In-Reply-To: <4718622B.60401@genesilico.pl> References: <85b5c3130710111729h62c1257ga268e432851ddea@mail.gmail.com> <4717C50B.2080404@genesilico.pl> <85b5c3130710181438q1ad40f22q8f48de328f886dc6@mail.gmail.com> <47185ED6.70003@genesilico.pl> <85b5c3130710190044v182db0fem41b08d0ed6ee8288@mail.gmail.com> <4718622B.60401@genesilico.pl> Message-ID: <85b5c3130710190055t5d2f01f3q80b00b99316a5f61@mail.gmail.com> On 10/19/07, Maciek Fijalkowski wrote: > Ondrej Certik wrote: > >> Ok, I'll take a look. Would be cool to have nice and working debian > >> package, but indeed we're not good in packaging. Also, we would like to > >> do 1.0 release at some point. The main blocker is some refactorings > >> to-be-done (some internal unification) and eventually unittest support > >> and/or cross-platform testing (like -d, but run every test per every > >> platform). > >> > > > > Guilherme wrote me that he orphaned the package, which means I can > > adopt it. So I'll try the svn and see if what works and what doesn't > > and then either I can package the svn version in Debian, or > > (preferably) you make a new release and I'll package that. > > > > Ondrej > > > > :. > > > Not sure what is in the package, but the last release is 0.9 (I think > package is like 0.7). Which means most of the stuff should work. I would > not like to have svn package, we can always do 0.9.1 if you find nice > stuff which works in svn, but doesn't in 0.9. Yes, that's the ideal solution. > But having 0.9 is still an > improvement :-) Also we need to wait for holger to come back (should be > soon). There is 0.9 in Debian, but as I wrote for example the "py.test -w" isn't working: $ wajig show python-codespeak-lib Package: python-codespeak-lib Priority: optional Section: python Installed-Size: 1680 Maintainer: Guilherme Salgado Architecture: i386 Source: codespeak-lib Version: 0.9.0-3.1 Replaces: python-pylib, python2.3-codespeak-lib, python2.4-codespeak-lib Provides: python2.4-codespeak-lib, python2.5-codespeak-lib Depends: python-central (>= 0.5.8), python (<< 2.6), python (>= 2.4), libc6 (>= 2.6.1-1) Recommends: python-tkinter, python-docutils Suggests: screen, rsync, graphviz, tetex-bin, gs-gpl | gs-esp, ps2eps, subversion Conflicts: python-pylib, python2.3-codespeak-lib, python2.4-codespeak-lib Filename: pool/main/c/codespeak-lib/python-codespeak-lib_0.9.0-3.1_i386.deb Size: 352534 MD5sum: c26760c4b5faf909755b00039206f083 SHA1: d3068c24477aa9b923decdc86d815f960355628b SHA256: ff742dd60a6de29ef2aa80473f16102c932a23f1d9d0da517862853a318147fa Description: The pylib library containing py.test, greenlets and other niceties It includes py.test, whose focus is to get a test environment that's easier to use than the existing ones, py.xml ("a fast'n'easy way to generate xml/html documents"), py.magic.greenlet ("Lightweight in-process concurrent programming") and many more features. . homepage: http://codespeak.net/py/ From arigo at tunes.org Sun Oct 21 12:53:03 2007 From: arigo at tunes.org (Armin Rigo) Date: Sun, 21 Oct 2007 12:53:03 +0200 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: <1192552256.4714e74018eec@webmail.mail.rice.edu> References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> Message-ID: <20071021105303.GA30423@code0.codespeak.net> Hi Raj, On Tue, Oct 16, 2007 at 11:30:56AM -0500, Raj wrote: > Well, for my previous problem, pypy-c on windows worked only when I ran > it in the installation directory, so I did copped out and ran my programs > by copying them over. Didn't really find a proper solution to the problem, > but I assume it involves setting some path variables. I'm confused. I tried downloading the file pypy-1.0.0-win32.zip and looked around (didn't test it on Windows myself though). The zip contains all the necessary standard library .py files, and I think that the paths you get in the zip are correct. In other words, if you run pypy-1.0.0\pypy-c.exe, it should pick up its stdlib at pypy-1.0.0\share\pypy-1.0\lib-python and pypy-1.0.0\share\pypy-1.0\pypy\lib. Of course it doesn't work if you try to move the .exe files elsewhere without also moving the 'share' subdirectory there. However, as I said this is untested, so something might be going wrong. A bientot, Armin. From arigo at tunes.org Sun Oct 21 13:08:31 2007 From: arigo at tunes.org (Armin Rigo) Date: Sun, 21 Oct 2007 13:08:31 +0200 Subject: [pypy-dev] Some issues with the testing framework In-Reply-To: <47168EC3.3030406@jippii.fi> References: <47166836.50100@jippii.fi> <47167881.5050902@jippii.fi> <47168815.40906@jippii.fi> <47168EC3.3030406@jippii.fi> Message-ID: <20071021110831.GB30423@code0.codespeak.net> Hi Elmo, Indeed, it seems that we didn't try --tb=short with app-level tests. It crashes for me too. Not sure I want to investigate as it seems that nobody used --tb=short enough to notice so far... It works fine on interp-level tests. Armin From fijal at genesilico.pl Sun Oct 21 13:17:48 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sun, 21 Oct 2007 13:17:48 +0200 Subject: [pypy-dev] Some issues with the testing framework In-Reply-To: <20071021110831.GB30423@code0.codespeak.net> References: <47166836.50100@jippii.fi> <47167881.5050902@jippii.fi> <47168815.40906@jippii.fi> <47168EC3.3030406@jippii.fi> <20071021110831.GB30423@code0.codespeak.net> Message-ID: <471B355C.6070308@genesilico.pl> Armin Rigo wrote: > Hi Elmo, > > Indeed, it seems that we didn't try --tb=short with app-level tests. It > crashes for me too. Not sure I want to investigate as it seems that > nobody used --tb=short enough to notice so far... It works fine on > interp-level tests. > > > Armin > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > > :. > > Might be worth noticing. I'm trying to refactor py.test on a huge scale. This means that few things will change in API when subclassing Session, hence applevel tests would need some refactorings as well (probably not too much, but still). This might solve the problem as a side effect. :. From rajb at rice.edu Sun Oct 21 15:55:12 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Sun, 21 Oct 2007 08:55:12 -0500 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: <20071021105303.GA30423@code0.codespeak.net> References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> <20071021105303.GA30423@code0.codespeak.net> Message-ID: Hi Armin It only worked for me when I cd'ed to the pypy-1.0.0 directory and ran pypy-c there. When I added pypy-1.0.0 to my path and ran pypy-c from somewhere else, it gave me errors saying that some modules are not found. This could definitely be a result of my inexperience with windows, but if you get a chance, please do test it out. Thanks! Raj On Oct 21, 2007, at 5:53 AM, Armin Rigo wrote: > Hi Raj, > > On Tue, Oct 16, 2007 at 11:30:56AM -0500, Raj wrote: >> Well, for my previous problem, pypy-c on windows worked only when >> I ran >> it in the installation directory, so I did copped out and ran my >> programs >> by copying them over. Didn't really find a proper solution to the >> problem, >> but I assume it involves setting some path variables. > > I'm confused. I tried downloading the file pypy-1.0.0-win32.zip and > looked around (didn't test it on Windows myself though). The zip > contains all the necessary standard library .py files, and I think > that > the paths you get in the zip are correct. In other words, if you run From exarkun at divmod.com Sun Oct 21 17:11:23 2007 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Sun, 21 Oct 2007 11:11:23 -0400 Subject: [pypy-dev] Some issues with the testing framework In-Reply-To: <20071021110831.GB30423@code0.codespeak.net> Message-ID: <20071021151123.8162.1112898290.divmod.quotient.25966@ohm> On Sun, 21 Oct 2007 13:08:31 +0200, Armin Rigo wrote: >Hi Elmo, > >Indeed, it seems that we didn't try --tb=short with app-level tests. It >crashes for me too. Not sure I want to investigate as it seems that >nobody used --tb=short enough to notice so far... It works fine on >interp-level tests. > fwiw, I noticed :P Jean-Paul From fijal at genesilico.pl Sun Oct 21 17:28:58 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sun, 21 Oct 2007 17:28:58 +0200 Subject: [pypy-dev] Strange optimisation Message-ID: <471B703A.9030706@genesilico.pl> Here is proposed diff: http://paste.pocoo.org/show/6990 I think it doesn't really crash anything (no tests failing), nor has any performance impact, but who knows... I would like someone to review that patch. Basically, half of the time spend in inline helpers is spend in cleanup_graph, which imho can be performed less often. Cheers, fijal :. From len-l at telus.net Sun Oct 21 19:01:39 2007 From: len-l at telus.net (Lenard Lindstrom) Date: Sun, 21 Oct 2007 10:01:39 -0700 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> <20071021105303.GA30423@code0.codespeak.net> Message-ID: <471B85F3.1030700@telus.net> My guess is the pypy-c considers the current directory as its root directory. This differs from Cpython which uses a registry entry. Raj Bandyopadhyay wrote: > Hi Armin > > It only worked for me when I cd'ed to the pypy-1.0.0 directory and > ran pypy-c there. > When I added pypy-1.0.0 to my path and ran pypy-c from somewhere > else, it gave me errors saying that some modules are not found. This > could definitely be a result of my inexperience with windows, but if > you get a chance, please do test it out. > > Thanks! > Raj > > On Oct 21, 2007, at 5:53 AM, Armin Rigo wrote: > > >> Hi Raj, >> >> On Tue, Oct 16, 2007 at 11:30:56AM -0500, Raj wrote: >> >>> Well, for my previous problem, pypy-c on windows worked only when >>> I ran >>> it in the installation directory, so I did copped out and ran my >>> programs >>> by copying them over. Didn't really find a proper solution to the >>> problem, >>> but I assume it involves setting some path variables. >>> >> I'm confused. I tried downloading the file pypy-1.0.0-win32.zip and >> looked around (didn't test it on Windows myself though). The zip >> contains all the necessary standard library .py files, and I think >> that >> the paths you get in the zip are correct. In other words, if you run >> > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- Lenard Lindstrom From fijal at genesilico.pl Sun Oct 21 19:52:59 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sun, 21 Oct 2007 19:52:59 +0200 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: <471B85F3.1030700@telus.net> References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> <20071021105303.GA30423@code0.codespeak.net> <471B85F3.1030700@telus.net> Message-ID: <471B91FB.8030504@genesilico.pl> Lenard Lindstrom wrote: > My guess is the pypy-c considers the current directory as its root > directory. This differs from Cpython which uses a registry entry. > The truth is that: 1. We didn't decide yet how to handle interaction with cpython library (use the same place, use different place, link somewhere) 2. We don't have a single windows developer which means that we don't experience such things on a day-to-day basis (and pypy source code is changing very rapidly, which means it's hard to follow). Cheers, fijal :. From fijal at genesilico.pl Sun Oct 21 19:54:36 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sun, 21 Oct 2007 19:54:36 +0200 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: <471B91FB.8030504@genesilico.pl> References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> <20071021105303.GA30423@code0.codespeak.net> <471B85F3.1030700@telus.net> <471B91FB.8030504@genesilico.pl> Message-ID: <471B925C.1040707@genesilico.pl> Maciek Fijalkowski wrote: > Lenard Lindstrom wrote: > >> My guess is the pypy-c considers the current directory as its root >> directory. This differs from Cpython which uses a registry entry. >> >> > The truth is that: > 1. We didn't decide yet how to handle interaction with cpython library > (use the same place, use different place, link somewhere) > 2. We don't have a single windows developer which means that we don't > experience such things on a day-to-day basis (and pypy source code is > changing very rapidly, which means it's hard to follow). > > > Cheers, > fijal > In short - yes, you're right :) :. From tismer at stackless.com Mon Oct 22 02:59:00 2007 From: tismer at stackless.com (Christian Tismer) Date: Mon, 22 Oct 2007 02:59:00 +0200 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: <20071021105303.GA30423@code0.codespeak.net> References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> <20071021105303.GA30423@code0.codespeak.net> Message-ID: <471BF5D4.9020601@stackless.com> Armin Rigo wrote: > Hi Raj, > > On Tue, Oct 16, 2007 at 11:30:56AM -0500, Raj wrote: >> Well, for my previous problem, pypy-c on windows worked only when I ran >> it in the installation directory, so I did copped out and ran my programs >> by copying them over. Didn't really find a proper solution to the problem, >> but I assume it involves setting some path variables. > > I'm confused. I tried downloading the file pypy-1.0.0-win32.zip and > looked around (didn't test it on Windows myself though). The zip > contains all the necessary standard library .py files, and I think that > the paths you get in the zip are correct. In other words, if you run > pypy-1.0.0\pypy-c.exe, it should pick up its stdlib at > pypy-1.0.0\share\pypy-1.0\lib-python and > pypy-1.0.0\share\pypy-1.0\pypy\lib. Of course it doesn't work if you > try to move the .exe files elsewhere without also moving the 'share' > subdirectory there. However, as I said this is untested, so something > might be going wrong. I tested this right now. D:\tmp\pypy-1.0.0-win32\pypy-1.0.0>pypy-c Python 2.4.1 (pypy 1.0.0 build 41438) on win32 Type "help", "copyright", "credits" or "license" for more information. >>>> import pickle >>>> pickle.__file__ 'D:\\tmp\\pypy-1.0.0-win32\\pypy-1.0.0\\share\\pypy-1.0\\lib-python\\modified-2.4.1\\pickle.py' >>>> Tried it from a different folder as well: D:\tmp\pypy-1.0.0-win32\pypy-1.0.0>cd \pypy D:\pypy>\tmp\pypy-1.0.0-win32\pypy-1.0.0\pypy-c.exe Python 2.4.1 (pypy 1.0.0 build 41438) on win32 Type "help", "copyright", "credits" or "license" for more information. >>>> import pickle >>>> pickle.__file__ '\\tmp\\pypy-1.0.0-win32\\pypy-1.0.0\\share\\pypy-1.0\\lib-python\\modified-2.4.1\\pickle.pyc' >>>> Looks all pretty good so far. What else should I try for validation? The basic stuff appears to be in place. 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 rajb at rice.edu Mon Oct 22 03:17:44 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Sun, 21 Oct 2007 20:17:44 -0500 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: <471BF5D4.9020601@stackless.com> References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> <20071021105303.GA30423@code0.codespeak.net> <471BF5D4.9020601@stackless.com> Message-ID: Hmmm, which windows OS are you using. Mine's a windows XP. OK, so you invoked pypy-c using the full pathname of the executable? I tried it by adding the pypy-1.0.0 to the system PATH variable and just using 'pypy-c'. I should have tried it your way :headdesk: :) Raj On Oct 21, 2007, at 7:59 PM, Christian Tismer wrote: > I tested this right now. > > D:\tmp\pypy-1.0.0-win32\pypy-1.0.0>pypy-c > Python 2.4.1 (pypy 1.0.0 build 41438) on win32 > Type "help", "copyright", "credits" or "license" for more information. >>>>> import pickle >>>>> pickle.__file__ > 'D:\\tmp\\pypy-1.0.0-win32\\pypy-1.0.0\\share\\pypy-1.0\\lib-python\ > \modified-2.4.1\\pickle.py' >>>>> > > Tried it from a different folder as well: > > D:\tmp\pypy-1.0.0-win32\pypy-1.0.0>cd \pypy > > D:\pypy>\tmp\pypy-1.0.0-win32\pypy-1.0.0\pypy-c.exe > Python 2.4.1 (pypy 1.0.0 build 41438) on win32 > Type "help", "copyright", "credits" or "license" for more information. >>>>> import pickle >>>>> pickle.__file__ > '\\tmp\\pypy-1.0.0-win32\\pypy-1.0.0\\share\\pypy-1.0\\lib-python\ > \modified-2.4.1\\pickle.pyc' >>>>> > > Looks all pretty good so far. > > What else should I try for validation? > The basic stuff appears to be in place. > > cheers - chris 'Sam, how far do we have to go?' 'I don't know, Mr. Frodo', said Sam 'because I don't know where we're going'. -- JRR Tolkien, Return of the King -------------- next part -------------- An HTML attachment was scrubbed... URL: From tismer at stackless.com Mon Oct 22 04:08:24 2007 From: tismer at stackless.com (Christian Tismer) Date: Mon, 22 Oct 2007 04:08:24 +0200 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> <20071021105303.GA30423@code0.codespeak.net> <471BF5D4.9020601@stackless.com> Message-ID: <471C0618.7070905@stackless.com> Raj Bandyopadhyay wrote: > Hmmm, which windows OS are you using. Mine's a windows XP. Of course. > OK, so you invoked pypy-c using the full pathname of the executable? > I tried it by adding the pypy-1.0.0 to the system PATH variable and just > using 'pypy-c'. I should have tried it your way :headdesk: :) Trying your way as well... Ok. I added D:\tmp\pypy-1.0.0-win32\pypy-1.0.0 to the system's path variable. let's see (after restarting the DOS shell with the changed environ, of course): C:\Dokumente und Einstellungen\tismer.MACGYVERXP>cd d:\ C:\Dokumente und Einstellungen\tismer.MACGYVERXP>pypy-c.exe debug: WARNING: library path not found, using compiled-in sys.path Python 2.4.1 (pypy 1.0.0 build 46843) on win32 Type "help", "copyright", "credits" or "license" for more information. >>>> import pickle >>>> pickle.__file__ 'd:\\pypy\\dist\\lib-python\\modified-2.4.1\\pickle.pyc' >>>> You are right!!! This comes from my active pypy check-out, not from the package that you downloaded. So I have to say: you are right! PyPy does not behave correctly on windows. Please take my deepest apologies for not testing this enough. We will figure this out, ASAP, and supply a patch. Armin, sorry about that, but he is just right with his complaint. 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 Mon Oct 22 10:45:27 2007 From: arigo at tunes.org (Armin Rigo) Date: Mon, 22 Oct 2007 10:45:27 +0200 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> <20071021105303.GA30423@code0.codespeak.net> Message-ID: <20071022084527.GA19426@code0.codespeak.net> Hi Raj, On Sun, Oct 21, 2007 at 08:55:12AM -0500, Raj Bandyopadhyay wrote: > It only worked for me when I cd'ed to the pypy-1.0.0 directory and > ran pypy-c there. > When I added pypy-1.0.0 to my path and ran pypy-c from somewhere > else, it gave me errors saying that some modules are not found. This > could definitely be a result of my inexperience with windows, but if > you get a chance, please do test it out. Ok. For anyone interested in helping out, the relevant code is in translator/goal/app_main.py. In particular, on Unix at least, the 10 first lines of entry_point() look if sys.argv[0] contains no '/' and if so search along the $PATH for the likely full path to the executable. After a quick look the same code appears ok for Windows too, but clearly something goes wrong somewhere. A way to check if these 10 lines worked is to print sys.executable from the command-line of pypy-c. A bientot, Armin From tismer at stackless.com Mon Oct 22 17:03:52 2007 From: tismer at stackless.com (Christian Tismer) Date: Mon, 22 Oct 2007 17:03:52 +0200 Subject: [pypy-dev] pypy-c and JIT In-Reply-To: <20071022084527.GA19426@code0.codespeak.net> References: <0D94C2EC-3793-42B4-A4FE-11735D839DD6@rice.edu> <4714C638.5000403@stackless.com> <1192552256.4714e74018eec@webmail.mail.rice.edu> <20071021105303.GA30423@code0.codespeak.net> <20071022084527.GA19426@code0.codespeak.net> Message-ID: <471CBBD8.8020802@stackless.com> Armin Rigo wrote: > Hi Raj, > > On Sun, Oct 21, 2007 at 08:55:12AM -0500, Raj Bandyopadhyay wrote: >> It only worked for me when I cd'ed to the pypy-1.0.0 directory and >> ran pypy-c there. >> When I added pypy-1.0.0 to my path and ran pypy-c from somewhere >> else, it gave me errors saying that some modules are not found. This >> could definitely be a result of my inexperience with windows, but if >> you get a chance, please do test it out. > > Ok. For anyone interested in helping out, the relevant code is in > translator/goal/app_main.py. In particular, on Unix at least, the 10 > first lines of entry_point() look if sys.argv[0] contains no '/' and if > so search along the $PATH for the likely full path to the executable. > After a quick look the same code appears ok for Windows too, but clearly > something goes wrong somewhere. A way to check if these 10 lines worked > is to print sys.executable from the command-line of pypy-c. Ok, I checked again. One fault of mine was that I happened to have another pypy-c.exe executable around. So actually, I now also crash with the import errors. Python 2.4.1 (pypy 1.0.0 build 41438) on win32 Type "help", "copyright", "credits" or "license" for more information. Error calling sys.excepthook: debug: OperationError: debug: operror-type: ImportError debug: operror-value: No module named traceback Then I tested what you said from the command line: C:\Dokumente und Einstellungen\tismer.MACGYVERXP>pypy-c.exe -c "import sys; print sys.executable" debug: WARNING: library path not found, using compiled-in sys.path C:\Dokumente und Einstellungen\tismer.MACGYVERXP\pypy-c.exe This is in fact nonsense, the executable came from the temp directory mentioned before, all other pypy-c's were removed. So something is wrong, and I'm looking into this. 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 rajb at rice.edu Mon Oct 22 18:14:07 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Mon, 22 Oct 2007 11:14:07 -0500 Subject: [pypy-dev] Compiling pypy-c on Linux Message-ID: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> Hi all Looks like I'm the one with all the complaints :) Thanks for investigating the Windows issues! I'm trying to compile pypy-c on a Linux/x86 machine, and running into all sorts of errors. Following the instructions in the getting- started document, I installed ctypes, pygame and graphviz. After that I run the translator tool and get the following errors. Any ideas what I might be missing? Thanks Raj bash-2.05b$ /local/python/bin/python translate.py --run --text targetpypystandalone.py [translation:info] Translating target as defined by targetpypystandalone [translation] PyPy config object: [translation] [objspace] [translation] compiler = ast [translation] nofaking = True [translation] [usemodules] [translation] errno = True [translation] posix = True [translation] time = True --- beginning of app_example.py --- 42 --- end of app_example.py --- [translation] translate.py configuration: [translation] [translate] [translation] [goal_options] [translation] run = True [translation] targetspec = targetpypystandalone [translation] text = True [translation] translation configuration: [translation] [translation] [translation:info] Annotating&simplifying... [translation:info] with policy: pypy.translator.goal.ann_override.PyPyAnnotatorPolicy ++++++++++++++***********************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%% ######################################################################## #####%%%%%%%%%*********** ++++++++++++********************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%##%%% ######################################################################## ####%%%%%%%%%%%%%%******** ++++++++++*******************%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%% ######################################################################## ###########%%%%%%%%%%%%%%%%%****** ++++++++******************%%%#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%% ######################################################################## ###########%%%%%%%#%%%%%%%%%%*** ++++++*****************%%%%%####%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%#% ################################################################### [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "translate.py", line 287, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/translator/ driver.py", line 709, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/translator/ tool/taskengine.py", line 112, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/translator/ driver.py", line 260, in _do [translation:ERROR] res = func() [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/translator/ driver.py", line 279, in task_annotate [translation:ERROR] s = annotator.build_types(self.entry_point, self.inputtypes) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ annrpython.py", line 101, in build_types [translation:ERROR] return self.build_graph_types(flowgraph, inputcells, complete_now=complete_now) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ annrpython.py", line 192, in build_graph_types [translation:ERROR] self.complete() [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ annrpython.py", line 248, in complete [translation:ERROR] self.processblock(graph, block) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ annrpython.py", line 477, in processblock [translation:ERROR] self.flowin(graph, block) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ annrpython.py", line 537, in flowin [translation:ERROR] self.consider_op(block.operations[i]) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ annrpython.py", line 739, in consider_op [translation:ERROR] raise_nicer_exception(op, str(graph)) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ annrpython.py", line 736, in consider_op [translation:ERROR] resultcell = consider_meth(*argcells) [translation:ERROR] File "", line 3, in consider_op_simple_call [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ unaryop.py", line 166, in simple_call [translation:ERROR] return obj.call(getbookkeeper().build_args ("simple_call", args_s)) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ unaryop.py", line 597, in call [translation:ERROR] return bookkeeper.pbc_call(pbc, args) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ bookkeeper.py", line 641, in pbc_call [translation:ERROR] results.append(desc.pycall(schedule, args, s_previous_result)) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ description.py", line 266, in pycall [translation:ERROR] result = self.specialize(inputcells) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ description.py", line 262, in specialize [translation:ERROR] return self.specializer(self, inputcells) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ specialize.py", line 64, in default_specialize [translation:ERROR] return funcdesc.cachedgraph(key, alt_name=alt_name) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ description.py", line 227, in cachedgraph [translation:ERROR] graph = self.buildgraph(alt_name, builder) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/annotation/ description.py", line 194, in buildgraph [translation:ERROR] graph = translator.buildflowgraph(self.pyobj) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/translator/ translator.py", line 77, in buildflowgraph [translation:ERROR] graph = space.build_flow(func) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/objspace/ flow/objspace.py", line 261, in build_flow [translation:ERROR] ec.build_flow() [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/objspace/ flow/flowcontext.py", line 302, in build_flow [translation:ERROR] self.mergeblock(e.block, e.currentstate) [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/objspace/ flow/flowcontext.py", line 348, in mergeblock [translation:ERROR] finished = newstate == block.framestate [translation:ERROR] File "/local/rajb/pypy-1.0.0/pypy/objspace/ flow/framestate.py", line 76, in __eq__ [translation:ERROR] assert len(self.mergeable) == len (other.mergeable) [translation:ERROR] AssertionError': [translation:ERROR] .. v4 = simple_call(v0, space_0, v1, v2, v3) [translation:ERROR] .. '(?:2) BuiltinActivation_UwS_ObjSpace_W_Root_W_Root_W_Root._run_UWS_ObjSpace_W_ Root_W_Root_W_Root' [translation:ERROR] Processing block: [translation:ERROR] block at 3 is a [translation:ERROR] in (?:2) BuiltinActivation_UwS_ObjSpace_W_Root_W_Root_W_Root._run_UWS_ObjSpace_W_ Root_W_Root_W_Root [translation:ERROR] containing the following operations: [translation:ERROR] v0 = getattr(self_0, ('behavior')) [translation:ERROR] v1 = getitem(scope_w_0, (0)) [translation:ERROR] v2 = getitem(scope_w_0, (1)) [translation:ERROR] v3 = getitem(scope_w_0, (2)) [translation:ERROR] v4 = simple_call(v0, space_0, v1, v2, v3) [translation:ERROR] --end-- [translation] start debugger... > /local/rajb/pypy-1.0.0/pypy/objspace/flow/framestate.py(76)__eq__() -> assert len(self.mergeable) == len(other.mergeable) (Pdb+) From fijal at genesilico.pl Mon Oct 22 18:38:31 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 22 Oct 2007 18:38:31 +0200 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> Message-ID: <471CD207.1090907@genesilico.pl> Raj Bandyopadhyay wrote: > Hi all > > Looks like I'm the one with all the complaints :) Thanks for > investigating the Windows issues! > > I'm trying to compile pypy-c on a Linux/x86 machine, and running into > all sorts of errors. Following the instructions in the getting- > started document, I installed ctypes, pygame and graphviz. After that > I run the translator tool and get the following errors. Any ideas > what I might be missing? > > Thanks > Raj > Casual question - what version of pypy are you trying? Try svn checkout (I don't think it's very recent checkout what you have, although I'm not sure) Cheers, fijal :. From rajb at rice.edu Mon Oct 22 19:21:04 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Mon, 22 Oct 2007 12:21:04 -0500 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <471CD207.1090907@genesilico.pl> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> Message-ID: <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> I'll try it and let you know. I downloaded to pypy-1.0.0 distribution tarball. Thanks Raj On Oct 22, 2007, at 11:38 AM, Maciek Fijalkowski wrote: > Raj Bandyopadhyay wrote: >> Hi all >> >> Looks like I'm the one with all the complaints :) Thanks for >> investigating the Windows issues! >> >> I'm trying to compile pypy-c on a Linux/x86 machine, and running >> into all sorts of errors. Following the instructions in the >> getting- started document, I installed ctypes, pygame and >> graphviz. After that I run the translator tool and get the >> following errors. Any ideas what I might be missing? >> >> Thanks >> Raj >> From tismer at stackless.com Mon Oct 22 20:21:17 2007 From: tismer at stackless.com (Christian Tismer) Date: Mon, 22 Oct 2007 20:21:17 +0200 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> Message-ID: <471CEA1D.2010509@stackless.com> Raj Bandyopadhyay wrote: > I'll try it and let you know. I downloaded to pypy-1.0.0 distribution > tarball. We also would like to know which version of CPython you have. 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 rajb at rice.edu Mon Oct 22 21:07:16 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Mon, 22 Oct 2007 14:07:16 -0500 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <471CEA1D.2010509@stackless.com> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> Message-ID: I have Python 2.5.1. I have currently downloaded the latest pypy from subversion, and it seems to be compiling happily for the last 10 mins or so. Raj On Oct 22, 2007, at 1:21 PM, Christian Tismer wrote: > Raj Bandyopadhyay wrote: >> I'll try it and let you know. I downloaded to pypy-1.0.0 >> distribution tarball. > > We also would like to know which version of CPython you have. > > cheers - chris > From cfbolz at gmx.de Mon Oct 22 22:03:10 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 22 Oct 2007 22:03:10 +0200 Subject: [pypy-dev] pypy-squeak sprint blog Message-ID: <348899050710221303m79da53a6s4376dd276a9d01d7@mail.gmail.com> hi all! So it seem that (as mention in the first entry) smalltalkers are more used to rss feeds and blogs than to mails on mailing lists, so Adrian Kuhn and me have just started a blog about the PyPy-Squeak sprint in Bern here: http://pypysqueak.blogspot.com/ Cheers, Carl Friedrich From rajb at rice.edu Tue Oct 23 01:21:03 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Mon, 22 Oct 2007 18:21:03 -0500 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <471CEA1D.2010509@stackless.com> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> Message-ID: <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> Ok, the compilation failed after quite a while. I have attached the output file of the compilation process. It seems to have failed on some simple C undeclared-variable error. Thanks Raj -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: errors.txt URL: -------------- next part -------------- On Oct 22, 2007, at 1:21 PM, Christian Tismer wrote: > Raj Bandyopadhyay wrote: >> I'll try it and let you know. I downloaded to pypy-1.0.0 >> distribution tarball. > > We also would like to know which version of CPython you have. > > cheers - chris From fijal at genesilico.pl Tue Oct 23 01:50:13 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Tue, 23 Oct 2007 01:50:13 +0200 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> Message-ID: <471D3735.2000704@genesilico.pl> Raj Bandyopadhyay wrote: > Ok, the compilation failed after quite a while. I have attached the > output file of the compilation process. It seems to have failed on > some simple C undeclared-variable error. > > Thanks > Raj > You don't have boehm (devel version) installed. Install it, go to /tmp/usession-/testing_1/ and type make. You'll have your pypy-c under name testing_1 :. From tismer at stackless.com Tue Oct 23 02:51:57 2007 From: tismer at stackless.com (Christian Tismer) Date: Tue, 23 Oct 2007 02:51:57 +0200 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> Message-ID: <471D45AD.4050709@stackless.com> Raj Bandyopadhyay wrote: > Ok, the compilation failed after quite a while. I have attached the > output file of the compilation process. It seems to have failed on some > simple C undeclared-variable error. Great result, so far. Compiling pypy should alas not be done without reading the getting started document. Either set the gc to something different, or install the boehm gc source package. 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 fijal at genesilico.pl Tue Oct 23 11:15:30 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Tue, 23 Oct 2007 11:15:30 +0200 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <87DA5A5D-568D-4D48-B2CD-71502AFBB613@rice.edu> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> <471D45AD.4050709@stackless.com> <87DA5A5D-568D-4D48-B2CD-71502AFBB613@rice.edu> Message-ID: <471DBBB2.1000702@genesilico.pl> Raj Bandyopadhyay wrote: > Hmm, I have installed the gc already, but maybe the library path is > not set correctly. lemme try changing that & I'll let you guys know > what happens. > > Thanks > Raj Libgc might be there, but header aren't (developement version of lib) :. From rajb at rice.edu Tue Oct 23 04:45:10 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Mon, 22 Oct 2007 21:45:10 -0500 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <471D45AD.4050709@stackless.com> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> <471D45AD.4050709@stackless.com> Message-ID: <87DA5A5D-568D-4D48-B2CD-71502AFBB613@rice.edu> Hmm, I have installed the gc already, but maybe the library path is not set correctly. lemme try changing that & I'll let you guys know what happens. Thanks Raj On Oct 22, 2007, at 7:51 PM, Christian Tismer wrote: > Raj Bandyopadhyay wrote: >> Ok, the compilation failed after quite a while. I have attached >> the output file of the compilation process. It seems to have >> failed on some simple C undeclared-variable error. > > Great result, so far. > > Compiling pypy should alas not be done without reading the > getting started document. > Either set the gc to something different, or install the boehm > gc source package. > > cheers - chris From rajb at rice.edu Tue Oct 23 16:45:29 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Tue, 23 Oct 2007 09:45:29 -0500 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <471DBBB2.1000702@genesilico.pl> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> <471D45AD.4050709@stackless.com> <87DA5A5D-568D-4D48-B2CD-71502AFBB613@rice.edu> <471DBBB2.1000702@genesilico.pl> Message-ID: Yes, that's the problem, in fact. Stupid question, but how (or where) do I set the include path for the C compiler to find the header? I can't find anything resembling a Makefile. Thanks again! Raj On Oct 23, 2007, at 4:15 AM, Maciek Fijalkowski wrote: > Raj Bandyopadhyay wrote: >> Hmm, I have installed the gc already, but maybe the library path >> is not set correctly. lemme try changing that & I'll let you guys >> know what happens. >> >> Thanks >> Raj > Libgc might be there, but header aren't (developement version of lib) > > :. From tismer at stackless.com Tue Oct 23 16:56:00 2007 From: tismer at stackless.com (Christian Tismer) Date: Tue, 23 Oct 2007 16:56:00 +0200 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> <471D45AD.4050709@stackless.com> <87DA5A5D-568D-4D48-B2CD-71502AFBB613@rice.edu> <471DBBB2.1000702@genesilico.pl> Message-ID: <471E0B80.1010403@stackless.com> Raj Bandyopadhyay wrote: > Yes, that's the problem, in fact. Stupid question, but how (or where) > do I set the include path for the C compiler to find the header? I > can't find anything resembling a Makefile. If you are on debian, just install the source package apt-get install libgc-dev This installs the header files into common directories like /usr/lib 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 rajb at rice.edu Tue Oct 23 16:57:55 2007 From: rajb at rice.edu (Raj Bandyopadhyay) Date: Tue, 23 Oct 2007 09:57:55 -0500 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <471E0B80.1010403@stackless.com> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> <471D45AD.4050709@stackless.com> <87DA5A5D-568D-4D48-B2CD-71502AFBB613@rice.edu> <471DBBB2.1000702@genesilico.pl> <471E0B80.1010403@stackless.com> Message-ID: I don't have admin perms on the machine I'm using :( Raj On Oct 23, 2007, at 9:56 AM, Christian Tismer wrote: > Raj Bandyopadhyay wrote: >> Yes, that's the problem, in fact. Stupid question, but how (or >> where) do I set the include path for the C compiler to find the >> header? I can't find anything resembling a Makefile. > > If you are on debian, just install the source package > > apt-get install libgc-dev > > This installs the header files into common directories > like /usr/lib > > cheers - chris From simon at arrowtheory.com Tue Oct 23 17:04:55 2007 From: simon at arrowtheory.com (Simon Burton) Date: Tue, 23 Oct 2007 08:04:55 -0700 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> <471D45AD.4050709@stackless.com> <87DA5A5D-568D-4D48-B2CD-71502AFBB613@rice.edu> <471DBBB2.1000702@genesilico.pl> Message-ID: <20071023080455.505f009c.simon@arrowtheory.com> On Tue, 23 Oct 2007 09:45:29 -0500 Raj Bandyopadhyay wrote: > > Yes, that's the problem, in fact. Stupid question, but how (or where) > do I set the include path for the C compiler to find the header? I > can't find anything resembling a Makefile. there is a Makefile somewhere here: /tmp/usession-* Simon. From tismer at stackless.com Tue Oct 23 17:16:20 2007 From: tismer at stackless.com (Christian Tismer) Date: Tue, 23 Oct 2007 17:16:20 +0200 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> <471D45AD.4050709@stackless.com> <87DA5A5D-568D-4D48-B2CD-71502AFBB613@rice.edu> <471DBBB2.1000702@genesilico.pl> <471E0B80.1010403@stackless.com> Message-ID: <471E1044.4050500@stackless.com> Raj Bandyopadhyay wrote: > I don't have admin perms on the machine I'm using :( Then either ask your sysop to install it, or get the source distro, build it locally, and then you are slightly on your own. One proposal from #pypy was to just run the translation and let compilation crash (this is where you are now), then edit the Makefile which is there and add what's needed to the INCLUDEDIRS variable. Then do a make, and you should be fine. 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 tismer at stackless.com Tue Oct 23 17:38:51 2007 From: tismer at stackless.com (Christian Tismer) Date: Tue, 23 Oct 2007 17:38:51 +0200 Subject: [pypy-dev] Compiling pypy-c on Linux In-Reply-To: <471E1044.4050500@stackless.com> References: <169AF2FF-3CEF-4009-A5BE-F3B6052DF0A2@rice.edu> <471CD207.1090907@genesilico.pl> <717B5E66-4D1A-44F5-8E75-4B530E75AB58@rice.edu> <471CEA1D.2010509@stackless.com> <09193F64-889A-458A-B45D-A2BF669EEB2E@rice.edu> <471D45AD.4050709@stackless.com> <87DA5A5D-568D-4D48-B2CD-71502AFBB613@rice.edu> <471DBBB2.1000702@genesilico.pl> <471E0B80.1010403@stackless.com> <471E1044.4050500@stackless.com> Message-ID: <471E158B.10207@stackless.com> Christian Tismer wrote: > Raj Bandyopadhyay wrote: >> I don't have admin perms on the machine I'm using :( > > Then either ask your sysop to install it, > or get the source distro, build it locally, > and then you are slightly on your own. > > One proposal from #pypy was to just run the translation and let > compilation crash (this is where you are now), > then edit the Makefile which is there and add what's needed > to the INCLUDEDIRS variable. > > Then do a make, and you should be fine. I was just told that translate.py has a --cflags option, so you should be able to pass your extra -I options in there. 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 anto.cuni at gmail.com Wed Oct 24 14:37:07 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Wed, 24 Oct 2007 14:37:07 +0200 Subject: [pypy-dev] Small optimization Message-ID: <471F3C73.2030807@gmail.com> Hi all, between some interesting and a lot of not-so-interesting talks here at oospla, I also find the time to hack a bit on pypy :-). Yesterday I tried the hand-written optimization attached to this mail; it seems to make pystone about 6% faster; it's not much, but it's not even so few not to take into account, IMHO. Btw, richards does not show any improvement, as expected. Also, it seems that it makes pypy-cli slower, at least on mono; this is somewhat surprising, because IronPython entirely relies on this kind of if-else if tests to dispath all operations... I would have bet that our multimethod dispatching was slower, but it does not seems so. I should try also on MS .NET, though. I know that this is not the way to do such an optimization; I guess that the correct way would be to teach the mutlimethod installer which are the "hot" cases to test first, before going for a full dispatch; I've not clue how to do it, though. :-) ciao Anto -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: From exarkun at divmod.com Wed Oct 24 14:53:02 2007 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Wed, 24 Oct 2007 08:53:02 -0400 Subject: [pypy-dev] Small optimization In-Reply-To: <471F3C73.2030807@gmail.com> Message-ID: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> On Wed, 24 Oct 2007 14:37:07 +0200, Antonio Cuni wrote: >Hi all, > >between some interesting and a lot of not-so-interesting talks here at >oospla, I also find the time to hack a bit on pypy :-). > >Yesterday I tried the hand-written optimization attached to this mail; >it seems to make pystone about 6% faster; it's not much, but it's not >even so few not to take into account, IMHO. Btw, richards does not >show any improvement, as expected. > >Also, it seems that it makes pypy-cli slower, at least on mono; this >is somewhat surprising, because IronPython entirely relies on this >kind of if-else if tests to dispath all operations... I would have bet >that our multimethod dispatching was slower, but it does not seems >so. I should try also on MS .NET, though. > >I know that this is not the way to do such an optimization; I guess >that the correct way would be to teach the mutlimethod installer which >are the "hot" cases to test first, before going for a full dispatch; >I've not clue how to do it, though. :-) Does this break (by ignoring) custom __add__ implementations on int subclasses? Jean-Paul From anto.cuni at gmail.com Wed Oct 24 15:12:56 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Wed, 24 Oct 2007 15:12:56 +0200 Subject: [pypy-dev] Small optimization In-Reply-To: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> References: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> Message-ID: <471F44D8.8010109@gmail.com> Jean-Paul Calderone wrote: > Does this break (by ignoring) custom __add__ implementations on int > subclasses? uh, right! :-/ Well, that means that we should check for the exact classes/python type instead for subclasses, but I think the optimization is still worth of. ciao Anto From cfbolz at gmx.de Wed Oct 24 15:44:16 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 24 Oct 2007 15:44:16 +0200 Subject: [pypy-dev] Small optimization In-Reply-To: <471F44D8.8010109@gmail.com> References: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> <471F44D8.8010109@gmail.com> Message-ID: <471F4C30.7040507@gmx.de> Antonio Cuni wrote: > Jean-Paul Calderone wrote: >> Does this break (by ignoring) custom __add__ implementations on int >> subclasses? > > uh, right! :-/ > > Well, that means that we should check for the exact classes/python type > instead for subclasses, but I think the optimization is still worth of. Isn't this the optimization that Michael already tried? See objspace/std/objspace.py line 65. command line option is --objspace-std-withsmallint I turned out to not be worth it in many cases. Cheers, Carl Friedrich From tismer at stackless.com Wed Oct 24 16:22:23 2007 From: tismer at stackless.com (Christian Tismer) Date: Wed, 24 Oct 2007 16:22:23 +0200 Subject: [pypy-dev] Small optimization In-Reply-To: <471F4C30.7040507@gmx.de> References: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> <471F44D8.8010109@gmail.com> <471F4C30.7040507@gmx.de> Message-ID: <471F551F.6050905@stackless.com> Carl Friedrich Bolz wrote: > Antonio Cuni wrote: > > Jean-Paul Calderone wrote: > >> Does this break (by ignoring) custom __add__ implementations on int > >> subclasses? > > > > uh, right! :-/ > > > > Well, that means that we should check for the exact classes/python type > > instead for subclasses, but I think the optimization is still worth of. > > Isn't this the optimization that Michael already tried? See > objspace/std/objspace.py line 65. command line option is > --objspace-std-withsmallint > > I turned out to not be worth it in many cases. But it is known as a useful special case in the CPython interpreter loop. 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 cfbolz at gmx.de Wed Oct 24 16:28:59 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 24 Oct 2007 16:28:59 +0200 Subject: [pypy-dev] Small optimization In-Reply-To: <471F551F.6050905@stackless.com> References: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> <471F44D8.8010109@gmail.com> <471F4C30.7040507@gmx.de> <471F551F.6050905@stackless.com> Message-ID: <471F56AB.2050708@gmx.de> Christian Tismer wrote: >> Isn't this the optimization that Michael already tried? See >> objspace/std/objspace.py line 65. command line option is >> --objspace-std-withsmallint >> >> I turned out to not be worth it in many cases. > > But it is known as a useful special case in the CPython interpreter loop. Well, read our D7.1 report for details. One reason why it didn't help could be that our multimethod implementation is very good already, so special cases don't help it (but make the generic case slower). Cheers, Carl Friedrich From anto.cuni at gmail.com Wed Oct 24 16:32:50 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Wed, 24 Oct 2007 16:32:50 +0200 Subject: [pypy-dev] Small optimization In-Reply-To: <471F551F.6050905@stackless.com> References: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> <471F44D8.8010109@gmail.com> <471F4C30.7040507@gmx.de> <471F551F.6050905@stackless.com> Message-ID: <471F5792.5080609@gmail.com> Christian Tismer wrote: >> Isn't this the optimization that Michael already tried? See >> objspace/std/objspace.py line 65. command line option is >> --objspace-std-withsmallint >> >> I turned out to not be worth it in many cases. > > But it is known as a useful special case in the CPython interpreter loop. moreover, according to Jim Hugunin, it's also an useful optimization in IronPython, that's why I decided to try it. Btw, I choose int+int for the example but in theory we could apply the same technique to other cases, says getitem on list and int or getattr on instances and string. I mean, they are the common cases so it might be worth of special casing them; of course not manually, that's not the pypy way :-). ciao Anto From micahel at gmail.com Wed Oct 24 16:44:27 2007 From: micahel at gmail.com (Michael Hudson) Date: Wed, 24 Oct 2007 15:44:27 +0100 Subject: [pypy-dev] Small optimization In-Reply-To: <471F5792.5080609@gmail.com> References: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> <471F44D8.8010109@gmail.com> <471F4C30.7040507@gmx.de> <471F551F.6050905@stackless.com> <471F5792.5080609@gmail.com> Message-ID: On 24/10/2007, Antonio Cuni wrote: > Christian Tismer wrote: > >> Isn't this the optimization that Michael already tried? See > >> objspace/std/objspace.py line 65. command line option is > >> --objspace-std-withsmallint > >> > >> I turned out to not be worth it in many cases. > > > > But it is known as a useful special case in the CPython interpreter loop. > > moreover, according to Jim Hugunin, it's also an useful optimization in > IronPython, that's why I decided to try it. > > Btw, I choose int+int for the example but in theory we could apply the > same technique to other cases, says getitem on list and int or getattr > on instances and string. I mean, they are the common cases so it might > be worth of special casing them; of course not manually, that's not the > pypy way :-). As Carl Friedrich said, I went down this route a bit before, and didn't get very much. Maybe you will have a happier time of it! Cheers, mwh From arigo at tunes.org Sat Oct 27 19:26:49 2007 From: arigo at tunes.org (Armin Rigo) Date: Sat, 27 Oct 2007 19:26:49 +0200 Subject: [pypy-dev] Small optimization In-Reply-To: <471F4C30.7040507@gmx.de> References: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> <471F44D8.8010109@gmail.com> <471F4C30.7040507@gmx.de> Message-ID: <20071027172648.GA30710@code0.codespeak.net> Hi, On Wed, Oct 24, 2007 at 03:44:16PM +0200, Carl Friedrich Bolz wrote: > Isn't this the optimization that Michael already tried? See > objspace/std/objspace.py line 65. command line option is > --objspace-std-withsmallint No, it's --objspace-std-optimized_int_add. You're reading the code too fast :-) Armin From cfbolz at gmx.de Sun Oct 28 12:13:06 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 28 Oct 2007 12:13:06 +0100 Subject: [pypy-dev] Small optimization In-Reply-To: <20071027172648.GA30710@code0.codespeak.net> References: <20071024125302.8162.17001784.divmod.quotient.27196@ohm> <471F44D8.8010109@gmail.com> <471F4C30.7040507@gmx.de> <20071027172648.GA30710@code0.codespeak.net> Message-ID: <348899050710280413j27af270etdcd63fdf338c5ff7@mail.gmail.com> Hi Armin, 2007/10/27, Armin Rigo : > On Wed, Oct 24, 2007 at 03:44:16PM +0200, Carl Friedrich Bolz wrote: > > Isn't this the optimization that Michael already tried? See > > objspace/std/objspace.py line 65. command line option is > > --objspace-std-withsmallint > > No, it's --objspace-std-optimized_int_add. You're reading the code too > fast :-) Argh, indeed. That was complete nonsense, thanks for noticing. Cheers, Carl Friedrich From cfbolz at gmx.de Sun Oct 28 18:47:01 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 28 Oct 2007 18:47:01 +0100 Subject: [pypy-dev] bern sprint finished Message-ID: <4724CB15.8080404@gmx.de> Hi all, the Bern Smalltalk/PyPy sprint is finished. There won't be a sprint summary in the PyPy sense, but we covered most of what happened during the week on the (already mentioned) pypysqueak.blogspot.com . I just posted a short summary about the overall achievements of the week: http://pypysqueak.blogspot.com/2007/10/bern-sprint-finished-summary.html Cheers, Carl Friedrich From bea at changemaker.nu Tue Oct 30 14:00:40 2007 From: bea at changemaker.nu (=?ISO-8859-1?Q?Beatrice_D=FCring?=) Date: Tue, 30 Oct 2007 14:00:40 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: <4724CB15.8080404@gmx.de> References: <4724CB15.8080404@gmx.de> Message-ID: <47272AF8.3050801@changemaker.nu> Hi there Carl Friedrich Bolz skrev: > Hi all, > > the Bern Smalltalk/PyPy sprint is finished. There won't be a sprint > summary in the PyPy sense, but we covered most of what happened during > the week on the (already mentioned) pypysqueak.blogspot.com . I just > posted a short summary about the overall achievements of the week: > > http://pypysqueak.blogspot.com/2007/10/bern-sprint-finished-summary.html > > Cheers, > > Carl Friedrich > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > Thanks for this Carl Friedrich, I really appreciated the ongoing blog entries and the pictures - looks like there was a ..... sprint ;-) Cheers Bea -- Beatrice D?ring, PMP Change Maker J?rntorget 3 413 04 Gothenburg www.changemaker.nu email: bea at changemaker.nu Phone: +46 31 7750940 Cellphone: +46 734 22 89 06 PyPy: www.pypy.org From faassen at startifact.com Tue Oct 30 16:52:53 2007 From: faassen at startifact.com (Martijn Faassen) Date: Tue, 30 Oct 2007 16:52:53 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: <4724CB15.8080404@gmx.de> References: <4724CB15.8080404@gmx.de> Message-ID: Hey, Carl Friedrich Bolz wrote: > the Bern Smalltalk/PyPy sprint is finished. There won't be a sprint > summary in the PyPy sense, but we covered most of what happened during > the week on the (already mentioned) pypysqueak.blogspot.com . I just > posted a short summary about the overall achievements of the week: > > http://pypysqueak.blogspot.com/2007/10/bern-sprint-finished-summary.html Thanks for keeping that blog! I've been following it while the sprint progressed. Cool event! I would suggest you continue using a blog for sprint reports and such - once a blog gets picked up in the appropriate planets (Python, etc), it'll help increase PyPy's mindshare. I'd recommend reusing a single blog for all sprints though so people have a chance to get used to it. Regards, Martijn From ondrej at certik.cz Tue Oct 30 17:11:22 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Tue, 30 Oct 2007 17:11:22 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: References: <4724CB15.8080404@gmx.de> Message-ID: <85b5c3130710300911v684bd5b8he0ad1afad9834a1b@mail.gmail.com> > Carl Friedrich Bolz wrote: > > the Bern Smalltalk/PyPy sprint is finished. There won't be a sprint > > summary in the PyPy sense, but we covered most of what happened during > > the week on the (already mentioned) pypysqueak.blogspot.com . I just > > posted a short summary about the overall achievements of the week: > > > > http://pypysqueak.blogspot.com/2007/10/bern-sprint-finished-summary.html > > Thanks for keeping that blog! I've been following it while the sprint > progressed. Cool event! > > I would suggest you continue using a blog for sprint reports and such - > once a blog gets picked up in the appropriate planets (Python, etc), > it'll help increase PyPy's mindshare. I'd recommend reusing a single > blog for all sprints though so people have a chance to get used to it. > > Regards, Yes, the blog is cool! Ondrej From cfbolz at gmx.de Tue Oct 30 17:14:29 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 30 Oct 2007 17:14:29 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: References: <4724CB15.8080404@gmx.de> Message-ID: <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> Hi Martijn, 2007/10/30, Martijn Faassen : > Carl Friedrich Bolz wrote: > > the Bern Smalltalk/PyPy sprint is finished. There won't be a sprint > > summary in the PyPy sense, but we covered most of what happened during > > the week on the (already mentioned) pypysqueak.blogspot.com . I just > > posted a short summary about the overall achievements of the week: > > > > http://pypysqueak.blogspot.com/2007/10/bern-sprint-finished-summary.html > > Thanks for keeping that blog! I've been following it while the sprint > progressed. Cool event! Good to hear! > I would suggest you continue using a blog for sprint reports and such - > once a blog gets picked up in the appropriate planets (Python, etc), > it'll help increase PyPy's mindshare. I'd recommend reusing a single > blog for all sprints though so people have a chance to get used to it. Yes, definitely makes sense to me. The reason why we started a Squeak/PyPy blog and not a general PyPy blog was because we didn't want to spam the Smalltalk community too much with general PyPy blog entries. So, it seems many people liked the blog thing. How about we start a general PyPy blog where we can all post? Should we try to set something up on codespeak or just keep using blogspot? The latter increases the chances that things are happening soon :). Any ideas for a title? pypy.blogspot.com seems already taken by a dead one-entry block :-(. We could then try to get it picked up by the python planet. Cheers, Carl Friedrich From fijal at genesilico.pl Tue Oct 30 17:25:59 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Tue, 30 Oct 2007 17:25:59 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> References: <4724CB15.8080404@gmx.de> <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> Message-ID: <47275B17.9050906@genesilico.pl> > So, it seems many people liked the blog thing. How about we start a > general PyPy blog where we can all post? Should we try to set > something up on codespeak or just keep using blogspot? The latter > increases the chances that things are happening soon :). Any ideas for > a title? pypy.blogspot.com seems already taken by a dead one-entry > block :-(. We could then try to get it picked up by the python planet. > > Cheers, > > Carl Friedrich > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > When we're talking about quick solution, what about morepypy.blogspot.com? We can always move stuff to codespeak when we feel like doing that. Cheers, fijal :. From anto.cuni at gmail.com Tue Oct 30 17:28:36 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Tue, 30 Oct 2007 17:28:36 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> References: <4724CB15.8080404@gmx.de> <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> Message-ID: <47275BB4.50808@gmail.com> Carl Friedrich Bolz wrote: > So, it seems many people liked the blog thing. How about we start a > general PyPy blog where we can all post? Should we try to set > something up on codespeak or just keep using blogspot? The latter > increases the chances that things are happening soon :). Any ideas for > a title? pypy.blogspot.com seems already taken by a dead one-entry > block :-(. We could then try to get it picked up by the python planet. > +1 for the pypy blog: I think it would be cool to have. I think that the best would be to have it on codespeak, with maybe one general pypy blog and several ad-personam ones. Ideally it would be integrated with svn, because we all know that we prefer to write inside emacs/vi/whatever than inside a browser :-), but I admit that it would require much more work to setup such a thing. About the name: if pypy.blogspot.com is already taken, we could try to move to another blog site; for example, pypy.blogger.com seems to be free; I've no clue about advantages/features of one site or another, though. ciao Anto From cfbolz at gmx.de Tue Oct 30 17:34:54 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 30 Oct 2007 17:34:54 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: <47275BB4.50808@gmail.com> References: <4724CB15.8080404@gmx.de> <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> <47275BB4.50808@gmail.com> Message-ID: <348899050710300934q78993547if3490f1964a7407a@mail.gmail.com> Hi Anto, 2007/10/30, Antonio Cuni : > Carl Friedrich Bolz wrote: > > > So, it seems many people liked the blog thing. How about we start a > > general PyPy blog where we can all post? Should we try to set > > something up on codespeak or just keep using blogspot? The latter > > increases the chances that things are happening soon :). Any ideas for > > a title? pypy.blogspot.com seems already taken by a dead one-entry > > block :-(. We could then try to get it picked up by the python planet. > > > > +1 for the pypy blog: I think it would be cool to have. > > I think that the best would be to have it on codespeak, with maybe one > general pypy blog and several ad-personam ones. Ideally it would be > integrated with svn, because we all know that we prefer to write inside > emacs/vi/whatever than inside a browser :-), but I admit that it would > require much more work to setup such a thing. See? If we decide to do that we won't get a blog anytime soon :-). But I agree that some rest/svn integration later would be nice. > About the name: if pypy.blogspot.com is already taken, we could try to > move to another blog site; for example, pypy.blogger.com seems to be > free; I've no clue about advantages/features of one site or another, though. blogger and blogspot are the same thing, I think. I went with Maciek's suggestion and registered morepypy.blogspot.com . Whoever wants to be able to post, please send me your google account name. We should move this thing to codespeak eventually, but for now I am happy to get things moving. Cheers, Carl Friedrich From anto.cuni at gmail.com Tue Oct 30 17:41:19 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Tue, 30 Oct 2007 17:41:19 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: <348899050710300934q78993547if3490f1964a7407a@mail.gmail.com> References: <4724CB15.8080404@gmx.de> <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> <47275BB4.50808@gmail.com> <348899050710300934q78993547if3490f1964a7407a@mail.gmail.com> Message-ID: <47275EAF.40008@gmail.com> Carl Friedrich Bolz wrote: > See? If we decide to do that we won't get a blog anytime soon :-). But > I agree that some rest/svn integration later would be nice. indeed, not being lazy is not our best value :-). > blogger and blogspot are the same thing, I think. I went with Maciek's > suggestion and registered morepypy.blogspot.com . Whoever wants to be > able to post, please send me your google account name. We should move > this thing to codespeak eventually, but for now I am happy to get > things moving. Ok, makes sense for me; me google account is, surprisingly enough, anto.cuni at gmail.com :-). ciao Anto From cfbolz at gmx.de Tue Oct 30 17:45:54 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 30 Oct 2007 17:45:54 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: <47275EAF.40008@gmail.com> References: <4724CB15.8080404@gmx.de> <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> <47275BB4.50808@gmail.com> <348899050710300934q78993547if3490f1964a7407a@mail.gmail.com> <47275EAF.40008@gmail.com> Message-ID: <348899050710300945j6e1615fcw84dff3f79ec7ee9f@mail.gmail.com> 2007/10/30, Antonio Cuni : > Carl Friedrich Bolz wrote: > > > See? If we decide to do that we won't get a blog anytime soon :-). But > > I agree that some rest/svn integration later would be nice. > > indeed, not being lazy is not our best value :-). > > > blogger and blogspot are the same thing, I think. I went with Maciek's > > suggestion and registered morepypy.blogspot.com . Whoever wants to be > > able to post, please send me your google account name. We should move > > this thing to codespeak eventually, but for now I am happy to get > > things moving. > > Ok, makes sense for me; me google account is, surprisingly enough, > anto.cuni at gmail.com :-). For future senders: sending it privately is fine with me. From lac at openend.se Tue Oct 30 18:09:46 2007 From: lac at openend.se (Laura Creighton) Date: Tue, 30 Oct 2007 18:09:46 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: Message from Antonio Cuni of "Tue, 30 Oct 2007 17:28:36 +0100." <47275BB4.50808@gmail.com> References: <4724CB15.8080404@gmx.de> <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> <47275BB4.50808@gmail.com> Message-ID: <200710301709.l9UH9kgd028717@theraft.openend.se> In a message of Tue, 30 Oct 2007 17:28:36 +0100, Antonio Cuni writes: >Carl Friedrich Bolz wrote: > >> So, it seems many people liked the blog thing. How about we start a >> general PyPy blog where we can all post? Should we try to set >> something up on codespeak or just keep using blogspot? The latter >> increases the chances that things are happening soon :). Any ideas for >> a title? pypy.blogspot.com seems already taken by a dead one-entry >> block :-(. We could then try to get it picked up by the python planet. >> > >+1 for the pypy blog: I think it would be cool to have. > >I think that the best would be to have it on codespeak, with maybe one >general pypy blog and several ad-personam ones. Ideally it would be >integrated with svn, because we all know that we prefer to write inside >emacs/vi/whatever than inside a browser :-), but I admit that it would >require much more work to setup such a thing. > >About the name: if pypy.blogspot.com is already taken, we could try to >move to another blog site; for example, pypy.blogger.com seems to be >free; I've no clue about advantages/features of one site or another, thou >gh. > >ciao Anto On Saturday, Jacob, Samuele, Armin and I leave for the USA. We are meeting with Humanized in Chicago, then IBM in New York, the Mozilla/Active State/Tim Bray of Sun in Vancouver, then going to a 3 day conference in Santa Cruz, then meeting John Rose of Sun and various other Sun people, then going to Electronic Arts, and then to google on the 14th. Then 2 days of free time in San Francisco, get back on an airplane on the 17th and arrive back here in G?teborg on the 19th, day 1 of the sprint. Ok, we're crazy. :-) But I think that a touring blog would be nice, even as a place to download our thoughts before our brains overflow. Somebody, someplace, must have made emacs binding for a commonly used blogging site, no? Googling isn't helping -- I keep finding everybody and their dog blogging about emacs bindings for every program on this planet, it seems, except the blogging software itself. Anybody know of any? Laura From cfbolz at gmx.de Tue Oct 30 18:19:10 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 30 Oct 2007 18:19:10 +0100 Subject: [pypy-dev] bern sprint finished In-Reply-To: <200710301709.l9UH9kgd028717@theraft.openend.se> References: <4724CB15.8080404@gmx.de> <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> <47275BB4.50808@gmail.com> <200710301709.l9UH9kgd028717@theraft.openend.se> Message-ID: <348899050710301019y6391a794qf66e34a4f7976ad2@mail.gmail.com> Hi Laura, 2007/10/30, Laura Creighton : [snip] > But I think that a touring blog would be nice, even as a place to > download our thoughts before our brains overflow. Somebody, > someplace, must have made emacs binding for a commonly used > blogging site, no? Googling isn't helping -- I keep finding > everybody and their dog blogging about emacs bindings for every > program on this planet, it seems, except the blogging software > itself. > > Anybody know of any? the easiest way is to just write the html yourself and paste that into the blogging thing. But maybe we can have a bit more convenience and use ReST or something, will experiment a bit. Cheers, Carl Friedrich From njriley at uiuc.edu Tue Oct 30 18:30:23 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue, 30 Oct 2007 12:30:23 -0500 Subject: [pypy-dev] bern sprint finished In-Reply-To: <200710301709.l9UH9kgd028717@theraft.openend.se> References: <4724CB15.8080404@gmx.de> <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> <47275BB4.50808@gmail.com> <200710301709.l9UH9kgd028717@theraft.openend.se> Message-ID: <20071030173023.GA50967@uiuc.edu> On Tue, Oct 30, 2007 at 06:09:46PM +0100, Laura Creighton wrote: > But I think that a touring blog would be nice, even as a place to > download our thoughts before our brains overflow. Somebody, > someplace, must have made emacs binding for a commonly used > blogging site, no? Googling isn't helping -- I keep finding > everybody and their dog blogging about emacs bindings for every > program on this planet, it seems, except the blogging software > itself. > > Anybody know of any? One of these should work... -- Nicholas Riley | From santagada at gmail.com Tue Oct 30 18:55:50 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Tue, 30 Oct 2007 15:55:50 -0200 Subject: [pypy-dev] bern sprint finished In-Reply-To: <200710301709.l9UH9kgd028717@theraft.openend.se> References: <4724CB15.8080404@gmx.de> <348899050710300914k7ef9435al87888a8fad75b9de@mail.gmail.com> <47275BB4.50808@gmail.com> <200710301709.l9UH9kgd028717@theraft.openend.se> Message-ID: This email is a great first post for the blog. And posts about how the trip is going would also be great... Em 30/10/2007, ?s 15:09, Laura Creighton escreveu: > > On Saturday, Jacob, Samuele, Armin and I leave for the USA. We are > meeting with Humanized in Chicago, then IBM in New York, the > Mozilla/Active State/Tim Bray of Sun in Vancouver, then going to a 3 > day conference in Santa Cruz, then meeting John Rose of Sun and > various other Sun people, then going to Electronic Arts, and then to > google on the 14th. Then 2 days of free time in San Francisco, get > back on an airplane on the 17th and arrive back here in G?teborg on > the 19th, day 1 of the sprint. > > Ok, we're crazy. :-) > > But I think that a touring blog would be nice, even as a place to > download our thoughts before our brains overflow. Somebody, > someplace, must have made emacs binding for a commonly used > blogging site, no? Googling isn't helping -- I keep finding > everybody and their dog blogging about emacs bindings for every > program on this planet, it seems, except the blogging software > itself. > > Anybody know of any? For textmate users out there it comes with a plugin for blog, if it is not there by default you will have to download the svn plugin repository. -- Leonardo Santagada A: Because it breaks the logical sequence of the discussion. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From lac at openend.se Tue Oct 30 21:55:22 2007 From: lac at openend.se (Laura Creighton) Date: Tue, 30 Oct 2007 21:55:22 +0100 Subject: [pypy-dev] http://morepypy.blogspot.com/ Message-ID: <200710302055.l9UKtMhd002705@theraft.openend.se> thank you for the welcoming post, carl friedrich. now -- can one get listed as a contributor even if one does not have a google account? I fear I may break down and get a google mail for this reason. Laura