From arigo at tunes.org Wed Sep 5 13:37:02 2007 From: arigo at tunes.org (Armin Rigo) Date: Wed, 5 Sep 2007 13:37:02 +0200 Subject: [pypy-dev] Branch Merged! Message-ID: <20070905113702.GA29505@code0.codespeak.net> Hi all, We've just merged the pypy-more-rtti-inprogress branch. For those of you still working in there - I'm thining about Simon in particular - you need to switch back to the regular trunk. In principle, you can issue the following command in your working copy even if there are local changes, which should stay untouched as long as they don't conflict (but make a backup, just in case!): In a checkout of pypy/dist/pypy, in the 'pypy' directory: svn switch http://codespeak.net/svn/pypy/dist/pypy This branch was a port of all low-level functions of the os module to use the new RFFI interface. The branch also contains progress made on RFFI itself. I've tested and fixed the branch yesterday for Windows XP, so it should compile there as well. A bientot, Armin. From gotcha at bubblenet.be Thu Sep 6 10:43:05 2007 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Thu, 06 Sep 2007 10:43:05 +0200 Subject: [pypy-dev] Help raise Open Source visibility in the government area Message-ID: <46DFBD99.8050506@bubblenet.be> Hi, ( If you have already received this email and have voted, thank you ! ) ( If you have not voted, and wanted to, this is a nice reminder. ) ( If you do not wish to vote, sorry for the noise. ) Please take 10 minutes to help raise open source profile in the government area by voting for the PloneGov project at the european egov awards. See below what PloneGov is and why you could vote to support open source even if you do not use Plone. Anyone from any country can vote, you don't have to live in the EU. And please vote *now*, the deadline is almost upon us **SEPTEMBER 7** ? you are likely to forget if you don't set aside 10 minutes now. This process is unfortunately a bit involved ? since we're dealing with governments ? but shouldn't take longer than 10 minutes to complete. Step-by-step: 1. Go to http://www.epractice.eu/register 2. Wait for the email confirmation and log in. 3. Fill out your profile: http://www.epractice.eu/myprofile/personal http://www.epractice.eu/myprofile/professional http://www.epractice.eu/myprofile/contact (If you don't want to provide professional info, we suggest you add "I just want to vote" in the required fields) 4. Vote for PloneGov by clicking here: http://www.epractice.eu/do/voteinspiring/1026 Thanks! More information below, if you're interested in what PloneGov is. _____________________________________ What is PloneGov? PloneGov aims to create a collaborative software ecosystem where governmental organizations work together, in close relationship with SMEs, to share the cost of software development and enhanced capabilities. This new initiative started by small towns now reaches all levels of public administration and spans over 13 countries on 3 continents. http://www.plonegov.org Your vote for the "Most innovative good practice" award is a unique opportunity to reach politicians and decision makers. Winning this award will highlight the maturity achieved by the Open Source collaborative model as a pragmatic way to tackle IT challenges in society. You may vote until Friday, September 7th. The Public Sector has an important influence on many sectors of society. A wider Open Source acceptance in this field is strategic to all Open Source users and advocates. Users in sectors such as Education, NGOs and businesses would directly benefit from broader adoption. It would result in a growing pool of available software, tools, and developers. Beyond the practical example of PloneGov, your vote contributes to support Open Source values that are based on collaboration, openness and fair trade. It is an opportunity to support Open Source as an innovative model of IT development in which the Public Sector, NGOs and Education can work together and all of society will benefit. -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be From jwal at jwal.me.uk Sun Sep 9 17:38:14 2007 From: jwal at jwal.me.uk (James Ascroft-Leigh) Date: Sun, 9 Sep 2007 16:38:14 +0100 Subject: [pypy-dev] Testing generated JavaScript code Message-ID: <8b3cc5810709090838t45b3b63av48e40041fa407d7e@mail.gmail.com> Hi all, I am interested in the potential for PyPy to run python code within the web browser using, at least as a fallback, the JavaScript interpreter. I have my own project (very immature and not yet usable) to try an achieve just this goal and, like PyPy, my tests exercise the generated JavaScript code using an external interpreter (currently rhino). I am just writing to let you know about this great project I discovered the other day called jpype (http://jpype.sf.net/) that lets you interact with an in-process JVM. Now that the JVM includes the Rhino JS interpreter I am going to switch my tests over to using this to run my generated JS code. This allows a higher level interaction between the languages because you no longer have to serialise the output of the script to stdout and de-serialise it to compare to the expected output. Maybe PyPy could do the same? I might get time to post a patch for this but, as the attached snippet shows, it is not too hard to get started so somebody else might want to do it sooner. What do people think about adding a testing dependency on the JVM and this jpype package? Regards, James -------------- next part -------------- A non-text attachment was scrubbed... Name: rhino.py Type: text/x-python Size: 464 bytes Desc: not available URL: From gholling at vni.com Tue Sep 11 00:27:41 2007 From: gholling at vni.com (Greg Holling) Date: Mon, 10 Sep 2007 16:27:41 -0600 Subject: [pypy-dev] NumPy in PyPy Message-ID: <84625E3AC73C7943A07A8712F940DB91015857DD@peabody.vni.com> Sorry if this has been posted before, but I didn't see anything in the archives. I see that there's been some recent activity in subversion related to numpy in pypy (specifically in pypy/dist/pypy/rpython/numpy). Can anybody on this list give me some more information about this development work (goals, status, etc.)? I have an upcoming project where it might be useful. Thanks! - Greg - -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at arrowtheory.com Tue Sep 11 07:16:16 2007 From: simon at arrowtheory.com (Simon Burton) Date: Mon, 10 Sep 2007 22:16:16 -0700 Subject: [pypy-dev] NumPy in PyPy In-Reply-To: <84625E3AC73C7943A07A8712F940DB91015857DD@peabody.vni.com> References: <84625E3AC73C7943A07A8712F940DB91015857DD@peabody.vni.com> Message-ID: <20070910221616.67dd69db.simon@arrowtheory.com> On Mon, 10 Sep 2007 16:27:41 -0600 "Greg Holling" wrote: > > I see that there's been some recent activity in subversion related to > numpy in pypy (specifically in pypy/dist/pypy/rpython/numpy). Can > anybody on this list give me some more information about this > development work (goals, status, etc.)? I have an upcoming project > where it might be useful. Yes, i've been working on this recently. I really have been aiming to have this functionality at the rpython level; it would take some re-thinking to get this to work in the pypy interpreter. And then, i think it only makes sense to do if we can exploit the JIT somehow. You can see the status from looking at the test code. I will be writing a more comprehensive email to pypy-dev in the next few days. One idea i had was to be able to use this in conjunction with cpython&numpy. But that's a few weeks away from working, and would still involve programming in rpython. Simon. From cfbolz at gmx.de Tue Sep 11 21:12:01 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 11 Sep 2007 21:12:01 +0200 Subject: [pypy-dev] cleanup sprint planning Message-ID: <46E6E881.50803@gmx.de> Hi PyPy-Dev, there has been the vague plan for a cleanup sprint since the end of the EU project. It is becoming more concrete now: There is the vague idea of doing a sprint in October/November (probably November) at Laura's place in Gothenburg. To coordinate the possible times a bit, I have set up a doodle: http://doodle.ch/5awzskkt5mian94a Please enter your available times if you want to attend. Note that this sprint is going to be likely newbie-unfriendly because of its refactoring and cleanup focus. About the work for the sprint: this is a list of possible tasks (they may be too much and some may happen before the sprint), other suggestions are also possible as long as they involve "cleanups". Meta-Task --------- - Tracker-gardening - Start slowly thinking about 1.1 plans Translation toolchain --------------------- - finish rctypes removal - implement correct implicit GIL release - move away from implicit keepalives - raw_malloc should be split, rffi one should not use obmalloc (it's not thread-safe) - kill simulator, run the semi space tests on llinterp (may happen before) - have a moving gc correct version of the gc framework transformation - delegate finding type stuff like vtables etc to GC, cleaner interface for rtti, simplify translator/c/gc.py - think about approaches to id, especially concerning boehm, where the id will keep the object alive and concerning a moving GC - clean up the tangle of including headers in the C backend - review pdbplus, especially the graph commands, also in the light of https://codespeak.net/issue/pypy-dev/issue303 and the fact that we can have more than one translator/annotator around (with the timeshifter) - remember and fix the inlining exception bug Interpreter ----------- - there's a shadow tracking bug it seems - fix taint space - review the things implemented at applevel whether they are performance-critical JIT ------- - start writing real unit tests for the merging logic Please post all comments you might have about the planning or the tasks above. Looking forward to a productive sprint. Carl Friedrich & Samuele From fijall at gmail.com Wed Sep 12 17:16:31 2007 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 12 Sep 2007 23:16:31 +0800 Subject: [pypy-dev] pypy cleanup sprint Message-ID: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> Few points from me: * Kill half concrete wrapper (kill kill kill) * Kill opaque hacks on the C backend * decide how to implement constants in rffi * think about/remove orphaned parts * finish ll2ctypes, especially rffi_platform The last one is not very much cleanup, but is needed to finish transition from rctypes (like rsocket). Also, why not make sprint in Poland? (hint, hint, cheap place). PS. Greetings from china Cheers, fijal -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Thu Sep 13 13:46:20 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 13 Sep 2007 13:46:20 +0200 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> Message-ID: <46E9230C.2060905@gmx.de> Hi Maciek! Maciej Fijalkowski wrote: > Few points from me: > > * Kill half concrete wrapper (kill kill kill) > > * Kill opaque hacks on the C backend What exactly do you mean there? The other points make sense to me. > * decide how to implement constants in rffi > > * think about/remove orphaned parts > > * finish ll2ctypes, especially rffi_platform > > The last one is not very much cleanup, but is needed to finish > transition from rctypes (like rsocket). Also, why not make sprint in > Poland? (hint, hint, cheap place). I would actually prefer to make this rather important sprint at a place where many of us have been and where we had sprints already. Besides, we will be in need for sprint venues after next one, so it would be great if you could organize one in Poland anyway. Cheers, Carl Friedrich From paul.degrandis at gmail.com Thu Sep 13 15:11:52 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Thu, 13 Sep 2007 09:11:52 -0400 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: <46E9230C.2060905@gmx.de> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> Message-ID: <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> If at all possibly, can we also consider a place that has cheaper air fare deals? I'd really like to come to this sprint. Paul On 9/13/07, Carl Friedrich Bolz wrote: > > Hi Maciek! > > Maciej Fijalkowski wrote: > > Few points from me: > > > > * Kill half concrete wrapper (kill kill kill) > > > > * Kill opaque hacks on the C backend > > What exactly do you mean there? The other points make sense to me. > > > * decide how to implement constants in rffi > > > > * think about/remove orphaned parts > > > > * finish ll2ctypes, especially rffi_platform > > > > The last one is not very much cleanup, but is needed to finish > > transition from rctypes (like rsocket). Also, why not make sprint in > > Poland? (hint, hint, cheap place). > > I would actually prefer to make this rather important sprint at a place > where many of us have been and where we had sprints already. Besides, we > will be in need for sprint venues after next one, so it would be great > if you could organize one in Poland anyway. > > Cheers, > > Carl Friedrich > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Thu Sep 13 15:21:18 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 13 Sep 2007 15:21:18 +0200 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> Message-ID: <46E9394E.2060705@gmx.de> Hi Paul, Paul deGrandis wrote: > If at all possibly, can we also consider a place that has cheaper air > fare deals? > I'd really like to come to this sprint. The sprint venue (as discussed on IRC a while ago) is really quite convenient for many, since Samuele, Laura, Jacob, Bea are living there, many of us know the sprint venue and the city, etc. So I don't think changing is a good idea. Maybe you can fly to Stockholm (or even Kopenhagen) and take the train? That takes a few hours but is actually very nice. Cheers, Carl Friedrich From paul.degrandis at gmail.com Thu Sep 13 15:25:06 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Thu, 13 Sep 2007 09:25:06 -0400 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: <46E9394E.2060705@gmx.de> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> <46E9394E.2060705@gmx.de> Message-ID: <9c0bb8a00709130625q370f8a47g17d3a6bcc939e4c8@mail.gmail.com> Sounds like an awesome idea to me. Thanks Carl. Paul On 9/13/07, Carl Friedrich Bolz wrote: > > Hi Paul, > > Paul deGrandis wrote: > > If at all possibly, can we also consider a place that has cheaper air > > fare deals? > > I'd really like to come to this sprint. > > The sprint venue (as discussed on IRC a while ago) is really quite > convenient for many, since Samuele, Laura, Jacob, Bea are living there, > many of us know the sprint venue and the city, etc. So I don't think > changing is a good idea. Maybe you can fly to Stockholm (or even > Kopenhagen) and take the train? That takes a few hours but is actually > very nice. > > Cheers, > > Carl Friedrich > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lac at openend.se Thu Sep 13 15:29:21 2007 From: lac at openend.se (Laura Creighton) Date: Thu, 13 Sep 2007 15:29:21 +0200 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: Message from Carl Friedrich Bolz of "Thu, 13 Sep 2007 15:21:18 +0200." <46E9394E.2060705@gmx.de> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> <46E9394E.2060705@gmx.de> Message-ID: <200709131329.l8DDTLtB008526@theraft.openend.se> In a message of Thu, 13 Sep 2007 15:21:18 +0200, Carl Friedrich Bolz writes: >Hi Paul, > >Paul deGrandis wrote: >> If at all possibly, can we also consider a place that has cheaper air >> fare deals? >> I'd really like to come to this sprint. > >The sprint venue (as discussed on IRC a while ago) is really quite >convenient for many, since Samuele, Laura, Jacob, Bea are living there, >many of us know the sprint venue and the city, etc. So I don't think >changing is a good idea. Maybe you can fly to Stockholm (or even >Kopenhagen) and take the train? That takes a few hours but is actually >very nice. > >Cheers, > >Carl Friedrich Planes may actually be cheaper. Where are you Paul? Laura From cfbolz at gmx.de Thu Sep 13 15:29:23 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 13 Sep 2007 15:29:23 +0200 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: <200709131329.l8DDTLtB008526@theraft.openend.se> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> <46E9394E.2060705@gmx.de> <200709131329.l8DDTLtB008526@theraft.openend.se> Message-ID: <46E93B33.4060305@gmx.de> Laura Creighton wrote: > Planes may actually be cheaper. Where are you Paul? but it is more stressful and you get to see less :-) Cheers, Carl Friedrich From paul.degrandis at gmail.com Thu Sep 13 15:33:34 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Thu, 13 Sep 2007 09:33:34 -0400 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: <46E93B33.4060305@gmx.de> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> <46E9394E.2060705@gmx.de> <200709131329.l8DDTLtB008526@theraft.openend.se> <46E93B33.4060305@gmx.de> Message-ID: <9c0bb8a00709130633i5814253di322e840c3b1ac4c0@mail.gmail.com> Philadelphia, PA int the US. Paul On 9/13/07, Carl Friedrich Bolz wrote: > > Laura Creighton wrote: > > Planes may actually be cheaper. Where are you Paul? > > but it is more stressful and you get to see less :-) > > Cheers, > > Carl Friedrich > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lac at openend.se Thu Sep 13 15:36:08 2007 From: lac at openend.se (Laura Creighton) Date: Thu, 13 Sep 2007 15:36:08 +0200 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: Message from Carl Friedrich Bolz of "Thu, 13 Sep 2007 15:29:23 +0200." <46E93B33.4060305@gmx.de> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> <46E9394E.2060705@gmx.de> <200709131329.l8DDTLtB008526@theraft.openend.se> <46E93B33.4060305@gmx.de> Message-ID: <200709131336.l8DDa8lf010277@theraft.openend.se> In a message of Thu, 13 Sep 2007 15:29:23 +0200, Carl Friedrich Bolz writes: >Laura Creighton wrote: >> Planes may actually be cheaper. Where are you Paul? > >but it is more stressful and you get to see less :-) > >Cheers, > >Carl Friedrich Absolutely. By all means take the train for maximum fun. But given that the request was for cheap airfair, the fact that the plane is usually the cheaper option to get from Stockholm to G?teborg may be relevant. Laura From lac at openend.se Thu Sep 13 16:55:01 2007 From: lac at openend.se (Laura Creighton) Date: Thu, 13 Sep 2007 16:55:01 +0200 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: Message from "Paul deGrandis" of "Thu, 13 Sep 2007 09:33:34 EDT." <9c0bb8a00709130633i5814253di322e840c3b1ac4c0@mail.gmail.com> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> <46E9394E.2060705@gmx.de> <200709131329.l8DDTLtB008526@theraft.openend.se> <46E93B33.4060305@gmx.de> <9c0bb8a00709130633i5814253di322e840c3b1ac4c0@mail.gmail.com> Message-ID: <200709131455.l8DEt1gF024383@theraft.openend.se> In a message of Thu, 13 Sep 2007 09:33:34 EDT, "Paul deGrandis" writes: >------=_Part_27723_30036397.1189690414424 >Content-Type: text/plain; charset=ISO-8859-1 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >Philadelphia, PA int the US. > >Paul > >On 9/13/07, Carl Friedrich Bolz wrote: >> >> Laura Creighton wrote: >> > Planes may actually be cheaper. Where are you Paul? >> >> but it is more stressful and you get to see less :-) >> >> Cheers, >> >> Carl Friedrich Well, taking the Train from Oslo, Copenhagen or Stockholm will definitely be pleasant. You can also take the overnight ferry from Kiel in Germany or Fredrikshavn in Denmark. For you, though, the bulk of the cost will be on the transatlantic flight. Last time I checked, flying KLM to Amsterdam and then Amsterdam to G?teborg was the cheapest, despite the fact that KLM is not a discount airline. http://www.lfv.se/templates/LFV_InfoSida_Bred____1582.aspx lists the airlines that run to Landvetter Airport. Discount airlines include: Malm? Aviation (sometimes), G?teborg City Airline (sometimes) Sterling, Welcome Air, Blue1, Wider?e Then there is G?teborg Ciry airport. They have nothing but discount airlines flying there. http://www.goteborgcityairport.se/info/resenaerer/destinationer.asp Let me know if you need help with anything. Laura From tismer at stackless.com Fri Sep 14 04:31:34 2007 From: tismer at stackless.com (Christian Tismer) Date: Fri, 14 Sep 2007 04:31:34 +0200 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: <200709131455.l8DEt1gF024383@theraft.openend.se> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> <46E9394E.2060705@gmx.de> <200709131329.l8DDTLtB008526@theraft.openend.se> <46E93B33.4060305@gmx.de> <9c0bb8a00709130633i5814253di322e840c3b1ac4c0@mail.gmail.com> <200709131455.l8DEt1gF024383@theraft.openend.se> Message-ID: <46E9F286.7030007@stackless.com> Laura Creighton wrote: ... Well, I'd like to come if I'm wellcomed. Has there been a concrete timing proposal, already? -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From lac at openend.se Fri Sep 14 06:02:25 2007 From: lac at openend.se (Laura Creighton) Date: Fri, 14 Sep 2007 06:02:25 +0200 Subject: [pypy-dev] pypy cleanup sprint In-Reply-To: Message from Christian Tismer of "Fri, 14 Sep 2007 04:31:34 +0200." <46E9F286.7030007@stackless.com> References: <693bc9ab0709120816w6f944e02w660541ac924b7ada@mail.gmail.com> <46E9230C.2060905@gmx.de> <9c0bb8a00709130611h777c9cbl289f0168c948d137@mail.gmail.com> <46E9394E.2060705@gmx.de> <200709131329.l8DDTLtB008526@theraft.openend.se> <46E93B33.4060305@gmx.de> <9c0bb8a00709130633i5814253di322e840c3b1ac4c0@mail.gmail.com> <200709131455.l8DEt1gF024383@theraft.openend.se> <46E9F286.7030007@stackless.com> Message-ID: <200709140402.l8E42PnJ028861@theraft.openend.se> In a message of Fri, 14 Sep 2007 04:31:34 +0200, Christian Tismer writes: >Laura Creighton wrote: > >... > >Well, I'd like to come if I'm wellcomed. >Has there been a concrete timing proposal, already? >-- >Christian Tismer :^) >tismerysoft GmbH : Have a break! Take a ride on Python's >Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ >14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ >work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 >PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 > whom do you want to sponsor today? http://www.stackless.com/ Of course you are most welcome. People are trying to find a time now. see: http://doodle.ch/5awzskkt5mian94a There is now a direct flight from Berlin to Gbg. http://www.goteborgcityairport.se/info/resenaerer/destinationer.asp from (Tegel) -- so not sure exactly where that is, via Air Berlin. Laura From tismer at stackless.com Fri Sep 14 20:07:59 2007 From: tismer at stackless.com (Christian Tismer) Date: Fri, 14 Sep 2007 20:07:59 +0200 Subject: [pypy-dev] Stackless PyPy mini sprint 2007 Message-ID: <46EACDFF.4020301@stackless.com> Hi Stackless PyPy people. We have been sprinting once, quite a long time, ago. Time to start over, again. I'm thinking of doing a mini sprint, before the PyPy cleanup-sprint. It should be a last sprint of clarifying issues which are not resolved, yet, concerning completeness of app-level basic Stackless implementations, and it should lead to an almost final application of the scalability goals stated in PyPy. Maybe these statements need to be adjusted as well. Effectively, I'd like to target this as the final sprint before transforming results into RPython. As a wish, RPython implementations might me tackled as well. But my primary intent is to have a very complete, well-tested code-base for app-level stackless, including composability. I will give a very intense introductory talk about this in the very beginning. Everybody will conceive composability as a simple concept which is not really new, but becomes new by introducing coroutines as the underlying structure for everything. This is non-intrusive, it just needs to be understood. The sprint can be done in my house, with a limit of about five external people, free food and accommodation included. I think a period of three days would be appropriate. Please give me timing proposals and different opinions as you see fit. Sincerely -- chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From ondrej at certik.cz Sat Sep 15 02:58:39 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 15 Sep 2007 02:58:39 +0200 Subject: [pypy-dev] pypy with sympy Message-ID: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> Hi, since pypy is in Debian for some time, I sometimes test it with our project SymPy[1], written in pure Python 2.4 and newer. Generally, it works out of the box and it's very nice and quite fast. You did an awesome job! However, sometimes, it fails, because of the bug[2], that we reported two months ago. Do you think you could please apply the patch provided in there, or just fix it somehow? Also another question - what is your plan with your RPython to javascript converter - are you planning to create something like the Google Web Toolkit, or just leave it as is, if someone becomes interested? I think it would be a very cool feature to have something like this in Python, just a little more documented and officially released. Thanks a lot, Ondrej Certik [1] http://code.google.com/p/sympy/ [2] https://codespeak.net/issue/pypy-dev/issue316 From cfbolz at gmx.de Sat Sep 15 14:48:54 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 15 Sep 2007 14:48:54 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> Message-ID: <46EBD4B6.2050500@gmx.de> Hi Ondrej, Ondrej Certik wrote: > since pypy is in Debian for some time, I sometimes test it with our > project SymPy[1], written in pure Python 2.4 and newer. Generally, it > works out of the box and it's very nice and quite fast. You did an > awesome job! Thanks for doing that! It's nice to hear that it's mostly working. Indeed at one point we could probably consider to use SymPy as some sort of benchmark for PyPy ? it's not easy to find nice pure-Python programs that are computationally bound. > However, sometimes, it fails, because of the bug[2], that we reported > two months ago. Do you think you could please apply the patch provided > in there, or just fix it somehow? Thanks for reporting it. Our problem with it is that we don't quite know how to fix it properly. Potentially, int_w itself should be calling __int__, but we are not sure whether this is good for all use-cases of int_w. > Also another question - what is your plan with your RPython to > javascript converter - are you planning to create something like the > Google Web Toolkit, or just leave it as is, if someone becomes > interested? I think it would be a very cool feature to have something > like this in Python, just a little more documented and officially > released. I think the PyPy team cannot put much more effort into this than what we did already. So we would need somebody interested who would work mostly exclusively on the JavaScript backend to make it live up to its full potential. Cheers, Carl Friedrich From ondrej at certik.cz Sat Sep 15 15:17:34 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 15 Sep 2007 15:17:34 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <46EBD4B6.2050500@gmx.de> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> Message-ID: <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> Hi Carl, > Ondrej Certik wrote: > > since pypy is in Debian for some time, I sometimes test it with our > > project SymPy[1], written in pure Python 2.4 and newer. Generally, it > > works out of the box and it's very nice and quite fast. You did an > > awesome job! > > Thanks for doing that! It's nice to hear that it's mostly working. > Indeed at one point we could probably consider to use SymPy as some sort > of benchmark for PyPy ? it's not easy to find nice pure-Python programs > that are computationally bound. We are actually optimizing sympy to by fast on top of a normal CPython, for example instantiating python classes is very expensive. But I guess it should be very similar in pypy as well. There is another problem actually: $ py.test --exec=pypy * opening PopenGateway: /usr/bin/pypy MASTER: initiated slave terminal session -> MASTER: send start info, topdir=/home/ondra/sympy Traceback (most recent call last): File "?", line 32, in run_toplevel File "?", line 265, in run_it File "", line 1, in File "", line 40, in ImportError: No module named thread Traceback (most recent call last): File "/usr/bin/py.test", line 4, in ? py.test.cmdline.main() File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 15, in main failures = session.main() File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", line 82, in main failures = self.run_remote_session(failures) File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", line 111, in run_remote_session return channel.receive() File "/usr/lib/python2.4/site-packages/py/execnet/channel.py", line 175, in receive raise self._getremoteerror() or EOFError() EOFError There is not module thread in there. So I cannot test the whole sympy using pypy, because we have all our tests made using py.test. Feel free to put this into the issues. > Thanks for reporting it. Our problem with it is that we don't quite know > how to fix it properly. Potentially, int_w itself should be calling > __int__, but we are not sure whether this is good for all use-cases of > int_w. Right, but do you agree, that this should be working in python 2.4? So there must be some way to do it. > I think the PyPy team cannot put much more effort into this than what we > did already. So we would need somebody interested who would work mostly > exclusively on the JavaScript backend to make it live up to its full > potential. So what is your priority now with pypy? I think it has such an enormous potential, but currently for me it's just a playground. Do you plan to apply pypy in some area, where people will use it as the best technology available in there? Or do you plan more to have pypy just as a means of testing new JIT ideas? Ondrej From ondrej at certik.cz Sat Sep 15 15:23:47 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 15 Sep 2007 15:23:47 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> Message-ID: <85b5c3130709150623p5de74662j107cccc39c65db8c@mail.gmail.com> > There is another problem actually: > > $ py.test --exec=pypy > * opening PopenGateway: /usr/bin/pypy > MASTER: initiated slave terminal session -> > MASTER: send start info, topdir=/home/ondra/sympy > Traceback (most recent call last): > File "?", line 32, in run_toplevel > File "?", line 265, in run_it > File "", line 1, in > File "", line 40, in > ImportError: No module named thread > Traceback (most recent call last): > File "/usr/bin/py.test", line 4, in ? > py.test.cmdline.main() > File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 15, in main > failures = session.main() > File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", > line 82, in main > failures = self.run_remote_session(failures) > File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", > line 111, in run_remote_session > return channel.receive() > File "/usr/lib/python2.4/site-packages/py/execnet/channel.py", line > 175, in receive > raise self._getremoteerror() or EOFError() > EOFError I forgot to add - I am using the versions from Debian unstable. I don't have time to test everything from svn, however, if you want, I can make new versions of pypy/py.test available in Debian when you release them, but I think the current maintainer will do also do it - Alexandre Fayolle is the maintainer of those packages - should I report bugs in them to Debian BTS, or here? I think the way to go is just users report problems against the packages in their distributions, like Debian, it is forwarded here, you fix it in svn, release a new version, it gets to Debian, etc. Ondrej From lac at openend.se Sat Sep 15 16:05:41 2007 From: lac at openend.se (Laura Creighton) Date: Sat, 15 Sep 2007 16:05:41 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: Message from "Ondrej Certik" of "Sat, 15 Sep 2007 15:17:34 +0200." <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> Message-ID: <200709151405.l8FE5fk8029135@theraft.openend.se> In a message of Sat, 15 Sep 2007 15:17:34 +0200, "Ondrej Certik" writes: >So what is your priority now with pypy? I think it has such an >enormous potential, but currently for me it's just a playground. Do >you plan to apply pypy in some area, where people will use it as the >best technology available in there? Or do you plan more to have pypy >just as a means of testing new JIT ideas? > >Ondrej We really want to push this as a real language that people should use to solve real problems they have. Currently, however, things are in a bad need of a cleanup. While it was terrific to have the EU funding which let many of us work on pypy full time, the deadlines for deliverables were such that many things were hacked together in ways that are ok for a prototype but not really robust enough for production use. We are planning our next sprint to work on the roughest of these. Then, of course, the problem is that there are so many things that could be the 'next step' for PyPy. Some of us (me for instance) are actively looking for paying customers who have a business case for wanting PyPy to do X. Tim Parkin, who designed the current python.org site is also interested in working on finding out what should be the next step for PyPy. He is collecting opinions, and people who are willing to put money where their mouth is here: http://wiki.python.org/moin/PyPyDonations It would be nice to get PyPy to such a state that it again had many tasks for those people who don't feel up to hacking the Just in Time Specialiser. A better garbage collector is necessary, but I think that people find that intimidating as well. We're much further along with the new scheme for working with C extensions, and that too is necessary. It would be nice to find out exactly who wants what next from PyPy, and perhaps more importantly, who would be willing to help on PyPy, but cannot now, and what they would need in the way of changes before they could contribute. Besides fixes for the bugs you have reported, is there anything in particular you wish we were doing next? Laura From ondrej at certik.cz Sat Sep 15 17:13:02 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 15 Sep 2007 17:13:02 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <200709151405.l8FE5fk8029135@theraft.openend.se> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <200709151405.l8FE5fk8029135@theraft.openend.se> Message-ID: <85b5c3130709150813s20ba3e4exd5a516953400cf4a@mail.gmail.com> > Then, of course, the problem is that there are so many things that > could be the 'next step' for PyPy. Some of us (me for instance) are > actively looking for paying customers who have a business case for > wanting PyPy to do X. Tim Parkin, who designed the current python.org > site is also interested in working on finding out what should be the > next step for PyPy. He is collecting opinions, and people who are > willing to put money where their mouth is here: > http://wiki.python.org/moin/PyPyDonations I'd suggest to put that link on the front page of pypy. And also to put that question where to go now on the front page. Compared to your donations, I hope you won't take mine as an offence, but I am a student. > It would be nice to get PyPy to such a state that it again had many > tasks for those people who don't feel up to hacking the Just in Time > Specialiser. A better garbage collector is necessary, but I think that > people find that intimidating as well. We're much further along with the > new scheme for working with C extensions, and that too is necessary. > > It would be nice to find out exactly who wants what next from PyPy, > and perhaps more importantly, who would be willing to help on PyPy, > but cannot now, and what they would need in the way of changes before > they could contribute. Besides fixes for the bugs you have reported, > is there anything in particular you wish we were doing next? I have many ideas: 1) Make predictable releases, get pypy into distributions, fix bugs and just make it another Python interpreter. 2) Provide a standard interpreter to: java, .NET and other platforms. In Jython, they need to code it in Java, by hand I guess. In PyPy, if I understand it correctly, you just update the interpeter in rpython and you get all those interpreters and all platforms for free. I guess this is one of the goals of pypy. So that for example SymPy can be run on all those platforms. 3) Allow efficient writing of modules in C/Fortran. There is SWIG, ctypes, f2py, then there are many projects like pyrex, Cython, etc. It's a mess. I think pypy has also something to say in this area and maybe make things more systematic, robust and multiplatform. 4) Myabe allow to speed my code up (JIT), or make Python as fast as possible. But this is rather a long term goal. Generally, I don't see why my code written in C and the same code written in Python, not using much dynamic features, couldn't be the same fast. (Of course I understand why now it is slower, Python is interpreted, etc. But I mean in principle. Python can have as much information about my code as the C compiler.) I use Python for devising new numerical algorithms, and than I need to rewrite them by hand to fortran for speed. It's a pain. 5) Google Web Toolkit, but in Python using PyPy. It's a lot of work, nevertheless it's already possible and that would be a boom to pypy and python in general, I am pretty sure about that. 6) Allow efficient threading? CPython has the GIL (for good technological reasons). Generally pypy can improve how to do things in parallel in python. Currently, one needs to use pympi, pypar, or something. 7) Using RPython as a compiled languge. Generally, many of my algorithms are just RPython. If they could be tranlated to C and all the other backends, the same efficient as I would do by hand, that'd be just awesome. This is connected to 4). 8) This is very long term thing - the whole pypy machinery should in principle allow to run Python on basically everything. So knowing Python could be enough to contribute to a project written in almost any language. Anyway, I think pypy either can already do the things above, or has a very big potential to do so, like a proof of concept. Ondrej From cfbolz at gmx.de Sun Sep 16 01:30:42 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 16 Sep 2007 01:30:42 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <85b5c3130709150813s20ba3e4exd5a516953400cf4a@mail.gmail.com> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <200709151405.l8FE5fk8029135@theraft.openend.se> <85b5c3130709150813s20ba3e4exd5a516953400cf4a@mail.gmail.com> Message-ID: <46EC6B22.1060600@gmx.de> Hi Ondrej, > I have many ideas: > > 1) Make predictable releases, get pypy into distributions, fix bugs > and just make it another Python interpreter. That one is a bit boring, don't you think? :-) No seriously, we can't really compete with CPython on its home turf, we need additional features that set us apart. > 2) Provide a standard interpreter to: java, .NET and other platforms. > In Jython, they need to code it in Java, by hand I guess. In PyPy, if > I understand it correctly, you just update the interpeter in rpython > and you get all those interpreters and all platforms for free. I guess > this is one of the goals of pypy. So that for example SymPy can be run > on all those platforms. Yes, that's correct. We are working on this, actually. Especially Java is interesting, I guess, since Jython is still behind CPython. Competing with IronPython won't be so easy. > 3) Allow efficient writing of modules in C/Fortran. There is SWIG, > ctypes, f2py, then there are many projects like pyrex, Cython, etc. > It's a mess. I think pypy has also something to say in this area and > maybe make things more systematic, robust and multiplatform. > > 4) Myabe allow to speed my code up (JIT), or make Python as fast as > possible. But this is rather a long term goal. Generally, I don't see > why my code written in C and the same code written in Python, not > using much dynamic features, couldn't be the same fast. (Of course I > understand why now it is slower, Python is interpreted, etc. But I > mean in principle. Python can have as much information about my code > as the C compiler.) I use Python for devising new numerical > algorithms, and than I need to rewrite them by hand to fortran for > speed. It's a pain. This, too, is definitely part of PyPy's agenda. We plan to work on this not even too far into the future, I would think. > 5) Google Web Toolkit, but in Python using PyPy. It's a lot of work, > nevertheless it's already possible and that would be a boom to pypy > and python in general, I am pretty sure about that. In my opinion this is way outside what the current team of people actively working on PyPy can manage. We would need outside people that are ready to work on this. > 6) Allow efficient threading? CPython has the GIL (for good > technological reasons). Generally pypy can improve how to do things in > parallel in python. Currently, one needs to use pympi, pypar, or > something. Right now we have a GIL as well, since it was easiest to implement. It's too early to think about removing the GIL, since we would need a better thread-aware garbage collector first ? Boehm is just not up to the task. > 7) Using RPython as a compiled languge. Generally, many of my > algorithms are just RPython. If they could be tranlated to C and all > the other backends, the same efficient as I would do by hand, that'd > be just awesome. Not sure whether it is as efficient as by hand, but such a translation is obviously possible. > This is connected to 4). I disagree with this. The JIT techniques that PyPy uses are very different from its RPython translators. > 8) This is very long term thing - the whole pypy machinery should in > principle allow to run Python on basically everything. So knowing > Python could be enough to contribute to a project written in almost > any language. I guess so, yes. Although right now our Python interpreter is not exactly lightweight, so running on very small machines is not going to be reasonable without quite some additional work. Cheers, Carl Friedrich From tismer at stackless.com Sun Sep 16 01:58:36 2007 From: tismer at stackless.com (Christian Tismer) Date: Sun, 16 Sep 2007 01:58:36 +0200 Subject: [pypy-dev] 46638 made Stackless to crash. Message-ID: <46EC71AC.5070404@stackless.com> Hi Armin, today you pointed me to stackless failures. They were caused by your revision 46638. both MacGyver:~/pypy-dist/pypy/lib/app_test tismer$ ../../../py/bin/py.test -A test_stackless.py -v -s and MacGyver:~/pypy-dist/pypy/lib/app_test tismer$ ~/pypy-builds/pypy-c ../../../py/bin/py.test -A test_stackless.py -v -s worked until your check-in. It is a bit annoying to get blamed on pypy-dev by you, after *you* obviously did not run these tests. Anyway, I would really like to understand what you did, since this bug does not make much sense to me. ciao -- chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Sun Sep 16 02:48:05 2007 From: tismer at stackless.com (Christian Tismer) Date: Sun, 16 Sep 2007 02:48:05 +0200 Subject: [pypy-dev] tephan. In-Reply-To: <20070915133824.B7E2B80A6@code0.codespeak.net> References: <20070915133824.B7E2B80A6@code0.codespeak.net> Message-ID: <46EC7D45.1030200@stackless.com> Hi friends, Something in this check-in has a huge impact on all of the stackless tests in pypy/lib/app-tests. I think that this was unforeseen by Armin, although it was not appropriate to blame me for this without any reflection. I felt exposed to something which I was unable to react on. Especially since I did not write these modules but Stephan. Thanks to cfbolz who reminded me how to track such things down. I would like to know if the resulting errors come from a mis-use on our side, or if we did all-right so far. cheers -- chris arigo at codespeak.net wrote: > Author: arigo > Date: Sat Sep 15 15:38:24 2007 > New Revision: 46638 > > Modified: > pypy/dist/pypy/tool/cache.py > Log: > Protect cache building in a multithreaded py.py. > > > Modified: pypy/dist/pypy/tool/cache.py > ============================================================================== > --- pypy/dist/pypy/tool/cache.py (original) > +++ pypy/dist/pypy/tool/cache.py Sat Sep 15 15:38:24 2007 > @@ -25,6 +25,9 @@ > # Be sure to call the parent __init__() if you override it. > # > > +from threading import RLock > +lock = RLock() # multithreading protection > + > > class Cache(object): > def __init__(self): > @@ -32,20 +35,24 @@ > self._building = {} > > def getorbuild(self, key): > + lock.acquire() > try: > - return self.content[key] > - except KeyError: > - if key in self._building: > - raise Exception, "%s recursive building of %r" % ( > - self, key) > - self._building[key] = True > try: > - result = self._build(key) > - self.content[key] = result > - finally: > - del self._building[key] > - self._ready(result) > - return result > + return self.content[key] > + except KeyError: > + if key in self._building: > + raise Exception, "%s recursive building of %r" % ( > + self, key) > + self._building[key] = True > + try: > + result = self._build(key) > + self.content[key] = result > + finally: > + del self._building[key] > + self._ready(result) > + return result > + finally: > + lock.release() > getorbuild._annspecialcase_ = "specialize:memo" > > def _ready(self, result): > _______________________________________________ > pypy-svn mailing list > pypy-svn at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From arigo at tunes.org Sun Sep 16 11:16:42 2007 From: arigo at tunes.org (Armin Rigo) Date: Sun, 16 Sep 2007 11:16:42 +0200 Subject: [pypy-dev] 46638 made Stackless to crash. In-Reply-To: <46EC71AC.5070404@stackless.com> References: <46EC71AC.5070404@stackless.com> Message-ID: <20070916091642.GA22349@code0.codespeak.net> Hi Christian, On Sun, Sep 16, 2007 at 01:58:36AM +0200, Christian Tismer wrote: > today you pointed me to stackless failures. > > They were caused by your revision 46638. I wouldn't be surprized if that was my fault - I recently caused JIT tests to break in a completely unexpected manner by changing apparently unrelated code. However it seems that you are mistaken in this case: the failures I'm referring to (e.g. [1]) have been on the wyvern report page since a few days longer than 46638. On my laptop I found that they are there since revision 46507 - this is the revision that fixes the IndentationError in stackless.py. Maybe a caching problem? Try removing the pypy/_cache directory (and all .pyc files as usual...). [1] http://wyvern.cs.uni-duesseldorf.de/pypytest/46667/failed/lib.app_test.test_stackless.py.Test_Stacklesstest_balance_recv.html Armin From tismer at stackless.com Sun Sep 16 16:37:50 2007 From: tismer at stackless.com (Christian Tismer) Date: Sun, 16 Sep 2007 16:37:50 +0200 Subject: [pypy-dev] 46638 made Stackless to crash. In-Reply-To: <20070916091642.GA22349@code0.codespeak.net> References: <46EC71AC.5070404@stackless.com> <20070916091642.GA22349@code0.codespeak.net> Message-ID: <46ED3FBE.8070807@stackless.com> Hello Armin, > On Sun, Sep 16, 2007 at 01:58:36AM +0200, Christian Tismer wrote: >> today you pointed me to stackless failures. >> >> They were caused by your revision 46638. > > I wouldn't be surprized if that was my fault - I recently caused JIT > tests to break in a completely unexpected manner by changing apparently > unrelated code. However it seems that you are mistaken in this case: > the failures I'm referring to (e.g. [1]) have been on the wyvern report > page since a few days longer than 46638. On my laptop I found that they > are there since revision 46507 - this is the revision that fixes the > IndentationError in stackless.py. > > Maybe a caching problem? Try removing the pypy/_cache directory (and > all .pyc files as usual...). > > [1] http://wyvern.cs.uni-duesseldorf.de/pypytest/46667/failed/lib.app_test.test_stackless.py.Test_Stacklesstest_balance_recv.html I'm not convinced. What I did yesterday was a completely new check-out, and I could binary search to 46638 in a repeatable way. I will try again now with cache clearing - no, ATM I even don't have a _cache. Ok, the result is the same. Exactly this change to pypy/tool/cache.py causes the errors. After the change, the threading module can no longer import thread, as like the stackless module no longer can import greenlet. cheers - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From erik at medallia.com Sun Sep 16 19:23:58 2007 From: erik at medallia.com (Erik Gorset) Date: Sun, 16 Sep 2007 19:23:58 +0200 Subject: [pypy-dev] Stackless PyPy mini sprint 2007 In-Reply-To: <46EACDFF.4020301@stackless.com> References: <46EACDFF.4020301@stackless.com> Message-ID: Hi, On Sep 14, 2007, at 8:07 PM, Christian Tismer wrote: > As a wish, RPython implementations might me tackled as well. > But my primary intent is to have a very complete, well-tested > code-base for app-level stackless, including composability. > I will give a very intense introductory talk about this in the > very beginning. Everybody will conceive composability as a simple > concept which is not really new, but becomes new by introducing > coroutines as the underlying structure for everything. > This is non-intrusive, it just needs to be understood. I'm wondering if there is any plans for pypy/stackless to support true continuations as first class citizen in the future? It would be easy to implement coroutines and exceptions in normal python code if call/cc was supported. After all, ruby, scheme and smalltalk can support this :-) -- Erik Gorset -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1962 bytes Desc: not available URL: From tismer at stackless.com Sun Sep 16 19:57:27 2007 From: tismer at stackless.com (Christian Tismer) Date: Sun, 16 Sep 2007 19:57:27 +0200 Subject: [pypy-dev] clarification of "46638 made Stackless to crash." In-Reply-To: <46ED3FBE.8070807@stackless.com> References: <46EC71AC.5070404@stackless.com> <20070916091642.GA22349@code0.codespeak.net> <46ED3FBE.8070807@stackless.com> Message-ID: <46ED6E87.9050007@stackless.com> Christian Tismer wrote: ... > I'm not convinced. What I did yesterday was a completely new > check-out, and I could binary search to 46638 in a repeatable way. > > I will try again now with cache clearing - no, ATM I even don't > have a _cache. > > Ok, the result is the same. > Exactly this change to pypy/tool/cache.py causes the errors. > After the change, the threading module can no longer import thread, > as like the stackless module no longer can import greenlet. This was actually a bad combination of errors and misunderstandings. The import problem was really caused by rev. 46638. The rest of the mess was my fault: My check-in from short before PyCon UK had a small glitch, and although it fixed pickling (modulo a bus error which is still sought), it made the tests in app_test/test_stackless fail completely. I was blind to this error, because things worked in compiled pypy-c and with my local cpython. I was not aware that I had changed the default interpreter during the conference to real stackless. This way, the buggy code that I checked in before was never executed, so I did not expect anything to be wrong. I felt innocent but I was guilty. Armin, please take by apologies. mixing too many stacklesses is probably a bad idea. sincerely -- chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Sun Sep 16 20:13:20 2007 From: tismer at stackless.com (Christian Tismer) Date: Sun, 16 Sep 2007 20:13:20 +0200 Subject: [pypy-dev] Stackless PyPy mini sprint 2007 In-Reply-To: References: <46EACDFF.4020301@stackless.com> Message-ID: <46ED7240.3060903@stackless.com> Hi Erik, Erik Gorset wrote: > Hi, > > On Sep 14, 2007, at 8:07 PM, Christian Tismer wrote: >> As a wish, RPython implementations might me tackled as well. >> But my primary intent is to have a very complete, well-tested >> code-base for app-level stackless, including composability. >> I will give a very intense introductory talk about this in the >> very beginning. Everybody will conceive composability as a simple >> concept which is not really new, but becomes new by introducing >> coroutines as the underlying structure for everything. >> This is non-intrusive, it just needs to be understood. > > I'm wondering if there is any plans for pypy/stackless to support > true continuations as first class citizen in the future? It would be easy > to implement coroutines and exceptions in normal python code if > call/cc was supported. After all, ruby, scheme and smalltalk can > support this :-) Maybe this is possible, but that's not a reason to do it. I have spent a little too much of my lifetime with taming continuations. And since Python has all the control flow it needs, it does not make sense to add continuations, which impose extra complications for no gain. I think to stick with coroutines as the building block, unless there is a real need for continuations. cheers - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From rhamph at gmail.com Sun Sep 16 22:03:03 2007 From: rhamph at gmail.com (Adam Olsen) Date: Sun, 16 Sep 2007 14:03:03 -0600 Subject: [pypy-dev] pypy with sympy Message-ID: > 4) Myabe allow to speed my code up (JIT), or make Python as fast as > possible. But this is rather a long term goal. Generally, I don't see > why my code written in C and the same code written in Python, not > using much dynamic features, couldn't be the same fast. (Of course I > understand why now it is slower, Python is interpreted, etc. But I > mean in principle. Python can have as much information about my code > as the C compiler.) I use Python for devising new numerical > algorithms, and than I need to rewrite them by hand to fortran for > speed. It's a pain. > 6) Allow efficient threading? CPython has the GIL (for good > technological reasons). Generally pypy can improve how to do things in > parallel in python. Currently, one needs to use pympi, pypar, or > something. These two together are, in my mind, where PyPy can really shine. Performance on par with CPython is critical to be taken seriously, but CPython's difficulties with the GIL mean I can only make it scalable at about 60% to 65% of the traditional efficiency (on pystones at least). That gap gives PyPy enough room to surpass CPython on scalable performance. -- Adam Olsen, aka Rhamphoryncus From erik at medallia.com Mon Sep 17 03:00:51 2007 From: erik at medallia.com (Erik Gorset) Date: Mon, 17 Sep 2007 03:00:51 +0200 Subject: [pypy-dev] Stackless PyPy mini sprint 2007 In-Reply-To: <46ED7240.3060903@stackless.com> References: <46EACDFF.4020301@stackless.com> <46ED7240.3060903@stackless.com> Message-ID: <7577F030-2075-4009-B05F-FCB2B12CF519@medallia.com> On Sep 16, 2007, at 8:13 PM, Christian Tismer wrote: > Erik Gorset wrote: >> I'm wondering if there is any plans for pypy/stackless to support >> true continuations as first class citizen in the future? It would >> be easy >> to implement coroutines and exceptions in normal python code if >> call/cc was supported. After all, ruby, scheme and smalltalk can >> support this :-) > > Maybe this is possible, but that's not a reason to do it. > I have spent a little too much of my lifetime with taming > continuations. And since Python has all the control flow > it needs, it does not make sense to add continuations, which > impose extra complications for no gain. > > I think to stick with coroutines as the building block, > unless there is a real need for continuations. Actually, having continuations as a fundamental building block is a big simplification as all other control flows can be expressed by it. The only "flaw" is that you can't use the c stack in a normal way since the executing contexts will form a tree instead of a linear structure. Of course, we can argue that this isn't pythonic anymore, so I believe I see your point. I'm already using greenlet extension for cpython heavily in my code, which is just GREAT :-) So I can live happily in python without continuations as long as I have coroutines. Btw, it's possible to simulate some of call/cc's behavior using _stackless.fork() (I have a play-implementation lying around here somewhere). But it has several issues. The biggest one is that fork() actually copies some of the objects found on the stack. It's been a while since I've played around with cloneable and fork, so maybe this has been fixed. -- Erik Gorset -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1962 bytes Desc: not available URL: From tismer at stackless.com Mon Sep 17 03:42:10 2007 From: tismer at stackless.com (Christian Tismer) Date: Mon, 17 Sep 2007 03:42:10 +0200 Subject: [pypy-dev] Stackless PyPy mini sprint 2007 In-Reply-To: <7577F030-2075-4009-B05F-FCB2B12CF519@medallia.com> References: <46EACDFF.4020301@stackless.com> <46ED7240.3060903@stackless.com> <7577F030-2075-4009-B05F-FCB2B12CF519@medallia.com> Message-ID: <46EDDB72.8050603@stackless.com> Erik Gorset wrote: > On Sep 16, 2007, at 8:13 PM, Christian Tismer wrote: >> Erik Gorset wrote: >>> I'm wondering if there is any plans for pypy/stackless to support >>> true continuations as first class citizen in the future? It would be >>> easy >>> to implement coroutines and exceptions in normal python code if >>> call/cc was supported. After all, ruby, scheme and smalltalk can >>> support this :-) >> >> Maybe this is possible, but that's not a reason to do it. >> I have spent a little too much of my lifetime with taming >> continuations. And since Python has all the control flow >> it needs, it does not make sense to add continuations, which >> impose extra complications for no gain. >> >> I think to stick with coroutines as the building block, >> unless there is a real need for continuations. > > Actually, having continuations as a fundamental building block is a > big simplification as all other control flows can be expressed by it. It is a complication, since continuation support is not trivial. The demands are much harder than for coroutines. > The only "flaw" is that you can't use the c stack in a normal way > since the executing contexts will form a tree instead of a linear > structure. Please don't continue this discussion on this list. This is a stackless issue in the first place, not PyPy's. I was just inviting people here to a sprint. Stackless matters go to the stackless list. See http://www.stackless.com/mailman/listinfo/stackless Also the issue of continuations has been discussed at length there. Please use this list for question about PyPy. cheers - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From cfbolz at gmx.de Mon Sep 17 10:34:11 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 17 Sep 2007 10:34:11 +0200 Subject: [pypy-dev] Stackless PyPy mini sprint 2007 In-Reply-To: <46EDDB72.8050603@stackless.com> References: <46EACDFF.4020301@stackless.com> <46ED7240.3060903@stackless.com> <7577F030-2075-4009-B05F-FCB2B12CF519@medallia.com> <46EDDB72.8050603@stackless.com> Message-ID: <46EE3C03.7000507@gmx.de> Christian Tismer wrote: [snip discussions about continuations] > Please don't continue this discussion on this list. > This is a stackless issue in the first place, not PyPy's. > I was just inviting people here to a sprint. > Stackless matters go to the stackless list. > > See http://www.stackless.com/mailman/listinfo/stackless > > Also the issue of continuations has been discussed at length there. > Please use this list for question about PyPy. While I agree with Christian's opinions that true continuations are probably a can of worms that you don't want to open, I don't see this discussion to be wrongly placed on this list. PyPy-dev is quite low-traffic and many of the things discussed here are "off-topic". Cheers, Carl Friedrich From arigo at tunes.org Mon Sep 17 12:31:23 2007 From: arigo at tunes.org (Armin Rigo) Date: Mon, 17 Sep 2007 12:31:23 +0200 Subject: [pypy-dev] Stackless PyPy mini sprint 2007 In-Reply-To: <7577F030-2075-4009-B05F-FCB2B12CF519@medallia.com> References: <46EACDFF.4020301@stackless.com> <46ED7240.3060903@stackless.com> <7577F030-2075-4009-B05F-FCB2B12CF519@medallia.com> Message-ID: <20070917103122.GA30798@code0.codespeak.net> Hi Erik, On Mon, Sep 17, 2007 at 03:00:51AM +0200, Erik Gorset wrote: > Btw, it's possible to simulate some of call/cc's behavior using > _stackless.fork() (I have a play-implementation lying around here > somewhere). But it has several issues. The biggest one is that fork() > actually copies some of the objects found on the stack. It's been > a while since I've played around with cloneable and fork, so maybe > this has been fixed. A deep issue with continuations in a language like Python is that there is no single best definition of what it should capture and what it should not. If you think about what you would like to occur when you capture a continuation or fork a coroutine, then you'll notice that you actually want some objects on the stack to be duplicated, and others not. For example, in: def f(n): return [x*x for x in range(n)] which, remember, is equivalent to: def f(n): lst = [] for x in range(n): lst.append(x*x) return lst if we pause this function in the middle of the loop and fork it, then it feels "right" to duplicate the list -- otherwise both the original and the copy will append the remaining items into the same list, resulting in a single list with more than n elements. In essence, it seems to me that both forking and full continuations should not be part of the core of a language, for the same reasons as pickling -- in my own experience at least, more than half of the time "pickle" doesn't capture enough or capture too much. There is no single best solution. A bientot, Armin. From arigo at tunes.org Mon Sep 17 12:33:10 2007 From: arigo at tunes.org (Armin Rigo) Date: Mon, 17 Sep 2007 12:33:10 +0200 Subject: [pypy-dev] tephan. In-Reply-To: <46EC7D45.1030200@stackless.com> References: <20070915133824.B7E2B80A6@code0.codespeak.net> <46EC7D45.1030200@stackless.com> Message-ID: <20070917103310.GB30798@code0.codespeak.net> Hi, On Sun, Sep 16, 2007 at 02:48:05AM +0200, Christian Tismer wrote: > Something in this check-in has a huge impact on all of the > stackless tests in pypy/lib/app-tests. Fixed in r46676. Armin From tismer at stackless.com Mon Sep 17 15:25:30 2007 From: tismer at stackless.com (Christian Tismer) Date: Mon, 17 Sep 2007 15:25:30 +0200 Subject: [pypy-dev] continuations (was: Stackless PyPy mini sprint 2007) In-Reply-To: <46EE3C03.7000507@gmx.de> References: <46EACDFF.4020301@stackless.com> <46ED7240.3060903@stackless.com> <7577F030-2075-4009-B05F-FCB2B12CF519@medallia.com> <46EDDB72.8050603@stackless.com> <46EE3C03.7000507@gmx.de> Message-ID: <46EE804A.9010307@stackless.com> Carl Friedrich Bolz wrote: > Christian Tismer wrote: > [snip discussions about continuations] >> Please don't continue this discussion on this list. >> This is a stackless issue in the first place, not PyPy's. >> I was just inviting people here to a sprint. >> Stackless matters go to the stackless list. >> >> See http://www.stackless.com/mailman/listinfo/stackless >> >> Also the issue of continuations has been discussed at length there. >> Please use this list for question about PyPy. > > While I agree with Christian's opinions that true continuations are > probably a can of worms that you don't want to open, I don't see this > discussion to be wrongly placed on this list. PyPy-dev is quite > low-traffic and many of the things discussed here are "off-topic". Ok, no problem, PyPy is the platform with the most chances to do this right, so why not discuss it here. I'd just prefer to change the topic then, since this is about a stackless sprint to finish and clean up things which are waiting. These things are going to be folded back into CPython stackless, where the re-incarnation of continuations is pretty unlikely. cheers - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From cfbolz at gmx.de Mon Sep 17 16:02:18 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 17 Sep 2007 16:02:18 +0200 Subject: [pypy-dev] continuations In-Reply-To: <46EE804A.9010307@stackless.com> References: <46EACDFF.4020301@stackless.com> <46ED7240.3060903@stackless.com> <7577F030-2075-4009-B05F-FCB2B12CF519@medallia.com> <46EDDB72.8050603@stackless.com> <46EE3C03.7000507@gmx.de> <46EE804A.9010307@stackless.com> Message-ID: <46EE88EA.9020108@gmx.de> Christian Tismer wrote: > Ok, no problem, PyPy is the platform with the most chances > to do this right, so why not discuss it here. > > I'd just prefer to change the topic then, since this is about a > stackless sprint to finish and clean up things which are waiting. > These things are going to be folded back into CPython stackless, > where the re-incarnation of continuations is pretty unlikely. Oh, absolutely. A change of topic (or even a new thread) would have been good. Cheers, Carl Friedrich From cfbolz at gmx.de Mon Sep 17 16:19:38 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 17 Sep 2007 16:19:38 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <85b5c3130709150623p5de74662j107cccc39c65db8c@mail.gmail.com> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <85b5c3130709150623p5de74662j107cccc39c65db8c@mail.gmail.com> Message-ID: <46EE8CFA.2080209@gmx.de> Ondrej Certik wrote: >> There is another problem actually: >> >> $ py.test --exec=pypy >> * opening PopenGateway: /usr/bin/pypy >> MASTER: initiated slave terminal session -> >> MASTER: send start info, topdir=/home/ondra/sympy >> Traceback (most recent call last): >> File "?", line 32, in run_toplevel >> File "?", line 265, in run_it >> File "", line 1, in >> File "", line 40, in >> ImportError: No module named thread >> Traceback (most recent call last): >> File "/usr/bin/py.test", line 4, in ? >> py.test.cmdline.main() >> File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 15, in main >> failures = session.main() >> File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", >> line 82, in main >> failures = self.run_remote_session(failures) >> File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", >> line 111, in run_remote_session >> return channel.receive() >> File "/usr/lib/python2.4/site-packages/py/execnet/channel.py", line >> 175, in receive >> raise self._getremoteerror() or EOFError() >> EOFError > > I forgot to add - I am using the versions from Debian unstable. I > don't have time to test everything from svn, however, if you want, I > can make new versions of pypy/py.test available in Debian when you > release them, but I think the current maintainer will do also do it - > Alexandre Fayolle is the maintainer of those packages - should I > report bugs in them to Debian BTS, or here? > > I think the way to go is just users report problems against the > packages in their distributions, like Debian, it is forwarded here, > you fix it in svn, release a new version, it gets to Debian, etc. Ah, I that can be circumvented by doing pypy `which py.test` ... instead of py.test --exec=pypy ... Cheers, Carl Friedrich From ondrej at certik.cz Mon Sep 17 16:32:13 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Mon, 17 Sep 2007 16:32:13 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <46EE8CFA.2080209@gmx.de> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <85b5c3130709150623p5de74662j107cccc39c65db8c@mail.gmail.com> <46EE8CFA.2080209@gmx.de> Message-ID: <85b5c3130709170732m3c32dd1co7aa7351c7762aa81@mail.gmail.com> On 9/17/07, Carl Friedrich Bolz wrote: > Ondrej Certik wrote: > >> There is another problem actually: > >> > >> $ py.test --exec=pypy > >> * opening PopenGateway: /usr/bin/pypy > >> MASTER: initiated slave terminal session -> > >> MASTER: send start info, topdir=/home/ondra/sympy > >> Traceback (most recent call last): > >> File "?", line 32, in run_toplevel > >> File "?", line 265, in run_it > >> File "", line 1, in > >> File "", line 40, in > >> ImportError: No module named thread > >> Traceback (most recent call last): > >> File "/usr/bin/py.test", line 4, in ? > >> py.test.cmdline.main() > >> File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 15, in main > >> failures = session.main() > >> File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", > >> line 82, in main > >> failures = self.run_remote_session(failures) > >> File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py", > >> line 111, in run_remote_session > >> return channel.receive() > >> File "/usr/lib/python2.4/site-packages/py/execnet/channel.py", line > >> 175, in receive > >> raise self._getremoteerror() or EOFError() > >> EOFError > > > > I forgot to add - I am using the versions from Debian unstable. I > > don't have time to test everything from svn, however, if you want, I > > can make new versions of pypy/py.test available in Debian when you > > release them, but I think the current maintainer will do also do it - > > Alexandre Fayolle is the maintainer of those packages - should I > > report bugs in them to Debian BTS, or here? > > > > I think the way to go is just users report problems against the > > packages in their distributions, like Debian, it is forwarded here, > > you fix it in svn, release a new version, it gets to Debian, etc. > > Ah, I that can be circumvented by doing > > pypy `which py.test` ... > > instead of > > py.test --exec=pypy ... I tried that one too: $ pypy `which py.test` Traceback (most recent call last): File "?", line 32, in run_toplevel File "/usr/bin/py.test", line 3, in import py ImportError: No module named py Ondrej From cfbolz at gmx.de Mon Sep 17 17:39:09 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 17 Sep 2007 17:39:09 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: References: Message-ID: <46EE9F9D.8000809@gmx.de> Adam Olsen wrote: >> 4) Myabe allow to speed my code up (JIT), or make Python as fast as >> possible. But this is rather a long term goal. Generally, I don't see >> why my code written in C and the same code written in Python, not >> using much dynamic features, couldn't be the same fast. (Of course I >> understand why now it is slower, Python is interpreted, etc. But I >> mean in principle. Python can have as much information about my code >> as the C compiler.) I use Python for devising new numerical >> algorithms, and than I need to rewrite them by hand to fortran for >> speed. It's a pain. > >> 6) Allow efficient threading? CPython has the GIL (for good >> technological reasons). Generally pypy can improve how to do things in >> parallel in python. Currently, one needs to use pympi, pypar, or >> something. > > These two together are, in my mind, where PyPy can really shine. > Performance on par with CPython is critical to be taken seriously, but > CPython's difficulties with the GIL mean I can only make it scalable > at about 60% to 65% of the traditional efficiency (on pystones at > least). That gap gives PyPy enough room to surpass CPython on > scalable performance. > We are confident that we can surpass CPython's speed with the help of the JIT. As for free threading, the big prerequisite for that is a GC that plays well with threads. Boehm is not very good in this respect. After this is done we can think about how to insert locking operations in an automatic way to reduce the likelyhood of errors (this is currently already done for releasing the GIL around external function calls). Then there will probably be a huge amount of painful debugging :-) Cheers, Carl Friedrich From ondrej at certik.cz Mon Sep 17 17:51:54 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Mon, 17 Sep 2007 17:51:54 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <46EE9F9D.8000809@gmx.de> References: <46EE9F9D.8000809@gmx.de> Message-ID: <85b5c3130709170851m58ddfa39we707dc04dd5557e9@mail.gmail.com> > We are confident that we can surpass CPython's speed with the help of > the JIT. As for free threading, the big prerequisite for that is a GC > that plays well with threads. Boehm is not very good in this respect. > After this is done we can think about how to insert locking operations > in an automatic way to reduce the likelihood of errors (this is > currently already done for releasing the GIL around external function > calls). Then there will probably be a huge amount of painful debugging :-) I remembered other few remarks to point out: 1) Current pypy in Debian doesn't have modules: thread, ctypes. Thread is needed for py.test, ctypes for plotting facilities in sympy. Ondrej From tismer at stackless.com Mon Sep 17 18:23:30 2007 From: tismer at stackless.com (Christian Tismer) Date: Mon, 17 Sep 2007 18:23:30 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <46EE9F9D.8000809@gmx.de> References: <46EE9F9D.8000809@gmx.de> Message-ID: <46EEAA02.7080408@stackless.com> Carl Friedrich Bolz wrote: ... > We are confident that we can surpass CPython's speed with the help of > the JIT. As for free threading, the big prerequisite for that is a GC > that plays well with threads. Boehm is not very good in this respect. > After this is done we can think about how to insert locking operations > in an automatic way to reduce the likelyhood of errors (this is > currently already done for releasing the GIL around external function > calls). Then there will probably be a huge amount of painful debugging :-) I'm actually no longer convinced that it makes soo much sense to get rid of the GIL. Python's data model is not made for free threading. Have you had a look into http://www.parallelpython.com/ ? Might be a starting point into threads with disjoint interpreters and some locking just for data exchange. cheers - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From rhamph at gmail.com Mon Sep 17 19:39:23 2007 From: rhamph at gmail.com (Adam Olsen) Date: Mon, 17 Sep 2007 11:39:23 -0600 Subject: [pypy-dev] pypy with sympy In-Reply-To: <46EE9F9D.8000809@gmx.de> References: <46EE9F9D.8000809@gmx.de> Message-ID: On 9/17/07, Carl Friedrich Bolz wrote: > Adam Olsen wrote: > >> 4) Myabe allow to speed my code up (JIT), or make Python as fast as > >> possible. But this is rather a long term goal. Generally, I don't see > >> why my code written in C and the same code written in Python, not > >> using much dynamic features, couldn't be the same fast. (Of course I > >> understand why now it is slower, Python is interpreted, etc. But I > >> mean in principle. Python can have as much information about my code > >> as the C compiler.) I use Python for devising new numerical > >> algorithms, and than I need to rewrite them by hand to fortran for > >> speed. It's a pain. > > > >> 6) Allow efficient threading? CPython has the GIL (for good > >> technological reasons). Generally pypy can improve how to do things in > >> parallel in python. Currently, one needs to use pympi, pypar, or > >> something. > > > > These two together are, in my mind, where PyPy can really shine. > > Performance on par with CPython is critical to be taken seriously, but > > CPython's difficulties with the GIL mean I can only make it scalable > > at about 60% to 65% of the traditional efficiency (on pystones at > > least). That gap gives PyPy enough room to surpass CPython on > > scalable performance. > > > > We are confident that we can surpass CPython's speed with the help of > the JIT. As for free threading, the big prerequisite for that is a GC > that plays well with threads. Boehm is not very good in this respect. > After this is done we can think about how to insert locking operations > in an automatic way to reduce the likelyhood of errors (this is > currently already done for releasing the GIL around external function > calls). Then there will probably be a huge amount of painful debugging :-) I'm confident CPython will provide a language-level solution to locking. This does mean waiting over a year from this point though. -- Adam Olsen, aka Rhamphoryncus From erik at medallia.com Tue Sep 18 02:57:25 2007 From: erik at medallia.com (Erik Gorset) Date: Tue, 18 Sep 2007 02:57:25 +0200 Subject: [pypy-dev] continuations In-Reply-To: <46EE88EA.9020108@gmx.de> References: <46EACDFF.4020301@stackless.com> <46ED7240.3060903@stackless.com> <7577F030-2075-4009-B05F-FCB2B12CF519@medallia.com> <46EDDB72.8050603@stackless.com> <46EE3C03.7000507@gmx.de> <46EE804A.9010307@stackless.com> <46EE88EA.9020108@gmx.de> Message-ID: <3DA3B58D-07A3-4300-924A-DDE2F029CFFC@medallia.com> On Sep 17, 2007, at 4:02 PM, Carl Friedrich Bolz wrote: > Christian Tismer wrote: >> Ok, no problem, PyPy is the platform with the most chances >> to do this right, so why not discuss it here. >> >> I'd just prefer to change the topic then, since this is about a >> stackless sprint to finish and clean up things which are waiting. >> These things are going to be folded back into CPython stackless, >> where the re-incarnation of continuations is pretty unlikely. > > Oh, absolutely. A change of topic (or even a new thread) would have > been > good. Ok, thanks. I hope I'm not stepping on anyones toes by discussing continuations here. I'm a big fan of pypy project and find the work you're doing very interesting. I was just curious if there was any plans for supporting my favorite language feature :-) I'll insert my answer to Armin here: On Sep 17, 2007, at 12:31 PM, Armin Rigo wrote: > On Mon, Sep 17, 2007 at 03:00:51AM +0200, Erik Gorset wrote: >> Btw, it's possible to simulate some of call/cc's behavior using >> _stackless.fork() (I have a play-implementation lying around here >> somewhere). But it has several issues. The biggest one is that fork() >> actually copies some of the objects found on the stack. It's been >> a while since I've played around with cloneable and fork, so maybe >> this has been fixed. > > A deep issue with continuations in a language like Python is that > there > is no single best definition of what it should capture and what it > should not. If you think about what you would like to occur when you > capture a continuation or fork a coroutine, then you'll notice that > you > actually want some objects on the stack to be duplicated, and others > not. Actually, continuation should never copy objects. It's only about the non-local returns. For example the return statement makes it possible to jump back to the caller. If return instead was a function which you could save and call again, you would have the equivalent of call/cc. The big point here is that you don't have a stack anymore, but a tree of continuations. > For example, in: > > def f(n): > return [x*x for x in range(n)] > > which, remember, is equivalent to: > > def f(n): > lst = [] > for x in range(n): > lst.append(x*x) > return lst > > if we pause this function in the middle of the loop and fork it, > then it > feels "right" to duplicate the list -- otherwise both the original and > the copy will append the remaining items into the same list, resulting > in a single list with more than n elements. This is similar to problems with some implementation of map in scheme, not all are safe to use with call/cc. Some care must be taken to make sure different control flows are compatible with each other. With great power comes great responsibility ;-) The thing is, with call/cc it's possible to embed different paradigms in python like constraint, logic and dataflow programming. I find this very interesting :-) > In essence, it seems to me that both forking and full continuations > should not be part of the core of a language, for the same reasons as > pickling -- in my own experience at least, more than half of the time > "pickle" doesn't capture enough or capture too much. There is no > single > best solution. I think I will have to disagree here. Several uses of continuations already exists in the language like generators/coroutines, the return statement, loops and exceptions. True continuations unifies this into one concept with simple semantics. The option for a virtual machine implementation is then to either implement all the normal flow controls as special cases, or use true continuations as the fundamental building block for the rest. -- Erik Gorset -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1962 bytes Desc: not available URL: From arigo at tunes.org Wed Sep 19 13:58:14 2007 From: arigo at tunes.org (Armin Rigo) Date: Wed, 19 Sep 2007 13:58:14 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <85b5c3130709170732m3c32dd1co7aa7351c7762aa81@mail.gmail.com> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <85b5c3130709150623p5de74662j107cccc39c65db8c@mail.gmail.com> <46EE8CFA.2080209@gmx.de> <85b5c3130709170732m3c32dd1co7aa7351c7762aa81@mail.gmail.com> Message-ID: <20070919115814.GA8402@code0.codespeak.net> Hi Ondrej, On Mon, Sep 17, 2007 at 04:32:13PM +0200, Ondrej Certik wrote: > $ pypy `which py.test` > ImportError: No module named py That's obviously because the python path of pypy doesn't allow it to find the 'py' module. You don't have this problem if you don't use the globally-installed py.test, but the one from a PyPy checkout instead: pypy .../pypy-dist/py/bin/py.test args... or equivalently pypy .../pypy-dist/pypy/test_all.py args... A bientot, Armin. From cfbolz at gmx.de Wed Sep 19 14:19:51 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 19 Sep 2007 14:19:51 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <20070919115814.GA8402@code0.codespeak.net> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <85b5c3130709150623p5de74662j107cccc39c65db8c@mail.gmail.com> <46EE8CFA.2080209@gmx.de> <85b5c3130709170732m3c32dd1co7aa7351c7762aa81@mail.gmail.com> <20070919115814.GA8402@code0.codespeak.net> Message-ID: <348899050709190519k764d7973n602e95c77b101945@mail.gmail.com> Hi Armin, 2007/9/19, Armin Rigo : > On Mon, Sep 17, 2007 at 04:32:13PM +0200, Ondrej Certik wrote: > > $ pypy `which py.test` > > ImportError: No module named py > > That's obviously because the python path of pypy doesn't allow it to > find the 'py' module. You don't have this problem if you don't use the > globally-installed py.test, but the one from a PyPy checkout instead: > > pypy .../pypy-dist/py/bin/py.test args... > > or equivalently > > pypy .../pypy-dist/pypy/test_all.py args... that doesn't really help if you don't have a pypy checkout at all, but only use the pypy binary installed by Debian. I guess some rethinking there is in order. Cheers, Carl Friedrich From ondrej at certik.cz Wed Sep 19 14:22:38 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Wed, 19 Sep 2007 14:22:38 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <20070919115814.GA8402@code0.codespeak.net> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <85b5c3130709150623p5de74662j107cccc39c65db8c@mail.gmail.com> <46EE8CFA.2080209@gmx.de> <85b5c3130709170732m3c32dd1co7aa7351c7762aa81@mail.gmail.com> <20070919115814.GA8402@code0.codespeak.net> Message-ID: <85b5c3130709190522u6cd98510o83ea4adcd0a0d2f4@mail.gmail.com> Hi Armin, > That's obviously because the python path of pypy doesn't allow it to > find the 'py' module. You don't have this problem if you don't use the > globally-installed py.test, but the one from a PyPy checkout instead: > > pypy .../pypy-dist/py/bin/py.test args... > > or equivalently > > pypy .../pypy-dist/pypy/test_all.py args... I tried: ondra at fuji:~/sympy$ PYTHONPATH="/usr/lib/python2.4/site-packages/" pypy `which py.test` and got many errors, but I think all are the same: def __init__(self, targetfd, tmpfile=None): self.targetfd = targetfd if tmpfile is None: > tmpfile = self.maketmpfile() [/usr/lib/python2.4/site-packages/py/io/fdcapture.py:12] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ def maketmpfile(self): """ create a temporary file """ E f = os.tmpfile() > AttributeError: 'module' object has no attribute 'tmpfile' [/usr/lib/python2.4/site-packages/py/io/fdcapture.py:44] _______________________________________________________________________________ ================= tests finished: 21 failed in 11.93 seconds ================== So, I think it's the problem in py lib in debian, that it doesn't work with pypy? Then I tried as you suggested now: in /tmp: $ svn co http://codespeak.net/svn/pypy/dist pypy-dist in ~/sympy: $ pypy /tmp/pypy-dist/py/bin/py.test But the exact same problem as above: def maketmpfile(self): """ create a temporary file """ E f = os.tmpfile() > AttributeError: 'module' object has no attribute 'tmpfile' [/tmp/pypy-dist/py/io/fdcapture.py:44] _______________________________________________________________________________ ================== tests finished: 21 failed in 1.80 seconds ================== then I tried: $ pypy /tmp/pypy-dist/pypy/test_all.py and again the same problem. Maybe just the pypy in Debian is old? In this case maybe it's time for a new release. :) If you tell me what to fix, I'll send a patch to the debian maintainer to fix it in Debian. Ondrej From faassen at startifact.com Wed Sep 19 17:24:17 2007 From: faassen at startifact.com (Martijn Faassen) Date: Wed, 19 Sep 2007 17:24:17 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <200709151405.l8FE5fk8029135@theraft.openend.se> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <200709151405.l8FE5fk8029135@theraft.openend.se> Message-ID: Laura Creighton wrote: [snip] > It would be nice to find out exactly who wants what next from PyPy, > and perhaps more importantly, who would be willing to help on PyPy, > but cannot now, and what they would need in the way of changes before > they could contribute. Besides fixes for the bugs you have reported, > is there anything in particular you wish we were doing next? I'm glad to see this important discussion is taking place again. For my input, see my mails from a few months ago. :) Regards, Martijn From faassen at startifact.com Wed Sep 19 17:27:14 2007 From: faassen at startifact.com (Martijn Faassen) Date: Wed, 19 Sep 2007 17:27:14 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <46EC6B22.1060600@gmx.de> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <200709151405.l8FE5fk8029135@theraft.openend.se> <85b5c3130709150813s20ba3e4exd5a516953400cf4a@mail.gmail.com> <46EC6B22.1060600@gmx.de> Message-ID: Hey, Carl Friedrich Bolz wrote: > > 1) Make predictable releases, get pypy into distributions, fix bugs > > and just make it another Python interpreter. > > That one is a bit boring, don't you think? :-) No seriously, we can't > really compete with CPython on its home turf, we need additional > features that set us apart. Heh, it's definitely boring, but it's essential if you want PyPy to be adopted more widely. You already have plenty of features. I want PyPy to be in a state so I can use it in production. :) Regards, Martijn From cfbolz at gmx.de Wed Sep 19 17:39:18 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 19 Sep 2007 17:39:18 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <200709151405.l8FE5fk8029135@theraft.openend.se> <85b5c3130709150813s20ba3e4exd5a516953400cf4a@mail.gmail.com> <46EC6B22.1060600@gmx.de> Message-ID: <348899050709190839v20623b04wa8a84c2ae9000025@mail.gmail.com> Hi Martijn, 2007/9/19, Martijn Faassen : > Carl Friedrich Bolz wrote: > > > 1) Make predictable releases, get pypy into distributions, fix bugs > > > and just make it another Python interpreter. > > > > That one is a bit boring, don't you think? :-) No seriously, we can't > > really compete with CPython on its home turf, we need additional > > features that set us apart. > > Heh, it's definitely boring, but it's essential if you want PyPy to be > adopted more widely. You already have plenty of features. I want PyPy to > be in a state so I can use it in production. :) I was referring to the "make it another Python interpreter", not to the first part. Probably wasn't all too clear. Cheers, Carl Friedrich From ondrej at certik.cz Wed Sep 19 17:43:22 2007 From: ondrej at certik.cz (Ondrej Certik) Date: Wed, 19 Sep 2007 17:43:22 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <348899050709190839v20623b04wa8a84c2ae9000025@mail.gmail.com> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <200709151405.l8FE5fk8029135@theraft.openend.se> <85b5c3130709150813s20ba3e4exd5a516953400cf4a@mail.gmail.com> <46EC6B22.1060600@gmx.de> <348899050709190839v20623b04wa8a84c2ae9000025@mail.gmail.com> Message-ID: <85b5c3130709190843w5d9f2cc6ydd217dc06ba7caaa@mail.gmail.com> > I was referring to the "make it another Python interpreter", not to > the first part. Probably wasn't all too clear. Well, but I think that "make it another Python interpreter" is maybe boring but essential. When substituting pypy for python, it shoud just work. Ondrej From simon at arrowtheory.com Wed Sep 19 22:31:19 2007 From: simon at arrowtheory.com (Simon Burton) Date: Wed, 19 Sep 2007 13:31:19 -0700 Subject: [pypy-dev] about breaking RPython, RCTypes In-Reply-To: References: Message-ID: <20070919133119.41621464.simon@arrowtheory.com> On Wed, 20 Jun 2007 12:23:06 +0200 Martijn Faassen wrote: ... > > I happen to be interested in use case a) though. It is quite exciting to > me that we could have a faster template language interpreter What is this interpreter you refer to here ? Simon. From simon at arrowtheory.com Wed Sep 19 22:36:43 2007 From: simon at arrowtheory.com (Simon Burton) Date: Wed, 19 Sep 2007 13:36:43 -0700 Subject: [pypy-dev] pypy-dev@codespeak.net In-Reply-To: <20070819103308.GA28257@code0.codespeak.net> References: <20070819103308.GA28257@code0.codespeak.net> Message-ID: <20070919133643.3ee8394a.simon@arrowtheory.com> On Sun, 19 Aug 2007 12:33:09 +0200 Armin Rigo wrote: > > Hi all, > > Those that follow IRC already know it, but it's worth being announced a > bit more widely: I've been working on a form of sandboxing for RPython > programs, which now seems to work for the whole of PyPy. > > It's "sandboxing" as in "full virtualization", but done in normal C with > no OS support at all. It's a two-processes model: we can translate PyPy > to a special "pypy-c-sandbox" executable, which is safe in the sense > that it doesn't do any library or system call - instead, whenever it > would like to perform such an operation, it marshals the operation name > and the arguments to its stdout and it waits for the marshalled result > on its stdin. This pypy-c-sandbox process is meant to be run by an > outer "controller" program that answers to these operation requests. How is this different to just linking against a libc wrapper (that does whatever marshal magic is required) ? Simon. From simon at arrowtheory.com Thu Sep 20 00:37:47 2007 From: simon at arrowtheory.com (Simon Burton) Date: Wed, 19 Sep 2007 15:37:47 -0700 Subject: [pypy-dev] transactional memory Message-ID: <20070919153747.ee8f0749.simon@arrowtheory.com> Someone on pypy irc posted a link to a talk by Simon Peyton-Jones on transactional memory: http://oscon.blip.tv/file/317758/ it's worth checking out. Also, i noticed on the llvm list someone has added support for TM: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-August/010365.html Simon. From rahulgarg44 at gmail.com Thu Sep 20 12:15:30 2007 From: rahulgarg44 at gmail.com (Rahul Garg) Date: Thu, 20 Sep 2007 04:15:30 -0600 Subject: [pypy-dev] llvm backend status? Message-ID: Hi. I recently discovered PyPy and its one cool project in which I would love to be involved in some capacity :) So I have a bunch of questions about the direction and status of the project a) How is the LLVM backend coming along? b) What really are the focus areas of the project currently? c) Any wishlists ? thanks, rahul -------------- next part -------------- An HTML attachment was scrubbed... URL: From santagada at gmail.com Thu Sep 20 17:25:52 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Thu, 20 Sep 2007 12:25:52 -0300 Subject: [pypy-dev] llvm backend status? In-Reply-To: References: Message-ID: <25D6F8C5-5FED-46B0-89BD-6427C94D7F0E@gmail.com> Em Sep 20, 2007, ?s 7:15 AM, Rahul Garg escreveu: > Hi. > > I recently discovered PyPy and its one cool project in which I > would love to > be involved in some capacity :) GReat just great > So I have a bunch of questions about the direction and status of > the project > > > a) How is the LLVM backend coming along? The LLVM backend is unmaintened for some time, so to ressurect it you would need to work a little on it. Recently someone commited some changes that made most of the tests passing again using LLVM 1.9 so what you would need to do is: * update LLVM to use the LLVM 2.0 sintax (specially accepting LLVM 2.0 generated code from llvm-gcc) * make threads work (I think this was one of the things the last commit removed) * make rffi work on it (this is a new way to call C code, created after the LLVM got unmaintened). * Lot's of other little things... * profit :) > b) What really are the focus areas of the project currently? After the eu project ended people took some time off the project to recharge the batteries... and now people have started working again, and the focus is on cleanups, you can find more on pypy/doc/cleanup- todo.txt. > c) Any wishlists ? I think that everyone has its own besides cleanup-todo, mine is suport for unicode at the RPython level, a new garbage collector, and the revival of the LLVM backend, and of course the completion of the JIT. This is all from someone following the development of pypy from the outside, but I think I got most things right :) []'s -- Leonardo Santagada From rahulgarg44 at gmail.com Fri Sep 21 00:21:03 2007 From: rahulgarg44 at gmail.com (Rahul Garg) Date: Thu, 20 Sep 2007 16:21:03 -0600 Subject: [pypy-dev] llvm backend status? In-Reply-To: <25D6F8C5-5FED-46B0-89BD-6427C94D7F0E@gmail.com> References: <25D6F8C5-5FED-46B0-89BD-6427C94D7F0E@gmail.com> Message-ID: Hi. Thanks for the info :) My plan is to first use pypy for a few weeks as a user (perhaps writing a few benchmarks, testing out stuff like AOP, reading the docs on pypy and psyco etc). I hope to be involved more directly from sometime in october. thanks, rahul On 9/20/07, Leonardo Santagada wrote: > > > Em Sep 20, 2007, ?s 7:15 AM, Rahul Garg escreveu: > > > Hi. > > > > I recently discovered PyPy and its one cool project in which I > > would love to > > be involved in some capacity :) > > GReat just great > > > So I have a bunch of questions about the direction and status of > > the project > > > > > > a) How is the LLVM backend coming along? > > The LLVM backend is unmaintened for some time, so to ressurect it you > would need to work a little on it. Recently someone commited some > changes that made most of the tests passing again using LLVM 1.9 so > what you would need to do is: > * update LLVM to use the LLVM 2.0 sintax (specially accepting LLVM > 2.0 generated code from llvm-gcc) > * make threads work (I think this was one of the things the last > commit removed) > * make rffi work on it (this is a new way to call C code, created > after the LLVM got unmaintened). > * Lot's of other little things... > * profit :) > > > > b) What really are the focus areas of the project currently? > > After the eu project ended people took some time off the project to > recharge the batteries... and now people have started working again, > and the focus is on cleanups, you can find more on pypy/doc/cleanup- > todo.txt. > > > c) Any wishlists ? > > I think that everyone has its own besides cleanup-todo, mine is > suport for unicode at the RPython level, a new garbage collector, and > the revival of the LLVM backend, and of course the completion of the > JIT. > > This is all from someone following the development of pypy from the > outside, but I think I got most things right :) > > []'s > -- > Leonardo Santagada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Sat Sep 22 09:18:50 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 22 Sep 2007 09:18:50 +0200 Subject: [pypy-dev] PyPy/Squeak Sprint Announcement Message-ID: <46F4C1DA.7080004@gmx.de> Bern Squeak/PyPy sprint October 22 - October 26 2007 ===================================================== We are proud to announce the first Squeak-PyPy-collaboration-sprint. The plan is to bring people from the Squeak/Smalltalk and the PyPy/Python communities together to learn about each others projects and to think about collaboration possibilies. The sprint will be hosted by the Software Composition Group of the University of Bern from the 22nd to the 26th of October 2007. Topics and goals ---------------- The general technical goal of the sprint is to explore implementing the bytecode interpreter as well as the primitives of Squeak in RPython. This should make it eventually possible to auto-generate a JIT for Squeak with the help of PyPy technologies. The other important goal of the sprint is to teach the first-time-sprinters the sprint-driven-development methodology. The first day of the sprint will be a tutorial day, were talks about PyPy, Squeak and sprint-driven-development will be given. The further days will be sprinting days. Of course the most important goal of the sprint is to get to know each other and have some fun :-). Topics of the sprint: - learning about: - PyPy - the internals of Squeaks VM - sprint-driven-development - exploring ways to implement Squeaks bytecode-interpreter and the primitives in Python - or (maybe alternatively) implement a Squeak-backend for PyPy - think about how to load and store of images in PyPy Location -------- The sprint will take place in a seminar room at the University of Bern. Further details of how to get there will be announced before the sprint. Registration ------------ If you'd like to come, please subscribe to the `pypy-sprint mailing list`_ and drop a note about your interests and post any questions. More organisational information will be send to that list. We'll keep a list of `people`_ which we'll update (which you can do so yourself if you have codespeak commit rights). If you have no clue where to stay in Bern ask around on the list, maybe we can help you find something or find some other solution. .. _`pypy-sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint .. _`people`: http://codespeak.net/pypy/extradoc/sprintinfo/bern2007/people.html From arigo at tunes.org Tue Sep 25 11:03:11 2007 From: arigo at tunes.org (Armin Rigo) Date: Tue, 25 Sep 2007 11:03:11 +0200 Subject: [pypy-dev] pypy-dev@codespeak.net In-Reply-To: <20070919133643.3ee8394a.simon@arrowtheory.com> References: <20070819103308.GA28257@code0.codespeak.net> <20070919133643.3ee8394a.simon@arrowtheory.com> Message-ID: <20070925090311.GA28896@code0.codespeak.net> Hi Simon, On Wed, Sep 19, 2007 at 01:36:43PM -0700, Simon Burton wrote: > > It's "sandboxing" as in "full virtualization", but done in normal C with > > no OS support at all. (...) > > How is this different to just linking against a libc wrapper (that does > whatever marshal magic is required) ? The result is similar; what differs is how we arrive there, and the level of confidence I'd have in the security of the result. In the case of PyPy the wrapping is done automatically and in a platform-independent way; contrast this with the need for the designers of the libc wrapper to carefully close all possible ways the C program could invoke the system and carefully review the result, which is error-prone and platform-specific. More importantly for the user, in the PyPy approach the C code is not random C code, but was generated from RPython. This (together with extra run-time assertions that the translation toolchain can insert for the paranoid) means that buffer overflow or memory management attacks should not be possible. This means that there is no need to review the source code of the whole PyPy interpreter for security issues. By contrast, if you take say CPython and put it inside a libc wrapper, the result is not safe because CPython itself is open to attacks (e.g. memory management issues where carefully crafted app-level Python code could force CPython to execute arbitrary machine code - including system calls bypassing the libc wrapper). A bientot, Armin. From arigo at tunes.org Tue Sep 25 11:05:43 2007 From: arigo at tunes.org (Armin Rigo) Date: Tue, 25 Sep 2007 11:05:43 +0200 Subject: [pypy-dev] pypy with sympy In-Reply-To: <85b5c3130709190522u6cd98510o83ea4adcd0a0d2f4@mail.gmail.com> References: <85b5c3130709141758s2c832322uc4b986144b87a14e@mail.gmail.com> <46EBD4B6.2050500@gmx.de> <85b5c3130709150617j37b76299o306b713bdc6bbb40@mail.gmail.com> <85b5c3130709150623p5de74662j107cccc39c65db8c@mail.gmail.com> <46EE8CFA.2080209@gmx.de> <85b5c3130709170732m3c32dd1co7aa7351c7762aa81@mail.gmail.com> <20070919115814.GA8402@code0.codespeak.net> <85b5c3130709190522u6cd98510o83ea4adcd0a0d2f4@mail.gmail.com> Message-ID: <20070925090542.GB28896@code0.codespeak.net> Hi Ondrej, On Wed, Sep 19, 2007 at 02:22:38PM +0200, Ondrej Certik wrote: > E f = os.tmpfile() > > AttributeError: 'module' object has no attribute 'tmpfile' > > Maybe just the pypy in Debian is old? In this case maybe it's time for > a new release. :) If you tell me what to fix, I'll send a patch to the > debian maintainer to fix it in Debian. Yes, os.tmpfile() was added in the meantime. I personally don't see much the point of making Debian packages of PyPy at the moment, given that we're in a state where you are almost always better off if you start from our Subversion repository instead of from a release a few months old. We're not "user-ready" and this situation will not change before some more months, maybe 1 year. I'd really recommend starting from our 'getting-started' document on the web site instead of the Debian packages. A bientot, Armin. From simon at arrowtheory.com Tue Sep 25 18:38:00 2007 From: simon at arrowtheory.com (Simon Burton) Date: Tue, 25 Sep 2007 09:38:00 -0700 Subject: [pypy-dev] rpython numpy Message-ID: <20070925093800.02d7ad4a.simon@arrowtheory.com> I've been having some fun working on a (tiny) rpython version of numpy. At the heart of numpy is a multi-dimensional array type, ndarray. For example it (the cpython version) can handle processing image arrays like so: >>> import numpy >>> from PIL import Image >>> im=Image.open('jit.png') >>> data=numpy.array(im) now data is a 3 dimensional array, data.ndim==3 and data.shape==(1158, 1173, 3). The last dimension is the color dimension. The cool part of numpy is all the indexing tricks. This is a single pixel: >>> data[0,0,:] array([224, 255, 224], dtype=uint8) this is the red channel: >>> data[:,:,0] array([[224, 224, 224, ..., 224, 224, 224], ... now we mix red and blue: >>> data[:,:,0]+data[:,:,2] (this actually didn't work so well because it's an array of uint8 and we get overflow, but that can be fixed with a cast) The trick with numpy is, every time we use an indexing operation it creates a "view" onto the original data, ie. the memory is aliased. Each ndarray stores a list of "strides" (integers) which specify how many bytes to skip when incrementing an index in a dimension: >>> data.strides (3519, 3, 1) >>> data[:,:,0].strides (3519, 3) Then numpy (at the c level) uses iterators to perform getattr, setattr, and other (pointwise) operations. "broadcasting" allows a smaller array to be used as a larger array, as long as the shape of the smaller array is a suffix of the shape of the larger. >>> green = numpy.array([0,255,0], dtype=numpy.uint8) >>> data[:] = green This sets every pixel to green. I made a design choice with rnumpy to specialize on the number of dimensions (ndim) of an array. This means that we can generate efficient code (more about this below); which was just too tempting to ignore. But also, * it would be impossible to access arbitrary ndim arrays from a pypy wrapped rnumpy. * the shape attribute is read-only. To change the shape of an array, use the reshape method (this does not copy the data): >>> numpy.array(range(12)).reshape((3,4)) array([[ 0, 1, 2, 3], [ 4, 5, 6, 7], [ 8, 9, 10, 11]]) The above mentioned "efficient code" is perhaps a non-issue. Numpy code tends to become memory-bound, not cpu-bound. However it is an interesting use of the rpython optimiser. In general, to iterate over an n-dimensional array requires n-nested for loops, or the use of a "coordinate" array. In this implementation (as in the c implementation) there is an iterator object to hold the coordinates (and the corresponding strides). With malloc removal, all this iterator data become local variables. It's nifty. I don't really know where this is all going; an obvious goal would be to extend all this with a variable dimension array type (and write an applevel numpy). One of the original ideas was to somehow produce cache friendly code by doing lazy operations. Another issue is that it has been mind-boggleingly difficult to directly extend the compiler. I would like to rethink this whole approach; perhaps special methods can help, or some other "low-level to high-level" interaction. Simon. From david at ar.media.kyoto-u.ac.jp Wed Sep 26 04:22:33 2007 From: david at ar.media.kyoto-u.ac.jp (David Cournapeau) Date: Wed, 26 Sep 2007 11:22:33 +0900 Subject: [pypy-dev] rpython numpy In-Reply-To: <20070925093800.02d7ad4a.simon@arrowtheory.com> References: <20070925093800.02d7ad4a.simon@arrowtheory.com> Message-ID: <46F9C269.4090605@ar.media.kyoto-u.ac.jp> Simon Burton wrote: > I've been having some fun working on a (tiny) rpython version of numpy. That's great, this is really one of the most interesting part of pypy for me. > > > The above mentioned "efficient code" is perhaps a non-issue. Numpy > code tends to become memory-bound, not cpu-bound. I tend to agree, at least from my limited observation and hacking on numpy: some (quite fundamental) operations are not cache friendly at all. But I thought this was what rpython + pypy could improve quite a lot, actually. For example, one problem with numpy, specially with broadcasting and the ufunc machinery, is to decide on which dimension to compute for maximum performances. See for example http://www.mail-archive.com/numpy-discussion at scipy.org/msg03759.html. David From brandon_lewis at berkeley.edu Wed Sep 26 06:07:59 2007 From: brandon_lewis at berkeley.edu (Brandon Lewis) Date: Tue, 25 Sep 2007 21:07:59 -0700 Subject: [pypy-dev] New on list Message-ID: <46F9DB1F.8010901@berkeley.edu> Hi, my name is Brandon Lewis. I'm an undergrad Cognitive Science major at U.C. Berkeley. I'm currently taking the upper-division compilers class. Our final project will be writing a JavaScript interpreter. Interestingly enough, we are using Python as the implementation language; so, when I discovered this project while looking through some python documentation, I was intrigued. Mostly just wanted to introduce myself. --Brandon Lewis From cfbolz at gmx.de Wed Sep 26 10:15:40 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Wed, 26 Sep 2007 10:15:40 +0200 Subject: [pypy-dev] New on list In-Reply-To: <46F9DB1F.8010901@berkeley.edu> References: <46F9DB1F.8010901@berkeley.edu> Message-ID: <348899050709260115p67e8d101v815d8892c6e649a6@mail.gmail.com> Hi Brandon! 2007/9/26, Brandon Lewis : > Hi, my name is Brandon Lewis. I'm an undergrad Cognitive Science major > at U.C. Berkeley. I'm currently taking the upper-division compilers class. Welcome! > Our final project will be writing a JavaScript interpreter. > Interestingly enough, we are using Python as the implementation > language; so, when I discovered this project while looking through some > python documentation, I was intrigued. I guess stealing the PyPy JavaScript interpreter andhanding it in is not an option, right? :-) Cheers, Carl Friedrich From santagada at gmail.com Wed Sep 26 12:42:57 2007 From: santagada at gmail.com (Leonardo Santagada) Date: Wed, 26 Sep 2007 07:42:57 -0300 Subject: [pypy-dev] New on list In-Reply-To: <46F9DB1F.8010901@berkeley.edu> References: <46F9DB1F.8010901@berkeley.edu> Message-ID: <8D369274-3FEC-4412-AB23-53DB51F71A93@gmail.com> Em Sep 26, 2007, ?s 1:07 AM, Brandon Lewis escreveu: > Hi, my name is Brandon Lewis. I'm an undergrad Cognitive Science major > at U.C. Berkeley. I'm currently taking the upper-division compilers > class. > > Our final project will be writing a JavaScript interpreter. > Interestingly enough, we are using Python as the implementation > language; so, when I discovered this project while looking through > some > python documentation, I was intrigued. > > Mostly just wanted to introduce myself. Great, if you want to use anything from the PyPy JS interpreter be welcome, and if you want to contribute back to that it would be perfect. But if you need to start from scratch (because your teacher told you to, or for any other reason) we would be happy to help you still. If you have any questions just mail it to the list and/or to me that I would be happy to help you get used to the code base. -- Leonardo Santagada From paul.degrandis at gmail.com Wed Sep 26 13:59:44 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Wed, 26 Sep 2007 07:59:44 -0400 Subject: [pypy-dev] New on list In-Reply-To: <46F9DB1F.8010901@berkeley.edu> References: <46F9DB1F.8010901@berkeley.edu> Message-ID: <9c0bb8a00709260459h162da238ga05f3f08ac4423e9@mail.gmail.com> On 9/26/07, Brandon Lewis wrote: > > Hi, my name is Brandon Lewis. I'm an undergrad Cognitive Science major > at U.C. Berkeley. I'm currently taking the upper-division compilers class. Finally I'm not the only person from the United States! :) Hi Brandon and welcome! I'm a BS/MS student at Drexel University. My BS is in Software Engineering. My MS is in Computer Science with my thesis on Dependable Systems and Autonomic Computing. Our final project will be writing a JavaScript interpreter. > Interestingly enough, we are using Python as the implementation > language; so, when I discovered this project while looking through some > python documentation, I was intrigued. It sounds like you have a great professor! Enjoy the class. Paul Mostly just wanted to introduce myself. > > --Brandon Lewis > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.jtm30 at gmail.com Wed Sep 26 16:36:18 2007 From: adam.jtm30 at gmail.com (Adam Bark) Date: Wed, 26 Sep 2007 15:36:18 +0100 Subject: [pypy-dev] New on list In-Reply-To: <9c0bb8a00709260459h162da238ga05f3f08ac4423e9@mail.gmail.com> References: <46F9DB1F.8010901@berkeley.edu> <9c0bb8a00709260459h162da238ga05f3f08ac4423e9@mail.gmail.com> Message-ID: On 26/09/2007, Paul deGrandis wrote: > > > > On 9/26/07, Brandon Lewis wrote: > > > > Hi, my name is Brandon Lewis. I'm an undergrad Cognitive Science major > > at U.C. Berkeley. I'm currently taking the upper-division compilers > > class. > > > > Finally I'm not the only person from the United States! :) > Hi Brandon and welcome! I'm a BS/MS student at Drexel University. My BS is in Software Engineering. > My MS is in Computer Science with my thesis on Dependable Systems and > Autonomic Computing. > > Our final project will be writing a JavaScript interpreter. > > Interestingly enough, we are using Python as the implementation > > language; so, when I discovered this project while looking through some > > python documentation, I was intrigued. > > > It sounds like you have a great professor! Enjoy the class. > > Paul > > Mostly just wanted to introduce myself. > > > > --Brandon Lewis > > Hi, I thought while people were introducing themselves I'd jump in. I'm a BSc Physics student at the University of Leicester in England I program almost exclusively for fun, I've been looking at getting into an established project but it's not as easy as it sounds so any help with getting me into pypy development would be cool. Thanks, sorry about the hijack Brandon :-p Adam Bark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richardemslie at gmail.com Wed Sep 26 20:07:11 2007 From: richardemslie at gmail.com (Richard Emslie) Date: Wed, 26 Sep 2007 19:07:11 +0100 Subject: [pypy-dev] PyPy cleanups In-Reply-To: <44A9D542-1F27-4E64-9EBA-123407BFB220@gmail.com> References: <44A9D542-1F27-4E64-9EBA-123407BFB220@gmail.com> Message-ID: Hi! Sorry it has taken forever to reply... > > This is the list of possibly orphaned parts of pypy. > We should consider each item here and think in detail > what to do with them. They're mostly broken or not > actively maintained. If nobody shows an interest > to maintain them, deleting would be the best solution > to avoid clutter. Also they pose a maintenance burden > when we proceed with the needed large refactorings. > Maybe it is also a solution to lazily delete them as > they are broken by refactoring if nobody steps up. > > Of course deleted things can easily be brought back from > svn history, if there is renewed interest. So the above > may sound scarier than it is. > > * llvm backend - we need a maintainer for that As much I as I agree that deleting code is better than leaving it to rot beyond all recognition, I'm still not sure why we need a "maintainer" for this given that no other backend has an explicit maintainer. But anyways I will take that role if it needs be. Most work to be done is in factoring code out of genc and making rffi work (which I am guessing making changes to rffi, but not sure since haven't been following things for last however many months). > * pyrex backend (llvm depends on it tough) There is no longer this dependency. Cheers, Richard From fijall at gmail.com Thu Sep 27 09:14:10 2007 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 27 Sep 2007 15:14:10 +0800 Subject: [pypy-dev] PyPy cleanups In-Reply-To: References: <44A9D542-1F27-4E64-9EBA-123407BFB220@gmail.com> Message-ID: <693bc9ab0709270014k6e1b788ej6bf5fc7bc24db859@mail.gmail.com> Good to hear. There is no reason for maintainer, but we need llvm backend to be refactored so it would be easier to maintain for whoever makes changes. Also right now llvm version dependency is so bizzare that I cannot really test it on my machine without additional hassle. I can help with that, if possible. Cheers, fijal On 9/27/07, Richard Emslie wrote: > > Hi! > > Sorry it has taken forever to reply... > > > > > This is the list of possibly orphaned parts of pypy. > > We should consider each item here and think in detail > > what to do with them. They're mostly broken or not > > actively maintained. If nobody shows an interest > > to maintain them, deleting would be the best solution > > to avoid clutter. Also they pose a maintenance burden > > when we proceed with the needed large refactorings. > > Maybe it is also a solution to lazily delete them as > > they are broken by refactoring if nobody steps up. > > > > Of course deleted things can easily be brought back from > > svn history, if there is renewed interest. So the above > > may sound scarier than it is. > > > > * llvm backend - we need a maintainer for that > > As much I as I agree that deleting code is better than leaving it to > rot beyond all recognition, I'm still not sure why we need a > "maintainer" for this given that no other backend has an explicit > maintainer. But anyways I will take that role if it needs be. Most > work to be done is in factoring code out of genc and making rffi work > (which I am guessing making changes to rffi, but not sure since > haven't been following things for last however many months). > > > * pyrex backend (llvm depends on it tough) > > There is no longer this dependency. > > Cheers, > Richard > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Thu Sep 27 09:15:41 2007 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 27 Sep 2007 15:15:41 +0800 Subject: [pypy-dev] New on list In-Reply-To: <348899050709260115p67e8d101v815d8892c6e649a6@mail.gmail.com> References: <46F9DB1F.8010901@berkeley.edu> <348899050709260115p67e8d101v815d8892c6e649a6@mail.gmail.com> Message-ID: <693bc9ab0709270015h4d63cdfepe27cec9fa1c7fa30@mail.gmail.com> Also I would be more than happy if we can at least share testing code :-) On 9/26/07, Carl Friedrich Bolz wrote: > > Hi Brandon! > > 2007/9/26, Brandon Lewis : > > Hi, my name is Brandon Lewis. I'm an undergrad Cognitive Science major > > at U.C. Berkeley. I'm currently taking the upper-division compilers > class. > > Welcome! > > > Our final project will be writing a JavaScript interpreter. > > Interestingly enough, we are using Python as the implementation > > language; so, when I discovered this project while looking through some > > python documentation, I was intrigued. > > I guess stealing the PyPy JavaScript interpreter andhanding it in is > not an option, right? :-) > > Cheers, > > Carl Friedrich > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Thu Sep 27 10:41:18 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 27 Sep 2007 10:41:18 +0200 Subject: [pypy-dev] New on list In-Reply-To: References: <46F9DB1F.8010901@berkeley.edu> <9c0bb8a00709260459h162da238ga05f3f08ac4423e9@mail.gmail.com> Message-ID: <348899050709270141j21854c2bm640bc247b3ef6e18@mail.gmail.com> Hi Adam, 2007/9/26, Adam Bark : > Hi, I thought while people were introducing themselves I'd jump in. I'm a > BSc Physics student at the University of Leicester in England I program > almost exclusively for fun, I've been looking at getting into an established > project but it's not as easy as it sounds so any help with getting me into > pypy development would be cool. Finally a physicist, welcome! (I did physics for a while but abandoned it later in favour of computer science). Cheers, Carl Friedrich From brandon_lewis at berkeley.edu Thu Sep 27 19:06:22 2007 From: brandon_lewis at berkeley.edu (Brandon Lewis) Date: Thu, 27 Sep 2007 10:06:22 -0700 Subject: [pypy-dev] Replies to list? Message-ID: <46FBE30E.3060506@berkeley.edu> Just wondering about how this list handles replies. If I get a reply off-list should I reply to it on-list? --Brandon From brandon_lewis at berkeley.edu Thu Sep 27 19:09:02 2007 From: brandon_lewis at berkeley.edu (Brandon Lewis) Date: Thu, 27 Sep 2007 10:09:02 -0700 Subject: [pypy-dev] New on list In-Reply-To: References: <46F9DB1F.8010901@berkeley.edu> <9c0bb8a00709260459h162da238ga05f3f08ac4423e9@mail.gmail.com> Message-ID: <46FBE3AE.8030003@berkeley.edu> > > Hi, I thought while people were introducing themselves I'd jump in. I'm > a BSc Physics student at the University of Leicester in England I > program almost exclusively for fun, I've been looking at getting into an > established project but it's not as easy as it sounds so any help with > getting me into pypy development would be cool. > Thanks, sorry about the hijack Brandon :-p > > Adam Bark. > > No, worries. To be honest, a language interpreter/compiler is not the easiest thing to get started on. From brandon_lewis at berkeley.edu Thu Sep 27 19:13:34 2007 From: brandon_lewis at berkeley.edu (Brandon Lewis) Date: Thu, 27 Sep 2007 10:13:34 -0700 Subject: [pypy-dev] New on list In-Reply-To: References: <46F9DB1F.8010901@berkeley.edu> <9c0bb8a00709260459h162da238ga05f3f08ac4423e9@mail.gmail.com> Message-ID: <46FBE4BE.2030009@berkeley.edu> > Hi, I thought while people were introducing themselves I'd jump in. I'm > a BSc Physics student at the University of Leicester in England I > program almost exclusively for fun, I've been looking at getting into an > established project but it's not as easy as it sounds so any help with > getting me into pypy development would be cool. I was in england last summer for G.U.A.D.E.C.! Nice to meet you. To be honest, a language interpreter/compiler is not an easy project starter project. I remember sweating through the introductory scheme course at Berkeley, where we had to write a scheme interpreter in scheme for our final project. But if you can wrap your head around it, it will be worth the effort. > Thanks, sorry about the hijack Brandon :-p > > Adam Bark. > No worries =) --Brandon Lewis From paul.degrandis at gmail.com Thu Sep 27 20:22:15 2007 From: paul.degrandis at gmail.com (Paul deGrandis) Date: Thu, 27 Sep 2007 14:22:15 -0400 Subject: [pypy-dev] Replies to list? In-Reply-To: <46FBE30E.3060506@berkeley.edu> References: <46FBE30E.3060506@berkeley.edu> Message-ID: <9c0bb8a00709271122w418d8750u46a3b41bfc85b52@mail.gmail.com> My word is not law by anymeans but if you feel it's something the whole communiety should know or be able to go back and search on, reply on the list. I know sometimes I click "reply" instead of "reply to all" and it seems that in all of those cases, the reply back to me has been sent to the list. Paul On 9/27/07, Brandon Lewis wrote: > > Just wondering about how this list handles replies. If I get a reply > off-list should I reply to it on-list? > > --Brandon > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Thu Sep 27 20:35:29 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 27 Sep 2007 20:35:29 +0200 Subject: [pypy-dev] Replies to list? In-Reply-To: <9c0bb8a00709271122w418d8750u46a3b41bfc85b52@mail.gmail.com> References: <46FBE30E.3060506@berkeley.edu> <9c0bb8a00709271122w418d8750u46a3b41bfc85b52@mail.gmail.com> Message-ID: <348899050709271135q5652077cr5cad3c2cfc04ffd@mail.gmail.com> 2007/9/27, Paul deGrandis : > My word is not law by anymeans but if you feel it's something the whole > communiety should know or be able to go back and search on, reply on the > list. Sounds good. If you want to answer the whole list, choose "reply to all", if you want to answer a person personally use "reply". If somebody wrote you personally and you are sure it was by mistake you can CC the list again (don't forget to not snip the other persons post then when replying). Cheers, Carl Friedrich From overminddl1 at gmail.com Thu Sep 27 21:03:15 2007 From: overminddl1 at gmail.com (OvermindDL1) Date: Thu, 27 Sep 2007 13:03:15 -0600 Subject: [pypy-dev] Fwd: New on list In-Reply-To: <3f49a9f40709271202y6f71d336kbc8fdd76b391919e@mail.gmail.com> References: <46F9DB1F.8010901@berkeley.edu> <9c0bb8a00709260459h162da238ga05f3f08ac4423e9@mail.gmail.com> <3f49a9f40709271202y6f71d336kbc8fdd76b391919e@mail.gmail.com> Message-ID: <3f49a9f40709271203p5ec35444gaf3f301820bb66cf@mail.gmail.com> I'm from the USA as well, although I tend to be extremely quiet on here... I'm hoping for PyPy to be a faster Python mostly (would love the exporting to C++), especially with stackless functionality. I know the CPython internals quite well, so if there is anywhere I can use that knowledge in here, feel free to ask, short on time but of what little I have I can give up to this. EDIT: Helps if I send to the right list... Too many too similar lists... On 9/26/07, Paul deGrandis wrote: > > > On 9/26/07, Brandon Lewis wrote: > > Hi, my name is Brandon Lewis. I'm an undergrad Cognitive Science major > > at U.C. Berkeley. I'm currently taking the upper-division compilers class. > > > Finally I'm not the only person from the United > States! :) > Hi Brandon and welcome! I'm a BS/MS student at > Drexel University. My BS is in Software > Engineering. My MS is in Computer Science with my thesis on Dependable > Systems and Autonomic Computing. > > Our final project will be writing a JavaScript interpreter. > > Interestingly enough, we are using Python as the implementation > > language; so, when I discovered this project while looking through some > > python documentation, I was intrigued. > > It sounds like you have a great professor! Enjoy the class. > > Paul > > > Mostly just wanted to introduce myself. > > > > --Brandon Lewis > > _______________________________________________ > > 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 bokr at oz.net Thu Sep 27 22:18:45 2007 From: bokr at oz.net (Bengt Richter) Date: Thu, 27 Sep 2007 13:18:45 -0700 Subject: [pypy-dev] PyPy/Squeak Sprint Announcement In-Reply-To: <46F4C1DA.7080004@gmx.de> Message-ID: <5.0.2.1.1.20070927115740.00aef730@mail.oz.net> At 09:18 2007-09-22 +0200, Carl Friedrich Bolz wrote: >Bern Squeak/PyPy sprint October 22 - October 26 2007 >===================================================== > >We are proud to announce the first Squeak-PyPy-collaboration-sprint. >The plan is to bring people from the Squeak/Smalltalk and the >PyPy/Python communities together to learn about each others projects and >to think about collaboration possibilies. The sprint will be hosted by >the Software Composition Group of the University of Bern from the 22nd >to the 26th of October 2007. > > >Topics and goals >---------------- > >The general technical goal of the sprint is to explore implementing the >bytecode interpreter as well as the primitives of Squeak in RPython. >This should make it eventually possible to auto-generate a JIT for >Squeak with the help of PyPy technologies. > >The other important goal of the sprint is to teach the >first-time-sprinters the sprint-driven-development methodology. > >The first day of the sprint will be a tutorial day, were talks about >PyPy, Squeak and sprint-driven-development will be given. The further >days will be sprinting days. > >Of course the most important goal of the sprint is to get to know each >other and have some fun :-). > >Topics of the sprint: > >- learning about: > > - PyPy > - the internals of Squeaks VM > - sprint-driven-development > >- exploring ways to implement Squeaks bytecode-interpreter and the > primitives in Python > >- or (maybe alternatively) implement a Squeak-backend for PyPy > >- think about how to load and store of images in PyPy > > >Location >-------- > >The sprint will take place in a seminar room at the University of Bern. >Further details of how to get there will be announced before the sprint. > > >Registration >------------ > >If you'd like to come, please subscribe to the `pypy-sprint mailing list`_ >and drop a note about your interests and post any questions. More >organisational information will be send to that list. We'll keep a list >of `people`_ which we'll update (which you can do so yourself if you >have codespeak commit rights). If you have no clue where to stay in >Bern ask around on the list, maybe we can help you find something or >find some other solution. > >.. _`pypy-sprint mailing list`: >http://codespeak.net/mailman/listinfo/pypy-sprint >.. _`people`: >http://codespeak.net/pypy/extradoc/sprintinfo/bern2007/people.html >_______________________________________________ >pypy-dev at codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev Hello. This sounds interesting! If a video or sound track plus slides wound up on video.google.com or youtube.com I would certainly watch it. Hint, hint ;-) Perhaps others would agree, and have the influence and/or ability/interest/energy to make it happen? (Perhaps the University of Bern has an audio/visual dept with someone who would be willing to come in and set up good sound recording etc for the event? Or maybe someone is in a music group that has a good sound-recordist? I emphasize sound because I think good/bad sound makes/breaks a video more than visual quality, especially when the speaker gets past reading bullet points (also helpful) and is interacting and explaining and musing.) Regards, Bengt Richter Still lurking now and then ;-) From cfbolz at gmx.de Sat Sep 29 15:50:33 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 29 Sep 2007 15:50:33 +0200 Subject: [pypy-dev] Gothenburg Sprint Announcement Message-ID: <348899050709290650qba97961k91b6c073a7e0ea34@mail.gmail.com> PyPy G?teborg Cleanup Sprint November 19 - November 25 2007 =========================================================== The next post-EU-project PyPy sprint will be in Gothenburg, Sweden. It will focus on cleaning up the PyPy codebase and making it ready for the next round of improvements. It is a "public" sprint but it will probably be more suitable for people already somewhat acquainted with PyPy. Topics and goals ---------------- Meta-Tasks ++++++++++ - Tracker-gardening - Start slowly thinking about 1.1 plans Translation toolchain +++++++++++++++++++++ - finish rctypes removal - move away from implicit keepalives - raw_malloc should be split, rffi one should not use obmalloc (it's not thread-safe) - kill simulator, run the semi space tests on llinterp (may happen before) - have a moving gc correct version of the gc framework transformation - delegate finding type stuff like vtables etc to GC, cleaner interface for rtti, simplify translator/c/gc.py - think about approaches to id, especially concerning boehm, where the id will keep the object alive and concerning a moving GC - clean up the tangle of including headers in the C backend - review pdbplus, especially the graph commands, also in the light of https://codespeak.net/issue/pypy-dev/issue303 and the fact that we can have more than one translator/annotator around (with the timeshifter) - Kill half concrete wrapper - Kill opaque hacks on the C backend - decide how to implement constants in rffi - think about/remove orphaned parts - finish ll2ctypes, especially rffi_platform Interpreter +++++++++++ - there's a shadow tracking bug it seems - fix the taint space - review the things implemented at applevel whether they are performance-critical JIT +++ - start writing real unit tests for the merging logic Location -------- The sprint will be held in the apartment of Laura Creighton and Jacob Hall?n which is at G?tabergsgatan 22 in Gothenburg, Sweden. Here is a map_. This is in central Gothenburg. It is between the tram_ stops of Vasaplatsen and Valand, where many lines call. .. _tram: http://www.vasttrafik.se .. _map: http://gulasidorna.eniro.se/query?stq=0&streetname=G%F6tabergsgatan+22%2C+G%F6teborg&what=map&asearch=1 Probably cheapest and not too far away is to book accomodation at `SGS Veckobostader`_. There are also hotels to suit every price range and desire for luxury. Just ask in the mailing list. .. _`SGS Veckobostader`: http://www.sgsveckobostader.com Registration ------------ If you'd like to come, please subscribe to the `pypy-sprint mailing list`_ and drop a note about your interests and post any questions. More organisational information will be send to that list. We'll keep a list of `people`_ which we'll update (which you can do so yourself if you have codespeak commit rights). .. _`pypy-sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint .. _`people`: http://codespeak.net/pypy/extradoc/sprintinfo/gothenburg-2007/people.html