Status set to postponed to indicate that this is still experimental.

Vladimir, are you there?

The patch doesn't apply cleanly to the current CVS tree any more...

Rejected. It's in the archives for reference, but for now, I don't think it's worth spending cycles worrying about this kind of stuff.  I'll eventually redesign the entire VM.

For testing, as discussed on python-dev. For a gentle summary, see:
http://www.python.org/pipermail/python-dev/2000-July/014364.html

A nit: inline the argfetch in CALL_TRACE and goto the switch,
instead of jumping to get_oparg which splits the sequence
[fetch opcode, fetch oparg] -- this can slow things down.

Another rewrite, making this whole strategy b/w compatible according to
the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html

Changes:

1. f.f_lineno is computed and updated on f_lineno attribute requests for
   f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated
   on *all* attribute accesses (in LOAD_ATTR in the main loop).

2. The standard setup does not generate SET_LINENO, but uses
   co_lnotab for computing the source line number (e.g. tracebacks)
   This is equivalent to the actual "python -O".

3. With "python -d", we fall back to the current version of the
   interpreter (with SET_LINENO) thus making it easy to test whether
   this patch fully replaces SET_LINENO's behavior.
   (modulo f->f_lineno accesses from legacy C code, but this is insane).

IMO, this version already worths the pain to be truly tested and improved.

One improvement is to define a nicer public C API for breakpoints:
 - PyCode_SetBreakPointAtLine(line)
 - PyCode_SetBreakPointAtAddr(addr)
or similar, which would install a CALL_TRACE opcode in the appropriate
location of the copy of co_code.

Another idea is to avoid duplicating the entire co_code just for storing
the CALL_TRACE opcodes. We can store them in the original and keep
a table of breakpoints. Setting the breakpoints would occur whenever
the sys.settrace hook is set.

A last tiny fix of the SET_LINENO opcode for better b/w compatibility.
Stopping here and entering standby mode for reactions & feedback.

PS: the last idea about not duplicating co_code and tweaking the
original with CALL_TRACE is a bad one. I remember Guido being
against it because co_code could be used elsewhere (copied, written
to disk, whatever) and he's right! Better operate on an internal copy
created in ceval.

Fix missing DECREF on error condition in start_tracing()
+ some renaming.

noreply@sourceforge.net wrote:
>
> Date: 2000-Oct-25 13:56
> By: gvanrossum
> 
> Comment:
> Vladimir, are you there?

So-so :) I'm a moving target, checking my mail occasionally these days.
Luckily, today is one of these days.

> 
> The patch doesn't apply cleanly to the current CVS tree any more...

Ah, this one's easy. Here's an update relative to 2.0 final, not CVS.
I got some r/w access error trying to update my CVS copy from SF
that I have no time to investigate right now... The Web interface still
works though :)

Oops, the last patch update does not contain the f.f_lineno
computation in frame_getattr. This is necessary, cf. the
following messages:
http://www.python.org/pipermail/python-dev/2000-July/014395.html
http://www.python.org/pipermail/python-dev/2000-July/014401.html

Patch assigned to Guido, for review or further assignment.

Logged In: YES 
user_id=6380

Tim wants to revisit this. It could be the quickest way to a
7% speedup in pystone that we can think of...

Logged In: YES 
user_id=31435

Unassigned again -- I'm not gonna get to this in this 
lifetime.

Logged In: YES 
user_id=35752

I worked a bit on porting to this patch to 2.2+ CVS.  I
ran into a snag with generators.  Generators save the
instruction pointer (i.e. the bytecode offset) on yield.
That makes the on-the-fly bytecode translation approach
more complicated.

Since Guido is going to redesign the whole VM it's probably
not work spending any more effort on this. :-)

Logged In: YES 
user_id=31392

Just in case Guido doesn't get to that VM redesign next 
week, do you want to upload whatever progress you made?

Logged In: YES 
user_id=31392

The URL of the day for Vladimir's explanation of how the
patch works is here:

http://mail.python.org/pipermail/python-dev/2000-July/007652.html

Logged In: YES 
user_id=44345

Michael Hudson's no SET_LINENO patch seems to be nearing completion 
& this one's been marked "out of date" with no assignee, so I'm closing it...

Logged In: YES 
user_id=44345

Michael Hudson's no SET_LINENO patch seems to be nearing completion 
& this one's been marked "out of date" with no assignee, so I'm closing it...