`dir'

`dir'

[Tom Tromey]

I hope I'm not being too annoying.  I figure you'd probably rather I
report things.

I couldn't find a way to add a search directory (gdb "dir" command)
via the GUI.

Invariably what happens (either with command-line or GUI) is that I
don't remember that I need to use "dir" until I move into a stack
frame where the source isn't found.

I'd really like it if adding a directory via "dir" caused the source
window to update if appropriate.  This would make Insight much nicer
than the command line (where I currently use "up ; down" to make it do
what I want -- lose).

Note that with Insight, the up/down trick currently doesn't work.
Once it can't find the file, it seems to get confused.

Tom

Re: `dir'

[James Ingham]

Tom,
 > I hope I'm not being too annoying.  I figure you'd probably rather I
 > report things.

Yup, totally!

 > 
 > I couldn't find a way to add a search directory (gdb "dir" command)
 > via the GUI.

This one should be easy.  I didn't do it before 'cause I didn't know
there was a directory chooser in libgui.  This is one of the silly
omissions of Tk, it has a choose file and a save file, but no choose
directory dialog.  Actually, there is a choose directory in Tk8.3,
though it is plug-ugly (except on the Mac, where it uses the very nice 
Navigation Services dialogs...)  But I was poking my nose in libgui,
and noted the tantelizing tclgetdir.c file...

I will get to this at some point, since I agree it is annoying, but if 
some enterprising soul wants to try their hand first, cool!

 > 
 > Invariably what happens (either with command-line or GUI) is that I
 > don't remember that I need to use "dir" until I move into a stack
 > frame where the source isn't found.
 > 
 > I'd really like it if adding a directory via "dir" caused the source
 > window to update if appropriate.  This would make Insight much nicer
 > than the command line (where I currently use "up ; down" to make it do
 > what I want -- lose).

I am more likely to add the GUI, and have that do the right thing,
than add another hook to the CL.  Actually, it would be nice to just
have a generic pre or post processing hook in ALL the commands
executed by the gdb command interpreter, so you wouldn't have to go
add the hooks into the C code to do this sort of thing.  I guess we
could add this to the console, but it might be cleaner to put it in
the command interpreter.  I will poke around a bit, it might already
be there for all I know...

 > 
 > Note that with Insight, the up/down trick currently doesn't work.
 > Once it can't find the file, it seems to get confused.

Yes, I know about this one.  This will take some work in the
SrcTextWin code to fix, which is a bit contorted, to be polite...

Jim

-- 
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham                                              jingham@cygnus.com
Cygnus Solutions, a Red Hat Company                      

Re: `dir'

[Tom Tromey]

Jim> But I was poking my nose in libgui, and noted the tantelizing
Jim> tclgetdir.c file...

Another wonderful piece of Foundry technology lives on!  Thanks, IanT.
Note that on Unix this works by using a hacked tk_getOpenFile.  I
don't know if those hacks are in the Insight Tk.

Jim> I am more likely to add the GUI, and have that do the right
Jim> thing, than add another hook to the CL.  Actually, it would be
Jim> nice to just have a generic pre or post processing hook in ALL
Jim> the commands executed by the gdb command interpreter, so you
Jim> wouldn't have to go add the hooks into the C code to do this sort
Jim> of thing.

My feeling is that what you really want is a way to be notified by the
gdb core when interesting state changes.  The GUI would run the "dir"
command, but would rely on this same notification to update the source
window cache.

You want this because then it doesn't matter how the state changes --
only that it has changed.

Whether this is done by hooking into the command interpreter in a
generic way, or more directly into the core (e.g. in this case in
directory_command()), I don't know.

Tom

Re: `dir'

[James Ingham]

Tom,

 > Jim> But I was poking my nose in libgui, and noted the tantelizing
 > Jim> tclgetdir.c file...
 > 
 > Another wonderful piece of Foundry technology lives on!  Thanks, IanT.
 > Note that on Unix this works by using a hacked tk_getOpenFile.  I
 > don't know if those hacks are in the Insight Tk.
 > 
 > Jim> I am more likely to add the GUI, and have that do the right
 > Jim> thing, than add another hook to the CL.  Actually, it would be
 > Jim> nice to just have a generic pre or post processing hook in ALL
 > Jim> the commands executed by the gdb command interpreter, so you
 > Jim> wouldn't have to go add the hooks into the C code to do this sort
 > Jim> of thing.
 > 
 > My feeling is that what you really want is a way to be notified by the
 > gdb core when interesting state changes.  The GUI would run the "dir"
 > command, but would rely on this same notification to update the source
 > window cache.
 > 
 > You want this because then it doesn't matter how the state changes --
 > only that it has changed.
 > 
 > Whether this is done by hooking into the command interpreter in a
 > generic way, or more directly into the core (e.g. in this case in
 > directory_command()), I don't know.

Yeah, I am of two minds about this.  On the one hand, you are right,
it is better to have the hook as close to where the change happens as
possible, so that you get consistent responses to the change no matter 
how it is affected.  On the other hand, to really track the command
line, you may end up sprinkling so many hooks all over the gdb code
that it gets cumbersome & ugly.  If you had a "run this tcl proc on
each CLI command" mechanism, picking up a place where you were not
tracking the gui properly and fixing it would be really trivial, just
add another pattern to your command hook, and write the Tcl code to
respond... 

I am not altogether sure.

Jim

Re: `dir'

[Mo DeJong]

Tom, keep those bug reports flying in. "fresh eyes" on a problem are
really good.

> Tom,
>  > I hope I'm not being too annoying.  I figure you'd probably rather I
>  > report things.
> 
> Yup, totally!
> 
>  > 
>  > I couldn't find a way to add a search directory (gdb "dir" command)
>  > via the GUI.

The tk_chooseDirectory dialog is really really ugly but at least there is
a hook for it. We really need to take the nice dir selection widget from
libgui and put it into the Tcl/Tk core (replace the tk_chooseDirectory
impl with ours). It might be better to actually sit down and create a
new mega widget that works just like the Mac dir an file selection
widgets (because they are so much better than the Win or Unix ones).

Mo

> This one should be easy.  I didn't do it before 'cause I didn't know
> there was a directory chooser in libgui.  This is one of the silly
> omissions of Tk, it has a choose file and a save file, but no choose
> directory dialog.  Actually, there is a choose directory in Tk8.3,
> though it is plug-ugly (except on the Mac, where it uses the very nice 
> Navigation Services dialogs...)  But I was poking my nose in libgui,
> and noted the tantelizing tclgetdir.c file...
> 
> I will get to this at some point, since I agree it is annoying, but if 
> some enterprising soul wants to try their hand first, cool!
> 
>  > 
>  > Invariably what happens (either with command-line or GUI) is that I
>  > don't remember that I need to use "dir" until I move into a stack
>  > frame where the source isn't found.
>  > 
>  > I'd really like it if adding a directory via "dir" caused the source
>  > window to update if appropriate.  This would make Insight much nicer
>  > than the command line (where I currently use "up ; down" to make it do
>  > what I want -- lose).
> 
> I am more likely to add the GUI, and have that do the right thing,
> than add another hook to the CL.  Actually, it would be nice to just
> have a generic pre or post processing hook in ALL the commands
> executed by the gdb command interpreter, so you wouldn't have to go
> add the hooks into the C code to do this sort of thing.  I guess we
> could add this to the console, but it might be cleaner to put it in
> the command interpreter.  I will poke around a bit, it might already
> be there for all I know...
> 
>  > 
>  > Note that with Insight, the up/down trick currently doesn't work.
>  > Once it can't find the file, it seems to get confused.
> 
> Yes, I know about this one.  This will take some work in the
> SrcTextWin code to fix, which is a bit contorted, to be polite...
> 
> Jim
> 
> -- 
> ++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
> Jim Ingham                                              jingham@cygnus.com
> Cygnus Solutions, a Red Hat Company                      
> 

Re: `dir'

[Tom Tromey]

Jim> On the one hand, you are right, it is better to have the hook as
Jim> close to where the change happens as possible, so that you get
Jim> consistent responses to the change no matter how it is affected.
Jim> On the other hand, to really track the command line, you may end
Jim> up sprinkling so many hooks all over the gdb code that it gets
Jim> cumbersome & ugly.

Yeah.  This would be easier if gdb had a nicer internal factoring, but
then, so would many things.

Jim> If you had a "run this tcl proc on each CLI command" mechanism,
Jim> picking up a place where you were not tracking the gui properly
Jim> and fixing it would be really trivial

I have a vague concern about performance here, but that probably isn't
serious.

At my last job I implemented an advice package for Tcl.  Hey... I
almost forgot, I reimplemented it in libgui as well.  The idea is that
you can attach random functions to run before or after other
functions.

This is really handy for debugging.  For other things it doesn't work
as well, because your advisee has to track the usage of the advisor --
and this relationship isn't explicit.  You just wind up with a runtime
error if the changes are out of sync.

For the "directory" command the problem doesn't occur -- no matter how
"directory" was invoked, you just re-examine the source cache.  But
for other commands, the behavior depends on the arguments, and you
have to be smart about examining them from Tcl.  To me this sounds
like a big maintenance problem -- and my experience using advice in my
previous job shows that it is.  In the end we decided that we would
*only* use advice to debug, and instead added explicit, documented
hooks (whose calling conventions were documented too) whenever state
notification was needed.

Tom