basic information

Check out my website: http://renickbell.net.

algorave

I have started posting examples of using Conductive to make bass music. Have a listen! http://www.renickbell.net/doku.php?id=algorave

using the parseargs package

This week I found the parseargs package in Hackage to be useful. It makes handling command-line arguments for your program easy, and gives the user a very pleasant command-line interface to your program.

http://hackage.haskell.org/package/parseargs

However, I also needed to use the command line options for the GHC runtime system in my compiled program.

http://hackage.haskell.org/package/parseargs/

The important thing to note (which I missed on a first sleepy reading) is this:

When your Haskell program starts up, its RTS extracts command-line arguments bracketed between +RTS and -RTS as its own. For example:

% ./a.out -f +RTS -p -S -RTS -h foo bar 

The RTS will snaffle -p -S for itself, and the remaining arguments -f -h foo bar will be handed to your program if/when it calls System.getArgs.

If you do that, then you can use the command line arguments for the RTS along with whatever you have written into your program.

profiling your Haskell program: enable profiling for libraries

Having read this chapter in Real World Haskell, I wanted to profile the program I'm working on.

http://book.realworldhaskell.org/read/profiling-and-optimization.html

Unfortunately, right away I got errors because profiling hadn't been enabled for the modules I was importing. The Haskell wiki has this page:

http://www.haskell.org/haskellwiki/How_to_profile_a_Haskell_program

The process described there for enabling profiling in libraries is fine if you just need one library, but as it turned out, I needed to enable profiling in about six libraries. What a pain!

In the section called 2.2 Enable profiling on libraries, this information should absolutely be included, particularly the answer:

http://stackoverflow.com/questions/1704421/cabal-not-installing-dependencies-when-needing-profiling-libraries

You just need to do this:

vim ~/.cabal/config

Uncomment this line and set it to True:

library-profiling: True

After that, you need to cabal install __(module)__ --reinstall for each module you are using, and their dependencies as well. Unfortunately, cabal isn't smart enough to do it all the way down automatically yet.

That is so much easier than doing each library by hand, though. I was about to get really frustrated until I read that post on StackOverflow.

ghc 6.10.4 solves the previous problem with sendtorepl

Upgrading to ghc 6.10.4 does solve the problem that I previously wrote about with 6.10.3:

http://renick-bell.blogspot.com/2009/05/upgrade-to-ghc-6103-broke-my-vim-script.html

Because of that, the workaround that I described previously is no longer needed:

http://renick-bell.blogspot.com/2009/05/workaround-for-sendtorepl-and-ghci.html

Thanks to the tireless developers!

Workaround for sendtorepl and ghci

Judah, the author of haskeline, says:

"This was probably caused by a bug which has been fixed in the latest
release of Haskeline (0.6.1.6).

That fix should ship with ghc-6.10.4"

In the meantime, he gave me this solution, which works here:

cabal update && cabal install ghci-haskeline

Then, you should not interact with your 6.10.3 ghci; rather, you should interact with the executable ghci-haskeline, which is probably here:

~/.cabal/bin/ghci-haskeline

So now, when I start my screen session that I plan to interact with, I use this line:

screen -S haskellSession -t haskellSession ~/.cabal/bin/ghci-haskeline

Ghc-6.10.4 should not require this simple workaround.

Upgrade to ghc 6.10.3 broke my vim script

If you by chance tried my vim script, it no longer works in ghci 6.10.3 for multiple lines. I'm not sure why, yet. Some amount of the beginning of the string is cut, and the final bit of the string, :}\n is also cut. There was a change from editline to haskeline. Could that be the reason?