I'm writing some disposable Haskell scripts to solve some of the Project Euler problems. I don't really want to have to compile them because of the number of changes I'm constantly having to make, but in a few cases I've found that I've run out of stack space.
The documentation for runhaskell says that the following syntax should increase the stack space:
runhaskell +RTS -K5M -RTS Script.hs
This never, ever works (in any permutation I've tried). The stack size always remains 8,388,608. This is maddening, and I haven't found much help on Google.
Any suggestions? What am I doing wrong?
I'm guessing you're using GHC. Chapter 4 of the User's Guide of the newly released 6.10.1 says:
The only runghc flag currently is -f
/path/to/ghc, which tells runghc which
GHC to use to run the program.
I don't see a bug logged at http://hackage.haskell.org/trac/ghc . Seems pretty lame to me. I'd suggest asking on irc #ghc, or the cvs-ghc mailing list.
Of the other Haskell compilers/interpreters, only nhc98 seems allow you to set the max stack size. Depending on your OS, nhc98 could be an option.
I'm doing the same thing (Project Euler) and have been using ghc. The trick (thanks #haskell!) is to tell the executable to have more stack size rather than the compiler.
$ ghc -O2 -o 23 23.hs
$ ./23 +RTS -K128M
Just compile it.
Problem123.hs:
module Main where
main = do
print solution
solution = ...
Short and sweet command line:
ghc --make -O3 Problem123.hs
./Problem123
Final note: I'm not sure I would call them "scripts".
Related
This question is the distilled solution of what others have helped me solved. The discussion can be found on this issue and this r/xmonad post.
I'm using Artix mainly with Pacman as a package manager. Today, after about a week, I've upgraded many packages and it ended up breaking XMonad.
This is the message I get from xmonad --recompile -v:
XMonad is recompiling and replacing itself another XMonad process because the current process is called "xmonad" but the compiled configuration should be called "xmonad-x86_64-linux"
XMonad will use ghc to recompile, because "/home/philippe/.xmonad/build" does not exist.
XMonad skipping recompile because it is not forced (e.g. via --recompile), and neither xmonad.hs nor any *.hs / *.lhs / *.hsc files in lib/ have been changed.
/home/philippe/.xmonad/xmonad-x86_64-linux: error while loading shared libraries: libHSxmonad-contrib-0.16-KKfUmtIonstICqbgIKQKYh-ghc8.10.4.so: cannot open shared object file: No such file or directory
I've tried a ton of solutions people mentioned on the internet — so far I've spent more than 3 hours trying to debug this —, among them, notably:
cabal install --lib xmonad-contrib, which had solved some issues I've had with XMonad in the past.
Removing and reinstalling Stack, GHC, Cabal, and XMonad itself.
Installing XMonad through Stack.
This ended up giving me the same error message, the difference is that I had to execute ~/.local/bin/xmonad --recompile -v instead.
Does anyone have an idea of how to solve this? I've had problems with upgrades of XMonad before, but never anything close to this — I love Haskell as a language, but its package management is one of the most disgusting, overcomplicated pieces of software I've ever experienced in my 10+ years of programming life.
If I end up cleaning up my system and managing everything through Stack, how do I compile XMonad through it? Using only Stack and then xmonad --recompile is giving me this error:
XMonad will use ghc to recompile, because "/home/philippe/.xmonad/build" does not exist.
xmonad: ghc: runProcess: runInteractiveProcess: exec: inappropriate type (Not a directory)
(I do have an ~/.xmonad/build/ folder by the way...)
I've finally made it work. The guys from the XMonad repo really helped, you can check out their help in this issue.
Roughly, what I did was:
Delete everything Haskell-related from my system.
Do this one carefully, use a lot of finds with the words haskell, stack, ghc, cabal, etc. Don't forget to use pacman -Rns and pacman -Q to uninstall everything that come from there first.
As some other users mentioned, you should absolutely not manage Haskell packages with both Pacman/AUR and Stack/Cabal. Choose one system and stick to it. Stack is probably the recommended one.
Install Stack directly with the script on its documentation.
Install GHC, XMonad, and XMonad-Contrib through Stack.
Create a build script for compiling XMonad with Stack:
#!/bin/sh
exec stack ghc -- \
--make xmonad.hs \
-i \
-ilib \
-fforce-recomp \
-main-is main \
-v0 \
-o "$1"jk
Add exec $HOME/.xmonad/xmonad-x86_64-linux to .xinitrc so it runs what was compiled with Stack previously.
This is a follow-up to this question, which is about whether it is possible to compile simple programs on Haskell in Windows, without recourse to Cygwin: Compiling Haskell programs in Windows: is it possible without downloading something such as Cygwin?
For background, I asked this question, since if there were some other way of compiling the program it would be very useful to know, since I am on a university computer and cannot download things like Cygwin without permission. (and even with permission it might not be possible, depending on what Cygwin requires)
Someone responded to my question, suggesting I open the command line and put ghc --make helloworld and hit Enter. However, when I put in ghc --make helloworld and hit Enter this comes up:
ghc: unrecognised flag: --
did you mean one of:
-D
-F
-H
Usage: For basic infomration, try the '--help' option
The person answering the question suggested I made another question, asking why I received the above message. How can I deal with this problem?
Yes, it is possible to use Windows to compile Haskell programs. In fact, I use Windows for all my Haskell programming! To compile a Haskell program, use ghc --make <program>; for instance, here it would be ghc --make helloworld.hs. Note that there is no space between -- and make; including this space gives the error you describe. After running this command, an executable helloworld.exe file is produced.
I had been working on a script in which I hoped to take advantage of multiple processors in my machine by swapping out mapM with Async.mapConcurrently.
Observing no speed increase in that instance, I wanted to verify that runghc can indeed utilize multiple cores.
Given a file Foo.hs:
import Control.Concurrent
main = print =<< Control.Concurrent.getNumCapabilities
If I compile the file as follows:
stack ghc -- -threaded Foo.hs
and then run it as follows:
./Foo
it returns the result 1. This is expected, as no RTS options have been supplied. Running it instead as follows:
./Foo +RTS -N
returns the number 6, as there are 6 processors in my machine (agreeing with nproc).
However, when I run the script in "interpreted mode" like so:
GHCRTS="-N" stack runghc Foo.hs
It yields the following error text:
Running /home/kostmo/.stack/programs/x86_64-linux/ghc-nopie-8.0.2/bin/ghc-pkg --no-user-package-db list --global exited with ExitFailure 1
ghc-pkg: the flag -N requires the program to be built with -threaded
Is it possible to utilize multiple cores with stack "scripts"?
Thanks for asking this question, I think stack should handle the GHCRTS environment variable specially, and opened this issue https://github.com/commercialhaskell/stack/issues/3444 and made this change https://github.com/commercialhaskell/stack/pull/3445
Unfortunately, it does not solve this case, because runghc itself (ghc) will process GHCRTS, and it is not built with the threaded runtime. So the environment variable solution cannot be used.
I think it should be possible to provide -with-rtsopts -N flag to stack script --compile, but that doesn't seem to be working, needs further investigation. This doesn't work with runghc, because it uses the interpreter.
I'm trying to do some profiling using stack --enable-profiling and I'm a bit confused about what's happening exactly.
Do I need to use also --enable-library ?.
Also, is it build in a separate directory ?What happend next I build it, will remember that am I in profiling mode or do I have to use the --enable-profiling all the time.
It is generally recommended to profile in conjonction with the -O2 option. Does --enable-profiling set it automatically ?
Stack support for enabling profiling works great, example:
stack build --profile --executable-profiling --library-profiling
stack exec -- example <your prog args> +RTS -p
Then see example.prof for the default output.
Update: the stack support pointed me to the right correct for exec, see https://github.com/commercialhaskell/stack/issues/1655
When compiling a haskell source file via ghc --make foo.hs GHC always leaves behind a variety of intermediate files other than foo.exe. These are foo.hi and foo.o.
I often end up having to delete the .hi and .o files to avoid cluttering up the folders.
Is there a command line option for GHC not to leave behind its intermediate files? (When asked on #haskell, the best answer I got was ghc --make foo.hs && rm foo.hi foo.o.
I've gone through the GHC docs a bit, and there doesn't seem to be a built-in way to remove the temporary files automatically -- after all, GHC needs those intermediate files to build the final executable, and their presence speeds up overall compilation when GHC knows it doesn't have to recompile a module.
However, you might find that setting the -outputdir option will help you out; that will place all of your object files (.o), interface files (.hi), and FFI stub files in the specified directory. It's still "clutter," but at least it's not in your working directory anymore.
GHC now has the options no-keep-hi-files and no-keep-o-files. See here for more information.
My usual workflow is to use cabal rather than ghc directly. This sets the outputdir option into an appropriate build folder and can do things like build haddock documentation for you. All you need is to define the .cabal file for your project and then say cabal install or cabal build instead of run ghc directly. Since you need to follow this process in the end if you ever want to share your work on hackage, it is a good practice to get into and it helps manage package dependencies as well.
You can set the -hidir to /dev/null, I think, sending them there. Also, the -fno-code option in general turns off a lot of output. You might just want to use Cabal.
Turns out that using -hidir/-odir/-outputdir is no good; /dev/null is a file, and not a directory. See http://www.haskell.org/pipermail/xmonad/2010-May/010182.html
2 cents to improve the workflow a bit:
We can put the following alias into the .bashrc (or similar) config
file:
alias hsc='_hsc(){ ghc -no-keep-hi-files -no-keep-o-files "$#";}; _hsc'
And then just call
$ hsc compose.hs
[1 of 1] Compiling Main ( compose.hs, compose.o )
Linking compose ...
$ ls
compose compose.hs