[Zope-dev] Re: Zope 2.7 running with Stackless 3.0

[Christian Tismer]

Shane Hathaway wrote:

> Christian Tismer wrote:
> 
>> Stackless 3.0 does all of it, whatever is possible.
>> That means, you can switch whatever, even extension
>> C code with Python callbacks. But cooperative code
>> can switch faster.
> 
> I'm very happy to hear you've forged onward.  I was concerned you had 
> given up.

I never give up. Giving up is for me the equivalent to death.
I'm undead. ;-)

...

>> No continuations, tasklets. :-)
> 
> Did you switch the terminology?  Where can I read about Stackless 3.0?

You will be able to, soon. At the moment, just read help("stackless").
Stackless 3.0 no longer has the primitive, most powerful concept
of continuations, it just has tasklets.
Tasklets are like one-shot continuations, so they are no longer
immutable. In other words, they are like tiny threads.
The reasons for that are multiple. But the main reason is the
hardware switching capability. It is a feature of SLP 3.0.
SLP 2.0 did only this. SLP 3.0 does this, and a subset of the 1.0
continuations, but reduced to a common subset.
With the presence of hardware C stack snapshot, it is not trivially
possible to provide immutable, re-runnable instances of such C stacks.
I only can (almost) guarantee, that they can continue once, after they
have been freezed. This is so, since I was (so far) unable to provide
a platform/compiler independent way to completely analyse them
for the presence of Python objects.
In summary, that means, allowing for C stack captures in a compatible
way kills the concept of pure continuations.
On the other hand, killing the concept of pure continuations allows
me to make C stack snapshots and pure Python frame chains to be
rather compatible. So what I do is to wrap an abject around
both, called a tasklet. And such a tasklet can be run just once,
since it has mutable state.
But this is exactly what peaople want.

> For the uninitiated: Stackless lets a Python program break out of the 
> rigid constraints of a simple stack.  It lets Python code manipulate its 
> own execution.  It provides new solutions to problems like threading, 
> debugging, network communication, etc.  It's a very interesting shift.

This is still true!

> BTW, here's one avenue you might pursue, Christian: Python IDEs.  When I 
> wrote the debugger for Boa Constructor, I hit a big wall.

*You* wrote the Boa debugger? Well, this is great. We need to talk.

> Since Python 
> is a dynamic language, one would expect to be able to pause the 
> execution of a function, change the function, and resume execution with 
> new code--never skipping a beat.  But CPython makes this nearly 
> impossible.  I imagine Stackless would provide an answer for this.  If 
> it does, get in contact with ActiveState, Secret Labs, or the Wing IDE 
> folks and tell them you can make their debugger twice as good as any 
> other.  Just an idea.

A very good idea. Although all of these people know me well,
and I think I don't need to talk so much. Instead, they are kind
of waiting. Actually, they don't need to wait so long, since
SLP 3.0 final is coming in the next three weeks, with a decent
C API.

cheers & thanks -- chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     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 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/