Re: [GHC] #1377: GHCi debugger tasks
#1377: GHCi debugger tasks -+-- Reporter: simonmar |Owner: mnislaih Type: task | Status: new Priority: normal|Milestone: 6.12 branch Component: GHCi | Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * milestone: 6.10 branch = 6.12 branch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1377#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1377: GHCi debugger tasks
#1377: GHCi debugger tasks
-+--
Reporter: simonmar |Owner: igloo
Type: task | Status: new
Priority: normal|Milestone: 6.10 branch
Component: GHCi | Version: 6.7
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by mnislaih):
* owner: = igloo
Comment:
Validated and pushed
{{{
Sun Feb 22 20:55:51 CET 2009 Peter Hercek pher...@gmail.com
* Do not print anything to stdout when stopping at a breakpoint with
custom code attached
}}}
Ian, this patch can be merged to 6.10, but do not close the ticket yet.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1377#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1377: GHCi debugger tasks
#1377: GHCi debugger tasks -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by mnislaih): Thanks for the patch Peter, I'll push it as soon as I run validate on it -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1377#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1377: GHCi debugger tasks
#1377: GHCi debugger tasks -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by phercek): ''* Some kind of step over or next...''[[BR]] Now I see what was meant. It can be achieved with something like '':cmd return _result\n:step''. Though I do not have any workaround for step out (would require dynamic stack?). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1377#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1377: GHCi debugger tasks
#1377: GHCi debugger tasks -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by mnislaih): * cc: mnisl...@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1377#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1377: GHCi debugger tasks
#1377: GHCi debugger tasks -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by phercek): * cc: pher...@gmail.com (added) Comment: Some ideas: * ''Some kind of step over or next...''[[BR]] Isn't :steplocal or :stepmodule it? Looks like already done. * ''We can disable a breakpoint with...''[[BR]] A breakpoint which has a code attached to it should not print anything not printed by the attached code. Well, except the command prompt printed if the attached code does not issue :continue. This would be handy. I asked for it also in my comment to #2737. If this is not done then custom implementation of features like conditional breakpoint or breakpoint setup solely to monitor value changes (an alternative to printf debugging) spit out a lot of garbage. The garbage can be suppressed but that suppresses also the legitimate program output. If you implement this then implementing flag for disabling breakpoints (a point later on) is not needed. * ''if a :force results in a breakpoint...''[[BR]] :force hitting a breakpoint should either print more information about the breakpoint or it should not print anything at all. The current situation is the worst one (it does something in the middle :) ). See also #2950. Anyway, I like the fact that :force does not stop at breakpoints. This ticket #2946 is related to :force too. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1377#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1377: GHCi debugger tasks
#1377: GHCi debugger tasks -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Old description: I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these. == easy == * Autocompletion for :break only provides names, not modules == moderate == * for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us show the enclosing binding(s) for each breakpoint in the UI (eg. Stopped in M.f (M.hs:40:23-28)). * :force should catch exceptions, so [1,2,undefined] would display as `[1,2, exception ]` * show variables with unboxed types. * tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh) == unknown, or require thinking about == * Some kind of step over or next command is needed. * `:print` shouldn't ever use show? * `:break qualified name` only works if the name is exported can/should we relax this? * sometimes the result types are wrong (see result001 test) * perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get thrown away by :continue) * 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? * Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way. * Flag to disable breakpoints? * When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this be fixed? * threads and breakpoints. * if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get *** Ignoring breakpoint). * It's a bit strange that in f = e you don't get a breakpoint covering the whole binding, but in f x = e you do. New description: I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these. == easy == * Autocompletion for :break only provides names, not modules == moderate == * for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us show the enclosing binding(s) for each breakpoint in the UI (eg. Stopped in M.f (M.hs:40:23-28)). * :force should catch exceptions, so [1,2,undefined] would display as `[1,2, exception ]` * show variables with unboxed types. * tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh) == unknown, or require thinking about == * Some kind of step over or next command is needed. * `:break qualified name` only works if the name is exported can/should we relax this? * perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get thrown away by :continue) * 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? * Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way. * Flag to disable breakpoints? * When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this be fixed? * threads and breakpoints. * if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get *** Ignoring breakpoint). * It's a bit strange that in f = e you don't get a breakpoint covering the whole binding, but in f x = e you do. Comment (by simonmar): removing a couple of items that are done or have other tickets. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1377#comment:2 GHC
Re: [GHC] #1377: GHCi debugger tasks
#1377: GHCi debugger tasks -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: 6.10 Component: GHCi | Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -+-- Old description: I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these. == easy == * Autocompletion for :break only provides names, not modules == moderate == * for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us show the enclosing binding(s) for each breakpoint in the UI (eg. Stopped in M.f (M.hs:40:23-28)). * :print probably doesn't work with strict unpacked pairs. * :force should catch exceptions, so [1,2,undefined] would display as `[1,2, exception ]` * show variables with unboxed types. * tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh) == unknown, or require thinking about == * `:print` shouldn't ever use show? * `:break qualified name` only works if the name is exported can/should we relax this? * sometimes the result types are wrong (see result001 test) * perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get thrown away by :continue) * 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? * Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way. * Flag to disable breakpoints? * When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this be fixed? * threads and breakpoints. * if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get *** Ignoring breakpoint). * It's a bit strange that in f = e you don't get a breakpoint covering the whole binding, but in f x = e you do. New description: I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these. == easy == * Autocompletion for :break only provides names, not modules == moderate == * for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us show the enclosing binding(s) for each breakpoint in the UI (eg. Stopped in M.f (M.hs:40:23-28)). * :force should catch exceptions, so [1,2,undefined] would display as `[1,2, exception ]` * show variables with unboxed types. * tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh) == unknown, or require thinking about == * Some kind of step over or next command is needed. * `:print` shouldn't ever use show? * `:break qualified name` only works if the name is exported can/should we relax this? * sometimes the result types are wrong (see result001 test) * perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get thrown away by :continue) * 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? * Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way. * Flag to disable breakpoints? * When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this be fixed? * threads and breakpoints. * if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get *** Ignoring breakpoint). * It's a bit strange that in f = e you don't get a breakpoint covering the whole binding, but in f x = e you do. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1377 GHC http://www.haskell.org/ghc/ The Glasgow
[GHC] #1377: GHCi debugger tasks
#1377: GHCi debugger tasks ---+ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: 6.10 Component: GHCi |Version: 6.7 Severity: normal| Keywords: Difficulty: Unknown | Os: Unknown Testcase:| Architecture: Unknown ---+ I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these. == easy == * Autocompletion for :break only provides names, not modules == moderate == * for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us show the enclosing binding(s) for each breakpoint in the UI (eg. Stopped in M.f (M.hs:40:23-28)). * :print probably doesn't work with strict unpacked pairs. * :force should catch exceptions, so [1,2,undefined] would display as `[1,2, exception ]` * show variables with unboxed types. * tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh) == unknown, or require thinking about == * `:print` shouldn't ever use show? * `:break qualified name` only works if the name is exported can/should we relax this? * sometimes the result types are wrong (see result001 test) * perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get thrown away by :continue) * 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? * Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way. * Flag to disable breakpoints? * When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this be fixed? * threads and breakpoints. * if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get *** Ignoring breakpoint). * It's a bit strange that in f = e you don't get a breakpoint covering the whole binding, but in f x = e you do. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1377 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
