Variable SWANK::*APPLICATION-HINTS-TABLES* is unbound

[Shinmera]

While quickloading esrap I ran into the condition stated in the title. My system setup is: SBCL: 1.1.10 Slime: 2013-05-26 Emacs: 24.3.1

Interestingly enough, the issue does not seem to re-occur once I choose the restart to treat the file as having been compiled correctly. Even if I then delete all FASLs and delete/re-quickload esrap, the condition isn't signalled again.

If there's anything else I should try or provide information about, please let me know. I'd be happy to help as best I can.

[scymtym]

Since you didn't include a backtrace, I can only guess that the problem originates at https://github.com/scymtym/esrap/blob/stable/esrap.lisp#L1776 (note that quicklisp now pulls from there, not from nikodemus/esrap).

hint-slime-indentation looks for the symbol *application-hints-tables* in package swank. If I understand correctly, this symbol only exists if the slime-indentation contrib is loaded. However, when that is the case the symbol should be bound to a list.

Sorry, but from your report, I cannot deduce what went wrong. Can you provide a recipe for reproducing the problem? Ideally with all user configuration (SBCL side) and customizations (Emacs side) disabled.

[Shinmera]

I couldn't include a backtrace at the time as I could not reproduce the problem any more. As I mentioned in the OP, confusingly enough the issue disappeared once I accepted the fault for the first time and then it continued to compile correctly ever after.

I'm sorry if I posted this on the wrong repository, I simply followed the link from the website and wasn't aware of the fork.

The first thing I tried after encountering the issue was reinstalling slime, which seemed to fix it, at least for the first time after launching emacs and quickloading esrap. All attempts after resulted in the same condition. However, simply choosing the 'accept' restart seemed to have fixed it permanently now.

I attempted to reproduce the issue on my laptop with clean configurations, clear fasl cache and new quicklisp setup, but to no avail it seems. I am rather puzzled as to how it kept reappearing but now seems to have vanished completely. Regardless, I thought it best to open a ticket, in case something like this had happened before and I was merely being stupid.

If I run across the condition again I'll try my best to trace it immediately and report about it in full here.

[scymtym]

I'm sorry if I posted this on the wrong repository, I simply followed the link from the website and wasn't aware of the fork.

No problem. Just wanted to let you know.

I attempted to reproduce the issue on my laptop with clean configurations, clear fasl cache and new quicklisp setup, but to no avail it seems. I am rather puzzled as to how it kept reappearing but now seems to have vanished completely. Regardless, I thought it best to open a ticket, in case something like this had happened before and I was merely being stupid.

Reporting an issue seems appropriate as there may actually be something wrong with esrap and/or slime. However, at this point, I cannot image what the problem might be either.

If I run across the condition again I'll try my best to trace it immediately and report about it in full here.

Thanks. We should probably leave this issue open until the situation clarifies.

[ruricolist]

This happens to me regularly; I finally got annoyed enough to figure it out.

Swank, being too cool for ASDF, implements its own, independent loader. This loader includes a compile-files stage where it checks for files newer than their fasls and recompiles them. At this stage, it is possible for *application-hints-tables* to be interned, but not bound.

There is a simple fix: since Slime uses provide and require, instead of looking for the symbols, check *modules* for "SWANK-INDENTATION".

[scymtym]

Hopefully fixed by scymtym/esrap@29c1751bd1.