From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Proposal: stack traces with line numbers Date: Sun, 15 Oct 2017 12:01:01 +0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1508061729 6630 195.159.176.226 (15 Oct 2017 10:02:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Oct 2017 10:02:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: John Williams To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 15 12:02:06 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3fk3-0008Ln-Mn for ged-emacs-devel@m.gmane.org; Sun, 15 Oct 2017 12:01:55 +0200 Original-Received: from localhost ([::1]:56669 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3fkB-0000bX-65 for ged-emacs-devel@m.gmane.org; Sun, 15 Oct 2017 06:02:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3fjd-0000bN-Ja for emacs-devel@gnu.org; Sun, 15 Oct 2017 06:01:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3fja-0000Is-E9 for emacs-devel@gnu.org; Sun, 15 Oct 2017 06:01:29 -0400 Original-Received: from [195.159.176.226] (port=46971 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e3fja-0000Ic-6W for emacs-devel@gnu.org; Sun, 15 Oct 2017 06:01:26 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1e3fjG-0002Lt-4f for emacs-devel@gnu.org; Sun, 15 Oct 2017 12:01:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 56 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:5EHpO4MWprbcya7n2LA7/EfH17I= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:219543 Archived-At: 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