unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Helmut Eller <eller.helmut@gmail.com>
To: emacs-devel@gnu.org
Cc: John Williams <jrw@pobox.com>
Subject: Re: Proposal: stack traces with line numbers
Date: Sun, 15 Oct 2017 12:01:01 +0200	[thread overview]
Message-ID: <m2fuakd92a.fsf@caladan> (raw)
In-Reply-To: CAEdRJLD=PROHc59mqK7s6AehoYSY4+bkRUO-uQDJ5_B-xQYpZw@mail.gmail.com

On Sat, Oct 14 2017, John Williams wrote:

> 1. Revise the reader to attach source references (i.e. filename, line
> number, and column number) to forms as they are read.  [...]

This part would be useful not just for backtraces, but also for improved
source positions in compiler messages.  And in general for users who use
the reader without the compiler.

> The information is "attached"
> using cons cells as keys in a weak-key hash table.  [...]

Unless you care about interpreted code, a non-weak hash-table should be
enough.  I think this hash table should work similar to
read-symbol-positions-list.

> - I'm storing the information in vectors because it seems like a
> reasonably efficient use of memory. [...]

It's debatable whether a [file line column] vector is an efficent
representation.  E.g. all lists in a source form come from the same file
(or buffer or string) so storing the same filename many times seems
redundant.  It might also be reasonable to use different representations
in the debug info than for the data-structures used by the reader or
compiler.

> - I'm saving line and column numbers rather that just byte/character
> offsets [...]

Line/column pairs have the (minor) advantage that line numbers have a
higher porbability to stay the same after small edits to the source.
But other than that, it seems to me that character offsets encode the
same information more compactly.

> - I'm only attaching information to the head of each list purely as a
> memory-saving measure. I can't think of scenario where you'd need a
> source reference for a list without having its head available, except
> maybe in the expansion of a macro that disassembles its arguments and
> puts them back together in a new list.  If it's an issue in practice,

In Lisp almost everything is a macro, so I bet that this is an issue.

> I think a better solution would be for the macro expander to propagate
> source refs to every cons cell in a macro argument at the point where
> macro expansion takes place.

It's clearly desirable that source positions are propagated
automatically as often as possible.  That job will be easier if the
reader records more information.

So, I think the reader should, at least optionally, also record
positions of every cons cell not just the first in a list.  Also, in
addition to the start position the reader could/should also record the
end position.

Helmut




  parent reply	other threads:[~2017-10-15 10:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-15  0:17 Proposal: stack traces with line numbers John Williams
2017-10-15  1:54 ` Daniele Nicolodi
2017-10-15  2:42 ` raman
2017-10-15  3:20   ` Noam Postavsky
2017-10-15  3:40 ` Robert Weiner
2017-10-15 10:01 ` Helmut Eller [this message]
2017-10-15 16:20   ` Stefan Monnier
2017-10-16 22:43   ` John Williams
2017-10-17  0:00     ` Helmut Eller
2017-10-18 15:00     ` John Williams
2017-10-16  1:53 ` Richard Stallman
2017-10-16 21:51 ` Wilfred Hughes

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=m2fuakd92a.fsf@caladan \
    --to=eller.helmut@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=jrw@pobox.com \
    /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).