FAQ
Dear friends,

just by chance, I got into the position to try out
Zope 2.7.0 beta 1/2, and since it needs Python 2.2.3
at least, and Stackless 3.0 was just ported to that, I tried
to build Zope with Stackless 3.0.

It works very very well! After a few patches to get the includes
right, here the installation instructions.

Get the current Stakless 3.0 beta.

CVSROOT=:pserver:anonymous at centera.de:/home/cvs
export CVSROOT

cvs co stackless

cd stackless/src
./configure
make
# su if your weren't root
make install

Then, install the Zope source, and make the same dance as usual.

Just a note:
Zope doesn't (yet) use any of the Stackless features.
It just builds and works with it. But of course, *you*
can use the stackless features, of course.

I also expect, that Zope will create a branch in some future
and implement a new Medusa which doesn't need real threads.

cheers and let me know of your experience -- 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/

Search Discussions

  • Andreas Jung at Aug 28, 2003 at 3:35 am
    What are the benefits of running Zope with Stackless Python?
    Cheers,
    Andreas

    --On Donnerstag, 28. August 2003 1:55 Uhr +0200 Christian Tismer
    wrote:
    Dear friends,

    just by chance, I got into the position to try out
    Zope 2.7.0 beta 1/2, and since it needs Python 2.2.3
    at least, and Stackless 3.0 was just ported to that, I tried
    to build Zope with Stackless 3.0.

    It works very very well! After a few patches to get the includes
    right, here the installation instructions.

    Get the current Stakless 3.0 beta.

    CVSROOT=:pserver:anonymous at centera.de:/home/cvs
    export CVSROOT

    cvs co stackless

    cd stackless/src
    ./configure
    make
    # su if your weren't root
    make install

    Then, install the Zope source, and make the same dance as usual.

    Just a note:
    Zope doesn't (yet) use any of the Stackless features.
    It just builds and works with it. But of course, *you*
    can use the stackless features, of course.

    I also expect, that Zope will create a branch in some future
    and implement a new Medusa which doesn't need real threads.

    cheers and let me know of your experience -- 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/




    _______________________________________________
    Zope-Dev maillist - Zope-Dev at zope.org
    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 )
  • Romain Slootmaekers at Aug 28, 2003 at 8:13 am

    Christian Tismer wrote:
    Dear friends,

    just by chance, I got into the position to try out
    Zope 2.7.0 beta 1/2, and since it needs Python 2.2.3
    at least, and Stackless 3.0 was just ported to that, I tried
    to build Zope with Stackless 3.0.

    It works very very well! After a few patches to get the includes
    right, here the installation instructions.

    Get the current Stakless 3.0 beta.

    CVSROOT=:pserver:anonymous at centera.de:/home/cvs
    export CVSROOT

    cvs co stackless

    cd stackless/src
    ./configure
    make
    # su if your weren't root
    make install

    Then, install the Zope source, and make the same dance as usual.
    This is very, very cool. I've been waiting for this quite a while...

    Romain.
  • Shane Hathaway at Aug 28, 2003 at 12:13 pm

    On 08/27/2003 07:55 PM, Christian Tismer wrote:
    just by chance, I got into the position to try out
    Zope 2.7.0 beta 1/2, and since it needs Python 2.2.3
    at least, and Stackless 3.0 was just ported to that, I tried
    to build Zope with Stackless 3.0.

    It works very very well! After a few patches to get the includes
    right, here the installation instructions.
    I am in awe. Cool. :-)

    However, I am also a little confused. As I understand it, Stackless
    needs all C code to be non-reentrant, i.e. C code must never call back
    into Python. But Zope has a lot of reentrant code, especially in
    Acquisition and ZODB. Doesn't that prevent Zope from taking advantage
    of Stackless continuations?

    Shane
  • Christian Tismer at Aug 28, 2003 at 5:33 pm

    Shane Hathaway wrote:
    On 08/27/2003 07:55 PM, Christian Tismer wrote:

    just by chance, I got into the position to try out
    Zope 2.7.0 beta 1/2, and since it needs Python 2.2.3
    at least, and Stackless 3.0 was just ported to that, I tried
    to build Zope with Stackless 3.0.

    It works very very well! After a few patches to get the includes
    right, here the installation instructions.

    I am in awe. Cool. :-)

    However, I am also a little confused. As I understand it, Stackless
    needs all C code to be non-reentrant, i.e. C code must never call back
    into Python.
    This has never been so. It was so that Stackless 1.0 could
    only do its switching if there was no recursive call, sure.
    But it was always allowed.
    Stackless 2.0 does it the brute-force way, by moving C stacks
    around.
    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.
    But Zope has a lot of reentrant code, especially in
    Acquisition and ZODB. Doesn't that prevent Zope from taking advantage
    of Stackless continuations?
    No continuations, tasklets. :-)

    ciao - 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 pager +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/
  • Shane Hathaway at Aug 28, 2003 at 6:20 pm

    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.
    But Zope has a lot of reentrant code, especially in Acquisition and
    ZODB. Doesn't that prevent Zope from taking advantage of Stackless
    continuations?

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

    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.

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

    Shane
  • Christian Tismer at Aug 29, 2003 at 2:34 am

    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/
  • Christian Tismer at Aug 31, 2003 at 9:38 pm
    Hi Shane,

    BTW, here's one avenue you might pursue, Christian: Python IDEs. When I
    wrote the debugger for Boa Constructor, I hit a big wall. 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.
    I think this is a great idea!

    Btw., Stackless works pretty well with wxPython and Boa.
    I have a commercial application that uses this.

    Since you have written the Boa debugger, can you help
    me what exactly you would need?
    There has been a request to find the function that
    created a frame, recently on the main list.
    Do you think such a feature would make writing
    edit-and-continue simpler, or is it not needed?
    There is that call-trace feature which intercepts
    every code blcok, but you have to guess the function.

    I'd really like to augment Stackless with everything
    that makes it into the ideal platform for IDEs.

    cheers - 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 pager +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/
  • Christian Tismer at Sep 3, 2003 at 11:23 am
    Hi Shane,
    Christian Tismer wrote:
    Since you have written the Boa debugger, can you help
    me what exactly you would need?
    There has been a request to find the function that
    created a frame, recently on the main list.
    Do you think such a feature would make writing
    edit-and-continue simpler, or is it not needed?

    Let me think out loud for a moment:

    The debugging-aware editor tells the debugger that file X, lines M-N,
    have changed, and that the debugger should reload that code before
    continuing. If the debugger can find a loaded module that corresponds
    with that file, the debugger should compile it using the compile()
    builtin, then pull code objects out of the compiled module. The
    debugger should then modify every affected code object in the module.
    Sounds tricky, anyway. If code is changed that logically
    comes before the current line, how to get the locals
    right, or changed scope and such, without re-executing
    the code so far?
    The tricky part is that there's a very good chance the user edited code
    that's on the stack. We can examine the stack, looking for code objects
    that got replaced in the step above. We can identify replaced code
    objects by the co_filename and co_firstline attributes. When we find a
    match, we need to replace the code object on the stack with new code.
    In other words, "frame.f_code = new_code". Now for the super-tricky
    part: we need to set the frame's f_lasti and f_lineno to reasonable
    values.
    I think that's not *that* hard. The debugger would support a
    "set next statement", anyway, and by default we could either
    try to be on the same line (numerically) as before editing,
    or try to do a match on the source code.
    There is alost nothing on the frame stack between lines,
    just some trivial flags in case of conditionals.
    It would be possible to compute the new f_lineno if the editor
    told us exactly which lines were inserted or deleted. Maybe we could
    base f_lasti on f_lineno by searching the bytecode for a specific
    SET_LINENO instruction. We could enhance that with an instruction
    offset computed by examining the original f_lasti and f_lineno. Yes, I
    think that could work, except when the user edits code on the very line
    that is being executed, in which case we should probably give up and
    tell the user that the debugger needs to restart or continue with old code.
    Or, this is at least solvable, somehow.
    So Stackless' role in all of this is essentially the ability to set the
    f_code, f_lineno, and f_lasti attributes of a frame object, or to mimic
    that capability in some way. I'm not sure that anything else is needed.
    I wonder how difficult it would be to patch standard Python to support
    this.
    Supporting this is easy for both Pythons.
    One problem with Standard Python is that
    the C interpreter is using the frame, and some
    variables are local to the C stack. Not so much
    of a problem, we just have to escape the frame,
    modify it, and restart it. This is implemented
    in a limited way for generators, and of course
    this is completey supported by Stackless. Leaving and
    re-entering frames is Stackless' job all the time.

    The need to update a code object that is on the
    frame stack is in fact almost impossible without
    stackless, since all frames on the stack are on the
    C stack as well, and they are not closed. The
    nested interpreters would have to be unwound and
    re-established. This is impossible at the moment,
    or would need a larger patch. This patch exists,
    it has the name Stackless.
    As nother benefit, you can even decide to continue
    debugging tomorrow, and simply pickle your running
    program or even your whole session to the disk.

    ...
    In my previous email, I was suggesting that you talk to one of the IDE
    companies about getting *paid* (either as a contractor or employee) to
    make Stackless the ideal platform for IDEs. :-)
    Now I understand, thanks a lot. I didn't remember that
    those you mentioned were commercial companies.
    I will try to make them interested, of course.

    many 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 pager +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/
  • Michael Geary at Aug 29, 2003 at 12:52 am

    Shane Hathaway wrote:
    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.

    BTW, here's one avenue you might pursue, Christian: Python IDEs. When I
    wrote the debugger for Boa Constructor, I hit a big wall. 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.
    Yes! This would be an outstanding benefit.

    As much as like Python, I *really* miss the Edit and Continue feature from
    Visual C++. It's truly liberating to be able to change my code right in the
    midst of debugging it, with all its state preserved. I often write a
    skeleton for a function, start it up, and then finish coding it while I'm
    running it.

    Even short of that, none of the Python debuggers I've tried support a Set
    Next Statement command like Visual C++ does. That itself is mighty useful.
    Maybe Stackless would make it possible to support this?

    -Mike
  • Christian Tismer at Aug 29, 2003 at 2:42 am
    Michael Geary wrote:

    ...
    As much as like Python, I *really* miss the Edit and Continue feature from
    Visual C++. It's truly liberating to be able to change my code right in the
    midst of debugging it, with all its state preserved. I often write a
    skeleton for a function, start it up, and then finish coding it while I'm
    running it.
    There is the general Python problem, that a running frame does
    not exactly know about its function object. There is only a name
    and a filename available in the code object, and the code object
    is the only thing a frame knows about.
    I think to propose a PEP about this.
    Even short of that, none of the Python debuggers I've tried support a Set
    Next Statement command like Visual C++ does. That itself is mighty useful.
    Maybe Stackless would make it possible to support this?
    In most cases Stackless could do that.
    Given a reliable way to deduce the module/function from a frame
    (see above), it would be possible to edit the function, create
    a new code object, and create a new frame.

    not-a-task-for-this-weekend-anyway -- ly 'yrs - chris

    p.s.: Please Delete.This. - we are all fighting SPAM.

    --
    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/
  • Michael Hudson at Aug 29, 2003 at 9:59 am

    "Michael Geary" <Mike at DeleteThis.Geary.com> writes:

    Even short of that, none of the Python debuggers I've tried support a Set
    Next Statement command like Visual C++ does. That itself is mighty useful.
    Maybe Stackless would make it possible to support this?
    pdb in Python 2.3 has this feature. It has some limitations, but it's
    there.

    Cheers,
    mwh

    --
    If you're talking "useful", I'm not your bot.
    -- Tim Peters, 08 Nov 2001
  • Michael Hudson at Aug 28, 2003 at 5:27 pm

    Shane Hathaway <shane at zope.com> writes:
    On 08/27/2003 07:55 PM, Christian Tismer wrote:
    just by chance, I got into the position to try out
    Zope 2.7.0 beta 1/2, and since it needs Python 2.2.3
    at least, and Stackless 3.0 was just ported to that, I tried
    to build Zope with Stackless 3.0.
    It works very very well! After a few patches to get the includes
    right, here the installation instructions.
    I am in awe. Cool. :-)

    However, I am also a little confused. As I understand it, Stackless
    needs all C code to be non-reentrant, i.e. C code must never call back
    into Python. But Zope has a lot of reentrant code, especially in
    Acquisition and ZODB. Doesn't that prevent Zope from taking advantage
    of Stackless continuations?
    I think this is the magic of stackless 3: it uses assembler to move
    pesky bits of the C stack away in some circumstances.

    Not all C code can safely have this done to it, mind, but most can
    (how often do you take the address of a stack variable and expect it
    to be valid for an extended period of time?).

    Cheers,
    mwh

    --
    This proposal, if accepted, will probably mean a heck of a lot of
    work for somebody. But since I don't want it accepted, I don't
    care. -- Laura Creighton, PEP 666

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedAug 27, '03 at 11:55p
activeSep 3, '03 at 11:23a
posts13
users6
websitepython.org

People

Translate

site design / logo © 2022 Grokbase