Opened 7 years ago
Closed 7 years ago
#116 closed enhancement (fixed)
Factor "breakpoint profile" out
Reported by: | ke | Owned by: | ke |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | kahina-qtype | Version: | |
Keywords: | Cc: |
Description
The instructions which QType predicates to trace, which QType predicates not to trace and on which layer to put them are now scattered between tracer:set_breakpoints/1, tracer:not_traced/1 and QTypeLayerDecider, partly in declarative, partly in procedural styles. There should be a separate Prolog module preferably containing all of this information (tricky in case of layers, since that is implemented on the Java side) in a declarative style. Ideally, there should also be an option allowing users to load the profile from a different module. In any case, users should be able to modify the profile easily.
Change History (2)
comment:1 Changed 7 years ago by jd
comment:2 Changed 7 years ago by ke
- Resolution set to fixed
- Status changed from new to closed
Done, called it "tracer profile". Layers are not part of it, though - handling them in a dynamic way must wait until we adinister tracer profiles on the Java side.
Which is a good idea for the future. We can indeed use skip points to achieve the same behavior, but additionally we need to distinguish skip points that skip traced steps (we see them, but not their descendants) from non-traced steps (we never see them since we don't trace them).
Also, we need to think about how to specify options for specific breakpoints that are now entirely specified on the Prolog side, like source_code_location/3 and goal_desc/4.
Anyway, one hurdle for the move from Prolog to Java is now out of the way: the complete tracer profile is now concentrated nicely, declaratively and uniformly in tracer_profile.pl.
Agreed, but don't call it breakpoint profile. The class BreakpointProfile? was recently introduced to store and administer user-defined breakpoints, and is used as a part of a Project in my recent attempt to group together configurations in an intuitive way. Is there any ase that our skip point mechanism couldn't handle in principle? Could skip points in any way be used as a method for administring these breakpoints entirely from the Java side? Easy modifiability could be achieved in a much more direct way, as the entire configuration information could become part of a Kahina project.