From arigo at tunes.org Wed May 2 20:42:49 2007 From: arigo at tunes.org (Armin Rigo) Date: Wed, 2 May 2007 20:42:49 +0200 Subject: [pypy-dev] Forward: Dyla 07 In-Reply-To: References: <20070414090553.GA20210@code0.codespeak.net> Message-ID: <20070502184249.GA14450@code0.codespeak.net> Hi Terry, hi all, On Sat, Apr 14, 2007 at 07:21:56PM -0400, Terry Reedy wrote: > | > fwiw, I was considering to submit my Prolog paper (or a variation of > it) > | > there - but we can do some common planning, not sure whether we should > | > submit two PyPy papers. > | > | I think that it's a good place to submit a "core" PyPy paper, and I also > | think that your Prolog paper is independent enough to not count as > | another PyPy paper. In fact I'd imagine that if we were "academic > | enough", at this point, several of us should try to publish several > | papers independently on several aspects of PyPy... > > For instance, if there is anything innovative in the JIT work, then that > might make a nice paper in itself. Now that the last-minute report writing is done - at least the technical reports - we should think about Dyla again. Remember that it is not a conference but a workshop, which as far as I understand it means that everybody is a speaker. We need to send in "position papers" - "we really think that this is the way this should be done". The obvious topics for us are "nobody should write complicated {virtual machines, interpreters, JIT compilers} by hand". Thoughts, topics? We have plenty of topics in and around PyPy, but let's keep in mind that each paper needs a "position paper" angle. A bientot, Armin. From arigo at tunes.org Wed May 2 20:51:05 2007 From: arigo at tunes.org (Armin Rigo) Date: Wed, 2 May 2007 20:51:05 +0200 Subject: [pypy-dev] What about a Slate front-end? In-Reply-To: <9c0bb8a00704300645p463b04f6vec7a3ca226a3c4a4@mail.gmail.com> References: <9c0bb8a00704300645p463b04f6vec7a3ca226a3c4a4@mail.gmail.com> Message-ID: <20070502185105.GB14450@code0.codespeak.net> Hi Paul, On Mon, Apr 30, 2007 at 09:45:54AM -0400, Paul deGrandis wrote: > Not too long ago there was a discussion about possible front-ends. > I know someone here is part of the tunes project... so how about a slate > front end? Slate is a strange language, but I guess its basics are not hard to write in RPython, if someone is interested. A Smalltalk front-end might be more useful to start with, though. I am the one here linked with the Tunes project - the e-mail address is some hint - but I have to say that I don't find Slate particularly exciting, beyond the fact that it starts from an interesting idea for multimethods. The very short file http://codespeak.net/svn/pypy/dist/pypy/tool/pairtype.py was inspired by this. A bientot, Armin. From lac at openend.se Sun May 6 09:16:41 2007 From: lac at openend.se (Laura Creighton) Date: Sun, 6 May 2007 09:16:41 +0200 Subject: [pypy-dev] Did anything happen with the mini coding Sprint in Poland idea? Message-ID: <200705060716.l467GfEk004421@theraft.openend.se> Dethe Elza is planning his European vacation, and he is flying into Amsterdam, August 16th and then going to Prague. The bulk of the vacation will be in Sofia, with some side trips, and then back to Amsterdam for a return trip Sept 11. So he misses EuroPython. He'd like to meet pypyers face to faqce and hack if possible. Do we have anything planned yet? Laura From stephan.diehl at gmx.net Mon May 7 09:00:56 2007 From: stephan.diehl at gmx.net (Stephan Diehl) Date: Mon, 07 May 2007 09:00:56 +0200 Subject: [pypy-dev] Did anything happen with the mini coding Sprint in Poland idea? In-Reply-To: <200705060716.l467GfEk004421@theraft.openend.se> References: <200705060716.l467GfEk004421@theraft.openend.se> Message-ID: <463ECEA8.5050805@gmx.net> What about PyCon UK on 8/9.9. (http://www.pyconuk.org/)? Just a thought Stephan Laura Creighton wrote: > Dethe Elza is planning his European vacation, and he is flying into > Amsterdam, August 16th and then going to Prague. The bulk of the vacation > will be in Sofia, with some side trips, and then back to Amsterdam for > a return trip Sept 11. So he misses EuroPython. He'd like to meet > pypyers face to faqce and hack if possible. Do we have anything > planned yet? > > Laura > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From holger at merlinux.de Tue May 8 08:51:38 2007 From: holger at merlinux.de (holger krekel) Date: Tue, 8 May 2007 08:51:38 +0200 Subject: [pypy-dev] Forward: Dyla 07 In-Reply-To: <20070502184249.GA14450@code0.codespeak.net> References: <20070414090553.GA20210@code0.codespeak.net> <20070502184249.GA14450@code0.codespeak.net> Message-ID: <20070508065138.GJ25045@solar.trillke> Hi Armin, hi all, On Wed, May 02, 2007 at 20:42 +0200, Armin Rigo wrote: > Hi Terry, hi all, > > On Sat, Apr 14, 2007 at 07:21:56PM -0400, Terry Reedy wrote: > > | > fwiw, I was considering to submit my Prolog paper (or a variation of > > it) > > | > there - but we can do some common planning, not sure whether we should > > | > submit two PyPy papers. > > | > > | I think that it's a good place to submit a "core" PyPy paper, and I also > > | think that your Prolog paper is independent enough to not count as > > | another PyPy paper. In fact I'd imagine that if we were "academic > > | enough", at this point, several of us should try to publish several > > | papers independently on several aspects of PyPy... > > > > For instance, if there is anything innovative in the JIT work, then that > > might make a nice paper in itself. > > Now that the last-minute report writing is done - at least the technical > reports - we should think about Dyla again. Remember that it is not a > conference but a workshop, which as far as I understand it means that > everybody is a speaker. We need to send in "position papers" - "we > really think that this is the way this should be done". The obvious > topics for us are "nobody should write complicated {virtual machines, > interpreters, JIT compilers} by hand". > > Thoughts, topics? We have plenty of topics in and around PyPy, but > let's keep in mind that each paper needs a "position paper" angle. I hope we can re-use parts of our technical EU reports (most of which haven't been published yet at a conference). Currently I could imagine two position papers: nobody should write complicated VMs/JIT-compilers by hand interpreters should offer {security,persistence,distribution} features directly (instead of adding Application APIs) Until Friday, i am still quite busy with lots of EU finalisation issues - not sure how much i can do till then but on saturday i could be there to work/help on the paper submissions (and it's the submission deadline IIUC, sigh). best, holger From arigo at tunes.org Tue May 8 13:35:11 2007 From: arigo at tunes.org (Armin Rigo) Date: Tue, 8 May 2007 13:35:11 +0200 Subject: [pypy-dev] Forward: Dyla 07 In-Reply-To: <20070508065138.GJ25045@solar.trillke> References: <20070414090553.GA20210@code0.codespeak.net> <20070502184249.GA14450@code0.codespeak.net> <20070508065138.GJ25045@solar.trillke> Message-ID: <20070508113511.GA20580@code0.codespeak.net> Hi, On Tue, May 08, 2007 at 08:51:38AM +0200, holger krekel wrote: > Currently I could imagine two position papers: > > nobody should write complicated VMs/JIT-compilers by hand > > interpreters should offer {security,persistence,distribution} > features directly (instead of adding Application APIs) That would make sense, but of course the limiting factor is going to be who wants to write them. I have started drafting the first one, but for now I just hope I can get it reasonably done by the deadline. I don't see me helping on a second paper as well. BTW, googling "how to write a position paper" gives useful hints about the expected structure and content. A bientot, Armin. From jgustak at gmail.com Wed May 9 23:05:17 2007 From: jgustak at gmail.com (Jakub Gustak) Date: Wed, 9 May 2007 23:05:17 +0200 Subject: [pypy-dev] scheme parser. Message-ID: I have been experimenting with rlib.parsing.ebnfparse today. One thing which is not described, if you want to use ebnfparse you have to: > py.test.config.parse([]) Can anyone explain what happens there? Is there any other "magical" initialization stuff which i have to know before going on? ebnfparse seems to work just fine, so I will stick with it, unless there is any contraindication. Now I am considering if the parser should generate some bytecode? Maybe pickling (not rpythonic) AST tree will be just fine (like in js interpreter)? Sincerely, Jakub Gustak From santagada at gmail.com Thu May 10 00:24:19 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Wed, 9 May 2007 19:24:19 -0300 Subject: [pypy-dev] scheme parser. In-Reply-To: References: Message-ID: <4AB71EA1-0AF0-4437-BFC9-674122A8D32F@gmail.com> Em 09/05/2007, ?s 18:05, Jakub Gustak escreveu: > I have been experimenting with rlib.parsing.ebnfparse today. One thing > which is not described, if you want to use ebnfparse you have to: >> py.test.config.parse([]) > I don't do that, so thats probably not necessary. Wy not put your code on lang/scheme so we can all see it? > Can anyone explain what happens there? Is there any other "magical" > initialization stuff which i have to know before going on? > > ebnfparse seems to work just fine, so I will stick with it, unless > there is any contraindication. parsing is a great language parser generator, and probably has everything a scheme interpreter will need. > Now I am considering if the parser should generate some bytecode? > Maybe pickling (not rpythonic) AST tree will be just fine (like in js > interpreter)? I am pickling the tree only if running on top of CPython, because RPython don't support that. And even then, it is really just a hack because parsing took a lot of time running on top of cpython. Iam going to give you the same advice I got from armin when I started... begin with AST and then when you have your parser ready we can see if using bytecode really get you faster. -- Leonardo Santagada santagada at gmail.com From arigo at tunes.org Thu May 10 14:59:15 2007 From: arigo at tunes.org (Armin Rigo) Date: Thu, 10 May 2007 14:59:15 +0200 Subject: [pypy-dev] scheme parser. In-Reply-To: <4AB71EA1-0AF0-4437-BFC9-674122A8D32F@gmail.com> References: <4AB71EA1-0AF0-4437-BFC9-674122A8D32F@gmail.com> Message-ID: <20070510125915.GA20089@code0.codespeak.net> Hi, On Wed, May 09, 2007 at 07:24:19PM -0300, Leonardo Santagada wrote: > > Now I am considering if the parser should generate some bytecode? > > Maybe pickling (not rpythonic) AST tree will be just fine (like in js > > interpreter)? > > I am pickling the tree only if running on top of CPython, because > RPython don't support that. And even then, it is really just a hack > because parsing took a lot of time running on top of cpython. Iam > going to give you the same advice I got from armin when I started... > begin with AST and then when you have your parser ready we can see if > using bytecode really get you faster. Yes, that's even more true for Scheme, where the AST is very simple. For now you should just interpret it, and we can see later if speed-ups can be achieved with bytecode. Also, if you are directly using rlib.parsing, then you don't need any pickling: parse the source into an AST, and pass the AST objects directly to the interpreter. (We can think later if it makes sense to add an equivalent of the .pyc files, but that's really questions for the very long term only.) A bientot, Armin. From cfbolz at gmx.de Thu May 10 16:20:54 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 10 May 2007 16:20:54 +0200 Subject: [pypy-dev] scheme parser. In-Reply-To: <20070510125915.GA20089@code0.codespeak.net> References: <4AB71EA1-0AF0-4437-BFC9-674122A8D32F@gmail.com> <20070510125915.GA20089@code0.codespeak.net> Message-ID: <46432A46.1060501@gmx.de> Armin Rigo wrote: > Yes, that's even more true for Scheme, where the AST is very simple. > For now you should just interpret it, and we can see later if speed-ups > can be achieved with bytecode. Also, if you are directly using > rlib.parsing, then you don't need any pickling: parse the source into an > AST, and pass the AST objects directly to the interpreter. (We can > think later if it makes sense to add an equivalent of the .pyc files, > but that's really questions for the very long term only.) I kind of hope that the parser is fast enough to not have to cache the trees for "reasonably" sized programs. I haven't measured them, but the lexing and parsing algorithms have nice bounds. In addition, it's probably simple to have a generic pickle format for parse trees that could be re-used across all users of rlib/parsing. But for Scheme even that is probably too much work, since the data structures should be very easy to serialize. Cheers, Carl Friedrich From len-l at telus.net Fri May 11 00:07:42 2007 From: len-l at telus.net (Lenard Lindstrom) Date: Thu, 10 May 2007 15:07:42 -0700 Subject: [pypy-dev] scheme parser. In-Reply-To: <20070510125915.GA20089@code0.codespeak.net> References: <4AB71EA1-0AF0-4437-BFC9-674122A8D32F@gmail.com> <20070510125915.GA20089@code0.codespeak.net> Message-ID: <464397AE.1050902@telus.net> Armin Rigo wrote: > Hi, > > On Wed, May 09, 2007 at 07:24:19PM -0300, Leonardo Santagada wrote: > >>> Now I am considering if the parser should generate some bytecode? >>> Maybe pickling (not rpythonic) AST tree will be just fine (like in js >>> interpreter)? >>> >> I am pickling the tree only if running on top of CPython, because >> RPython don't support that. And even then, it is really just a hack >> because parsing took a lot of time running on top of cpython. Iam >> going to give you the same advice I got from armin when I started... >> begin with AST and then when you have your parser ready we can see if >> using bytecode really get you faster. >> > > Yes, that's even more true for Scheme, where the AST is very simple. > For now you should just interpret it, and we can see later if speed-ups > can be achieved with bytecode. Also, if you are directly using > rlib.parsing, then you don't need any pickling: parse the source into an > AST, and pass the AST objects directly to the interpreter. (We can > think later if it makes sense to add an equivalent of the .pyc files, > but that's really questions for the very long term only.) > > The lisp interpreter loop body is very simple: (print (eval (read))) First implement read and print. Implement eval when input can be reliably converted to s-expressions. There is no need for a distinct parser or special AST structures if that is the plan. That would come into play in writing a compiler. Lenard Lindstrom From holger at merlinux.de Fri May 11 00:52:38 2007 From: holger at merlinux.de (holger krekel) Date: Fri, 11 May 2007 00:52:38 +0200 Subject: [pypy-dev] quick review of final activity report? Message-ID: <20070510225238.GG25045@solar.trillke> Hi all! here is our preliminary "final activity report" draft which summarizes the whole PyPy EU project period on several levels. (Heh, the EU part is not finished yet - we are heading towards the final review on 31st May). http://codespeak.net/~hpk/pypy-final-activity-may-10-2007.pdf If you ad-hoc review and feedback on the report during the next 12-14 hours (until friday 11th 9am UTC+2) i could still try to incorporate changes before it is declared finished and published ... particularly readability and sense-making are of interest :) feedback is welcome also later, of course. best & thanks, holger -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From arigo at tunes.org Sun May 13 15:12:30 2007 From: arigo at tunes.org (Armin Rigo) Date: Sun, 13 May 2007 15:12:30 +0200 Subject: [pypy-dev] Dyla 07 Message-ID: <20070513131230.GA6079@code0.codespeak.net> Hi all, I didn't do any work on any Dyla'07 paper so I was about to post some apology and thanks to the people that proposed to help me even though they were more busy than me with EU reports. Recently I have not been up to working on anything at all (which is not an excuse but just a fact I guess). However, the submission deadline was extended to May 27th. I still don't know if I'm going to find enough motivation, but that gives us a second chance... A bientot, Armin From alexandre.fayolle at free.fr Mon May 14 14:26:45 2007 From: alexandre.fayolle at free.fr (Alexandre Fayolle) Date: Mon, 14 May 2007 14:26:45 +0200 Subject: [pypy-dev] building pypy on a powerpc running linux Message-ID: <1179145605.464855851cd5e@imp.free.fr> Hi, I know pypy builds on macos X, but has anyone tried (and succeeded) to translate on a powerpc running Linux? The Debian autobuilders have failed to compile it, and I wonder if this is an issue in my package or just that this platform is not supported. The build logs are available at http://buildd.debian.org/build.php?pkg=pypy Thanks in advance -- Alexandre Fayolle From fijal at genesilico.pl Mon May 14 17:04:27 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 14 May 2007 17:04:27 +0200 Subject: [pypy-dev] building pypy on a powerpc running linux In-Reply-To: <1179145605.464855851cd5e@imp.free.fr> References: <1179145605.464855851cd5e@imp.free.fr> Message-ID: <46487A7B.3050608@genesilico.pl> Alexandre Fayolle wrote: > Hi, > > I know pypy builds on macos X, but has anyone tried (and succeeded) to translate > on a powerpc running Linux? The Debian autobuilders have failed to compile it, > and I wonder if this is an issue in my package or just that this platform is not > supported. > > The build logs are available at http://buildd.debian.org/build.php?pkg=pypy > > Thanks in advance > > -- > Alexandre Fayolle > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > > :ms > > The nightly benchmarks are running on power pc processor. http://tuatara.cs.uni-duesseldorf.de/benchmark.html From fijal at genesilico.pl Mon May 14 17:06:05 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Mon, 14 May 2007 17:06:05 +0200 Subject: [pypy-dev] building pypy on a powerpc running linux In-Reply-To: <1179145605.464855851cd5e@imp.free.fr> References: <1179145605.464855851cd5e@imp.free.fr> Message-ID: <46487ADD.8050805@genesilico.pl> Alexandre Fayolle wrote: > Hi, > > I know pypy builds on macos X, but has anyone tried (and succeeded) to translate > on a powerpc running Linux? The Debian autobuilders have failed to compile it, > and I wonder if this is an issue in my package or just that this platform is not > supported. > > The build logs are available at http://buildd.debian.org/build.php?pkg=pypy > > Thanks in advance > > For me it seems like build started swapping (not enough memory or so?) and was killed due to inactivity. From holger at merlinux.de Mon May 14 20:59:27 2007 From: holger at merlinux.de (holger krekel) Date: Mon, 14 May 2007 20:59:27 +0200 Subject: [pypy-dev] [ann] pypy EU project finishing up Message-ID: <20070514185927.GW25045@solar.trillke> Hi all, puh! ... The 28 months of the PyPy[*] EU project period have been an intense experience on many levels. We wrote a summary of results, development methods and experiences here: http://codespeak.net/pypy/extradoc/eu-report/PYPY-EU-Final-Activity-Report.pdf and are now heading for the final review meeting in Bruxelles (31st May). Most involved people look forward to some resting and letting the dust settle before tackling next steps and sprints. best, holger [*] The PyPy project aims to generate flexible and fast Python Implementations for various target environments and provides largely re-usable capabilities for implementing other dynamic languages. More info: http://codespeak.net/pypy -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From bea at changemaker.nu Tue May 15 06:04:30 2007 From: bea at changemaker.nu (=?ISO-8859-1?Q?Beatrice_D=FCring?=) Date: Tue, 15 May 2007 06:04:30 +0200 Subject: [pypy-dev] PyPy Europython talks? Message-ID: <4649314E.2020303@changemaker.nu> Hi there Back from Japan and thinking a bit about Europython 2007. Submission deadline is closing in and I wonder if we are to do any PyPy talks at EP 2007? I would be prepared to do one PyPy talk on the methodology - such as an experience summary on how we worked with sprints etc.... What do we want to do on the technical side? Submission deadline 18th of May. Sorry to ask about this when I know many are exhausted and focused on finalizing the EU-review - but I felt the need to ask.... Cheers Bea From faassen at startifact.com Tue May 15 13:00:05 2007 From: faassen at startifact.com (Martijn Faassen) Date: Tue, 15 May 2007 13:00:05 +0200 Subject: [pypy-dev] PyPy Europython talks? In-Reply-To: <4649314E.2020303@changemaker.nu> References: <4649314E.2020303@changemaker.nu> Message-ID: Beatrice D?ring wrote: > Hi there > > Back from Japan and thinking a bit about Europython 2007. > > Submission deadline is closing in and I wonder if we are to do any PyPy > talks at EP 2007? I would be prepared to do one PyPy talk on the methodology > - such as an experience summary on how we worked with sprints etc.... > > What do we want to do on the technical side? > > Submission deadline 18th of May. > > Sorry to ask about this when I know many are exhausted and focused > on finalizing the EU-review - but I felt the need to ask.... I would like to see PyPy talks at EuroPython! It's a tradition! :) Regards, Martijn From fijal at genesilico.pl Tue May 15 13:51:52 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Tue, 15 May 2007 13:51:52 +0200 Subject: [pypy-dev] PyPy Europython talks? In-Reply-To: <4649314E.2020303@changemaker.nu> References: <4649314E.2020303@changemaker.nu> Message-ID: <46499ED8.7060008@genesilico.pl> Beatrice D?ring wrote: > Hi there > > Back from Japan and thinking a bit about Europython 2007. > > Submission deadline is closing in and I wonder if we are to do any PyPy > talks at EP 2007? I would be prepared to do one PyPy talk on the methodology > - such as an experience summary on how we worked with sprints etc.... > > What do we want to do on the technical side? > > Submission deadline 18th of May. > > Sorry to ask about this when I know many are exhausted and focused > on finalizing the EU-review - but I felt the need to ask.... > > Cheers > > Bea Hi Bea! There were some discussions on IRC regarding technical talks on the Europython. The rough outline what was proposed was to give 3 technical talks. 1. "usual pypy talk" 2. RPython talk (anto was talking about it) 3. unique features talk (regarding interpreter). (me & hpk are planning to do this). This is just my POV, but there are some ideas to give those talks :) From bea at changemaker.nu Tue May 15 19:27:23 2007 From: bea at changemaker.nu (=?UTF-8?B?QmVhdHJpY2UgRMO8cmluZw==?=) Date: Tue, 15 May 2007 19:27:23 +0200 Subject: [pypy-dev] PyPy Europython talks? In-Reply-To: <46499ED8.7060008@genesilico.pl> References: <4649314E.2020303@changemaker.nu> <46499ED8.7060008@genesilico.pl> Message-ID: <4649ED7B.4040109@changemaker.nu> Hi there Maciek Fijalkowski skrev: > Beatrice D?ring wrote: >> Hi there >> >> Back from Japan and thinking a bit about Europython 2007. >> >> Submission deadline is closing in and I wonder if we are to do any PyPy >> talks at EP 2007? I would be prepared to do one PyPy talk on the >> methodology >> - such as an experience summary on how we worked with sprints etc.... >> >> What do we want to do on the technical side? >> >> Submission deadline 18th of May. >> >> Sorry to ask about this when I know many are exhausted and focused >> on finalizing the EU-review - but I felt the need to ask.... >> >> Cheers >> >> Bea > Hi Bea! > > There were some discussions on IRC regarding technical talks on the > Europython. The rough outline what was proposed was to give 3 > technical talks. > > 1. "usual pypy talk" > 2. RPython talk (anto was talking about it) > 3. unique features talk (regarding interpreter). (me & hpk are > planning to do this). > > This is just my POV, but there are some ideas to give those talks :) > > Thanks for the answer Maciek - it sounds like we are upholding the PyPy tradition Martijn holds so dear ;-) Cheers Bea From anto.cuni at gmail.com Thu May 17 20:34:33 2007 From: anto.cuni at gmail.com (Antonio Cuni) Date: Thu, 17 May 2007 20:34:33 +0200 Subject: [pypy-dev] DLS paper on RPython In-Reply-To: <419A3BF2-694D-4A50-A340-EABBD563D37E@alum.mit.edu> References: <4643232C.9020007@gmail.com> <08FB5296-C3B7-48C3-B6A1-1750D085ACDB@alum.mit.edu> <46436E08.2040801@gmail.com> <464462EA.9070301@gmail.com> <180B9E23-9667-4278-A811-DBB1E77AB2F9@alum.mit.edu> <46481697.4040101@disi.unige.it> <7ADA7D08-1E1A-4874-BC92-3E69C83985BB@alum.mit.edu> <46499E9B.6020404@disi.unige.it> <96E254B7-C6B0-4F89-887F-48D5632CA499@alum.mit.edu> <4649CFD3.9000204@disi.unige.it> <4649D0A6.8000806@disi.unige.it> <464C15AF.6090205@disi.unige.it> <464C19A6.2020809@gmail.com> <464C3232.5010405@disi.unige.it> <6C5016FD-7582-4361-BA2B-071AEC729187@alum.mit.edu> <464C62D2.7040801@gmail.com> <464C7437.7090105@gmail.com> <419A3BF2-694D-4A50-A340-EABBD563D37E@alum.mit.edu> Message-ID: <464CA039.8080706@gmail.com> [I respond only to you because I don't think Massimo and Davide are interested in such details; I'm also cc-ing pypy-dev] Niko Matsakis wrote: > Ok. I'll look at that some. I may have to rewrite my section on > exceptions to describe the type-wrapping solution; I wrote it to > describe the newer system I started to checked in today, but then I > found that RPython allows any object, not just Exceptions, to be thrown, > meaning that this newer system won't work as well as I thought (and so > is currently disabled). Probably the simplest way to solve the problem is not to allow arbitrary objects to be thrown in RPython; I quick grep inside objspace/std and interpret didn't show any case in which this feature is used, and in any case it should be very easy to patch. Else, you could special-case the raise/except when using subclasses of Exception, and don't do the wrapping in those cases; of course you would have to be careful when catching all the exceptions, something like this: try: foo() except: bar() needs to be translated to: try { foo() } catch(Exception e) { // this is __builtin__.Exception bar() } catch(ExceptionWrapper e) { bar() } or something similar. I think we should really try to avoid ExceptionWrapper beacuse it's both ugly and probably veeery slow. ciao Anto From niko at alum.mit.edu Thu May 17 22:07:12 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Thu, 17 May 2007 22:07:12 +0200 Subject: [pypy-dev] Throwing arbitrary objects as exceptions (was Re: DLS paper on RPython) In-Reply-To: <464CA039.8080706@gmail.com> References: <4643232C.9020007@gmail.com> <08FB5296-C3B7-48C3-B6A1-1750D085ACDB@alum.mit.edu> <46436E08.2040801@gmail.com> <464462EA.9070301@gmail.com> <180B9E23-9667-4278-A811-DBB1E77AB2F9@alum.mit.edu> <46481697.4040101@disi.unige.it> <7ADA7D08-1E1A-4874-BC92-3E69C83985BB@alum.mit.edu> <46499E9B.6020404@disi.unige.it> <96E254B7-C6B0-4F89-887F-48D5632CA499@alum.mit.edu> <4649CFD3.9000204@disi.unige.it> <4649D0A6.8000806@disi.unige.it> <464C15AF.6090205@disi.unige.it> <464C19A6.2020809@gmail.com> <464C3232.5010405@disi.unige.it> <6C5016FD-7582-4361-BA2B-071AEC729187@alum.mit.edu> <464C62D2.7040801@gmail.com> <464C7437.7090105@gmail.com> <419A3BF2-694D-4A50-A340-EABBD563D37E@alum.mit.edu> <464CA039.8080706@gmail.com> Message-ID: I guess the question is whether people consider the ability to throw arbitrary objects (rather than only those whose type is a subtype of Exception) a feature or a bug. I'm on the fence myself: it makes translating to the jvm and clr easier if we prohibit arbitrary objects, and it seems like a marginal use-case, but on the other hand, well, Python can do it, so why not? If anyone wanted to give me a few pointers as to what has to be changed to force exceptions to be subtypes of Exception, I'd be excited to try hacking it, just so I can learn more about that part of PyPy. On the other hand, I think that a hybrid wrapping strategy could actually work reasonably well and avoid wrapping in the 99% of cases where Exception sub-types are thrown and caught. Therefore, I'd say the real question is how people on the list think that RPython "ought" to behave. Niko From pedronis at openendsystems.com Fri May 18 10:29:02 2007 From: pedronis at openendsystems.com (Samuele Pedroni) Date: Fri, 18 May 2007 10:29:02 +0200 Subject: [pypy-dev] Throwing arbitrary objects as exceptions (was Re: DLS paper on RPython) In-Reply-To: References: <4643232C.9020007@gmail.com> <08FB5296-C3B7-48C3-B6A1-1750D085ACDB@alum.mit.edu> <46436E08.2040801@gmail.com> <464462EA.9070301@gmail.com> <180B9E23-9667-4278-A811-DBB1E77AB2F9@alum.mit.edu> <46481697.4040101@disi.unige.it> <7ADA7D08-1E1A-4874-BC92-3E69C83985BB@alum.mit.edu> <46499E9B.6020404@disi.unige.it> <96E254B7-C6B0-4F89-887F-48D5632CA499@alum.mit.edu> <4649CFD3.9000204@disi.unige.it> <4649D0A6.8000806@disi.unige.it> <464C15AF.6090205@disi.unige.it> <464C19A6.2020809@gmail.com> <464C3232.5010405@disi.unige.it> <6C5016FD-7582-4361-BA2B-071AEC729187@alum.mit.edu> <464C62D2.7040801@gmail.com> <464C7437.7090105@gmail.com> <419A3BF2-694D-4A50-A340-EABBD563D37E@alum.mit.edu> <464CA039.8080706@gmail.com> Message-ID: <464D63CE.3060300@openendsystems.com> Niko Matsakis wrote: > I guess the question is whether people consider the ability to throw > arbitrary objects (rather than only those whose type is a subtype of > Exception) a feature or a bug. > > I'm on the fence myself: it makes translating to the jvm and clr > easier if we prohibit arbitrary objects, and it seems like a marginal > use-case, but on the other hand, well, Python can do it, so why not? > the idea is that only subclasses of Exception/BaseException can be thrown in RPython, we have no code to enforce that right now OTOH if you find places in our RPython code that don't do that those are bugs to fix. > If anyone wanted to give me a few pointers as to what has to be > changed to force exceptions to be subtypes of Exception, I'd be > excited to try hacking it, just so I can learn more about that part > of PyPy. > > On the other hand, I think that a hybrid wrapping strategy could > actually work reasonably well and avoid wrapping in the 99% of cases > where Exception sub-types are thrown and caught. > > Therefore, I'd say the real question is how people on the list think > that RPython "ought" to behave. > > > Niko > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From niko at alum.mit.edu Fri May 18 11:14:22 2007 From: niko at alum.mit.edu (Niko Matsakis) Date: Fri, 18 May 2007 11:14:22 +0200 Subject: [pypy-dev] Throwing arbitrary objects as exceptions (was Re: DLS paper on RPython) In-Reply-To: <464D63CE.3060300@openendsystems.com> References: <4643232C.9020007@gmail.com> <08FB5296-C3B7-48C3-B6A1-1750D085ACDB@alum.mit.edu> <46436E08.2040801@gmail.com> <464462EA.9070301@gmail.com> <180B9E23-9667-4278-A811-DBB1E77AB2F9@alum.mit.edu> <46481697.4040101@disi.unige.it> <7ADA7D08-1E1A-4874-BC92-3E69C83985BB@alum.mit.edu> <46499E9B.6020404@disi.unige.it> <96E254B7-C6B0-4F89-887F-48D5632CA499@alum.mit.edu> <4649CFD3.9000204@disi.unige.it> <4649D0A6.8000806@disi.unige.it> <464C15AF.6090205@disi.unige.it> <464C19A6.2020809@gmail.com> <464C3232.5010405@disi.unige.it> <6C5016FD-7582-4361-BA2B-071AEC729187@alum.mit.edu> <464C62D2.7040801@gmail.com> <464C7437.7090105@gmail.com> <419A3BF2-694D-4A50-A340-EABBD563D37E@alum.mit.edu> <464CA039.8080706@gmail.com> <464D63CE.3060300@openendsystems.com> Message-ID: <4BA670AE-8EC2-4E47-8756-9BE46E0DE2A2@alum.mit.edu> >> > the idea is that only subclasses of Exception/BaseException can be > thrown in RPython, we have no code > to enforce that right now OTOH if you find places in our RPython > code that don't do that those > are bugs to fix. Okay, I guess the right thing to do then is to insert a CHECKCAST when the static type of a thrown exception is not a sub-type of Exception. "Correct" RPython should work, and the rest will throw a ClassCastException. If the annotator/rtyper were later changed to provide a static type better than Object, then the casts won't be generated. That's what I've done for now. It fixes the broken test, at least. :) Niko From tjreedy at udel.edu Sat May 19 05:51:13 2007 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 18 May 2007 23:51:13 -0400 Subject: [pypy-dev] Throwing arbitrary objects as exceptions (was Re: DLSpaper on RPython) References: <4643232C.9020007@gmail.com><08FB5296-C3B7-48C3-B6A1-1750D085ACDB@alum.mit.edu><46436E08.2040801@gmail.com><464462EA.9070301@gmail.com><180B9E23-9667-4278-A811-DBB1E77AB2F9@alum.mit.edu><46481697.4040101@disi.unige.it><7ADA7D08-1E1A-4874-BC92-3E69C83985BB@alum.mit.edu><46499E9B.6020404@disi.unige.it><96E254B7-C6B0-4F89-887F-48D5632CA499@alum.mit.edu><4649CFD3.9000204@disi.unige.it> <4649D0A6.8000806@disi.unige.it><464C15AF.6090205@disi.unige.it> <464C19A6.2020809@gmail.com><464C3232.5010405@disi.unige.it><6C5016FD-7582-4361-BA2B-071AEC729187@alum.mit.edu><464C62D2.7040801@gmail.com><464C7437.7090105@gmail.com><419A3BF2-694D-4A50-A340-EABBD563D37E@alum.mit.edu><464CA039.8080706@gmail.com> Message-ID: "Niko Matsakis" wrote in message news:FF531020-FE60-47B2-A30F-CB13D6E696F0 at alum.mit.edu... |I guess the question is whether people consider the ability to throw | arbitrary objects (rather than only those whose type is a subtype of | Exception) a feature or a bug. | | I'm on the fence myself: it makes translating to the jvm and clr | easier if we prohibit arbitrary objects, and it seems like a marginal | use-case, but on the other hand, well, Python can do it, so why not? 'Python can do it'??? In 2.4, only throw (old-style) classes or instances thereof or (deprecated) strings. In 2.5, I believe base exception was made new style. In 3.0, I expect subtype thereof will be enforced. tjr From mauriceling at gmail.com Mon May 21 09:14:49 2007 From: mauriceling at gmail.com (Maurice Ling) Date: Mon, 21 May 2007 17:14:49 +1000 Subject: [pypy-dev] Implementing R (GNU S) in PyPy Message-ID: <465146E9.7000806@acm.org> Hi all, I'm attempting to implement a R (Splus language) interpreter in PyPy so that R statistical modules can be used in Python, as an alternative to R runtime + RPy platform. Currently, I have R language in EBNF, how do I go from here? Thanks in advance, maurice From lac at openend.se Mon May 21 10:39:16 2007 From: lac at openend.se (Laura Creighton) Date: Mon, 21 May 2007 10:39:16 +0200 Subject: [pypy-dev] Implementing R (GNU S) in PyPy In-Reply-To: Message from Maurice Ling of "Mon, 21 May 2007 17:14:49 +1000." <465146E9.7000806@acm.org> References: <465146E9.7000806@acm.org> Message-ID: <200705210839.l4L8dGFT028175@theraft.openend.se> In a message of Mon, 21 May 2007 17:14:49 +1000, Maurice Ling writes: >Hi all, > >I'm attempting to implement a R (Splus language) interpreter in PyPy so >that R statistical modules can be used in Python, as an alternative to R >runtime + RPy platform. Currently, I have R language in EBNF, how do I >go from here? > >Thanks in advance, >maurice >_______________________________________________ >pypy-dev at codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev Talk to people on #pypy on irc.freenode.net and I am busy with other things this day. Laura From mauriceling at gmail.com Mon May 21 12:37:47 2007 From: mauriceling at gmail.com (Maurice Ling) Date: Mon, 21 May 2007 20:37:47 +1000 Subject: [pypy-dev] Implementing R (GNU S) in PyPy In-Reply-To: <200705210839.l4L8dGFT028175@theraft.openend.se> References: <465146E9.7000806@acm.org> <200705210839.l4L8dGFT028175@theraft.openend.se> Message-ID: <4651767B.3090102@acm.org> Laura Creighton wrote: >In a message of Mon, 21 May 2007 17:14:49 +1000, Maurice Ling writes: > > >>Hi all, >> >>I'm attempting to implement a R (Splus language) interpreter in PyPy so >>that R statistical modules can be used in Python, as an alternative to R >>runtime + RPy platform. Currently, I have R language in EBNF, how do I >>go from here? >> >>Thanks in advance, >>maurice >>_______________________________________________ >>pypy-dev at codespeak.net >>http://codespeak.net/mailman/listinfo/pypy-dev >> >> > >Talk to people on #pypy on irc.freenode.net > >and I am busy with other things this day. > >Laura > > > I do wish that I can find someone to talk on #pypy. I'm in Australia and apparently is awake when everyone is off to bed. maurice From tismer at stackless.com Tue May 22 15:36:53 2007 From: tismer at stackless.com (Christian Tismer) Date: Tue, 22 May 2007 15:36:53 +0200 Subject: [pypy-dev] Licensing: [gnu.org #335118] References: Message-ID: <7E3F9EEC-5685-4C03-A472-5E847B020737@stackless.com> Hi colleagues, finally I got this answer from gnu.org which I didn't expect. I'm not sure that I understand what he's saying, I thought it is a problem. What should I reply? cheers - chris Begin forwarded message: > From: "Yoni Rabkin via RT" > Date: 22. Mai 2007 10:55:00 MESZ > To: tismer at stackless.com > Subject: [gnu.org #335118] > Reply-To: licensing at fsf.org > > > Hello, > > Please accept our apologies for the delay in getting back to you. We > rely on volunteer effort and often have difficulties keeping up. > >> My question is if there is any chance to distribute binaries which >> use >> readline, without having to change PyPy's license? > > Here is the situation as I see it: The parts of PyPy have 4 different > licenses: The Pyrex license, the Python license, the Expat license and > the Unicode license. The parts which interact with GNU Readline > seem to > be under GPL compatible licenses. So there should not be any problem > with linking to the GNU Readline library and distributing under the > GNU > GPL. > > Is that a problem? > > -- > I am not a lawyer, the above is not legal advice > > Regards, Yoni Rabkin > > > > From tismer at stackless.com Wed May 23 02:47:49 2007 From: tismer at stackless.com (Christian Tismer) Date: Wed, 23 May 2007 02:47:49 +0200 Subject: [pypy-dev] [gnu.org #335118] In-Reply-To: References: <874pm5fdeh.fsf@actcom.com> Message-ID: On 22.05.2007, at 10:55, Yoni Rabkin via RT wrote: > > Hello, > > Please accept our apologies for the delay in getting back to you. We > rely on volunteer effort and often have difficulties keeping up. > Thank you, keep up the good work. >> My question is if there is any chance to distribute binaries which >> use >> readline, without having to change PyPy's license? > > Here is the situation as I see it: The parts of PyPy have 4 different > licenses: The Pyrex license, the Python license, the Expat license and > the Unicode license. The parts which interact with GNU Readline > seem to > be under GPL compatible licenses. So there should not be any problem > with linking to the GNU Readline library and distributing under the > GNU > GPL. > > Is that a problem? Seems to be ok with us. Thank you very much! cheers - chris From jgustak at gmail.com Thu May 24 01:29:30 2007 From: jgustak at gmail.com (Jakub Gustak) Date: Thu, 24 May 2007 01:29:30 +0200 Subject: [pypy-dev] Mini sprint in Poland Message-ID: I would like to organize mini sprint (2-3 days) in Wroclaw. It would be hold on Wroclaw University of Technology. There are possible two alternative dates: 2-3th June 16(15)-17th June It depends how fast we can organize ourselves. Is there anybody, who would like to participate? Cheers, Jakub Gutsak p.s. I have a feeling, that I spend too much time doing that kind of stuff instead of coding my project. From holger at merlinux.de Mon May 28 12:05:24 2007 From: holger at merlinux.de (holger krekel) Date: Mon, 28 May 2007 12:05:24 +0200 Subject: [pypy-dev] CFP 5th June for CC Camp [camp-orga@events.ccc.de: FINAL Call for Papers: Chaos Communication Camp 2007] Message-ID: <20070528100524.GB25045@solar.trillke> Hello all, below is an invitation and CFP for the Chaos Computer Camp in August 2007 around Berlin. (extended) deadline for proposals is 5th June. Maybe I submit a py.execnet/higher level networking talk ("building a flexible and fast platform for computer viruses" or so) and co-submit a "PyPy" one - question being: do some of us maybe want to meet up there and sprint a bit? Seems one is giving talks in airport hangars, btw, ... best, holger ----- Forwarded message from camp-orga at events.ccc.de ----- Date: Wed, 23 May 2007 22:38:53 +0200 From: camp-orga at events.ccc.de To: hpk at trillke.net Subject: FINAL Call for Papers: Chaos Communication Camp 2007 X-Spambayes-Classification: ham; 0.00 [snip personalized prae-ambel] FINAL Call for Papers: Chaos Communication Camp 2007, Berlin Chaos Communication Camp 2007 "In Fairy Dust We Trust!" August, 8th to 12th, 2007 Airport Museum Finowfurt (Finow Airport) near Berlin, Germany http://events.ccc.de/camp/2007/ Final Call for Paper Deadline: June 5th 2007, 23:59 CET =Overview= The Chaos Communication Camp is an international, five-day open-air event for hackers, builders, and makers organized by the Chaos Computer Club (CCC). The camp provides a relaxed atmosphere for free exchange of technical, social and political ideas. Discuss, sunbathe, and enjoy camping with some of the most interesting people you might ever meet. And all that with internet, power, an abundance of weird self-made gadgets, and people willing to explain them to you, right next to your tent. The Camp area is themed as a starship launch site and split into various thematic villages organized by participating groups from all over the world. Have a look at the incredible new location, right next to an old Russian military airfield (we'll launch drones and UFOs - no kidding!). All this together with vintage MiG fighter planes the Soviet airforce left there when they left East Germany and helicopters, oh my! Two huge main hangars (room for 400 people each) will feature conference tracks with lectures and presentations, while workshops will take place in a central workshop area and in the various villages. To get a first glimpse of what to expect have a look at our self-organizing participants at the Camp Wiki: http://events.ccc.de/camp/2007/Villages. Furthermore there will be a hangar for not-so-lonely hacking nights and days together with hundreds of others, and a hangar featuring art and beauty created with or without a computer. Of course there will also be a lounge with nice electronic music, German beer, great food, and a choice of caffeinated hacker drinks. The conference languages are English and German. Don't worry about language issues though - the Camp is a truly international event! Everyone will be happy to communicate with you in the languages of the Internet - broken English and 1337speak. =Topics= In general, lectures and workshops dealing with technology, ethics, science, security, art, philosophy, politics, culture and cooking are welcome. The main theme of this year's camp is the world we want to live in tomorrow. Any cool tech, research, ideas, and presentations interesting to our audience, are interesting to us. And even beyond the presentations, the camp lives from participation, so bring those gadgets, Go boards, webapps, p2p-simulators, knitted hardware protectors, drones, and lockpicking sets, and expect people to come to you wanting to learn more. =Travel= For this year's Camp there's a special travel opportunity. The Hacker Foundation (http://hackerfoundation.org) has put together a package of nothing less than legendary proportions. For US$1337 (roundtrip from the US and Canada) or ???1337 (roundtrip from Europe) you get admission to both the Camp and the Defcon hacker conference in Las Vegas just a few days before the Camp, a flight from Defcon to Frankfurt (Germany) and from there directly to Finow Airfield on a specially chartered "Hackers on a Plane" flight. This offer includes optional accomodation at the Camp. See for yourself: http://www.hackersonaplane.info/ For general travel Information see http://events.ccc.de/camp/2007/Getting_there =Lecture Requirements= Lectures are expected to be highly relevant in practice or better be darn funny. Sales droids and PR-people have been known to disappear without traces on past events. Interactive workshops are welcome. Hands-on anything are even more welcome. Final presentations for talks should be up to 60 minutes, for workshops up to 60 or 120 minutes long. Additionally, a question-and-answer period will be provided. Follow-up discussions and hands-on workshops are strongly encouraged, there will be space for such activities available outside the main lecture shelters (if you don't prefer a nice sit-in on the grass in the sun). Audio and video recordings of the lectures will be published online in various formats. All material will be available under a Creative Commons licence allowing free non-commercial redistribution of the material as long as the original credit to authors and publishers is retained. =Submissions= All proposals MUST be submitted online using our lecture submission system at https://pentabarf.cccv.de/submission/Camp+2007 . Please follow the instructions given there. You can provide papers and slides for the digital conference pack upon submission. Please make sure your submission contains all information we need to review your talk and send us everything in one go. If you have any questions regarding your submission, feel free to contact us at camp-content at cccv.de but do NOT submit your lecture via e-mail. Accepted speakers are asked to hand in slides used in their talks. Please use a well-known format for your slides. =Dates and deadlines= We've already finished our first CFP. We offer a scheduled second deadline till June, 5th. Submissions received before June 5th, 23:59 CET, will be allocated to remaining slots. Notification of acceptance will be sent by June, 27th, or earlier. Early submissions will be treated with higher priority. ----- End forwarded message ----- -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From fijal at genesilico.pl Tue May 29 18:44:19 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Tue, 29 May 2007 18:44:19 +0200 Subject: [pypy-dev] Unusual problem. Message-ID: <465C5863.50902@genesilico.pl> I want to wrap termios lib, also for RPython. everything works quite smooth except error reporting. termios.tcgetattr (and others as well) use termios.error for error reporting, which is exception which cannot be used in a translated version. Hence my ll_termios_tcgetattr raises OSError instead (it's not mentioned anywhere in documentation of termios library, nor present in any CPython tests, but well...) So than arises a problem - ll version rises OSError, while default one raises termios.error, which makes everything harder to test (ie the same RPython program behaves differently before and after translation). What is casual solution here? Also any magic wrapping doesn't work here, since termios is a builtin module. Cheers, fijal From arigo at tunes.org Wed May 30 21:46:36 2007 From: arigo at tunes.org (Armin Rigo) Date: Wed, 30 May 2007 21:46:36 +0200 Subject: [pypy-dev] Unusual problem. In-Reply-To: <465C5863.50902@genesilico.pl> References: <465C5863.50902@genesilico.pl> Message-ID: <20070530194636.GA21548@code0.codespeak.net> Hi Maciek, On Tue, May 29, 2007 at 06:44:19PM +0200, Maciek Fijalkowski wrote: > termios.tcgetattr (and others as well) use termios.error for error > reporting, which is exception which cannot be used in a translated > version. Why not? Armin