Opened 9 years ago

Last modified 22 months ago

#2737 new feature request

add :tracelocal to ghci debugger to trace only the expressions in a given function

Reported by: phercek Owned by:
Priority: lowest Milestone:
Component: GHCi Version: 6.8.3
Keywords: debugger Cc: mnislaih@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

As there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within a given function. When an acces to a variable is needed it would be searched first in the selected expression and if not found the search would continue in the expressions from the trace history. If the value used would originate from the trace history it should be indicated so in the output: at the end or beginning of the output there would be the list of identifiers which values were taken from trace history. This would avoid the tedious task of searching the trace history manually and moreover it would limit the history to the interesting parts (so hopefully the current depth of 50 would be enough).

:tracelocal should take an optional argument which defines the function to trace. Similar options as for a breakpoint specification (:break command) would be fine. It might be usefull to associate the tracelocal trace with breakpoint and having an option to set it on for given breakpoint (in such a case it would be possible to add tracelocal flag for a breakpoint).

Note that the results from the trace history may not be from the expected scope but the same problem is with "printf debugging" which is an efficient way to debug Haskell programs now too. The list of identifiers which were taken from trace history (while evaluating an interactively entered expression) should be provided because of the posibility to get values from an unexpected scope.

This should be a cheap way to make ghci debugger better than just plain "printf debugging", especially when used together with scriptable breakpoints (where one could script each breakpoint individually - not only all of them at once with :set stop). The best solution from user point of view would be just to provide access to all the variables which are in scope in a given expression (not just the free ones) but it is believed that it would introduce too much overhead.

Here is the url of the thread head where this proposal started to evolve: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015840.html

Change History (18)

comment:1 Changed 9 years ago by phercek

Actually, I see now, that it is possible to script individual breakpoints with ":set stop N <cmd>" but it is not indicated so in the output of :help command. The format in the :help output is ":set stop <cmd>" but it should be ":set stop [N] <cmd>". I still miss a minor feature: a switch to disable any default output when a breakpoint with a custom script is hit (so that only the custom script output (if any) is visible).

comment:2 Changed 9 years ago by mnislaih

Cc: mnislaih@… added

comment:3 Changed 9 years ago by igloo

difficulty: Unknown
Milestone: 6.12 branch

comment:4 Changed 9 years ago by phercek

Before implementation of this is commited it should be decided about ticket #2946 which should be either accpeted or rejected. If it is rejected nothing changes but if #2964 is accepted then user interface for this command should be a bit different. Instead of ":tracelocal <breakpointArgs>" there should be a command ":set trace <breakpointArgs>". If this second alternative is implemented then an user can check what is being traced by ":show trace". Being able to check what fucntions are being traced would be handy. Then it could be also added ":unset trace <breakpointArgs>" xor ":unset trace <id>" (in case trace local locations get numbered like breakpoints are).

comment:5 Changed 9 years ago by fasta

I don't really believe in the "too much overhead" argument, until there is a clear analysis, which demonstrates this. It's often possible during debugging to create a small test case (one which does not take a long time to run). So, even recording all the state changes in the machine would be possible. I also argue that this should be the default. If it is too slow, people would just use some approximation (like is currently being done).

comment:6 Changed 9 years ago by phercek

Maybe the analysis was done, at least partially. A Lightweight Interactive Debugger for Haskell paper indicates so at the end of chapter 4.3.
As for as the filtering of the trace history, it is not about performace savings but making sure that the right stuff is in it. A possibility of detailed filtering what goes into the trace log is important. I discussed it in this message my experience with ghci debugger extensions.
Btw, a new version of GhciExt (0.6) is available here. It does not require prefixing with :x any more and works with stock ghc 6.10.3. No custom patches to ghc are needed.

comment:7 Changed 8 years ago by igloo

Milestone: 6.12 branch6.12.3

comment:8 Changed 7 years ago by igloo

Milestone: 6.12.36.14.1
Priority: normallow

comment:9 Changed 7 years ago by igloo

Milestone: 7.0.17.0.2

comment:10 Changed 7 years ago by igloo

Milestone: 7.0.27.2.1

comment:11 Changed 6 years ago by igloo

Milestone: 7.2.17.4.1

comment:12 Changed 6 years ago by igloo

Milestone: 7.4.17.6.1
Priority: lowlowest

comment:13 Changed 5 years ago by igloo

Milestone: 7.6.17.6.2

comment:14 Changed 3 years ago by thoughtpolice

Milestone: 7.6.27.10.1

Moving to 7.10.1.

comment:15 Changed 3 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:16 Changed 3 years ago by thoughtpolice

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:17 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:18 Changed 22 months ago by thomie

Milestone: 8.0.1
Note: See TracTickets for help on using tickets.