[Zope-dev] Zope 2.7 running with Stackless 3.0

[Christian Tismer]

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/