From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: The poor quality of Emacs's backtraces Date: Fri, 14 Jul 2023 10:48:59 +0000 Message-ID: References: <3D901B62-4826-4783-B684-968E6890E75A@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26954"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 14 12:49:24 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qKGMW-0006lO-7h for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Jul 2023 12:49:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKGMF-0002tM-IA; Fri, 14 Jul 2023 06:49:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKGME-0002tD-5S for emacs-devel@gnu.org; Fri, 14 Jul 2023 06:49:06 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKGMB-0005aG-Pt for emacs-devel@gnu.org; Fri, 14 Jul 2023 06:49:05 -0400 Original-Received: (qmail 99451 invoked by uid 3782); 14 Jul 2023 12:48:59 +0200 Original-Received: from acm.muc.de (p4fe159b6.dip0.t-ipconnect.de [79.225.89.182]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 14 Jul 2023 12:48:59 +0200 Original-Received: (qmail 1995 invoked by uid 1000); 14 Jul 2023 10:48:59 -0000 Content-Disposition: inline In-Reply-To: <3D901B62-4826-4783-B684-968E6890E75A@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307863 Archived-At: Hello, Mattias. On Thu, Jul 13, 2023 at 16:57:52 +0200, Mattias Engdegård wrote: > 13 juli 2023 kl. 15.35 skrev Alan Mackenzie : > > (wrong-type-argument listp > > #[257 "\300\211\2!\262\1\207" [yes-or-no-p] 4 > > "\n\n(fn ARG124 &optional)" t]) > > So, this says that _something_ wasn't a list, without telling me what the > > something was. > Actually it does. It's the element after the type, in this case the > byte-compiled function #[257 ...]. You haven't grasped my point. It doesn't tell me which variable had or which evaluation resulted in that invalid value. It just prints out the value, leaving me to guess what, exactly, had that value. Such "guessing" can take hours or days. > > It says "wrong-type-argument", but doesn't say why it's wrong. It > > doesn't disclose which primitive detected the fault, though Emacs could > > easily do this. > Usually it's the topmost function in the traceback. > If not, please report it as a bug. There's certainly work to be done. I found the bug, eventually. I'd written (nth 5 byte-code) where what I needed was (aref byte-code 5). If the message had included the information "nth" in it, I would have found the bug quickly. > > test suite truncating every line at ~70 characters. (Why is this done?) > I agree, that's annoying. We have to truncate at some point or we'll > be treated to dumps of impractical size before we know it, but 70 > chars is pretty useless. > > (The symbols in braces are an enhancement I'm currently working on to give > > more information for anonymous functions.) > Keep us in touch, because it's very likely that some of us are working > on the same code, with similar but different goals. Don't go it alone. You're working on something similar, too? My enhancement is to store the @dfn{defining symbol} of anonymous functions inside the function, whether an interpreted function, or either type of compiled function. This symbol is the defun/defmacro etc. within which the lambda is defined. It's approaching the point at which it would be sensible to create a new branch for it and commit the changes to it. > > It's worth pointing out that there doesn't seem to be a way to get Emacs > > to disassemble a function, only a symbol with a function value. > Actually there is. Just use the function `disassemble`: > (disassemble #[257 "\300\211\2!\262\1\207" [yes-or-no-p] 4 "\n\n(fn ARG124 &optional)" t]) Ah! Thanks! -- Alan Mackenzie (Nuremberg, Germany).