Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Carlo Tambuatco]

During routine upgrading of my installed elpa packages via:

M-x package-list-packages
U
x

the package manager just kind of downloads the requested packages, then when the compilation starts, it dies after about one second with the message: Lisp nesting exceeds max-lisp-eval-depth

I get the error message listed above and the package manager simply fails to compile the files...

This only started happening today, it has never happened before. This happens regardless of which packages 
I am upgrading.

Any help appreciated...

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Joost Kremers]

On Sun, Oct 06 2019, Carlo Tambuatco wrote:
> During routine upgrading of my installed elpa packages via:
>
> M-x package-list-packages
> U
> x
>
> the package manager just kind of downloads the requested 
> packages, then when the compilation starts, it dies after about 
> one second with the message: Lisp nesting exceeds 
> max-lisp-eval-depth

It happened to me to today. Except in my case, Emacs manages to 
compile 4-5 packages before the error occurs. I was able to 
compile all updates by retrying 3-4 times.

I had quite a large number of updates, but that has never been an 
issue before.



-- 
Joost Kremers
Life has its moments

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Michael Heerdegen]

Carlo Tambuatco <oraclmaster@gmail.com> writes:

> During routine upgrading of my installed elpa packages via:
>
> M-x package-list-packages
> U
> x
>
> the package manager just kind of downloads the requested packages,
> then when the compilation starts, it dies after about one second with
> the message: Lisp nesting exceeds max-lisp-eval-depth
>
> I get the error message listed above and the package manager simply
> fails to compile the files...
>
> This only started happening today, it has never happened before. This
> happens regardless of which packages
> I am upgrading.
>
> Any help appreciated...

I have heard that an recursive dependency of Helm packages is the
culprit (helm vs. helm-org or so).  Not your fault.  I think it will be
fixed soon.

Michael.

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Joost Kremers]

On Sun, Oct 06 2019, Michael Heerdegen wrote:
> Carlo Tambuatco <oraclmaster@gmail.com> writes:
>> the package manager just kind of downloads the requested 
>> packages,
>> then when the compilation starts, it dies after about one 
>> second with
>> the message: Lisp nesting exceeds max-lisp-eval-depth
>> 
> I have heard that an recursive dependency of Helm packages is 
> the
> culprit (helm vs. helm-org or so).  Not your fault.  I think it 
> will be
> fixed soon.

I don't know about the OP, but I myself don't use helm and nothing 
helm-related seems to be installed:

~ $ v .elpa/helm*
.elpa/helm*: No such file or directory

So why would I get the error, then?

-- 
Joost Kremers
Life has its moments

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Michael Heerdegen]

Joost Kremers <joostkremers@fastmail.fm> writes:

> I don't know about the OP, but I myself don't use helm and nothing
> helm-related seems to be installed:
>
> ~ $ v .elpa/helm*
> .elpa/helm*: No such file or directory
>
> So why would I get the error, then?

Hmm, the error happens in `async-bytecomp-get-allowed-pkgs', it loops
over `async-bytecomp-allowed-packages' which includes helm (hardcoded in
async-bytecomp.el !).  When you upgrade packages
`async-bytecomp-get-allowed-pkgs' is called and that produces the issue
no matter which packages you have installed.

I guess setting async-bytecomp-allowed-packages to nil could be a
workaround but I don't want to try this now.

Michael.

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Carlo Tambuatco]

I do have helm installed as well as several other helm dependents..

helm-20191003.727
helm-core-20191003.1622
helm-projectile-20190731.1538

Are these causing the problem?



> On Oct 6, 2019, at 10:59 AM, Michael Heerdegen <michael_heerdegen@web.de> wrote:
> 
> Carlo Tambuatco <oraclmaster@gmail.com> writes:
> 
>> During routine upgrading of my installed elpa packages via:
>> 
>> M-x package-list-packages
>> U
>> x
>> 
>> the package manager just kind of downloads the requested packages,
>> then when the compilation starts, it dies after about one second with
>> the message: Lisp nesting exceeds max-lisp-eval-depth
>> 
>> I get the error message listed above and the package manager simply
>> fails to compile the files...
>> 
>> This only started happening today, it has never happened before. This
>> happens regardless of which packages
>> I am upgrading.
>> 
>> Any help appreciated...
> 
> I have heard that an recursive dependency of Helm packages is the
> culprit (helm vs. helm-org or so).  Not your fault.  I think it will be
> fixed soon.
> 
> Michael.

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Michael Heerdegen]

Carlo Tambuatco <oraclmaster@gmail.com> writes:

> I do have helm installed as well as several other helm dependents..
>
> helm-20191003.727
> helm-core-20191003.1622
> helm-projectile-20190731.1538
>
> Are these causing the problem?

As I said - seems it's already enough to have a repository included that
has these packages (Melpa).  Whether these packages are actually
installed or to be upgraded doesn't seem to matter.

But the helm list reads like they have fixed it so it should start
working again soon.  Just be patient.

Michael.

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Stefan Monnier]

>> I don't know about the OP, but I myself don't use helm and nothing
>> helm-related seems to be installed:
>>
>> ~ $ v .elpa/helm*
>> .elpa/helm*: No such file or directory
>>
>> So why would I get the error, then?
>
> Hmm, the error happens in `async-bytecomp-get-allowed-pkgs', it loops
> over `async-bytecomp-allowed-packages' which includes helm (hardcoded in
> async-bytecomp.el !).  When you upgrade packages
> `async-bytecomp-get-allowed-pkgs' is called and that produces the issue
> no matter which packages you have installed.

Indeed it's a bug in async.el.
Does the patch below help?

[ Of course, package--get-deps should be fixed accordingly.  ]


        Stefan


diff --git a/packages/async/async-bytecomp.el b/packages/async/async-bytecomp.el
index 082b31adb..ae24cfce8 100644
--- a/packages/async/async-bytecomp.el
+++ b/packages/async/async-bytecomp.el
@@ -108,46 +108,30 @@ All *.elc files are systematically deleted before proceeding."
 (defvar package-alist)
 (declare-function package-desc-reqs "package.el" (cl-x))
 
-(defun async-bytecomp--get-package-deps (pkg &optional only)
+(defun async-bytecomp--get-package-deps (pkgs)
   ;; Same as `package--get-deps' but parse instead `package-archive-contents'
   ;; because PKG is not already installed and not present in `package-alist'.
   ;; However fallback to `package-alist' in case PKG no more present
   ;; in `package-archive-contents' due to modification to `package-archives'.
   ;; See issue #58.
-  (let* ((pkg-desc (cadr (or (assq pkg package-archive-contents)
-                             (assq pkg package-alist))))
-         (direct-deps (cl-loop for p in (package-desc-reqs pkg-desc)
-                               for name = (car p)
-                               when (or (assq name package-archive-contents)
-                                        (assq name package-alist))
-                               collect name))
-         (indirect-deps (unless (eq only 'direct)
-                          (delete-dups
-                           (cl-loop for p in direct-deps append
-                                    (async-bytecomp--get-package-deps p))))))
-    (cl-case only
-      (direct   direct-deps)
-      (separate (list direct-deps indirect-deps))
-      (indirect indirect-deps)
-      (t        (delete-dups (append direct-deps indirect-deps))))))
-
-(defun async-bytecomp-get-allowed-pkgs ()
-  (when (and async-bytecomp-allowed-packages
-             (listp async-bytecomp-allowed-packages))
-    (if package-archive-contents
-        (cl-loop for p in async-bytecomp-allowed-packages
-                 when (assq p package-archive-contents)
-                 append (async-bytecomp--get-package-deps p) into reqs
-                 finally return
-                 (delete-dups
-                  (append async-bytecomp-allowed-packages reqs)))
-        async-bytecomp-allowed-packages)))
+  (let ((seen '()))
+    (while pkgs
+      (let ((pkg (pop pkgs)))
+        (if (memq pkg seen)
+            nil ;; Done already!
+          (let ((pkg-desc (cadr (or (assq pkg package-archive-contents)
+                                    (assq pkg package-alist)))))
+            (when pkg-desc
+              (push pkg seen)
+              (setq pkgs (nconc pkgs (package-desc-reqs pkg-desc))))))))
+    seen))
 
 (defun async--package-compile (orig-fun pkg-desc &rest args)
   (let ((cur-package (package-desc-name pkg-desc))
         (pkg-dir (package-desc-dir pkg-desc)))
-    (if (or (equal async-bytecomp-allowed-packages '(all))
-            (memq cur-package (async-bytecomp-get-allowed-pkgs)))
+    (if (or (member async-bytecomp-allowed-packages '(t all (all)))
+            (memq cur-package (async-bytecomp--get-package-deps
+                               async-bytecomp-allowed-packages)))
         (progn
           ;; FIXME: Why do we use (eq cur-package 'async) once
           ;; and (string= cur-package "async") afterwards?

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Indeed it's a bug in async.el.
> Does the patch below help?

I can't really test anymore, since all packages are updated now...but
evaluating (async-bytecomp-get-allowed-pkgs) gives me

Debugger entered--Lisp error: (wrong-type-argument listp async)
  cdr(async)
  (setq pkgs (cdr pkgs))
  (prog1 pkgs (setq pkgs (cdr pkgs)))
  (car-safe (prog1 pkgs (setq pkgs (cdr pkgs))))
  (let ((pkg (car-safe (prog1 pkgs (setq pkgs (cdr pkgs)))))) (if (memq pkg seen) nil (let ((pkg-desc (car (cdr (or ... ...))))) (if pkg-desc (progn (setq seen (cons pkg seen)) (setq pkgs (nconc pkgs (progn ... ...))))))))
  (while pkgs (let ((pkg (car-safe (prog1 pkgs (setq pkgs (cdr pkgs)))))) (if (memq pkg seen) nil (let ((pkg-desc (car (cdr ...)))) (if pkg-desc (progn (setq seen (cons pkg seen)) (setq pkgs (nconc pkgs ...))))))))
  (let ((seen 'nil)) (while pkgs (let ((pkg (car-safe (prog1 pkgs (setq pkgs ...))))) (if (memq pkg seen) nil (let ((pkg-desc (car ...))) (if pkg-desc (progn (setq seen ...) (setq pkgs ...))))))) seen)
  async-bytecomp--get-package-deps(async)
  async-bytecomp-get-allowed-pkgs()

But it seems your patch did obsolete this function.  Could someone else
pls test?

Michael.

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > Indeed it's a bug in async.el.

Even harder to test now since the fixed helm package appeared in this moment.

Michael.

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Stefan Monnier]

> +              (setq pkgs (nconc pkgs (package-desc-reqs pkg-desc))))))))
                             ^^^^^
Nooo!!!!

This should be `append` (and it's better to reverse the two arguments,
tho both choices should work correctly).


        Stefan

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Stefan Monnier]

>> Indeed it's a bug in async.el.
>> Does the patch below help?
> I can't really test anymore, since all packages are updated now...but
> evaluating (async-bytecomp-get-allowed-pkgs) gives me

There's no async-bytecomp-get-allowed-pkgs any more, so if you're still
using it, it will break because it uses the old calling convention of
async-bytecomp--get-package-deps (which took a single package whereas
now it takes a list of packages).

> Even harder to test now since the fixed helm package appeared in this moment.

Actually, the most important test is to make sure it still works
correctly: I'm pretty sure it fixes the inf-recursion.


        Stefan

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > +              (setq pkgs (nconc pkgs (package-desc-reqs pkg-desc))))))))
>                              ^^^^^
> Nooo!!!!
>
> This should be `append` (and it's better to reverse the two arguments,
> tho both choices should work correctly).

Ok, will try tomorrow if it works for the next package upgrade.

Michael.

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Ok, will try tomorrow if it works for the next package upgrade.

Ok, I flunked the test today (do you say so in American English? - I
mean, I failed to test correctly).  I had only reloaded the new source
while the old defadvice of `package--compile' was still in effect, so I
got an error (expectedly).  Will retry tomorrow :-)


Michael.

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Will retry tomorrow :-)

It's still today (unless you read this tomorrow, then it is yesterday),
but it worked.  But I suddenly do have 24 packages for autoremove.  This
could be due to messed updates in the meantime, I don't have enough
overview to estimate.  Or is it worth to investigate?

Michael.

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Stefan Monnier]

> overview to estimate.  Or is it worth to investigate?

Don't bother.  The author of async.el took my patch so it'll be tested
"live" soon enough ;-)


        Stefan

Re: Upgrading elpa packages results in Lisp nesting exceeds max-lisp-eval-depth...

[Stefan Monnier]

> +              (setq pkgs (nconc pkgs (package-desc-reqs pkg-desc))))))))
                                       ^
                                 (mapcar #'car

And I also forgot that!
Duh!


        Stefan