[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC project - Improving ELisp Traceback and Debugging Information

From: Zach Shaftel
Subject: Re: GSoC project - Improving ELisp Traceback and Debugging Information
Date: Sat, 06 Jun 2020 14:20:46 -0400
User-agent: mu4e 1.4.8; emacs 28.0.50

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.

Ah my mistake, Rocky Bernstein had pushed that branch, I'm still waiting to hear back from copyright-clerk@fsf.org so I don't know if I can push
to Savannah just yet. The repo is available at
if you'd like to take a look.

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.

That's an excellent idea. That would make the logic cleaner and should speed up the interpreter to boot. I'll get to work on that right away.

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.

That was also mentioned in this thread
discussing this project. I'll be looking into this option but as Alan Mackenzie mentioned in that thread it might not be plausible, largely due to the sheer number of cons cells created during compilation and
macroexpansion. Keeping that information across all those source
transformations seems nigh impossible without some very convoluted

I'm also not so keen on the symbols approach because it splits symbols into two different types, annotated and bare, which to me just seems unnecessarily complicated. But this could be changed so that it isn't
transparent to the user like it is in that branch.

I'll be looking at how other Lisp compilers record source code
locations. SBCL is what I'm most familiar with but that compiler is very complex, and uses an intermediate code representation during compilation that makes recording this type of information easier. Ideally I would teach the byte compiler to do something as advanced as this as well, but that would probably entail a complete overhaul that wouldn't fit into the span of my project. Perhaps, once the offset is readily available, I could start this undertaking and continue work on it after GSoC ends.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]