[pypy-dev] pypy-sync thursday 5:30 GMT+2
arigo at tunes.org
Thu Apr 20 13:24:57 CEST 2006
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
> - 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
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.
More information about the Pypy-dev