"Unexpected response from haskell process" when loading in new session

[cmears]

Sometimes when you press C-c C-l to start a new session and immediately load a file, I get "Unexpected response from haskell process." I think this is due to a race condition.

When the new session starts, it issues a few commands to set the prompt, set verbosity and change directory. If the empty response to these commands comes late, they appear to haskell-mode to be in response to the load command, which doesn't match the expected output.

That is, you get this timeline:

send "cd"
send "load"
receive empty response (from the cd)
receive response "compiling, loading modules, etc." (from the load)

It doesn't always happen, (un)fortunately. You can see it in action in the log below -- the last few lines are the interesting bit. I've tried fiddling around with a few things but I don't know the right way to fix it.

("Starting inferior stack GHCi process using stack" "haskell" nil "stack" "ghci" "--ghc-options=-ferror-spans")

-> :set prompt "\4"

-> Prelude.putStrLn ""

-> :set -v1

<- Run from outside a project, using implicit global config

   Using resolver: lts-2.15 from global config file: /home/chris/.stack/global/stack.yaml



<- Configuring GHCi with the following packages: 



<- GHCi, version 7.8.4: http://www.haskell.org/ghc/  :? for help



<- Loading package ghc-prim ... 

<- linking ... done.

   Loading package integer-gmp ... linking ... done.

   Loading package base ... linking ... done.



<- Prelude

<- > �

-> :cd /home/chris/elisp/others/haskell-mode/

<- 



<- ��

-> :load "/home/chris/elisp/others/haskell-mode/Test.hs"

<- �

<- [1 of 1] Compiling Test             ( /home/chris/elisp/others/haskell-mode/Test.hs, /home/chris/.stack/global/.stack-work/odir/Test.ghcio )

[gracjan]

As I understand how command queue is supposed to work is that it should follow strict request-response-request-response order. Pending commands should be queued. If what you say is true then that would explain some other transient bugs reports.

[cmears]

I investigated this some more and found that it should only be a problem at session start -- otherwise, all commands are run in the strict request-response order. See pull request #887 for a fix.