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.bugs Subject: bug#61847: debug-early-backtrace only works some of the time. Date: Wed, 1 Mar 2023 15:22:29 +0000 Message-ID: References: <83v8jkfz04.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16455"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 01 16:23:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pXOIf-000417-5Q for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 Mar 2023 16:23:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pXOIN-0007kl-Q2; Wed, 01 Mar 2023 10:23:07 -0500 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 1pXOIL-0007kP-Kt for bug-gnu-emacs@gnu.org; Wed, 01 Mar 2023 10:23:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pXOII-0000rk-NT for bug-gnu-emacs@gnu.org; Wed, 01 Mar 2023 10:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pXOII-0005V4-7f for bug-gnu-emacs@gnu.org; Wed, 01 Mar 2023 10:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Mar 2023 15:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61847 X-GNU-PR-Package: emacs Original-Received: via spool by 61847-submit@debbugs.gnu.org id=B61847.167768415821088 (code B ref 61847); Wed, 01 Mar 2023 15:23:02 +0000 Original-Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 15:22:38 +0000 Original-Received: from localhost ([127.0.0.1]:54581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOHt-0005U4-Vm for submit@debbugs.gnu.org; Wed, 01 Mar 2023 10:22:38 -0500 Original-Received: from mx3.muc.de ([193.149.48.5]:11124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOHr-0005Tq-R8 for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 10:22:36 -0500 Original-Received: (qmail 41771 invoked by uid 3782); 1 Mar 2023 16:22:30 +0100 Original-Received: from acm.muc.de (pd953ac29.dip0.t-ipconnect.de [217.83.172.41]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 01 Mar 2023 16:22:29 +0100 Original-Received: (qmail 25611 invoked by uid 1000); 1 Mar 2023 15:22:29 -0000 Content-Disposition: inline In-Reply-To: <83v8jkfz04.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:257070 Archived-At: Hello, Eli. On Wed, Mar 01, 2023 at 14:16:11 +0200, Eli Zaretskii wrote: > > Cc: 61847@debbugs.gnu.org > > Date: Tue, 28 Feb 2023 19:52:33 +0000 > > From: Alan Mackenzie > > The lack of output for compiled functions with cl-prin1 condemns it. All > > that appears is "#f(compiled-function)" together with an empty pair of > > parentheses and a meaningless hex address. What use is any of that in > > debugging a batch mode bug? > And what use is the meaningless stream of raw bytes that prin1 > produces? If that were indeed what was produced, none at all. Because debug-early-backtrace binds print-escape-control-characters to t, what actually gets produced is a mixture of ascii characters and octal escaped representations, just like you see when an .elc file is visited in Emacs. > > prin1 by contrast prints the actual contents of the function - its byte > > code string and its constant vector, among other things. > And with some of the bytes interpreted by the terminal, it is _really_ > useful. To say nothing of attempting to post it in a bug report, > where it can ruin the entire email message. See above. > I think you should re-evaluate your preferences, and base them on real > advantages and disadvantages, not on imaginary ones. What makes you think I'm not doing this already? I wrote debug-early last year because I _needed_ it. I've a lot of experience using it, and the way it prints (or rather used to print) a compiled function is/was useful. You can see how many arguments it takes. You can see the byte code string, hence enabling you to compare it visually with the contents of a .elc file, should such already exist. You can see the constant vector. You get an idea of how big the function is. All these things are helpful when you want to find out which particular lambda form is in the backtrace. Again, I'm talking from experience, not imagined benefits. > If we want our backtraces to be more informative, not less, we should > move farther away of "dumb" output functions that just spill the guts > and towards more humanly-readable formatted description of the called > functions. A wholesome long term goal I fully agree with. For the here and now, outputting "#f(compiled-function () " and nothing else is not a step in that direction. > IOW, make cl-prin1 smarter and teach it doing _more_ and do it > _better_, not less and worse. For example, how about a more detailed, > but human-readable description of bytecode? You mean a disassembly? That's an idea, but it would be very bulky in a backtrace, and hinder the visual comparison with the putatively same byte code in a .elc buffer in Emacs. A backtrace I got the other evening was already 126 MB big. Besides, the idea of debug-early is to generate a backtrace before all the fancy Lisp facilities are available. -- Alan Mackenzie (Nuremberg, Germany).