Re: [GHC] #2946: tracing should be controled by a global flag (it should not be resume context specific)
#2946: tracing should be controled by a global flag (it should not be resume context specific) -+-- Reporter: phercek |Owner: Type: feature request | Status: new Priority: normal|Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by phercek): I asked for :force expr in the second bullet of the ticket description. It was an insight by accident. It would be really cool if we could force expressions and not only a list of variables. The main reason is user defined conditional breakpoints. A breakpoint condition may contain thunks which need to be forced to compute the condition result. This may result in hitting other breakpoints in nested contexts. This may be required or not. It depends, but it is almost never required if we query some expression containing _result variable. The problem is we stop at the same breakpoint we are just now at. With :foce expr we could force the breakpoint stop condition first and then query its result by checking the it variable.[[BR]] This is convenient for scripts, not that interesting for manual interaction. But scripts can disable breakpoints before evaluating the stop condition and enable them after the condition evaluation finished so there is a workaround. I just did not add :enable and :disable to my .ghci yet :-/ -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2946#comment:4 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] #2946: tracing should be controled by a global flag (it should not be resume context specific)
#2946: tracing should be controled by a global flag (it should not be resume context specific) -+-- Reporter: phercek |Owner: Type: feature request | Status: new Priority: normal|Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * difficulty: = Unknown * milestone: = 6.12 branch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2946#comment:3 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] #2946: tracing should be controled by a global flag (it should not be resume context specific)
#2946: tracing should be controled by a global flag (it should not be resume context specific) --+- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal| Milestone: Component: GHCi |Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Comment (by phercek): Current :steplocal fills in trace history with all source locations executed even when they are not inside the function stepped through using :steplocal. If this is accepted then the source locations outside the localy stepped function should not be logged to trace history if trace is not set to True. Actually I think the locations ouside the locally stepped function should not be added to the trace history even when this is rejected in general. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2946#comment:2 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] #2946: tracing should be controled by a global flag (it should not be resume context specific)
#2946: tracing should be controled by a global flag (it should not be resume context specific) --+- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal| Milestone: Component: GHCi |Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Comment (by phercek): Actually instead of :trace on/off the interface should be rather :set trace True/False. The reason is relationship of this ticket to ticket #2737. The rest stays as it is. One more advantage to this approach is that user can check whether tracing is on with :show trace (if it is implemented). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2946#comment:1 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
[GHC] #2946: tracing should be controled by a global flag (it should not be resume context specific)
#2946: tracing should be controled by a global flag (it should not be resume context specific) -+-- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal| Component: GHCi Version: 6.10.1| Severity: minor Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -+-- Instead of :trace and :trace expr command there should be one command :set trace on/off and a new command :debug expr. :set trace would control a global flag indicating whether tracing should be active or not. If tracing is active then:[[BR]] * :continue would behave like current :trace,[[BR]] * forcing a value using :force expr woudl work like current :trace expr but ignoring breakpoitns,[[BR]] * :debug expr would work like current :trace expr,[[BR]] * and :main ... would start Main.main with tracing on from the very beginning.[[BR]] If tracing is not active then :continue, :force, :main would behave like they do now and :debug expr would be the same as current expr. Reasoning: I believe people use tracing to get access to variables which are not free in the selected scope but which contributed to values in the selected scope. So if they want variable availability they want tracing on all the time if they care about speed they want tracing off all the time. With this change request accepted they do not need to remember which command to use to continue or to print a forced value. When an expr is an argument to a ghci command and tracing is on then trace hisotry is extended, if tracing is off then trace history is not extended, if expr is typed on the ghci command line directly then tracing is never extended. This change is not that important for manual ussage but it helps to simplify custom defined ghci comamnds/scripts (which e.g. will not need to take care whether to use :continue or :trace based on a global flag). This would also allow to start tracing from the very beggining of :main instead of setting a break at Main.main with a script set to :trace and then running :main Related discussion is here: http://www.haskell.org/pipermail/glasgow- haskell-users/2009-January/016436.html I do not know about other usage patterns for which the current state of tracing UI is better. If you do know then vote against this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2946 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
