Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects]

[Stefan Monnier]

>> "More precise line numbers" is a misconstruction, even though I've used
>> such language myself in the past.  Line numbers don't come from a
>> physical instrument which measures with, say +-1% accuracy.  CORRECT
>> line (and column) numbers are what we need.
> A bytecode offset is exact and accurate.

I think he was talking about line-number info in byte-compiler warnings
(where the info comes from the source code, not from the backtrace).
Currently we use a hack that gives us approximate locations which can be
wildly off-the-mark.

> Right now this information unavailable. I think the interpreter uses
> C pointers stored in a register.  So just recording the bytecode
> offset is a little bit of a slowdown, but not that much.

Indeed.  If it's too high we could make it conditional on a boolean
variable.

> I doubt it would even register as %1 slower.

Reminds me that another project could be to try and speed up function
calls.  The difficulty here is that we don't really know what's the main
source of the cost, so there's a good chance that any specific attempt
will give disappointing results.  It'd still be useful in helping us
getting a better idea of what it is that takes time.

> But just that would open the way for improvements. This is doable by a
> Summer student - Stefan thinks it trivial.

Just recording this info in the backtrace (at a minor performance cost)
is indeed very easy.

> But tas you point out there is overhead in getting it accepted and
> into GNU Emacs.

Right.  Until this info is actually usable by tools like the debugger,
the code would inevitably be #ifdef'd out unless it has zero-cost which
seems unlikely.

> Having access to the bytecode offset in a traceback there next are
> several options.  At the lowest level there is just showing that along
> with a disassembly of the bytecode.
> And that I believe that is also doable by a summer student.

Agreed.


        Stefan