Re: my experience with ghci debugger extensions
Peter Hercek wrote: Pepe Iborra wrote: - 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. Ach, I missed I'm supposed to do this first time I read the message. I'll get to it at worst during this weekend. http://hackage.haskell.org/trac/ghc/ticket/3035 It is there with a patch attached. Maybe you can still validate and add it to 6.10.2. Sorry for not noticing that you wanted me to do it. For me it is not important, I already run a custom ghc anyway because of other things so one more patch does not change much. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
Peter Hercek wrote: Also there does not seem to be a demand for ghciext package so I'm not Hi Peter.. just to note that I haven't had the need/time yet to try it, but I'm very thankful for the work you and Pepe are doing to make ghci more powerful. It's a very useful tool for learning about Haskell and figuring out perplexing behaviours in real-world programs. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
Pepe Iborra wrote: - 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. Ach, I missed I'm supposed to do this first time I read the message. I'll get to it at worst during this weekend. 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 Ok, I found a note in HWN that Ashley Yakeley can create a wiki account. He kindly did it for me so I updated the second page. Also there does not seem to be a demand for ghciext package so I'm not going to advertise it any more but I'll keep the latest version here (if anybody would be interested): http://www.hck.sk/users/peter/pub/ Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
Hi, Simon Marlow wrote: If you felt like working on this yourself, possibly with Pepe, then we'd be happy to support in any way we can. Thanks. It may happen though it is not probable. I do not know the code so anything non-trivial is a significant effort and my free weekends and evenings are sparse :-( If I would do anything, should it be posted here, sent to Pepe, or attached to the ticket? Is it a habit to indicate in the ticket that somebody started coding it actually (especially if it takes longer to implement)? Peter, it is best if you attach everything to the ticket. If you want to signal that you started coding on a ticket, just take ownership of it. As for as /:next/ command: Like Pepe indicated, I do not have idea how to do it without working _result and without dynamic stack. Though dynamic stack should not be that hard since how otherwise could profiler count ticks for cost centers. And dynamic stack would be great. It would create new options where to store lists of free variables of selected expressions :) Having (a kind of messy approximation of) a dynamic stack is possible with a variant of the cost center stacks mechanism used for profiling. But the downside is that code and libraries would need to be compiled for debugging. Nevertheless, I believe that having a true dynamic stack would make debugging so much simpler. Ok, I did not understand this part a bit till I did not skim over http://www.haskell.org/~simonmar/papers/ghci-debug.pdf Maybe that paper should be mentioned on the wiki pages about debugger. Something like: "If you do not understand why ghci debugger is limited in such a strange way read this." Debugging for lazy functional languages is a hard problem. The GHCi debugger is no panacea. But you are right in that the current state of things can be improved in several ways. However, the Simons have already enough things in their hands; it is up to us to step forward and help. Unfortunately, my time is also very limited, as I am trying to get a degree here. I am happy to support Peter and anyone else who wants to hack on the debugger, and I will continue maintaining the code around :print. But right now I don't think I can find the time to work on the tickets brought up in this discussion. Cheers, pepe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
Hi Simon, Simon Marlow wrote: If you felt like working on this yourself, possibly with Pepe, then we'd be happy to support in any way we can. Thanks. It may happen though it is not probable. I do not know the code so anything non-trivial is a significant effort and my free weekends and evenings are sparse :-( If I would do anything, should it be posted here, sent to Pepe, or attached to the ticket? Is it a habit to indicate in the ticket that somebody started coding it actually (especially if it takes longer to implement)? So #1531 is tricky to fix, unfortunately. The implementation of _result is a bit of a hack in the first place. The fundamental problem is that a tick expression looks like this case tick of _ -> e where 'e' is not necessarily exactly the same as the expression that was originally inside the tick. We are careful to maintian the property that the tick is evaluated iff the original expression is evaluated, but that's all. _result is bound to e, which may or may not be what you wanted. One way to fix it would be to add extra constraints on what the simplifier can do with tick expressions. I don't like the sound of that because (a) I doni't know exactly what restrictions we'd have to add and (b) this amounts to changing the semantics of Core (i.e. changing which transformations are valid). Ok, I did not understand this part a bit till I did not skim over http://www.haskell.org/~simonmar/papers/ghci-debug.pdf Maybe that paper should be mentioned on the wiki pages about debugger. Something like: "If you do not understand why ghci debugger is limited in such a strange way read this." A breakpoint condition on _result: My guess is that in about half of the cases I can just put them on a free variable on some other location just as comfortably. In other cases I'm out of luck :) As for as /:next/ command: Like Pepe indicated, I do not have idea how to do it without working _result and without dynamic stack. Though dynamic stack should not be that hard since how otherwise could profiler count ticks for cost centers. And dynamic stack would be great. It would create new options where to store lists of free variables of selected expressions :) Maybe there's another way to fix it, but I can't think of one right now. If by simplifier you did not mean straight translation to core, then I assume you wanted to try to just skip over all the optimizations (simplifications?). Was it hard to do it or was the performance impact so bad that it was not worth the addition of a command line switch? Thanks for reading the post about debugging, now there is at least a chance that it will be better once. Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
Hi Peter, Thanks very much for all the suggestions here. As Simon mentioned, we're not actively working on the debugger, and speaking for myself I don't plan to invest significant effort in it in the near future (too many things to do!). If you felt like working on this yourself, possibly with Pepe, then we'd be happy to support in any way we can. Peter Hercek wrote: /:next/ 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 /:next/ forces _result and does a /:step/. 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 _|_. So #1531 is tricky to fix, unfortunately. The implementation of _result is a bit of a hack in the first place. The fundamental problem is that a tick expression looks like this case tick of _ -> e where 'e' is not necessarily exactly the same as the expression that was originally inside the tick. We are careful to maintian the property that the tick is evaluated iff the original expression is evaluated, but that's all. _result is bound to e, which may or may not be what you wanted. One way to fix it would be to add extra constraints on what the simplifier can do with tick expressions. I don't like the sound of that because (a) I doni't know exactly what restrictions we'd have to add and (b) this amounts to changing the semantics of Core (i.e. changing which transformations are valid). Maybe there's another way to fix it, but I can't think of one right now. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: my experience with ghci debugger extensions
| Hello Peter, | | Your efforts are simply outstanding. Thanks a lot for sharing your | experiences. Seconded! Very useful stuff. That said, Simon M and I are not really focused on the debugger right now, so I'm hoping that someone (Pepe or others helping him) can follow up your suggestions. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: my experience with ghci debugger extensions
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) - 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. 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. I applied the two other patches succesfully and hopefully in a few minutes will have a working build. Evidently this is a suboptimal way to distribute your changes. If GHCi lived in its own package as a real GHC api client, it would certainly be much easier to distribute modifications like these.Although it would not have helped in this occasion: the changes you needed required modifying the API. 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 Thanks, pepe 2009/2/5 Peter Hercek : > Hi users of ghci debugger, > > This post is going to be a bit longer. Here are few cookies to motivate you > to go on: > * you will probably like it more than printf debugging for a lot of cases > * 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: > http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15900 > * 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) > > 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. > > 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. > > You can get my extensions here: > http://www.hck.sk/users/peter/pub/ghciext-0.1.tar.gz > 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. > > And here are arch linux packaging instructions for my custom ghc (if you are > an arch linux user just download and run makepkg :) ): > http://www.hck.sk/users/peter/pub/ghc-custom-6.10.1.tar.gz > 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. > > 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: > http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html > > Here is the list of custom commands in ghciext package: > :defs -- list user-defined commands > :. -- source commands from > :redir ... -- execute redirecting stdout to > :grep ... -- filter lines matching from output > :* ... -- run times > :x ... -- run with stdout suppressed > :bp -- put breakpoint at location (adds hit > count) > :inject -- at location execute if , and stop > if > :monitor [""] -- show comma separated variables at location > if > :watch -- break at location when is True > :count (_|) [] -- count/query/stop execution at location > :find ... -- step with until is found > :findex ...-- step with until is found > :next [lazy] --
my experience with ghci debugger extensions
Hi users of ghci debugger, This post is going to be a bit longer. Here are few cookies to motivate you to go on: * you will probably like it more than printf debugging for a lot of cases * 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: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15900 * 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) 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. 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. You can get my extensions here: http://www.hck.sk/users/peter/pub/ghciext-0.1.tar.gz 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. And here are arch linux packaging instructions for my custom ghc (if you are an arch linux user just download and run makepkg :) ): http://www.hck.sk/users/peter/pub/ghc-custom-6.10.1.tar.gz 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. 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: http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html Here is the list of custom commands in ghciext package: :defs -- list user-defined commands :. -- source commands from :redir ... -- execute redirecting stdout to :grep ... -- filter lines matching from output :* ... -- run times :x ... -- run with stdout suppressed :bp -- put breakpoint at location (adds hit count) :inject -- at location execute if , and stop if :monitor [""] -- show comma separated variables at location if :watch -- break at location when is True :count (_|) [] -- count/query/stop execution at location :find ... -- step with until is found :findex ...-- step with until is found :next [lazy] -- step over; lazy version forces only the top constructor :xout -- redirect ghci stdout to /dev/null :out -- redirect ghci stdout back to console :defs, :., :redir, :grep, are the same as the commands in Claus' tutorial. The only differences I recall now are: * grep pattern can be in quotation marks (easier search for spaces) * grep merges :browse output more nicely * redir can accept :step, :steplocal etc; i.e. also the commands which sometimes remove top level bindings * the commands do not pollute top level bindings so much 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: http://hackage.haskell.org/trac/ghc/search?q=phercek&noquickjump=1&ticket=on 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: /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?/ 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 /:main/ and /:continue /with my command /:x/. This makes output by default disabled and ghciExt enables it just before a breakpoint cod
