From list-sink at trainedmonkeystudios.org Tue Dec 1 08:13:23 2009 From: list-sink at trainedmonkeystudios.org (Terrence Cole) Date: Mon, 30 Nov 2009 23:13:23 -0800 Subject: [pypy-dev] pyprocessing/multiprocessing In-Reply-To: <20091121093502403150.86fa8efe@flyfi.com> References: <20091121085430645676.95eb2994@flyfi.com> <693bc9ab0911210605o6592ceffrd2f63d9ee4701614@mail.gmail.com> <693bc9ab0911210606r371c0cddg52775410a2b2a00f@mail.gmail.com> <20091121093502403150.86fa8efe@flyfi.com> Message-ID: <1259651603.31237.27.camel@localhost> On Sat, 2009-11-21 at 09:35 -0500, Gary Robinson wrote: > OK, thanks for the confirmation that it's not working yet, and letting me know what it would take! > > I wish we had the resources to take on the task of converting it to > RPython, but there's no way at this point. :) I'm using pyprocessing > with unladen swallow now and it works fine but for the kinds of things > we're doing (mathy floating point stuff) I'd expect more speed from > PyPy... The C component of multiprocessing, at least in python 2.6 is tiny and trivial: a read and write implementation for the underlying connection class. It would probably be better off converted to plain python for pypy in any case. On Sat, 2009-11-21 at 15:06 +0100, Maciej Fijalkowski wrote: > Oh, and by the way, personally I would prefer to kill the GIL, so we > don't have to worry any more (but also noone from core devs is working > on it). > What, roughly, would be required to remove pypy's gil? I have heard rather nebulous tales of woe and tribulation on the cpython lists referring to fine-grained per-object locking, re-entrant garbage collectors, abi stability, and other horrors. I have no idea what bits of this dubious information would be relevant to pypy's rather more abstract internals, however. -Terrence From arigo at tunes.org Wed Dec 2 13:43:19 2009 From: arigo at tunes.org (Armin Rigo) Date: Wed, 2 Dec 2009 13:43:19 +0100 Subject: [pypy-dev] Leysin Winter Sprint: 23-30th January 2010 Message-ID: <20091202124318.GA17481@code0.codespeak.net> ===================================================================== PyPy Leysin Winter Sprint (23-30th January 2010) ===================================================================== .. image:: http://www.ermina.ch/002.JPG The next PyPy sprint will be in Leysin, Switzerland, for the seventh time. This is a fully public sprint: newcomers and topics other than those proposed below are welcome. ------------------------------ Goals and topics of the sprint ------------------------------ * The main idea of the sprint is to prepare the upcoming release of PyPy. This means mostly JIT or JIT-related work. It is a bit hard to be more precise right now, because it depends on how much is left to do in the core JIT. So work will be focused either on the JIT itself or on "make this or that feature of PyPy more JIT-friendly". Of course, as usual, we are ready to add any other task -- please mention on the mailing list what you would like to work on; the list of task is not really fixed. * And as usual, the main side goal is to have fun in winter sports :-) We can take a day off for ski. ----------- Exact times ----------- Officially, 23-30 January 2010. The idea is that the 23rd should be the arrival day, so we won't work too much until the 24th. ----------------------- Location & Accomodation ----------------------- Leysin, Switzerland, "same place as before". Let me refresh your memory: both the sprint venue and the lodging will be in a very spacious pair of chalets built specifically for bed & breakfast: http://www.ermina.ch/. The place has a good ADSL Internet connexion with wireless installed. You can of course arrange your own lodging anywhere (so long as you are in Leysin, you cannot be more than a 15 minutes walk away from the sprint venue), but I definitely recommend lodging there too -- you won't find a better view anywhere else (though you probably won't get much worse ones easily, either :-) Please *confirm* that you are coming so that we can adjust the reservations as appropriate. The rate so far has been around 60 CHF a night all included in 2-person rooms, with breakfast. There are larger rooms too (less expensive) and maybe the possibility to get a single room if you really want to. Please register by svn: http://codespeak.net/svn/pypy/extradoc/sprintinfo/leysin-winter-2010/people.txt or on the pypy-sprint mailing list if you do not yet have check-in rights: http://codespeak.net/mailman/listinfo/pypy-sprint You need a Swiss-to-(insert country here) power adapter. There will be some Swiss-to-EU adapters around -- bring a EU-format power strip if you have one. From cfbolz at gmx.de Wed Dec 2 15:37:31 2009 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 02 Dec 2009 15:37:31 +0100 Subject: [pypy-dev] Moving language implementations out of the PyPy tree Message-ID: <4B167BAB.6090509@gmx.de> Hi all, this has been discussed a few times in the past, but I actually started on this today. The idea is to no longer have the various non-Python implementations in the pypy/trunk/pypy/lang part of svn, as a first step of having a less monolithic PyPy source tree. Instead I made a new directory where those languages can live: https://codespeak.net/svn/pypy/lang The idea is that the various languages have a subdirectory there, with their own trunk/branches. I did the move for the Io, the Prolog and the Smalltalk interpreter. The following subdirs in pypy/trunk/pypy/lang still need to be moved: - automata - gameboy - js - malbolge - scheme Could people actual involved in those implementations step up and do the move? Cheers, Carl Friedrich From arigo at tunes.org Thu Dec 3 16:19:18 2009 From: arigo at tunes.org (Armin Rigo) Date: Thu, 3 Dec 2009 16:19:18 +0100 Subject: [pypy-dev] Leysin Winter Sprint: 23-30th January 2010 In-Reply-To: <20091202124318.GA17481@code0.codespeak.net> References: <20091202124318.GA17481@code0.codespeak.net> Message-ID: <20091203151918.GA18204@code0.codespeak.net> Hi all, Given the number of absent people announced already, I start to wonder if it makes sense to have a sprint at these dates at all. Indeed, from the list of "core" people, namely Maciek, Carl Friedrich, Antonio, Samuele and myself, we have two "no", two "yes", and one "don't know". The two "yes" are from Samuele and myself, which is particularly pointless given that we are together in Goteborg already. The two "no" are from Maciek and Carl Friedrich. What do you think? Moving the sprint to some unspecified later date would seem to be the best plan at the moment. Note that I will myself stay in Switzerland until mid-February in any case. A bientot, Armin. From hakan at debian.org Thu Dec 3 16:55:08 2009 From: hakan at debian.org (Hakan Ardo) Date: Thu, 3 Dec 2009 16:55:08 +0100 Subject: [pypy-dev] Special methods Message-ID: Hi, some while ago we had a discution about how to make rpython classes supprt special methods. I've spent some time on that and have an implementation[1] that implemtes support for quite a few of them. It consists of 4 patches and one special_methods module. Would it be of interest to palce this in the svn? If not what about apply the patches (with suitable modificatons)? How cnan I make that happend? 1. http://hakan.ardoe.net/pypy/ -- H?kan Ard? From santagada at gmail.com Thu Dec 3 17:57:37 2009 From: santagada at gmail.com (Leonardo Santagada) Date: Thu, 3 Dec 2009 14:57:37 -0200 Subject: [pypy-dev] Leysin Winter Sprint: 23-30th January 2010 In-Reply-To: <20091203151918.GA18204@code0.codespeak.net> References: <20091202124318.GA17481@code0.codespeak.net> <20091203151918.GA18204@code0.codespeak.net> Message-ID: <07BB8FB8-EEC2-4672-908F-974F24E3B4DC@gmail.com> On Dec 3, 2009, at 1:19 PM, Armin Rigo wrote: > What do you think? Moving the sprint to some unspecified later date > would seem to be the best plan at the moment. Talked on the channel about doing it during the pycon atlanta. Would the main developers go there? Can the pypy project reserve some space during the sprint days (from 22-25 february)? I think this would be a good chance to have more people involved, as I think there is some renewed interest in pypy since the news about the jit started to appear on the blog. Here is the call for sprints (but be aware that the dates apear to be wrong) http://us.pycon.org/2010/sprints/call-for-projects/ the correct dates and more info here: http://us.pycon.org/2010/sprints/ -- Leonardo Santagada santagada at gmail.com From lac at openend.se Thu Dec 3 20:58:56 2009 From: lac at openend.se (Laura Creighton) Date: Thu, 03 Dec 2009 20:58:56 +0100 Subject: [pypy-dev] Leysin Winter Sprint: 23-30th January 2010 In-Reply-To: Message from Armin Rigo of "Thu, 03 Dec 2009 16:19:18 +0100." <20091203151918.GA18204@code0.codespeak.net> References: <20091202124318.GA17481@code0.codespeak.net> <20091203151918.GA18204@code0.codespeak.net> Message-ID: <200912031958.nB3JwusP017965@theraft.openend.se> In a message of Thu, 03 Dec 2009 16:19:18 +0100, Armin Rigo writes: >Hi all, > >Given the number of absent people announced already, I start to wonder >if it makes sense to have a sprint at these dates at all. Indeed, from >the list of "core" people, namely Maciek, Carl Friedrich, Antonio, >Samuele and myself, we have two "no", two "yes", and one "don't know". >The two "yes" are from Samuele and myself, which is particularly >pointless given that we are together in Goteborg already. The two "no" >are from Maciek and Carl Friedrich. > >What do you think? Moving the sprint to some unspecified later date >would seem to be the best plan at the moment. > >Note that I will myself stay in Switzerland until mid-February in any >case. > > >A bientot, > >Armin. Can we still get a release made before PyCON? Laura From benjamin at python.org Fri Dec 4 05:13:54 2009 From: benjamin at python.org (Benjamin Peterson) Date: Thu, 3 Dec 2009 22:13:54 -0600 Subject: [pypy-dev] Special methods In-Reply-To: References: Message-ID: <1afaf6160912032013l3b081a69j8607ca0de76e4a5a@mail.gmail.com> 2009/12/3 Hakan Ardo : > Hi, > some while ago we had a discution about how to make rpython classes > supprt special methods. ?I've spent some time on that and have an > implementation[1] that implemtes support for quite a few of them. It > consists of 4 patches and one special_methods module. Would it be of > interest to palce this in the svn? If not what about apply the patches > (with suitable modificatons)? How cnan I make that happend? I'm personally -1 to this change. RPython is supposed to be a no-frills language, and I don't really see the advantage or use cases for adding this extra maintenance burden. -- Regards, Benjamin From william.leslie.ttg at gmail.com Fri Dec 4 05:36:56 2009 From: william.leslie.ttg at gmail.com (William Leslie) Date: Fri, 4 Dec 2009 15:36:56 +1100 Subject: [pypy-dev] Special methods In-Reply-To: <1afaf6160912032013l3b081a69j8607ca0de76e4a5a@mail.gmail.com> References: <1afaf6160912032013l3b081a69j8607ca0de76e4a5a@mail.gmail.com> Message-ID: You probably mean SomeInstance rather than SomeObject in that annotator patch. 2009/12/4 Benjamin Peterson : > 2009/12/3 Hakan Ardo : >> Hi, >> some while ago we had a discution about how to make rpython classes >> supprt special methods. ?I've spent some time on that and have an >> implementation[1] that implemtes support for quite a few of them. It >> consists of 4 patches and one special_methods module. Would it be of >> interest to palce this in the svn? If not what about apply the patches >> (with suitable modificatons)? How cnan I make that happend? > > I'm personally -1 to this change. RPython is supposed to be a > no-frills language, and I don't really see the advantage or use cases > for adding this extra maintenance burden. Not only is it potentially a maintainence burden, it is also a development burden when doing optimisations on the rtyped graphs, for example, any optimisation that deals with setitem in some way now has to deal with the target not being a list or dict. This is probably not as big a deal now as it may be in the future, since a lot of new analyses seem to be using the lltype and ootype systems rather than the high level types (hence the type information is encoded into the operation where useful). Willam Leslie From hakan at debian.org Fri Dec 4 09:23:55 2009 From: hakan at debian.org (Hakan Ardo) Date: Fri, 4 Dec 2009 09:23:55 +0100 Subject: [pypy-dev] Special methods In-Reply-To: References: <1afaf6160912032013l3b081a69j8607ca0de76e4a5a@mail.gmail.com> Message-ID: On Fri, Dec 4, 2009 at 5:36 AM, William Leslie wrote: > You probably mean SomeInstance rather than SomeObject in that annotator patch. No, the intention with that construction is to make the can_be_notImplemented method return True for SomeObject instances, but defalt to False for all subclasses not implementing the can_be_notImplemented method. I.e. we want SomeInteger to still represent an integer and not an "integer or NotImplemented". The alternative would be to add a can_be_notImplemented method to every Some.... class returning False. >> >> I'm personally -1 to this change. RPython is supposed to be a >> no-frills language, and I don't really see the advantage or use cases >> for adding this extra maintenance burden. > > Not only is it potentially a maintainence burden, it is also a > development burden when doing optimisations on the rtyped graphs, for OK. How about applying (some of) the pathces (http://hakan.ardoe.net/pypy/)? str_or_none.patch A bugfix preventing the call str(o), where o is a "string or None" object, from segfaulting when o becomes None oper.patch Allows the oppertaions int(), and float(), to be defined in methods of Some... classes. The chunk modifying rclass.py should probably be discarded if speical_methods.py is not used. setitem.patch Replace setitem operations with setitem_{key, idx, idx_key} in the same way as getitem is replaced depending on what exceptions are caught. annotator.patch Allows Some... classes to represent "... and NotImplemented" objects in the same way as they can represent "... and None". -- H?kan Ard? From sh at lutzhaase.com Fri Dec 4 16:50:33 2009 From: sh at lutzhaase.com (Sven-Hendrik Haase) Date: Fri, 04 Dec 2009 16:50:33 +0100 Subject: [pypy-dev] Parallel translation? Message-ID: <4B192FC9.5040203@lutzhaase.com> Hey, I just translated SVN trunk of PyPy with JIT enabled and I was very pleased by the results as I noticed that PyPy with JIT is now two times faster in Pystone (I know that's not saying too much) than Cpython. However, translating took a very long time due to not being able to make use of my other CPU cores. I did not find a switch to compile using multiple shells (as in -jN) so I was wondering whether such a feature was planned or even possible. At least for the compilation part, this should be very possible. -- Sven-Hendrik From benjamin at python.org Fri Dec 4 17:36:39 2009 From: benjamin at python.org (Benjamin Peterson) Date: Fri, 4 Dec 2009 10:36:39 -0600 Subject: [pypy-dev] Parallel translation? In-Reply-To: <4B192FC9.5040203@lutzhaase.com> References: <4B192FC9.5040203@lutzhaase.com> Message-ID: <1afaf6160912040836m617685ean15d3fdada5a1d7bc@mail.gmail.com> 2009/12/4 Sven-Hendrik Haase : > Hey, > > I just translated SVN trunk of PyPy with JIT enabled and I was very > pleased by the results as I noticed that PyPy with JIT is now two times > faster in Pystone (I know that's not saying too much) than Cpython. > However, translating took a very long time due to not being able to make > use of my other CPU cores. I did not find a switch to compile using > multiple shells (as in -jN) so I was wondering whether such a feature > was planned or even possible. At least for the compilation part, this > should be very possible. No, that's not planned at the moment. The only time we could easily use multiple CPU at the moment is compiling the final C sources. You can even do this manually with the make file in the temp source directory. -- Regards, Benjamin From anto.cuni at gmail.com Fri Dec 4 18:18:13 2009 From: anto.cuni at gmail.com (Antonio Cuni) Date: Fri, 04 Dec 2009 18:18:13 +0100 Subject: [pypy-dev] Parallel translation? In-Reply-To: <1afaf6160912040836m617685ean15d3fdada5a1d7bc@mail.gmail.com> References: <4B192FC9.5040203@lutzhaase.com> <1afaf6160912040836m617685ean15d3fdada5a1d7bc@mail.gmail.com> Message-ID: <4B194455.6000406@gmail.com> Benjamin Peterson wrote: > No, that's not planned at the moment. The only time we could easily > use multiple CPU at the moment is compiling the final C sources. You > can even do this manually with the make file in the temp source > directory. I agree that at this point in time we cannot or don't want to make annotation/rtyping/backend parallelizable, but it should definitely be possible to just pass the -j flag to 'make' in an automatic way. Anyone feeling like to implement it? :-) From arigo at tunes.org Sat Dec 5 16:44:45 2009 From: arigo at tunes.org (Armin Rigo) Date: Sat, 5 Dec 2009 16:44:45 +0100 Subject: [pypy-dev] Parallel translation? In-Reply-To: <4B194455.6000406@gmail.com> References: <4B192FC9.5040203@lutzhaase.com> <1afaf6160912040836m617685ean15d3fdada5a1d7bc@mail.gmail.com> <4B194455.6000406@gmail.com> Message-ID: <20091205154445.GA18139@code0.codespeak.net> Hi, On Fri, Dec 04, 2009 at 06:18:13PM +0100, Antonio Cuni wrote: > I agree that at this point in time we cannot or don't want to make > annotation/rtyping/backend parallelizable, but it should definitely be > possible to just pass the -j flag to 'make' in an automatic way. Of course, that is full of open problems too. The main one is that each gcc process consumes potentially a lot of RAM, so just passing "-j" is not a great idea, as all gccs are started in parallel. It looks like some obscure tweak is needed, like setting -j to a number that depends not only on the number of CPUs (as is classically done) but also on the total RAM of the system... A bientot, Armin. From fijall at gmail.com Sat Dec 5 17:49:37 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sat, 5 Dec 2009 17:49:37 +0100 Subject: [pypy-dev] Parallel translation? In-Reply-To: <20091205154445.GA18139@code0.codespeak.net> References: <4B192FC9.5040203@lutzhaase.com> <1afaf6160912040836m617685ean15d3fdada5a1d7bc@mail.gmail.com> <4B194455.6000406@gmail.com> <20091205154445.GA18139@code0.codespeak.net> Message-ID: <693bc9ab0912050849m3f9441cpf6e6e2b53a08857a@mail.gmail.com> On Sat, Dec 5, 2009 at 4:44 PM, Armin Rigo wrote: > Hi, > > On Fri, Dec 04, 2009 at 06:18:13PM +0100, Antonio Cuni wrote: >> I agree that at this point in time we cannot or don't want to make >> annotation/rtyping/backend parallelizable, but it should definitely be >> possible to just pass the -j flag to 'make' in an automatic way. > > Of course, that is full of open problems too. ?The main one is that each > gcc process consumes potentially a lot of RAM, so just passing "-j" is > not a great idea, as all gccs are started in parallel. ?It looks like > some obscure tweak is needed, like setting -j to a number that depends > not only on the number of CPUs (as is classically done) but also on the > total RAM of the system... > > > A bientot, > > Armin. I guess the original idea was to have a translation option that is passed as -j flag to make, so one can specify what number of jobs he wants, instead of trying to guess it automatically. Cheers, fijal From fijall at gmail.com Sun Dec 6 00:46:04 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sun, 6 Dec 2009 00:46:04 +0100 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: <4AEF617F.6030502@samuelreis.de> References: <4AEF617F.6030502@samuelreis.de> Message-ID: <693bc9ab0912051546p2ec8eae5uba72ac1ac89f347a@mail.gmail.com> On Mon, Nov 2, 2009 at 11:47 PM, Samuel Reis wrote: > Hello everybody, > > My name is Samuel Reis and I'm a 17-year-old student from Hanover, Germany. Hi samuel. Actually, I wanted to use your artwork, but unfortunately links are gone and I don't have copies :-( Can you provide them again? Cheers, fijal From p.giarrusso at gmail.com Sun Dec 6 12:05:00 2009 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Sun, 6 Dec 2009 12:05:00 +0100 Subject: [pypy-dev] Parallel translation? In-Reply-To: <20091205154445.GA18139@code0.codespeak.net> References: <4B192FC9.5040203@lutzhaase.com> <1afaf6160912040836m617685ean15d3fdada5a1d7bc@mail.gmail.com> <4B194455.6000406@gmail.com> <20091205154445.GA18139@code0.codespeak.net> Message-ID: On Sat, Dec 5, 2009 at 16:44, Armin Rigo wrote: > Hi, > > On Fri, Dec 04, 2009 at 06:18:13PM +0100, Antonio Cuni wrote: >> I agree that at this point in time we cannot or don't want to make >> annotation/rtyping/backend parallelizable, but it should definitely be >> possible to just pass the -j flag to 'make' in an automatic way. > > Of course, that is full of open problems too. ?The main one is that each > gcc process consumes potentially a lot of RAM, so just passing "-j" is > not a great idea, as all gccs are started in parallel. ?It looks like > some obscure tweak is needed, like setting -j to a number that depends > not only on the number of CPUs (as is classically done) but also on the > total RAM of the system... My 2 cents: for C++ I would be really worried, but for C I'd guess that even with 4 CPUs (i.e. classically 5 jobs) one is not going to go over 1Gb... or not? Dear Sven-Hendrik, would you verify this idea by launching make by hand, as suggested? (Now, I'm going back to just lurking). Regards -- Paolo Giarrusso From daniel at bovensiepen.net Sun Dec 6 20:08:23 2009 From: daniel at bovensiepen.net (Daniel Bovensiepen) Date: Sun, 6 Dec 2009 20:08:23 +0100 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: <4AEF617F.6030502@samuelreis.de> References: <4AEF617F.6030502@samuelreis.de> Message-ID: Hi Samuel, I didn't saw your mail last month. I'm at the moment in copenhagen but my home town is also hanover. There is a small group of people who are meeting every month to talk mainly about ruby. But we are all also interested in programming languages such as python. So if you like you can join us at the 14.12.2009 (http://wiki.ruby-portal.de/RUUH). I'm quite new to pypy, but I'm playing with the idea to write a small (means reduced) rb implementation in it just for fun. If you like to join one of the coming pypy sprints, maybe we can also find a way to travel together to reduce the financial issue. best regards daniel From overminddl1 at gmail.com Mon Dec 7 03:39:28 2009 From: overminddl1 at gmail.com (OvermindDL1) Date: Sun, 6 Dec 2009 19:39:28 -0700 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: <693bc9ab0912051546p2ec8eae5uba72ac1ac89f347a@mail.gmail.com> References: <4AEF617F.6030502@samuelreis.de> <693bc9ab0912051546p2ec8eae5uba72ac1ac89f347a@mail.gmail.com> Message-ID: <3f49a9f40912061839s6791dd10u4aa15982196e100b@mail.gmail.com> Yeesh, helps if I sent this to the pypy list instead of just replying to the person above. Why are the headers broken on the list? On Sat, Dec 5, 2009 at 4:46 PM, Maciej Fijalkowski wrote: > On Mon, Nov 2, 2009 at 11:47 PM, Samuel Reis wrote: >> Hello everybody, >> >> My name is Samuel Reis and I'm a 17-year-old student from Hanover, Germany. > > Hi samuel. Actually, I wanted to use your artwork, but unfortunately > links are gone and I don't have copies :-( Can you provide them again? And unfortunately he setup his robots.txt exclusion to prevent archive.org and google from copying/cache'ing the images so they really are gone from the world unless reposted. From stefan_ml at behnel.de Mon Dec 7 10:48:19 2009 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 07 Dec 2009 10:48:19 +0100 Subject: [pypy-dev] Parallel translation? In-Reply-To: <20091205154445.GA18139@code0.codespeak.net> References: <4B192FC9.5040203@lutzhaase.com> <1afaf6160912040836m617685ean15d3fdada5a1d7bc@mail.gmail.com> <4B194455.6000406@gmail.com> <20091205154445.GA18139@code0.codespeak.net> Message-ID: Armin Rigo, 05.12.2009 16:44: > On Fri, Dec 04, 2009 at 06:18:13PM +0100, Antonio Cuni wrote: >> I agree that at this point in time we cannot or don't want to make >> annotation/rtyping/backend parallelizable, but it should definitely be >> possible to just pass the -j flag to 'make' in an automatic way. > > Of course, that is full of open problems too. The main one is that each > gcc process consumes potentially a lot of RAM, so just passing "-j" is > not a great idea, as all gccs are started in parallel. It looks like > some obscure tweak is needed, like setting -j to a number that depends > not only on the number of CPUs (as is classically done) but also on the > total RAM of the system... I just did a quick check with lxml.etree, for which Cython generates a 6.5MB C file with 150K lines (~96K non-empty/non-'#' lines in gcc -E). Running that through "gcc -O3 -march=core2 -pipe" keeps the peek virtual memory allocation in 'top' well below 350MB on my 32bit Linux system. Developer machines tend to be rather well equipped these days, so not much to worry about here, IMHO. Stefan From con at samuelreis.de Mon Dec 7 17:01:29 2009 From: con at samuelreis.de (Samuel Reis) Date: Mon, 7 Dec 2009 17:01:29 +0100 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: <693bc9ab0912051546p2ec8eae5uba72ac1ac89f347a@mail.gmail.com> References: <4AEF617F.6030502@samuelreis.de> <693bc9ab0912051546p2ec8eae5uba72ac1ac89f347a@mail.gmail.com> Message-ID: <2AB20B61-329C-45FE-BB75-7F57A140880F@samuelreis.de> -- Reposting this -- somehow I didn't got listet. -- Am 06.12.2009 um 00:46 schrieb Maciej Fijalkowski: > On Mon, Nov 2, 2009 at 11:47 PM, Samuel Reis > wrote: >> Hello everybody, >> >> My name is Samuel Reis and I'm a 17-year-old student from Hanover, >> Germany. > > Hi samuel. Actually, I wanted to use your artwork, but unfortunately > links are gone and I don't have copies :-( Can you provide them again? > > Cheers, > fijal Hi fijal, I'm sorry for replying so late to you, but I was not at home on the weekend. Links are here: http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.jpg http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.svg Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Mon Dec 7 17:07:08 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 7 Dec 2009 17:07:08 +0100 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: <2AB20B61-329C-45FE-BB75-7F57A140880F@samuelreis.de> References: <4AEF617F.6030502@samuelreis.de> <693bc9ab0912051546p2ec8eae5uba72ac1ac89f347a@mail.gmail.com> <2AB20B61-329C-45FE-BB75-7F57A140880F@samuelreis.de> Message-ID: <693bc9ab0912070807r58d1a15cvf92701ed022b6c8d@mail.gmail.com> Thanks! Btw - friend of mine suggests that logo should focus rather on speed than on looping ;-) Cheers, fijal On Mon, Dec 7, 2009 at 5:01 PM, Samuel Reis wrote: > -- Reposting this -- somehow I didn't got listet. -- > Am 06.12.2009 um 00:46 schrieb Maciej Fijalkowski: > > On Mon, Nov 2, 2009 at 11:47 PM, Samuel Reis wrote: > > Hello everybody, > > My name is Samuel Reis and I'm a 17-year-old student from Hanover, Germany. > > Hi samuel. Actually, I wanted to use your artwork, but unfortunately > links are gone and I don't have copies :-( Can you provide them again? > > Cheers, > fijal > > Hi fijal, > > I'm sorry for replying so late to you, but I was not at home on the > weekend. > Links are here: > http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.jpg > http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.svg > > Samuel > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From con at samuelreis.de Mon Dec 7 17:17:11 2009 From: con at samuelreis.de (Samuel Reis) Date: Mon, 7 Dec 2009 17:17:11 +0100 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: <693bc9ab0912070807r58d1a15cvf92701ed022b6c8d@mail.gmail.com> References: <4AEF617F.6030502@samuelreis.de> <693bc9ab0912051546p2ec8eae5uba72ac1ac89f347a@mail.gmail.com> <2AB20B61-329C-45FE-BB75-7F57A140880F@samuelreis.de> <693bc9ab0912070807r58d1a15cvf92701ed022b6c8d@mail.gmail.com> Message-ID: Hi fijal, maybe I can add some "speed" to it .. I'll see what I can do. Do you have any concrete plans where you want to use the logo? It would be nice to know where it is used. Regards -- Samuel Am 07.12.2009 um 17:07 schrieb Maciej Fijalkowski: > Thanks! > > Btw - friend of mine suggests that logo should focus rather on speed > than on looping ;-) > > Cheers, > fijal > > On Mon, Dec 7, 2009 at 5:01 PM, Samuel Reis wrote: >> -- Reposting this -- somehow I didn't got listet. -- >> Am 06.12.2009 um 00:46 schrieb Maciej Fijalkowski: >> >> On Mon, Nov 2, 2009 at 11:47 PM, Samuel Reis >> wrote: >> >> Hello everybody, >> >> My name is Samuel Reis and I'm a 17-year-old student from Hanover, >> Germany. >> >> Hi samuel. Actually, I wanted to use your artwork, but unfortunately >> links are gone and I don't have copies :-( Can you provide them >> again? >> >> Cheers, >> fijal >> >> Hi fijal, >> >> I'm sorry for replying so late to you, but I was not at home on the >> weekend. >> Links are here: >> http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.jpg >> http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.svg >> >> Samuel >> >> _______________________________________________ >> pypy-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/pypy-dev >> From con at samuelreis.de Mon Dec 7 19:33:08 2009 From: con at samuelreis.de (Samuel Reis) Date: Mon, 7 Dec 2009 19:33:08 +0100 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: References: <4AEF617F.6030502@samuelreis.de> <693bc9ab0912051546p2ec8eae5uba72ac1ac89f347a@mail.gmail.com> <2AB20B61-329C-45FE-BB75-7F57A140880F@samuelreis.de> <693bc9ab0912070807r58d1a15cvf92701ed022b6c8d@mail.gmail.com> Message-ID: <3A3E97B5-C022-4632-AA3D-E06DFA2D1F91@samuelreis.de> Update: Some rough drafts of "speed" (based on my previous logo) http://stuff.coffeine.info/pypy_fin.png http://stuff.coffeine.info/pypy_fin.svg Feedback is highly appreciated. Greetings -- Samuel Am 07.12.2009 um 17:17 schrieb Samuel Reis: > Hi fijal, > > maybe I can add some "speed" to it .. I'll see what I can do. > Do you have any concrete plans where you want to use the logo? It > would be nice to know where it is used. > > Regards -- Samuel > > Am 07.12.2009 um 17:07 schrieb Maciej Fijalkowski: > >> Thanks! >> >> Btw - friend of mine suggests that logo should focus rather on speed >> than on looping ;-) >> >> Cheers, >> fijal >> >> On Mon, Dec 7, 2009 at 5:01 PM, Samuel Reis >> wrote: >>> -- Reposting this -- somehow I didn't got listet. -- >>> Am 06.12.2009 um 00:46 schrieb Maciej Fijalkowski: >>> >>> On Mon, Nov 2, 2009 at 11:47 PM, Samuel Reis >>> wrote: >>> >>> Hello everybody, >>> >>> My name is Samuel Reis and I'm a 17-year-old student from Hanover, >>> Germany. >>> >>> Hi samuel. Actually, I wanted to use your artwork, but unfortunately >>> links are gone and I don't have copies :-( Can you provide them >>> again? >>> >>> Cheers, >>> fijal >>> >>> Hi fijal, >>> >>> I'm sorry for replying so late to you, but I was not at home on the >>> weekend. >>> Links are here: >>> http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.jpg >>> http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.svg >>> >>> Samuel >>> >>> _______________________________________________ >>> pypy-dev at codespeak.net >>> http://codespeak.net/mailman/listinfo/pypy-dev >>> > From fuzzyman at gmail.com Mon Dec 7 20:47:30 2009 From: fuzzyman at gmail.com (Michael Foord) Date: Mon, 7 Dec 2009 19:47:30 +0000 Subject: [pypy-dev] Hello PyPy Developer Team In-Reply-To: <3A3E97B5-C022-4632-AA3D-E06DFA2D1F91@samuelreis.de> References: <4AEF617F.6030502@samuelreis.de> <693bc9ab0912051546p2ec8eae5uba72ac1ac89f347a@mail.gmail.com> <2AB20B61-329C-45FE-BB75-7F57A140880F@samuelreis.de> <693bc9ab0912070807r58d1a15cvf92701ed022b6c8d@mail.gmail.com> <3A3E97B5-C022-4632-AA3D-E06DFA2D1F91@samuelreis.de> Message-ID: <6f4025010912071147u77d3aa72w6d761ddcf166a49b@mail.gmail.com> 2009/12/7 Samuel Reis > Update: > > Some rough drafts of "speed" (based on my previous logo) > > http://stuff.coffeine.info/pypy_fin.png > http://stuff.coffeine.info/pypy_fin.svg > > Feedback is highly appreciated. > I really like the first one. Michael > > Greetings -- Samuel > > Am 07.12.2009 um 17:17 schrieb Samuel Reis: > > > Hi fijal, > > > > maybe I can add some "speed" to it .. I'll see what I can do. > > Do you have any concrete plans where you want to use the logo? It > > would be nice to know where it is used. > > > > Regards -- Samuel > > > > Am 07.12.2009 um 17:07 schrieb Maciej Fijalkowski: > > > >> Thanks! > >> > >> Btw - friend of mine suggests that logo should focus rather on speed > >> than on looping ;-) > >> > >> Cheers, > >> fijal > >> > >> On Mon, Dec 7, 2009 at 5:01 PM, Samuel Reis > >> wrote: > >>> -- Reposting this -- somehow I didn't got listet. -- > >>> Am 06.12.2009 um 00:46 schrieb Maciej Fijalkowski: > >>> > >>> On Mon, Nov 2, 2009 at 11:47 PM, Samuel Reis > >>> wrote: > >>> > >>> Hello everybody, > >>> > >>> My name is Samuel Reis and I'm a 17-year-old student from Hanover, > >>> Germany. > >>> > >>> Hi samuel. Actually, I wanted to use your artwork, but unfortunately > >>> links are gone and I don't have copies :-( Can you provide them > >>> again? > >>> > >>> Cheers, > >>> fijal > >>> > >>> Hi fijal, > >>> > >>> I'm sorry for replying so late to you, but I was not at home on the > >>> weekend. > >>> Links are here: > >>> http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.jpg > >>> http://maddog22.de/samuelreis_old/artwork/pypy/pypy_fin.svg > >>> > >>> Samuel > >>> > >>> _______________________________________________ > >>> pypy-dev at codespeak.net > >>> http://codespeak.net/mailman/listinfo/pypy-dev > >>> > > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- http://www.ironpythoninaction.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh at lutzhaase.com Tue Dec 8 02:22:45 2009 From: sh at lutzhaase.com (Sven-Hendrik Haase) Date: Tue, 08 Dec 2009 02:22:45 +0100 Subject: [pypy-dev] Parallel translation? In-Reply-To: References: <4B192FC9.5040203@lutzhaase.com> <1afaf6160912040836m617685ean15d3fdada5a1d7bc@mail.gmail.com> <4B194455.6000406@gmail.com> <20091205154445.GA18139@code0.codespeak.net> Message-ID: <4B1DAA65.20200@lutzhaase.com> On 07.12.2009 10:48, Stefan Behnel wrote: > Armin Rigo, 05.12.2009 16:44: > >> On Fri, Dec 04, 2009 at 06:18:13PM +0100, Antonio Cuni wrote: >> >>> I agree that at this point in time we cannot or don't want to make >>> annotation/rtyping/backend parallelizable, but it should definitely be >>> possible to just pass the -j flag to 'make' in an automatic way. >>> >> Of course, that is full of open problems too. The main one is that each >> gcc process consumes potentially a lot of RAM, so just passing "-j" is >> not a great idea, as all gccs are started in parallel. It looks like >> some obscure tweak is needed, like setting -j to a number that depends >> not only on the number of CPUs (as is classically done) but also on the >> total RAM of the system... >> > > I just did a quick check with lxml.etree, for which Cython generates a > 6.5MB C file with 150K lines (~96K non-empty/non-'#' lines in gcc -E). > Running that through "gcc -O3 -march=core2 -pipe" keeps the peek virtual > memory allocation in 'top' well below 350MB on my 32bit Linux system. > Developer machines tend to be rather well equipped these days, so not much > to worry about here, IMHO. > > Stefan > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > > Indeed, my own tests support this. Especially with kernel 2.6.32, memory should no longer be the issue. -- Sven-Hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Thu Dec 10 17:59:55 2009 From: arigo at tunes.org (Armin Rigo) Date: Thu, 10 Dec 2009 17:59:55 +0100 Subject: [pypy-dev] Leysin Winter Sprint: 23-30th January 2010 In-Reply-To: <200912031958.nB3JwusP017965@theraft.openend.se> References: <20091202124318.GA17481@code0.codespeak.net> <20091203151918.GA18204@code0.codespeak.net> <200912031958.nB3JwusP017965@theraft.openend.se> Message-ID: <20091210165955.GA31759@code0.codespeak.net> Hi Laura, hi all, On Thu, Dec 03, 2009 at 08:58:56PM +0100, Laura Creighton wrote: > Can we still get a release made before PyCON? We agreed that a "virtual sprint" will occur, roughly on the same dates. The release should be made during that sprint. The sprint is "virtual" because we will not be all together at that point in time (e.g. I will be in Switzerland, while Samuele and Maciek will be in Gothenburg). The actual sprint in Leysin is reported to some later date -- maybe March or April, in any case after PyCon. More about the "virtual sprint" should follow here :-) A bientot, Armin. From arigo at tunes.org Thu Dec 10 19:05:52 2009 From: arigo at tunes.org (Armin Rigo) Date: Thu, 10 Dec 2009 19:05:52 +0100 Subject: [pypy-dev] Special methods In-Reply-To: References: <1afaf6160912032013l3b081a69j8607ca0de76e4a5a@mail.gmail.com> Message-ID: <20091210180552.GA2842@code0.codespeak.net> Hi Hakan, On Fri, Dec 04, 2009 at 09:23:55AM +0100, Hakan Ardo wrote: > OK. How about applying (some of) the pathces (http://hakan.ardoe.net/pypy/)? In general, I agree with others that we don't want to add frills to the annotator now. You need some serious motivation to convince us: "this feature is useful when writing an interpreter for that kind of language" is definitely a better motivation than "this feature is useful when writing this random piece of RPython software", because we don't want any more to support random pieces of RPython software. RPython is supposed to be used to write interpreters. > str_or_none.patch > A bugfix preventing the call str(o), where o is a "string or None" > object, from segfaulting when o becomes None Preventing a segfault is ok, but then, returning the string "None" is also a bit obscure. It is always better written explicitly, because you can then return whatever you want if it's a None. > oper.patch > Allows the oppertaions int(), and float(), to be defined in methods > of Some... classes. I must say that I don't really understand what this patch is trying to achieve. Do you have your custom SomeXxx classes that represent objects on which you want int() and float() to have custom behavior? That seems pretty much ruled out by the rule "RPython is for writing interpreters"... > setitem.patch > Replace setitem operations with setitem_{key, idx, idx_key} in the > same way as getitem > is replaced depending on what exceptions are caught. That one looks like a good idea. Didn't review the patch in detail so far... > annotator.patch > Allows Some... classes to represent "... and NotImplemented" objects > in the same way as > they can represent "... and None". "RPython is supposed to be used for interpreters" rules it out again. Moreover it's very well to say during annotation that this can be NotImplemented, but you need to do something during RTyping also, to support NotImplemented objects there. That's quite unlikely to be done without adding mess to the two versions (ootype and lltype) of the already-messy rclass.py. A bientot, Armin. From hakan at debian.org Fri Dec 11 11:12:41 2009 From: hakan at debian.org (Hakan Ardo) Date: Fri, 11 Dec 2009 11:12:41 +0100 Subject: [pypy-dev] Special methods In-Reply-To: <20091210180552.GA2842@code0.codespeak.net> References: <1afaf6160912032013l3b081a69j8607ca0de76e4a5a@mail.gmail.com> <20091210180552.GA2842@code0.codespeak.net> Message-ID: On Thu, Dec 10, 2009 at 7:05 PM, Armin Rigo wrote: > writing this random piece of RPython software", because we don't want > any more to support random pieces of RPython software. RPython is > supposed to be used to write interpreters. OK I didn't know. It seems to me that it could be useful more generally... But if you're not interested I'll keep this stuff elsewhere somehow... > >> str_or_none.patch >> ? A bugfix preventing the call str(o), where o is a "string or None" >> object, from segfaulting when o becomes None > > Preventing a segfault is ok, but then, returning the string "None" is > also a bit obscure. ?It is always better written explicitly, because you > can then return whatever you want if it's a None. Well this is what python does, i.e str(None) is the string 'None' in python. Rpython is suppsed to be a subset of python isn't it? > >> oper.patch >> ? Allows the oppertaions int(), and float(), to be defined in methods >> of Some... classes. > > I must say that I don't really understand what this patch is trying to > achieve. ?Do you have your custom SomeXxx classes that represent > objects on which you want int() and float() to have custom behavior? Yes, the object I worked with here was representing a rational number as two integers and the int operation would perform a division between the two. > That seems pretty much ruled out by the rule "RPython is for writing > interpreters"... OK, but isn't it a more uniform design to have all operation handled by SomeXxx methods? > >> setitem.patch >> ? Replace setitem operations with setitem_{key, idx, idx_key} in the >> same way as getitem >> ? is replaced depending on what exceptions are caught. > > That one looks like a good idea. ?Didn't review the patch in detail so > far... It's pretty much a duplication of the corresponding getitem implementation. > >> annotator.patch >> ? Allows Some... classes to represent "... and NotImplemented" objects >> in the same way as >> ? they can represent "... and None". > > "RPython is supposed to be used for interpreters" rules it out again. > Moreover it's very well to say during annotation that this can be > NotImplemented, but you need to do something during RTyping also, to > support NotImplemented objects there. ?That's quite unlikely to be done > without adding mess to the two versions (ootype and lltype) of the > already-messy rclass.py. I needed this in the annotator to chose between calling __radd__ and __add__. By using _annspecialcase_ = 'specialize:argtype(1)' the annotator could prove that a specific specialized __add__ would always return NotImplemented (since this typically only depends on the argument types) and in that case call __radd__ instead. That way the NotImplemented objects would never survive the annotation and there was no need to be able to represent them during the rtyping. -- H?kan Ard? From arigo at tunes.org Fri Dec 11 12:41:16 2009 From: arigo at tunes.org (Armin Rigo) Date: Fri, 11 Dec 2009 12:41:16 +0100 Subject: [pypy-dev] Special methods In-Reply-To: References: <1afaf6160912032013l3b081a69j8607ca0de76e4a5a@mail.gmail.com> <20091210180552.GA2842@code0.codespeak.net> Message-ID: <20091211114116.GA798@code0.codespeak.net> Hi Hakan, On Fri, Dec 11, 2009 at 11:12:41AM +0100, Hakan Ardo wrote: > OK I didn't know. It seems to me that it could be useful more > generally... But if you're not interested I'll keep this stuff > elsewhere somehow... Indeed, the current situation is that we actively don't want to support more RPython features if it's not clear what they could be used for in writing interpreters. We are not interested in supporting RPython as a general-purpose language, because we don't have the resources to do it and because it's not really the goal of the PyPy project. The goal is to give you a good and fast interpreter for full Python. > Well this is what python does, i.e str(None) is the string 'None' in > python. Rpython is suppsed to be a subset of python isn't it? Yes, so in that sense, str(None) returning the string 'None' is the only sane result. What I was complaining about is that it looks pretty pointless to add that rule when writing an interpreter for any different language. It might be useful for debugging, though. A bientot, Armin. From cfbolz at gmx.de Fri Dec 11 12:44:08 2009 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 11 Dec 2009 12:44:08 +0100 Subject: [pypy-dev] Special methods In-Reply-To: <20091211114116.GA798@code0.codespeak.net> References: <1afaf6160912032013l3b081a69j8607ca0de76e4a5a@mail.gmail.com> <20091210180552.GA2842@code0.codespeak.net> <20091211114116.GA798@code0.codespeak.net> Message-ID: <4B223088.6050808@gmx.de> On 12/11/2009 12:41 PM, Armin Rigo wrote: > Hi Hakan, > > On Fri, Dec 11, 2009 at 11:12:41AM +0100, Hakan Ardo wrote: >> OK I didn't know. It seems to me that it could be useful more >> generally... But if you're not interested I'll keep this stuff >> elsewhere somehow... > > Indeed, the current situation is that we actively don't want to support > more RPython features if it's not clear what they could be used for in > writing interpreters. We are not interested in supporting RPython as a > general-purpose language, because we don't have the resources to do it > and because it's not really the goal of the PyPy project. The goal is > to give you a good and fast interpreter for full Python. > >> Well this is what python does, i.e str(None) is the string 'None' in >> python. Rpython is suppsed to be a subset of python isn't it? > > Yes, so in that sense, str(None) returning the string 'None' is the only > sane result. What I was complaining about is that it looks pretty > pointless to add that rule when writing an interpreter for any different > language. It might be useful for debugging, though. It's definitely nicer than getting a segfault. Cheers, Carl Friedrich From andrewfr_ice at yahoo.com Sat Dec 12 01:02:39 2009 From: andrewfr_ice at yahoo.com (Andrew Francis) Date: Fri, 11 Dec 2009 16:02:39 -0800 (PST) Subject: [pypy-dev] Advice needed debugging a Sys.exit error involving py.py and Stackless.py Message-ID: <606760.40853.qm@web112406.mail.gq1.yahoo.com> Hello Folks: I am trying to add a new function, stackless.select() to the Stackless.py module. This select() is loosely based on the select() in Newsqueak/Go. Once I get this select() to work, I would like to figure out some Python syntax to support it. One step deeper into PyPy :-) For the most part, select() is pretty straightforward to implement. In two of my test cases, test4.py and test5.py, the select() function seems to work. Unfortunately, I get a sys.exit() error. I invoke the programme with python ../bin/py.py --withmod_-stackless testX.py and I get (test4.py) THE RESULT FROM SELECT -> hello world schedule(): returned from _schedule_switch schedule(): about to _schedule_switch schedule(): returned from _schedule_switch File "../py.py", line 171, in sys.exit(main_(sys.argv)) File "../py.py", line 142, in main_ verbose=interactiveconfig.verbose): File "/home/andrew/lab/pypy-dist/pypy/interpreter/main.py", line 103, in run_toplevel f() .... File "/home/andrew/lab/pypy-dist/pypy/interpreter/executioncontext.py", line 48, in leave self.framestack.pop() File "/home/andrew/lab/pypy-dist/pypy/interpreter/miscutils.py", line 34, in pop return self.items.pop() IndexError: pop from empty list and (test5.py) THE RESULT FROM SELECT -> hello world schedule(): returned from _schedule_switch schedule(): about to _schedule_switch XXX error, nesting_level = 1 Traceback (most recent call last): File "../py.py", line 171, in sys.exit(main_(sys.argv)) File "../py.py", line 142, in main_ verbose=interactiveconfig.verbose): File "/home/andrew/lab/pypy-dist/pypy/interpreter/main.py", line 103, in run_toplevel f() ... File "/home/andrew/lab/pypy-dist/pypy/interpreter/gateway.py", line 513, in funcrun_obj w_result = activation._run(space, scope_w) File "", line 3, in _run_UWS_AppCoroutine File "/home/andrew/lab/pypy-dist/pypy/module/_stackless/interp_coroutine.py", line 90, in w_switch self.switch() File "/home/andrew/lab/pypy-dist/pypy/rlib/rcoroutine.py", line 256, in switch incoming_frame = state.update(self).switch() AttributeError: 'tuple' object has no attribute 'switch' I wrote a third test, test6.py which blocks select() and then terminates because there is no tasklet on the other end. I do this on purpose. Test6.py works correctly making me suspect something is going wrong with the switching. Although I understand most of the Stackless.py module's code, I am still very green when it comes to PyPy and the various coroutine packages. I understand the PyPy team has not being developing Stackless.py for a while. However I would greatly appreciate insights into figuring out what is going wrong. I would also appreciate insights into how to effectively debug PyPy. Eventually I would like to get into a position where I could support Stackless.py and continue its development. I have enclosed my copy of Stackless.py, the output, and some test scripts. Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: stackless.py Type: text/x-python Size: 21458 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test5.py Type: text/x-python Size: 855 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test6.py Type: text/x-python Size: 686 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: results4 Type: application/octet-stream Size: 1938 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: results5 Type: application/octet-stream Size: 7864 bytes Desc: not available URL: From olliwang at ollix.com Sat Dec 12 19:22:54 2009 From: olliwang at ollix.com (Olli Wang) Date: Sun, 13 Dec 2009 02:22:54 +0800 Subject: [pypy-dev] Failed to translate PyPy Python interpreter on Snow Leopard Message-ID: <1590abce0912121022n370400a1j7b6a74553afc4574@mail.gmail.com> Hi, I was following this page ( http://codespeak.net/pypy/dist/pypy/doc/getting-started-python.html#translating-the-pypy-python-interpreter) and tried to translate the PyPy Python interpreter on Snow Leopard. But unfortunately it always failed unexpectedly after a long time translating. Here's the error messages, any idea? Thanks. [c:writing] implement.c [backendopt:WARNING] constant-folding v1 = getfield(v0, ('inst_co_varnames')): [backendopt:WARNING] AttributeError: 'NoneType' object has no attribute '_getattr' [backendopt:WARNING] constant-folding v1 = getfield(v0, ('inst_co_varnames')): [backendopt:WARNING] AttributeError: 'NoneType' object has no attribute '_getattr' [backendopt:WARNING] constant-folding v1 = getfield(v0, ('inst_co_varnames')): [backendopt:WARNING] AttributeError: 'NoneType' object has no attribute '_getattr' [backendopt:WARNING] constant-folding v1 = getfield(v0, ('inst_co_varnames')): [backendopt:WARNING] AttributeError: 'NoneType' object has no attribute '_getattr' [backendopt:WARNING] constant-folding v1 = getfield(v0, ('inst_co_varnames')): [backendopt:WARNING] AttributeError: 'NoneType' object has no attribute '_getattr' [c:writing] implement_1.c [c:writing] implement_2.c [c:writing] implement_3.c [c:writing] implement_4.c [c:writing] implement_5.c [c:writing] implement_6.c [c:writing] implement_7.c [c:writing] implement_8.c [c:writing] implement_9.c [translation:info] written: /var/folders/m9/m9iGqKJ2EACAKiV+yD8Lb++++TI/-Tmp-/usession-trunk-4/testing_1/testing_1.c [translation:info] Compiling c source... [c:profopt] -c 'from richards import main;main(); from test import pystone; pystone.main()' [platform:execute] gcc -c -O3 -fomit-frame-pointer -mmacosx-version-min=10.4 -mdynamic-no-pic -fprofile-generate -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c -I/usr/include/ffi /var/folders/m9/m9iGqKJ2EACAKiV+yD8Lb++++TI/-Tmp-/usession-trunk-4/testing_1/testing_1.c -o /var/folders/m9/m9iGqKJ2EACAKiV+yD8Lb++++TI/-Tmp-/usession-trunk-4/testing_1/testing_1.o [platform:ERROR] In file included from /Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/src/g_include.h:54, [platform:ERROR] from /var/folders/m9/m9iGqKJ2EACAKiV+yD8Lb++++TI/-Tmp-/usession-trunk-4/testing_1/testing_1.c:42: [platform:ERROR] /Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/src/debug.h: In function 'pypy_read_timestamp': [platform:ERROR] /Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/src/debug.h:127: error: 'CLOCK_THREAD_CPUTIME_ID' undeclared (first use in this function) [platform:ERROR] /Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/src/debug.h:127: error: (Each undeclared identifier is reported only once [platform:ERROR] /Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/src/debug.h:127: error: for each function it appears in.) [Timer] Timings: [Timer] annotate --- 445.6 s [Timer] rtype_lltype --- 587.0 s [Timer] backendopt_lltype --- 305.5 s [Timer] stackcheckinsertion_lltype --- 71.5 s [Timer] database_c --- 433.6 s [Timer] source_c --- 812.9 s [Timer] compile_c --- 8.7 s [Timer] =========================================== [Timer] Total: --- 2664.7 s [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "translate.py", line 277, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/driver.py", line 741, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/tool/taskengine.py", line 116, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/driver.py", line 279, in _do [translation:ERROR] res = func() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/driver.py", line 504, in task_compile_c [translation:ERROR] cbuilder.compile() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/genc.py", line 452, in compile [translation:ERROR] self.executable_name = compiler.build() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/genc.py", line 86, in build [translation:ERROR] return self._do_profbased() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/genc.py", line 94, in _do_profbased [translation:ERROR] exename = profdrv.first() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/genc.py", line 49, in first [translation:ERROR] ofiles = platform._compile_o_files(prof, p_eci) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/platform/__init__.py", line 72, in _compile_o_files [translation:ERROR] ofiles.append(self._compile_c_file(self.cc, cfile, compile_args)) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/platform/posix.py", line 33, in _compile_c_file [translation:ERROR] self._execute_c_compiler(cc, args, oname) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/platform/__init__.py", line 106, in _execute_c_compiler [translation:ERROR] self._handle_error(returncode, stderr, stdout, outname) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/platform/__init__.py", line 117, in _handle_error [translation:ERROR] raise CompilationError(stdout, stderr) [translation:ERROR] CompilationError: -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh at lutzhaase.com Sat Dec 12 20:03:04 2009 From: sh at lutzhaase.com (Sven-Hendrik Haase) Date: Sat, 12 Dec 2009 20:03:04 +0100 Subject: [pypy-dev] JIT issues on x86_64 Message-ID: <4B23E8E8.2070708@lutzhaase.com> I have issues translating JIT on x86_64 architecture as opposed to i686. I know this issue from Psyco which was never meant to work on other architectures due to low-level optimizations. However, I think it was one of PyPy's goals to make the JIT available to more architecture (wasn't it?). Should I be able to successfully translate the JIT at this point or is it supposed to break due to missing implementation? -- Sven-Hendrik From santagada at gmail.com Sat Dec 12 20:25:45 2009 From: santagada at gmail.com (Leonardo Santagada) Date: Sat, 12 Dec 2009 17:25:45 -0200 Subject: [pypy-dev] JIT issues on x86_64 In-Reply-To: <4B23E8E8.2070708@lutzhaase.com> References: <4B23E8E8.2070708@lutzhaase.com> Message-ID: On Dec 12, 2009, at 5:03 PM, Sven-Hendrik Haase wrote: > I have issues translating JIT on x86_64 architecture as opposed to i686. > I know this issue from Psyco which was never meant to work on other > architectures due to low-level optimizations. However, I think it was > one of PyPy's goals to make the JIT available to more architecture > (wasn't it?). Should I be able to successfully translate the JIT at this > point or is it supposed to break due to missing implementation? There isn't a JIT backend for x86_64 yet, so there is no way to get a PyPy with JIT in 64 bit right now, unfortunately. But you are right one of the goals is to make it available in more architectures, and that is already made simpler by separating the backend code of the jit from the rest of the implementation. No one is currently working on it as the focus for the next release is getting the jit solid and fast on 32 bit machines. If you want to port is to x86_64 PyPy people are probably going to help you to do it, but if you are not you can follow the developments on the blog[1] because it is going to be announced there when it is at least ready for testing :) [1] http://morepypy.blogspot.com/ ps: Psyco doesn't actually have anything prohibiting it to run on 64bit it is just way more difficult to work with it than with PyPy. ps2: A better version of this answer must be in the site somewhere, as more and more people will be asking this when anything about the JIT is posted on the blog... maybe a faq that gets linked to in every post. -- Leonardo Santagada santagada at gmail.com From jandemooij at gmail.com Sat Dec 12 20:23:23 2009 From: jandemooij at gmail.com (Jan de Mooij) Date: Sat, 12 Dec 2009 20:23:23 +0100 Subject: [pypy-dev] JIT issues on x86_64 In-Reply-To: <4B23E8E8.2070708@lutzhaase.com> References: <4B23E8E8.2070708@lutzhaase.com> Message-ID: On Sat, Dec 12, 2009 at 8:03 PM, Sven-Hendrik Haase wrote: > Should I be able to successfully translate the JIT at this > point or is it supposed to break due to missing implementation? The JIT does not support 64-bit yet. The good news is that it's much easier to write an x86-64 backend for Pypy than for Psyco - that was indeed one of the original goals. Regards, Jan > -- Sven-Hendrik > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From sh at lutzhaase.com Sat Dec 12 20:35:12 2009 From: sh at lutzhaase.com (Sven-Hendrik Haase) Date: Sat, 12 Dec 2009 20:35:12 +0100 Subject: [pypy-dev] JIT issues on x86_64 In-Reply-To: References: <4B23E8E8.2070708@lutzhaase.com> Message-ID: <4B23F070.1000501@lutzhaase.com> On 12.12.2009 20:25, Leonardo Santagada wrote: > On Dec 12, 2009, at 5:03 PM, Sven-Hendrik Haase wrote: > > >> I have issues translating JIT on x86_64 architecture as opposed to i686. >> I know this issue from Psyco which was never meant to work on other >> architectures due to low-level optimizations. However, I think it was >> one of PyPy's goals to make the JIT available to more architecture >> (wasn't it?). Should I be able to successfully translate the JIT at this >> point or is it supposed to break due to missing implementation? >> > There isn't a JIT backend for x86_64 yet, so there is no way to get a PyPy with JIT in 64 bit right now, unfortunately. But you are right one of the goals is to make it available in more architectures, and that is already made simpler by separating the backend code of the jit from the rest of the implementation. No one is currently working on it as the focus for the next release is getting the jit solid and fast on 32 bit machines. > > If you want to port is to x86_64 PyPy people are probably going to help you to do it, but if you are not you can follow the developments on the blog[1] because it is going to be announced there when it is at least ready for testing :) > > [1] http://morepypy.blogspot.com/ > > > ps: Psyco doesn't actually have anything prohibiting it to run on 64bit it is just way more difficult to work with it than with PyPy. > ps2: A better version of this answer must be in the site somewhere, as more and more people will be asking this when anything about the JIT is posted on the blog... maybe a faq that gets linked to in every post. > > -- > Leonardo Santagada > santagada at gmail.com > > > > > Thanks for the answers (also Jan). I haven't looked at it at all yet but I imagine it will involve a lot of assembly or very low-level C? And having this in the FAQ till then would be a good idea I imagine. Also have the translator fail on different architectures for JIT with a clear error that it isn't implemented yet. -- Sven-Hendrik From arigo at tunes.org Sun Dec 13 12:25:43 2009 From: arigo at tunes.org (Armin Rigo) Date: Sun, 13 Dec 2009 12:25:43 +0100 Subject: [pypy-dev] JIT issues on x86_64 In-Reply-To: <4B23F070.1000501@lutzhaase.com> References: <4B23E8E8.2070708@lutzhaase.com> <4B23F070.1000501@lutzhaase.com> Message-ID: <20091213112543.GA12061@code0.codespeak.net> Hi, On Sat, Dec 12, 2009 at 08:35:12PM +0100, Sven-Hendrik Haase wrote: > I imagine it will involve a lot of assembly or very low-level C? You have to know assembly, but program in Python. > Also have the translator fail on different architectures for JIT with a > clear error that it isn't implemented yet. It's supposed to. When I try it, I get the following error: ProcessorAutodetectError: unsupported cpu 'x86_64' Are you sure you aren't running a 32-bit version of Python? If you are, then you will be getting a 32-bit version of pypy-c-jit too, and it should work. Maybe you have to tweak the gcc options to compile it, though. The point is that the produced '.c' files should be for 32-bit then. (I guess that given that we generate .c files specifically for 32-bit or 64-bit, these files should at least contain a '#error' if you try to compile them on a different word size.) A bientot, Armin. From arigo at tunes.org Sun Dec 13 13:08:53 2009 From: arigo at tunes.org (Armin Rigo) Date: Sun, 13 Dec 2009 13:08:53 +0100 Subject: [pypy-dev] Failed to translate PyPy Python interpreter on Snow Leopard In-Reply-To: <1590abce0912121022n370400a1j7b6a74553afc4574@mail.gmail.com> References: <1590abce0912121022n370400a1j7b6a74553afc4574@mail.gmail.com> Message-ID: <20091213120853.GA15821@code0.codespeak.net> Hi Olli, On Sun, Dec 13, 2009 at 02:22:54AM +0800, Olli Wang wrote: > and tried to translate the PyPy Python interpreter on Snow Leopard. But > unfortunately it always failed unexpectedly after a long time translating. > Here's the error messages, any idea? Thanks. Ah, it's about clock_gettime(), which is a standard POSIX function that does not exist on Mac OS/X. Should be fixed now; can you try again? You can try by compiling a much smaller program than the whole PyPy interpreter first. For example: ./translate.py targetgcbench A bientot, Armin. From olliwang at ollix.com Sun Dec 13 17:03:51 2009 From: olliwang at ollix.com (Olli Wang) Date: Mon, 14 Dec 2009 00:03:51 +0800 Subject: [pypy-dev] Failed to translate PyPy Python interpreter on Snow Leopard In-Reply-To: <1590abce0912130801h772a6861q61248c42ea9db53a@mail.gmail.com> References: <1590abce0912121022n370400a1j7b6a74553afc4574@mail.gmail.com> <20091213120853.GA15821@code0.codespeak.net> <1590abce0912130801h772a6861q61248c42ea9db53a@mail.gmail.com> Message-ID: <1590abce0912130803s2ac4ee8bnfa4ea2408e5f36a7@mail.gmail.com> Hi, thanks for replying. I tried the targetgcbench program but still failed. Here's the error message: [translation:info] written: /var/folders/m9/m9iGqKJ2EACAKiV+yD8Lb++++TI/-Tmp-/usession-trunk-1/testing_1/testing_1.c [translation:info] Compiling c source... [platform:execute] gcc -c -O3 -fomit-frame-pointer -mmacosx-version-min=10.4 -mdynamic-no-pic -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c /var/folders/m9/m9iGqKJ2EACAKiV+yD8Lb++++TI/-Tmp-/usession-trunk-1/testing_1/testing_1.c -o /var/folders/m9/m9iGqKJ2EACAKiV+yD8Lb++++TI/-Tmp-/usession-trunk-1/testing_1/testing_1.o [platform:ERROR] In file included from /Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/src/g_include.h:54, [platform:ERROR] from /var/folders/m9/m9iGqKJ2EACAKiV+yD8Lb++++TI/-Tmp-/usession-trunk-1/testing_1/testing_1.c:42: [platform:ERROR] /Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/src/debug.h: In function 'pypy_read_timestamp': [platform:ERROR] /Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/src/debug.h:134: error: incompatible type for argument 1 of 'gettimeofday' [Timer] Timings: [Timer] annotate --- 0.7 s [Timer] rtype_lltype --- 2.3 s [Timer] backendopt_lltype --- 0.5 s [Timer] stackcheckinsertion_lltype --- 0.0 s [Timer] database_c --- 9.2 s [Timer] source_c --- 2.0 s [Timer] compile_c --- 0.5 s [Timer] ========================================= [Timer] Total: --- 15.3 s [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "translate.py", line 277, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/driver.py", line 741, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/tool/taskengine.py", line 116, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/driver.py", line 279, in _do [translation:ERROR] res = func() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/driver.py", line 504, in task_compile_c [translation:ERROR] cbuilder.compile() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/genc.py", line 452, in compile [translation:ERROR] self.executable_name = compiler.build() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/genc.py", line 87, in build [translation:ERROR] return self._build() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/c/genc.py", line 82, in _build [translation:ERROR] outputfilename=self.outputfilename) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/platform/__init__.py", line 63, in compile [translation:ERROR] ofiles = self._compile_o_files(cfiles, eci, standalone) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/platform/__init__.py", line 72, in _compile_o_files [translation:ERROR] ofiles.append(self._compile_c_file(self.cc, cfile, compile_args)) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/platform/posix.py", line 33, in _compile_c_file [translation:ERROR] self._execute_c_compiler(cc, args, oname) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/platform/__init__.py", line 106, in _execute_c_compiler [translation:ERROR] self._handle_error(returncode, stderr, stdout, outname) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/platform/__init__.py", line 117, in _handle_error [translation:ERROR] raise CompilationError(stdout, stderr) [translation:ERROR] CompilationError: On Sun, Dec 13, 2009 at 8:08 PM, Armin Rigo wrote: > Hi Olli, > > On Sun, Dec 13, 2009 at 02:22:54AM +0800, Olli Wang wrote: > > and tried to translate the PyPy Python interpreter on Snow Leopard. But > > unfortunately it always failed unexpectedly after a long time > translating. > > Here's the error messages, any idea? Thanks. > > Ah, it's about clock_gettime(), which is a standard POSIX function that > does not exist on Mac OS/X. Should be fixed now; can you try again? > > You can try by compiling a much smaller program than the whole PyPy > interpreter first. For example: ./translate.py targetgcbench > > > A bientot, > > Armin. > -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From olliwang at ollix.com Sun Dec 13 17:22:53 2009 From: olliwang at ollix.com (Olli Wang) Date: Mon, 14 Dec 2009 00:22:53 +0800 Subject: [pypy-dev] Failed to translate PyPy Python interpreter on Snow Leopard In-Reply-To: <20091213160541.GA31502@code0.codespeak.net> References: <1590abce0912121022n370400a1j7b6a74553afc4574@mail.gmail.com> <20091213120853.GA15821@code0.codespeak.net> <1590abce0912130801h772a6861q61248c42ea9db53a@mail.gmail.com> <20091213160541.GA31502@code0.codespeak.net> Message-ID: <1590abce0912130822w32bfd75dv5237648833b745d8@mail.gmail.com> Wow, so fast! The targetgcbench works now. Now I'm trying to translate the Python interpreter again. Thanks for your help. :) On Mon, Dec 14, 2009 at 12:05 AM, Armin Rigo wrote: > Hi, > > Bah, a typo. Try again? > > > Armin > -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Sun Dec 13 20:11:50 2009 From: arigo at tunes.org (Armin Rigo) Date: Sun, 13 Dec 2009 20:11:50 +0100 Subject: [pypy-dev] Advice needed debugging a Sys.exit error involving py.py and Stackless.py In-Reply-To: <606760.40853.qm@web112406.mail.gq1.yahoo.com> References: <606760.40853.qm@web112406.mail.gq1.yahoo.com> Message-ID: <20091213191150.GA10380@code0.codespeak.net> Hi Andrew, I must warn you that you may not get much attention these days. I can only say that I'm sorry about it. As you found out, the stackless part of PyPy is sleeping nowadays -- it still works, and is tested, but that's about it. A bientot, Armin. From olliwang at ollix.com Sun Dec 13 20:22:13 2009 From: olliwang at ollix.com (Olli Wang) Date: Mon, 14 Dec 2009 03:22:13 +0800 Subject: [pypy-dev] What does MemoryError mean? Message-ID: <1590abce0912131122n43848652oe34e733edfc17263@mail.gmail.com> Hi, I was trying to translate Python interpreter using the JIT backend on Snow Leopard (don't know if PyPy supports jit on Snow Leopard now). But I got a MemoryError, does it mean I do not have enough memory? I have 4GB RAM on my computer and most of them should be available when translating. Here's the error message: [rtyper] specializing: 78200 / 80335 blocks (97%) .....+%+#%*+...*%......... [rtyper] specializing: 80400 / 80467 blocks (99%) [rtyper] -=- specialized 2310 more blocks -=- [rtyper] -=- specialized 0 more blocks -=- .... [rtyper] -=- specialized 13 more blocks -=- [translation:info] JIT compiler generation... [Timer] Timings: [Timer] annotate --- 446.3 s [Timer] rtype_lltype --- 590.8 s [Timer] pyjitpl_lltype --- 0.2 s [Timer] =========================================== [Timer] Total: --- 1037.2 s [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "/usr/local/bin/translate.py", line 277, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/driver.py", line 741, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/tool/taskengine.py", line 116, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/driver.py", line 279, in _do [translation:ERROR] res = func() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/translator/driver.py", line 377, in task_pyjitpl_lltype [translation:ERROR] backend_name=self.config.translation.jit_backend, inline=True) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/jit/metainterp/warmspot.py", line 35, in apply_jit [translation:ERROR] kwds['CPUClass'] = getcpuclass(backend_name) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/jit/backend/detect_cpu.py", line 54, in getcpuclass [translation:ERROR] backend_name = autodetect() [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/jit/backend/detect_cpu.py", line 48, in autodetect [translation:ERROR] if not detect_sse2(): [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/jit/backend/x86/detect_sse2.py", line 7, in detect_sse2 [translation:ERROR] data = alloc(4096) [translation:ERROR] File "/Users/olliwang/workspace/repo/pypy-trunk/pypy/rlib/rmmap.py", line 638, in alloc [translation:ERROR] raise MemoryError [translation:ERROR] MemoryError -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Sun Dec 13 20:30:30 2009 From: arigo at tunes.org (Armin Rigo) Date: Sun, 13 Dec 2009 20:30:30 +0100 Subject: [pypy-dev] What does MemoryError mean? In-Reply-To: <1590abce0912131122n43848652oe34e733edfc17263@mail.gmail.com> References: <1590abce0912131122n43848652oe34e733edfc17263@mail.gmail.com> Message-ID: <20091213193030.GA11896@code0.codespeak.net> Hi, On Mon, Dec 14, 2009 at 03:22:13AM +0800, Olli Wang wrote: > Hi, I was trying to translate Python interpreter using the JIT backend on > Snow Leopard (don't know if PyPy supports jit on Snow Leopard now). There is a 32-bit-versus-64-bit issue with Snow Leopard. See the mails from today, topic "JIT issues on x86_64". A bientot, Armin. From olliwang at ollix.com Mon Dec 14 11:30:52 2009 From: olliwang at ollix.com (Olli Wang) Date: Mon, 14 Dec 2009 18:30:52 +0800 Subject: [pypy-dev] pypy-jvm doesn't work? Message-ID: <1590abce0912140230g5807b6e4vb4b173751eeb502d@mail.gmail.com> Hi, I tried to execute the compiled Python interpreter with jvm backend on both Gentoo Linux(amd64) and Snow Leopard. But unfortunately both of them failed to start. I simply ran "./translate.py --backend=jvm targetpypystandalone.py" and "pypy-jvm" on both computer. Do I miss something? Thanks. == Error messages on Gentoo Linux (amd64) Exception in thread "main" java.lang.VerifyError: (class: pypy/ConstantInit_0, method: constant_init signature: ()V) Expecting to find long on stack at pypy.ConstantInit.init(ConstantInit.j:6) at pypy.Main.(Main.j:26) Could not find the main class: pypy.Main. Program will exit. == Error messages on Snow Leopard (I also tried to fix the "Adobe Unit Types.osax" by following this page ( http://www.davidchinphoto.com/snow-leopard-and-adobe-unit-types-osax/), but still failed.) 2009-12-14 18:25:20.913 java[9944:1707] Error loading /Library/ScriptingAdditions/Adobe Unit Types copy.osax/Contents/MacOS/Adobe Unit Types: dlopen(/Library/ScriptingAdditions/Adobe Unit Types copy.osax/Contents/MacOS/Adobe Unit Types, 262): no suitable image found. Did find: /Library/ScriptingAdditions/Adobe Unit Types copy.osax/Contents/MacOS/Adobe Unit Types: no matching architecture in universal wrapper Exception in thread "main" java.lang.VerifyError: (class: pypy/ConstantInit_0, method: constant_init signature: ()V) Expecting to find long on stack at pypy.ConstantInit.init(ConstantInit.j:6) at pypy.Main.(Main.j:26) java: OpenScripting.framework - scripting addition "/Library/ScriptingAdditions/Adobe Unit Types copy.osax" declares no loadable handlers. 2009-12-14 18:25:20.923 java[9944:1707] Error loading /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: dlopen(/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types, 262): no suitable image found. Did find: /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: no matching architecture in universal wrapper java: OpenScripting.framework - scripting addition "/Library/ScriptingAdditions/Adobe Unit Types.osax" declares no loadable handlers. -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From anto.cuni at gmail.com Mon Dec 14 11:39:59 2009 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 14 Dec 2009 11:39:59 +0100 Subject: [pypy-dev] pypy-jvm doesn't work? In-Reply-To: <1590abce0912140230g5807b6e4vb4b173751eeb502d@mail.gmail.com> References: <1590abce0912140230g5807b6e4vb4b173751eeb502d@mail.gmail.com> Message-ID: <4B2615FF.3090601@gmail.com> Hi Olli, Olli Wang wrote: > Hi, I tried to execute the compiled Python interpreter with jvm backend > on both Gentoo Linux(amd64) and Snow Leopard. > But unfortunately both of them failed to start. I simply ran > "./translate.py --backend=jvm targetpypystandalone.py" and "pypy-jvm" on > both computer. Do I miss something? Thanks. > > == > Error messages on Gentoo Linux (amd64) > > Exception in thread "main" java.lang.VerifyError: (class: > pypy/ConstantInit_0, method: constant_init signature: ()V) Expecting to > find long on stack > at pypy.ConstantInit.init(ConstantInit.j:6) > at pypy.Main.(Main.j:26) > Could not find the main class: pypy.Main. Program will exit. I suppose it's a 32/64 bit issue again: the problem is that when you run ./translate.py with a 64 bit python, it assumes that 'int' variables are 64 bits, but on the JVM they are always 32 bit. For what I know, the CLI backend has exactly the same problem. As a workaround, you can try to run translate.py under a 32bit chroot (which works for sure, as I use it daily to develop pypy) or with a 32bit python (which should work, but I've never tried). ciao, Anto From cfbolz at gmx.de Mon Dec 14 13:45:44 2009 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 14 Dec 2009 13:45:44 +0100 Subject: [pypy-dev] Advice needed debugging a Sys.exit error involving py.py and Stackless.py In-Reply-To: <606760.40853.qm@web112406.mail.gq1.yahoo.com> References: <606760.40853.qm@web112406.mail.gq1.yahoo.com> Message-ID: <4B263378.3000102@gmx.de> Hi Andrew, On 12/12/2009 01:02 AM, Andrew Francis wrote: > I am trying to add a new function, stackless.select() to the Stackless.py module. This select() is loosely based on the select() in Newsqueak/Go. Once I get this select() to work, I would like to figure out some Python > syntax to support it. One step deeper into PyPy :-) > > For the most part, select() is pretty straightforward to implement. > In two of my test cases, test4.py and test5.py, the select() function seems to work. Unfortunately, I get a sys.exit() error. unfortunately I don't really have time to dig deeply into your code. I just wanted to give you the following hint: if you install greenlets for CPython, you can test the lib/stackless.py code on top of CPython. This makes it possible to distinguish problems in the pure app-level code in lib/stackless.py from problems in the RPython-implementation of coroutines in PyPy. Given that you are changing the applevel code only, it is much more likely that the problem is actually caused by something you changed. Cheers, Carl Friedrich From andrewfr_ice at yahoo.com Thu Dec 17 03:52:32 2009 From: andrewfr_ice at yahoo.com (Andrew Francis) Date: Wed, 16 Dec 2009 18:52:32 -0800 (PST) Subject: [pypy-dev] Advice needed debugging a Sys.exit error involving py.py and Stackless.py Message-ID: <92152.3994.qm@web112417.mail.gq1.yahoo.com> Hello Armin: --- On Sun, 12/13/09, Armin Rigo wrote: > I must warn you that you may not get much attention these > days. I understand. I understand the PyPy team is busy. And I have privately received some useful feedback. > I can only say that I'm sorry about it.? As you found out, > the stackless part of PyPy is sleeping nowadays -- it still works, >and is tested, but that's about it. Well if I can get select() to work, I would be more than happy to maintain and expand stackless.py. stackless.py is too cool and important to be just left sleeping. Meanwhile, I have written much simplified tests. I get the same errors. Given that problems revolve around context switches in schedule() and the probably the main tasklet, I believe there are modules other than stackless.py that I need to modify. I also need to understand some of the terminology - for instance, nesting_level. Does that refer to frames. Or tasklets or coroutines? Again, I think there is something very simple at the bottom of all this - I am just a newbie. Cheers, Andrew From olliwang at ollix.com Thu Dec 17 13:26:35 2009 From: olliwang at ollix.com (Olli Wang) Date: Thu, 17 Dec 2009 20:26:35 +0800 Subject: [pypy-dev] Questions about RPython Message-ID: <1590abce0912170426v6e94b500n5709614251071529@mail.gmail.com> Hi, I was trying to develop a tiny application using RPython and I have a few of questions. Obviously, RPython has the advantage of translating the code to various backends so we can get much better performance than Python scripts running on top of any Python implementation, so I was wondering, is it possible to rewrite the full Python's standard library using RPython so people can treat RPython as a general purpose programming language? (is that a good idea?) BTW, in my tiny experiment application. I want to create an empty file and write something there. Unfortunately, the open() function is not supported in RPython and the os.open() can't create a new file if not existed. So how do I `touch` a new file in RPython? Thanks. -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin at python.org Thu Dec 17 13:48:47 2009 From: benjamin at python.org (Benjamin Peterson) Date: Thu, 17 Dec 2009 06:48:47 -0600 Subject: [pypy-dev] Questions about RPython In-Reply-To: <1590abce0912170426v6e94b500n5709614251071529@mail.gmail.com> References: <1590abce0912170426v6e94b500n5709614251071529@mail.gmail.com> Message-ID: <1afaf6160912170448he09131bhbb0987fcaa1a696c@mail.gmail.com> 2009/12/17 Olli Wang : > Hi, I was trying to develop a tiny application using RPython and I have a > few of questions. Obviously, RPython has the advantage of translating the > code to various backends so we can get much better performance than Python > scripts running on top of any Python implementation, so I was wondering, is > it possible to rewrite the full Python's standard library using RPython so > people can treat RPython as a general purpose programming language? (is that > a good idea?) We intend RPython to be a language for writing interpreters not as a general purpose programming language. > BTW, in my tiny experiment application. I want to create an empty file and > write something there. Unfortunately, the open() function is not supported > in RPython and the os.open() can't create a new file if not existed. So how > do I `touch` a new file in RPython? Thanks. You're probably not passing the right flags to os.open. -- Regards, Benjamin From elec.lomy.ru at gmail.com Thu Dec 17 13:48:42 2009 From: elec.lomy.ru at gmail.com (Alexander D. Sedov) Date: Thu, 17 Dec 2009 15:48:42 +0300 Subject: [pypy-dev] Questions about RPython In-Reply-To: <1590abce0912170426v6e94b500n5709614251071529@mail.gmail.com> References: <1590abce0912170426v6e94b500n5709614251071529@mail.gmail.com> Message-ID: <1261054122.3936.0.camel@sedovs.local> ? ???, 17/12/2009 ? 20:26 +0800, Olli Wang ?????: > Hi, I was trying to develop a tiny application using RPython and I > have a few of questions. Obviously, RPython has the advantage of > translating the code to various backends so we can get much better > performance than Python scripts running on top of any Python > implementation, so I was wondering, is it possible to rewrite the full > Python's standard library using RPython so people can treat RPython as > a general purpose programming language? (is that a good idea?) > > > BTW, in my tiny experiment application. I want to create an empty file > and write something there. Unfortunately, the open() function is not > supported in RPython and the os.open() can't create a new file if not > existed. So how do I `touch` a new file in RPython? Thanks. Just use os.O_CREAT flag after existence check. From amauryfa at gmail.com Thu Dec 17 14:47:00 2009 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Thu, 17 Dec 2009 14:47:00 +0100 Subject: [pypy-dev] Questions about RPython In-Reply-To: <1590abce0912170426v6e94b500n5709614251071529@mail.gmail.com> References: <1590abce0912170426v6e94b500n5709614251071529@mail.gmail.com> Message-ID: Hi, 2009/12/17 Olli Wang > Hi, I was trying to develop a tiny application using RPython and I have a > few of questions. Obviously, RPython has the advantage of translating the > code to various backends so we can get much better performance than Python > scripts running on top of any Python implementation, so I was wondering, is > it possible to rewrite the full Python's standard library using RPython so > people can treat RPython as a general purpose programming language? (is that > a good idea?) > I don't think so. RPython is a statically typed language, even if types are not explicit in the code, but determined by the translator. For example, os.open() accepts a string for its first argument, so it cannot accept unicode. A RPython library would be quite different from the CPython standard library. -- Amaury Forgeot d'Arc -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Fri Dec 18 12:13:59 2009 From: arigo at tunes.org (Armin Rigo) Date: Fri, 18 Dec 2009 12:13:59 +0100 Subject: [pypy-dev] Leysin Winter Sprint: 23-30th January 2010 In-Reply-To: <07BB8FB8-EEC2-4672-908F-974F24E3B4DC@gmail.com> References: <20091202124318.GA17481@code0.codespeak.net> <20091203151918.GA18204@code0.codespeak.net> <07BB8FB8-EEC2-4672-908F-974F24E3B4DC@gmail.com> Message-ID: <20091218111359.GC23039@code0.codespeak.net> Hi Leonardo, hi all, On Thu, Dec 03, 2009 at 02:57:37PM -0200, Leonardo Santagada wrote: > Talked on the channel about doing it during the pycon atlanta. > Would the main developers go there? I fear not. There will be 1 or 2 of us at PyCon, but setting up a PyPy sprint is not really useful. There are several factors, but mostly it's that it's quite unclear what kind of project can be done in the JIT in 2-3 days by people that did not work with PyPy so far; it might work, but it would require enough PyPy people to be there and to be not completely knocked out by the time lag. FWIW I am planning to have the sprint in Leysin sometimes around Easter. A bientot, Armin. From andrewfr_ice at yahoo.com Fri Dec 18 20:08:28 2009 From: andrewfr_ice at yahoo.com (Andrew Francis) Date: Fri, 18 Dec 2009 11:08:28 -0800 (PST) Subject: [pypy-dev] Success and Thanks! : Advice needed debugging a Sys.exit error Message-ID: <172694.28058.qm@web112414.mail.gq1.yahoo.com> Hi Carl and Stephan: >Message: 4 >Date: Mon, 14 Dec 2009 13:45:44 +0100 >From: Carl Friedrich Bolz >Subject: Re: [pypy-dev] Advice needed debugging a Sys.exit error > involving py.py and Stackless.py >To: pypy-dev at codespeak.net >Message-ID: <4B263378.3000102 at gmx.de> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed CB>unfortunately I don't really have time to dig deeply into your code. I CB>just wanted to give you the following hint: if you install greenlets for CB>CPython, you can test the lib/stackless.py code on top of CPython. Carl, I took your advice and ran stackless.py on top of greenlets and CPython. The test programmes worked! I will write more tests in the days to come. However this is a really need approach. This should be documented somewhere for other folks to try! CB>This makes it possible to distinguish problems in the pure app-level CB>code in lib/stackless.py from problems in the RPython-implementation of CB>coroutines in PyPy. Given that you are changing the applevel code only, CB>it is much more likely that the problem is actually caused by something CB>you changed. I changed only stackless.py. In turn, I changed very little code outside of adding the select function. I am not sure what I am looking for but I started to look at pypy/module/_stackless for clues. If I had to guess, I am thinking a culprit may involve stackless_flags - I am not setting a flag in the correct spot in the new code. Once again, thanks for your help. Cheers, Andrew From olliwang at ollix.com Sat Dec 19 08:41:33 2009 From: olliwang at ollix.com (Olli Wang) Date: Sat, 19 Dec 2009 15:41:33 +0800 Subject: [pypy-dev] The builtin tuple() function doesn't work Message-ID: <1590abce0912182341r184646efh6234d1cee3547333@mail.gmail.com> Hi, I tried to convert a list to tuple in RPython such as tuple([1, 2, 3]), but it would cause errors during translating. Is that a bug? I did find the builtin_tuple() function in http://codespeak.net/pypy/dist/pypy/annotation/builtin.py, so it should work, right? Thanks. -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From amauryfa at gmail.com Sat Dec 19 09:13:38 2009 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Sat, 19 Dec 2009 09:13:38 +0100 Subject: [pypy-dev] The builtin tuple() function doesn't work In-Reply-To: <1590abce0912182341r184646efh6234d1cee3547333@mail.gmail.com> References: <1590abce0912182341r184646efh6234d1cee3547333@mail.gmail.com> Message-ID: Hello,Rpy 2009/12/19 Olli Wang > > Hi, I tried to convert a list to tuple in RPython such as tuple([1, 2, 3]), > but it would cause errors during translating. > Is that a bug? I did find the?builtin_tuple() function > in?http://codespeak.net/pypy/dist/pypy/annotation/builtin.py, > so it should work, right? A RPython tuple is very different from a list. Please see http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#object-restrictions For me, a RPython tuple is similar to the python's collection.namedtuple object: the fields (number and types) are fixed, and if you can access items by their position in the tuple, the index value must be known at translation time (for type inference to succeed). It is very similar to the C++ boost::tuple template class. Yet another reason why it would be difficult to rewrite the python standard library in RPython... -- Amaury Forgeot d'Arc From elec.lomy.ru at gmail.com Sat Dec 19 19:17:02 2009 From: elec.lomy.ru at gmail.com (Alexander D. Sedov) Date: Sat, 19 Dec 2009 21:17:02 +0300 Subject: [pypy-dev] Questions about PyPy In-Reply-To: References: <1590abce0912182341r184646efh6234d1cee3547333@mail.gmail.com> Message-ID: <1261246622.13353.17.camel@sedovs.local> Hello, I have some questions about PyPy. I want to use PyPy with its great coroutines in my project. But I already use numpy for it. Is there a working numpy port for PyPy? BTW, when I looked through exist Numeric code, I noticed a typo: In function 'get_slice': dim = (stop-start)//step stride = self.strides[i]*step dims.append( dim ) > strides.append( step ) I think that author meant 'strides.append(stride)'. Question 2 is about `py` library distributed with PyPy, is it unmodified? There were some great changes from version 1.0 to 1.1, so I want to know if I may just replace or have to patch. Question 3 is about `stackless` module. As far as I can understand from mailing list it is not supported for long time. So, because I need it and I think that I have understood it, I can support it if you'll let. Question 4 is about `distributed` module. I know it doesn't work, but what does line > from py.__.green.msgstruct import decodemessage, message mean? I tried to locate `green` module, but located no one. Thanks, and sorry for my bad English. -- Alexander D. Sedov From olliwang at ollix.com Sun Dec 20 21:13:15 2009 From: olliwang at ollix.com (Olli Wang) Date: Mon, 21 Dec 2009 04:13:15 +0800 Subject: [pypy-dev] AES Implementation in RPython Message-ID: <1590abce0912201213j3b864a86q7e371a77242ffe66@mail.gmail.com> Hi, I implemented the AES in RPython and made some benchmarks. You may want to take a look at http://olliwang.com/2009/12/20/aes-implementation-in-rpython/ I know that RPython is designed to write Python interpreter, but the translated C performance is really really impressive. If RPython could be integrated into normal Python code seamlessly, that would be fantastic! -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Sun Dec 20 22:13:06 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sun, 20 Dec 2009 22:13:06 +0100 Subject: [pypy-dev] AES Implementation in RPython In-Reply-To: <1590abce0912201213j3b864a86q7e371a77242ffe66@mail.gmail.com> References: <1590abce0912201213j3b864a86q7e371a77242ffe66@mail.gmail.com> Message-ID: <693bc9ab0912201313w14a78204id8deeecb37b0b856@mail.gmail.com> On Sun, Dec 20, 2009 at 9:13 PM, Olli Wang wrote: > Hi, I implemented the AES in RPython and made some benchmarks. > You may want to take a look > at?http://olliwang.com/2009/12/20/aes-implementation-in-rpython/ > > I know that RPython is designed to write Python interpreter, but the > translated C performance is really really impressive. > If RPython could be integrated into normal Python code seamlessly, that > would be fantastic! Hi. There is a possibility to implement this, but none of core developers is willing to spend time on this. However, you might be interested that on top of pypy-c with JIT (compiled interpreter, but pypy one and not CPython), it's over 5x faster than CPython. This is maybe not 150x, but something anyway. Cheers, fijal From olliwang at ollix.com Mon Dec 21 07:59:13 2009 From: olliwang at ollix.com (Olli Wang) Date: Mon, 21 Dec 2009 14:59:13 +0800 Subject: [pypy-dev] Failed to translate interpreter to JIT on Windows Message-ID: <1590abce0912202259s4177f239o7fb9c984c44ba974@mail.gmail.com> Hi, I was trying to translate Python interpreter to JIT backend on WIndows but failed. It's no problem to translate it to C backend. Do I miss something? Thanks. [c:writing] implement_40.c [c:writing] implement_41.c [c:writing] implement_42.c [translation:info] written: c:\docume~1\olliwa~1\locals~1\temp\usession-26\testi ng_1\testing_1.c [translation:info] Compiling c source... [platform:execute] make in c:\docume~1\olliwa~1\locals~1\temp\usession-26\testin g_1 [platform:ERROR] cl : Command line warning D9024 : unrecognized source file type 'Wang\\pypy-trunk\\pypy\\translator\\c', object file assumed [platform:ERROR] cl : Command line warning D9027 : source file 'Wang\\pypy-trunk \\pypy\\translator\\c' ignored [platform:ERROR] cl : Command line warning D9024 : unrecognized source file type 'Wang\\pypy-trunk\\pypy\\translator\\c\\src\\libffi_msvc', object file assumed [platform:ERROR] cl : Command line warning D9027 : source file 'Wang\\pypy-trunk \\pypy\\translator\\c\\src\\libffi_msvc' ignored [platform:ERROR] NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"' : return code '0x2' [platform:ERROR] Stop. [platform:ERROR] cl.exe /nologo /MD /O2 /Oi /Ob1 /c /FAs /Fatesting_1.s testing_1.c /Ic:\\Python26\\include /IC:\\cygwin\\home\\Olli Wang\\pypy-trunk\\ pypy\\translator\\c /IC:\\cygwin\\home\\Olli Wang\\pypy-trunk\\pypy\\translator \\c\\src\\libffi_msvc [platform:ERROR] testing_1.c [platform:ERROR] c:\documents and settings\olli wang\local settings\temp\usessio n-26\testing_1\common_header.h(12) : fatal error C1083: Cannot open include file : 'src/stack.h': No such file or directory [Timer] Timings: [Timer] annotate --- 395.8 s [Timer] rtype_lltype --- 540.0 s [Timer] pyjitpl_lltype --- 371.9 s [Timer] backendopt_lltype --- 229.9 s [Timer] stackcheckinsertion_lltype --- 72.2 s [Timer] database_c --- 559.6 s [Timer] source_c --- 661.0 s [Timer] compile_c --- 0.5 s [Timer] =========================================== [Timer] Total: --- 2830.9 s [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "./translate.py", line 277, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "C:\cygwin\home\Olli Wang\pypy-trunk\pypy\translator \driver.py", line 741, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip ()) [translation:ERROR] File "C:\cygwin\home\Olli Wang\pypy-trunk\pypy\translator \tool\taskengine.py", line 116, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "C:\cygwin\home\Olli Wang\pypy-trunk\pypy\translator \driver.py", line 279, in _do [translation:ERROR] res = func() [translation:ERROR] File "C:\cygwin\home\Olli Wang\pypy-trunk\pypy\translator \driver.py", line 504, in task_compile_c [translation:ERROR] cbuilder.compile() [translation:ERROR] File "C:\cygwin\home\Olli Wang\pypy-trunk\pypy\translator \c\genc.py", line 447, in compile [translation:ERROR] self.translator.platform.execute_makefile(self.targetdir ) [translation:ERROR] File "C:\cygwin\home\Olli Wang\pypy-trunk\pypy\translator \platform\windows.py", line 281, in execute_makefile [translation:ERROR] self._handle_error(returncode, stdout, stderr, path.join ('make')) [translation:ERROR] File "C:\cygwin\home\Olli Wang\pypy-trunk\pypy\translator \platform\windows.py", line 197, in _handle_error [translation:ERROR] raise CompilationError(stdout, stderr) [translation:ERROR] CompilationError: -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Mon Dec 21 18:56:52 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 21 Dec 2009 18:56:52 +0100 Subject: [pypy-dev] release / funding bits Message-ID: <20091221175652.GR3516@trillke.net> Hi all, not sure how many of pypy-dev subscribers are following the PyPy status blog, so here are some brief pointers to two recent posts: PyPy-1.2 release planning: http://tinyurl.com/yacbb8t Accelerating PyPy by funding: http://tinyurl.com/yakb3en feedback as always welcome, here or on the posts (i am still waiting to get to know a common way to bidirectionally map e-mail threads to blog post comments) cheers, holger From fijall at gmail.com Mon Dec 21 19:05:07 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 21 Dec 2009 19:05:07 +0100 Subject: [pypy-dev] Failed to translate interpreter to JIT on Windows In-Reply-To: <1590abce0912202259s4177f239o7fb9c984c44ba974@mail.gmail.com> References: <1590abce0912202259s4177f239o7fb9c984c44ba974@mail.gmail.com> Message-ID: <693bc9ab0912211005u354f4f8bg68649e04cbd38554@mail.gmail.com> Hi Unfortunately, both windows and os x are less developed platforms (since less active jit developers use them). OS X is known not to work with the JIT. Regarding windows error - it looks strange. I think it's somehow missing the include path in the makefile, so it's more a build system problem. Do you feel like looking what's missing? I don't know much about VSC++, but include dirs for compilation should include pypy-checkout/pypy/trunk/pypy/translator/c/ somewhere. Cheers, fijal From amauryfa at gmail.com Tue Dec 22 18:11:51 2009 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Tue, 22 Dec 2009 18:11:51 +0100 Subject: [pypy-dev] Failed to translate interpreter to JIT on Windows In-Reply-To: <1590abce0912202259s4177f239o7fb9c984c44ba974@mail.gmail.com> References: <1590abce0912202259s4177f239o7fb9c984c44ba974@mail.gmail.com> Message-ID: Hello, 2009/12/21 Olli Wang : > Hi, I was trying to translate Python interpreter to JIT backend on WIndows > but failed. > It's no problem to translate it to C backend. Do I miss something? Thanks. > [c:writing] implement_40.c > [c:writing] implement_41.c > [c:writing] implement_42.c > [translation:info] written: > c:\docume~1\olliwa~1\locals~1\temp\usession-26\testi > ng_1\testing_1.c > [translation:info] Compiling c source... > [platform:execute] make in > c:\docume~1\olliwa~1\locals~1\temp\usession-26\testin > g_1 > [platform:ERROR] cl : Command line warning D9024 : unrecognized source file > type > ?'Wang\\pypy-trunk\\pypy\\translator\\c', object file assumed > [platform:ERROR] cl : Command line warning D9027 : source file > 'Wang\\pypy-trunk > \\pypy\\translator\\c' ignored I suggest that you use a directory wihout spaces in its name... -- Amaury Forgeot d'Arc From olliwang at ollix.com Wed Dec 23 06:13:14 2009 From: olliwang at ollix.com (Olli Wang) Date: Wed, 23 Dec 2009 13:13:14 +0800 Subject: [pypy-dev] Failed to translate interpreter to JIT on Windows In-Reply-To: References: <1590abce0912202259s4177f239o7fb9c984c44ba974@mail.gmail.com> Message-ID: <1590abce0912222113w4d0ab4f9h3029a48208fd66af@mail.gmail.com> Hi, remove spaces in directory name works! Thanks a lot. :) On Wed, Dec 23, 2009 at 1:11 AM, Amaury Forgeot d'Arc wrote: > Hello, > > 2009/12/21 Olli Wang : > > Hi, I was trying to translate Python interpreter to JIT backend on > WIndows > > but failed. > > It's no problem to translate it to C backend. Do I miss something? > Thanks. > > [c:writing] implement_40.c > > [c:writing] implement_41.c > > [c:writing] implement_42.c > > [translation:info] written: > > c:\docume~1\olliwa~1\locals~1\temp\usession-26\testi > > ng_1\testing_1.c > > [translation:info] Compiling c source... > > [platform:execute] make in > > c:\docume~1\olliwa~1\locals~1\temp\usession-26\testin > > g_1 > > [platform:ERROR] cl : Command line warning D9024 : unrecognized source > file > > type > > 'Wang\\pypy-trunk\\pypy\\translator\\c', object file assumed > > [platform:ERROR] cl : Command line warning D9027 : source file > > 'Wang\\pypy-trunk > > \\pypy\\translator\\c' ignored > > I suggest that you use a directory wihout spaces in its name... > > -- > Amaury Forgeot d'Arc > -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From olliwang at ollix.com Wed Dec 23 07:46:14 2009 From: olliwang at ollix.com (Olli Wang) Date: Wed, 23 Dec 2009 14:46:14 +0800 Subject: [pypy-dev] Failed to translate interpreter to JIT on Windows In-Reply-To: <1590abce0912222113w4d0ab4f9h3029a48208fd66af@mail.gmail.com> References: <1590abce0912202259s4177f239o7fb9c984c44ba974@mail.gmail.com> <1590abce0912222113w4d0ab4f9h3029a48208fd66af@mail.gmail.com> Message-ID: <1590abce0912222246h7ab7552tc5461bb85fe401c6@mail.gmail.com> Hi, though the pypy-c-jit interpreter has been compiled successfully, but I found a new problem. That is, I couldn't import any module in the `pypy.rlib` package. Any idea? Here's the test running pypy-c, and everything works fine: $ ./pypy/translator/goal/pypy-c.exe Python 2.5.2 (70148, Dec 21 2009, 03:51:26) [PyPy 1.1.0] on win32 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``things will be nice and stuff'' >>>> import pypy.rlib >>>> pypy.rlib >>>> from pypy.rlib import rmd5 >>>> Here's the test running pypy-c-jit, and importing failed: $ ./pypy/translator/goal/pypy-c-jit.exe 'import site' failed Python 2.5.2 (70227, Dec 23 2009, 00:01:42) [PyPy 1.1.0] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>> import pypy.rlib >>>> pypy.rlib >>>> from pypy.rlib import rmd5 Traceback (most recent call last): File "", line 1, in ImportError: cannot import name 'rmd5' >>>> On Wed, Dec 23, 2009 at 1:13 PM, Olli Wang wrote: > Hi, remove spaces in directory name works! Thanks a lot. :) > > On Wed, Dec 23, 2009 at 1:11 AM, Amaury Forgeot d'Arc wrote: > >> Hello, >> >> 2009/12/21 Olli Wang : >> > Hi, I was trying to translate Python interpreter to JIT backend on >> WIndows >> > but failed. >> > It's no problem to translate it to C backend. Do I miss something? >> Thanks. >> > [c:writing] implement_40.c >> > [c:writing] implement_41.c >> > [c:writing] implement_42.c >> > [translation:info] written: >> > c:\docume~1\olliwa~1\locals~1\temp\usession-26\testi >> > ng_1\testing_1.c >> > [translation:info] Compiling c source... >> > [platform:execute] make in >> > c:\docume~1\olliwa~1\locals~1\temp\usession-26\testin >> > g_1 >> > [platform:ERROR] cl : Command line warning D9024 : unrecognized source >> file >> > type >> > 'Wang\\pypy-trunk\\pypy\\translator\\c', object file assumed >> > [platform:ERROR] cl : Command line warning D9027 : source file >> > 'Wang\\pypy-trunk >> > \\pypy\\translator\\c' ignored >> >> I suggest that you use a directory wihout spaces in its name... >> >> -- >> Amaury Forgeot d'Arc >> > > > > -- > Olli Wang > > OLLI WANG PRODUCTIONS - http://olliwang.com > A BLOG ABOUT MY LIFE AND MY WORK > -- Olli Wang OLLI WANG PRODUCTIONS - http://olliwang.com A BLOG ABOUT MY LIFE AND MY WORK -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Wed Dec 23 12:00:02 2009 From: arigo at tunes.org (Armin Rigo) Date: Wed, 23 Dec 2009 12:00:02 +0100 Subject: [pypy-dev] Failed to translate interpreter to JIT on Windows In-Reply-To: <1590abce0912222246h7ab7552tc5461bb85fe401c6@mail.gmail.com> References: <1590abce0912202259s4177f239o7fb9c984c44ba974@mail.gmail.com> <1590abce0912222113w4d0ab4f9h3029a48208fd66af@mail.gmail.com> <1590abce0912222246h7ab7552tc5461bb85fe401c6@mail.gmail.com> Message-ID: <20091223110002.GA20072@code0.codespeak.net> Hi Olli, On Wed, Dec 23, 2009 at 02:46:14PM +0800, Olli Wang wrote: > Hi, though the pypy-c-jit interpreter has been compiled successfully, but I > found a new problem. That is, I couldn't import any module in the > `pypy.rlib` package. Any idea? Why you want to import pypy.rlib on top of a pypy-c, I cannot guess, but we might have more information about this fact: > $ ./pypy/translator/goal/pypy-c-jit.exe > 'import site' failed So I suggest to try "pypy-c-jit.exe -S" and typing "import site" to see what the error message is. Armin From arigo at tunes.org Thu Dec 24 17:23:57 2009 From: arigo at tunes.org (Armin Rigo) Date: Thu, 24 Dec 2009 17:23:57 +0100 Subject: [pypy-dev] Failed to translate interpreter to JIT on Windows In-Reply-To: <1590abce0912230648w44b2de91i298a54db078cc82e@mail.gmail.com> References: <1590abce0912202259s4177f239o7fb9c984c44ba974@mail.gmail.com> <1590abce0912222113w4d0ab4f9h3029a48208fd66af@mail.gmail.com> <1590abce0912222246h7ab7552tc5461bb85fe401c6@mail.gmail.com> <20091223110002.GA20072@code0.codespeak.net> <1590abce0912230648w44b2de91i298a54db078cc82e@mail.gmail.com> Message-ID: <20091224162357.GA6968@code0.codespeak.net> Hi, On Wed, Dec 23, 2009 at 10:48:10PM +0800, Olli Wang wrote: > ... > "C:\cygwin\home\olliwang\pypy-trunk\lib-python\modified-2.5.2\encodings\_ > _init__.py", line 32, in > from encodings import aliases > ImportError: cannot import name 'aliases' > >>>> Sorry, no clue about it. Others on pypy-dev may speak if they already encountered something similar. Otherwise it just looks like you are missing the file lib-python\modified-2.5.2\encodings\aliases.py. A bientot, Armin.