emacs-devel
[Top][All Lists]
Advanced

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

Re: Update 1 on Bytecode Offset tracking


From: Zach Shaftel
Subject: Re: Update 1 on Bytecode Offset tracking
Date: Thu, 16 Jul 2020 20:24:40 -0400
User-agent: mu4e 1.4.10; emacs 28.0.50

Hi Andrea,

Andrea Corallo <akrl@sdf.org> writes:

> Hi Zach and Rocky,
>
> IMO having the exact offset for all functions in the stack except the
> last is already a measurable improvement.  Reevaluating the top function
> and rerunning is not a huge deal, reevaluating N functions and rerunning
> each time trying to figure out what is going wrong and where on the
> contrary can be considerably more painful.

Absolutely, and since this deficiency arises when errors are signalled
from byte ops other than `Bcall`, many backtraces still present accurate
offsets top to bottom.

> Zach Shaftel <zshaftel@gmail.com> writes:
>
>> With respect to reporting offsets, using code from edebug we have a
>> Lisp-Expression reader that will track source-code locations and
>> store the information in a source-map-expression cl-struct. The code
>> in progress is here.
>>
>> Information currently saved is:
>>
>>     The expression itself
>>     The exact string that was read
>>     Begin and end point​s of the sexp in the buffer
>>     source-map-expression children (for conses and vectors)
>>
>> which can be generated for a whole lisp file with the function
>> source-map-file. We are testing this on lots of files such as the
>> lisp files in the GNU Emacs distribution. After this is done we will
>> try hooking this into the compilation process.
>
> Regarding the reader I fear modifying the C one will be the only way if
> we want to have something sufficiently high performance to be used as
> default.

I suspect you're right that processing and saving this information in
Lisp won't be fast enough to maintain reasonable compilation time.
Perhaps it could be made available as an option, in the form of
alternate byte-compile functions for example, but that would be an
unfortunate compromise. Down the line, perhaps the native compiler could
change that.

> That said having one to begin with experimenting is a very
> good start.  I guess we'll want to have the 'children' as key of an hash
> where the rest is the value.

That's the plan!

> Thanks you and Rocky for the effort!
>
>   Andrea




reply via email to

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