Here’s a project where a lockup/cpu-heating issue can be reproduced, using Calva https://github.com/PEZ/repro-calva-nrepl-lockup Calva sends a complete message that makes nREPL go spinning a while.
Calva’s nREPL log has this when it happens:
-> sent
{
op: 'complete',
ns: 'user',
symbol: 'igno',
id: '95',
session: '9b241d55-c918-43fa-b776-19b41a80bc43',
context: '{:ignr __prefix__\n' +
';; On ^that^ line:\n' +
';; 1. continue typing one letter after the word starting with `ign`\n' +
';; 2. hit backspace (assuming you have strict structural delete enabled)\n' +
';; 3. the letter is deleted.\n' +
';; Try typing some more and backspace over it.\n' +
';; It works.\n' +
';; 4. Start and connect the REPL\n' +
';; 5. Goto 1.\n' +
';; 6. Instead of 3. experience lockup,\n' +
';; The letter will eventually be deleted\n' +
'\n' +
' (?: # Ignorables\n' +
' \\#\\!.*\\n? | # hashbang line\n' +
' [\\s,]+ | # whitespace, commas,\n' +
' ;.*\\n? # comments\n' +
' )"\n' +
' :char #"\\\\." ; Character token\n' +
' :keyw #"(?:\\:\\w+(?:-\\w+)*)" ; Keyword token\n' +
' :oper #"[-+*/<=>|&]{1,3}" ; Operator token\n' +
' :str #"(?x)\n' +
' \\#? # Possibly a regex\n' +
' \\"(?: # Quoted string\n' +
' \\\\. | # Escaped char\n' +
' [^\\\\\\"] # Any other char\n' +
' )*\\"? # Ending quote\n' +
' "\n' +
' :sym #"\\w+(?:-\\w+)*[?!]?" ; Symbol token\n' +
' :symp #"\\w+(?:-\\w+)*[?!]?\\(" ; Symbol followed by paren\n' +
' })\n' +
'\n' +
' (defn re [s]\n' +
' (re-pattern\n' +
' (reduce\n' +
' (fn [re [k v]]\n' +
' (let [pat (re-pattern (str #"\\$" (subs (str k) 1) #"(?!\\w)"))]\n' +
' (str/replace re pat (str/re-quote-replacement v))))\n' +
' s dict)))',
'enhanced-cljs-completion?': 't'
}
<- received
{
id: '94',
list: [],
session: '9b241d55-c918-43fa-b776-19b41a80bc43',
status: [ 'done' ]
}
<- received
{
completions: [],
id: '95',
session: '9b241d55-c918-43fa-b776-19b41a80bc43',
status: [ 'done' ]
}
I haven’t tried it with CIDER, yet, but I’m guessing it might not send that broken code as context. I will see when I try it. Or someone else will see, beating me to it, because I won’t be doing it tonight.
OK. After having given this some more thought, I don’t think I have enough data to conclude this happens in nREPL. It could be that it is Calva that struggles with collecting the context. I think I should start with adding time stamps to those nREPL message log entries… Anyway, I’ll be looking at it from the Calva end first, and will update about wether I have reason to think something needs to be looked at in the nREPL server.
Indeed. With timestamps on the messages I can clearly see that there is nothing getting stuck in nREPL. This is all going wrong in Calva. Sorry about the noise!