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:[EMAIL PROTECTED]>
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/



_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to