Mailman 3 January 2006 - pypy-dev

we passed the interim EU review!
by hpk＠trillke.net Jan. 21, 2006

Jan. 21, 2006

Hey folks, in case you didn't hear about it already: yesterday the EU reviewers accepted the results and our general direction of the PyPy project! Cheers to everyone who helped to make this happen ... the last two months have involved some of us quite intensively on preparing reports and the review. Here are some more remarks from my side. First, i think that everybody from our presenting group performed really well. Second, the reviwers were also well prepared and had read our reports … [View More]to some detail with specific questions to technical and non-technical topics. It was was a very interesting and intense session. Apart from accepting our results they provided 5-8 recommendations which we will receive as a report within a month. I am thankful that our Project Officer picked reviewers who really seem to have an interest in our project. It helped tremendously to meet for a rehearsal the day before the actual Review day. Basically we improved all of our talks and thus could present a coherent view of the project. This review was an interim review so there was not too much emphasis on financial aspects of the projects - although some questions were put forward there as well. As to the revision ideas regarding our EU work plan, i guess that they were well received. We presented the idea to work towards a separate RPython compiler that could be used more independently from translating PyPy itself. Also the Summer of PyPy idea got some support (although not as official feedback) and we will have to see now how/if we can put this to work. Regarding the JIT compiler it seems possible that we postpone a release (planned for May at the moment) to a later date. We have to discuss at project levels now how/if we want to tackle the revision ideas. Basically the EU wants us to meet our objectives and allows freedom on the means and plans to meet those objectives. Again, i got the impression that it is too easy to just blame the EU and its adminstration for problems that occur within a funded project. During the last two months i have met several such people and without exception they were very reasonable people - and one has to consider that they organise the spending billions of Euros and are confronted with some partners and organisations simply wanting to get the most money with spending the least effort - if not outright attempts at cheating. Anyway, sometimes it may also be our own organisational issues that delay things or make them more complicated. so far, feel free to ask any more questions, i am sure others can chime in as well and add their impressions ... cheers, holger P.S.: this is a cross-posting, when replying you may select only the developers or the consortium mailing list as appropriate. [View Less]

1 0

RE: [pypy-dev] idea for Summer of PyPy - call for feedback (multimethods, actually)
by Drumheller, Michael Jan. 20, 2006

Jan. 20, 2006

>>> -----Original Message----- >>> From: Aurelien Campeas [mailto:aurelien.campeas@logilab.fr] >>> Sent: Wednesday, January 18, 2006 8:33 AM >>> To: pypy-dev(a)codespeak.net >>> Subject: Re: [pypy-dev] idea for Summer of PyPy - call for feedback >>> It still does not seem to really support multiple dispatch >>> (only the funky "predicative" dispatch). David Mertz's own >>> multimethods.py is more complete than that. … [View More]

3 3

Re: [pypy-dev] idea for Summer of PyPy - call for feedback
by Aurélien Campéas Jan. 19, 2006

Jan. 19, 2006

Le mercredi 18 janvier 2006 à 10:23 -0500, Matt Revelle a écrit : > Hi Aurélien, > PEAK's dispatch provides generic function support for Python. > More info here: http://www-128.ibm.com/developerworks/library/l-cppeak2/ Thanks for the link. It still does not seem to really support multiple dispatch (only the funky "predicative" dispatch). David Mertz's own multimethods.py is more complete than that. Whatever. None of them is complete. I'm told there that it is not really something … [View More]

2 2

idea for Summer of PyPy - call for feedback
by hpk＠trillke.net Jan. 18, 2006

Jan. 18, 2006

Hey folks, while many of us are gearing up for the EU review end next week (we should sent our last reports in, puh!) there is an idea where i'd enjoy your feedback on. We'd like to propose to the EU that we can fund a Summer of PyPy (modelled after Google's Summer of Code last year) which would roughly work like this: - all students can send in proposals for roughly two-months projects that leverage PyPy in some way - e.g. in areas like new backends or frontends, optimisations, … [View More]

7 7

Re: [pypy-dev] idea for Summer of PyPy - call for feedback
by Matt Revelle Jan. 16, 2006

Jan. 16, 2006

Hi Holger, Sure thing. =) On 1/16/06, holger krekel <hpk(a)trillke.net> wrote: > Hey Matt, > > On Mon, Jan 16, 2006 at 09:42 -0500, Matt Revelle wrote: > > Hi Holger, > > It might be better to see if a second Summer of Code is going to occur > > and to be one of the listed projects. I'm curious about how many > > students would be interested in and capable of writing code for PyPy. > > The program sounds like fun, though. > > The thing with … [View More]summer-of-code is: we could not easily fund > the sprint attendances and also we might not be able > to push 6-10 proposals through although they could be > interesting ... > > cheers, > > holger > > P.S.: are you ok with cross-posting our conversation > to pypy-dev? I think it's interesting for > everyone ... i have heard this comment a number > of times before :) > > > > On 1/16/06, holger krekel <hpk(a)trillke.net> wrote: > > > Hey again, > > > > > > so right after this mail was sent out there was a > > > codespeak downtime lasting 12 hours. > > > > > > Anyway, let me clarify that this mail was not addressed > > > to the core PyPy developers (who endorse the idea already) > > > but to everybody else so please speak up if you are interested > > > or have comments regarding the idea. Hum, or should we > > > post to comp.lang.python? > > > > > > you can of course also mail me privately - it doesn't mean > > > that you have to guarantee to propose something later. > > > > > > cheers, > > > > > > holger > > > > > > > > > On Sat, Jan 14, 2006 at 21:31 +0100, holger krekel wrote: > > > > while many of us are gearing up for the EU review end next > > > > week (we should sent our last reports in, puh!) > > > > there is an idea where i'd enjoy your feedback on. > > > > > > > > We'd like to propose to the EU that we can fund > > > > a Summer of PyPy (modelled after Google's Summer of Code > > > > last year) which would roughly work like this: > > > > > > > > - all students can send in proposals for roughly two-months > > > > projects that leverage PyPy in some way - e.g. in areas like > > > > new backends or frontends, optimisations, new fun > > > > tools, security, distributed systems, logical programming, > > > > whatever. > > > > > > > > - 6-10 people get accepted from a board of experts > > > > and everyone gets a personal mentor > > > > > > > > - you would be invited to the PyPy Post-EuroPython sprint > > > > which serves as a kickoff meeting > > > > > > > > - two months implementation time > > > > > > > > - participants are invited to another closing-off sprint > > > > > > > > - results get reviewed if they achieved the goals > > > > if so: a sum of 3000-4000 euro is payed flat > > > > > > > > This is the rough idea - no guarantee it will work this > > > > exact way or any way at all :) > > > > > > > > So what do you think about this whole idea? > > > > > > > > And would you personally consider wanting to participate? > > > > Are you not a student and would like to participate anyway? > > > > > > > > Summer of PyPy would involve a noticeable organisational > > > > effort on our side so it's good to have an idea how much > > > > interest there might be. > > > > > > > > thanks & cheers, > > > > > > > > holger > > > > _______________________________________________ > > > > pypy-dev(a)codespeak.net > > > > http://codespeak.net/mailman/listinfo/pypy-dev > > > > > > > _______________________________________________ > > > pypy-dev(a)codespeak.net > > > http://codespeak.net/mailman/listinfo/pypy-dev > > > > > > [View Less]

1 0

Fw: [pypy-dev] Re: [pypy-svn] r22006 - in pypy/dist/pypy/translator/c: . src test
by Ben.Young＠risk.sungard.com Jan. 12, 2006

Jan. 12, 2006

Cool. That was very quick! This malloc removal stuff is looking really good! Does it also mean (if it works) that the inlining threshold can be reduced a bit as part of the reason it needs to be high is to allow the current malloc removal to work? This could reduce the codebase size by rather a lot. Cheers, Ben Eric van Riet Paap <eric(a)vanrietpaap.nl> wrote on 12/01/2006 09:49:38: > Hi Ben, > > Thank you for that info. I've added some preprocessor stuff to handle > … [View More]this windows case. I hope the test/test_lladdresses.py tests pass on > windows too now. > Using _malloca (together with _freea) is something we have to think > about. Mostly because currently is all to easy to exhaust stackspace > anyway. > > cheers > Eric > > > On Jan 12, 2006, at 10:41 AM, Ben.Young(a)risk.sungard.com wrote: > > > Hi Eric, > > > > Just to let you know that on Windows, alloca is spelt _alloca. In > > later > > versions the preferred version is _malloca, which needs to be > > matched by a > > _freea, as _malloca can allocate on the heap if the object is too > > large. > > > > Cheers, > > Ben > > > > pypy-svn-bounces(a)codespeak.net wrote on 12/01/2006 09:31:21: > > > >> Author: ericvrp > >> Date: Thu Jan 12 10:31:20 2006 > >> New Revision: 22006 > >> > >> Modified: > >> pypy/dist/pypy/translator/c/funcgen.py > >> pypy/dist/pypy/translator/c/src/address.h > >> pypy/dist/pypy/translator/c/test/test_lladdresses.py > >> Log: > >> Added genc support of stack flavored_malloc > >> > >> > >> Modified: pypy/dist/pypy/translator/c/funcgen.py > >> > > ====================================================================== > > ======== > >> --- pypy/dist/pypy/translator/c/funcgen.py (original) > >> +++ pypy/dist/pypy/translator/c/funcgen.py Thu Jan 12 10:31:20 2006 > >> @@ -568,6 +568,8 @@ > >> flavor = op.args[0].value > >> if flavor == "raw": > >> return "OP_RAW_MALLOC(%s, %s, %s);" % (esize, > >> eresult, err) > > > >> + elif flavor == "stack": > >> + return "OP_STACK_MALLOC(%s, %s, %s);" % (esize, eresult, > > err) > >> else: > >> raise NotImplementedError > >> > >> > >> Modified: pypy/dist/pypy/translator/c/src/address.h > >> > > ====================================================================== > > ======== > >> --- pypy/dist/pypy/translator/c/src/address.h (original) > >> +++ pypy/dist/pypy/translator/c/src/address.h Thu Jan 12 > >> 10:31:20 2006 > >> @@ -20,5 +20,9 @@ > >> r = (void*) malloc(size); \ > >> if (r == NULL) FAIL_EXCEPTION(err, PyExc_MemoryError, "out of > > memory");\ > >> > >> +#define OP_STACK_MALLOC(size,r,err) \ > >> + r = (void*) alloca(size); \ > >> + if (r == NULL) FAIL_EXCEPTION(err, PyExc_MemoryError, "out of > > memory");\ > >> + > >> #define OP_RAW_FREE(x,r,err) free(x); > >> #define OP_RAW_MEMCOPY(x,y,size,r,err) memcpy(y,x,size); > >> > >> Modified: pypy/dist/pypy/translator/c/test/test_lladdresses.py > >> > > ====================================================================== > > ======== > >> --- pypy/dist/pypy/translator/c/test/test_lladdresses.py (original) > >> +++ pypy/dist/pypy/translator/c/test/test_lladdresses.py Thu Jan > >> 12 10:31:20 2006 > >> @@ -88,7 +88,7 @@ > >> res = fc() > >> assert res == int('011100' * 2, 2) > >> > >> -def test_flavored_malloc(): > >> +def test_flavored_malloc_raw(): > >> class A(object): > >> _alloc_flavor_ = "raw" > >> def __init__(self, val): > >> @@ -100,3 +100,15 @@ > >> return result > >> fn = compile(f, [int]) > >> assert fn(1) == 2 > >> + > >> +def test_flavored_malloc_stack(): > >> + class A(object): > >> + _alloc_flavor_ = "stack" > >> + def __init__(self, val): > >> + self.val = val > >> + def f(x): > >> + a = A(x + 1) > >> + result = a.val > >> + return result > >> + fn = compile(f, [int]) > >> + assert fn(1) == 2 > >> _______________________________________________ > >> pypy-svn mailing list > >> pypy-svn(a)codespeak.net > >> http://codespeak.net/mailman/listinfo/pypy-svn > >> > > > > _______________________________________________ > > pypy-dev(a)codespeak.net > > http://codespeak.net/mailman/listinfo/pypy-dev > > [View Less]

2 1

Re: [pypy-svn] r22006 - in pypy/dist/pypy/translator/c: . src test
by Ben.Young＠risk.sungard.com Jan. 12, 2006

Jan. 12, 2006

Hi Eric, Just to let you know that on Windows, alloca is spelt _alloca. In later versions the preferred version is _malloca, which needs to be matched by a _freea, as _malloca can allocate on the heap if the object is too large. Cheers, Ben pypy-svn-bounces(a)codespeak.net wrote on 12/01/2006 09:31:21: > Author: ericvrp > Date: Thu Jan 12 10:31:20 2006 > New Revision: 22006 > > Modified: > pypy/dist/pypy/translator/c/funcgen.py > pypy/dist/pypy/translator/c/src/… [View More]address.h > pypy/dist/pypy/translator/c/test/test_lladdresses.py > Log: > Added genc support of stack flavored_malloc > > > Modified: pypy/dist/pypy/translator/c/funcgen.py > ============================================================================== > --- pypy/dist/pypy/translator/c/funcgen.py (original) > +++ pypy/dist/pypy/translator/c/funcgen.py Thu Jan 12 10:31:20 2006 > @@ -568,6 +568,8 @@ > flavor = op.args[0].value > if flavor == "raw": > return "OP_RAW_MALLOC(%s, %s, %s);" % (esize, eresult, err) > + elif flavor == "stack": > + return "OP_STACK_MALLOC(%s, %s, %s);" % (esize, eresult, err) > else: > raise NotImplementedError > > > Modified: pypy/dist/pypy/translator/c/src/address.h > ============================================================================== > --- pypy/dist/pypy/translator/c/src/address.h (original) > +++ pypy/dist/pypy/translator/c/src/address.h Thu Jan 12 10:31:20 2006 > @@ -20,5 +20,9 @@ > r = (void*) malloc(size); \ > if (r == NULL) FAIL_EXCEPTION(err, PyExc_MemoryError, "out of memory");\ > > +#define OP_STACK_MALLOC(size,r,err) \ > + r = (void*) alloca(size); \ > + if (r == NULL) FAIL_EXCEPTION(err, PyExc_MemoryError, "out of memory");\ > + > #define OP_RAW_FREE(x,r,err) free(x); > #define OP_RAW_MEMCOPY(x,y,size,r,err) memcpy(y,x,size); > > Modified: pypy/dist/pypy/translator/c/test/test_lladdresses.py > ============================================================================== > --- pypy/dist/pypy/translator/c/test/test_lladdresses.py (original) > +++ pypy/dist/pypy/translator/c/test/test_lladdresses.py Thu Jan > 12 10:31:20 2006 > @@ -88,7 +88,7 @@ > res = fc() > assert res == int('011100' * 2, 2) > > -def test_flavored_malloc(): > +def test_flavored_malloc_raw(): > class A(object): > _alloc_flavor_ = "raw" > def __init__(self, val): > @@ -100,3 +100,15 @@ > return result > fn = compile(f, [int]) > assert fn(1) == 2 > + > +def test_flavored_malloc_stack(): > + class A(object): > + _alloc_flavor_ = "stack" > + def __init__(self, val): > + self.val = val > + def f(x): > + a = A(x + 1) > + result = a.val > + return result > + fn = compile(f, [int]) > + assert fn(1) == 2 > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn > [View Less]

1 0

next pypy-sync meeting
by Carl Friedrich Bolz Jan. 12, 2006

Jan. 12, 2006

Hi pypy-devers! You are hereby invited to tomorrow's pypy-sync meeting Time & location: 1.00 - 1.30 pm (GMT+1) at #pypy-sync Regular Topics ==================== - activity reports (3 prepared lines of info, LAST/NEXT/BLOCKERS). - resolve conflicts/blockers Annotated Topics of the week ================================= logic programming and aspect orient programming in PyPy -------------------------------------------------------- Logilab and DFKI are going to work on integrating … [View More]

1 0

New branch for performance experiments.
by Anders Chrigström Jan. 11, 2006

Jan. 11, 2006

I'm creating the branch ssh://codespeak.net/svn/pypy/branch/arre-experiments to use for experimenting with performance. The first of these will be trying to refactor the usage of the Arguments objects so that fewer objects get created when it is used. This is a part of the work to get creation of applevel user-defined objects go faster. /Arre

1 0

at some point we will experiment with issues of security, persistence & distribution
by Samuele Pedroni Jan. 9, 2006

Jan. 9, 2006

this talk by Gilad Bracha: Objects as Software Services, An invited talk at the Dynamic Language Symposium at OOPSLA 2005. ( http://www.bracha.org/oopsla05-dls-talk.pdf ) is an interesting across-the-sprectum take on these or related issues. At least it makes for some interesting thinking. regards.

2 2