Well, we have the permission to host stackless at hg.python.org.  The question 
is just how.
It will be a new project and the question is whether we should try to recreate 
the svn history in hg, (complicated, apparently) or just start afresh with a 
clear slate and a few branches.

As for Nagare:
At pycon, we were sprinting on adding picking for (vanilla) python's built in 
iterators.  This would reduce the diff between Stackless and CPython.
We have a clone of hg.python.org/cpython sitting at 
http://nagare.org:8000/cpython and this is the repository that we used to 
synchronize our work.
It's just a temporary one, for this particular code sprint.

K


From: [email protected] [mailto:[email protected]] 
On Behalf Of Jeff Senn
Sent: 29. mars 2011 14:01
To: The Stackless Python Mailing List
Subject: Re: [Stackless] Me Bad Re: Stackless sprint at PyCon

So what is the plan for a source repository for stackless? (now that python 
proper is moving/has moved to hg.python.org<http://hg.python.org>)

K, you mentioned Nagare.... is there one in the Nagare repos somewhere?  Is 
that going to be "official"?  Should this:
http://zope.stackless.com/svn/sdocument_view  get updated?


On Mar 29, 2011, at 9:44 AM, Kristján Valur Jónsson wrote:


I just uploaded my most recent changes.  I think we have all of the iterators 
covered in cpython now, apart from "generators"
Please take a look.
The next step is to get this stuff into cpython proper, I´ll start the process 
for that.

K

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Kristján Valur Jónsson
Sent: 23. mars 2011 09:16
To: The Stackless Python Mailing List
Cc: Andrew Francis
Subject: Re: [Stackless] Me Bad Re: Stackless sprint at PyCon

I'm doing some review and cleanup of your contributions and uploading it back 
to the nagare HG host.
I think all of you did a great job getting your hands dirty with the C python 
api, but there are still some reference counting errors (mostly leaks) in there 
and also potential crash cases with some of the __setstate__ things.  Mostly we 
have to be vigilant in error checking so that unpicling bad data cannot crash 
the interpreter.+

Cheers,

K
 ...

_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless

Reply via email to