Re: prompt in console window

Re: prompt in console window

[Nicholas_Karagas]

>>
>> Hello, Insight gurus...
>>
>> I've recently come across a problem using the console window in Insight.
>> In ordinary GDB, if the number of lines printed exceeds the 'height'
>> parameter, then the debugger will issue the prompt '---Type <return> to
>> continue, or q <return> to quit---'.  However, this apparently doesn't
work
>> in the Insight console, as the call to readline (readline.c:337) from
>> prompt_for_continue (utils.c:1619) always returns 0x0, and never shows
the
>> prompt in the console window.  I imagine that this is because readline
>> expects everything to be going to and from stdout (since it doesn't
require
>> a stream as a parameter).  Is there a quick fix for this that doesn't
>> involve fiddling with readline, and therefore binutils (I think that's
>> where it lives)?  Thanks in advance.
>
>Ugh. Don't even ask. This is very nasty, and not particularly useful in
>a GUI, anyway (IMO). That's why man invented scrollbars. O:-)
>
>The trick that Insight uses to turn this off is "set height 0", which
>tells gdb that the window height is zero lines high. This can be
>overridden by setting it to some number, but I just tried it in a recent
>snapshot, and it did exactly what I thought it would: it works as
>expected, but the message "---Type <return>..." appears in the
>controlling terminal, not in the console window. (Which reminds me, why
>haven't we closed stdout???) This happens because this message is passed
>to readline to handle, and readline doesn't understand how to use the
>GUI's printing streams. In order for anything to show up in the GUI, all
>output MUST pass through fputs_unfiltered, which is hooked. This
>function is called by all of gdb's printf_unfiltered/filtered commands.
>(So if anyone happens to see a "printf" or "fprintf" or "putc" or "puts"
>or anything like them without "_unfiltered" or "_filtered" in gdb, it's
>a bug.)
>
>We could hack readline to take an input/output hook, but when we
>upgraded to the lastest version of readline, we really wanted to avoid
>any hacking. I suspect this could be done, but I've not taken a good,
>serious look at readline.
>
>Of course, the console window could be modified to do this, too. It
>probably wouldn't be too difficult, either, but it would not qualify as
>"quick". Use ConsoleWin::insert to count the number of lines inserted,
>when it hits some maximum, output the prompt, wait for the keypress,
>etc. The trick, though, is that many internal messages/errors are sent
>to the console. One must be certain that we are processing user input
>when we do this (so set some flag saying it's okay to do this in
>ConsoleWin::invoke). That part would be quick, but hooking it all up to
>the preferences dialog and all the little nitpicks (adding online
>documentation for it) can be too easily overlooked.
>
>Keith
>--
>Why chat when you can Firetalk?
>Firetalk ID: Keith (10320)
>www.firetalk.com

Hmm... perhaps I can ask an easier question.  The only reason that I wanted
to get the prompt_for_continue prompt back was that I wanted a way to stop
a gdb macro (the kind that are defined in the .gdbinit file) that had
started running, in case it was taking too long and I didn't care about the
rest of the output.  With the command-line gdb, you could type Ctrl-C at
that prompt to stop whatever was running, including a macro.  Would it be
easier (and more helpful to the rest of the world) to get Ctrl-C working in
the console window instead of the unnecessary prompt?

Nicholas Karagas
Associate Software Engineer
Cirilium Corporation
Tempe, AZ
(480) 317-1144

Re: prompt in console window

[Jim Ingham]

Nicholas,

Control-C actually means copy in the console window, as God intended :-)
However, wiring up the stop button so that it would also interrupt macros
might not be a bad idea...  Or using Control-. or escape are other good
options.  

Remember also that in most GUI applications, Control-C does not generate a
SIGINT, since the GUI wants to handle all the key sequences itself.  So to
interrupt a macro while it is running, gdb would have to be giving control
periodically back to the GUI.  Don't know whether this is true or not...

Jim 

> Hmm... perhaps I can ask an easier question.  The only reason that I wanted
> to get the prompt_for_continue prompt back was that I wanted a way to stop
> a gdb macro (the kind that are defined in the .gdbinit file) that had
> started running, in case it was taking too long and I didn't care about the
> rest of the output.  With the command-line gdb, you could type Ctrl-C at
> that prompt to stop whatever was running, including a macro.  Would it be
> easier (and more helpful to the rest of the world) to get Ctrl-C working in
> the console window instead of the unnecessary prompt?

Re: prompt in console window

[Keith Seitz]

Jim Ingham wrote:
> 
> Keith,
> 
> >
> > The trick that Insight uses to turn this off is "set height 0", which
> > tells gdb that the window height is zero lines high. This can be
> > overridden by setting it to some number, but I just tried it in a recent
> > snapshot, and it did exactly what I thought it would: it works as
> > expected, but the message "---Type <return>..." appears in the
> > controlling terminal, not in the console window. (Which reminds me, why
> > haven't we closed stdout???)
> 
> Because we still haven't gotten Tom's hack to launch the inferior in an
> XTerm into the sources.  So we leave stdout & stdin for the inferior to use.
> Using the console for this is not good, since it is a Tk text widget, and
> doesn't understand all the coolo junk you can do to terminals...
> 
> Maybe somebody who is still working on Insight can just slide this in and
> see if it breaks.

Argh! I forgot about that... See what happens when you write
non-interactive software for a while? :-)

Keith
-- 
Why chat when you can Firetalk?
Firetalk ID: Keith (10320)
www.firetalk.com

Re: prompt in console window

[Jim Ingham]

Keith,

> 
> The trick that Insight uses to turn this off is "set height 0", which
> tells gdb that the window height is zero lines high. This can be
> overridden by setting it to some number, but I just tried it in a recent
> snapshot, and it did exactly what I thought it would: it works as
> expected, but the message "---Type <return>..." appears in the
> controlling terminal, not in the console window. (Which reminds me, why
> haven't we closed stdout???)

Because we still haven't gotten Tom's hack to launch the inferior in an
XTerm into the sources.  So we leave stdout & stdin for the inferior to use.
Using the console for this is not good, since it is a Tk text widget, and
doesn't understand all the coolo junk you can do to terminals...

Maybe somebody who is still working on Insight can just slide this in and
see if it breaks.

Jim

Re: prompt in console window

[Keith Seitz]

Nicholas_Karagas@cirilium.com wrote:
> 
> Hello, Insight gurus...
> 
> I've recently come across a problem using the console window in Insight.
> In ordinary GDB, if the number of lines printed exceeds the 'height'
> parameter, then the debugger will issue the prompt '---Type <return> to
> continue, or q <return> to quit---'.  However, this apparently doesn't work
> in the Insight console, as the call to readline (readline.c:337) from
> prompt_for_continue (utils.c:1619) always returns 0x0, and never shows the
> prompt in the console window.  I imagine that this is because readline
> expects everything to be going to and from stdout (since it doesn't require
> a stream as a parameter).  Is there a quick fix for this that doesn't
> involve fiddling with readline, and therefore binutils (I think that's
> where it lives)?  Thanks in advance.

Ugh. Don't even ask. This is very nasty, and not particularly useful in
a GUI, anyway (IMO). That's why man invented scrollbars. O:-)

The trick that Insight uses to turn this off is "set height 0", which
tells gdb that the window height is zero lines high. This can be
overridden by setting it to some number, but I just tried it in a recent
snapshot, and it did exactly what I thought it would: it works as
expected, but the message "---Type <return>..." appears in the
controlling terminal, not in the console window. (Which reminds me, why
haven't we closed stdout???) This happens because this message is passed
to readline to handle, and readline doesn't understand how to use the
GUI's printing streams. In order for anything to show up in the GUI, all
output MUST pass through fputs_unfiltered, which is hooked. This
function is called by all of gdb's printf_unfiltered/filtered commands.
(So if anyone happens to see a "printf" or "fprintf" or "putc" or "puts"
or anything like them without "_unfiltered" or "_filtered" in gdb, it's
a bug.)

We could hack readline to take an input/output hook, but when we
upgraded to the lastest version of readline, we really wanted to avoid
any hacking. I suspect this could be done, but I've not taken a good,
serious look at readline.

Of course, the console window could be modified to do this, too. It
probably wouldn't be too difficult, either, but it would not qualify as
"quick". Use ConsoleWin::insert to count the number of lines inserted,
when it hits some maximum, output the prompt, wait for the keypress,
etc. The trick, though, is that many internal messages/errors are sent
to the console. One must be certain that we are processing user input
when we do this (so set some flag saying it's okay to do this in
ConsoleWin::invoke). That part would be quick, but hooking it all up to
the preferences dialog and all the little nitpicks (adding online
documentation for it) can be too easily overlooked.

Keith
-- 
Why chat when you can Firetalk?
Firetalk ID: Keith (10320)
www.firetalk.com

prompt in console window

[Nicholas_Karagas]

Hello, Insight gurus...

I've recently come across a problem using the console window in Insight.
In ordinary GDB, if the number of lines printed exceeds the 'height'
parameter, then the debugger will issue the prompt '---Type <return> to
continue, or q <return> to quit---'.  However, this apparently doesn't work
in the Insight console, as the call to readline (readline.c:337) from
prompt_for_continue (utils.c:1619) always returns 0x0, and never shows the
prompt in the console window.  I imagine that this is because readline
expects everything to be going to and from stdout (since it doesn't require
a stream as a parameter).  Is there a quick fix for this that doesn't
involve fiddling with readline, and therefore binutils (I think that's
where it lives)?  Thanks in advance.

Nicholas Karagas
Associate Software Engineer
Cirilium Corporation
Tempe, AZ
(480) 317-1144