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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
