GNU bug report logs -
#45854
28.0.50; [feature/native-comp] autoload behavior different in the presence of errors
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45854 in the body.
You can then email your comments to 45854 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Thu, 14 Jan 2021 02:53:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Mauricio Collares <mauricio <at> collares.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 14 Jan 2021 02:53:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The example is a bit convoluted, but it is a reduced example from
another error I saw in the wild. It's not a big problem, but since this
might be a bug I thought a report could be useful. I wish I could reduce
it further, but hopefully this is enough.
Suppose I have three files as below (I've appended an x to the original package
names to avoid conflict):
* File 1: transientx.el
;;; transientx.el --- x -*- lexical-binding: t; -*-
;; Package-Requires: ((emacs "25.1"))
;; Package-Version: 0
(require 'cl-lib)
(require 'eieio)
(defclass transient-suffix () ())
(cl-defmethod transient--init-suffix-key ((obj transient-suffix)))
;; (provide 'transientx) commented on purpose to cause an error when requiring
;;; transientx.el ends here
* File 2: git-commitx.el
;;; git-commitx.el --- x -*- lexical-binding: t; -*-
;; Package-Requires: ((emacs "25.1") (transientx "20200601"))
;; Package-Version: 20210102.1242
(require 'transientx)
;;;###autoload
(define-minor-mode global-git-commit-mode
"desc"
:global t
:initialize (lambda (symbol exp)
(add-hook 'find-file-hook 'git-commit-setup-check-buffer)))
;;;###autoload
(defun git-commit-setup-check-buffer ())
(provide 'git-commitx)
;;; git-commitx.el ends here
* File 3: elpa2nix.el
(require 'package)
(package-initialize)
(defun elpa2nix-install-package ()
(pcase command-line-args-left
(`(,archive)
(with-temp-buffer
(insert-file-contents archive)
(package-unpack (package-buffer-info))))))
Then running the following two commands in order produces the stack
trace below on the native-comp branch:
$ emacs --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package transientx.el
$ emacs --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package git-commitx.el
git-commitx.el:6:1: Error: Loading file /home/collares/.emacs.d/elpa/transientx-0/transientx.elc failed to provide feature ‘transientx’
Done (Total of 0 files compiled, 1 failed, 2 skipped)
Debugger entered--Lisp error: (error "transient--init-suffix-key is already defined as s...")
error("%s is already defined as something else than a gen..." transient--init-suffix-key)
cl-generic-ensure-function(transient--init-suffix-key)
cl-generic-define-method(transient--init-suffix-key nil ((obj transient-suffix)) nil #f(compiled-function (obj) #<bytecode 0x1bd084804d24a6d3>))
require(transientx)
load-with-code-conversion("/home/collares/.emacs.d/elpa/git-commitx-20210102...." "/home/collares/.emacs.d/elpa/git-commitx-20210102...." nil t)
git-commit-setup-check-buffer()
run-hooks(find-file-hook)
after-find-file(nil t)
find-file-noselect-1(#<buffer git-commitx.el> "~/git-commitx.el" nil nil "~/git-commitx.el" (7340496 65025))
find-file-noselect("/home/collares/git-commitx.el")
command-line-1(("-l" "/home/collares/elpa2nix.el" "-f" "elpa2nix-install-package" "/home/collares/git-commitx.el"))
command-line()
normal-top-level()
The transient--init-suffix-key error does not appear on trunk (the
"failed to provide feature" error appears as expected). Reverting commit
7d7bfbf0346114b116e14a4338ea235d12674f13 makes the change of behaviour
disappear, but I suspect it's not the true cause of the difference.
Things that might be relevant: package-native-compile is nil, but when
package-unpack is called on git-commitx.el the (require 'transientx)
causes native compilation to happen. The above stacktrace seems to come
from the "(package--load-files-for-activation new-desc :reload)" call in
package.el's package-unpack.
Let me know if I can provide more information.
Best,
Mauricio
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Thu, 14 Jan 2021 12:02:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 45854 <at> debbugs.gnu.org (full text, mbox):
This might be slightly off-topic (in the sense that the previous message
stands alone and is not corrected by this one) but I have a related
question to ask about the actual error I was hitting. To reproduce the
error, one can use git-commitx.el and elpa2nix.el from the previous
email and the following transientx.el file:
;;; transientx.el --- x -*- lexical-binding: t; -*-
;; Package-Requires: ((emacs "25.1"))
;; Package-Version: 0
(require 'cl-lib)
(require 'eieio)
(defclass transient-suffix () ())
(cl-defmethod transient--init-suffix-key ((obj transient-suffix)))
(advice-add 'top-level :before 'identity)
(provide 'transientx)
;;; transientx.el ends here
That is, the "provide" line is uncommented but there's now an advice-add
call. Running the following commands causes a problem similar to the one
in the previous message:
$ --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package /home/collares/transientx.el
$ --batch -Q --eval "(setq comp-eln-load-path '())" -l ~/elpa2nix.el -f elpa2nix-install-package /home/collares/git-commitx.el
git-commitx.el:6:1: Error: Cannot find suitable directory for output in ‘comp-eln-load-path’
Done (Total of 0 files compiled, 1 failed, 2 skipped)
Debugger entered--Lisp error: (error "transient--init-suffix-key is already defined as s...")
error("%s is already defined as something else than a gen..." transient--init-suffix-key)
cl-generic-ensure-function(transient--init-suffix-key)
Apparently, advice-add caused native compilation to happen, and that
failed because comp-eln-load-path was empty. This error plays a role
similar to the lack of "(provide 'transientx)" in the previous email,
leading to the second error which does not happen in trunk.
In this email, however, I would like to address the first error. My
question is: Is it possible to disable the native compilation caused by
advice-add in the above example? In Nix we run batch-native-compile
separately after installing the package, and comp-eln-load-path is not
set up until that point, so an option to disable all native compilation
for a single batch session would be helpful. I tried setting
comp-deferred-compilation and comp-enable-subr-trampolines to nil but
still got the "Cannot find suitable directory for output in
‘comp-eln-load-path’" error with an empty comp-eln-load-path.
Best,
Mauricio
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Thu, 14 Jan 2021 14:25:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Mauricio Collares <mauricio <at> collares.org> writes:
> This might be slightly off-topic (in the sense that the previous message
> stands alone and is not corrected by this one) but I have a related
> question to ask about the actual error I was hitting. To reproduce the
> error, one can use git-commitx.el and elpa2nix.el from the previous
> email and the following transientx.el file:
>
> ;;; transientx.el --- x -*- lexical-binding: t; -*-
>
> ;; Package-Requires: ((emacs "25.1"))
> ;; Package-Version: 0
>
> (require 'cl-lib)
> (require 'eieio)
>
> (defclass transient-suffix () ())
> (cl-defmethod transient--init-suffix-key ((obj transient-suffix)))
>
> (advice-add 'top-level :before 'identity)
>
> (provide 'transientx)
>
> ;;; transientx.el ends here
>
> That is, the "provide" line is uncommented but there's now an advice-add
> call. Running the following commands causes a problem similar to the one
> in the previous message:
>
> $ --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package /home/collares/transientx.el
> $ --batch -Q --eval "(setq comp-eln-load-path '())" -l ~/elpa2nix.el -f elpa2nix-install-package /home/collares/git-commitx.el
>
> git-commitx.el:6:1: Error: Cannot find suitable directory for output in ‘comp-eln-load-path’
> Done (Total of 0 files compiled, 1 failed, 2 skipped)
> Debugger entered--Lisp error: (error "transient--init-suffix-key is already defined as s...")
> error("%s is already defined as something else than a gen..." transient--init-suffix-key)
> cl-generic-ensure-function(transient--init-suffix-key)
>
> Apparently, advice-add caused native compilation to happen, and that
> failed because comp-eln-load-path was empty. This error plays a role
> similar to the lack of "(provide 'transientx)" in the previous email,
> leading to the second error which does not happen in trunk.
>
> In this email, however, I would like to address the first error. My
> question is: Is it possible to disable the native compilation caused by
> advice-add in the above example?
I think that's a bug, I believe `comp-enable-subr-trampolines' should
cover this case too.
> In Nix we run batch-native-compile
> separately after installing the package, and comp-eln-load-path is not
> set up until that point, so an option to disable all native compilation
> for a single batch session would be helpful. I tried setting
> comp-deferred-compilation and comp-enable-subr-trampolines to nil but
> still got the "Cannot find suitable directory for output in
> ‘comp-eln-load-path’" error with an empty comp-eln-load-path.
>
> Best,
> Mauricio
>
>
>
>
--
akrl <at> sdf.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Sun, 17 Jan 2021 15:30:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Mauricio Collares <mauricio <at> collares.org> writes:
> The example is a bit convoluted, but it is a reduced example from
> another error I saw in the wild. It's not a big problem, but since this
> might be a bug I thought a report could be useful. I wish I could reduce
> it further, but hopefully this is enough.
>
> Suppose I have three files as below (I've appended an x to the original package
> names to avoid conflict):
>
> * File 1: transientx.el
>
> ;;; transientx.el --- x -*- lexical-binding: t; -*-
>
> ;; Package-Requires: ((emacs "25.1"))
> ;; Package-Version: 0
>
> (require 'cl-lib)
> (require 'eieio)
>
> (defclass transient-suffix () ())
> (cl-defmethod transient--init-suffix-key ((obj transient-suffix)))
>
> ;; (provide 'transientx) commented on purpose to cause an error when requiring
> ;;; transientx.el ends here
>
> * File 2: git-commitx.el
>
> ;;; git-commitx.el --- x -*- lexical-binding: t; -*-
>
> ;; Package-Requires: ((emacs "25.1") (transientx "20200601"))
> ;; Package-Version: 20210102.1242
>
> (require 'transientx)
>
> ;;;###autoload
> (define-minor-mode global-git-commit-mode
> "desc"
> :global t
> :initialize (lambda (symbol exp)
> (add-hook 'find-file-hook 'git-commit-setup-check-buffer)))
>
> ;;;###autoload
> (defun git-commit-setup-check-buffer ())
>
> (provide 'git-commitx)
>
> ;;; git-commitx.el ends here
>
> * File 3: elpa2nix.el
>
> (require 'package)
> (package-initialize)
>
> (defun elpa2nix-install-package ()
> (pcase command-line-args-left
> (`(,archive)
> (with-temp-buffer
> (insert-file-contents archive)
> (package-unpack (package-buffer-info))))))
>
> Then running the following two commands in order produces the stack
> trace below on the native-comp branch:
>
> $ emacs --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package transientx.el
> $ emacs --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package git-commitx.el
>
> git-commitx.el:6:1: Error: Loading file /home/collares/.emacs.d/elpa/transientx-0/transientx.elc failed to provide feature ‘transientx’
> Done (Total of 0 files compiled, 1 failed, 2 skipped)
>
> Debugger entered--Lisp error: (error "transient--init-suffix-key is already defined as s...")
> error("%s is already defined as something else than a gen..." transient--init-suffix-key)
> cl-generic-ensure-function(transient--init-suffix-key)
> cl-generic-define-method(transient--init-suffix-key nil ((obj transient-suffix)) nil #f(compiled-function (obj) #<bytecode 0x1bd084804d24a6d3>))
> require(transientx)
> load-with-code-conversion("/home/collares/.emacs.d/elpa/git-commitx-20210102...." "/home/collares/.emacs.d/elpa/git-commitx-20210102...." nil t)
> git-commit-setup-check-buffer()
> run-hooks(find-file-hook)
> after-find-file(nil t)
> find-file-noselect-1(#<buffer git-commitx.el> "~/git-commitx.el" nil nil "~/git-commitx.el" (7340496 65025))
> find-file-noselect("/home/collares/git-commitx.el")
> command-line-1(("-l" "/home/collares/elpa2nix.el" "-f" "elpa2nix-install-package" "/home/collares/git-commitx.el"))
> command-line()
> normal-top-level()
>
> The transient--init-suffix-key error does not appear on trunk (the
> "failed to provide feature" error appears as expected). Reverting commit
> 7d7bfbf0346114b116e14a4338ea235d12674f13 makes the change of behaviour
> disappear, but I suspect it's not the true cause of the difference.
Hi Mauricio,
I failed to reproduce on latest native-comp 88100bed0a. Either I missed
somenthing or is maybe fixed by the latest merge?
Could you check if you still see this?
Thanks
Andrea
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Sun, 17 Jan 2021 15:33:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <andrea.corallo <at> arm.com> writes:
> Mauricio Collares <mauricio <at> collares.org> writes:
>
>> The example is a bit convoluted, but it is a reduced example from
>> another error I saw in the wild. It's not a big problem, but since this
>> might be a bug I thought a report could be useful. I wish I could reduce
>> it further, but hopefully this is enough.
>>
>> Suppose I have three files as below (I've appended an x to the original package
>> names to avoid conflict):
>>
>> * File 1: transientx.el
>>
>> ;;; transientx.el --- x -*- lexical-binding: t; -*-
>>
>> ;; Package-Requires: ((emacs "25.1"))
>> ;; Package-Version: 0
>>
>> (require 'cl-lib)
>> (require 'eieio)
>>
>> (defclass transient-suffix () ())
>> (cl-defmethod transient--init-suffix-key ((obj transient-suffix)))
>>
>> ;; (provide 'transientx) commented on purpose to cause an error when requiring
>> ;;; transientx.el ends here
>>
>> * File 2: git-commitx.el
>>
>> ;;; git-commitx.el --- x -*- lexical-binding: t; -*-
>>
>> ;; Package-Requires: ((emacs "25.1") (transientx "20200601"))
>> ;; Package-Version: 20210102.1242
>>
>> (require 'transientx)
>>
>> ;;;###autoload
>> (define-minor-mode global-git-commit-mode
>> "desc"
>> :global t
>> :initialize (lambda (symbol exp)
>> (add-hook 'find-file-hook 'git-commit-setup-check-buffer)))
>>
>> ;;;###autoload
>> (defun git-commit-setup-check-buffer ())
>>
>> (provide 'git-commitx)
>>
>> ;;; git-commitx.el ends here
>>
>> * File 3: elpa2nix.el
>>
>> (require 'package)
>> (package-initialize)
>>
>> (defun elpa2nix-install-package ()
>> (pcase command-line-args-left
>> (`(,archive)
>> (with-temp-buffer
>> (insert-file-contents archive)
>> (package-unpack (package-buffer-info))))))
>>
>> Then running the following two commands in order produces the stack
>> trace below on the native-comp branch:
>>
>> $ emacs --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package transientx.el
>> $ emacs --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package git-commitx.el
>>
>> git-commitx.el:6:1: Error: Loading file /home/collares/.emacs.d/elpa/transientx-0/transientx.elc failed to provide feature ‘transientx’
>> Done (Total of 0 files compiled, 1 failed, 2 skipped)
>>
>> Debugger entered--Lisp error: (error "transient--init-suffix-key is already defined as s...")
>> error("%s is already defined as something else than a gen..." transient--init-suffix-key)
>> cl-generic-ensure-function(transient--init-suffix-key)
>> cl-generic-define-method(transient--init-suffix-key nil ((obj transient-suffix)) nil #f(compiled-function (obj) #<bytecode 0x1bd084804d24a6d3>))
>> require(transientx)
>> load-with-code-conversion("/home/collares/.emacs.d/elpa/git-commitx-20210102...." "/home/collares/.emacs.d/elpa/git-commitx-20210102...." nil t)
>> git-commit-setup-check-buffer()
>> run-hooks(find-file-hook)
>> after-find-file(nil t)
>> find-file-noselect-1(#<buffer git-commitx.el> "~/git-commitx.el" nil nil "~/git-commitx.el" (7340496 65025))
>> find-file-noselect("/home/collares/git-commitx.el")
>> command-line-1(("-l" "/home/collares/elpa2nix.el" "-f" "elpa2nix-install-package" "/home/collares/git-commitx.el"))
>> command-line()
>> normal-top-level()
>>
>> The transient--init-suffix-key error does not appear on trunk (the
>> "failed to provide feature" error appears as expected). Reverting commit
>> 7d7bfbf0346114b116e14a4338ea235d12674f13 makes the change of behaviour
>> disappear, but I suspect it's not the true cause of the difference.
>
> Hi Mauricio,
>
> I failed to reproduce on latest native-comp 88100bed0a. Either I missed
> somenthing or is maybe fixed by the latest merge?
>
> Could you check if you still see this?
>
> Thanks
>
> Andrea
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
Apologies, I've mistakenly used the wrong mail account
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Sun, 17 Jan 2021 16:04:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> Mauricio Collares <mauricio <at> collares.org> writes:
>
>> This might be slightly off-topic (in the sense that the previous message
>> stands alone and is not corrected by this one) but I have a related
>> question to ask about the actual error I was hitting. To reproduce the
>> error, one can use git-commitx.el and elpa2nix.el from the previous
>> email and the following transientx.el file:
>>
>> ;;; transientx.el --- x -*- lexical-binding: t; -*-
>>
>> ;; Package-Requires: ((emacs "25.1"))
>> ;; Package-Version: 0
>>
>> (require 'cl-lib)
>> (require 'eieio)
>>
>> (defclass transient-suffix () ())
>> (cl-defmethod transient--init-suffix-key ((obj transient-suffix)))
>>
>> (advice-add 'top-level :before 'identity)
>>
>> (provide 'transientx)
>>
>> ;;; transientx.el ends here
>>
>> That is, the "provide" line is uncommented but there's now an advice-add
>> call. Running the following commands causes a problem similar to the one
>> in the previous message:
>>
>> $ --batch -Q -l ~/elpa2nix.el -f elpa2nix-install-package /home/collares/transientx.el
>> $ --batch -Q --eval "(setq comp-eln-load-path '())" -l ~/elpa2nix.el -f elpa2nix-install-package /home/collares/git-commitx.el
>>
>> git-commitx.el:6:1: Error: Cannot find suitable directory for output in ‘comp-eln-load-path’
>> Done (Total of 0 files compiled, 1 failed, 2 skipped)
>> Debugger entered--Lisp error: (error "transient--init-suffix-key is already defined as s...")
>> error("%s is already defined as something else than a gen..." transient--init-suffix-key)
>> cl-generic-ensure-function(transient--init-suffix-key)
>>
>> Apparently, advice-add caused native compilation to happen, and that
>> failed because comp-eln-load-path was empty. This error plays a role
>> similar to the lack of "(provide 'transientx)" in the previous email,
>> leading to the second error which does not happen in trunk.
>>
>> In this email, however, I would like to address the first error. My
>> question is: Is it possible to disable the native compilation caused by
>> advice-add in the above example?
>
> I think that's a bug, I believe `comp-enable-subr-trampolines' should
> cover this case too.
Hi Mauricio,
This should be fixed by 883d937320, could you give it a try and confirm?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Mon, 18 Jan 2021 12:37:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <andrea.corallo <at> arm.com> writes:
>
> Hi Mauricio,
>
> I failed to reproduce on latest native-comp 88100bed0a. Either I missed
> somenthing or is maybe fixed by the latest merge?
>
> Could you check if you still see this?
>
Hi Andrea,
Thanks for taking a look at this. I tested 883d937320 and although the
comp-enable-subr-trampolines bugs is fixed (many thanks!), I can still
reproduce this, both with the testcase from the first email
(comented-out "(provide 'transientx)") and with the testcase from the
second email (empty comp-eln-load-path + comp-enable-subr-trampolines
enabled by default). Any of those two errors then causes the following
error:
error("%s is already defined as something else than a gen..."
transient--init-suffix-key)
Is there any other information I can provide to help figure out why we
get different behaviour? I will include random ideas below, just in case.
The two commands I mentioned above install stuff in ~/.emacs.d/elpa (the
"git-commitx-20210102.1242" and "transientx-0" directories). Could it be
that your test succeeds because it is reusing files generated by a
different emacs version? In the first testcase, this is supposed to
apear right before the transient--init-suffix-key error:
INFO Scraping files for git-commitx-autoloads.el...
INFO Scraping files for git-commitx-autoloads.el...done
Checking /home/collares/.emacs.d/elpa/git-commitx-20210102.1242...
Compiling /home/collares/.emacs.d/elpa/git-commitx-20210102.1242/git-commitx-autoloads.el...
Compiling /home/collares/.emacs.d/elpa/git-commitx-20210102.1242/git-commitx-pkg.el...
Compiling /home/collares/.emacs.d/elpa/git-commitx-20210102.1242/git-commitx.el...
In toplevel form:
git-commitx.el:6:1: Error: Loading file /home/collares/.emacs.d/elpa/transientx-0/transientx.elc failed to provide feature ‘transientx’
Done (Total of 0 files compiled, 1 failed, 2 skipped)
Best,
Mauricio
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Mon, 18 Jan 2021 20:57:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Mauricio Collares <mauricio <at> collares.org> writes:
> Andrea Corallo <andrea.corallo <at> arm.com> writes:
>>
>> Hi Mauricio,
>>
>> I failed to reproduce on latest native-comp 88100bed0a. Either I missed
>> somenthing or is maybe fixed by the latest merge?
>>
>> Could you check if you still see this?
>>
>
> Hi Andrea,
>
> Thanks for taking a look at this. I tested 883d937320 and although the
> comp-enable-subr-trampolines bugs is fixed (many thanks!), I can still
> reproduce this
Okay I probably did something wrong then. I'm taking a look into the
compile-time bugs now, I'll come back to this after that.
Thanks!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Fri, 22 Jan 2021 22:01:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <akrl <at> sdf.org> writes:
>
> Okay I probably did something wrong then. I'm taking a look into the
> compile-time bugs now, I'll come back to this after that.
Many thanks and no hurry :) I just noticed that this bug has nothing to
do with autoloads, sorry for the red herring! You can replace
git-commitx.el by just
;;; git-commitx.el --- x -*- lexical-binding: t; -*-
;; Package-Requires: ((emacs "25.1") (transientx "20200601"))
;; Package-Version: 20210102.1242
(require 'transientx)
(provide 'git-commitx)
;;; git-commitx.el ends here
together with transientx.el and elpa2nix.el from the previous email
and the difference of behaviour (compared to trunk) still exists.
Best,
Mauricio
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Thu, 28 Jan 2021 21:12:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Mauricio Collares <mauricio <at> collares.org> writes:
> Andrea Corallo <akrl <at> sdf.org> writes:
>>
>> Okay I probably did something wrong then. I'm taking a look into the
>> compile-time bugs now, I'll come back to this after that.
>
> Many thanks and no hurry :) I just noticed that this bug has nothing to
> do with autoloads, sorry for the red herring! You can replace
> git-commitx.el by just
>
> ;;; git-commitx.el --- x -*- lexical-binding: t; -*-
>
> ;; Package-Requires: ((emacs "25.1") (transientx "20200601"))
> ;; Package-Version: 20210102.1242
>
> (require 'transientx)
> (provide 'git-commitx)
>
> ;;; git-commitx.el ends here
>
> together with transientx.el and elpa2nix.el from the previous email
> and the difference of behaviour (compared to trunk) still exists.
>
> Best,
> Mauricio
I tried to reproduce again but with no success:
====
HOME=~/tmp ~/emacs2/src/emacs --batch -Q -l ./elpa2nix.el -f elpa2nix-install-package git-commitx.el
INFO Scraping files for git-commitx-autoloads.el...
INFO Scraping files for git-commitx-autoloads.el...done
Checking /home/akrl/tmp/.emacs.d/elpa/git-commitx-20210102.1242...
Compiling /home/akrl/tmp/.emacs.d/elpa/git-commitx-20210102.1242/git-commitx-autoloads.el...
Compiling /home/akrl/tmp/.emacs.d/elpa/git-commitx-20210102.1242/git-commitx-pkg.el...
Compiling /home/akrl/tmp/.emacs.d/elpa/git-commitx-20210102.1242/git-commitx.el...
In toplevel form:
git-commitx.el:6:1: Error: Loading file /home/akrl/tmp/.emacs.d/elpa/transientx-0/transientx.elc failed to provide feature ‘transientx’
Done (Total of 0 files compiled, 1 failed, 2 skipped)
akrl <at> foo:~/el_debug$
====
Am I doing something wrong?
Would be nice to have someone else trying to reproduce this.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Thu, 28 Jan 2021 22:05:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <akrl <at> sdf.org> writes:
>
> I tried to reproduce again but with no success:
>
> ====
> [...]
> ====
>
> Am I doing something wrong?
Thanks for testing! You're not doing anything wrong from what I see, but
I messed up in my last email: The git-commitx.el file from my first
email causes the bug to show up but not the last one I sent. I must have
forgotten to erase ~/.emacs.d/elpa after testing on the last email; I am
very sorry for the time wasting caused by this mistake. On the bright
side, at least this makes more sense, since the commit that exposed this
bug is related to autoloads.
If you're feeling charitable, testing with the original git-commitx.el
and with a clean ~/tmp would be helpful. Either way, I appreciate the
time you took to test this, and I will ask other people to try and
reproduce this too.
Best,
Maurício
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Fri, 29 Jan 2021 09:09:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 45854 <at> debbugs.gnu.org (full text, mbox):
Mauricio Collares <mauricio <at> collares.org> writes:
> Andrea Corallo <akrl <at> sdf.org> writes:
>>
>> I tried to reproduce again but with no success:
>>
>> ====
>> [...]
>> ====
>>
>> Am I doing something wrong?
>
> Thanks for testing! You're not doing anything wrong from what I see, but
> I messed up in my last email: The git-commitx.el file from my first
> email causes the bug to show up but not the last one I sent. I must have
> forgotten to erase ~/.emacs.d/elpa after testing on the last email; I am
> very sorry for the time wasting caused by this mistake. On the bright
> side, at least this makes more sense, since the commit that exposed this
> bug is related to autoloads.
>
> If you're feeling charitable,
LOL, I'm no worries :)
> testing with the original git-commitx.el
> and with a clean ~/tmp would be helpful. Either way, I appreciate the
> time you took to test this, and I will ask other people to try and
> reproduce this too.
I can reproduce it! I'll try to have a look it this week-end to explain
what's going on.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Sat, 30 Jan 2021 14:25:01 GMT)
Full text and
rfc822 format available.
Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):
akrl--- via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
[...]
> I can reproduce it! I'll try to have a look it this week-end to explain
> what's going on.
Here I'm,
I can see the same exact behavior on current master as on a native-comp
build so I believe this is not a misbehavior. I did the two experiments
starting from a clean .emacs.d to avoid state issues.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Sat, 30 Jan 2021 14:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Mon, 01 Feb 2021 12:50:01 GMT)
Full text and
rfc822 format available.
Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <akrl <at> sdf.org> writes:
> Here I'm,
>
> I can see the same exact behavior on current master as on a native-comp
> build so I believe this is not a misbehavior. I did the two experiments
> starting from a clean .emacs.d to avoid state issues.
Hi Andrea,
Yes, I now agree. Starting with "HOME=~/tmp", a git bisect says that
master changed behaviour at 9973019764250ac1f4d77a6b426cdd9c241151c5
too. So this is not a problem with native-compilation and the bug I
reported is invalid. Truly sorry for the confusion. I took care to
delete ~/.emacs.d/elpa and the eln-cache directories between tests but
there must be additional state that interfered with my initial testing.
I have one last question to ask you. The original investigation started
because failure to compile a trampoline (due to an empty
comp-eln-load-path, say) previously didn't interrupt package
installation, and after changes on master it now does. So the remaining
question is: Is triggering trampoline compilation expected even when
running emacs non-interactively in a context (such as in the above
testcase with an uncommented (provide 'transientx)) that otherwise does
not generate .eln files? If this is the intended behaviour, would it
make sense to make trampoline compilation failure emit a warning instead
of an error in those contexts?
Best,
Mauricio
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#45854
; Package
emacs
.
(Mon, 01 Feb 2021 12:50:01 GMT)
Full text and
rfc822 format available.
Reply sent
to
Andrea Corallo <akrl <at> sdf.org>
:
You have taken responsibility.
(Mon, 01 Feb 2021 14:01:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Mauricio Collares <mauricio <at> collares.org>
:
bug acknowledged by developer.
(Mon, 01 Feb 2021 14:01:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 45854-done <at> debbugs.gnu.org (full text, mbox):
Mauricio Collares <mauricio <at> collares.org> writes:
> Andrea Corallo <akrl <at> sdf.org> writes:
>> Here I'm,
>>
>> I can see the same exact behavior on current master as on a native-comp
>> build so I believe this is not a misbehavior. I did the two experiments
>> starting from a clean .emacs.d to avoid state issues.
>
> Hi Andrea,
>
> Yes, I now agree. Starting with "HOME=~/tmp", a git bisect says that
> master changed behaviour at 9973019764250ac1f4d77a6b426cdd9c241151c5
> too. So this is not a problem with native-compilation and the bug I
> reported is invalid. Truly sorry for the confusion. I took care to
> delete ~/.emacs.d/elpa and the eln-cache directories between tests but
> there must be additional state that interfered with my initial testing.
No problem.
> I have one last question to ask you. The original investigation started
> because failure to compile a trampoline (due to an empty
> comp-eln-load-path, say) previously didn't interrupt package
> installation, and after changes on master it now does. So the remaining
> question is: Is triggering trampoline compilation expected even when
> running emacs non-interactively in a context (such as in the above
> testcase with an uncommented (provide 'transientx)) that otherwise does
> not generate .eln files? If this is the intended behaviour, would it
> make sense to make trampoline compilation failure emit a warning instead
> of an error in those contexts?
A trampoline is requested each time a primitive function gets redefined
or advised, if this is not available it gets synthesized. Each eln
might make use of this, not only the one being compiled or installed
therfore is mandatory to have in interactive sessions as well as in non
interactive. If we cannot satisfy this condition for any reason I think
is correct to have an error as Emacs might misbehave.
I'm not sure about what's going on in this specific case but if the
trampoline is requested means a primitive is being redefined or advised.
Okay I'm closing this bug.
Thanks
Andrea
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 02 Mar 2021 12:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 47 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.