When I tried to run cabal benchmark on bytestring I got package has no benchmark. Indeed, the .cabal file does not have benchmark configs. But the repo does have a bench directory. How does this work? Should I not try to benchmark it?
edit:
When running cabal build in the bench directory I got the following error:
Building bench-bytestring-0.1.0.0...
Preprocessing executable 'bench-bytestring-builder' for
bench-bytestring-0.1.0.0...
[18 of 18] Compiling Main ( BenchAll.hs, dist/build/bench-bytestring-builder/bench-bytestring-builder-tmp/Main.o )
BenchAll.hs:133:46:
Couldn't match expected type ‘Benchmarkable’
with actual type ‘IO ()’
In the second argument of ‘($)’, namely ‘benchIntEncodingB nRepl e’
In the expression:
bench (name ++ " (" ++ show nRepl ++ ")")
$ benchIntEncodingB nRepl e
The bench directory has a separate Cabal file, bench-bytestring.cabal. You should be able to cd into that directory and do cabal run to run the benchmarks.
That package's description explains why it works this way:
This package is not meant for public release. It fixes a problem with the current benchmarking support in cabal, which has trouble compiling because criterion depends on bytestring. Here, we just include the whole source of the bytestring library directly.
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!
In haskell build system, Cabal as well as runhaskell has got almost same set of sub-commands, configure, build. For runhaskell, it is:
runhaskell Setup.hs configure
runhaskell Setup.hs build
...whereas for cabal it is:
cabal build
cabal configure
So, when should I use which command? Do both the commands have same functionality?
Can I run runhaskell without sudo access, because I see runhaskell makes entries inside /opt/ghc/7.8.4/lib whereas cabal works in sudo/non-sudo mode?
cabal and runhaskell serve entirely different purpose.
runhaskell is used for executing Haskell programs without
having the need to compile them. You can place this on the top of an Haskell file: #!/usr/bin/env runhaskell and give it the scripting ability. The cabal is a package manager and a build system
for Haskell.
Also cabal and runhaskell don't share their sub-commands like
configure, build, install etc.
i saw in this link bob.ippoli.to/archives/2013/01/11/getting-started-with-haskell, two commands being used... runhaskell Setup.hs configure && runhaskell Setup.hs build
Usually Setup.hs has the following code when generated from cabal init:
import Distribution.Simple
main = defaultMain
Now if you see the implementation of defaultMain:
defaultMain :: IO ()
defaultMain = getArgs >>= defaultMainHelper simpleUserHooks
So what you are passing is actually command line arguments which can be anything. In fact you can test that yourself:
$ runhaskell Setup.hs invalid_argument
unrecognised command: invalid_argument (try --help)
runhaskell doesn’t have any subcommands:
$ runhaskell --help
Usage: runghc [runghc flags] [GHC flags] module [program args]
It takes a path to a Haskell source file and executes it right away. So you should use it when all you want is to run some Haskell code you have. Of course, you can use runhaskell without superuser access; I doubt it creates anything in /opt.
Cabal is a build-system for Haskell projects, its purpose is transforming Haskell sources into binaries.
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.
I'm trying to get this example code to compile on my system.
When I try to compile the Chat module with ghc Chat.hs, ghc gives me this:
Chat.hs:76:39:
Couldn't match expected type `Network.Wai.Request'
with actual type `wai-0.4.3:Network.Wai.Request'
In the second argument of `eventSourceApp', namely `req'
In the second argument of `($)', namely `eventSourceApp chan req'
In a stmt of a 'do' expression:
res <- lift $ eventSourceApp chan req
I am on OS X Snow Leopard and cleared up (everything?) except the Haskell Platform like this:
rm -r ~/.cabal
rm -r ~/.ghc
rm -r ~/Library/Haskell
and installed yesod and wai-eventsource anew from hackage.
As far as I understand the error comes from a dependency problem.
wai
Synopsis: Web Application Interface.
Default available version: 1.0.0
Installed versions: 0.4.3, 1.0.0
Homepage: https://github.com/yesodweb/wai
License: BSD3
Where yesod-0.9.4.1 requires wai == 0.4.* and wai-eventsource-1.0.0 requires wai >= 1.0.
So, my question would be: Is it possible to get this example (with the official releases of yesod) to work right now? With all the change the yesod project is going through atm?
Do I have to be more precise on the versions I try to install and, if so, how?
Edit:
I wiped out ~/.ghc (or actually followed a more rigorous approach given here, just in case) and tried to install the packages with a single
cabal install yesod wai-eventsource resulting in (incomplete):
Resolving dependencies...
cabal: cannot configure yesod-0.9.4.1. It requires wai ==0.4.* and warp ==0.4.*
For the dependency on wai ==0.4.* there are these packages: wai-0.4.0,
wai-0.4.1, wai-0.4.2 and wai-0.4.3. However none of them are available.
wai-0.4.0 was excluded because wai-eventsource-1.0.0 requires wai >=1.0
...
wai-0.4.3 was excluded because wai-eventsource-1.0.0 requires wai >=1.0
For the dependency on warp ==0.4.* there are these packages: warp-0.4.0,
warp-0.4.0.1, warp-0.4.1, warp-0.4.1.1, warp-0.4.1.2, warp-0.4.2, warp-0.4.3,
warp-0.4.3.1, warp-0.4.4, warp-0.4.5, warp-0.4.6, warp-0.4.6.1, warp-0.4.6.2
and warp-0.4.6.3. However none of them are available.
warp-0.4.0 was excluded because wai-eventsource-1.0.0 requires warp >=1.0
...
warp-0.4.6.3 was excluded because wai-eventsource-1.0.0 requires warp >=1.0
Before that (with yesod and wai-eventsource installed separately) I tried ghc -hide-package wai-1.0.0 Chat.hs resulting in,
Chat.hs:77:39:
Couldn't match expected type `wai-1.0.0:Network.Wai.Request'
with actual type `Network.Wai.Request'
In the second argument of `eventSourceApp', namely `req'
In the second argument of `($)', namely `eventSourceApp chan req'
In a stmt of a 'do' expression:
res <- lift $ eventSourceApp chan req
I think you need to unregister (or hide) wai 1.0.0. The current Yesod is using wai 0.4, which is where the mismatch is coming from. (Once a newer Yesod is released, this problem will disappear.)
Alternatively, you could wipe out your ~/.ghc folder again and run cabal install yesod wai-eventsource, which should automatically install only the compatible versions.
Edit: You need to hide wai-eventsource as well, and possibly a few others. And simplest approach is to run ghc-pkg unregister wai-eventsource-1.0.0 --force.
What's the best way to iterate over all the modules (files) in a given package? Concretely, suppose I have
an executable called "runThis"
a cabal package P with files F1.hs, F2.hs, ..., Fn.hs
Whats the easiest way to execute:
runThis F1.hs
runThis F2.hs
...
runThis Fn.hs
?
I thought I might try --with-compiler but that fails with
cabal: The program ghc version >=6.4 is required but the version of runThis
(The other option looks like tweaking the Setup.lhs -- but ideally I'd like to hijack the build process and use "runThis" instead of, say, ghc)
Thanks!
From Duncan Coutts' email:
Question: How to add the preprocessor? I have tried
main =
defaultMainWithHooks
simpleUserHooks{hookedPreProcessors=[("foo",transformation)]}
transformation :: BuildInfo -> LocalBuildInfo -> PreProcessor
That looks right. Here's how to complete it (example taken from the
Cabal haddock docs for the PreProcess module):
transformation _ _ =
PreProcessor {
platformIndependent = True,
runPreProcessor =
mkSimplePreProcessor $ \inFile outFile verbosity -> do
fail $ "transformation: " ++ inFile ++ " " ++ outFile
}
and it works fine:
runghc Setup.hs build
Preprocessing library foo-1.0...
Setup.hs: transformation: Abc.foo dist/build/Abc.hs
But under which circumstances will this function be called? Up to now
I have not succeeded in making cabal call this function.
It calls it when it goes and looks for the module Abc (ie Abc.hs
or .lhs), and since if does not find it, it'll check through the list of
preprocessors and go looking for the corresponding files, ie Abc.foo.