all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Rocky Bernstein <rocky@gnu.org>
Cc: Alan Mackenzie <acm@muc.de>, emacs-devel <emacs-devel@gnu.org>
Subject: Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects]
Date: Thu, 19 Mar 2020 18:05:33 -0400	[thread overview]
Message-ID: <jwv1rpoja1t.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CANCp2ga-7bpRJ+7chvxv4QkmG-zpWmdtmRVNuZtm920vsDHQ9Q@mail.gmail.com> (Rocky Bernstein's message of "Thu, 19 Mar 2020 16:56:45 -0400")

>> "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




  reply	other threads:[~2020-03-19 22:05 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-19 15:10 GNU is looking for Google Summer of Code Projects Rocky Bernstein
2020-03-19 17:35 ` Stefan Monnier
2020-03-19 17:56   ` Andrea Corallo
2020-03-19 18:05     ` Andrea Corallo
2020-03-19 18:19     ` Rocky Bernstein
2020-03-19 21:26     ` Stefan Monnier
2020-03-19 21:45       ` Andrea Corallo
2020-03-19 23:07         ` Rocky Bernstein
2020-03-19 20:34   ` Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Alan Mackenzie
2020-03-19 20:43     ` Andrea Corallo
2020-03-20 19:18       ` Alan Mackenzie
2020-03-21 11:22         ` Andrea Corallo
2020-03-21 15:30           ` Correct line/column numbers in byte compiler messages Alan Mackenzie
2020-03-21 16:28             ` Andrea Corallo
2020-03-21 18:37               ` Andrea Corallo
2020-03-21 20:19                 ` Alan Mackenzie
2020-03-21 21:08                   ` Andrea Corallo
2020-03-21 23:39                     ` Andrea Corallo
2020-03-22 11:26                   ` Alan Mackenzie
2020-03-19 20:56     ` Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Rocky Bernstein
2020-03-19 22:05       ` Stefan Monnier [this message]
2020-03-20 19:25       ` Alan Mackenzie
2020-03-19 21:41     ` Stefan Monnier
2020-03-19 22:09       ` Stefan Monnier
2020-03-20 20:10       ` Alan Mackenzie
2020-03-20 21:23         ` Rocky Bernstein
2020-03-20 21:27         ` Clément Pit-Claudel
2020-03-20 23:46           ` Stefan Monnier
2020-03-20 21:30         ` Stefan Monnier

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv1rpoja1t.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=rocky@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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.