stack-mode hangs emacs when using latest load-targets release

[lukehoersten]

After upgrading to the latest load-targets release of stack-ide, stack-mode blocks emacs in various situations.

Versions

• stack: Version 0.1.5.0, Git revision f89f03c099c5405ed51462384cc60af5a62ade0a X86_64
• stack-ide: Version 0.1.0.0, Git revision bd7d845 (153 commits) X86_64

Problem 1

On initial startup, stack-mode blocks emacs indefinitely. This can be unblocked by hitting C-g numerous times.

The resulting *stack:project* buffer looks like this (those are ^H characters):

Stack backend isn't ready. Waiting (0 attempts) ...
Flycheck tried to use the Stack backend, but the Stack backend isn't started yet. Starting it ...
Set initial command.
Starting: ("stack:project" nil "stack" "ide" "start" "package")
Running Flycheck with Stack backend ...
 <- Progress: 0/2�������������             �������������statistics-0.13.2.3: configure
 <- Progress: 0/2�������������             �������������statistics-0.13.2.3: build
 <- Progress: 0/2�������������             �������������statistics-0.13.2.3: install
 <- Progress: 0/2�������������             �������������Progress: 1/2�������������             �������������criterion-1.1.0.0: configure
 <- Progress: 1/2�������������             �������������criterion-1.1.0.0: build
 <- Progress: 1/2�������������             �������������criterion-1.1.0.0: install
 <- Progress: 1/2�������������             �������������Completed all 2 actions.

Problem 2

After C-g-ing the first hang, running anything like (stack-mode-goto) hangs emacs in the same manor as above.

C-g-ing that adds only one new line to the *stack:project* buffer:

[nil] ~> {"tag":"RequestGetSpanInfo","contents":{"spanFilePath":"lib\/src\/Project\/File.hs","spanFromLine":27,"spanFromColumn":31,"spanToLine":27,"spanToColumn":43}}

This is reproducible.

[chrisdone]

Does M-x stack-mode-restart and then disabling/re-enabling stack-mode temporarily fix this?

[lukehoersten]

@chrisdone yes but any time I do a stack-mode-* function it freezes until I C-g again.

[lukehoersten]

This seems to be the last thing left in the *stack:project* buffer when it stops responding:

 <- {"tag":"ResponseLog","contents":"[Debug] Recompile required, starting... @(ideba_3ZhTR2JwASF9jTa238ZFTP:IdeSession.Update.ExecuteSessionUpdate ./IdeSession/Update/ExecuteSessionUpdate.hs:223:5)\n"}

[rjmac]

I've done some digging. It looks like what's happening is that stack-mode-set-initial-command is setting up Emacs to expect a response to a command that is never sent (presumably because stack-ide used to reload targets on startup, as the docstring says, but no longer does as part of the reload rework) but with that outstanding pseudorequest pending, no other command is ever sent from emacs. Simply changing stack-mode-set-initial-command to set stack-mode-current-command to nil makes the mode work for me again (at least in the toy one-file project I used to investigate), because Flycheck immediately issues a command that causes stack-ide to load the current file.

[rjmac]

Well, for some values of "work". It seems eager to unload modules under circumstances that are not yet clear, but at least it doesn't get into a state that a quick C-c C-l can't fix.

[lukehoersten]

My case doesn't look like it's even trying to initially load modules anymore. And similarly, C-c C-l does nothing.

[mithrandi]

I can reproduce the same thing: the stack-ide buffer ends in "Recompile required, starting..." after starting the process, with no apparent compilation actually happening (there are no child processes of the stack ide process at all, for example). Is this a red herring? (I see the same output when running stack ide start from the command line)

After that, any command that tries to interact with the subprocess just seems to hang. I'm using git master of stack-ide and stack revision 42bb3b35b50f93183e5c605f68e73302f3dd16db as installed by stack upgrade --git. My emacs version is: GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.16.6) of 2015-09-19 on trouble, modified by Debian

[rjmac]

@lukehoersten I think I was unclear. I was seeing exactly the same symptoms as you, with the log ending at "Recompile required, starting...". What my digging showed was that from that point onward, Emacs was refusing to send any more commands at all because it was still awaiting a "response" which was really a default startup message from the backend (specifically, it was waiting for a message with the tag ResponseUpdateSession). It doesn't look like a message of that sort is sent anymore without prompting. By making it not expect that message, it's free to send other commands.

[lattenwald]

Following @rjmac's solution I was able to see stack-mode working finally. Running stack from git Version 0.1.5.0, Git revision 06a4b270de2d2dcbd3ee8abe98078151c4a8f075 X86_64, stack-ide from git f78ff35abfbbc52e171ee109682c85baa9deb5f1

[lukehoersten]

@chrisdone any ideas on @rjmac's hint?

[erikkaplun]

f78ff35 has stopped working as of stack-0.1.6.0. reverting back to stack-0.1.5.0 fixes it. this applies to both using stack-ide from within Emacs as well as $ stack ide start on the command line.

[erikkaplun]

the solution offered by @rjmac does indeed work for me as of stack-0.1.8.0.