Minutes 2007-02-14 @9:30 US-EST

[Andrew Cagney <cagney@redhat.com>]

Present: Rick, Phil, Mike, Cagney, Elena, Moller, Kris, Stan, Tim, 
Jonathan, Mark, Sami, Nurdin

(snow in Toronto meant some people arrived late)

HPD command line.
-----------------------
Stan and Tim provided a walk through.

tab-completion:
- per bug(?), for a full completion, should append a space as that is 
the next thing the user will type, vis:
help<tab> -> help_

attach:
- HPD syntax is <<attach program pid ...>>, per bug (?) the <<program>> 
is redundant, and just the list of pids need to be provided
- attach needs to provide direct feed back that the operation is 
completed, for instance by displaying the line of the main thread

print:
Working in some cases.  Need to expose code to more stress testing.

help:
Simple help works, but <<help sub-command>> doesn't display the more 
specific information.

breakpoint:
The syntax needs to review the HPD, in particular how to specify 
file#line or foo(int) or file#foo(int) or #glibc.so#printf or ...; the 
syntax is powerful and follow pattern matching (but may contain 
limitations).  Most important the wart of having to specify 'foo(int)', 
caused by using ':' as the breakpoint separator needs to be avoidable.

additional comments and notes:

threads and thread groups?
The HPD describes how the prompt can change, reflecting which threads an 
operation will apply to.  For instance:
  [1.1,1.2]> break foo
applies the breakpoint to both threads.

transcript mechanism?
is there a command for capturing operations (hpd defines one) so that it 
is possible to capture how people are trying to use the interface.

registers?
Brief discussion about adding a way to print registers; was noted that 
this requires core changes, in particular changing 
frysk.proc.Task.registers so that they are described in terms of 
frysk.value.Value - i.e., the registers have a type.

disassembler?
Brief discussion about adding a disassembler; was noted that 
frysk.rt.StackFrame will need to be modified adding a frysk.rt.Symbol 
object that contains the function address, name, and bound; and then 
disassemble based on that range.


-----

Custom Observer:

Meta-discussion: is the custom observer at the right level.  For 
instance, is it reasonable to be trying to implement all possible 
functionality graphically, or provide a basic edit menu and then have 
more complicated events added as custom event handling code.

Conclusion: custom observer is at the right level, with edits.  In 
particular complicated event trigers should be handled using programming 
interface.

-> default should be to capture information, but not try to log it.  For 
instance, don't write to log window, instead let user examine event 
using monitor view.
-> rename observer to "event"; its an event trigger that is being selected
-> +/- buttons in filter et.al. confused; for instance, why does the 
first action have a "+"; suggest looking at thunderbird and evolution's 
filter windows
-> 'ok' at bottom should make it clear what clicking on it does
-> action arguments should be disabled when they don't apply; for 
instance, catch stack backtrace requires no argument
-> "filter" and what it is doing misleading; should be clear that a 
filter is a customization of the event