Re: GSoC project - Improving ELisp Traceback and Debugging Information

[Helmut Eller <eller.helmut@gmail.com>]

On Wed, Jun 03 2020, Zach Shaftel wrote:

> Hello all,
>
> This summer I will be working on improving ELisp traceback information
> for Google Summer of Code.

Sounds very useful.

> So far I've modified the byte-code interpreter to simply store the
> offset of each funcall in the backtrace specbinding frame, and 
> modified backtrace.el so the sequence of offsets is printed alongside
> each respective call in the backtrace. It's available on the
> feature/soc-bytecode-in-traceback-specbinding branch on
> Savannah.

I don't see this branch on Savannah; there's a
feature/soc-bytecode-in-traceback from 2020-04-27, but apparently
doesn't contain all this.  Anyway, just wanted to say, that it would
nice if bytecode to bytecode calls would not leave the exec_byte_code
function.  Those calls should push the necessary frames and continue the
interpreter loop.  That way the bytecoe PC doesn't need to be saved
redundantly on the C stack and the specbinding stack.

> I've been looking at the scratch/accurate-warning-pos branch as well
> as prior discussions and am still evaluating different approaches to
> solving the task. It might be necessary to modify the way code is
> represented during compilation, be it simply with the annotated
> symbols as in that branch or with another more generalized form of
> object representation.

Instead of annotating symbols I would annotate cons cells.  The reader
could keep a hash table on the side an record the source position of
cons cells.

Helmut