max-lisp-eval-depth

[drain]

The following issue is raised when I use Wanderlust, but it must relate to
Emacs at large, given that the variable max-lisp-eval-depth is defined in
emacs/src/eval.c.

Plus the Wanderlust mailing list is only semi-active.

The issue:

When I relaunch Wanderlust sometimes (within the same Emacs session), I get
the message, "Lisp nesting exceeds max-eval-depth." Because of this,
Wanderlust will not update my inbox. It shows what I had before.

And then other times, I can't enter my Inbox because of
"max-lisp-eval-depth."

Maybe there's some variable here, perhaps max-lisp-eval-depth, I need to
set to a different value.

Now so that this does not appear like a case of
answering my own question, I am asking what the ideal value should be,
given the problem as described (I'm still just presuming that the value of
that variable is the source of the problem; conjecturing to my own
question, not answering it).

My current solution is to completely kill all mail processes, then launch
Wanderlust afresh.



--
View this message in context: http://emacs.1067599.n5.nabble.com/max-lisp-eval-depth-tp276835.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

[Perry Smith]

Mine is set to 600 (emacs 24.2) on two different platforms.

Would setting debug-on-error to t help? Then you would see the stack and that might give you a hint. It may be some data structure is looped back on itself and its not suppose to be causing infinite recursion.

[Drew Adams]

> Mine is set to 600 (emacs 24.2) on two different platforms.
>
> Would setting debug-on-error to t help? Then you would see
> the stack and that might give you a hint. It may be some
> data structure is looped back on itself and its not suppose
> to be causing infinite recursion.

The error that max-lisp-eval-depth is exceeded is nearly always an
infinite-recursion problem. Bisect your init file to try to identify the
culprit code.

You might need to recompile that code or load it without compiling it. Or
perhaps (most likely) it is just buggy and needs to be fixed.

But the point is to respond to a max-lisp-eval-depth error by looking for a code
problem, not by increasing that variable value.

[drain]

Drew Adams wrote

> But the point is to respond to a max-lisp-eval-depth error by looking for
> a code
> problem, not by increasing that variable value.

Answer I was looking for.




--
View this message in context: http://emacs.1067599.n5.nabble.com/max-lisp-eval-depth-tp276835p276849.html

[Stefan Monnier]

> And then other times, I can't enter my Inbox because of
> "max-lisp-eval-depth."

That's either because there's an infinite recursion (in which case you
need to fix the corresponding code), or because the code uses more stack
space than provided.
You can fix the latter problem either by increasing the stack space (by
setting max-lisp-eval-depth to a larger value) or by reducing the
stack usage. Byte-compiled code uses much less stack space, so if you
use Elisp packages without byte-compiling them, the first thing I'd
suggest is to byte-compile them.


Stefan

[drain]

Stefan Monnier wrote

> That's either because there's an infinite recursion (in which case you
> need to fix the corresponding code), or because the code uses more stack
> space than provided.

> Stefan

The only problem is figuring out where in the code this occurs...

Thus far that variable is the best lead, but I'm fairly convinced this is
an infinite recursion issue.



--
View this message in context: http://emacs.1067599.n5.nabble.com/max-lisp-eval-depth-tp276835p276870.html

[jack-mac]

Le jeudi 31 janvier 2013 04:08:12 UTC+1, drain a écrit :
> Stefan Monnier wrote
>
> > That's either because there's an infinite recursion (in which case you
> > need to fix the corresponding code), or because the code uses more stack
> > space than provided.
>

> The only problem is figuring out where in the code this occurs...

Perry Smith already gave you the answer:
To use the emacs-lisp debugging tools, try to set the variable 'debug-on-error' to t (true) and see what happens when stack overflows.

[jack-mac]

Le jeudi 31 janvier 2013 04:08:12 UTC+1, drain a écrit :

> Stefan Monnier wrote
>
> > That's either because there's an infinite recursion (in which case you
> > need to fix the corresponding code), or because the code uses more stack
> > space than provided.
>

> The only problem is figuring out where in the code this occurs...

[Ludwig, Mark]

> From: jack-mac
> Sent: Thursday, January 31, 2013 8:54 AM
> Subject: Re: max-lisp-eval-depth

Right, and I would REDUCE the value of max-lisp-eval-depth, so the error hits faster
and when it does, I have fewer calls to wade through....

[drain]

I got this:

Debugger entered--Lisp error: (error "Lisp nesting exceeds
`max-lisp-eval-depth'")
signal(error ("Lisp nesting exceeds `max-lisp-eval-depth'"))
byte-code("\302 !\203\n



--
View this message in context: http://emacs.1067599.n5.nabble.com/max-lisp-eval-depth-tp276835p276921.html

[Oleksandr Gavenko]

Please answer why *Byte-compiled code uses much less stack space*?

Very briefly, with few tech details. Which ratio between compiled and
non-compiled usage?

--
Best regards!

[Stefan Monnier]

> Please answer why *Byte-compiled code uses much less stack space*?

Simple because every `progn' or `if' nesting adds to the stack
space usage in interpreted code, but not in byte-compiled code.

Similarly for `let', interpreted code will end up pushing the new
binding on the "specpdl stack" and then doing a recursive C call to the
Feval function, whereas byte-compiled code will only push the new value
onto the "specpdl stack" but will stay within the same function.

> Very briefly, with few tech details. Which ratio between compiled and
> non-compiled usage?

That varies a lot depending on the kind of code.
I'd guess on the average a factor of 4, maybe?


Stefan "Note that there are different notions of stack space at
play here, such as the one measured by
max-lisp-eval-depth, the one measuring the size of the
C stack, the once measured by max-specpdl-size, ..."

[drain]

Does anyone have suggestions on setting up a server relay for mail? I
suspect the recursion issue might be incidentally related to not using one
with Wanderlust.

At this point, I have to compose all messages in org-mode, then copy them
into the mail buffer, lest I wait too long before sending (and therefore
losing contact with the server).



--
View this message in context: http://emacs.1067599.n5.nabble.com/max-lisp-eval-depth-tp276835p277099.html

[Drew Adams]

Please change the Subject line when you change the subject. Thx.

[drain]

I believe Wanderlust was not purging my cache; or, at least, not frequently
enough.

For those future Google searchers out there, this is what solved the
problem (at least apparently solved it):

"How does the cache work? How can I purge it?

Even when using IMAP, wl caches the messages (by default it caches the
message being read, and the following one), and stores them in
elmo-cache-directory i.e. ~/.elmo. This cache can get quite large.
Especially if you tend to run online most of the time, you may want to purge
it periodically, which can be done by either doing “M-x
elmo-cache-expire-by-size” or putting something similar in .wl:

;;days since last access, i.e atime. (default: 50)
(elmo-cache-expire-by-age 14)

;;kilobytes (default 30000)
(elmo-cache-expire-by-size 1024)"

http://www.emacswiki.org/emacs/WlFaq#toc6

I noticed that even after deleting all my Inbox messages, WL still
indicated that it was storing > 300, though not visible. After M-x
elmo-cache-expire-by-size (which took its time -- must have been a large
cache), I no longer get the max-lisp-eval depth error. And happily my mail
loads much more quickly now.



--
View this message in context: http://emacs.1067599.n5.nabble.com/max-lisp-eval-depth-tp276835p277119.html