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
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.