SET_LINENO killer

[mwhudson]

BPO	587993
Nosy	@mwhudson, @gvanrossum, @tim-one, @loewis, @arigo, @nascheme
Files	setlineno-7.diff: another update! setlineno-8.diff: update 2002-08-15 setlineno-fixup-1.diff: first fixup attempt setlineno-fixup-2.diff: fixup 2

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/mwhudson'
closed_at = <Date 2002-11-27.09:44:01.000>
created_at = <Date 2002-07-29.11:27:43.000>
labels = ['interpreter-core']
title = 'SET_LINENO killer'
updated_at = <Date 2002-11-27.09:44:01.000>
user = 'https://github.com/mwhudson'

bugs.python.org fields:

activity = <Date 2002-11-27.09:44:01.000>
actor = 'mwh'
assignee = 'mwh'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2002-07-29.11:27:43.000>
creator = 'mwh'
dependencies = []
files = ['4453', '4454', '4455', '4456']
hgrepos = []
issue_num = 587993
keywords = ['patch']
message_count = 47.0
messages = ['40679', '40680', '40681', '40682', '40683', '40684', '40685', '40686', '40687', '40688', '40689', '40690', '40691', '40692', '40693', '40694', '40695', '40696', '40697', '40698', '40699', '40700', '40701', '40702', '40703', '40704', '40705', '40706', '40707', '40708', '40709', '40710', '40711', '40712', '40713', '40714', '40715', '40716', '40717', '40718', '40719', '40720', '40721', '40722', '40723', '40724', '40725']
nosy_count = 8.0
nosy_names = ['mwh', 'gvanrossum', 'tim.peters', 'loewis', 'nnorwitz', 'arigo', 'nascheme', 'niemeyer']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue587993'
versions = ['Python 2.3']

[mwhudson]

This patch is a proof-of-concept of another way to
remove the SET_LINENO patch (as opposed to Vladimir's
ancient one).

Instead of rewriting bytecode (ick!) we poke into the
c_lnotab to see if we've moved onto a different line.

The c_lnotab is not the most transparent of data
structures, it has to be said.

I'm not sure this patch is 100% correct -- but I think
the idea can definitely fly. There will be some more
overhead to tracing than before, but I hope not too
much. I haven't tested these aspects.

Comments welcome!

[nascheme]

Logged In: YES
user_id=35752

Moving the "int io, instr_ub = -1, instr_lb = 0;"
declaration and the
"io = INSTR_OFFSET();"| statement below the "if
(tstate-c_tracefunc ...)"
test gives a small speedup on my machine and is a little
neater, IMHO.

I was worried that this would slow down "python -O". That
doesn't seem to
be the case (at least I can't measure it). Well done.

[mwhudson]

Logged In: YES
user_id=6656

Uhh, the instr_[lu]b variables need to keep their values
around the loop; otherwise we might just as well call
PyCode_Addr2Line each time around.

I have another version of the patch that does that, but I
assumed the overhead of doing so was deemed too high, or
someone else would have done this by now. It's certainly
easier.

Glad to hear it doesn't affect python -O too much. I was
doing this away from the internet and forgot to keep a clean
copy of the source around for doing comparisons with...

[tim-one]

Logged In: YES
user_id=31435

Dropping out of "vacation mode" long enough to say "mondo
cool!" and encourage this. Guido may not agree, but I also
encourage you to redefine c_lnotab if it can make life easier
and quicker here. That subtle compression scheme has
been the source of several nasty bugs, both in the core C
code and in Jeremy's compiler pkg (cut 'n paste bugs
abound here, because few people understand what's really
needed, so flawed code gets copied with little thought).

[mwhudson]

Logged In: YES
user_id=6656

I worked out why some of the code in ceval.c wasn't making
sense to me -- it didn't make sense, period.

I've also fixed a number of silly and not so silly bugs in
my patch. I'm now 99% certain this idea can fly. The patch
isn't *finished* but the hard bit is done, IMHO.

There are some other points to make, but I think I'll raise
them on python-dev.

[mwhudson]

Logged In: YES
user_id=6656

Guido should see this, assuming he still isn't subscribed to
patches@python.org.

[gvanrossum]

Logged In: YES
user_id=6380

Cool idea, but I get "unknown opcode" errors... Keep me
posted though! (I wil ll now see any changes to this patch
item.)

[gvanrossum]

Logged In: YES
user_id=6380

Never mind the errors, I hadn't done a cvs update in weeks
on the machine where I tested it. :-(

[mwhudson]

Logged In: YES
user_id=6656

Yeah, the obvious response to that was "delete your .pycs"...

Right, I'm going to upload my latest, and hopefully final
patch in three bits.

First, I'm attaching the "interesting" patch. This touches:

Objects/frameobject.c -- adds f_lineno descr
Python/ceval.c -- the obvious
Python/compile.c -- don't emit SET_LINENO
Lib/dis.py -- use c_lnotab for line numbers
Tools/scripts/trace.py -- ditto

This is the most subtle patch, and the one that I'd most
like review on.