my experience with ghci debugger extensions
phercek at gmail.com
Thu Feb 5 12:07:44 EST 2009
Pepe Iborra wrote:
> Hello Peter,
> Your efforts are simply outstanding. Thanks a lot for sharing your
> experiences. I want to add a few comments:
> - Regarding your :logLocal, you should rename it to :stepLocal, open a
> ticket, and attach your patch. We should really try to get this into
> :stepLocal is broken right now, as you say it traces a lot of
> garbage. I implemented it and shortly later
> noticed the problem you mention, but never got around to fixing it.
> Thanks for shouting.
> (unless you think it makes sense to keep two versions of this
> command, :logLocal and :stepLocal)
I do no think it makes sense to keep two versions (both /:steplocal/ and
/:loglocal/). I'm aware the name loglocal is bad. I named it that way
since it was a way for me to fill in trace log with the right stuff
using /:findex/. I kind of did not really intended to release this but
I noticed that there was some activity on my ghci debugger related
tickets and wanted to get it out till anybody starts to code. Yeah and
I'm getting limited by bugs and missing features too.
Back to the /:loglocal/ and /:steplocal/. I think there should be only
/:steplocal/, but I think the interface for tracing is bad. There should
not be /:trace/ command at all. Instead (if the proposal with /:set
trace/ is accepted (also mentioned in ticket #2946)) when /:set trace/
is set to True then /:steplocal/ would behave like now; if it is set to
False it would behave like /:loglocal/. Of course setting trace to True
is just a special case; in my opinion almost useless. The useful cases
are when you can set it to scopes either denying them or allowing them.
The idea is user should specify filter what is traced. With filter
switched off nothing is traced and this case should not have any
significant performance impact. When tracing filter is set up into
something more complicated it may have some performance impact, but in
that case we are not after speed.
> - Your idea of forcing _result to implement step over is very nice.
> A while ago I tried and failed at implementing :next. The conclusion
> was it cannot be done without a lexical call stack.
> Your idea could be useful as a pseudo :next, as long as the user of
> the debugger is ok with changing the evaluation semantics of the
> program. However, I don't know if there is a fix for the _result bug
> at hand's reach.
As for as the /:next/ semantics. I actually do not know what it should
be in a lazy language. The trick with _result is close sometimes. I
could really use it. Especially in my /if/ conditions. They are often
simple in my code just some simple arithmetics and record accessors.
Stepping over them individually is a pain. It would be also good to step
over a function containing a loop when using /:loglocal/ otherwise (so
that the loop does not pollute trace log).
> I look forward to playing this.
> Your custom ghc tar.gz file contains an additional patch,
> network.patch, but there are no instructions about it. I assume it is
> ok to ignore it.
It is a patch from arch linux upstream. I do not have idea why it is
there. It has license whatever arch linux has. You probably can find out
more on arch-haskell mailing list.
> Finallly, please do not forget to add a link to this in the GHCi
> Debugger wiki page at
> and/or at the debugging page at
Hmmm, I do not have wiki account and cannot create it. "Create an
account or log in" page has a note: "new account creation has been
disabled as an anti-spam measure". So I guess it is up to somebody who
has a wiki account :-D
More information about the Glasgow-haskell-users