Mailman 3 March 2006 - pypy-dev

Re: [pypy-svn] r24500 - pypy/dist/pypy/doc/weekly
by Michael Hudson 17 Mar '06

17 Mar '06

mwh(a)codespeak.net writes: > Author: mwh > Date: Fri Mar 17 01:37:26 2006 > New Revision: 24500 > > Modified: > pypy/dist/pypy/doc/weekly/summary-2006-03-15.txt > Log: > pypy-c _finally_ built, so add some (not too good) performance numbers. > > looking at the c source reveals that the inlining is not as thorough as we > might have liked for a sort of "haha" reason: direct_calls in 'finally' > cleanups are not inlined (presumably 'except' cleanups have the same problem). > > maybe it should be an except block and a cleanup block, or something. So it's late and I should be in bed and so on, but this 'cleanup' thing is getting really horrible. So here's how I think it should work: a SpaceOperation that can raise an exception has a *Link* to a Block that should be taken when an error is raised. Then things can be inlined into these blocks, it's natural to chain the blocks to replicate the falling through of error labels in the old genc code, there are (hopefully) fewer special cases and so on. I think the 'finally' operations should just go after the operation. To avoid getting into trouble with c_last_exception cases, code that cares should search back through the block's operations to find one with a cleanup link (if finally operations can raise, we're already in trouble). Thoughts? I have another train ride tomorrow when I might be able to play with this. Cheers, mwh -- The rapid establishment of social ties, even of a fleeting nature, advance not only that goal but its standing in the uberconscious mesh of communal psychic, subjective, and algorithmic interbeing. But I fear I'm restating the obvious. -- Will Ware, comp.lang.python

1 0

Re: [pypy-svn] r24466 - in pypy/dist/pypy/rpython/memory: . test
by Christian Tismer 16 Mar '06

16 Mar '06

cfbolz(a)codespeak.net wrote: > Author: cfbolz > Date: Thu Mar 16 15:02:22 2006 > New Revision: 24466 > > Modified: > pypy/dist/pypy/rpython/memory/gctransform.py > pypy/dist/pypy/rpython/memory/test/test_gctransform.py > Log: > fix the quite broken gc_(un)protect code: 1) > * raise NotImplementedError in the base class, since (un)protect does not > make sense for most gcs 2) > * make sure that the new operation introduced by replace_gc_(un)protect has > the same result variable as the replaced operation. Otherwise we will end > up with graphs that are missing a variable. I agree that 2) is needed, although I don't understand it really, 'cause I thought the result of the operation would be never used. But I don't agree on 1). Maybe I need to learn more about garbage collectors. Are you saying that there exist GCs where I cannot protect an object? It the operation is not necessary because the object will survive anyway, then it is perfectly fine. If you have a compacting GC, the protect operation makes very much sense, too, but needs a different implementation of course. After all, I agree that raising NotImplemented is right, because itreally would need to be implemented. Still I can't see how it "does not make sense for most GCs". It makes sense for those which I know and use. -- Christian Tismer :^) <mailto:tismer@stackless.com> 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/

2 1

Re: [pypy-svn] r24473 - in pypy/dist/pypy: interpreter module/stackless
by Christian Tismer 16 Mar '06

16 Mar '06

ac(a)codespeak.net wrote: > Author: ac > Date: Thu Mar 16 16:04:11 2006 > New Revision: 24473 > > Modified: > pypy/dist/pypy/interpreter/executioncontext.py > pypy/dist/pypy/module/stackless/coroutine.py > Log: > (pedronis, arre) Make a single point of creation for framestacks. > Fixed subcontext_switch. > Don't store initially a framestack in AppCoroutine for the main coroutine. Thank you very much for this change. It is much better now, also smaller and more elegant. On the code I checked in: hmm, I must have done some wrong revert, but the new code didn't work anyway, because I didn't know the stack trick. The thing I was not aware of was the dependency of the point where we create the stack. This gave my annotation problems. thanks again - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> 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/

1 0

annotation problem
by Christian Tismer 16 Mar '06

16 Mar '06

Howdy, I wanted to get the executioncontext stuff ready for coroutines, but I can't get things to annotate. For some reason, it thinks my Stack() is a SomeObject. It would nice if someone could have a look. I have no clue what it could be, ASFAICT I made it very clear to the annotator that there is always a stack. see executioncontext subcontext_new I think this check-in is anyway ok since it should compile if --stackless is not given. -- Christian Tismer :^) <mailto:tismer@stackless.com> 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/

3 3

small problem with return values
by Christian Tismer 16 Mar '06

16 Mar '06

Hi friends, today I stumbled over a tiny problem. I'm actually not sure how to fix it, so here it is: When we annotate a function in a way that it does not return a value, but we happen to use its return value, this case is not caught early, but very late in backend_optimizations. An example is here: http://codespeak.net:/svn/user/tismer/test_wrapping.py See line 77, where we call something that has no return value: def call_destructor(thing): ll_call_destructor(thing) # <<========== if you use return here # then we crash in backend_optimizations The ll_call_destructor call is actually mapped this way: extregistry.register_value(ll_call_destructor, compute_result_annotation=annmodel.s_None, specialize_call=rtype_destruct_object) and the rtype function is this: def rtype_destruct_object(hop): v_any, = hop.inputargs(hop.args_r[0]) return hop.genop('gc_unprotect', [v_any], resulttype=lltype.Void) As you can see, the rtype func returns lltype.Void, nothing. I think the backend_optimization does a cleanup and removes the unused return variable from the ll function's graph, but then it is required because we return this value. Question: should we silently ignore this case, or raise an exception? It would need a more exact check that we don't pass variables around which are really Void. ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> 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/

4 5

Re: [pypy-svn] r24486 - pypy/extradoc/minute
by Aurélien Campéas 16 Mar '06

16 Mar '06

On Thu, 2006-03-16 at 17:52 +0100, mwh(a)codespeak.net wrote: > Author: mwh > Date: Thu Mar 16 17:52:42 2006 > New Revision: 24486 > > Added: > pypy/extradoc/minute/pypy-sync-2006-03-16.txt (contents, props changed) > Log: > minutes of today's meeting > > > Added: pypy/extradoc/minute/pypy-sync-2006-03-16.txt > ============================================================================== > --- (empty file) > +++ pypy/extradoc/minute/pypy-sync-2006-03-16.txt Thu Mar 16 17:52:42 2006 > @@ -0,0 +1,128 @@ > +============================================= > +pypy-sync developer meeting 16th March 2006 > +============================================= > + > + > +Attendees: Samuele > + Anders C. who's this last one ? > + [16:10] auc: .... this guy ?

2 1

pypy-sync developer meeting 16th March 2006
by Michael Hudson 16 Mar '06

16 Mar '06

Attendees: Samuele Anders C. Anders L. (arrived late) Carl Friedrich Michael (minutes) Nik Eric Summary ======= - activity reports (LAST WEEK/NEXT WEEK/BLOCKERS) See `the log`_ below. - leysin sprint details See the mail to pypy-dev, etc. As this is an internal only sprint somewhere we've been before, organization is not expected to be a major chore. - this "week" in pypy We would like to resurrect the 'this week in pypy newsletter', but probably with a reduced, and maybe less regular, frequency. We have one almost ready to go, but it depends on Armin writing a JIT section and finishing up the PyCon sprint report. .. _`the log`: Complete Log ============ Complete IRC log:: [16:09] mwh: hello [16:09] arigo: :-) [16:09] nikh: hola [16:09] ericvrp: :) summertime in england? [16:09] mwh: am i still supposed to be running the meeting [16:09] cfbolz: yes [16:09] mwh: ericvrp: no, i'm just at my parents' house, different distractions than normal ... [16:10] mwh: right, activity reports please [16:10] cfbolz: LAST: logic sprint, GC work [16:10] cfbolz: NEXT: more GC work [16:10] cfbolz: BLOCKERS: personal issues [16:10] arigo: LAST: not much (setting up new laptop) [16:10] arigo: NEXT: JIT: virtual structures, more general thinking... [16:10] arigo: BLOCKERS: whiteness of the landscape [16:10] arre: PREV: Bug hunting, improve performance of attribute access, some JIT work. [16:10] arre: NEXT: More JIT. [16:10] arre: BLOCKERS: - [16:10] ericvrp: LAST: pyllvm setup script [16:10] ericvrp: NEXT: pyllvm setup using llvm build tools [16:10] ericvrp: BLOCKERS: None [16:10] nikh: LAST: pushing gensqueak ahead [16:10] nikh: NEXT: more pushing and pulling [16:10] nikh: BLOCKERS: none [16:10] auc: last : big cleanup [16:10] auc: next : figure out how to implement 'choice' with spaces [16:10] auc: blockers : nil [16:10] pedronis: LAST: sprint, bug hunting, some opt and jit work, helping others [16:10] pedronis: NEXT: more jit, more helping [16:10] pedronis: BLOCKERS: a bit hard to focus [16:11] mwh: LAST: GC debugging [16:11] mwh: NEXT: more of same [16:11] mwh: BLOCKERS: personal issues too [16:11] mwh: i think arigo has the best blockers [16:11] mwh: pedronis: does strakt have minders who can drag him back to gtbg? [16:12] cfbolz: let's produce some global warming, that will fix the problem [16:12] pedronis: I think Strakt has at least one person that would like to join him [16:12] arre: We do have snow, just not much of it :( [16:12] mwh: pedronis: is your 'a bit hard to focus' because all and sundry keep bugging you for help? [16:13] pedronis: yes, there's a lot of stuff going on on all front [16:13] mwh: i don't suppose there's much that can be done about that [16:13] cfbolz: well, we can try to bug him less [16:13] pedronis: no, just pointing it out as a fact [16:14] mwh: having armin around more might shift some of the load off [16:14] mwh: fair enough [16:14] mwh: what else was on the agenda? [16:14] mwh: leysin seems to be happening [16:14] mwh: given that it's internal and we've been there before it shouldn't be the biggest of deals [16:15] arigo: yes, I can confidently say "feel free to bug me about it" and not expect too much to happen [16:16] nikh: what's the deadline for registering for leysin? i will be there 2 - 3 days, but don't know which yet [16:16] mwh: i guess the only potential issue is accomodation [16:16] mwh: do we have a block booking or something/ [16:16] mwh: ? [16:16] arigo: yes, there is a common booking [16:16] arigo: there is no fixed deadline [16:16] mwh: cool [16:17] nikh: good. i will try to fix dates beginning next week [16:17] arigo: I will send to the housekeeper, Arianne, the people's information as they come along [16:17] mwh: the other topic is 'this "week" in pypy' [16:17] mwh: we'd like to resurrect it, but probably not actually weekly [16:18] arre: arigo: What information do you need from us? [16:19] arigo: dates, and possibly if you'd agree to share with more than two for a couple of days (week-end days) in case of booking pressure [16:19] arigo: mwh: monthly, or fromtimetotimely ? [16:19] cfbolz: the latter probably [16:19] mwh: arigo: fortnightly, maybe ? [16:20] mwh: but perhaps not fixed [16:20] mwh: arigo: fwiw, i have no problem with sharing with whoever [16:21] cfbolz: anyway the point for having this "this week..." topic is to ask people to write about stuff [16:21] arigo: there is also an extra bed at the place where I am staying, which I'd like to reserve for a non-funded person [16:21] nikh: given that sprints are coming up pretty regularly, maybe the sprint reports could be combined with a report about what happened in the weeks before a sprint [16:21] cfbolz: armin told me he would write a bit about the jit [16:22] arigo: yes, I should do that as a way to come back to the topic [16:22] arigo: until tomorrow [16:22] cfbolz: nikh: well, I would like to keep the sprint report separate [16:23] nikh: sure [16:23] cfbolz: ah, I see what you mean [16:24] nikh: it would imply a certain fixed schedule for the "this week in ..." reports [16:24] cfbolz: yes [16:24] cfbolz: but on the other hand, "this week" could complement the sprint reports [16:24] cfbolz: and it should be a bit more common than sprints [16:24] aleale joined the chat room. [16:26] mwh: aleale: i guess you know you're late, but do you have an activity report? [16:27] aleale: yes, sorry about that - you are not finished yet [16:27] mwh: not quite :) [16:27] mwh: it started late because i forgot too ... [16:27] aleale: PREV: recovering from back to back sprinting [16:27] aleale: NEXT: continue refactoring of pyontology [16:27] aleale: blockers: - [16:29] mwh: but it's now nearly half past, any other topics? [16:29] mwh: otherwise: expect to be bugged about this week in pypy [16:29] mwh: and see you next week! -- <glyph> It's just like a method call, but ON FIRE AND UPSIDE DOWN!!! -- from Twisted.Quotes

1 0

Leysin sprint confirmed
by Armin Rigo 16 Mar '06

16 Mar '06

Hi all, This is a quick mail sent over a reaaaaally bad wireless connexion to confirm the dates of the upcoming Leysin sprint: 3-9 April. I will set things up correctly tomorrow, when (if?) I figure out why my wireless card is behaving so erratically. The venue will be the same chalet as the January 2005 sprint. It would be helpful to know kind-of-soon how many people are there for the accomodation. A bientot, Armin

1 1

#pypy-sync tomorrow -- new US friendlier time!
by Michael Hudson 15 Mar '06

15 Mar '06

what: weekly pypy-sync meeting where: #pypy-sync on freenode when: 5pm Central European Time <--- THIS IS NEW who: all active PyPy developers topics: - activity reports (LAST WEEK/NEXT WEEK/BLOCKERS) - resolve blockers, if any - leysin sprint details - this "week" in pypy - anything else? email first, if possible Cheers, mwh -- I never realized it before, but having looked that over I'm certain I'd rather have my eyes burned out by zombies with flaming dung sticks than work on a conscientious Unicode regex engine. -- Tim Peters, 3 Dec 1998

1 0

logic/oz sprint report
by Nicolas Chauvat 15 Mar '06

15 Mar '06

Hello, You will find the sprint report at: http://codespeak.net/pypy/extradoc/sprintinfo/louvain-la-neuve-2006/report.… or below: Sprint Report Louvain-La-Neuve 6-10/3/2006 ========================================== Achievements ------------ The main achievements of the sprint are : * wrapper of GECODE constraint-solving library * workshop about functionnalities of the PyPy/Python and Oz languages * microthreads and dataflow variables in Logic ObjectSpace * draft of a standard mechanism to express search problems in Python Sprint participants ------------------- Ludovic Aubry, Aurélien Campéas, Nicolas Chauvat, Alexandre Fayolle, Anders Lehmann, Grégoire Dooms, Samuele Pedroni, Carl Friedrich Bolz, Raphaël Collet. Workshop participants --------------------- Sprinters + Roel Wuyts, Peter Van Roy, Kevin Glynn, Luis Quesada, Boris Mejias, Jean-Noël Monette, Pierre Schaus Before workshop --------------- Monday and Tuesday where spent sharing information about what had been implemented, discussing what could be implemented and looking at existing implementations. This is what the planning was like: * identify parts of the current logic module that can be usefully implemented in RPython * take a look at existing logic programming software and think about integration (pychinko_ and Rete_ algorithm or CWM_ for forward-chaining, GECODE_ library for constraint-solving, tableau, pylog_ for backward-chaining, Python Cookbook recipes, etc.) * existing Python syntax/new syntax: look at and update existing document in pypy's svn * consistency for multi-paradigm programming languages (especially Python). Oz_ has consistent semantics and offers many different programming paradigms (object, functionnal, constraint, distributed, secure, dataflow, etc.) References that we looked at are: * the Rete_ algorithm, an efficient algorithm_ for rule-based systems * CWM_, a rule-based system written in Python by Tim Berners-Lee * pychinko_, a Python implementation of RETE * pylog_, an implementation of prolog in python that compiles prolog source code to Python functions * a Python cookbook recipe_ that lets one add arbitrary infix binary operators * a simple Prolog implementation using continuations_ to implement backtracking search * `linear programming`_ with nice syntactic sugar via operator overloading * candygram_, erlang style message-based communication and concurrency in Python * discussing extending python with `futures/promises`_ * two_ python recipes_ that analyse and transform the bytecode of a function to interpret it as a set of facts and rules .. _GECODE: http://www.gecode.org/ .. _Rete: http://en.wikipedia.org/wiki/Rete .. _algorithm: http://drools.org/Rete .. _CWM: http://infomesh.net/2001/cwm/ .. _pychinko: http://www.mindswap.org/~katz/pychinko/ .. _pylog: http://christophe.delord.free.fr/en/pylog/ .. _recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/384122 .. _continuations: http://www.ps.uni-sb.de/~duchier/python/continuations.html .. _`linear programming`: http://www.jeannot.org/~js/code/index.en.html .. _candygram: http://candygram.sourceforge.net/ .. _`futures/promises`: http://lists.logilab.org/pipermail/python-logic/2005-August/000112.html .. _two: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/360698 .. _recipes: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303057 .. _Oz: http://www.mozart-oz.org/ Workshop -------- * presentation of pypy architecture * presentation of current implementation of a constraint store in python * presentation of soul/smalltalk language symbiosis * presentation of dataflow paradigm and basic mechanisms After the workshop ------------------ Samuele and Carl implemented a logic object space with microthreads and logic variables. See dist/pypy/objspace/logic.py Nicolas, Raphaël and Aurélien discussed a design for a generic computation space similar to Oz's object space that could run searches expressed as a constraint problem or as a rule-set. Ludovic, Alexandre and Grégoire wrapped the GECODE library. See dist/pypy/lib/logic/gecode_wrapper Alexandre and Anders used PyPy to compile the constraints before running the search and gained a nice speedup. -- Nicolas Chauvat logilab.fr - services en informatique avancée et gestion de connaissances

3 2