... | @@ -20,7 +20,7 @@ Here are the approaches we have under consideration |
... | @@ -20,7 +20,7 @@ Here are the approaches we have under consideration |
|
> then any crash (call to `error`) will yield an informative backtrace. The backtrace gives you a stack of calls that looks very like what you'd get in a call-by-value language. (Lots of papers about profiling in a lazy language, dating right back to [ Formally based profiling for higher order functional languages](http://research.microsoft.com/~simonpj/papers/1997_profiling_TOPLAS.ps.gz) give the background.)
|
|
> then any crash (call to `error`) will yield an informative backtrace. The backtrace gives you a stack of calls that looks very like what you'd get in a call-by-value language. (Lots of papers about profiling in a lazy language, dating right back to [ Formally based profiling for higher order functional languages](http://research.microsoft.com/~simonpj/papers/1997_profiling_TOPLAS.ps.gz) give the background.)
|
|
|
|
|
|
>
|
|
>
|
|
> You need to compile your whole program with profiling, and you need a profiled version of the packages you install. You can do the latter by adding `--enable-pofiling` to Cabal, and you can put that in your `~/.cabal` file.
|
|
> You need to compile your whole program with profiling, and you need a profiled version of the packages you install. You can do the latter by adding `--enable-profiling` to Cabal, and you can put that in your `~/.cabal` file.
|
|
|
|
|
|
>
|
|
>
|
|
> Programs run slower, of course, but that may not matter when debugging. But a crash in a production system will generate no useful information.
|
|
> Programs run slower, of course, but that may not matter when debugging. But a crash in a production system will generate no useful information.
|
... | | ... | |