Installing on Windows

[ncreep]

Hi,

I tried installing ide-backend on Windows, but the dependency on the unix package fails the whole process (even when using Cygwin).

So, are there any workarounds for getting ide-backend to work on Windows?

Thanks.

[snoyberg]

Not yet. It's a known limitation that the library does not work on windows
due to usage of features like named pipes. There is interest in fixing
that. At the very least, the yesod devel gsoc project will be interested in
doing so. Would you be interested in working on this too?

On Tue, May 19, 2015, 8:28 AM ncreep notifications@github.com wrote:

Hi,

I tried installing ide-backend on Windows, but the dependency on the unix
package fails the whole process (even when using Cygwin).

So, are there any workarounds for getting ide-backend to work on Windows?

Thanks.

—
Reply to this email directly or view it on GitHub
#279.

[ncreep]

I would be interested in taking a stab at this issue, but I have no experience with such things. Maybe with some initial guidance I can get into it. Is there some simple, self-contained problem that you can point me to to get me started?

[snoyberg]

My guess is that the best place to start is to make the unix dependency conditional on OS and see where things break. Some things may be solvable by using unix-compat.

Pinging @mgsloan and @urbanslug on this, perhaps we can use this issue as the base-of-operations for Windows support.

[ncreep]

Thanks for the pointer, I'll be looking into it soon.

[urbanslug]

@snoyberg Do you want this worked on right away?

@ncreep Give me a few hours to set up a windows environment and we could work together if that's okay with you. Is it okay with you? I could just do it on my own if you're busy or something.

[ncreep]

@urbanslug I'm definitely okay with it. As I mentioned earlier, I really don't have any experience with these things, so any help/guidance is most welcome.

In the meantime, a naive swapping of unix with unix-compat reveals that unix-compat doesn't have an IO package...

[ncreep]

Also, I see that the Darcs repository has an IO package for Windows. Could this be a direction worth pursuing?

[snoyberg]

@urbanslug If @ncreep is taking a crack at it, it's worth spending some time to make sure it will address the use cases the GSoC has. But I'd focus on the simpler requirements for now (like automatic data file discovery).

@ncreep Unfortunately, I doubt that .IO module will be much help, as the features ide-backend is using are (to my knowledge) not covered there.

[mgsloan]

Yes feel free to add windows support, it'd be great to have!

We would indeed need an alternative to named pipes. Looks like windows has such a thing, but they aren't in the filesystem, and you need to use a special API for IO for them. This seems ugly and I'm not sure if there are haskell bindings for it.

Another possibility is to use a localhost network connection. I don't think we'd want to do this when we posix pipes are available, though, as it'd be a bit less efficient. This approach has the advantage of also making it easier to support non-posix / non-windows OSes, down the road.

[urbanslug]

@ncreep Email me at the email address in my profile so that I may contact you and discuss this further.

[ncreep]

@mgsloan is the work going on in the soh branch makes ide-backend closer to being compatible with non-Unix platforms?

[mgsloan]

@ncreep Nope, that's my branch for the School of Haskell, which will be merged in when it's ready. It adds support for running code with a unix pty. So, it actually makes it less compatible with non-unix platforms.

I wanted this because I'm using term.js as a terminal emulator in the browser. This it lets you use things like ghci, ncurses based apps, etc.

I imagine this feature would probably be disabled for windows, unless there's a way to do something like forkpty in windows (note: this isn't how the feature is implemented, but it's essentially the same thing. My implementation uses forkProcess

[ncreep]

Okay, thanks for the detailed response.

So I'm guessing that using a localhost network connection as you suggested before is the most reasonable direction to pursue.

[ncreep]

So I started (naively) playing around with the sockets idea. My aim was to just imitate whatever was being done with pipes (and figuring out what it is that they are doing along the way). Going in this direction, it seems like I'd have to use port numbers in the same way that the pipes code uses temporary files. This doesn't seem like a good idea, since I can imagine that there can be many clients connecting to one server, and having a port for each one seems excessive.

A more complicated direction would be to use a single port (on the server) and then let every client connect with some unique id. The id would be used to dispatch the messages from the server to the various clients. This sounds like overkill compared to the simplicity of named pipes.

Am I missing something very simple, or is it going to be a full-blown inter-process communication thing?

[snoyberg]

This doesn't seem like a good idea, since I can imagine that there can be many clients connecting to one server, and having a port for each one seems excessive.

There's only ever one ide-backend talking to one ide-backend-server. But even if that wasn't the case, you have tens of thousands of port numbers; using a few extra doesn't seem like a big deal.

[ncreep]

Doesn't the concurrentConversation function implies that there can be many connections going on concurrently?

[snoyberg]

I'm not sure of the details there, it would be nice if @edsko could clarify. I don't believe it is intended to support multiple connections to a single server, though.

[edsko]

Yes and no. When the server starts there is a single conversation to that server. Whenever the client requests to run a snippet, the server starts an auxiliary "concurrent" conversation (which uses its own set of named pipes), sends the names of those pipes back to the client, and then forks off an auxiliary server which will be running the snippet. The main server keeps communicating on the original conversation, and the auxiliary server, which runs only for the duration of the snippet, communicates over the new concurrent conversation.

[ncreep]

Okay, so if we are using potentially more than one port, the code needs to figure out how to find an available port. Is there anything more elegant than trying to bind a port and if it throws an exception retry with another port number?

[snoyberg]

Binding to port 0 seems to work on Windows:

{-# LANGUAGE OverloadedStrings #-}
import Data.Streaming.Network
import Network.Socket

main :: IO ()
main = bindPortTCP 0 "*" >>= socketPort >>= print

[ncreep]

Thanks, didn't know that.

[ncreep]

Yet another question (sorry for asking so many questions...): while browsing the code I stumbled upon the CreatePipe module. Am I correct in understanding that it provides the createPipe functionality on Windows? I.e., does that mean that that forkRpcServer can use it to work on Windows unmodified?

[mgsloan]

Hi! No worries on the questions, sorry for the delay in answering. CreatePipe is a module in cabal that does seem to provide some compatibility for this. It may indeed be feasible to use this mechanism to add windows support, but I'm not sure. Worth a shot!

[ncreep]

Thanks, no problem about the delay, I'm currently away from a development environment anyway.
Hopefully I'll get to looking into in about a week or so.

[ncreep]

That's probably me not really understanding the code flow (and how pipes work), but why do the connectToRpcServer and concurrentConversation functions need to use named pipes instead of anonymous pipes?
If we are able to pass around file descriptors when starting the server, why can't we do the same for concurrent conversations?

[mgsloan]

That's a good question! I don't know of a particular reason for that, but I didn't write the code. So, there may be a reason. Maybe @edsko or @Mikolaj know?

[edsko]

I don't follow. If by anonymous pipes you mean file descriptors, how would the server share file descriptors with the client? They are only inherited at process startup. Sure, I could send the number of a file descriptor to a process, but that doesn't mean that number would refer to a valid file descriptor in that process.

[mgsloan]

Ah, I see, that makes perfect sense, thanks! I didn't realize that's how file descriptors work.

[ncreep]

Okay, thanks. I somehow thought that there's more flexibility in passing file descriptors when the processes have a child/parent relationship (after the fork).
Anyways, I guess that means that I'll have to abandon trying to use CreatePipe for this purpose. Back to sockets it is.

[ncreep]

So I made some progress: managed to rewrite the communication parts in ide-backend and ide-backend-common to use sockets (but not in server and rts). I gave up, for the moment, on writing something that uses named pipes on Unix, the code got me too confused. Doing only sockets is an easier first step for me.

In order to test the changes, I tried to compile both projects and found further complicating issues:

• Usages of plain createPipe, though not for server/client communication, I ported the code to use a version of Cabal's CreatePipe.
• The various swizzle* functions. They use dup and dupTo, not sure where to get those on Windows, though I'm quite sure that mingw should have C implementations for those. For the moment, I just commented out all usages of swizzle*.
• Usages of sigKILL and the corresponding pids all over the place (regular code and tests). I'm hoping that it's possible to replace those with something portable from System.Process, but I didn't look further into it. Again, I just commented out the offending pieces of code.

As a result, I was able to compile and run rpc-server.hs (with the various process killing tests commented out). The tests, including the concurrent conversation one, pass. Setting up the full test suite is beyond my mental capabilities... Which means, among other things, that I'm not sure whether the createPipe replacement is actually working.

Going further, is it possible for the sockets solution to completely replace named pipes? The advantages are:

• The code with sockets is a little bit simpler (no openFileFor* functions).
• Fitting named pipes and sockets into the same mold will probably lead to even more complicated code.

Regarding the efficiency issue, we could use AF_UNIX sockets when compiling on Unix systems. They, supposedly, should be more efficient than proper network communication. Though I don't know how they compare to named pipes in efficiency.

Also, any pointers on how to resolve the above-mentioned would be most appreciated.

[mgsloan]

Due to historical reasons, these errors are reported by getSourceErrors, as messages labeled with KindServerDied (instead of being ghc errors or warnings). This decision can be revisited.

I will need to dig into the code more than my tired brain can right now to determine exactly how server-side exceptions are handled. I thought they were written to a log file and read by the client, but I can't find the relevant code right now.

[mgsloan]

Also, I've attempted to make the stream error messages a bit less obtuse: 2a2ccee

[ncreep]

Sorry for taking so long to reply, I was away from a proper development environment for a while.

The migration to stack seems to be throwing me off. I can't compile on nightly-2015-07-29, I get duplicate symbols coming from Cabal-ide-backend and the regular Cabal package. Reverting back to lts-2.18 I can compile again, but things still behave strangely:

• When I do stack ghci I get Unsupported GHC version while compiling GhcShim.hs. Even if I ignore this, loading a file hits ambiguous imports from Cabal-ide-backend and Cabal, so I can't run anything that depends on the project.
• While I can do stack ghc from the root directory, doing so from the ide-backend directory hits an import error when importing something from Cabal-ide-backend, which appears to be hidden for some reason.
• Running stack test from the root directory suppresses all output until the test suites finish. This makes it unusable for me since TestSuite hangs midway. On the other hand, running stack test in the ide-backend directory does produce output right away.

Anyways, the actual result of running TestSuite is that I still get a mallocPlainForeignPtrByte exception on various occasions.
Also, at least on one occasion, running stack test and running the the TestSuite binary directly produced different results. In one a test failed with Data.Binary.Get.runGet at position 1: demandInput: not enough bytes while in the other it was a regular test failure with Unexpected errors: ....

[mgsloan]

When I do stack ghci I get Unsupported GHC version while compiling GhcShim.hs. Even if I ignore this, loading a file hits ambiguous imports from Cabal-ide-backend and Cabal, so I can't run anything that depends on the project.

Seems like maybe there's an issue with cabal flags and ghci support. Stack's support for ghci is still quite WIP.. In the meantime maybe use cabal repl?

Running stack test from the root directory suppresses all output until the test suites finish. This makes it unusable for me since TestSuite hangs midway. On the other hand, running stack test in the ide-backend directory does produce output right away.

Yeah, this isn't so ideal. There's a relevant discussion here: commercialhaskell/stack#426

I just open up .stack-work/logs/ide-backend-0.10.0-test.log. For me, the test suite finished, but with a smattering of failures which I'm currently investigating.

[ncreep]

In the meantime maybe use cabal repl?

... and I thought that stack will be a remedy to all my earthly woes...

There's a relevant discussion here: commercialhaskell/stack#426

Running the tests in the ide-backend directory is acceptable from my point of view, since I don't need anything else at the moment. But good to know that the output thing is not some esoteric bug that only I'm experiencing.

For me, the test suite finished, but with a smattering of failures which I'm currently investigating.

Holding my fingers crossed that this might resolve some issues on my end.

[ncreep]

Another peculiar thing is that running the tests with --no-session-reuse -j1 makes TestSuite hang much earlier than it would without these flags.

[mgsloan]

... and I thought that stack will be a remedy to all my earthly woes...

Certainly ought to remedy all your cabal-install woes! The GHCI feature is just not a priority, and Chris has been busy. Fixes welcome, of course! Some of these fixes will also be helpful for the stack ide functionality.

But good to know that the output thing is not some esoteric bug that only I'm experiencing.

Yeah, sorry it got into this state. I didn't realize travis wasn't actually running the tests.

Holding my fingers crossed that this might resolve some issues on my end.

My fixes have pretty much all been to the test suite itself, making it automatically run well under stack test (usually something that requires no work, but when package databases etc come into play..). Also fixing a few things here and there in the test suite broken by recent changes.

For me the test-suite passes for GHC 7.10.2. Travis is showing failures for GHC 7.10.1 / 7.8.4, but I haven't quite gotten around to addressing those.

Once nice thing is that testing with 7.8 is now as easy as stack test --stack-yaml=stack-7.8.yaml

[ncreep]

The GHCI feature is just not a priority, and Chris has been busy. Fixes welcome, of course! Some of these fixes will also be helpful for the stack ide functionality.

My nitpick with stack ghci should not detract from the fact that I do actually appreciate stack very much.
Trying to fix whatever went wrong with stack ghci is still somewhat above my Haskell skill set. Hopefully this might change in the not so distant future...

My fixes have pretty much all been to the test suite itself, making it automatically run well under stack test

Sadly, the tests on Windows still run the same. Thanks for the stack-7.8.yaml file, that works out nicely, though I still wonder why I can't build with stackage nightly.

@urbanslug and whomever wants to try and run the windows branch, I fixed to the socket code so that it doesn't throw the getAddrInfo anymore (all it took is to explicitly specify localhost instead of an empty host). So it's now possible to start running the tests on Linux as well.

Having done that, all tests pass till the
Relative include paths (#156) with dynamic include path change:
test, where it throws a
ide-backend-server: Data.Binary.Get.runGet at position 1: depmandInput: not enough bytes
error and then hangs.

[ncreep]

I've managed to track down the reason why the mallocPlainForeignPtrByte error suppresses the exception thrown by the server.

The exception itself is thrown in Stream.hs here. Since this is not an IOException (unlike the the other errors in Stream here), the mapIOToExternal function that is responsible for fetching the server side errors ignores it and let's it bubble up back to the tests.
Cheating and somehow wrapping this exception into an IOException does trigger a proper ExternalException with the correct error message from the server.

The question now is, how come BSS.hGetSome throws this exception, instead of stumbling on an empty byte string (which is what I would expect when the server throws an exception)?
Also, how do the tests handle the case when the server crashes unexpectedly? Can the state of the remaining tests after the crash be corrupted by such an event?

[ncreep]

I think I now have the mallocPlainForeignPtrByte exception pinpointed:
On Windows, if you have a handle to a socket and you terminate the process on the other end, then reading from the handle throws this exception. This is not the case on Linux where it just reads an empty string. Since the handle is not marked in any special way (e.g., hIsEOF returns false), I would say that this is a bug, not sure whether in Network or IO.

So what do we do with it, just swallow the exception and pretend that it returned an empty string? Or is there a legitimate scenario where the exception from the offending line should be propagated as is?

[ncreep]

As I mentioned earlier passing --no-session-reuse to TestSuite makes it hang on the second test. So the commit dd6ea79 gets me completely stuck.

It seems that running any single test without session reuse on WIndows gets it stuck. Which is not the case when running the sockets implementation on Linux.

[ncreep]

I take my statement from above back, not every test fails when not reusing sessions, it's the tests that try to run statements on the server, which at the moment fails with an exception.

Given how much throwing an exception from the server complicates things, I think that I'll try implementing an alternative solution where instead of throwing an exception the server will send some erroneous value back to the client, and let the client handle the rest.

But in any case, the fact that exceptions mess things up so much should probably be addressed somehow.

[mgsloan]

The test-suite should pass reliably now - travis passes! https://travis-ci.org/fpco/ide-backend

While this is a bit hacky, one thing to note is that now --no-session-reuse is always on, until bugs such as #257 are resolved.

I agree that the error handling for the server should be revisited. It's unfortunate how so many errors manifest as "demandInput: ..." errors on the client.

[ncreep]

Congrats on getting travis to work.

I've implemented what I described above, so now the client gets to handle the fact that command running is not supported on Windows. With this in place --no-session-reuse doesn't bite me anymore (and it's much easier to deal with a local exception in the test suite, as opposed to a remote one).

But TestSuite still behaves strangely. I get sproadic Irrefutable pattern failed and demandInput failures (plus some others) and TestSuite hangs at random places, never reaching the end (even when using -j1).

Also, there's some inconsistency with file path separators, so sometimes paths like a/b/c\d.hs crop up. It was causing failures at one point (where a function explicitly looks for /), for which I've implemented a hacky workaround, but this should probably be addressed in a more consistent manner.

[ncreep]

I stumbled upon something really weird, I'm trying to get the "Make sure we can terminate the IDE session when exe is running" to work. It seems that the test ignores some side effects, namely the forceCancel side effect (and also print commands around that line). Though the executable is created and run.
Running a standalone program with the same content from the REPL works fine.

Any suggestions as to what could've gone wrong?

[mgsloan]

I've rebased and pushed the windows branch to the fpco repo, and here's the travis results: https://travis-ci.org/fpco/ide-backend/builds/75006301 . Note that you can also add your repo to travis.

Looks like there's just one test failure, good work!

     #220: Calling forceCancel can have detrimental side-effects:                                          FAIL (14.29s)
        expected: RunOk
         but got: RunGhcException "External exception: <file descriptor: 1024>: hGetBufSome: invalid argument (Invalid argument). Local exception: user error (IdeSession.RPC.Stream ended, causing not enough bytes)"

I'm not sure what's going on here, but without digging in to the code, my guess is that killing the forked process is causing the stream to close. Maybe that hGetBufSome ought to be wrapped in some exception handling?

But TestSuite still behaves strangely. I get sproadic Irrefutable pattern failed and demandInput failures (plus some others) and TestSuite hangs at random places, never reaching the end (even when using -j1).

Is this with windows or on linux? Does your branch of ide-backend function on windows?

[ncreep]

Looks like there's just one test failure, good work!

Thanks. Nice to see that there are less errors than on my Linux VM. Strangely, the error that I get for that test is:

expected: RunOk
         but got: RunGhcException "External exception: createPipe: resource exhausted (Too many open files). Local exception: user error (IdeSession.RPC.Stream ended, causing not enough bytes)"

It seems that socket handles are not nice when they're forcibly closed. I'll have a bit of hard time fixing this test, since it's skipped on Windows anyways (because of runStmt), and doing anything on my Linux VM is clunky.

Is this with windows or on linux? Does your branch of ide-backend function on windows?

That's already outdated, I've managed to fix the Irrefutable pattern failed errors (as I mentioned in an email). The most pertinent issue at the moment is the problems with forceCancel that I described in the next message.

Related to the above, generally, it seems that when some test fails unexpectedly with an exception, it can potentially freeze the rest of TestSuite, though not always. It won't be an issue if I ever manage to fix the rest of the tests, but it still feels that there's something wrong there.

[lukexi]

How's this going? I was going to give getting stack-ide-sublime working on Windows a whirl sometime soon — is your branch mostly functional??

Thanks so much for tackling this!! : )

[ncreep]

@lukexi I think that the windows branch is mostly functional, but there are still things to iron out. On Linux, there's a single failing test which I've yet to figure out. On Windows there are more failures, which I'll get to tackling once I'm done with the above mentioned test.

Also, as it stands, there are features of ide-backend that are completely disabled on Windows, those are snippet evaluation and pty support.

If you want to be doing anything off my branch, notice that I abuse it occasionally, e.g. resetting and rebasing.

[ncreep]

@mgsloan I've finally managed to tackle the #220: Calling forceCancel ... bug.
The solution was swallowing exceptions when trying to read some stdout handle.
But the bug itself seems to be this severely weird race condition, which I wasn't able to pinpoint. What I do know is:

• That it appears only when the whole of TestSuite is run (or at least most of it, I wasn't able to find a minimal set of tests to include whilst retaining the bug).
• The broken test must appear in the right order, moving it around the test suite makes it disappear.
• It should be run with at least -j2.
• If the the environment that runs it has only a single processor, the bug disappears, no matter what value of -j is used.

Anyhow, at the moment, it seems that the build is working. Though I do occasionally have problems with the script for 7.8, which randomly fails before actually running anything or gets stuck typically around the Concurrent snippets tests. Rerunning the tests usually works.

[ncreep]

Given the above, I would like to open up for consideration the merging of my fork into master.

Although there are still quite a few issues to iron out when running on Windows (apart from the completely disabled snippet running functionality), I think that most of the functionality is there.

Regarding Linux, there's still the question of whether it's okay to use regular sockets, or should they be replaced with Unix domain sockets. Is there anyway to benchmark the performance hit (if any) from using sockets as compared to the original pipes implementation?

[mgsloan]

@ncreep Cool, looks good to me, awesome work! I'm using it locally with stack-ide, and so far it's working fine. I'm in favor of merging soon, how about opening a PR from your branch to master?

Ideally we'd use unix domain sockets, but that can be a separate issue, and shouldn't block merging this in.

[ncreep]

PR opened. Might look into the Unix sockets thing soon.

[dgpratt]

I'm not sure how all these pieces fit together, so I'm not sure this has any relevance to ide-backend on Windows. With that disclaimer out of the way, I tried to run "stack ide" on Windows using the "windows" branch of ide-backend. In brief, I couldn't get it to work.

In not so brief, I tried to run "stack ide" within a stack project. It generated the following output:

{"tag":"ResponseWelcome","contents":[0,1,1]}
{"tag":"ResponseLog","contents":"[Info] Initializing ide-backend session @(ideba_DRjamzh8Lym4GSkmicp2ET:IdeSession.Update .\\IdeSession\\Update.hs:196:3)\n"}
{"tag":"ResponseLog","contents":"[Debug] Session dir = C:\\Users\\dpratt\\Documents\\Projects\\Prototypes\\Snap\\session.34660 @(ideba_DRjamzh8Lym4GSkmicp2ET:IdeSession.Update .\\IdeSession\\Update.hs:209:3)\n"}
{"tag":"ResponseLog","contents":"[Debug] Dist dir = C:\\Users\\dpratt\\Documents\\Projects\\Prototypes\\Snap\\.stack-work\\dist\\x86_64-windows\\Cabal-1.22.4.0\\ @(ideba_DRjamzh8Lym4GSkmicp2ET:IdeSession.Update .\\IdeSession\\Update.hs:211:3)\n"}
{"tag":"ResponseLog","contents":"[Debug] Local working dir = C:\\Users\\dpratt\\Documents\\Projects\\Prototypes\\Snap\\ @(ideba_DRjamzh8Lym4GSkmicp2ET:IdeSession.Update .\\IdeSession\\Update.hs:218:17)\n"}
{"tag":"ResponseFatalError","contents":"user error ('C:\\Users\\dpratt\\AppData\\Local\\Programs\\minghc-7.10.2-x86_64\\ghc-7.10.2\\bin\\ghc-pkg.exe' exited with an error:\nghc-pkg.exe: C:\\Users\\dpratt\\AppData\\Roaming\\stack\\snapshots\\x86_64-windows\\lts-3.0\\7.10.2\\pkgdb\\:C:\\Users\\dpratt\\Documents\\Projects\\Prototypes\\Snap\\.stack-work\\install\\x86_64-windows\\lts-3.0\\7.10.2\\pkgdb\\: getDirectoryContents: invalid argument (The filename, directory name, or volume label syntax is incorrect.)\n)"}

I ran a trace during this process and determined that stack-ide was launched with the following command line (reformatted with line breaks):

"C:\Users\dpratt\AppData\Roaming\local\bin\stack-ide.exe"
"--verbose"
"--local-work-dir=C:\Users\dpratt\Documents\Projects\Prototypes\Snap\\"
"--ide-backend-tools-path=C:\Users\dpratt\Documents\Projects\Prototypes\Snap\.stack-work\install\x86_64-windows\lts-3.0\7.10.2\bin\:C:\Users\dpratt\AppData\Roaming\stack\snapshots\x86_64-windows\lts-3.0\7.10.2\bin\:C:\Tools\cmder\vendor\conemu-maximus5;C:\Tools\cmder\vendor\conemu-maximus5\ConEmu;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\CollabNet Subversion Client;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\cURL\bin;C:\Python27;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.1\;C:\Program Files (x86)\WinMerge;C:\Program Files (x86)\Heroku\bin;C:\Program Files (x86)\git\cmd;C:\Program Files\Calibre2\;C:\Users\dpratt\.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files\TortoiseHg\;C:\ProgramData\chocolatey\bin;C:\Program Files (x86)\Git\cmd;C:\Users\dpratt\.dnx\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\nodejs\;C:\Users\dpratt\Tools\bin;C:\Users\dpratt\AppData\Local\Programs\minghc-7.10.2-x86_64\switch;C:\Users\dpratt\AppData\Local\Programs\minghc-7.10.2-x86_64\git-2.4.5.1\cmd;C:\Users\dpratt\AppData\Local\Programs\minghc-7.10.2-x86_64\git-2.4.5.1\usr\bin;C:\Users\dpratt\AppData\Roaming\cabal\bin;C:\Users\dpratt\AppData\Local\Programs\minghc-7.10.2-x86_64\ghc-7.10.2\mingw\bin;C:\Users\dpratt\AppData\Local\Programs\minghc-7.10.2-x86_64\ghc-7.10.2\bin;C:\Users\dpratt\AppData\Local\Programs\minghc-7.10.2-x86_64\bin;C:\Users\dpratt\.dnx\runtimes\dnx-clr-win-x86.1.0.0-beta6\bin;C:\Users\dpratt\.dnx\bin;C:\Users\dpratt\AppData\Roaming\local\bin;C:\Users\dpratt\AppData\Local\Code\bin;C:\Users\dpratt\AppData\Roaming\npm;C:\Users\dpratt\AppData\Local\atom\bin"
"--dist-dir=C:\Users\dpratt\Documents\Projects\Prototypes\Snap\.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\\"
"--ghc-option=-hide-all-packages"
"--ghc-option=-Wall"
"--ghc-option=-fwarn-tabs"
"--ghc-option=-funbox-strict-fields"
"--ghc-option=-fno-warn-orphans"
"--ghc-option=-fno-warn-unused-do-bind"
"--ghc-option=-iC:\Users\dpratt\Documents\Projects\Prototypes\Snap\\"
"--ghc-option=-iC:\Users\dpratt\Documents\Projects\Prototypes\Snap\src\\"
"--ghc-option=-iC:\Users\dpratt\Documents\Projects\Prototypes\Snap\.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\autogen\\"
"--ghc-option=-iC:\Users\dpratt\Documents\Projects\Prototypes\Snap\.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\\"
"--ghc-option=-stubdir=C:\Users\dpratt\Documents\Projects\Prototypes\Snap\.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\\"
"--ghc-option=-optP-include"
"--ghc-option=-optPC:\Users\dpratt\Documents\Projects\Prototypes\Snap\.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\autogen\cabal_macros.h"
"--ghc-option=-package=bytestring-0.10.6.0"
"--ghc-option=-package=heist-0.14.1.1"
"--ghc-option=-package=MonadCatchIO-transformers-0.3.1.3"
"--ghc-option=-package=mtl-2.2.1"
"--ghc-option=-package=snap-0.14.0.6"
"--ghc-option=-package=snap-core-0.9.7.2"
"--ghc-option=-package=snap-server-0.9.5.1"
"--ghc-option=-package=snap-loader-static-0.9.0.2"
"--ghc-option=-package=text-1.2.1.3"
"--ghc-option=-package=time-1.5.0.1"
"--ghc-option=-package=xmlhtml-0.2.3.4"
"--ghc-option=-package=base"
"--ghc-option=-package=lens-4.12.3"
"--package-db=C:\Users\dpratt\AppData\Roaming\stack\snapshots\x86_64-windows\lts-3.0\7.10.2\pkgdb\:C:\Users\dpratt\Documents\Projects\Prototypes\Snap\.stack-work\install\x86_64-windows\lts-3.0\7.10.2\pkgdb\\"

At some point, this stack-ide process attempted to access a file with path C:\Users\dpratt\Documents\Projects\Prototypes\Snap\"C:\Users\dpratt\AppData\Local\Programs\minghc-7.10.2-x86_64\ghc-7.10.2\bin\, which is obviously not a valid path.

[ncreep]

@dpratt71 I think that this issue on stack-ide is the place to track progress on the problem that you stumbled upon.

[mgsloan]

I'm going to close this out, since it's implemented. Thanks again, @ncreep !