From: Zach Shaftel <zshaftel@gmail.com>
To: Helmut Eller <eller.helmut@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: GSoC project - Improving ELisp Traceback and Debugging Information
Date: Sat, 06 Jun 2020 14:20:46 -0400 [thread overview]
Message-ID: <878sh0rr7m.fsf@gmail.com> (raw)
In-Reply-To: <m2a71iov31.fsf@gmail.com>
> 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
https://github.com/SwiftLawnGnome/emacs-gsoc/tree/feature/soc-bytecode-in-traceback-specbinding
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
https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00444.html
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
logic.
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.
-Zach
next prev parent reply other threads:[~2020-06-06 18:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-03 21:42 GSoC project - Improving ELisp Traceback and Debugging Information Zach Shaftel
2020-06-05 7:00 ` Helmut Eller
2020-06-06 18:20 ` Zach Shaftel [this message]
2020-06-06 19:56 ` Helmut Eller
2020-06-06 23:18 ` Zach Shaftel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878sh0rr7m.fsf@gmail.com \
--to=zshaftel@gmail.com \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).