Opened 7 years ago

Last modified 5 months ago

#2803 new feature request

bring full top level of a module in scope when a breakpoint is hit in the module

Reported by: phercek Owned by:
Priority: lowest Milestone: 7.12.1
Component: GHCi Version: 6.8.3
Keywords: debugger Cc: mnislaih@…
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

It should do something like :module + *ModuleWhereBreakpointWasHit and remove the added top level symbols of ModuleWhereBreakpointWasHit when we leave it.
The goal is so that the functions which are in scope when we hit a breakpoint are readily available for investigations of the values stored in the free variables of the selected expression.
This feature request is a consequence of the dicsussion in this ticket http://hackage.haskell.org/trac/ghc/ticket/2740#comment:4

... and a realated thing: When I do something like :module + ModName and later I do :module + *ModName then the non-exported symbols from ModName are not added into the scope.

Change History (14)

comment:1 Changed 6 years ago by igloo

  • difficulty set to Unknown
  • Milestone set to 6.12 branch

comment:2 Changed 6 years ago by phercek

Having this implemented is also very handy for user defined command for conditional breakpoints. Sometimes I find myself in need to stop based on some structure member which accessor function is not exported. In such a case, I cannot use it in the code for the conditional breakpoint. To make this work my user defined conditional breakpoint command needs one more argument to specify the module name for explicit :module commands. This sucks. I tried to find out how to get the module name automatically when stopped at a breakpoint but the only think I can get is the file name using ":show context". The problem is that the file name does not need to correspond to the module name.

comment:3 follow-up: Changed 6 years ago by phercek

In addition to adding all the symbols (even the nonexported ones) from the module where breakpoint was hit, consider "executing" all the import directives of the module where the breakpoint was hit. I would like it. Though this is not critical since I can just fully qualify all the names which are imported in my breakpoint scripts. Since the list of all the import directives can be long this would increase command prompt a lot. That means the modules introduced with import directives should be represented by one token in the command prompt (e.g. bpContext). This would also allow to add/remove all the imports easily with :module (+|-)bpContext.

comment:4 in reply to: ↑ 3 Changed 6 years ago by simonmar

Replying to phercek:

In addition to adding all the symbols (even the nonexported ones) from the module where breakpoint was hit, consider "executing" all the import directives of the module where the breakpoint was hit.

The "top-level scope of a module" is exactly the set of names that are in scope in the source code of a module, including all those names in scope by virtue of being imported. So I think the proposed solution would do what you want.

comment:5 Changed 5 years ago by igloo

  • Milestone changed from 6.12 branch to 6.12.3

comment:6 Changed 5 years ago by igloo

  • Milestone changed from 6.12.3 to 6.14.1
  • Priority changed from normal to low

comment:7 Changed 4 years ago by igloo

  • Milestone changed from 7.0.1 to 7.0.2

comment:8 Changed 4 years ago by igloo

  • Milestone changed from 7.0.2 to 7.2.1

comment:9 Changed 4 years ago by igloo

  • Milestone changed from 7.2.1 to 7.4.1

comment:10 Changed 3 years ago by igloo

  • Milestone changed from 7.4.1 to 7.6.1
  • Priority changed from low to lowest

comment:11 Changed 3 years ago by igloo

  • Milestone changed from 7.6.1 to 7.6.2

comment:12 Changed 11 months ago by thoughtpolice

  • Milestone changed from 7.6.2 to 7.10.1

Moving to 7.10.1.

comment:13 Changed 5 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.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:14 Changed 5 months 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.

Note: See TracTickets for help on using tickets.