Re: [GHC] #2946: tracing should be controled by a global flag (it should not be resume context specific)

2009-02-03 Thread GHC
#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 " 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 " 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: 
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)

2009-02-02 Thread GHC
#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: 
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)

2009-01-23 Thread GHC
#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: 
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)

2009-01-21 Thread GHC
#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: 
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)

2009-01-13 Thread GHC
#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 " command there should be one
 command ":set trace on/off" and a new command ":debug ".

 ":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 " woudl work like current ":trace
 " but ignoring breakpoitns,[[BR]]
  * ":debug " would work like current ":trace ",[[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 " would be the same as current
 "".

 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  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  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: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs