<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi users of ghci debugger,<br>
<br>
This post is going to be a bit longer. Here are few cookies to motivate
you to go on:<br>
* you will probably like it more than printf debugging for a lot of
cases<br>
* it can provide a way of implementing Claus Reinke's idea of
breakpoints with a list of identifiers which should be available at
breakpoint location and doing it without recompilation; here is the
link to Claus' message:
<a class="moz-txt-link-freetext"
 href="http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15900">http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15900</a><br>
* it gives some idea to ghc team about importance of ghci debugger
related tickets (and whether to implement them just the way they were
proposed)<br>
<br>
A note to ghc developers: Stepping program in ghci debugger sometimes
purges top level bindings and sometimes not. Not sure this is a bug or
feature (whether there is some logic in it). I do not have a simple
example when it purges the bindings. But I did not really look for one.<br>
<br>
I would probably post later, but some ghci bugs and missing features
are badly limiting my progress. There is not much more I can think of
to investigate. Maybe somebody will have better ideas how to solve the
obstacles I'm hitting. I'm also posting with hope that people will find
this interesting
and ghc team will fix some of the critical bugs and adds the most
critical features, especially if somebody will not have better
debugging tips.<br>
<br>
You can get my extensions here:<br>
<a class="moz-txt-link-freetext"
 href="http://www.hck.sk/users/peter/pub/ghciext-0.1.tar.gz">http://www.hck.sk/users/peter/pub/ghciext-0.1.tar.gz</a><br>
The extensions are not in a single .ghci file now. The new .ghci file
needs to
install a library. The reason is that without the library it is not
manageable any more.<br>
<br>
And here are arch linux packaging instructions for my custom ghc (if
you
are an arch linux user just download and run makepkg :) ):<br>
<a class="moz-txt-link-freetext"
 href="http://www.hck.sk/users/peter/pub/ghc-custom-6.10.1.tar.gz">http://www.hck.sk/users/peter/pub/ghc-custom-6.10.1.tar.gz</a><br>
The custom ghc is just the same one as ghc 6.10.1 with two more
patches: t2740.patch and loglocal.patch. The first one fixes ticket
2740 and you will get it in 6.10.2. The second one adds :loglocal
command to ghci. You can extract the patches from the tar file.<br>
<br>
If you already read ghci scripting tutorial from Claus Reinke then you
will know how to customize ghciext (that is if you would feel like
doing so). The tutorial is here:<br>
<a class="moz-txt-link-freetext"
 href="http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html">http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html</a><br>
<br>
Here is the list of custom commands in ghciext package:<br>
<tt>:defs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- list user-defined commands</tt><br>
<tt>:. &lt;file&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- source commands from &lt;file&gt;<br>
:redir &lt;var&gt; &lt;cmd&gt;...&nbsp;&nbsp;&nbsp;&nbsp; -- execute &lt;cmd&gt;
redirecting stdout to &lt;var&gt;<br>
:grep &lt;pat&gt; &lt;cmd&gt;...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- filter lines matching
&lt;pat&gt; from &lt;cmd&gt; output<br>
</tt><tt>:* &lt;count&gt; &lt;cmd&gt;...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- run &lt;cmd&gt;
&lt;count&gt; times<br>
:x &lt;cmd&gt;...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- run &lt;cmd&gt; with stdout
suppressed<br>
</tt><tt>:bp &lt;bpArgs&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- put breakpoint at location
&lt;bpArgs&gt; (adds hit count)<br>
:inject &lt;cc&gt; &lt;c&gt; &lt;sc&gt; &lt;b&gt; -- at location
&lt;b&gt; execute &lt;c&gt; if &lt;cc&gt;, and stop if &lt;sc&gt;<br>
:monitor ["&lt;c&gt;"] &lt;vs&gt; &lt;b&gt; -- show comma separated
variables at location &lt;b&gt; if &lt;c&gt;<br>
:watch &lt;cond&gt; &lt;bpArgs&gt;&nbsp;&nbsp;&nbsp; -- break at location
&lt;bpArgs&gt; when &lt;cond&gt; is True<br>
:count (_|&lt;N&gt;) [&lt;bpArgs&gt;] -- count/query/stop execution at
location &lt;bpArgs&gt;<br>
:find &lt;var&gt; &lt;cmd&gt;...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- step with &lt;cmd&gt; until
&lt;var&gt; is found<br>
:findex &lt;str&gt; &lt;cmd&gt;...&nbsp;&nbsp;&nbsp; -- step with &lt;cmd&gt; until
&lt;str&gt; is found<br>
:next [lazy]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- step over; lazy version forces only the
top constructor<br>
:xout&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- redirect ghci stdout to /dev/null<br>
:out&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- redirect ghci stdout back to console<br>
</tt><br>
:defs, :., :redir, :grep, are the same as the commands in Claus'
tutorial. The only differences I recall now are:<br>
&nbsp;* grep pattern can be in quotation marks (easier search for spaces)<br>
&nbsp;* grep merges :browse output more nicely<br>
&nbsp;* redir can accept :step, :steplocal etc; i.e. also the commands which
sometimes
remove top level bindings<br>
&nbsp;* the commands do not pollute top level bindings so much<br>
<br>
The rest will describe my custom commands and now they relate to
tickets in ghci track. If you want to check the tickets mentioned here
then the most easy way is probably selecting them from this list:<br>
<a class="moz-txt-link-freetext"
 href="http://hackage.haskell.org/trac/ghc/search?q=phercek&amp;noquickjump=1&amp;ticket=on">http://hackage.haskell.org/trac/ghc/search?q=phercek&amp;noquickjump=1&amp;ticket=on</a><br>
<br>
The initial big problem was how to limit the amount of information ghci
debugger spits at you when breakpoints with custom scripts are used.
This is also mentioned in forth point of the "unknown" section of
ticket #1377:<br>
<i>We can disable a breakpoint with ":set stop N :continue", but this
still prints out the breakpoint info when we stop.
Should we print the info only if there were no commands?</i><br>
So I say: yes do it! Just disable any ghci output related to a
breakpoint when the breakpoint has a custom code attached. We can
disable the output ourselves, but then we disable all the output
(including the output of the debugged program). People who are
debugging console applications are busted (especially if the
applications are interactive). This is not an issue for me since my
application is not using console almost at all. I'm solving the problem
by prefixing commands like <i>:main</i> and <i>:continue </i>with my
command <i>:x</i>. This makes output by default disabled and ghciExt
enables it just before a breakpoint code is run. If the breakpoint
continues execution it disables it again. If the debugged function
finishes the output is enabled by <i>:x</i> itself. A small problem
happens when you forget to use <i>:x</i> e.g. with your <i>:main</i>.
Then you do not get a prompt when the program finishes. It's time to
notice it and use <i>:out</i> to switch it on. This is the only minor
disadvantage for a gui application debugging. <i>:xout </i>in not
that useful (it is mostly used internally by <i>:x</i>). It could be a
hidden command (i.e. not registered in defs).<br>
<br>
Now when we have ghci "muted" we can get to real goodies: <i>:monitor</i>,
<i>:watch</i>, and <i>:count</i>.<br>
If you like printf debugging, then <i>:monitor</i> can help you. It
can monitor only free variables in the selected expression (on which a
breakpoint is hit) but that was always enough for me during debug
sessions I had. Write a script
file (lets say it is named <b>ghciInit</b> (I'll also call it this way
later on in this text)) which is like this example:<br>
<i>:monitor var1,var2 ModuleName 23<br>
:monitor var3 ModuleName 40<br>
:x :main mainArgument</i><br>
<br>
Then open ghci with your program and run <b>:. ghciInit</b><br>
And you will get nice log like this:<br>
<i>(0): var1 = &lt;value01&gt;<br>
var2 = &lt;value02&gt;<br>
(1): var3 = &lt;value03&gt;<br>
(0): var1 = &lt;value11&gt;<br>
var2 = &lt;value12&gt;<br>
(1): var3 = &lt;value13&gt;<br>
... etc</i><br>
<br>
Moreover <i>:monitor</i> allows condition in quotation marks to be
specified as the first argument. If you do it then the variable values
will be printed only when the condition is True. Of course the
condition can contain only free variables in the selected expression.
Mostly it is not a problem.<br>
<i>:watch</i> is a conditional breakpoint which stops when the
specified condition is True.<br>
<i>:count</i> has 3 forms:<br>
<i>:count _ ModuleName 23</i><br>
&nbsp;&nbsp; This never breaks just counts number of times the execution reached
position ModuleName 23<br>
<i>:count 5 ModuleNmae 23</i><br>
&nbsp;&nbsp; This breaks when we reach position ModuleName 23 fifth time<br>
<i>:count 0</i><br>
&nbsp;&nbsp; This tells how many times breakpoint number 0 was hit (it can report
the number of hits for any breakpoint created with <i>:bp</i>, <i>:inject</i>,
<i>:monitor</i>, <i>:watch</i>, and <i>:count</i>).<br>
<br>
The first form of <i>:count</i> is interesting when you want to stop
earlier than something bad happens so that you can see why the bad
think happened. Put the first form of <i>:count</i> at the start of
the function with the bug and then put a break in the function which is
hit when the bad think happens maybe with <i>:watch</i>. When you stop
at the bug place, check hit count at the start of the function. Add the
hit count in your <i>:count</i> breakpoint in your <b>ghciInt</b>
file restart and you can use <i>:steplocal</i> or <i>:loglocal</i> to
find out what went wrong.<br>
<br>
<i>:loglocal</i> is implemented directly in ghc source code. It does
exactly the same as <i>:steplocal</i> but makes sure that the trace
history does not contain anything outside of the function we step with <i>:steplocal</i>.
The problem is that <i>:steplocal</i>
works like the code was traced while it is executing. Mostly the result
is that your trace history is loaded with crap outside of the scope you
are interested in. I'll return to <i>:loglocal</i> later again.<br>
<br>
<i>:inject</i> is there when you need something special (<i>:monitor</i>,
<i>:watch</i>, and <i>:count</i> are implemented with something very
like <i>:inject</i>). E.g. when you want to do monitoring of a value
but do not want the associated breakpoint number printed.<br>
<br>
<i>:find</i> and <i>:findex</i> are there primary to search trace
history.<br>
<i>:find var1 :back</i><br>
&nbsp;&nbsp; will find the variable var1 in your trace history by back stepping it<br>
<i>:find var1 :step</i><br>
&nbsp;&nbsp; will single step forward till variable var1 is in the list of free
variables<br>
<i>:findex BL/Logic.hs:23 :loglocal</i><br>
&nbsp; will fill in your trace history will all the local breakpoints till
location BL/Logic.hs:23 is hit. Having the trace history filled in with
the right stuff is useful for checking out why you got bad results
later.<br>
<br>
Now lets return to Claus' idea of breakpoints with a list of
identifiers which should be available at the breakpoint location. You
can make sure the identifiers are available with the first form of <i>:count</i>.
It never stops but it puts records to the trace history. So the trace
history will contain free variables at the locations where you put <i>:count</i>.
This will be even more useful when automatic search of trace history is
built in (see ticket #2737). So a weaker form of Claus' idea can be
implemented by carefully selecting what should bet to the trace
history. Why a weaker form only? Well, in some cases, the&nbsp; variable
instances in trace log may not be the expected ones (they may be
from a different lexical scope). Experience with my code indicates this
should be rare.<br>
<br>
<i>:next</i> is an idea how to implement a kind of step over. That is
if by step over you mean something else than steplocal. The
non-lazy form of <i>:next</i> forces _result and does a <i>:step</i>.
The lazy form
forces only the top level constructor of _result before the step. Hey,
I even had a case when it worked just like I expected. But typically it
does not work because of bug #1531. _result is not correctly bound to
the result of selected expression in most of the practical cases. This
bug is also critical for all the forms of conditional breakpoints. It
would be cool if we could specify the condition based on _result or
some part of it. The implementation of ghciExt conditional breakpoints
would need to be extended to support conditions on _result (in
particular the breakpoint would need to be disabled during the
condition execution) but that is easy to do. Even more worrying thing
about bug #1531 is that it has the milestone set to _|_.<br>
<br>
It is easy to add <i>:enable</i> and <i>:disable</i> to support
enabling and disabling breakpoints. I just did not need it yet. Here is
how a GhciExt breakpoint looks like:<br>
<tt>*Main&gt; :show breaks<br>
[0] Main a.hs:4:2-8 ":cmd return$GhciExt.getStopCode 0 (True) "putStr
\"(0): \"\n:force x" "False""<br>
*Main&gt;</tt><br>
Just replace getStopCode with getDisabledStopCode and you have it
disabled. Return back to enable. Yeah, and implement
getDisabledStopCode which will just continue.<br>
<br>
I added :<i>loglocal</i> mostly to simulate how <i>:tracelocal</i> in
ticket #2737 would help. I was also trying how full tracing is helping.
In both cases the answer is: full tracing almost never helps. <i>:tracelocal</i>
from ticket #2737 as proposed originally would rarely help. The problem
is that trace log gets
overwhelmed with crap
when we cannot control what can be saved in it and what cannot be
saved. My idea is that user should be able to specify what can go in it
and also what should not go in it. Here is an alternative solution to
the ones I proposed in tickets #2737 and #2946. I think this one would
be best. The command to control the tracing should
look like:<br>
&nbsp;<tt>-- should everything be traced?<br>
:set trace (True|False)<br>
-- scopes which should be traced (or should not be traced when ! is
present)<br>
:set trace ( (!)? scopeid )*<br>
-- add/remove individual scopeids to/from the trace specification<br>
:set trace (+|-) (!)? scopeid<br>
</tt>where<tt> scopeid = ( conid . )* ( varid . )* varid</tt>
<br>
Notice how scopeid looks. It can have a sequence of varids at the end.
The reason is so that user can leave out a scope of a function which is
defined in a where clause. The scope specification is similar to the
proposal in ticket #3000. E.g. for this code:<br>
<tt>fn s = 'a' : add s<br>
&nbsp; where add = (++"z")<br>
</tt>it could look like<br>
:set trace Main.fn !Main.fn.add<br>
meaning trace whole scope of <b>fn</b> but not the stuff in the scope
of <b>add.<br>
</b>Order should not be important, requests for not tracing should have
precedence before requests to trace.<br>
The scopes which we want typically exclude are the ones which contain
loops. The loop content often fills in the trace log forcing
the interesting stuff out of it. It is better to investigate functions
with
loops separately in nested context.<br>
<br>
Notice that there is a bit difference between this proposal of
controlling trace content and the one in ticket #2737. #2737 assumes
usage of breakpoint arguments to specify a scope. The breakpoint
arguments give an ability to define scopes at finer level but there is
no option to define exclude scopes which I find important now.<br>
<br>
The summary is: Trace log is as useful as much you can control what can
get in it. The :trace command looks to me like an error. It is better
to control it by allowing/disallowing scopes.<br>
<br>
I also changed my opinion a bit about ticket #2945. :mergetrace would
be better than global trace history. Being able to investigate
something separately in a nested context is useful.<br>
<br>
If I should order the ghci debugger related tickets then the order
would be
like (more important first):<br>
#1531 (_result can get bound to the wrong value in a breakpoint)<br>
#2737 and #2946 (add :tracelocal to ghci debugger...&nbsp; and&nbsp;&nbsp;&nbsp; add
command :mergetrace...)<br>
#3000 (:break command should recognize also nonexported top level
symbols...)<br>
#2803 (bring full top level of a module in scope when a breakpoint is
hit in the ...)<br>
#1377 (the task: "We should print breakpoint related info only if
breakpoint has no commands set") but people debugging interactive
console applications would like to have this one the very top; <b>IIRC</b>
this may be easy to do, looks like all the printing is done in one
function (something like afterCmd???); also #2950 looked like trivial
to do (like 15 mins without the compile time???)<br>
<br>
And the last thing: my first time experiences hacking in the <i>:loglocal</i>
into ghc. I cannot tell much, I spend with it only one long Sunday
afternoon, but here are my two points:<br>
* I needed to extend ghc interface. The type of function GHC.resume
changed from:<br>
&nbsp;&nbsp;&nbsp; <i class="moz-txt-slash"><span class="moz-txt-tag"></span>resume
:: GhcMonad m =&gt; SingleStep -&gt; m RunResult<span
 class="moz-txt-tag"></span></i>
<br>
&nbsp;&nbsp;&nbsp; to:
<br>
<i class="moz-txt-slash"><span class="moz-txt-tag">&nbsp;&nbsp;&nbsp; </span>resume
:: GhcMonad m =&gt; (SrcSpan-&gt;Bool) -&gt; SingleStep -&gt; m
RunResult<span class="moz-txt-tag"></span></i>
<br>
&nbsp;&nbsp;&nbsp; ... plus the corresponding implementation change.
The added argument is a filtering function to limit source spans which
can recorded in the trace history. <br>
* It would be cool if ghci has its own dir in the souce tree where only
the ghci source files are. It would encourage people to hack it more
since it would be easier to maintain private patches and merging
upstream. It would be also easier to make sure one modifies only ghci
source code so that it works with other ghc releases.<br>
<br>
Hopefully this helps somebody,<br>
&nbsp; Peter.<br>
<br>
</body>
</html>