Simon Marlow wrote:
Peter Hercek wrote: <---cut--->
I see that it is not a good idea to keep references to all the variables in scope but maybe few improvements are possible:
1) As there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within given function then when user asks for a variable it would be searched first in the selected expression and if not found in the expressions from the tracelocal history. If the result would be printed from tracelocal history it should be indicated so in the output. This would avoid the tedious task of searching the trace history manually and moreover it would limit the history to the interesting parts (so hopefully the depth of 50 would be enough). The results from the tracelocal history may not be from the expected scope sometimes but the same problem is with "printf debugging".
Good suggestion - please submit it via the bugtracker,
http://hackage.haskell.org/trac/ghc/newticket?type=feature+request
Here it is: http://hackage.haskell.org/trac/ghc/ticket/2737
2) I noticed only now that I do not know how to script breakpoints. I tried :set stop if myFreeVar == 666 then :list else :continue ... and it did not work. My goal was to create a conditional breakpoint. I also wanted to use it instead of "printf debugging" using something like :set stop { :force myFreeVar; :continue } Ideally it should be possible to attach different script for each breakpoint and the functions for controlling debugger should be available in the Haskell. I would expect this is already partially possible now (using :set stop) and possibly some functions from ghci api which correspond to ghci commands (like :set etc.). But I do not know how, any pointers from experienced ghci debugger users?
I think you want :cmd. e.g.
:set stop :cmd if myFreeVar == 666 then return ":list" else return ":continue"
Yes! That works good enough, and I can set a different script for each breakpoint with ":set stop N <cmd>"! Thanks. The only thing I still miss here is a way to suppress the default output when a breakpoint (which has a script attached?) is hit. As for as the rest of the message. Those are possible bugs. If I can reduce them to few tens of lines of a test, I'll post the bug reports. I use Archlinux and the last (non-testing) version of ghc there is ghc-6.8.2. Do you accept bug reports against it or do you need them against 6.10.1rc1 only? Thanks for help, Peter.
Ghci debugger did not know some functions in my code which I would expect it to know; e.g. field selection functions from a record which is not exported from the module but which are available withing module. Is this expected? (I did not have any *.hi *.o files around when ghci did run the code.)
It could be a bug, if you could figure out how to reproduce it and submit a bug report that would be great.
Och and sometimes it did not recognize a free variable in the selected expression. The code looked like let myFn x = x `div` getDivisor state > 100 in if myFn xxx then ... the expression "myFn xxx" was selected while browsing trace history but xxx was not recognized, but when I browsed into myFn definition in the trace log the x (which represented the same value) was recognized. Is this expected?
Again, please submit a bug report. The debugger is supposed to give you access to all of the free variables of the current expression.
Cheers, Simon