I've set up my environment as instructed in quick start guide (http://www.yesodweb.com/page/quickstart) without any obvious troubles on my 64bit Window 7 machine.
I then run the following (which execute fine)
"yesod init"
"cabal install --enable-tests --reorder-goals --max-backjumps=-1 -j"
However when I run "yesod devel" I find it stuck (not doing anything) showing following message:
> yesod devel
Yesod devel server. Press ENTER to quit
yesod: DeleteFile "C:\\Users\\USER~1\\AppData\\Local\\Temp\\10445.o": does
not exist (The system cannot find the file specified.)
Mentioned temp file does not exist in the Temp folder.
I tried looking at yesod source code to see what it does but not sure if that helps:
putStrLn $ "Yesod devel server. " ++ terminator ++ " to quit"
void $ forkIO $ do
filesModified <- newEmptyMVar
void $ forkIO $
void $ watchTree manager "." (const True) (\_ -> void (tryPutMVar filesModified ()))
evalStateT (mainOuterLoop develHsPath iappPort filesModified) Map.empty
after
writeLock opts
exitSuccess
I had the same issue as yours and I've even reported it: https://github.com/yesodweb/yesod/issues/949
The problem gone after flushing the cabal package cache and rebuilding everything from scratch. This is definitely an environmental issue.
Also if you're experiencing anything like this, be sure to check PATH if there are some 3rd-party gcc installations in it.
Related
I'm working on a team project using Haskell and whenever I compile our project using 'cabal install' I start seeing the following:
$ cabal clean && cabal install
cleaning...
Resolving dependencies...
Configuring hackathon-0.1...
Building hackathon-0.1...
Preprocessing executable 'hackathon' for hackathon-0.1...
[ 1 of 65] Compiling Data.MaybeUtil ( src/Data/MaybeUtil.hs, dist/dist-sandbox-52369b17/build/hackathon/hackathon-tmp/Data/MaybeUtil.o )
[ 2 of 65] Compiling Data.JQL ( src/Data/JQL.hs, dist/dist-sandbox-52369b17/build/hackathon/hackathon-tmp/Data/JQL.o )
[ 3 of 65] Compiling Data.Tuples ( src/Data/Tuples.hs, dist/dist-sandbox-52369b17/build/hackathon/hackathon-tmp/Data/Tuples.o )
...
$
However, my team members see:
$ cabal clean && cabal install
cleaning...
Resolving dependencies...
Configuring hackathon-0.1...
Building hackathon-0.1...
Installed hackathon-0.1
What is different in their configuration that they don't see all of the "Progress" messages that start with [X of N] My.Module?
I would really like them to be able to see the progress of the compilation as it is happening as our project is quite large and currently has 65 modules and growing. Cheers!
When you run cabal install multithreaded (-j2 and up), single file compilation does not appear on stdout, but should still be written to the log file.
Okay, I decided to just look at the source code and answer my own question. After diving through the cabal-install source code and ending up inside the GHC source I eventually found what I was looking for at the bottom of compiler/main/HscMain.hs:
showModuleIndex :: (Int, Int) -> String
showModuleIndex (i,n) = "[" ++ padded ++ " of " ++ n_str ++ "] "
where
n_str = show n
i_str = show i
padded = replicate (length n_str - length i_str) ' ' ++ i_str
This is the method that prints the Module Index. It is used inside a function called batchMsg which wraps it with a method called compilationProgressMessage:
compilationProgressMsg :: DynFlags -> String -> IO ()
compilationProgressMsg dflags msg
= ifVerbose dflags 1 $
logOutput dflags defaultUserStyle (text msg)
As you can see this method only prints things to the log output filestream if the verbosity is one or higher.
So I have just tried to do this in my terminal:
cabal install -j4 -v1
And then if I tail -f the .cabal-sandbox/logs/package-name.log file then I can see the module indexed compilation messages happening. I think that this solves this problem. Then, when the compilation finishes (or errors out) all of the module messages get printed to stdout. It seems that something is blocking print calls to stdout in parallel compilation in GHC. There is also something that sets the verbosity to 0 when you turn on parallel compilation. I think that both of these are bugs and should be fixed so I may go and try and raise feature requests now.
At any rate I hope that this investigation helps somebody else too. Cheers and thanks for the pointers everybody!
I'm pretty new to Haskell, and trying to install Yesod with Cabal, but I'm running into this compilation error:
cabal install yesod --force-reinstalls
Network/Wai/Parse.hs:106:61:
No instance for (Control.Monad.Trans.Resource.Internal.MonadThrow
(ConduitM S8.ByteString Void IO))
arising from a use of `allocate'
Possible fix:
add an instance declaration for
(Control.Monad.Trans.Resource.Internal.MonadThrow
(ConduitM S8.ByteString Void IO))
In the second argument of `($)', namely
`allocate
(do { tempDir <- getTmpDir;
openBinaryTempFile tempDir pattern })
(\ (_, h) -> hClose h)'
In a stmt of a 'do' block:
(key, (fp, h)) <- flip runInternalState internalState
$ allocate
(do { tempDir <- getTmpDir;
openBinaryTempFile tempDir pattern })
(\ (_, h) -> hClose h)
In the expression:
do { (key, (fp, h)) <- flip runInternalState internalState
$ allocate
(do { tempDir <- getTmpDir;
openBinaryTempFile tempDir pattern })
(\ (_, h) -> hClose h);
_ <- runInternalState (register $ removeFile fp) internalState;
CB.sinkHandle h;
lift $ release key;
.... }
Failed to install wai-extra-2.0.2
This is the full output when installing
I'm using the latest Haskell Platform with the ghc-clang-wrapper script.
Cabal versions:
$ cabal --version
cabal-install version 1.16.0.2
using version 1.16.0 of the Cabal library
GHC version:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3
Some of the tutorials mention using a cabal sandbox, but my version of cabal (1.16) is too old for that. If the sandbox is likely too help I'll try and get that working (had a little trouble updating cabal to 1.18).
It looks like you have several modules which when installed beside existing modules cause name collisions. Further up in the output before the error you posted there are a bunch of errors like this:
Network/HTTP/Client/Conduit.hs:37:9:
Ambiguous occurrence `MonadResource'
It could refer to either `Data.Conduit.MonadResource',
imported from `Data.Conduit' at Network/HTTP/Client/Conduit.hs:13:1-19
(and originally defined in `resourcet-0.4.10:Control.Monad.Trans.Resource.Internal')
or `Control.Monad.Trans.Resource.MonadResource',
imported from `Control.Monad.Trans.Resource' at Network/HTTP/Client/Conduit.hs:15:1-35
(and originally defined in `Control.Monad.Trans.Resource.Internal')
These may be caused by --force-reinstalls. This is basically what cabal sandbox was created for so it may be easier to post a question about whatever is going wrong in updating that. You should be able to cabal install cabal-install to update it to the newest version.
Edit:
If cabal install cabal-install is working then the first thing I would check, as Chrules mentions, is where your path is pointed at. When you install cabal via cabal it will get put in ~/.cabal/bin so that needs to be first in your path. If you do which cabal you'l probably now see something like /usr/bin/cabal, you want that to be ~/.cabal/bin/cabal. Since you're local user packages are now messed up anway here's what I would do.
rm -rf ~/.cabal ~/.ghc # This deletes everything you installed with cabal
cabal update # Reinitialize the platform cabal
cabal install cabal-install # Update cabal
cabal install yesod # This will work since you nuked your ~/.cabal and ~/.ghc
After doing this you will have nothing installed but yesod, and you probably want yesod-bin as well since that has the yesod binary (at ~/.cabal/bin).
I've installed Leksah 0.12.1.3 on Xubuntu 13.10 from terminal.
sudo apt-get install leksah
Opened leksah, created new workspace and package.
Main.hs is created by default with 'Hello world' program.
module Main (
main
) where
import Control.Monad (unless)
import Data.List (stripPrefix)
import System.Exit (exitFailure)
import Test.QuickCheck.All (quickCheckAll)
-- Simple function to create a hello message.
hello s = "Hello " ++ s
-- Tell QuickCheck that if you strip "Hello " from the start of
-- hello s you will be left with s (for any s).
prop_hello s = stripPrefix "Hello " (hello s) == Just s
-- Hello World
exeMain = do
putStrLn (hello "World")
-- Entry point for unit tests.
testMain = do
allPass <- $quickCheckAll -- Run QuickCheck on all prop_ functions
unless allPass exitFailure
-- This is a clunky, but portable, way to use the same Main module file
-- for both an application and for unit tests.
-- MAIN_FUNCTION is preprocessor macro set to exeMain or testMain.
-- That way we can use the same file for both an application and for tests.
#ifndef MAIN_FUNCTION
#define MAIN_FUNCTION exeMain
#endif
main = MAIN_FUNCTION
Now, if I try to run package, or write anything in editor, in lower-right window
========== 127 ==========================
appears.
This happens to me a lot.... I don't know what the cause is, but (at least in my case) I know I can fix the problem by just using the command line. I just "cd" into the directory with the package (the one with the *.cabal file), and type
cabal configure
cabal build
after this is done, Leksah works properly. Clearly it is a Leksah bug, but it is easy to work around.
Problem was in my naive assumption that 'apt-get install leksah' will install all needed packages.
However, that's not correct.
After leksah installation you'll need:
apt-get install cabal-install
apt-get install ghc
cabal update
After that, as jamshidh mentioned, you need to click package->cofigure.
Now build brakes with (for program posted in question, which is leksah autogenerated default):
Couldn't match type `IO' with `[]'
Expected type: String
Actual type: IO ()
In the first argument of `putStrLn', namely `testMain'
In the expression: putStrLn testMain
In an equation for `main': main = putStrLn testMain
But I managed to build much simpler version:
module Main (
main
) where
main = putStrLn "Hello World"
The problem with the default hello world is the following line:
putStrLn (hello "World")
It's simply that the left quote is not in the correct place. Change that to
putStrLn ("hello World")
and it should work.
here is what I did:
makdir happstack_01
cabal-dev install happstack-server
write the typical helloworld.hs with "import Happstack.Server (nullConf, simpleHTTP, toResponse, ok)"
ghc -threaded HelloWorld.hs -o helloworld
and I got:
Could not find module `Happstack.Server'
This is so obvious wrong. But what I am more surprised is that no tutorial on google for simple thing as this.
Any intuition would be awesome!
This is a set of instructions for a very bare-bones, Cabalized, and sandboxed build.
$ mkdir happstack01 && cd happstack01/
$ cabal init .
$ <CR><CR><CR><CR><CR><CR><CR><CR><CR> 1 <CR><CR><CR>
$ mkdir src
$ touch src/Main.hs
$ vi happstack-01.cabal
In happstack01.cabal
...
library
exposed-modules:
Main
build-depends: base >=4.6 && <4.7
, happstack-server
hs-source-dirs: src
default-language: Haskell2010
Then
$ cabal sandbox init
$ cabal install --only-dependencies
$ vi src/Main.hs
In src/Main.hs
import Happstack.Server
main :: IO ()
main = simpleHTTP nullConf $ return "Hello sandbox!"
Get some coffee while the sandbox builds.
$ cabal repl
> main
After this I usually add an executable entry to the Cabal file and begin to build the server from that.
Since you wanted a small tutorial, I am writing up how I just got it to work. I used cabal instead of cabal-dev though (if you care, let me know and I can play around a bit more)....
> cabal install happstack-server
> mkdir sample
> cd sample
Then I created the file sample.hs
import Happstack.Server
main = simpleHTTP nullConf $ return "hello, world!"
and I compiled it
> ghc sample.hs
(This is where you seem to be having problems finding the library.... You might want to check if ~/.ghc//package.conf.d/happstack-server-7.3.1-.conf and ~/.cabal/packages/hackage.haskell.org/happstack-server/ exist to verify the download)
Then run the server
./sample
and verify that it works using curl
> curl http://127.0.0.1:8000
This should respond with
hello, world!
ok I figured this out. GHC will not regonized local sanboxed libs. at least my GHC --version 7.6.3 does not. So I will have to cabalise my project in order to make sandboxed libs work.
I'm using the FSNotify package to watch my filesystem for changes to markdown files, so I can run them through Pandoc automatically. However, I'm having trouble getting the manager to exit nicely.
As it stands, my code is based on Yesod's use of the same package:
module Main where
import System.FSNotify
import Filesystem (getWorkingDirectory)
import System.Exit
import Control.Concurrent
main = do
cwd <- getWorkingDirectory
putStrLn "Watching current directory, press RETURN to exit."
withManager $ \man -> do
_ <- forkIO $ do
watchTree man cwd (const True) $ \fp -> print fp
_ <- getLine
exitSuccess
When I use runhaskell, the program works perfectly, but if I compile it to an executable (using ghc --make), when I press enter, my terminal becomes unresponsive. I'm compiling this on Windows 7 64-bit.
EDIT: Completed code. Well, not entirely completed - there's still more I want to do with this - but working.
Whenever I see a question of the form "works in GHCi, hangs when compiled", I think to myself "you need the threaded runtime".
Try recompiling with -threaded and see if that helps.
(GHCi is compiled with this flag, which explains the difference. I do recall there's some difference in how external function calls work depending on whether you use the threaded runtime or not...)