GHC 6.8.1 RC debugger only breaking on first evaluation of a function

Hi all, I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. When debugging a function, as for example the qsort function given as an example in the "3.5 The GHCi Debugger" documentation page, the debugger will only break on first function evaluation. As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-) Thanks, Olivier.

Olivier, On 18/09/2007, at 20:26, Olivier Boudry wrote:
Hi all,
I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1.
When debugging a function, as for example the qsort function given as an example in the "3.5 The GHCi Debugger" documentation page, the debugger will only break on first function evaluation.
As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-)
Definitely, there should be one such way. Could you paste a ghci session demonstrating the problem? Thanks in advance, we are heavily in need of feedback and bug reports reg. the debugger. pepe

On 9/18/07, Pepe Iborra
Could you paste a ghci session demonstrating the problem?
Here is a very short and simple debug session showing the problem: ======================================= *Main> :l debug68.hs [1 of 1] Compiling Main ( debug68.hs, interpreted ) Ok, modules loaded: Main. *Main> :break qsort Breakpoint 1 activated at debug68.hs:(1,0)-(3,55) *Main> main Stopped at debug68.hs:(1,0)-(3,55) _result :: [a] = _ [debug68.hs:(1,0)-(3,55)] *Main> :delete * [debug68.hs:(1,0)-(3,55)] *Main> :continue [0,1,3,4,8,11,18,23] *Main> :break qsort Breakpoint 2 activated at debug68.hs:(1,0)-(3,55) *Main> main [0,1,3,4,8,11,18,23] ======================================= The code: ======================================= qsort [] = [] qsort (a:as) = qsort left ++ [a] ++ qsort right where (left,right) = (filter (<=a) as, filter (>a) as) main = do print $ qsort [8, 4, 0, 3, 1, 23, 11, 18] ======================================= The sequence is: 1: set a breakpoint at qsort 2: evaluate function main 3: execution stopped at qsort (as expected) 4: delete all breakpoints 5: set breakpoint at qsort again 6: evaluate function main 7: that lazy haskell show the result without stopping at the breakpoint Just for fun I wrote an IO qsort function: qsortIO :: (Ord a) => [a] -> IO [a] qsortIO [] = return [] qsortIO (a:as) = do l <- qsortIO left r <- qsortIO right return $ l ++ [a] ++ r where (left, right) = (filter (<=a) as, filter (>a) as) and this one gets debugged on each run thanks to it's IO signature. Hope this helps, Best regards, Olivier.

On Tue, Sep 18, 2007 at 02:26:38PM -0400, Olivier Boudry wrote:
Hi all,
I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1.
When debugging a function, as for example the qsort function given as an example in the "3.5 The GHCi Debugger" documentation page, the debugger will only break on first function evaluation.
As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-)
There is a flag to do this, and it's even In The Manual! http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085 3.8.1. GHCi options GHCi options may be set using :set and unset using :unset. The available GHCi options are: +r Normally, any evaluation of top-level expressions (otherwise known as CAFs or Constant Applicative Forms) in loaded modules is retained between evaluations. Turning on +r causes all evaluation of top-level expressions to be discarded after each evaluation (they are still retained during a single evaluation). This option may help if the evaluated top-level expressions are consuming large amounts of space, or if you need repeatable performance measurements. ... Stefan

On 9/18/07, Stefan O'Rear
There is a flag to do this, and it's even In The Manual!
http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085
3.8.1. GHCi options
GHCi options may be set using :set and unset using :unset.
The available GHCi options are:
+r
Thanks Stefan, I just tried the ":set +r" trick. It looked really promising but it doesn't seem to work as expected. The session with the ":set +r" is exactly the same as without it: Prelude> :l debug68.hs [1 of 1] Compiling Main ( debug68.hs, interpreted ) Ok, modules loaded: Main. *Main> :set +r *Main> :b qsort Breakpoint 0 activated at debug68.hs:(1,0)-(3,55) *Main> main Stopped at debug68.hs:(1,0)-(3,55) _result :: [a] = _ [debug68.hs:(1,0)-(3,55)] *Main> :del * [debug68.hs:(1,0)-(3,55)] *Main> :cont [0,1,3,4,8,11,18,23] *Main> :b qsort Breakpoint 1 activated at debug68.hs:(1,0)-(3,55) *Main> main [0,1,3,4,8,11,18,23] Best regards, Olivier.

Olivier Boudry wrote:
On 9/18/07, *Stefan O'Rear*
mailto:stefanor@cox.net> wrote: There is a flag to do this, and it's even In The Manual!
http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085 http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085
3.8.1. GHCi options
GHCi options may be set using :set and unset using :unset.
The available GHCi options are:
+r
Thanks Stefan,
I just tried the ":set +r" trick. It looked really promising but it doesn't seem to work as expected.
Unfortunately not: http://hackage.haskell.org/trac/ghc/ticket/1400 Cheers, Simon

On Tue, Sep 18, 2007 at 02:26:38PM -0400, Olivier Boudry wrote:
Hi all,
I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1.
When debugging a function, as for example the qsort function given as an example in the "3.5 The GHCi Debugger" documentation page, the debugger will only break on first function evaluation.
As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-)
If you don't find a better solution, then at least you can make it easier to perform the above sequence: $ cat ~/.ghci :def . readFile $ cat script :l Module :b 236 $ ghci GHCi, version 6.8.20070912: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :. script [1 of 1] Compiling Module ( Module.hs, interpreted ) Ok, modules loaded: Module. Breakpoint 0 activated at Module.hs:236:20-45 *Module> _ It should be quite easy to go a step further and generate breakpoint locations from markers in comments in the source file. Best regards Tomek

On 19/09/2007, at 10:05, Tomasz Zielonka wrote:
If you don't find a better solution, then at least you can make it easier to perform the above sequence:
$ cat ~/.ghci :def . readFile $ cat script :l Module :b 236 $ ghci GHCi, version 6.8.20070912: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :. script [1 of 1] Compiling Module ( Module.hs, interpreted ) Ok, modules loaded: Module. Breakpoint 0 activated at Module.hs:236:20-45 *Module> _
You could also touch the module file to force a full reload: GHCi, version 6.7.20070907: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( Qsort.hs, interpreted ) Ok, modules loaded: Main. *Main> :! touch Qsort.hs *Main> :r [1 of 1] Compiling Main ( Qsort.hs, interpreted ) Ok, modules loaded: Main. *Main> Cheers pepe

The touch and reload option works but breakpoints are lost in the reload. For the moment putting the instructions in a script seems to be the simplest solution. Thanks for all inputs, Olivier.
participants (5)
-
Olivier Boudry
-
Pepe Iborra
-
Simon Marlow
-
Stefan O'Rear
-
Tomasz Zielonka