From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.bugs Subject: bug#59707: 29.0.50; Seeking a more robust `package-quickstart' Date: Tue, 29 Nov 2022 21:59:56 -0800 Message-ID: <87cz95rnhf.fsf@rfc20.org> References: <87edtlpact.fsf@rfc20.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36055"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59707@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 30 07:01:28 2022 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 1p0G9v-0009Bd-Mb for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Nov 2022 07:01:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0G9Z-0006qS-Ng; Wed, 30 Nov 2022 01:01:05 -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 1p0G9W-0006qE-Mk for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 01:01:02 -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 1p0G9W-0001Y6-EO for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 01:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p0G9W-00022U-3f for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 01:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Matt Armstrong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2022 06:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59707 X-GNU-PR-Package: emacs Original-Received: via spool by 59707-submit@debbugs.gnu.org id=B59707.16697880217823 (code B ref 59707); Wed, 30 Nov 2022 06:01:02 +0000 Original-Received: (at 59707) by debbugs.gnu.org; 30 Nov 2022 06:00:21 +0000 Original-Received: from localhost ([127.0.0.1]:58821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0G8o-000227-3l for submit@debbugs.gnu.org; Wed, 30 Nov 2022 01:00:21 -0500 Original-Received: from relay5-d.mail.gandi.net ([217.70.183.197]:34321) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0G8i-00020r-7M for 59707@debbugs.gnu.org; Wed, 30 Nov 2022 01:00:16 -0500 Original-Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id 9599F1C0003; Wed, 30 Nov 2022 06:00:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1669788005; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tGhD6uYyQBA1vA4lFodYc+bK3vC2eCWaeu03F+YGy3M=; b=jT/lXyInIMGSmPILZnUnvIDsosC5B4Jz5tgwHG4XoIN+d1GNKDnf7ZkvuhS+Trr6Bv4eep eMXuRVwPhkNSiUXHoTADvIwgnNKi42ThdGe50IqB3qKHDuPlfKoLDIXVFTC0cKpl9RVIyy S4AZsi/ABgSsu9qjKWOoHKz/itPwgv5QtykII3E/5Ec550dbIZNTHVQYMbrJvS+TTF9iKw F6EDfGkwLQOb9zWhaPgSBBlEsNwLGtk5SwnPAKAjnbwN3KO6jtlYyAAlJ1fdU43vJ3WGu3 rksFjR5qu9H8ffl3db57z1s/u9lpdfh7BLQJIarAmDYuehpPwjdiN38KLKnx7g== Original-Received: by mac-mini.lan (Postfix) with ESMTPS id A80DD3C9CE; Tue, 29 Nov 2022 21:59:57 -0800 (PST) Original-Received: by naz.lan (Postfix, from userid 1000) id 87C6B43D80B1; Tue, 29 Nov 2022 21:59:57 -0800 (PST) In-Reply-To: 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:249467 Archived-At: Stefan Monnier writes: >> With this, emacs fails to launch, instead printing: >> >> Symbol=E2=80=99s value as variable is void: geiser-active-implementa= tions > > Did `--debug-init` provide a backtrace? --debug-init did nothing insofar as I could tell. Emacs behavior did not observably change. It prints the following to stderr and exits with 255: Symbol=E2=80=99s value as variable is void: geiser-active-implementatio= ns In gdb I end up in a call to Fcommand_error_default_function with SELECTED_FRAME()->glyphs_initialized_p false, so it takes the Fkill_emacs(-1) path. The trace below is easy for me to repro so feel free to ask me to root around. #0 __GI_exit (status=3D-1) at ./stdlib/exit.c:143 #1 0x000055555567ffab in Fkill_emacs (arg=3DPython Exception : value has been optimized out , arg@entry=3Dmake_fixnum(-1), restart=3DXIL(0)) at emacs.c:2916 #2 0x00005555556884f1 in Fcommand_error_default_function (data=3DPython Ex= ception : value has been optimized out , context=3DPython Exception : value has been optimized = out , signal=3DXIL(0x2aaa9b653e40)) at /home/matt/git/e/emacs/src/lisp.h:758 #3 0x0000555555719217 in funcall_subr (subr=3D0x555555dcf620 , numargs=3Dnum= args@entry=3D3, args=3Dargs@entry=3D0x7ffff0dff050) at eval.c:3026 #4 0x0000555555756f03 in exec_byte_code (fun=3DPython Exception : value has been optimized out , fun@entry=3DXIL(0x7ffff18fdfc5), args_template=3Dargs_template@entry=3D77= 1, nargs=3D, nargs@entry=3D3, args=3D,=20 args@entry=3D0x7fffffffda18) at bytecode.c:809 #5 0x0000555555718aa6 in fetch_and_exec_byte_code (fun=3Dfun@entry=3DXIL(0x7ffff18fdfc5), args_template=3D771, nargs=3Dna= rgs@entry=3D3, args=3Dargs@entry=3D0x7fffffffda18) at eval.c:3069 #6 0x000055555571a165 in funcall_lambda (fun=3Dfun@entry=3DXIL(0x7ffff18fdfc5), nargs=3Dnargs@entry=3D3, arg_ve= ctor=3Darg_vector@entry=3D0x7fffffffda18) at eval.c:3141 #7 0x000055555571a593 in funcall_general (fun=3DXIL(0x7ffff18fdfc5), numar= gs=3Dnumargs@entry=3D3, args=3Dargs@entry=3D0x7fffffffda18) at eval.c:2933 #8 0x000055555571707c in Ffuncall (nargs=3Dnargs@entry=3D4, args=3Dargs@en= try=3D0x7fffffffda10) at eval.c:2983 #9 0x0000555555682726 in call3 (fn=3DPython Exception := value has been optimized out , arg1=3DPython Exception : value has been optimized out , arg1@entry=3DXIL(0x555555f74ef3), arg2=3DPython Exception : value has been optimized out , arg3=3DPython Exception : value has been optimized out ) at /home/matt/git/e/emacs/src/lisp.h:3256 #10 0x0000555555689328 in cmd_error_internal (data=3Ddata@entry=3DXIL(0x555= 555f74ef3), context=3Dcontext@entry=3D0x7fffffffda60 "") at keyboard.c:1005 #11 0x000055555568952e in cmd_error (data=3DXIL(0x555555f74ef3)) at keyboar= d.c:973 #12 0x0000555555715df3 in internal_condition_case (bfun=3Dbfun@entry=3D0x55= 55556826c1 , handlers=3DPython Exception : = value has been optimized out , hfun=3Dhfun@entry=3D0x555555689363 ) at eval.c:1470 #13 0x00005555556825a1 in top_level_1 (ignore=3DPython Exception : value has been optimized out , ignore@entry=3DXIL(0)) at keyboard.c:1142 #14 0x0000555555715d43 in internal_catch (tag=3DPython Exception : value has been optimized out , func=3Dfunc@entry=3D0x55555568256b , arg=3DPython Exception = : value has been optimized out , arg@entry=3DXIL(0)) at eval.c:1197 #15 0x00005555556824d7 in command_loop () at keyboard.c:1102 #16 0x0000555555688e10 in recursive_edit_1 () at keyboard.c:712 #17 0x000055555568925c in Frecursive_edit () at keyboard.c:795 #18 0x0000555555681255 in main (argc=3D4, argv=3D) at emacs.= c:2517 Lisp Backtrace: "command-error-default-function" (0xf0dff050) "help-command-error-confusable-suggestions" (0xffffda18) >> The code for `geiser-activate-implementation' was originally: >> >> (defsubst geiser-activate-implementation (impl) >> (add-to-list 'geiser-active-implementations impl)) >> >> So the `(add-to-list 'geiser-active-implementations 'guile)' ended up >> inlined into "package-quickstart.elc", which executed directly, without >> first (auto) loading 'geiser-impl' as was intended. Thus, the >> `geiser-active-implementations' variable did not exist, yet was >> referenced, by inlining, but did not appear textually in >> package-quickstart.el. >> >> Once understood obvious fix to make geiser-activate-implementation a >> defun instead of a defsubst. > > FWIW, that's a rather poor fix, since it causes `geiser-impl.el` (and > the files it requires) to be unconditionally loaded during > Emacs startup. The better fix would be to make sure the > `geiser-active-implementations` itself gets initialized before the calls > to `geiser-activate-implementation`. Yes, I agree that the fix is suboptimal -- it was the smallest diff that made the code do what it clearly intended to do. I'm not sure I like your suggestion to keep using the `geiser-activeate-implementation' function, because I don't think it is because calling functions from "foo" without loading "foo" first is confusing, and works only if they are defsubst (or macros). Is this kind of thing commonly done in autoloads? Seems quite subtle. I'd rather suggest that the gesier package autoloads simply not use the helper function at all. Instead, just have the autoloads defvar `geiser-active-implementations' and call `add-to-list' on it explicitly. Seems simpler and unsurprising. >> Ideas for improvement (also seeking ideas from others) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> 0) Make `package-quickstart t' the default, because it is great, and >> that way people tend to see the same kinds of problems. :-) > > I think it's a good idea to do that on `master`, indeed. Ok. >> 1) Harden Emacs such that signaled errors from "package-quickstart.elc" >> don't prevent startup (but are somehow saved and logged, maybe as >> warnings?). > > Agreed. I suspect it should also do things like delete the `.elc` file > (and/or the `.el` file), or at least suggest doing it, so as to help > diagnose/circumvent the problem. Ok, let's keep it on the list of possibilities. >> 2) Make --debug-init functional for errors thrown by >> "package-quickstart.elc". Currently, package-quickstart is loaded >> before the first frame is initialized, so Emacs takes the "print the >> error and exit" route for any signaled errors, instead of, for example, >> ending up in the elisp debugger. > > In the case of `--debug-init` it could at least print the backtrace on > `stderr`. Or store the backtrace and display it later (even though the > debugger wouldn't be active, it would still be nicer to manipulate than > when sent to stderr). Yes, though see the backtrace above. It isn't very helpful, at least for me, since the bottom of the lisp stack is the current `command-error-function'. Is this because the stack has already been unwound somehow? >> 3) Perhaps package-quickstart.elc could be loaded later in the >> initialization phase, after the first frame is created? > > I'm not in favor of such a change, no. > >> 5) Change "package-quickstart.el" code gen to provide more context for >> errors, perhaps with `condition-case-unless-debug'. The jwigley's >> use-package package does something similar in its macro expansions and >> it is nice. In the specific case with the geiser packages, because >> Emacs exited immediately, it would have been useful to know that the >> error came from the "geiser-guile-autloads" portion of >> "package-quickstart.elc". > > We could probably use `(setq load-file-name ...)` between file chunks > (instead of `let` binding the var) and wrap the whole file with > a `condition-case` which then prints the "current" `load-file-name`. ...adding to the list. :) >> 6) Print a warning when a `defsubst' function is autoloaded, as the >> autoload won't work from byte compiled code. > > It works. It just works differently (it copies the whole `defsubst` > instead of placing an `autoload` statement). AFAIK byte-compiled or > not doesn't make much difference in this respect. Ah, ok. It looks like geiser's autoloads are hand written (and might predate package.el), so an actual autoload for the defsubst ends up in package-quickstart.el. See https://gitlab.com/emacs-geiser/geiser/-/blob/master/elisp/geiser.el#L104 So, there is an extra level of indirection there compared to what presumably a "modern" emacs package would do. Yet, geiser wants to support use directly from downloaded source. What is our current suggestion for packages that want to ship their own pre-canned autoloads? Do you know of a package supporting this without resorting to hand edited autoloads? I assume there is some canonical 'emacs -f batch_blah_blah' but, maybe not?