#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 <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
