pypy-sync thursday 5:30 GMT+2
Hi there, the next pypy-sync meeting of active developers is THURSDAY, 20th April, 5:30 PM GMT+2 (30-45 minutes) at #pypy-sync on freenode with the following topics (plus the ones that get mailed ahead of the meeting ): - activity reports + blockers - summer of X, how do we go about it? there are three possibilities: - aim for Summer of PyPy through the EU (becomes unlikely) - aim for becoming an "Summer of Code" organisation - provide mentors and participate at Googles Summer-of-Code through the PSF and try to get a bit of external funding for having participants attend sprints? decision time :) - what needs to be done until Iceland (21st May) for 0.9? Samuele and Holger went through the issue tracker and identified 0.9 release issues in Leysin. But we are missing assignments ... could everyone have a look and take responsibility for resolving particular issues? https://codespeak.net/issue/pypy-dev/ (and hit "Show 0.9"). Of course it is great if you assign yourself already before the sync meeting so we can see what is missing. - tackling and assigning the major 0.9 tasks to be worked on until Iceland: - integrating/refining the new stackless CFG transformations instead of the genc-support - adding missing support (if any) for app level stackless module (e.g. yield_current_frame_to_caller ?) - implementing tasklet pickling - advancing rctypes to support interfacing with CPython runtime through a CPyObjSpace - tackling the actual extension module compiler tool (including testing improvements and writing a tutorial) - overhauling and updating translation documentation (also in preparation for EU reports pending in June) best, holger
Hi all, On Tue, Apr 18, 2006 at 10:37:31AM +0200, holger krekel wrote:
THURSDAY, 20th April, 5:30 PM GMT+2 (30-45 minutes)
Oups, I'm going to miss this pypy-sync...
- activity reports + blockers
LAST: rctypes, which are roughly done by now. NEXT: polish edges, try compiling pypy/module/_demo as a CPython ext mod BLOCKERS: -
- summer of X, how do we go about it? there are three possibilities:
- aim for Summer of PyPy through the EU (becomes unlikely) - aim for becoming an "Summer of Code" organisation - provide mentors and participate at Googles Summer-of-Code through the PSF and try to get a bit of external funding for having participants attend sprints?
decision time :)
I can't judge on the likeliness of various funding models, but at that point I believe (without convincing arguments, though) that just going for the same model as last year is what makes the most sense. Nothing was done on the Summer of PyPy front as far as I can tell. I don't fully see the point of becoming our own Summer of Code organization at this point. I'm also ready to mentor a student, whatever the model.
- what needs to be done until Iceland (21st May) for 0.9?
A possible missing clasification on the issue tracker is the separation between the two goals of that release: one is community-oriented, and the other is to fullfill EU requirements. For the latter, we are mostly done apart from tasklet pickling. This is the one that needs to find a leader *now*. It's a contractual thing. I agree that all other points are very nice and some are rather needed, but we are still allowed to miss one of them, like weakrefs, __subclasses__, or moving gc's... My point is that I would personally like some more focus on new experimental features instead of spending too much time on polishing, making performance more stable, even more compliance, etc. -- I think that's what we really promized to both the community and the EU. I'm not trying to minimize the importance of all that work, which will have to be done sooner or later, but basically we promized many great things so the sooner we show at least experimentally that they are possible, the more interested people will become IMHO. I hope this doesn't sound too negative! It was not my intention. My intention is just to reiterate what I see as the mid-term guidelines that I need to keep in mind.
(...) - adding missing support (if any) for app level stackless module (e.g. yield_current_frame_to_caller ?)
No, this was about the higher-level interfaces -- we cannot expose yield_current_frame_to_caller directly. It's about exposing channels to make tasklets usable, and greenlets. A bientot, Armin
Hi Armin, On Thu, Apr 20, 2006 at 13:24 +0200, Armin Rigo wrote:
On Tue, Apr 18, 2006 at 10:37:31AM +0200, holger krekel wrote:
- what needs to be done until Iceland (21st May) for 0.9?
A possible missing clasification on the issue tracker is the separation between the two goals of that release: one is community-oriented, and the other is to fullfill EU requirements. For the latter, we are mostly done apart from tasklet pickling.
I disagree. We cannot just ship the current svn/pypy/dist and i actually think it's very misleading to give this impression. Getting to 0.9 is more than just a few days work or even (as you somewhat imply apart from tasklet pickling) no work at all. And don't forget the reports for that matter.
This is the one that needs to find a leader *now*. It's a contractual thing. I agree that all other points are very nice and some are rather needed, but we are still allowed to miss one of them, like weakrefs, __subclasses__, or moving gc's...
sure, but it's not that we don't have tons of other stuff waiting for us after 0.9. Generally i think we should be careful if we further postpone issues into the last 7 months of the EU project (where people might get the funny idea to even take holidays) that got already postponed for 5-9 months. but i am fine with missing _some_ of the issues.
My point is that I would personally like some more focus on new experimental features instead of spending too much time on polishing, making performance more stable, even more compliance, etc. -- I think that's what we really promized to both the community and the EU. I'm not trying to minimize the importance of all that work, which will have to be done sooner or later, but basically we promized many great things so the sooner we show at least experimentally that they are possible, the more interested people will become IMHO.
Hum, but especially users of the release ("the community" resp.) will want to get some reasonably stable and entry points for using PyPy (especially the ext-compiler) which requires some polishing and documentation work, doesn't it?
I hope this doesn't sound too negative! It was not my intention. My intention is just to reiterate what I see as the mid-term guidelines that I need to keep in mind.
(...) - adding missing support (if any) for app level stackless module (e.g. yield_current_frame_to_caller ?)
No, this was about the higher-level interfaces -- we cannot expose yield_current_frame_to_caller directly. It's about exposing channels to make tasklets usable, and greenlets.
sure, i didn't mean to expose yield_current_frame_to_caller at app-level but to support it for the stackless (interp-level) module which itself supports tasklets etc. holger
participants (3)
-
Armin Rigo -
holger krekel -
hpk＠trillke.net