Quick tips for fast iteration in Haskell | The Haskell Programming Language's

Links
1
17 Likes
2

Is there a way to set up my cabal project in such a way that I don’t have to rebuild my whenever I want to run at full speed or in profiling mode? Ideally, I would like there to be two executables that build/update what has changed since for that executable since it last run; it seems I have to always rebuild the library if I want to build the other executable…

Currently, I have one cabal file, with one library and two executables. The main flags and ghc options are controlled in cabal.project.* files.

1 Like
3

I think if you use the profiling: directives in your cabal.project.* file, cabal should put the two different modes in two different directories enabling separate caching. If you do change the ghc-options then cabal does not do separate caching.

2 Likes
4

Ah, thanks! That’s a bit of pain, however…

Say I have cabal.project.local:

import: ./cabal.project

ignore-project: False
optimization: 2
package package1 
  ghc-options: "-with-rtsopts=-N -s"

and cabal.project.prof:

import: ./cabal.project

ignore-project: False
optimization: 2
package package1
  profiling: true
  profiling-detail: late
  ghc-options: -finfo-table-map -fdistinct-constructor-tables -fno-prof-count-entries "-with-rtsopts= -l -pj -hc -N -s"

program-options
  ghc-options:
    -dsuppress-all
    -dsuppress-uniques
    -ddump-deriv
    -ddump-simpl
    -ddump-stg-final
    -ddump-to-file
    -dumpdir=dumps

To my mind, the most sensible thing to do is to put the ghc-options as pragmas in the files themselves? How would I ensure that I only dump the core and stg whenever I do profiling runs?

1 Like
5

Am I understanding it correctly that you’re compiling one of your dependencies with profiling, but not the main executable? Why is there no profiling: true at the top level in cabal.project.prof?

6

I want to compile the whole package(?). My understanding is the package contains my libraries and executables and I would like away to apply different settings to different executables.

Lack of knowledge, I didn’t know it was supposed to go there :smiley: (it’s been a journey even using cabal.project files!! I used to stick everything in project.cabal until it stopped working for profiling and info tables didn’t get filled properly!)

To be clear, I want to have the following kind of behaviour (if it is possible):

$ cabal run --project-file=cabal.project.local exe1 # Builds and runs exe1

then later on, when I do

$ cabal run --project-file=cabal.project.prof exe1-profile # Builds and runs exe1-profile

but it does so without requiring a full rebuild of the library and executable because I ran the exe1 build some time in between: rather it increments on the last time I ran exe1-profile.

3 Likes
7

I use ghci on Windows. Its most annoying (lack of) feature, that slows me down the worst, is I can’t use cut’n’paste keys. Instead I have to dive around the menu.

8

Nice article! I appreciate the build optimization section!

One of the nicest tricks I know for working effectively with ghci (or cabal repl) is defining this custom “command”:

$ cat ~/.ghci | fgrep 'def x '
:def x \expr -> return $ unlines [":!clear", ":reload", expr]

This way, when iterating on a particular bit of code, you can :

  • editor: change a bit of code
  • ghci: press the up arrow then enter to observe the change
  • editor: change a bit of code
  • ghci: press the up arrow then enter to observe the change
  • and so on…

This requires an initial setup where you load the required modules properly and initiate a proper function call with the required args, say:

ghci> myFunc 1 2 3

Then you can simply prefix the REPL expression with :x to initiate the “REPL driven development loop” described above, so :

ghci> :x myFunc 1 2 3

It’s been working very well for me. “X” as in “scratch that, let’s try again” :slight_smile:

4 Likes
9

I’m happy to see that the blog post generated real-world impact!

Dominik has reported build speedups of ~2.2x. Very nice!

4 Likes
10

Speaking of these things, some 15 years ago I set up :L to load the currently edited file. I just have vim write that to a known place on BufEnter. Then the other major productivity bonus is to alias :R to :r, because I can’t get my finger off the shift key fast enough half the time. I also have :load add a :module +D, which puts some pretty-printing functions into scope.

Since I run tests from ghci and use a framework where they are plain IO () actions, the usual loop is to edit, and then up arrow return the test_whatever function. I have a :K alias that does a reload and rerun all at once. It’s from a DSL that produces text output and has the side-effect of saving the output to a file. So I can do :K to reload and rerun, and then diff to show the diffs with the output of the last time I ran it. I could have the editor send these over automatically on save ala ghcid via tslime.vim which sends text to other tmux windows, but so far haven’t gotten around to it.

For functions under test, I have a habit of just assigning them in the file as eg t0 = f 1 2 3, since this is persistent across reloads. Then if they are still interesting I might copy paste them into a test.