Issue can be reproduced by running cabal repl for Haskell Editor Setup project. Build instructions are here. After cabal repl loaded evaluate main and it will print following error:
<interactive>:1:1: error: Variable not in scope: main
You can see entire project at: Haskell Editor Setup project
The haskell-editor-setup.cabal has main-is: Main.hs so I do not understand why it is not activated on cabal repl run.
I am also using ide-haskell-repl Atom extension which gives a REPL inside Atom and it works fine even though it is set to run by using cabal repl.
I am not sure whether this is a bug in cabal or something I am doing wrong. Any advice on how to fix this?
Running :m *Main or :m +Main in cabal repl will fix the issue but what I am looking for is to fix cabal repl run so that it loads Main properly.
Related
I've previously used stack ghci app:exe:executable to get a list of any errors in my Haskell project managed via cabal.
However now that I'm not using stack, how would I achieve the above (essentially load all the modules from the executable defined in the cabal project file)?
https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-repl
cabal v2-repl executableNameGoesHere
I have following problem with ghc-mod which prevents me from using ide for some files in a yesod app project.
I install template app as follows:
/tmp$ stack new demo yesod-sqlite && cd demo
/tmp/demo$ stack setup && stack build && stack install ghc-mod
Which yields following stack.yaml (commented lines removed):
resolver: lts-5.6
packages:
- '.'
extra-deps: []
flags: {}
extra-package-dbs: []
And this is a demo.cabal: http://pastebin.com/i4n1TR6W.
Then, running stack exec -- ghc-mod check app/main.hs does not produce errors, but stack exec -- ghc-mod check app/devel.hs has this to say:
app/devel.hs:2:1:Failed to load interface for ‘Application’It is a member of the hidden package ‘demo-0.0.0’.Perhaps you need to add ‘demo’ to the build-depends in your .cabal file.
So the ghc-mod somehow thinks this package is itself hidden? But any other place where project's files are imported by another checks fine, and the application builds and works successfully. The only specifics about this file is using PackageImports language extension:
{-# LANGUAGE PackageImports #-}
import "demo" Application (develMain)
I tried googling the error message but it seems to only come up with regard to external packages and not the one being debugged.
These two files devel.hs and DevelMain.hs are quite special: they are marked as a module of demo in .cabal but they are importing demo as a compiled package, i.e. recursive dependency.
They are not exposed from library demo nor imported anywhere else so won't get compiled when you run stack build, but when you run ghc-mod check on them, they are interpreted in the context of the current project, therefore the recursive dependency will be an issue.
The only purpose of these two otherwise meaningless files is to debug your yesod website in ghci, as the comment in DevelMain.hs stated:
-- | Running your app inside GHCi.
--
-- To start up GHCi for usage with Yesod, first make sure you are in dev mode:
--
-- > cabal configure -fdev
--
-- Note that #yesod devel# automatically sets the dev flag.
-- Now launch the repl:
--
-- > cabal repl --ghc-options="-O0 -fobject-code"
--
-- To start your app, run:
--
-- > :l DevelMain
-- > DevelMain.update
--
-- You can also call #DevelMain.shutdown# to stop the app
--
-- You will need to add the foreign-store package to your .cabal file.
-- It is very light-weight.
--
-- If you don't use cabal repl, you will need
-- to run the following in GHCi or to add it to
-- your .ghci file.
--
-- :set -DDEVELOPMENT
--
-- There is more information about this approach,
-- on the wiki: https://github.com/yesodweb/yesod/wiki/ghci
cabal repl and stack ghci will compile the project beforehand so these two files won't cause any error there.
Using cabal repl seems to do nothing at all when used on library projects, but works fine for executable projects. Is this expected behavior that I just don't understand?
If I have a file containing simply
go = putStrLn "test"
and use cabal init with all the defaults (but choose "library" as the type), then running cabal repl just produces the some text about configuring and preprocessing the library and never enters a REPL environment. The exact same steps, but with "executable" selected as the type, puts me right into GHCi as expected.
The code works fine when loaded directly into GHCi.
For cabal repl to load your modules, you have to first name them in code and then specify them in your project's .cabal file as exposed:
-- MyModule.hs
module MyModule where
go = putStrLn "test"
-- MyProject.cabal
name: MyProject
-- other info ...
library
exposed-modules: MyModule
-- other options ...
Then when you run cabal repl, it'll have access to everything in your sandbox (if present) and the exposed modules. It might also work if you specify them as other-modules instead of exposed-modules, but I haven't tried that one out.
cabal sandbox init
cabal install haskeline
... installs successfully ...
ghci
Prelude> :module +System.Console.Haskeline
<no location info>:
Could not find module `System.Console.Haskeline'
ghc-pkg list haskeline
.. not found ..
What do I have to do get haskeline to work with cabal sandbox? If I install haskeline normally (no sandbox) it is fine (ghc-pkg list haskeline -- found it).
Either use cabal repl like Joseph mentioned or you can explicitly pass the package db to the GHCi shell relative to your current working directory.
ghci -no-user-package-db -package-db .cabal-sandbox/*-packages.conf.d YourModule.hs
It's recommended that you just use cabal.
In order to get ghci to use a local sandbox you must (a) set up a my-project.cabal file and (b) use cabal repl.
Unfortunately cabal-dev ghci does not work in this project, i get an error:
Loading package download-0.3.2 ... linking ...
ghc: /home/stulli/haskell/ifdl/cabal-dev//lib/download-0.3.2/ghc-7.4.1/HSdownload-0.3.2.o: unknown symbol `stat64'
ghc: unable to load package `download-0.3.2'
So i try runhaskell, but it uses the packages that come installed with cabal instead of cabal-dev and thus fails.
update:
runhaskell produces the same error:
$ runhaskell -isrc:src/test -package-conf=cabal-dev/packages-7.4.1.conf src/test/Test.hs
Test.hs: /home/stulli/haskell/ifdl/cabal-dev//lib/download-0.3.2/ghc-7.4.1/HSdownload-0.3.2.o: unknown symbol `stat64'
Test.hs: Test.hs: unable to load package `download-0.3.2'
cabal-dev install on the other hand works without problems.
You can try something like the next:
runhaskell -package-conf=cabal-dev/packages-7.0.3.conf main.hs
But I think if cabal-dev ghci doesn't work, then runhaskell will not work too. You need to find out what is wrong with download package.
To use runhaskell with cabal sandboxes (cabal >= 1.18), run the command
runhaskell -package-db=.cabal-sandbox/i386-windows-ghc-7.6.3-packages.conf.d <file.hs>
substituting the proper *-packages.conf.d directory for your GHC version.
The cabal-dev setup doesn't work very well for ghci, so it might very well be that it also doesn't work well for runhaskell. Maybe virthualenv will work better for this use case?