I have
mainLogger.hs
Logger.hs
in my local directory where the mainLogger.hs reference the Logger module.
When in stack ghci I :load mainLogger.hs I get the following error message :
mainLogger.hs:6:18:
Could not find module ‘Logger’
It is not a module in the current program, or in any known package.
However if I can compile stack exec -- ghc mainLogger.hs and run stack runghc mainLogger2.hs or have stack exec -- ghci load the module correctly.
Anyone knows what is preventing stack ghci from locating module in the local directory ?
ps : I am not using any cabal file or stack.yaml file in this directory, so it falls back onto my global stack.yaml config
You should be able to load both if you do it at the same time:
:load Logger.hs mainLogger.hs
I don't know if you can get GHCi to look for the missing module in the current folder if you have no cabal file but if you create/initialize one this is not necessary.
This issue should now be fixed in the latest version of stack. It seems that when a module imported a local module, stack wasn't including the local directory in its module search path. In the latest 1.5.1. version of stack, this has been fixed - so you should be able to just type
stack ghci mainLogger.hs
Related
I'm trying to start working on https://github.com/system-f/fp-course. After running stack ghci, it finishes with:
...
[51 of 51] Compiling Test.Loader ( src/Test/Loader.hs, interpreted )
Ok, 51 modules loaded.
Loaded GHCi configuration from /home/lpied/haskell/fp-course/.ghci
<no location info>: error:
module ‘main:Course’ is defined in multiple files: src/Course.hs
src/Course.hs
Failed, 51 modules loaded.
Loaded GHCi configuration from /tmp/haskell-stack-ghci/75d10d48/ghci-script
Any idea why it's complaining that the module is defined in the same file (src/Course.hs)?
Can you try using stack exec ghci instead? stack ghci is probably recognizing the src directory and adding -isrc to the ghci command line, and then the .ghci file in the course root directory is also adding -isrc to the ghci command line. GHC probably doesn't de-duplicate its search path, so it acts like you have two separate directories which both happen to be named src.
I have a .ghci in my local project directory, and another one in my $HOME. When I do a stack ghci, then $HOME/.ghci is loaded first, followed by $PWD/.ghci. Is it possible to have ONLY the local .ghci be loaded, and the global one ignored?
I could do a stack exec -- ghci -ignore-dot-ghci, but then, none is loaded.
What I also tried is:
stack exec -- ghci -ignore-dot-ghci -W .ghci
The idea being to first tell ghci not to load anything and then explicitly requesting the local .ghci file, but this gives the error message Warning: ignoring unrecognised input `.ghci'
GHCi has a -ghci-script flag which can be used alongside -ignore-dot-ghci. It can be used with stack ghci through --ghci-options:
stack ghci --ghci-options "-ignore-dot-ghci -ghci-script .ghci"
For the sake of completeness, here is the corresponding cabal repl invocation:
cabal repl --repl-options "-ignore-dot-ghci" --repl-options "-ghci-script .ghci"
Question
Is there a way to force stack to rebuild all local precompiled packages?
Context
I had a working stack installation but I've updated my ArchLinux (including kernel update) and I get this now:
stack ghci
Main.hs: <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libncurses.so (-lncursesw: cannot open shared object file: No such file or directory)
Since the given exists my guess is that the compiled version isn't linked correctly, that's why I try to rebuild everything.
I am trying to setup my Haskero (Visual Studio Code extension that uses Intero) for my Haskell project, yet I get the following error :
app\Main.hs:3:1: error:
Failed to load interface for `Lib'
Use -v to see a list of the files searched for.
Steps to reproduce:
stack new project
cd project
stack build intero
stack exec intero
> :l app/Main.hs
app/Main.hs :
module Main where
import Lib
main :: IO ()
main = someFunc
src/Lib.hs :
module Lib
( someFunc
) where
someFunc :: IO ()
someFunc = putStrLn "someFunc"
I had similar issue occuring in Visual Studio Code.
Under the hood Haskero properly uses:
stack ghci --with-ghc intero --no-build --no-load
However Haskero assumes that the stack project is the working directory loaded to VSCode. If instead the stack project is one of the subdirectories then the same error appears in IDE, because stack command is run from that main directory. At least it's what happens currently with Haskero 1.3.1.
The solution is to always make sure that stack project is equal to working directory in VSCode.
I don't have experience with Haskero but can duplicate the problem with a plain old Intero installation on a Linux machine.
The issue is that you're invoking the Intero backend via stack exec instead of stack ghci. You would observe the same problem if you tried using stack exec ghci instead of stack ghci to invoke a usual GHC interactive session (see the documentation for stack ghci for more information).
Instead of stack exec intero, try:
stack ghci --with-ghc intero --no-build --no-load
and it should work okay.
(Note that stack exec intero actually works okay if you stack build your project first, but the interactive session is still supposed to be invoked via stack ghci.)
I created a very simple project with stack. It contains: an executable, a library and test targets in the associated cabal file. When I load the code to ghci via stack ghci, I can't access test there, even if they are in separate module. Is there any way to use it in such a way?
Try stack ghci (your project name):(the test suite name). Then you should be able to enter main and your tests will run.
Example:
If your .cabal project file had the following values:
name: ExampleProject
...
test-suite Example-test
Then the command to run would be stack ghci ExampleProject:Example-test
(edit suggested by #Chris Stryczynski)
To watch the test and src directories so they are updated when you reload with :r, run:
stack ghci --ghci-options -isrc --ghci-options -itest ExampleProduct:Example-test