[Patches] [ python-Patches-401022 ] Removal of SET_LINENO (experimental)
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 04 Aug 2002 14:55:08 -0700
Patches item #401022, was opened at 2000-07-30 18:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=401022&group_id=5470
Category: Core (C code)
Group: None
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Vladimir Marangozov (marangoz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Removal of SET_LINENO (experimental)
Initial Comment:
----------------------------------------------------------------------
>Comment By: Skip Montanaro (montanaro)
Date: 2002-08-04 16:55
Message:
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...
----------------------------------------------------------------------
Comment By: Skip Montanaro (montanaro)
Date: 2002-08-04 16:42
Message:
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...
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 16:04
Message:
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
----------------------------------------------------------------------
Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 15:50
Message:
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?
----------------------------------------------------------------------
Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-07 12:41
Message:
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. :-)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-11-27 15:54
Message:
Logged In: YES
user_id=31435
Unassigned again -- I'm not gonna get to this in this
lifetime.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-10 13:51
Message:
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...
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-13 13:42
Message:
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.
----------------------------------------------------------------------
Comment By: Vladimir Marangozov (marangoz)
Date: 2000-10-27 06:08
Message:
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.
----------------------------------------------------------------------
Comment By: Vladimir Marangozov (marangoz)
Date: 2000-10-25 19:42
Message:
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 :)
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-25 15:56
Message:
Vladimir, are you there?
The patch doesn't apply cleanly to the current CVS tree any more...
----------------------------------------------------------------------
Comment By: Vladimir Marangozov (marangoz)
Date: 2000-08-03 14:22
Message:
Fix missing DECREF on error condition in start_tracing()
+ some renaming.
----------------------------------------------------------------------
Comment By: Vladimir Marangozov (marangoz)
Date: 2000-07-31 12:50
Message:
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.
----------------------------------------------------------------------
Comment By: Vladimir Marangozov (marangoz)
Date: 2000-07-31 09:57
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2000-07-31 08:40
Message:
Status set to postponed to indicate that this is still experimental.
----------------------------------------------------------------------
Comment By: Vladimir Marangozov (marangoz)
Date: 2000-07-30 20:16
Message:
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.
----------------------------------------------------------------------
Comment By: Vladimir Marangozov (marangoz)
Date: 2000-07-30 18:12
Message:
For testing, as discussed on python-dev. For a gentle summary, see:
http://www.python.org/pipermail/python-dev/2000-July/014364.html
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=401022&group_id=5470