search

HeinrichApfelmus / hyper-haskell

The strongly hyped Haskell interpreter.
Other
363 stars 24 forks source link

Can't run interpreter with my GHC setup #18

Open sebeaumont opened 7 years ago

sebeaumont commented 7 years ago

How ever I build the back end, stack or cabal sandbox -- when I start the front end and ask for a new worksheet I get the following error: WontCompile [GhcError {errMsg = "<no location info>: error:\n Could not find module \8216Hyper\8217\n Use -v to see a list of the files searched for."}] hyper-haskell-server: hyper-haskell-server: signal: 15 Interpreter stopped (Exit code 1)

HeinrichApfelmus commented 7 years ago

That's weird. The message indicates that the hyper-haskell-server executable can run, so the hyper package should be installed as well (it's a dependency).

EDIT: Added link to and quoted the blog post on stack

It may be a visibility issue. Which version of stack are you using? In a recent blog post, titled "Conflicting module names", it was mentioned that packages may be hidden by default in newer versions of the stackage database:

We now have the ability to list some packages as hidden in a Stackage snapshot. This means that, after installing the package, the Stackage build system will hide the package, so that its modules won't be available for import.

I don't know how this is relevant to your issue or not.

Can you go to the directory where the stack.yaml file that you have pointed HyperHaskell to resides, and execute the command

stack exec ghc-pkg list

?

sebeaumont commented 7 years ago

hmm -- this is stack: Version 1.3.2 x86_64 hpack-0.15.0 and right enough the visible packages are just my project ones... I'll dig around a bit and see if the packages are really there.

sebeaumont commented 7 years ago

I don't really understand what stack is up to -- seems to install stuff in various places I might have a clear out (I thought stack was supposed to fix all this nonsense) can Hyper be installed in a cabal sandbox?

HeinrichApfelmus commented 7 years ago

No idea either. Using Hyper from a cabal sandbox is currently not implemented, only vanilla cabal for now. But I'm happy to accept patches, it's mainly a matter of figuring out the right paths.

sebeaumont commented 7 years ago

I can take a look. I guess we can figure out which ghc version the server was built with and then constrain it to look for appropriate packages within given paths.

sebeaumont commented 7 years ago

I built the Haskell backend etc. from master using the following:

seb@psi:hyper-haskell 1347> ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1.20161213

seb@psi:hyper-haskell 1341> stack --stack-yaml=haskell/stack.yaml --resolver=lts-7.14 --system-ghc build

And can thus run it as:

seb@psi:hyper-haskell 1345> stack --stack-yaml=haskell/stack.yaml --resolver=lts-7.14 --system-ghc exec hyper-haskell-server Setting phasers to stun... (port 8024) (ctrl-c to quit) Waiting for Haskell expression

I'm using the os-x binary front end which still doesn't seem to work with this server -- will I have to rebuild that? How does the front end start/communicate with server? Can it be configured to use the stack command as above? I think the original error might be spurious...

BTW ^c does not quit the server as advertised. As a general question do you know if can stack.yaml be configured to use different resolvers depending on the ghc in use?

sebeaumont commented 7 years ago

Ah I see that the stack command is hardwired in interpreter.js... explains why this could never have worked with ghc-8.0.1 we need to be able to configure the entire command or have stack.yaml do the right thing... or indeed cabal sandboxes