max-lisp-eval-depth

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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.
Reply | Threaded
Open this post in threaded view
|

Re: max-lisp-eval-depth

Perry Smith-4
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.

On Jan 30, 2013, at 1:42 PM, drain wrote:

> 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.
>


Reply | Threaded
Open this post in threaded view
|

RE: max-lisp-eval-depth

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.


Reply | Threaded
Open this post in threaded view
|

RE: max-lisp-eval-depth

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.
Reply | Threaded
Open this post in threaded view
|

Re: max-lisp-eval-depth

Stefan Monnier
In reply to this post by drain
> 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
Reply | Threaded
Open this post in threaded view
|

Re: max-lisp-eval-depth

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.
Reply | Threaded
Open this post in threaded view
|

Re: max-lisp-eval-depth

jack-mac
In reply to this post by Stefan Monnier
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.

Reply | Threaded
Open this post in threaded view
|

RE: max-lisp-eval-depth

Ludwig, Mark-2
> From: jack-mac
> Sent: Thursday, January 31, 2013 8:54 AM
> Subject: Re: max-lisp-eval-depth
>
> 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.

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....


Reply | Threaded
Open this post in threaded view
|

RE: max-lisp-eval-depth

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
Reply | Threaded
Open this post in threaded view
|

Re: max-lisp-eval-depth

Oleksandr Gavenko (aka gavenkoa)
In reply to this post by Stefan Monnier
On 2013-01-31, Stefan Monnier wrote:

>> 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.
>
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!


Reply | Threaded
Open this post in threaded view
|

Re: max-lisp-eval-depth

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, ..."


Reply | Threaded
Open this post in threaded view
|

Re: max-lisp-eval-depth

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).
Reply | Threaded
Open this post in threaded view
|

RE: max-lisp-eval-depth

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


Reply | Threaded
Open this post in threaded view
|

RE: max-lisp-eval-depth

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.