my experience with ghci debugger extensions

[Peter Hercek]

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
> 6.10.2.
>   :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
>
> http://haskell.org/haskellwiki/GHC/GHCi_debugger
>
> and/or at the debugging page at
>
> http://haskell.org/haskellwiki/Debugging
>   
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

Peter.