I'm developing an application that uses OpenGL to render an image. My usual workflow involves testing code in GHCI, as :r reloading and interpreted mode are much faster than compiling.
When I run the code from ghci via Stack (stack ghci), the frontend stutters and may not respond to input events.
If I compile the code without -threaded, it works as expected.
I can also make it work from stack ghci using runInBoundThread.
Answer turned out to be passing the correct RTS option to ghci:
stack repl --ghci-options='+RTS -N -RTS'
Related
I'm writing a dynamically linked library that includes both C and Haskell code. I'm using the GHC. It's working fine except that when there is a stack overflow in Haskell, the program crashes. It looks like I should be able to catch these errors by adding a hook when I set up the RTS. (https://downloads.haskell.org/ghc/8.10.5/docs/html/users_guide/runtime_control.html#hooks-to-change-rts-behaviour)
However, the hook isn't run. The documentation says that it won't work if the library is dynamically linked in Windows, but I'm running in Linux. Am I missing something or is the documentation incomplete?
The hook runs in a stand-alone executable.
A little more detail: I'm writing a plug-in for PostgreSQL to allow a user to run haskell code. I'm using Hint as the interpreter. Since the user can input possibly bad code, a stack overflow is an issue that must be handled gracefully.
Does for anyone else stack compile & link the whole project when only stack ghci is asked for?
Shouldn't it skip the former and jump into ghci right away to load sources? I've observed it to do both for me on most of my projects and therefore it's doing seemingly superfluous work. Is this by design, or might have I misconfigured some of my stack projects?
Perhaps is this done by cabal underneath without stack asking for it?
And at any rate, is there something I could do to skip the compilation + linking when I just want to enter stack ghci?
From the Haskell Tool Stack Documentation:
Speeding up initial load
There are two ways to speed up the initial startup of ghci:
--no-build, to skip an initial build step. This only works if the dependencies have already been built.
You can also have stack ghci skip loading sources (if you know you only want one file loaded in, and can do it by hand) by using:
--no-load, to skip loading all defined modules into ghci. You can then directly use :load MyModule to load a specific module in your project.
I've just realized that -fobject-code may also play a part in this. I'm unsure where it is being set (not on the command line, not in the .cabal/package.yaml file and not in ~/.ghci either).
Nevertheless when I negate it with --ghci-options=-fbyte-code the recompilation doesn't seem to be taking place.
I still hope to hear others' responses as I'd like to understand more thoroughly why the -fobject-code may require minutes for full recompilation on initial load, since :reloading only takes about a second after a file has changed. (E.g. with ghcid too.)
I'm currently using Stack to build a project, which totals about 80 modules and 13,000 lines of code. Currently, compilation takes about 3 minutes for a minor change in my types files, which is unacceptable -- it prevents me from rapidly testing my code via stack ghci. It also significantly slows down a number of things: for instance, pair programming with peers or consulting with experts.
I would like to be able to figure out why compilation is taking so long, and what I can do to speed it up. Is there some way to profile compilation times?
Additionally, how can I tell whether it is stack or ghc that is slow?
I know about setting -O0, though this does not seem to help compilation times. I also know that TemplateHaskell and Typeclass Resolution can take a while -- is there any way I can get better resolution on how long these are taking?
Note: i have seen Speed up compilation in GHC, but that was from 2013, and hdevtools currently does not work on my setup.
In case this question is still relevant, you could try this:
stack ghci --fast --no-build --ghc-options="-fbyte-code"
IIRC using this got me the quickest results with stack ghci.
If this doesn't help enough, you could look in the direction of --ghc-options="-dshow-passes". I myself am also looking in this direction currently to try to speed up a build/ghci-reload.
If GHC takes a long time to compile something, is there a way to find out what it's doing?
Firstly, it would be nice to know if I've actually crashed the compiler (i.e., put it into some sort of infinite loop somehow), or whether it's actually making progress, but just very slowly.
Secondly, it would be nice to know exactly what part of the compilation process GHC is having trouble with. Is it the parsing, or desugaring, or type-checking, or Core optimisation, or code generation, or...?
Is there some way to monitor what's going on? (Bearing in mind that if GHC is taking a long time, that probably means it's doing a lot of work, so if you ask for too much output it's going to be huge!)
GHC already tells you which modules it's trying to (re)compile. In my case, the problem is a single self-contained module. I'd like to know where GHC is getting stuck.
Following Daniel Fischer's comment, I tried running GHC with different verbosity options.
-v1: Produced a bit more output, but nothing during the main compilation step.
-v2: Tells you what step GHC is currently doing (parser, desugar, type check, simplifier, etc). This is pretty much what I actually wanted.
-v3: Appears to make the simplifier actually dump what it's doing to the console - bad idea while compiling 8MB of source code!
So it seems that -v2 is the place to start.
(In the specific case of the program that prompted this question, it seems GHC is spending forever in the type checking phase.)
Is there options, except -O0, that can speed up compilation time?
It's not matter if resulting programs will be not optimised. Actually I want to just type-check large haskell package often and fast.
Flag -fno-code dramatically speeds up compilation but it's not possible to use it because TemplateHaskell is used by this program.
Looks like a task for hdevtools! Hdevtools is used to as a backend for vim-plugin of the same name and it provides speedy syntax and type checking, directly from the editor. It is about as fast as ghci when reloading modules. I assume that it can be used from the command line.
Another alternative would be to keep a ghci instance running and use that to type check your modules.
I've found splitting up large files can speed up compilation.