Symbol’s function definition is void: uninstallable
DarwinAwardWinner opened this issue · comments
I just upgraded to Eldev 0.9, and now most commands fail with the following error:
$ eldev version
eldev 0.9
$ eldev -d upgrade # Also happens for compile, test, ...
Debugger entered--Lisp error: (void-function uninstallable)
uninstallable(nil nil)
eldev--install-or-upgrade-dependencies(project (test) t nil nil t)
eldev-upgrade()
apply(eldev-upgrade nil)
eldev-cli(("-d" "upgrade"))
(kill-emacs (eldev-cli (append (cdr (member "--" command-line-args)) nil)))
eval((kill-emacs (eldev-cli (append (cdr (member "--" command-line-args)) nil))) t)
command-line-1(("--execute" "(let ((eldev--emacs-version (format \"%s.%s\" emacs-..." "--execute" "(kill-emacs (eldev-cli (append (cdr (member \"--\" c..." "--" "-d" "upgrade"))
command-line()
normal-top-level()
Looking at the source, it seems this value is bound using a special eldev lazy evaluation macro, so I'm not sure how to debug it.
Deleting ~/.eldev and re-running seems to have fixed this. I guess it's another ghost of upgrades past.
Good that it got resolved. Do you remember which version you had had before upgrading? Maybe it is reproducible and should be properly fixed in that case.
I don't remember exactly, but it started with 0.8. FWIW I just tried on another computer upgrading from 0.8.1 to 0.9, and the issue didn't happen.
Would be nice to have a copy of ~/.eldev contents, or at least the list of contained files, but I guess it's too late now. I'll keep this issue open in case it happens again.
Hmm, actually, I have Time Machine enabled, let me see if I can pull the previous contents from a backup.
Ok, I recovered the offending ~/.eldev contents, and I can reproduce the error:
$ emacs --version
GNU Emacs 27.2
Copyright (C) 2021 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
$ eldev --version
eldev 0.8.1
$ eldev upgrade-self
[1/1] Upgrading package ‘eldev’ (0.8.1 -> 0.9.1) from ‘melpa-stable’...
Upgraded or installed 1 package
$ eldev --version
eldev 0.9.1
$ eldev test
Symbol’s function definition is void: uninstallable
Run with ‘--debug’ (‘-d’) option to see error backtrace
$ eldev -d test
Debugger entered--Lisp error: (void-function uninstallable)
uninstallable(nil nil)
eldev--install-or-upgrade-dependencies(nil (runtime) nil nil t nil nil)
eldev-load-extra-dependencies(runtime)
eldev--set-up-undercover(nil)
#f(compiled-function () #<bytecode 0x1fe548a33805>)()
run-hooks(eldev-test-hook)
eldev-cli(("-d" "test"))
(kill-emacs (eldev-cli (append (cdr (member "--" command-line-args)) nil)))
eval((kill-emacs (eldev-cli (append (cdr (member "--" command-line-args)) nil))) t)
command-line-1(("--execute" "(let ((eldev--emacs-version (format \"%s.%s\" emacs-..." "--execute" "(kill-emacs (eldev-cli (append (cdr (member \"--\" c..." "--" "-d" "test"))
command-line()
normal-top-level()
I'm attaching a tarball of ~/.eldev prior to running eldev upgrade-self and another one after.
dot-eldev-broken-before-upgrade-0.8.1.tar.gz
dot-eldev-broken-after-upgrade-0.9.1.tar.gz
I guess I understand what happens now. When Eldev upgrades self, it installs the new package, which means it gets byte-compiled by Emacs. But since the features are already loaded, it doesn't read new macro definitions before compiling, which results in partially broken compilation results (in this case, eldev--lazy-scope is a new macro, and byte-compiled code, not knowing about it, just calls it as a function). It's kind of an annoying side-effect of how Elisp works.
Need to think through how to fix it best. And whether it has some consequences for other packages installed/upgraded as dependencies.
@juergenhoetzel, @ikappaki: I would need your help with Windows, if possible (if you are willing to investigate, please reply here, so that the other doesn't duplicate your work). After the latest commits related to this bug, testing fails on Windows only, on the new tests eldev-upgrade-self-new-macros-1/* (in file test/upgrade-self.el). From the error messages it looks to me like the generated .tar file is corrupt. It is generated using eldev dist, which has always worked fine. But in this case it is also later edited with Emacs, at which point, I suspect, something goes wrong on Windows only. Can you please have a look at it?
Can you please have a look at it?
I will take a look 🤓
@juergenhoetzel: it has been two weeks, any results? If you don't feel like doing it anymore, that's ok, but then please say so.
@juergenhoetzel: it has been two weeks, any results? If you don't feel like doing it anymore, that's ok, but then please say so.
Yes i found the root cause of:
[1/1] Upgrading package `eldev' (0.9.2snapshot -> 999.9) from `bootstrap-pa'...
eldev-buttercup.el:0:0: error: scan-error: (Unbalanced parentheses 1574 3023)
The editing of in tar-mode creates a corrupt tar file on windows:
tar tvf .\test\.tmp\27.1\eldev-archive-2\eldev-999.9.tar
-rw-r--r-- pidsleywin/Administratoren 3081 2021-04-22 19:12 eldev-999.9/eldev-buttercup.el
"C:/Users/pidsleywin/scoop/apps/tar/current/bin/tar.exe": Skipping to next header
"C:/Users/pidsleywin/scoop/apps/tar/current/bin/tar.exe": Exiting with failure status due to previous errors
The eldev-buttercup.el file is just half written which causes the error message (Unbalanced parentheses).
It seems windows bsd tar is incompatible with Emacs tar-mode.
Thank you, that's basically what I suspected. Do you see an easy way out, or should we just disabled this test on Windows? By the way, maybe it's a good idea to report a bug to Emacs in this case.
Thank you, that's basically what I suspected. Do you see an easy way out, or should we just disabled this test on Windows? By the way, maybe it's a good idea to report a bug to Emacs in this case.
I don't see any easy workarounds.
What puzzles me is that the error occurs under Windows also when using GNU tar.
tar-mode itself is elisp-only code.
I will skim to through tar-mode.el to figure out more details what is going on and file a bug.
It seems that additional CR (0x0d) characters cause a destruction of the tar structure on Windows. Maybe we can work around this issue.
It is not terribly important. Unless the workaround would be a simple variable assignment or a short function override, let's just disable the test instead. Have you reported this to Emacs developers?
Have you reported this to Emacs developers
Not yet. But this bizarre bug has awakened my interest in internals of TAR 😆 I'll try to tackle the problem on the WE.
For now commit 9e59d6c disables these tests on Windows. If you find a simple workaround, feel free to create a PR to re-enable them, but it's not very important.
For now commit 9e59d6c disables these tests on Windows. If you find a simple workaround, feel free to create a PR to re-enable them, but it's not very important.
I commited a simple workaround: #46
On windows saving the tar-buffer inserts additional 0x0d (CR) which breaks the tar-structure even tough buffer-file-coding-system is set to no-conversion.
This problem should not happen again after the fixes in 0.9.2.