From scott+pypy-dev at scottdial.com Tue Aug 1 07:47:11 2006 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Tue, 01 Aug 2006 01:47:11 -0400 Subject: [pypy-dev] small patch for translator/c/src/ll_osdefs.h for win32 In-Reply-To: <44CB7E75.5010805@scottdial.com> References: <44C53C95.4070002@scottdial.com> <9eebf5740607242145j5fe29b20t2b10de9c28747b33@mail.gmail.com> <20060725093843.GA26167@code0.codespeak.net> <44C6042D.7090806@scottdial.com> <20060727090729.GA25278@code0.codespeak.net> <44CA4C37.3060709@scottdial.com> <20060729070549.GA22919@code0.codespeak.net> <44CB7E75.5010805@scottdial.com> Message-ID: <44CEEADF.4090104@scottdial.com> Scott Dial wrote: > I'm not sure what time is the best for it to run daily. I've currently > set it run daily at midnight GMT. For the record, I have a need for this to happen much later. I have moved it to 9am GMT which I realize may be afternoon for some people in Europe, but I can't help the Earth's rotation determining my schedule. -- Scott Dial scott at scottdial.com scodial at indiana.edu From cfbolz at gmx.de Tue Aug 1 09:44:26 2006 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 01 Aug 2006 09:44:26 +0200 Subject: [pypy-dev] small patch for translator/c/src/ll_osdefs.h for win32 In-Reply-To: <44CEEADF.4090104@scottdial.com> References: <44C53C95.4070002@scottdial.com> <9eebf5740607242145j5fe29b20t2b10de9c28747b33@mail.gmail.com> <20060725093843.GA26167@code0.codespeak.net> <44C6042D.7090806@scottdial.com> <20060727090729.GA25278@code0.codespeak.net> <44CA4C37.3060709@scottdial.com> <20060729070549.GA22919@code0.codespeak.net> <44CB7E75.5010805@scottdial.com> <44CEEADF.4090104@scottdial.com> Message-ID: <44CF065A.5050101@gmx.de> Hi Scott! Scott Dial wrote: > Scott Dial wrote: >> I'm not sure what time is the best for it to run daily. I've currently >> set it run daily at midnight GMT. > > For the record, I have a need for this to happen much later. I have > moved it to 9am GMT which I realize may be afternoon for some people in > Europe, but I can't help the Earth's rotation determining my schedule. > Just for the record, I think we all appreciate very much that you are running the tests and it does not matter too much _when_ you run them :-). Thank you! Cheers, Carl Friedrich From mwh at python.net Tue Aug 1 10:06:44 2006 From: mwh at python.net (Michael Hudson) Date: Tue, 01 Aug 2006 09:06:44 +0100 Subject: [pypy-dev] small patch for translator/c/src/ll_osdefs.h for win32 References: <44C53C95.4070002@scottdial.com> <9eebf5740607242145j5fe29b20t2b10de9c28747b33@mail.gmail.com> <20060725093843.GA26167@code0.codespeak.net> <44C6042D.7090806@scottdial.com> <20060727090729.GA25278@code0.codespeak.net> <44CA4C37.3060709@scottdial.com> <20060729070549.GA22919@code0.codespeak.net> <44CB7E75.5010805@scottdial.com> <44CEEADF.4090104@scottdial.com> Message-ID: <2mvepcx4kr.fsf@starship.python.net> Scott Dial writes: > Scott Dial wrote: >> I'm not sure what time is the best for it to run daily. I've currently >> set it run daily at midnight GMT. > > For the record, I have a need for this to happen much later. I have > moved it to 9am GMT which I realize may be afternoon for some people in > Europe, How could 9am _Greenwich_ (a place in the UK) Mean Time be in the afternoon anywhere in Europe? :) > but I can't help the Earth's rotation determining my schedule. Indeed :) As Carl says, thanks a lot for doing this! Cheers, mwh -- [1]For those of you who aren't aware "tossing" is a euphamism for, well, vigourously rubbing your love pole. You understand? Flogging the dolphin. Stretching the chicken's neck. Waving your magic wand. Basically, wanking. -- Just another Morfans SDA update From arigo at tunes.org Tue Aug 1 13:06:59 2006 From: arigo at tunes.org (Armin Rigo) Date: Tue, 1 Aug 2006 13:06:59 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> Message-ID: <20060801110659.GA21064@code0.codespeak.net> Hi Lawrence, On Sat, Jul 29, 2006 at 03:58:45PM +0200, Lawrence Oluyede wrote: > [translation:ERROR] AttributeError: 'CallEntry' object has no > attribute 'get_repr' This means that you are passing 'ctypes function' objects around, in variables. The only thing you can do with ctypes functions is call them directly. For now you have to find a workaround, e.g. pass stub RPython functions around. E.g. instead of: f1 = mylib.f1 f2 = mylib.f2 def invoke(f): return f(17) # 'f' holds a variable ctypes function object ... invoke(f1) ... invoke(f2) Do: f1 = mylib.f1 f2 = mylib.f2 def f1stub(x): return f1(x) def f2stub(x): return f2(x) def invoke(f): return f(17) # 'f' holds a regular RPython function ... invoke(f1stub) ... invoke(f2stub) (Note: this and a number of other ext-compiler or rctypes limitations could be removed with a bit of work; don't hesitate to tell us if a particular workaround seems really awkard in your cases. I'd love this kind of input, to know where to put efforts for more support.) A bientot, Armin From arigo at tunes.org Tue Aug 1 13:41:59 2006 From: arigo at tunes.org (Armin Rigo) Date: Tue, 1 Aug 2006 13:41:59 +0200 Subject: [pypy-dev] gateway.applevel and kwargs In-Reply-To: <5a8cc9e00607291811k3a0d0902w6e1cc7bccd170308@mail.gmail.com> References: <5a8cc9e00607291811k3a0d0902w6e1cc7bccd170308@mail.gmail.com> Message-ID: <20060801114159.GA23548@code0.codespeak.net> Hi Leonardo, On Sat, Jul 29, 2006 at 09:11:14PM -0400, Leonardo Soto wrote: > I've recently filled the issue 244 (dict.update() doesn't support > keywords argument), and tried to solve it in a naive way, just > modifying the applevel definition to: > > def update(d, o, **kwargs): > (...) This is a bit messy. It's an app-level definition but it goes through the interp-level gateway code via the multimethod logic. The first thing to change is the declared signature of the dict_update multimethod, also in dicttype.py: dict_update = SMM('update', 2, defaults=((),), doc="...") This means "two arguments with a default of () for the second one". Note that it's where the default comes from, too; not from the "def update(d, o)" implementation. Note first a difficulty: if we were implementing this method in pure Python, we couldn't say 'def update(self, o, **kwargs)' because there is a name clash between 'o' and the keywords, preventing an explicit 'o' keyword from being passed. To solve this we would have to declare it 'def update(self, *args, **kwargs)'. The equivalent solution here is: dict_update = SMM('update', 1, general__args__=True, doc="...") ^^^^^^^^^^^^^^^^^^^^^^^^ def update(d, *args, **kwargs): if len(args) > 1: raise TypeError("update takes at most 1 (non-keyword) argument") ... dict_update__ANY = app.interphook("update") ^^^^ But it doesn't work yet, because I'm just discovering that we have no support for *args/**kwargs in app.interphook()! Trying to fix this now... Armin From arigo at tunes.org Tue Aug 1 13:56:33 2006 From: arigo at tunes.org (Armin Rigo) Date: Tue, 1 Aug 2006 13:56:33 +0200 Subject: [pypy-dev] gateway.applevel and kwargs In-Reply-To: <20060801114159.GA23548@code0.codespeak.net> References: <5a8cc9e00607291811k3a0d0902w6e1cc7bccd170308@mail.gmail.com> <20060801114159.GA23548@code0.codespeak.net> Message-ID: <20060801115633.GB23548@code0.codespeak.net> Hi Leonardo, On Tue, Aug 01, 2006 at 01:41:59PM +0200, Armin Rigo wrote: > But it doesn't work yet, because I'm just discovering that we have no > support for *args/**kwargs in app.interphook()! Should work now. Armin From l.oluyede at gmail.com Tue Aug 1 15:09:42 2006 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Tue, 1 Aug 2006 15:09:42 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <20060801110659.GA21064@code0.codespeak.net> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> <20060801110659.GA21064@code0.codespeak.net> Message-ID: <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> Thanks for replying. > This means that you are passing 'ctypes function' objects around, in > variables. The only thing you can do with ctypes functions is call them > directly. Wish it was that but as far as I know no behavior of this kind is present in the code. Isn't there a way to know the name of the ctypes function troubled from the pdb inspector when the crash happens? From the CallEntry instance. -- Lawrence http://www.oluyede.org/blog From l.oluyede at gmail.com Tue Aug 1 15:20:53 2006 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Tue, 1 Aug 2006 15:20:53 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> Message-ID: <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> > Wish it was that but as far as I know no behavior of this kind is > present in the code. Isn't there a way to know the name of the ctypes > function troubled from the pdb inspector when the crash happens? From > the CallEntry instance. I dig some more and you were right (as always :)) I have SSLv23_method which returns a pointer to SSL_METHOD (which is a struct) and seems to dislike it. -- Lawrence http://www.oluyede.org/blog From l.oluyede at gmail.com Tue Aug 1 16:15:22 2006 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Tue, 1 Aug 2006 16:15:22 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> Message-ID: <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> > I have SSLv23_method which returns a pointer to SSL_METHOD (which is a > struct) and seems to dislike it. I forgot to say that disliking means "not fixable" :( -- Lawrence http://www.oluyede.org/blog From arigo at tunes.org Tue Aug 1 18:18:04 2006 From: arigo at tunes.org (Armin Rigo) Date: Tue, 1 Aug 2006 18:18:04 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> Message-ID: <20060801161803.GA20629@code0.codespeak.net> Hi Lawrence, On Tue, Aug 01, 2006 at 04:15:22PM +0200, Lawrence Oluyede wrote: > > I have SSLv23_method which returns a pointer to SSL_METHOD (which is a > > struct) and seems to dislike it. > > I forgot to say that disliking means "not fixable" :( Ah, oups, of course. It prevents supporting functions that return other functions, or structures with function pointers in them. I was just bit by the same restriction, when trying to cast a pointer to a function in order to call it. So indeed, it should be fixed. BTW I just added some support for var-sized arrays, so that we can now write: a = (c_int * n)() to create an array of 'n' integers even if 'n' is not a compile-time constant. A bientot, Armin From arigo at tunes.org Tue Aug 1 19:25:28 2006 From: arigo at tunes.org (Armin Rigo) Date: Tue, 1 Aug 2006 19:25:28 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <20060801161803.GA20629@code0.codespeak.net> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> <20060801161803.GA20629@code0.codespeak.net> Message-ID: <20060801172528.GA27594@code0.codespeak.net> Hi, On Tue, Aug 01, 2006 at 06:18:04PM +0200, Armin Rigo wrote: > Ah, oups, of course. It prevents supporting functions that return other > functions, or structures with function pointers in them. I was just bit > by the same restriction, when trying to cast a pointer to a function in > order to call it. So indeed, it should be fixed. arigo -> off-line holidays, though, so it will have to wait next week :-/ A bientot, Armin From scott+pypy-dev at scottdial.com Wed Aug 2 02:05:34 2006 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Tue, 01 Aug 2006 20:05:34 -0400 Subject: [pypy-dev] small patch for translator/c/src/ll_osdefs.h for win32 In-Reply-To: <2mvepcx4kr.fsf@starship.python.net> References: <44C53C95.4070002@scottdial.com> <9eebf5740607242145j5fe29b20t2b10de9c28747b33@mail.gmail.com> <20060725093843.GA26167@code0.codespeak.net> <44C6042D.7090806@scottdial.com> <20060727090729.GA25278@code0.codespeak.net> <44CA4C37.3060709@scottdial.com> <20060729070549.GA22919@code0.codespeak.net> <44CB7E75.5010805@scottdial.com> <44CEEADF.4090104@scottdial.com> <2mvepcx4kr.fsf@starship.python.net> Message-ID: <44CFEC4E.70004@scottdial.com> Michael Hudson wrote: > How could 9am _Greenwich_ (a place in the UK) Mean Time be in the > afternoon anywhere in Europe? :) *blush* I should avoid writing emails at 2am (localtime). :-) -- Scott Dial scott at scottdial.com scodial at indiana.edu From bea at changemaker.nu Thu Aug 3 15:28:06 2006 From: bea at changemaker.nu (Beatrice During) Date: Thu, 03 Aug 2006 15:28:06 +0200 Subject: [pypy-dev] Phase 2 report available! Message-ID: <44D1F9E6.3090805@changemaker.nu> Hi there Our report on phase 2 of the project is now finished and is available on: http://codespeak.net/pypy/dist/pypy/doc/index-report.html This report covers work achieved during the period September 2005-May 2006 (and a bit of June - the 0.9 release ;-). Although this report is written as part of the EU project we hope that many of you out there will enjoy reading it. Looking back to all those long months of check-ins and what we all actually accomplished it is not difficult to realise that it is the community around PyPy that makes this project tick - so thanks everyone out there! A special thank you to Holger for major part of the technical writing, Carl Friedrich for the funky metrics (and forever stuck in the swamp of ReST/pdf:s) and to Michael - always stuck in the dark hole of language reviews! Cheers Bea From Ben.Young at risk.sungard.com Mon Aug 7 16:35:21 2006 From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com) Date: Mon, 7 Aug 2006 15:35:21 +0100 Subject: [pypy-dev] Bytecode counting patch Message-ID: Hi PyPys! Here's a patch that counts the number of times the different bytecodes are used. I haven't tried doing translation yet as I can't use the work machine cycles, but it can't be far off. I've put the counts on the object space as this is accessable from most places. I've also implemented something that should resort the opcodes in the switch statement of the bytecode dispatcher according to the statistics I found. This may have a slight speed improvement. Cheers, Ben -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From cfbolz at gmx.de Mon Aug 7 16:56:55 2006 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 07 Aug 2006 16:56:55 +0200 Subject: [pypy-dev] Bytecode counting patch In-Reply-To: References: Message-ID: <44D754B7.3030007@gmx.de> Hi Ben! Ben.Young at risk.sungard.com wrote: > Here's a patch that counts the number of times the different bytecodes are > used. I haven't tried doing translation yet as I can't use the work > machine cycles, but it can't be far off. I've put the counts on the object > space as this is accessable from most places. > > I've also implemented something that should resort the opcodes in the > switch statement of the bytecode dispatcher according to the statistics I > found. This may have a slight speed improvement. Looks quite good. The only thing I don't really like is the fact that the logbytecodes config options is in the global option name space. Should probably be config.objspace.logbytecodes or even introduce an new interpreter name space and be config.interpreter.logbytecodes Cheers, Carl Friedrich From Ben.Young at risk.sungard.com Mon Aug 7 17:00:26 2006 From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com) Date: Mon, 7 Aug 2006 16:00:26 +0100 Subject: [pypy-dev] Bytecode counting patch In-Reply-To: <44D754B7.3030007@gmx.de> Message-ID: Carl Friedrich Bolz wrote on 07/08/2006 15:56:55: > Hi Ben! > > Ben.Young at risk.sungard.com wrote: > > Here's a patch that counts the number of times the different bytecodes > are > > used. I haven't tried doing translation yet as I can't use the work > > machine cycles, but it can't be far off. I've put the counts on the > object > > space as this is accessable from most places. > > > > I've also implemented something that should resort the opcodes in the > > switch statement of the bytecode dispatcher according to the statistics I > > found. This may have a slight speed improvement. > > Looks quite good. The only thing I don't really like is the fact that > the logbytecodes config options is in the global option name space. > Should probably be config.objspace.logbytecodes or even introduce an new > interpreter name space and be config.interpreter.logbytecodes > Thanks! I think it should have gone in objspace. It originally was, but then I moved the count onto ExecutionContext for a while, so I put it in global. Feel free to move it. The other bit I'm not sure about it the reporting of the results. At the momement it's just a hack in py.py, but it should go in objspace.finish. However, I couldn't work out how to print from there. Cheers, Ben > Cheers, > > Carl Friedrich > > From eric at vanrietpaap.nl Mon Aug 7 18:35:17 2006 From: eric at vanrietpaap.nl (Eric van Riet Paap) Date: Mon, 7 Aug 2006 18:35:17 +0200 Subject: [pypy-dev] Bytecode counting patch In-Reply-To: References: Message-ID: <9EBBE66F-EFF0-4290-943C-7AA4AFE87F70@vanrietpaap.nl> Hi Ben, It's nice to know what opcodes are popular! However, sorting them in whatever order within a switch will likely not make a difference. This switch will be converted to a jumptable, so the compiler will order the cases again. cheers Eric On Aug 7, 2006, at 4:35 PM, Ben.Young at risk.sungard.com wrote: > Hi PyPys! > > Here's a patch that counts the number of times the different > bytecodes are > used. I haven't tried doing translation yet as I can't use the work > machine cycles, but it can't be far off. I've put the counts on the > object > space as this is accessable from most places. > > I've also implemented something that should resort the opcodes in the > switch statement of the bytecode dispatcher according to the > statistics I > found. This may have a slight speed improvement. > > > > Cheers, > Ben > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From mwh at python.net Mon Aug 7 18:50:11 2006 From: mwh at python.net (Michael Hudson) Date: Mon, 07 Aug 2006 17:50:11 +0100 Subject: [pypy-dev] Bytecode counting patch References: <9EBBE66F-EFF0-4290-943C-7AA4AFE87F70@vanrietpaap.nl> Message-ID: <2mmzagv6bg.fsf@starship.python.net> Eric van Riet Paap writes: > Hi Ben, > > It's nice to know what opcodes are popular! However, sorting them in > whatever order within a switch will likely not make a difference. > This switch will be converted to a jumptable, so the compiler will > order the cases again. Unclear; similar rearrangements made a noticeable difference in CPython a few years back (I think, anyway). Cheers, mwh -- okay, tell me if i am crazy you are damn -- from Twisted.Quotes From Ben.Young at risk.sungard.com Tue Aug 8 08:57:55 2006 From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com) Date: Tue, 8 Aug 2006 07:57:55 +0100 Subject: [pypy-dev] Bytecode counting patch In-Reply-To: <9EBBE66F-EFF0-4290-943C-7AA4AFE87F70@vanrietpaap.nl> Message-ID: pypy-dev-bounces at codespeak.net wrote on 07/08/2006 17:35:17: > Hi Ben, > > It's nice to know what opcodes are popular! However, sorting them in > whatever order within a switch will likely not make a difference. > This switch will be converted to a jumptable, so the compiler will > order the cases again. > > cheers > Eric > Hi Eric, It probably won't, but there appeared to be some desire for this on irc, and this is the kind of project I can fit into my lunch break! I think it's worth a try to see if it makes a difference. Unfortunately, I can't test it here. Cheers, Ben > > On Aug 7, 2006, at 4:35 PM, Ben.Young at risk.sungard.com wrote: > > > Hi PyPys! > > > > Here's a patch that counts the number of times the different > > bytecodes are > > used. I haven't tried doing translation yet as I can't use the work > > machine cycles, but it can't be far off. I've put the counts on the > > object > > space as this is accessable from most places. > > > > I've also implemented something that should resort the opcodes in the > > switch statement of the bytecode dispatcher according to the > > statistics I > > found. This may have a slight speed improvement. > > > > > > > > Cheers, > > Ben > > > > _______________________________________________ > > pypy-dev at codespeak.net > > http://codespeak.net/mailman/listinfo/pypy-dev > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From arigo at tunes.org Wed Aug 9 14:28:04 2006 From: arigo at tunes.org (Armin Rigo) Date: Wed, 9 Aug 2006 14:28:04 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <20060801172528.GA27594@code0.codespeak.net> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> <20060801161803.GA20629@code0.codespeak.net> <20060801172528.GA27594@code0.codespeak.net> Message-ID: <20060809122804.GA30370@code0.codespeak.net> Hi Lawrence, rctypes should now support variables of "function pointer" types, so this problem with _ssl and bzip2 should be fixed. Congrats on finishing the ctypes implementation of all your modules, btw :-) Armin From arigo at tunes.org Wed Aug 9 14:36:40 2006 From: arigo at tunes.org (Armin Rigo) Date: Wed, 9 Aug 2006 14:36:40 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <20060809122804.GA30370@code0.codespeak.net> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> <20060801161803.GA20629@code0.codespeak.net> <20060801172528.GA27594@code0.codespeak.net> <20060809122804.GA30370@code0.codespeak.net> Message-ID: <20060809123640.GA31312@code0.codespeak.net> Re-hi, Ouch. _ssl is full of ctypes Unions, which rctypes doesn't support at all... More hacks in sight. Maybe we can handle the unions as structures with a special hint that forces the C code generator to write 'union' instead of 'struct' in their declaration... A bientot, Armin From l.oluyede at gmail.com Thu Aug 10 15:13:20 2006 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Thu, 10 Aug 2006 15:13:20 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <20060809123640.GA31312@code0.codespeak.net> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> <20060801161803.GA20629@code0.codespeak.net> <20060801172528.GA27594@code0.codespeak.net> <20060809122804.GA30370@code0.codespeak.net> <20060809123640.GA31312@code0.codespeak.net> Message-ID: <9eebf5740608100613k4f4803c0p14dd09e1efecf533@mail.gmail.com> > Ouch. _ssl is full of ctypes Unions, which rctypes doesn't support at > all... More hacks in sight. Maybe we can handle the unions as > structures with a special hint that forces the C code generator to write > 'union' instead of 'struct' in their declaration... So do you mean treat unions as struct at the rctypes level ? That could be simply making rctypes recognizing "Union" base class as an alias of Structure? -- Lawrence http://www.oluyede.org/blog From arigo at tunes.org Fri Aug 11 11:32:28 2006 From: arigo at tunes.org (Armin Rigo) Date: Fri, 11 Aug 2006 11:32:28 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <9eebf5740608100613k4f4803c0p14dd09e1efecf533@mail.gmail.com> References: <9eebf5740607290658w2dba6c96n38e5ab6d61b5c41b@mail.gmail.com> <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> <20060801161803.GA20629@code0.codespeak.net> <20060801172528.GA27594@code0.codespeak.net> <20060809122804.GA30370@code0.codespeak.net> <20060809123640.GA31312@code0.codespeak.net> <9eebf5740608100613k4f4803c0p14dd09e1efecf533@mail.gmail.com> Message-ID: <20060811093227.GA28992@code0.codespeak.net> Hi Lawrence, On Thu, Aug 10, 2006 at 03:13:20PM +0200, Lawrence Oluyede wrote: > So do you mean treat unions as struct at the rctypes level ? That > could be simply making rctypes recognizing "Union" base class as an > alias of Structure? Yes. After all, as far as I can tell, in C a 'union' is exactly the same as a 'struct' apart from one detail: all fields start at offset 0 in the 'union' case, whereas they are one after the other in the 'struct' case. A bientot, Armin From arigo at tunes.org Fri Aug 11 12:59:43 2006 From: arigo at tunes.org (Armin Rigo) Date: Fri, 11 Aug 2006 12:59:43 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <20060811093227.GA28992@code0.codespeak.net> References: <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010609t506bacdep7631bd0ff3f74c90@mail.gmail.com> <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> <20060801161803.GA20629@code0.codespeak.net> <20060801172528.GA27594@code0.codespeak.net> <20060809122804.GA30370@code0.codespeak.net> <20060809123640.GA31312@code0.codespeak.net> <9eebf5740608100613k4f4803c0p14dd09e1efecf533@mail.gmail.com> <20060811093227.GA28992@code0.codespeak.net> Message-ID: <20060811105943.GA5327@code0.codespeak.net> Hi, Ok, unions should now compile correctly. The next problem with "compilemodule.py _ssl" is that some structs have no _fields_ declaration (they are opaque). I guess that we could consider this case as equivalent to "_fields_ = []", for structs that are already declared in C headers anyway. GenC doesn't try to produce a new declaration for these structures. A bientot, Armin From l.oluyede at gmail.com Fri Aug 11 14:15:51 2006 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Fri, 11 Aug 2006 14:15:51 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <20060811105943.GA5327@code0.codespeak.net> References: <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010620w34abe276m2dca94ea35a7e63e@mail.gmail.com> <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> <20060801161803.GA20629@code0.codespeak.net> <20060801172528.GA27594@code0.codespeak.net> <20060809122804.GA30370@code0.codespeak.net> <20060809123640.GA31312@code0.codespeak.net> <9eebf5740608100613k4f4803c0p14dd09e1efecf533@mail.gmail.com> <20060811093227.GA28992@code0.codespeak.net> <20060811105943.GA5327@code0.codespeak.net> Message-ID: <9eebf5740608110515n2750bfe5u2bd27a8fbfcc17e3@mail.gmail.com> > The next problem with "compilemodule.py _ssl" is that some structs have > no _fields_ declaration (they are opaque). I guess that we could > consider this case as equivalent to "_fields_ = []", for structs that > are already declared in C headers anyway. GenC doesn't try to produce a > new declaration for these structures. I think that could be fixed by the code generator that generates that fields. I should talk to Thomas Heller to know what he can do about that. Meanwhile I can fix that manually and see what comes next. -- Lawrence http://www.oluyede.org/blog From l.oluyede at gmail.com Fri Aug 11 14:24:12 2006 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Fri, 11 Aug 2006 14:24:12 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <9eebf5740608110515n2750bfe5u2bd27a8fbfcc17e3@mail.gmail.com> References: <20060801110659.GA21064@code0.codespeak.net> <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> <20060801161803.GA20629@code0.codespeak.net> <20060801172528.GA27594@code0.codespeak.net> <20060809122804.GA30370@code0.codespeak.net> <20060809123640.GA31312@code0.codespeak.net> <9eebf5740608100613k4f4803c0p14dd09e1efecf533@mail.gmail.com> <20060811093227.GA28992@code0.codespeak.net> <20060811105943.GA5327@code0.codespeak.net> <9eebf5740608110515n2750bfe5u2bd27a8fbfcc17e3@mail.gmail.com> Message-ID: <9eebf5740608110524u301bd860ucdd8234f1aef4b7a@mail.gmail.com> > I think that could be fixed by the code generator that generates that > fields. I should talk to Thomas Heller to know what he can do about > that. Meanwhile I can fix that manually and see what comes next. I added empty fields, now I have a: [flowgraph] (pypy.rpython.lltypesystem.rrange:85)ll_rangeiter [annrpython] -> SomePtr(ll_ptrtype=<* GcStruct range { next: Signed, stop: Signed }>) [translation:ERROR] Error: [translation:ERROR] KeyError: -- Lawrence http://www.oluyede.org/blog From mwh at python.net Fri Aug 11 17:49:50 2006 From: mwh at python.net (Michael Hudson) Date: Fri, 11 Aug 2006 16:49:50 +0100 Subject: [pypy-dev] fun with dictionaries Message-ID: <2mk65ftgpt.fsf@starship.python.net> So part of WP06 is improving the dictionary implementation. To do this, it seemed like a good idea to find out what Python code does with dictionaries, which is what I've been working on this week. If you activate the "objspace.std.withmultidict" option, make MEASURE_DICT in pypy/objspace/std/dictmultiobject.py true and build yourself a pypy-c, you'll find that this pypy-c will create a dictinfo.txt file that summarizes how every dictionary in the program has been used. The benchmark programs I have been using are: pystone, richards, "rst2html coding-guide.txt" and "translate.py --backendopt --no-compile --batch --text targetrpystonedalone.py", and the (compressed) results can be found in: http://codespeak.net/~mwh/dictinfo/ The file dictinfos.tar.bz2 contains the dictinfo.txt files created by the above runs, and the RData files are binary files suitable for loading into R: http://www.r-project.org/ What I'd like to get some input on is stuff like: what aspects of this data should I analyse? Is there any data you think I should collect? Something that I don't measure at all is the order things happen in, which might be interesting: it's easy to believe many dictionaries go through a phase of being written to before a longer pahse of being read from. But I'm not sure how to measure that... Cheers, mwh -- I am *not* a PSU agent. -- from Twisted.Quotes From mwh at python.net Fri Aug 11 18:30:21 2006 From: mwh at python.net (Michael Hudson) Date: Fri, 11 Aug 2006 17:30:21 +0100 Subject: [pypy-dev] fun with dictionaries References: <2mk65ftgpt.fsf@starship.python.net> Message-ID: <2mfyg3teua.fsf@starship.python.net> Michael Hudson writes: > The benchmark programs I have been using are: pystone, richards, > "rst2html coding-guide.txt" and "translate.py --backendopt > --no-compile --batch --text targetrpystonedalone.py", and the > (compressed) results can be found in: > > http://codespeak.net/~mwh/dictinfo/ > > The file dictinfos.tar.bz2 contains the dictinfo.txt files created by > the above runs, and the RData files are binary files suitable for > loading into R: Unfortunately, the RData files aren't quite right. I'll fix them soon (though it would be sooner if pypy2 reappeared again quickly...). Cheers, mwh -- Screaming 14-year-old boys attempting to prove to each other that they are more 3133t than j00. -- Reason #8 for quitting slashdot today, from http://www.cs.washington.edu/homes/klee/misc/slashdot.html From mwh at python.net Fri Aug 11 19:18:26 2006 From: mwh at python.net (Michael Hudson) Date: Fri, 11 Aug 2006 18:18:26 +0100 Subject: [pypy-dev] fun with dictionaries References: <2mk65ftgpt.fsf@starship.python.net> <2mfyg3teua.fsf@starship.python.net> Message-ID: <2mbqqrtcm5.fsf@starship.python.net> Michael Hudson writes: > Michael Hudson writes: > >> The benchmark programs I have been using are: pystone, richards, >> "rst2html coding-guide.txt" and "translate.py --backendopt >> --no-compile --batch --text targetrpystonedalone.py", and the >> (compressed) results can be found in: >> >> http://codespeak.net/~mwh/dictinfo/ >> >> The file dictinfos.tar.bz2 contains the dictinfo.txt files created by >> the above runs, and the RData files are binary files suitable for >> loading into R: > > Unfortunately, the RData files aren't quite right. I'll fix them soon > (though it would be sooner if pypy2 reappeared again quickly...). Should be better now. Cheers, mwh -- I've even been known to get Marmite *near* my mouth -- but never actually in it yet. Vegamite is right out. UnicodeError: ASCII unpalatable error: vegamite found, ham expected -- Tim Peters, comp.lang.python From arigo at tunes.org Fri Aug 11 19:33:23 2006 From: arigo at tunes.org (Armin Rigo) Date: Fri, 11 Aug 2006 19:33:23 +0200 Subject: [pypy-dev] make _ssl module compile In-Reply-To: <9eebf5740608110524u301bd860ucdd8234f1aef4b7a@mail.gmail.com> References: <9eebf5740608010715j279d31dby9c4173cd4ba17773@mail.gmail.com> <20060801161803.GA20629@code0.codespeak.net> <20060801172528.GA27594@code0.codespeak.net> <20060809122804.GA30370@code0.codespeak.net> <20060809123640.GA31312@code0.codespeak.net> <9eebf5740608100613k4f4803c0p14dd09e1efecf533@mail.gmail.com> <20060811093227.GA28992@code0.codespeak.net> <20060811105943.GA5327@code0.codespeak.net> <9eebf5740608110515n2750bfe5u2bd27a8fbfcc17e3@mail.gmail.com> <9eebf5740608110524u301bd860ucdd8234f1aef4b7a@mail.gmail.com> Message-ID: <20060811173323.GA14768@code0.codespeak.net> Hi Lawrence, On Fri, Aug 11, 2006 at 02:24:12PM +0200, Lawrence Oluyede wrote: > [translation:ERROR] Error: > [translation:ERROR] KeyError: 0x2e3180 (NoneType)> My mistake. Fixed in rev 31266. Armin From santagada at gmail.com Fri Aug 11 23:59:00 2006 From: santagada at gmail.com (Leonardo Santagada) Date: Fri, 11 Aug 2006 18:59:00 -0300 Subject: [pypy-dev] Summer of PyPy pre-proposal Message-ID: <2f2e5f950608111459p4f0d511er7373de5b26394b75@mail.gmail.com> I would like to enter Summer of Pypy with my proposal to make a javascript interpreter. I had a chat with some nice people in #pypy and they thought it was a good idea. So I checked the code and started looking at what should/can do on 2 months of work ( I don't know if there is this limitation on time). I am a litle lost with all the code from pypy and the idea of making another interpreter so I am posting here my ideas and I am specting your feedback. What do you think I need to do? define a javascript virtual machine or do simple direct interpretation of the source? Should I use the parser defined on pyparsing (this one seems really nice) or write one manually? What I am certain is that it need to have an Interpreter so people can play with it. I should probably write more, but I want to know what you all think about this proposal. ps: I had another idea of translating readline to ctype and make it work on windows also like the one in ipython and also translating sqlite so people can try to run their webframeworks on pypy, but the js interpreter seems more important. -- Leonardo Santagada (http://www.lomohomes.com/retype) N?o se preocupe com o que os outros v?o fazer. O melhor jeito de prever o futuro ? inventa-lo. - Alan Kay From len-l at telus.net Sat Aug 12 03:50:31 2006 From: len-l at telus.net (Lenard Lindstrom) Date: Fri, 11 Aug 2006 18:50:31 -0700 Subject: [pypy-dev] Summer of PyPy pre-proposal In-Reply-To: <2f2e5f950608111459p4f0d511er7373de5b26394b75@mail.gmail.com> Message-ID: <44DCD177.28255.10875BF@len-l.telus.net> On 11 Aug 2006 at 18:59, Leonardo Santagada wrote: > I would like to enter Summer of Pypy with my proposal to make a > javascript interpreter. I had a chat with some nice people in #pypy > and they thought it was a good idea. So I checked the code and started > looking at what should/can do on 2 months of work ( I don't know if > there is this limitation on time). I am a litle lost with all the code > from pypy and the idea of making another interpreter so I am posting > here my ideas and I am specting your feedback. > > What do you think I need to do? define a javascript virtual machine or > do simple direct interpretation of the source? > Maybe javascript can compile to Python byte code. Lenard Lindstrom From arigo at tunes.org Sat Aug 12 10:09:01 2006 From: arigo at tunes.org (Armin Rigo) Date: Sat, 12 Aug 2006 10:09:01 +0200 Subject: [pypy-dev] Summer of PyPy pre-proposal In-Reply-To: <44DCD177.28255.10875BF@len-l.telus.net> References: <2f2e5f950608111459p4f0d511er7373de5b26394b75@mail.gmail.com> <44DCD177.28255.10875BF@len-l.telus.net> Message-ID: <20060812080901.GA29264@code0.codespeak.net> Hi Lenard, On Fri, Aug 11, 2006 at 06:50:31PM -0700, Lenard Lindstrom wrote: > Maybe javascript can compile to Python byte code. No, that wouldn't work. The two language's object models are different, as is always the case between dynamic languages, so you cannot just map the syntax of one to the bytecode of the other. Armin From arigo at tunes.org Sat Aug 12 10:45:31 2006 From: arigo at tunes.org (Armin Rigo) Date: Sat, 12 Aug 2006 10:45:31 +0200 Subject: [pypy-dev] Summer of PyPy pre-proposal In-Reply-To: <2f2e5f950608111459p4f0d511er7373de5b26394b75@mail.gmail.com> References: <2f2e5f950608111459p4f0d511er7373de5b26394b75@mail.gmail.com> Message-ID: <20060812084530.GB29264@code0.codespeak.net> Hi Leonardo, On Fri, Aug 11, 2006 at 06:59:00PM -0300, Leonardo Santagada wrote: > I would like to enter Summer of Pypy with my proposal to make a > javascript interpreter. I had a chat with some nice people in #pypy > and they thought it was a good idea. Nice plan :-) > So I checked the code and started > looking at what should/can do on 2 months of work ( I don't know if > there is this limitation on time). Not necessarily, but the proposal should have a timeline and your calendar should allow you to put "reasonable" amounts of work on it. > I am a litle lost with all the code > from pypy and the idea of making another interpreter so I am posting > here my ideas and I am specting your feedback. > > What do you think I need to do? define a javascript virtual machine or > do simple direct interpretation of the source? I'm not completely clear about the difference between a simple direct interpreter and a virtual machine. JavaScript like Python is a language where the main work is in getting the execution model and the object model right. For the object model I mean building the Python classes that support the various kinds of JavaScript objects -- "kind" as in the [[Class]] internal property -- with all the other internal properties and methods; and then making the pre-built objects and prototypes and functions. It's ok to leave out some parts of the library of pre-built objects for the Summer of PyPy's duration. (This part corresponds to PyPy's "object spaces".) For the execution model, as you note, you need to start with an interpreter. It would interpret bytecodes that you are free to invent; I guess they would directly correspond to JavaScript syntax elements. (What I mean by execution model also includes things like function and method calls, and how to fit built-in functions.) (This part is documented under the name "bytecode interpreter" in PyPy.) (JavaScript ref.: http://www.ecma-international.org/publications/standards/Ecma-262.htm) > Should I use the parser defined on pyparsing (this one seems really > nice) or write one manually? I'm not sure about this. Our tokenizer and parser are definitely meant to be reusable, but I'm not exactly sure how :-/ I think there is a way to recompile the tables in pytokenize.py. The parser loads a grammar dynamically, so that's simpler. My 2 cents, though, is that you don't start the work here; if you know about another JavaScript parser that produces some data that is easy to feed to Python, it would be a good start. (Ultimately, we really need a parser written in RPython, but it's ok to leave this out of the Summer of PyPy proposal.) A bientot, Armin From len-l at telus.net Sat Aug 12 20:54:42 2006 From: len-l at telus.net (Lenard Lindstrom) Date: Sat, 12 Aug 2006 11:54:42 -0700 Subject: [pypy-dev] Summer of PyPy pre-proposal In-Reply-To: <20060812080901.GA29264@code0.codespeak.net> References: <44DCD177.28255.10875BF@len-l.telus.net> Message-ID: <44DDC182.899.B56587@len-l.telus.net> Hi Armin, I must be missing something here. Isn't Python's object model defined by the type objects themselves? So implement a javascript prototype type. Create the necessary javascript root objects and import them into the __builtin__ namespace or something. I would expect any serious problems would involve identifier scope or exception handling, language qualities very much tied to the bytecode interpreter framework. On 12 Aug 2006 at 10:09, Armin Rigo wrote: > Hi Lenard, > > On Fri, Aug 11, 2006 at 06:50:31PM -0700, Lenard Lindstrom wrote: > > Maybe javascript can compile to Python byte code. > > No, that wouldn't work. The two language's object models are different, > as is always the case between dynamic languages, so you cannot just map > the syntax of one to the bytecode of the other. > Lenard Lindstrom From scott+pypy-dev at scottdial.com Sun Aug 13 12:58:36 2006 From: scott+pypy-dev at scottdial.com (Scott Dial) Date: Sun, 13 Aug 2006 06:58:36 -0400 Subject: [pypy-dev] Lingering issues w/my pypy tester Message-ID: <44DF05DC.4090202@scottdial.com> Whether any of these are "bugs" or not is up to you, but they are nuissances for my test runs: * module._stackless.test.test_choicepoint http://scottdial.com/pypytest/31094/failed/module._stackless.test.test_choicepoint.py.test_choicepoint.html This test gets stalled while running a subprocess (testing_1.exe) and I must manually kill this process for the testing to continue. I haven't been able to identify the problem. * translator.c.test.test_stackless.TestStackless().test_stack_too_big http://scottdial.com/pypytest/31094/failed/translator.c.test.test_stackless.py.TestStacklesstest_stack_too_big.html This test causes the boehm gc library to throw and catch an exception "Too many heap sections". I suspect this means that the test has indeed failed. However, this assertion from the gc library is modal and blocking, so it stalls the test run until human intervention clicks "ok". I haven't looked deeply into this one. Otherwise, none of the failures require human involvement to get things going again, but there are plenty of other tests which are erroneous failures. -- Scott Dial scott at scottdial.com scodial at indiana.edu From arigo at tunes.org Mon Aug 14 13:38:06 2006 From: arigo at tunes.org (Armin Rigo) Date: Mon, 14 Aug 2006 13:38:06 +0200 Subject: [pypy-dev] Summer of PyPy pre-proposal In-Reply-To: <44DDC182.899.B56587@len-l.telus.net> References: <44DCD177.28255.10875BF@len-l.telus.net> <44DDC182.899.B56587@len-l.telus.net> Message-ID: <20060814113806.GB9100@code0.codespeak.net> Hi Lenard, On Sat, Aug 12, 2006 at 11:54:42AM -0700, Lenard Lindstrom wrote: > I must be missing something here. Isn't Python's object model defined > by the type objects themselves? I was thinking about the way all objects work; the type objects only define methods and properties of their instances, but not *what* a method or a property is. In Python, the "object model" contains a lot of logic about what special method calls are triggered by "a+b", and how an attribute lookup is performed. In JavaScript the object model is far simpler: it is described by a number of internal properties that objects have, like [[Prototype]], and how these properties are used in various operations like attribute lookup. It needs to be done, but that's not necessarily difficult indeed. It's possible that other aspects will be more irksome. Nevertheless, it means that you can never really reuse the bytecode of one dynamic language to implement another one, because the "object models" are typically quite different, in the sense above. Most bytecodes - GETATTR, BINARY_ADD, etc. - do things in Python that are completely unrelated to what the equivalent bytecode would need to do in JavaScript, even before we consider type objects. A bientot, Armin From arigo at tunes.org Mon Aug 14 13:42:11 2006 From: arigo at tunes.org (Armin Rigo) Date: Mon, 14 Aug 2006 13:42:11 +0200 Subject: [pypy-dev] Lingering issues w/my pypy tester In-Reply-To: <44DF05DC.4090202@scottdial.com> References: <44DF05DC.4090202@scottdial.com> Message-ID: <20060814114211.GC9100@code0.codespeak.net> Hi Scott, On Sun, Aug 13, 2006 at 06:58:36AM -0400, Scott Dial wrote: > Whether any of these are "bugs" or not is up to you, but they are > nuissances for my test runs: We'll try to look into them, but for now, feel free to skip them. (You can probably just drop a py.test.skip("XXX") in the tests in your automated runner's working copy.) A bientot, Armin From arigo at tunes.org Thu Aug 17 10:57:11 2006 From: arigo at tunes.org (Armin Rigo) Date: Thu, 17 Aug 2006 10:57:11 +0200 Subject: [pypy-dev] Self-hosted Message-ID: <20060817085711.GA17222@code0.codespeak.net> Hi all, A few days ago we got our first version of pypy-c compiled with pypy-c. At least it produced the C code before distutils crashed because of our incomplete posix module; so you have to say cd pypy/translator/goal pypy-c --text --source translate.py cd /tmp/usession-yourname/testing_1 make So now we're self-hosted :-) A bientot, Armin From seojiwon at gmail.com Fri Aug 18 03:31:13 2006 From: seojiwon at gmail.com (Jiwon Seo) Date: Thu, 17 Aug 2006 18:31:13 -0700 Subject: [pypy-dev] Self-hosted In-Reply-To: <20060817085711.GA17222@code0.codespeak.net> References: <20060817085711.GA17222@code0.codespeak.net> Message-ID: Great! On 8/17/06, Armin Rigo wrote: > Hi all, > > A few days ago we got our first version of pypy-c compiled with pypy-c. > At least it produced the C code before distutils crashed because of our > incomplete posix module; so you have to say > > cd pypy/translator/goal > pypy-c --text --source translate.py > cd /tmp/usession-yourname/testing_1 > make > > So now we're self-hosted :-) > > > A bientot, > > Armin > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From faassen at infrae.com Fri Aug 18 10:58:38 2006 From: faassen at infrae.com (Martijn Faassen) Date: Fri, 18 Aug 2006 10:58:38 +0200 Subject: [pypy-dev] Self-hosted In-Reply-To: <20060817085711.GA17222@code0.codespeak.net> References: <20060817085711.GA17222@code0.codespeak.net> Message-ID: <44E5813E.9000709@infrae.com> Armin Rigo wrote: [snip] > So now we're self-hosted :-) Awesome! I like little (or bigger) progress reports like this. :) Regards, Martijn From l.oluyede at gmail.com Sun Aug 20 02:44:57 2006 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Sun, 20 Aug 2006 02:44:57 +0200 Subject: [pypy-dev] Modules on Windows Message-ID: <9eebf5740608191744w6f553703p846517512236fef5@mail.gmail.com> I managed to port rctime and mmap on Windows. So there's a little bit more of pypy on Windows platform. I can't tell you how much pain was to configure Windows to compile but I'm sure you all can understand :-) -- Lawrence http://www.oluyede.org/blog From arigo at tunes.org Sun Aug 20 15:49:23 2006 From: arigo at tunes.org (Armin Rigo) Date: Sun, 20 Aug 2006 15:49:23 +0200 Subject: [pypy-dev] Modules on Windows In-Reply-To: <9eebf5740608191744w6f553703p846517512236fef5@mail.gmail.com> References: <9eebf5740608191744w6f553703p846517512236fef5@mail.gmail.com> Message-ID: <20060820134923.GA17301@code0.codespeak.net> Hi Lawrence, On Sun, Aug 20, 2006 at 02:44:57AM +0200, Lawrence Oluyede wrote: > I managed to port rctime and mmap on Windows. So there's a little bit > more of pypy on Windows platform. I can't tell you how much pain was > to configure Windows to compile but I'm sure you all can understand > :-) Great news :-) Armin From alexandre.fayolle at logilab.fr Tue Aug 22 16:35:05 2006 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Tue, 22 Aug 2006 16:35:05 +0200 Subject: [pypy-dev] [jinty@web.de: [Zope3-dev] zope.interface using PyPy's extension compiler] Message-ID: <20060822143505.GE4823@crater.logilab.fr> Hi everyone, I hope you're having fun in Ireland. I don't remember seing the information below on this list, and thought it could interest people to know of other's efforts to use pypy. Cheers, ----- Forwarded message from Brian Sutherland ----- From: Brian Sutherland To: Zope3-dev Date: Mon, 21 Aug 2006 16:57:06 +0200 Subject: [Zope3-dev] zope.interface using PyPy's extension compiler At EuroPython I investigated re-implementing a class from zope.interface in PyPy's Restricted Python. I compiled it to C and then compared it to the Pure Python implementation and handcrafted C optimization. Not having touched PyPy before, I found it extreemly interesting. The report and code I wrote is available here for anyone else interested: http://lentejasverdes.ath.cx/stuff/pypy/europython_2006/README.html -- Brian Sutherland ----- End forwarded message ----- -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations D?veloppement logiciel sur mesure: http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: Digital signature URL: From jinty at web.de Tue Aug 22 17:05:56 2006 From: jinty at web.de (Brian Sutherland) Date: Tue, 22 Aug 2006 17:05:56 +0200 Subject: [pypy-dev] [jinty@web.de: [Zope3-dev] zope.interface using PyPy's extension compiler] In-Reply-To: <20060822143505.GE4823@crater.logilab.fr> References: <20060822143505.GE4823@crater.logilab.fr> Message-ID: <20060822150556.GC7145@minipas.home> On Tue, Aug 22, 2006 at 04:35:05PM +0200, Alexandre Fayolle wrote: > Hi everyone, > > I hope you're having fun in Ireland. > > I don't remember seing the information below on this list, and thought > it could interest people to know of other's efforts to use pypy. Actually, I was going to post it on this list "Real Soon". But thanks for doing it for me;) > Cheers, > > ----- Forwarded message from Brian Sutherland ----- > > From: Brian Sutherland > To: Zope3-dev > Date: Mon, 21 Aug 2006 16:57:06 +0200 > Subject: [Zope3-dev] zope.interface using PyPy's extension compiler > > At EuroPython I investigated re-implementing a class from zope.interface > in PyPy's Restricted Python. I compiled it to C and then compared it to > the Pure Python implementation and handcrafted C optimization. > > Not having touched PyPy before, I found it extreemly interesting. The > report and code I wrote is available here for anyone else interested: > http://lentejasverdes.ath.cx/stuff/pypy/europython_2006/README.html > > -- > Brian Sutherland > > > > ----- End forwarded message ----- > > -- > Alexandre Fayolle LOGILAB, Paris (France) > Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations > D?veloppement logiciel sur mesure: http://www.logilab.fr/services > Informatique scientifique: http://www.logilab.fr/science > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" From faassen at infrae.com Wed Aug 23 12:51:15 2006 From: faassen at infrae.com (Martijn Faassen) Date: Wed, 23 Aug 2006 12:51:15 +0200 Subject: [pypy-dev] practical experiences with PyPy's extension compiler In-Reply-To: <20060822150556.GC7145@minipas.home> References: <20060822143505.GE4823@crater.logilab.fr> <20060822150556.GC7145@minipas.home> Message-ID: <44EC3323.90301@infrae.com> Hey, As someone who suggested to Brian he try something like this with PyPy, I just wanted to highlight this. To make sure the PyPy developer's brains don't turn off when they hear Zope, that's not important bit, so I changed the title. :) Please all read Brian's entry! Brian Sutherland wrote: [snip] > At EuroPython I investigated re-implementing a class from > zope.interface in PyPy's Restricted Python. I compiled it to C > and then compared it to the Pure Python implementation and > handcrafted C optimization. > > Not having touched PyPy before, I found it extremely interesting. The > report and code I wrote is available here for anyone else interested: > http://lentejasverdes.ath.cx/stuff/pypy/europython_2006/README.html The point of Brian's experiment from PyPy's perspective is that you get feedback on PyPy's utility from a developer who is not primarily engaged with the development of programming language technology. I think that's good for the PyPy project. I think the following strategy has a lot of potential getting PyPy technology to the "masses": * write your module in RPython. * use (R)CTypes if you want to bind to existing C libraries. * promise performance as this module can compile to a CPython C extension. * promise maintainability and testability as this module should be able to run in straight Python (+ CTypes). This is one of the main areas where this strategy would give practical benefits over technology like Pyrex. * and actually all these people are making their extension modules ready for PyPy too. I know that this is your strategy, I'm just repeating it to let the echo sink in. And feedback on the experience from people like Brian may give vital information on how to improve the experience... In this case, Brian's feedback (also personally on irc) indicates to me that the above points have not yet been reached entirely: * writing RPython is rather difficult as you need to keep the various levels straight. This unfortunately hurts the maintainability point. * in this case, the promised performance wasn't delivered, unfortunately. * as far as I understood it, in this case, the code wasn't directly testable in CPython after the rewriting to RPython was done. This hurts the testability case. (my apologies of any of this is wrong; Brian would know better of course) I'm really excited about the potential here, so I hope this can be the start of a longer dialog between PyPy developers and application developers. Now I'm done highlighting this. :) Regards, Martijn From bea at changemaker.nu Wed Aug 23 15:33:38 2006 From: bea at changemaker.nu (Beatrice During) Date: Wed, 23 Aug 2006 15:33:38 +0200 Subject: [pypy-dev] Sprint reports 2003-2006 Message-ID: <44EC5932.5040901@changemaker.nu> Hi there We now have a page linking to all sprint reports from PyPy sprints since the project started 2003 up to present time. http://codespeak.net/pypy/dist/pypy/doc/sprint-reports.html There are 22 (!!) sprints during this period and we have reports from 16 of them (soon - after the ongoing Limerick sprint 17 ;-). This page should help people to better understand the progress of the project - so enjoy a stroll down the PyPy memory lane. Thanks Michael for helping out with this. Cheers Bea From jacob at strakt.com Wed Aug 23 18:15:28 2006 From: jacob at strakt.com (Jacob =?iso-8859-1?q?Hall=E9n?=) Date: Wed, 23 Aug 2006 18:15:28 +0200 Subject: [pypy-dev] Sprint reports 2003-2006 In-Reply-To: <44EC5932.5040901@changemaker.nu> References: <44EC5932.5040901@changemaker.nu> Message-ID: <200608231815.33714.jacob@strakt.com> Great work! I think we should try to reconstruct at least stub reports for the remaining sprints. Here are some notes on what happened at the ones I attended. This is in no way complete (and fairly Jacob focused, since I remember what I did, but have a hazy understanding of what others did): Gothenburg (May 2003) =================== The major focus of the sprint was to make the interpreter chain complete. A first goal was to make "Hello world" run and this was accomplished about half way into the sprint. We then proceded to making a more complex program that had operations involving string operations and dictionaries work. This was accomplished before the end of the sprint. http://www.strakt.com/~jacob/pypy/img_0062.jpg There was a big discussion, mostly involving Armin and Samuele over how to handle operator dispatching. This ended in the Multimethod dispatcher that mostly still survives in the Standard Object Space. http://www.strakt.com/~jacob/pypy/img_0064.jpg http://www.strakt.com/~jacob/pypy/img_0065.jpg http://www.strakt.com/~jacob/pypy/img_0066.jpg People I remember being there: Armin, Christian, Samuele, Michael, Alex Martelli, Anna Ravenscroft, Laura, Tomek Meka Europython/Gothenburg (June 2004) ============================= The sprint happened before the conference, and I'm rather hazy on what actually happened since I spent almost all my time on conference preparations. I'm rather certain Christian, Holger, Armin and Anders Lehman were there. Maybe they can fill in details. (To jog your memories, you were sitting in a room with green doors, skylights and no windows in the IT-support department). Vilnius (Nov 2004) =============== I don't really remember what others did at this sprint, but this is where Laura and I wrote the file I/O handling. People I remember being there: Marius Gedminas, Bob Ippolito, Christian, Armin. Leysin (April 2006) =============== Armin, Arre and Samuele started with 2 days working on the JIT. When others joined the sprint focus changed and there was a bunch of work on fixing translation to work with stackless features and other stuff. There was also some work done on the constraints package. People I remember being there: Armin, Arre, Samuele, Holger, Michael, Alexandre, Aurelien Europython/Gothenburg (June 2005) ============================= Apart from the presprint, which is already reoprted, there was an open post.-Europython sprint. At the open sprint there were 24 people on the first day and activities happened on may fronts. A large group of people focused on porting PyPy to support Python2.4. This work was 3/4 finished by the end of the sprint. Christian and Jacob worked on support for floats and Jacob did a bunch of work on binascii and related modules. I think there was also a bunch of work going into annotation, translation and the C and llvm backends. Nick worked on his sre Summer of Code project. There was also work being done on the AST compiler. People I remember being there: All the regulars plus Anders Qvist and Marius Gedminas. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From marius at pov.lt Wed Aug 23 18:25:52 2006 From: marius at pov.lt (Marius Gedminas) Date: Wed, 23 Aug 2006 19:25:52 +0300 Subject: [pypy-dev] Sprint reports 2003-2006 In-Reply-To: <200608231815.33714.jacob@strakt.com> References: <44EC5932.5040901@changemaker.nu> <200608231815.33714.jacob@strakt.com> Message-ID: <20060823162552.GA16202@fridge.pov.lt> On Wed, Aug 23, 2006 at 06:15:28PM +0200, Jacob Hall?n wrote: > Vilnius (Nov 2004) > =============== > I don't really remember what others did at this sprint, but this is where > Laura and I wrote the file I/O handling. > > People I remember being there: Marius Gedminas, Bob Ippolito, Christian, > Armin. IIRC everyone was overjoyed when PyPy managed to completely translate into C and compute the Ultimate Answer to Life, the Universe, and Everything (def somefunc(): return -6 * -7). > Europython/Gothenburg (June 2005) > ============================= > Apart from the presprint, which is already reoprted, there was an open > post.-Europython sprint. At the open sprint there were 24 people on the first > day and activities happened on may fronts. A large group of people focused on > porting PyPy to support Python2.4. This work was 3/4 finished by the end of > the sprint. Christian and Jacob worked on support for floats and Jacob did a > bunch of work on binascii and related modules. I think there was also a bunch > of work going into annotation, translation and the C and llvm backends. Nick > worked on his sre Summer of Code project. There was also work being done on > the AST compiler. > > People I remember being there: All the regulars plus Anders Qvist and Marius > Gedminas. I was there for one day only, and didn't get anything done. (I tried to make py.test run the Zope 3 testsuite, which was not a very PyPy-related task.) Marius Gedminas -- If the code and the comments disagree, then both are probably wrong. -- Norm Schryer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From bea at changemaker.nu Thu Aug 24 12:27:11 2006 From: bea at changemaker.nu (Beatrice During) Date: Thu, 24 Aug 2006 12:27:11 +0200 Subject: [pypy-dev] Sprint reports 2003-2006 In-Reply-To: <200608231815.33714.jacob@strakt.com> References: <44EC5932.5040901@changemaker.nu> <200608231815.33714.jacob@strakt.com> Message-ID: <44ED7EFF.5070407@changemaker.nu> Hi there Thanks Jacob and Marius for your feedback. I am working on updating the sprint report page with this feedback. If anyone has comments and want me to add stuff/clear out missing pieces - please email me and I will update. Cheers Bea Jacob Hall?n skrev: > Great work! > > I think we should try to reconstruct at least stub reports for the remaining > sprints. Here are some notes on what happened at the ones I attended. This is > in no way complete (and fairly Jacob focused, since I remember what I did, > but have a hazy understanding of what others did): > > > Gothenburg (May 2003) > =================== > The major focus of the sprint was to make the interpreter chain complete. A > first goal was to make "Hello world" run and this was accomplished about half > way into the sprint. We then proceded to making a more complex program that > had operations involving string operations and dictionaries work. This was > accomplished before the end of the sprint. > > http://www.strakt.com/~jacob/pypy/img_0062.jpg > > There was a big discussion, mostly involving Armin and Samuele over how to > handle operator dispatching. This ended in the Multimethod dispatcher that > mostly still survives in the Standard Object Space. > > http://www.strakt.com/~jacob/pypy/img_0064.jpg > http://www.strakt.com/~jacob/pypy/img_0065.jpg > http://www.strakt.com/~jacob/pypy/img_0066.jpg > > People I remember being there: Armin, Christian, Samuele, Michael, Alex > Martelli, Anna Ravenscroft, Laura, Tomek Meka > > Europython/Gothenburg (June 2004) > ============================= > The sprint happened before the conference, and I'm rather hazy on what > actually happened since I spent almost all my time on conference > preparations. I'm rather certain Christian, Holger, Armin and Anders Lehman > were there. Maybe they can fill in details. (To jog your memories, you were > sitting in a room with green doors, skylights and no windows in the > IT-support department). > > Vilnius (Nov 2004) > =============== > I don't really remember what others did at this sprint, but this is where > Laura and I wrote the file I/O handling. > > People I remember being there: Marius Gedminas, Bob Ippolito, Christian, > Armin. > > Leysin (April 2006) > =============== > Armin, Arre and Samuele started with 2 days working on the JIT. When others > joined the sprint focus changed and there was a bunch of work on fixing > translation to work with stackless features and other stuff. There was also > some work done on the constraints package. > > People I remember being there: > Armin, Arre, Samuele, Holger, Michael, Alexandre, Aurelien > > Europython/Gothenburg (June 2005) > ============================= > Apart from the presprint, which is already reoprted, there was an open > post.-Europython sprint. At the open sprint there were 24 people on the first > day and activities happened on may fronts. A large group of people focused on > porting PyPy to support Python2.4. This work was 3/4 finished by the end of > the sprint. Christian and Jacob worked on support for floats and Jacob did a > bunch of work on binascii and related modules. I think there was also a bunch > of work going into annotation, translation and the C and llvm backends. Nick > worked on his sre Summer of Code project. There was also work being done on > the AST compiler. > > People I remember being there: All the regulars plus Anders Qvist and Marius > Gedminas. > > > ------------------------------------------------------------------------ > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From laurent.destriau at gmail.com Fri Aug 25 22:05:02 2006 From: laurent.destriau at gmail.com (laurent destriau) Date: Fri, 25 Aug 2006 22:05:02 +0200 Subject: [pypy-dev] Extension compiler and external DLLs Message-ID: <3bb8d3330608251305k333890blca6215055e854e8a@mail.gmail.com> Hi, I would like to use pypy/bin/compilemodule.py to compile some of my code, which uses OpenGL. I am wondering why the following does not work (Link error on glEnd) : from ctypes import windll glEnd = windll.opengl32.glEnd glEnd.restype = None def DrawSomething(space): glEnd() While this does compile fine: from pypy.rpython.rctypes.tool import ctypes_platform from pypy.rpython.rctypes.tool.libc import libc from ctypes import * time_t = ctypes_platform.getsimpletype('time_t', '#include ', c_long) time = libc.time time.argtypes = [POINTER(time_t)] time.restype = time_t def DrawLine(space): time(None) Any help would be much appreciated. Thanks, Laurent Destriau -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.oluyede at gmail.com Fri Aug 25 23:19:48 2006 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Fri, 25 Aug 2006 23:19:48 +0200 Subject: [pypy-dev] Extension compiler and external DLLs In-Reply-To: <3bb8d3330608251305k333890blca6215055e854e8a@mail.gmail.com> References: <3bb8d3330608251305k333890blca6215055e854e8a@mail.gmail.com> Message-ID: <9eebf5740608251419x7ccf2e81gec3e915d78dbdd24@mail.gmail.com> On 8/25/06, laurent destriau wrote: > Hi, > I would like to use pypy/bin/compilemodule.py to compile some of my code, > which uses OpenGL. > I am wondering why the following does not work (Link error on glEnd) : > > from ctypes import windll > > glEnd = windll.opengl32.glEnd > glEnd.restype = None > > def DrawSomething(space): > glEnd() > You should provide more information about your errors so it could be easier to help you. Anyway I guess the compiler doesn't find the C header in which glEnd() is defined. Do you have the headers of the opengl library on the machine? ps. do you know there is a opengl-ctypes implementation, right? -- Lawrence http://www.oluyede.org/blog From laurent.destriau at gmail.com Sat Aug 26 01:58:28 2006 From: laurent.destriau at gmail.com (laurent destriau) Date: Sat, 26 Aug 2006 01:58:28 +0200 Subject: [pypy-dev] Extension compiler and external DLLs In-Reply-To: <9eebf5740608251419x7ccf2e81gec3e915d78dbdd24@mail.gmail.com> References: <3bb8d3330608251305k333890blca6215055e854e8a@mail.gmail.com> <9eebf5740608251419x7ccf2e81gec3e915d78dbdd24@mail.gmail.com> Message-ID: <3bb8d3330608251658p4e3cfdbbycedd0c1222237c54@mail.gmail.com> Thank you for your answer. Here is some more info: - I use Visual C++ .Net 2003, which includes the OpenGL header - I get the following warning: "warning C4013: glEnd not defined ; extern returning int assumed" - I get the following error: "error LNK2001: unresolved external symbol _glEnd" How can I tell the extension compiler how to find the proper headers/libraries? > ps. do you know there is a opengl-ctypes implementation, right? No, I didn't. Thanks for the tip. -- Laurent Destriau On 8/25/06, Lawrence Oluyede wrote: > > On 8/25/06, laurent destriau wrote: > > Hi, > > I would like to use pypy/bin/compilemodule.py to compile some of my > code, > > which uses OpenGL. > > I am wondering why the following does not work (Link error on glEnd) : > > > > from ctypes import windll > > > > glEnd = windll.opengl32.glEnd > > glEnd.restype = None > > > > def DrawSomething(space): > > glEnd() > > > > You should provide more information about your errors so it could be > easier to help you. Anyway I guess the compiler doesn't find the C > header in which glEnd() is defined. Do you have the headers of the > opengl library on the machine? > > ps. do you know there is a opengl-ctypes implementation, right? > > -- > Lawrence > http://www.oluyede.org/blog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.oluyede at gmail.com Sat Aug 26 02:02:45 2006 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Sat, 26 Aug 2006 02:02:45 +0200 Subject: [pypy-dev] Extension compiler and external DLLs In-Reply-To: <3bb8d3330608251658p4e3cfdbbycedd0c1222237c54@mail.gmail.com> References: <3bb8d3330608251305k333890blca6215055e854e8a@mail.gmail.com> <9eebf5740608251419x7ccf2e81gec3e915d78dbdd24@mail.gmail.com> <3bb8d3330608251658p4e3cfdbbycedd0c1222237c54@mail.gmail.com> Message-ID: <9eebf5740608251702u56b89d18n89634649fc6b910@mail.gmail.com> On 8/26/06, laurent destriau wrote: > Thank you for your answer. > Here is some more info: > - I use Visual C++ .Net 2003, which includes the OpenGL header > - I get the following warning: "warning C4013: glEnd not defined ; extern > returning int assumed" > - I get the following error: "error LNK2001: unresolved external symbol > _glEnd" Mmm that's happened to me too but I'm still looking for the solution > How can I tell the extension compiler how to find the proper > headers/libraries? Look at the definition of CConfig in this file: http://codespeak.net/svn/pypy/dist/pypy/module/readline/c_readline.py I have to admit it didn't work for me... -- Lawrence http://www.oluyede.org/blog From laurent.destriau at gmail.com Sat Aug 26 04:14:11 2006 From: laurent.destriau at gmail.com (laurent destriau) Date: Sat, 26 Aug 2006 04:14:11 +0200 Subject: [pypy-dev] Extension compiler and external DLLs In-Reply-To: <3bb8d3330608251849y58399db1v851e42e41cb650c1@mail.gmail.com> References: <3bb8d3330608251305k333890blca6215055e854e8a@mail.gmail.com> <9eebf5740608251419x7ccf2e81gec3e915d78dbdd24@mail.gmail.com> <3bb8d3330608251658p4e3cfdbbycedd0c1222237c54@mail.gmail.com> <9eebf5740608251702u56b89d18n89634649fc6b910@mail.gmail.com> <3bb8d3330608251849y58399db1v851e42e41cb650c1@mail.gmail.com> Message-ID: <3bb8d3330608251914l2a6db9a5yd06c4ffece607131@mail.gmail.com> > I have to admit it didn't work for me... It did for me: from pypy.rpython.rctypes.tool.ctypes_platform import configure, Library class CConfig: _header_ = "" _includes_ = ["windows.h", "gl/gl.h"] gl = Library("opengl32") gl = configure(CConfig)["gl"] glEnd = gl.glEnd glEnd.restype = None def DrawSomething(space): glEnd() Thanks! -- Laurent Destriau -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Sun Aug 27 19:30:01 2006 From: arigo at tunes.org (Armin Rigo) Date: Sun, 27 Aug 2006 19:30:01 +0200 Subject: [pypy-dev] Extension compiler and external DLLs In-Reply-To: <3bb8d3330608251914l2a6db9a5yd06c4ffece607131@mail.gmail.com> References: <3bb8d3330608251305k333890blca6215055e854e8a@mail.gmail.com> <9eebf5740608251419x7ccf2e81gec3e915d78dbdd24@mail.gmail.com> <3bb8d3330608251658p4e3cfdbbycedd0c1222237c54@mail.gmail.com> <9eebf5740608251702u56b89d18n89634649fc6b910@mail.gmail.com> <3bb8d3330608251849y58399db1v851e42e41cb650c1@mail.gmail.com> <3bb8d3330608251914l2a6db9a5yd06c4ffece607131@mail.gmail.com> Message-ID: <20060827173001.GA29486@code0.codespeak.net> Hi Laurent, On Sat, Aug 26, 2006 at 04:14:11AM +0200, laurent destriau wrote: > It did for me: > > from pypy.rpython.rctypes.tool.ctypes_platform import configure, Library > > class CConfig: > _header_ = "" > _includes_ = ["windows.h", "gl/gl.h"] > gl = Library("opengl32") This works because of the Library() object, which tells the extension compiler to pass the appropriate flags to the C linker. You can get the same effect by attaching flags directly to the function instead: glEnd = windll.opengl32.glEnd glEnd.restype = None glEnd.includes = ["windows.h", "gl/gl.h"] glEnd.libraries = ["opengl32"] # nb. untested code But using a CConfig is better anyway for other reasons, e.g. to avoid having to hard-code too many details of the type and structure declarations. A bientot, Armin. From hpk at trillke.net Tue Aug 29 15:48:06 2006 From: hpk at trillke.net (holger krekel) Date: Tue, 29 Aug 2006 15:48:06 +0200 Subject: [pypy-dev] pypy-sync thursday 4pm UTC+2 Message-ID: <20060829134806.GK21969@solar.trillke.net> Hi folks, at the nice and small Ireland sprint we discussed apart from the weather a bit future sprint planning. Next Thursday 4pm UTC+2, 31st August, there is now a pypy-sync meeting scheduled. Concrete initial topics: * rough sprint planning till March 2007 * concrete sprint planning beginning November, HHU/Duesseldorf? * security prototype: when to work on it and the actual workshop timing with the IBM guy(s), suggestion is January/February feel free to append topics, also at the meeting, but the meeting is limited to 30 minutes from my moderation side. best, holger From Ben.Young at risk.sungard.com Wed Aug 30 09:48:12 2006 From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com) Date: Wed, 30 Aug 2006 08:48:12 +0100 Subject: [pypy-dev] Fw: [Python-3000] Premature optimization and all that Message-ID: Hi PyPy'rs! I'm sure you will have already seen this email, but I thought it was quite interesting, as it may mean that Python 3000 is where PyPy can become faster than CPython! Given a years development time at the current rate of progress. I think PyPy is about 2.5 times slower than CPython at the moment isn't it? Cheers, Ben ----- Forwarded by Ben Young/Infinity on 30/08/2006 08:43 ----- python-3000-bounces+python=theyoungfamily.co.uk at python.org wrote on 29/08/2006 22:51:17: > Over lunch with Neal we came upon the topic of optimization and Python 3000. > > It is our strong opinion that in this stage of the Py3k project we > should focus on getting the new language spec and implementation > feature-complete, without worrying much about optimizations. > > We're doing major feature-level surgery, e.g. int/long unification, > str/unicode unification, range/xrange unification, keys() views, and > many others. Keeping everything working is hard work in and of itself; > having to keep it as fast as it was through all the transformations > just makes it that much harder. > > if Python 3.0 alpha 1 is twice as slow as 2.5, that's okay with me; we > will have another year to do performance measurements and add new > optimizations in the ramp-up for 3.0 final. Even if 3.0 final is a bit > slower than 2.5 it doesn't bother me too much; we can continue the > tweaks during the 3.1 and 3.2 development cycle. > > Note: I'm note advicating wholesale proactive *removal* of > optimizations. However, I'm allowing new features to slow down > performance temporarily while we get all the features in place. I > expect that the optimization possibilities and needs will be different > than for 2.x, since some of the fundamental data types will be so > different. > > In particular, I hope that Martin's int/long unification code can land > ASAP; it's much better to have this feature landed in the p3yk branch, > where everyone can bang on it easily, and learn how this affects user > code, even if it makes everything twice as slow. This seems much > preferable over having it languish in a separate branch until it's > perfect. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ > Python-3000 mailing list > Python-3000 at python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: http://mail.python. > org/mailman/options/python-3000/python%40theyoungfamily.co.uk > From haggai.eran at gmail.com Wed Aug 30 10:53:56 2006 From: haggai.eran at gmail.com (Haggai Eran) Date: Wed, 30 Aug 2006 11:53:56 +0300 Subject: [pypy-dev] compilemodule.py not working Message-ID: Hi I cannot get the compilemodule to work. It seems that strings returned from PyString_FromStringAndSize are unwrapped automatically, causing ctypes.byref to fail. Traceback (most recent call last): File "../bin/compilemodule.py", line 12, in ? main(sys.argv) File "/usr/src/pypy-dist/pypy/rpython/rctypes/tool/compilemodule.py", line 78, in main c_ext_module = compilemodule(argv[1], interactive=True) File "/usr/src/pypy-dist/pypy/rpython/rctypes/tool/compilemodule.py", line 26, in compilemodule module = ModuleClass(space, space.wrap(modname)) File "/usr/src/pypy-dist/pypy/module/thread/__init__.py", line 25, in __init__ MixedModule.__init__(self, space, *args) File "/usr/src/pypy-dist/pypy/interpreter/mixedmodule.py", line 18, in __init__ Module.__init__(self, space, w_name) File "/usr/src/pypy-dist/pypy/interpreter/module.py", line 17, in __init__ space.setitem(w_dict, space.new_interned_str('__name__'), w_name) File "/usr/src/pypy-dist/pypy/objspace/cpy/objspace.py", line 171, in new_interned_str PyString_InternInPlace(byref(w_s)) TypeError: byref() argument must be a ctypes instance, not 'str' -- Haggai Eran From haggai.eran at gmail.com Thu Aug 31 12:35:13 2006 From: haggai.eran at gmail.com (Haggai Eran) Date: Thu, 31 Aug 2006 13:35:13 +0300 Subject: [pypy-dev] compilemodule.py not working In-Reply-To: References: Message-ID: Silly me: I had an older version of ctypes. Version 0.9.9 and 1.0.0 don't have this problem. Haggai On 8/30/06, Haggai Eran wrote: > Hi > I cannot get the compilemodule to work. It seems that strings returned > from PyString_FromStringAndSize are unwrapped automatically, causing > ctypes.byref to fail. > > Traceback (most recent call last): > File "../bin/compilemodule.py", line 12, in ? > main(sys.argv) > File "/usr/src/pypy-dist/pypy/rpython/rctypes/tool/compilemodule.py", > line 78, in main > c_ext_module = compilemodule(argv[1], interactive=True) > File "/usr/src/pypy-dist/pypy/rpython/rctypes/tool/compilemodule.py", > line 26, in compilemodule > module = ModuleClass(space, space.wrap(modname)) > File "/usr/src/pypy-dist/pypy/module/thread/__init__.py", line 25, in __init__ > MixedModule.__init__(self, space, *args) > File "/usr/src/pypy-dist/pypy/interpreter/mixedmodule.py", line 18, > in __init__ > Module.__init__(self, space, w_name) > File "/usr/src/pypy-dist/pypy/interpreter/module.py", line 17, in __init__ > space.setitem(w_dict, space.new_interned_str('__name__'), w_name) > File "/usr/src/pypy-dist/pypy/objspace/cpy/objspace.py", line 171, > in new_interned_str > PyString_InternInPlace(byref(w_s)) > TypeError: byref() argument must be a ctypes instance, not 'str' > > > -- > Haggai Eran > -- Haggai Eran