• bobef <valid email.kom> Apr 03 2007
• Jascha Wetzel <"[firstname]" mainia.de> Apr 04 2007
• bobef <asd asd.asd> Apr 04 2007
• Jascha Wetzel <"[firstname]" mainia.de> Apr 04 2007
• Jascha Wetzel <firstname mainia.de> Apr 04 2007
• bobef <asdasd asdalfksdj85.asdasld> Apr 04 2007
• Jascha Wetzel <"[firstname]" mainia.de> Apr 04 2007
• Frits van Bommel <fvbommel REMwOVExCAPSs.nl> Apr 04 2007
• Jascha Wetzel <"[firstname]" mainia.de> Apr 04 2007
• Frits van Bommel <fvbommel REMwOVExCAPSs.nl> Apr 04 2007
• Ary Manzana <ary esperanto.org.ar> Apr 20 2007
• Jascha Wetzel <"[firstname]" mainia.de> Apr 21 2007
• Ary Manzana <ary esperanto.org.ar> Apr 23 2007

The debugee's output must be distinguished from the debuggers's output by
prefix or something. Otherwise it is impossible for non-human to say which one
is which. A single character would do nicely.

you can use the "nc" command before starting the debuggee to make ddbg
open a new console for it. i think that's the best solution for that
problem. no prefix can be unique and it's a lot more readable to
separate the ouput properly.
i will still consider adding a prefix as an option if there is need for it.

bobef wrote:
 The debugee's output must be distinguished from the debuggers's output by
prefix or something. Otherwise it is impossible for non-human to say which one
is which. A single character would do nicely.

There is need. To create a font end the two things must be separated. Also the
prefix don't have to be "unique", it just have to be something that is
different from the debugger's output. Say the debugee's output is prefixed with
# or $ or whatever. I doubt that any message of the debugger starts with $ (or
something other). So when the line begins with $ just strip the $ and the rest
is debugee's output, otherwise it is debugger's.


Jascha Wetzel <[firstname] mainia.de> Wrote:

 you can use the "nc" command before starting the debuggee to make ddbg
 open a new console for it. i think that's the best solution for that
 problem. no prefix can be unique and it's a lot more readable to
 separate the ouput properly.
 i will still consider adding a prefix as an option if there is need for it.
 
 bobef wrote:
 The debugee's output must be distinguished from the debuggers's output by
prefix or something. Otherwise it is impossible for non-human to say which one
is which. A single character would do nicely.

ok, to be sure, i'll make the prefix configurable.
personally, i use a new console when using Code::Blocks as a front end.
i wonder if a that ouput could be redirected to a front end as well.

bobef wrote:
 There is need. To create a font end the two things must be separated. Also the
prefix don't have to be "unique", it just have to be something that is
different from the debugger's output. Say the debugee's output is prefixed with
# or $ or whatever. I doubt that any message of the debugger starts with $ (or
something other). So when the line begins with $ just strip the $ and the rest
is debugee's output, otherwise it is debugger's.
 
 
 Jascha Wetzel <[firstname] mainia.de> Wrote:
 
 you can use the "nc" command before starting the debuggee to make ddbg
 open a new console for it. i think that's the best solution for that
 problem. no prefix can be unique and it's a lot more readable to
 separate the ouput properly.
 i will still consider adding a prefix as an option if there is need for it.

 bobef wrote:
 The debugee's output must be distinguished from the debuggers's output by
prefix or something. Otherwise it is impossible for non-human to say which one
is which. A single character would do nicely.

hm, i guess i misunderstood you.
prefixing the debuggee's output requires intercepting it's output, which is not
a good idea.
prefixing the debugger's output isn't unambiguous, since the debuggee can
always use the same prefix.
therefore, the best solution is to separate the two output streams by using
different consoles, as implemented by the "nc" command. i'd recommend that you
consider using this solution.
as i said, i can add a configurable prefix for the debugger's output, but
that's pretty hacky, imho.

Jascha Wetzel <[firstname] mainia.de> Wrote:

 ok, to be sure, i'll make the prefix configurable.
 personally, i use a new console when using Code::Blocks as a front end.
 i wonder if a that ouput could be redirected to a front end as well.
 
 bobef wrote:
 There is need. To create a font end the two things must be separated. Also the
prefix don't have to be "unique", it just have to be something that is
different from the debugger's output. Say the debugee's output is prefixed with
# or $ or whatever. I doubt that any message of the debugger starts with $ (or
something other). So when the line begins with $ just strip the $ and the rest
is debugee's output, otherwise it is debugger's.
 
 
 Jascha Wetzel <[firstname] mainia.de> Wrote:
 
 you can use the "nc" command before starting the debuggee to make ddbg
 open a new console for it. i think that's the best solution for that
 problem. no prefix can be unique and it's a lot more readable to
 separate the ouput properly.
 i will still consider adding a prefix as an option if there is need for it.

 bobef wrote:
 The debugee's output must be distinguished from the debuggers's output by
prefix or something. Otherwise it is impossible for non-human to say which one
is which. A single character would do nicely.

I see. Then how to get the both outputs to the front end and let it know which
one is which?



Jascha Wetzel Wrote:

 hm, i guess i misunderstood you.
 prefixing the debuggee's output requires intercepting it's output, which is
not a good idea.
 prefixing the debugger's output isn't unambiguous, since the debuggee can
always use the same prefix.
 therefore, the best solution is to separate the two output streams by using
different consoles, as implemented by the "nc" command. i'd recommend that you
consider using this solution.
 as i said, i can add a configurable prefix for the debugger's output, but
that's pretty hacky, imho.
 
 Jascha Wetzel <[firstname] mainia.de> Wrote:
 
 ok, to be sure, i'll make the prefix configurable.
 personally, i use a new console when using Code::Blocks as a front end.
 i wonder if a that ouput could be redirected to a front end as well.
 
 bobef wrote:
 There is need. To create a font end the two things must be separated. Also the
prefix don't have to be "unique", it just have to be something that is
different from the debugger's output. Say the debugee's output is prefixed with
# or $ or whatever. I doubt that any message of the debugger starts with $ (or
something other). So when the line begins with $ just strip the $ and the rest
is debugee's output, otherwise it is debugger's.
 
 
 Jascha Wetzel <[firstname] mainia.de> Wrote:
 
 you can use the "nc" command before starting the debuggee to make ddbg
 open a new console for it. i think that's the best solution for that
 problem. no prefix can be unique and it's a lot more readable to
 separate the ouput properly.
 i will still consider adding a prefix as an option if there is need for it.

 bobef wrote:
 The debugee's output must be distinguished from the debuggers's output by
prefix or something. Otherwise it is impossible for non-human to say which one
is which. A single character would do nicely.

one could use named pipes or simply control the debugger through an API
instead of a CLI.
i've just looked at the GDB/MI specs, they also require the debugger to
prefix the debuggee's output. GDB/MI appears to not distinguish stdout
and stderr output, though.

personally i feel that using a separate pair of IO streams (or an API)
for controlling the debugger would be nicer. but since i will implement
GDB/MI for compatibility reasons anyway, the effort of implementing an
alternative approach won't be worthwhile.


bobef wrote:
 I see. Then how to get the both outputs to the front end and let it know which
one is which?
 
 
 
 Jascha Wetzel Wrote:
 
 hm, i guess i misunderstood you.
 prefixing the debuggee's output requires intercepting it's output, which is
not a good idea.
 prefixing the debugger's output isn't unambiguous, since the debuggee can
always use the same prefix.
 therefore, the best solution is to separate the two output streams by using
different consoles, as implemented by the "nc" command. i'd recommend that you
consider using this solution.
 as i said, i can add a configurable prefix for the debugger's output, but
that's pretty hacky, imho.

 Jascha Wetzel <[firstname] mainia.de> Wrote:

 ok, to be sure, i'll make the prefix configurable.
 personally, i use a new console when using Code::Blocks as a front end.
 i wonder if a that ouput could be redirected to a front end as well.

 bobef wrote:
 There is need. To create a font end the two things must be separated. Also the
prefix don't have to be "unique", it just have to be something that is
different from the debugger's output. Say the debugee's output is prefixed with
# or $ or whatever. I doubt that any message of the debugger starts with $ (or
something other). So when the line begins with $ just strip the $ and the rest
is debugee's output, otherwise it is debugger's.


 Jascha Wetzel <[firstname] mainia.de> Wrote:

 you can use the "nc" command before starting the debuggee to make ddbg
 open a new console for it. i think that's the best solution for that
 problem. no prefix can be unique and it's a lot more readable to
 separate the ouput properly.
 i will still consider adding a prefix as an option if there is need for it.

 bobef wrote:
 The debugee's output must be distinguished from the debuggers's output by
prefix or something. Otherwise it is impossible for non-human to say which one
is which. A single character would do nicely.

Jascha Wetzel wrote:
 ok, to be sure, i'll make the prefix configurable.
 personally, i use a new console when using Code::Blocks as a front end.
 i wonder if a that ouput could be redirected to a front end as well.
 
 bobef wrote:
 There is need. To create a font end the two things must be separated. Also the
prefix don't have to be "unique", it just have to be something that is
different from the debugger's output. Say the debugee's output is prefixed with
# or $ or whatever. I doubt that any message of the debugger starts with $ (or
something other). So when the line begins with $ just strip the $ and the rest
is debugee's output, otherwise it is debugger's.


 Jascha Wetzel <[firstname] mainia.de> Wrote:

 you can use the "nc" command before starting the debuggee to make ddbg
 open a new console for it. i think that's the best solution for that
 problem. no prefix can be unique and it's a lot more readable to
 separate the ouput properly.
 i will still consider adding a prefix as an option if there is need for it.

 bobef wrote:
 The debugee's output must be distinguished from the debuggers's output by
prefix or something. Otherwise it is impossible for non-human to say which one
is which. A single character would do nicely.








Note that in your earlier message you seemed to think he wanted a prefix 
on the output of the debugger, but he meant the _debuggee_. Just in case 
you missed that.
This shouldn't be a problem, since presumably you (as the author of the 
debugger) have control over what messages the debugger itself generates 
and can ensure it never starts with the chosen prefix?

Frits van Bommel wrote:
 Note that in your earlier message you seemed to think he wanted a prefix
 on the output of the debugger, but he meant the _debuggee_. Just in case
 you missed that.
 This shouldn't be a problem, since presumably you (as the author of the
 debugger) have control over what messages the debugger itself generates
 and can ensure it never starts with the chosen prefix?


yep, took me some time to realize that ;)
see my other post for the problem with this.

Jascha Wetzel wrote:
 Frits van Bommel wrote:
 Note that in your earlier message you seemed to think he wanted a prefix
 on the output of the debugger, but he meant the _debuggee_. Just in case
 you missed that.
 This shouldn't be a problem, since presumably you (as the author of the
 debugger) have control over what messages the debugger itself generates
 and can ensure it never starts with the chosen prefix?


 yep, took me some time to realize that ;)
 see my other post for the problem with this.


Yeah, you beat me to posting that by a couple of minutes :).

bobef escribió:
 The debugee's output must be distinguished from the debuggers's output by
prefix or something. Otherwise it is impossible for non-human to say which one
is which. A single character would do nicely.


Another suggestions: a) allow the debugger to run in "for non-human" 
mode (with a flag), and b) to be able to specify two local ports on the 
machine, one to send requests, the other to recieve answers. This way:

a) The UI (or any program) can communicate with the debugger in a more 
"computer", efficient way. For example for a human the stack frame 
currently is shown like this:

#0  main.bla1 () at main.d:9
#1 0x004027a4 in _main () from dmain2
#2 0x0040ab05 in _mainCRTStartup () from constart
#3 0x7c816fd7 in ?? () from KERNEL32.dll

This is "hard" to parse (could be simpler). The #0 dosen't have an 
address, the last three don't have a line number or filename, etc.

In the "non-human" mode they could be shown like this:

// number, address, function, filename, line number (other parameters?)
0, , main.bla1, main.d, 9
1, 0x004027a4, _main, dmain2
2, 0x0040ab05, _mainCRTStartup,
3, 0x7c816fd7, ??,

(I currently don't use the other parameters, all of these would have to 
be defined properly, but you get the point)

Another example: when a breakpoint is set, you get the answer 
"Breakpoint set: main.d:9 0x402038"; when a breakpoint is hit, you get 
"Breakpoint 0 hit at main.d:9 0x402038". Again, they could be simpler to 
understand.

Yet another improvement: in the case of a breakpoint hit you just get:

Breakpoint 0 hit at main.d:9 0x402038
void bla1(int x) {

In the case of requesting the stack frame, the last line is "->". There 
is no "standard" way the debugger is saying "here ends my answer". Each 
kind of answer line should start with a different symbol or letter, and 
another symbol should be used for "answer end".

b) The debuggers output is *just* the program's output (it dosen't 
interfere with the commands sent to the debugger and recieved from it), 
which is very suitable for showing in a console.

The point b) is used in Eclipse for the Java debugger, as well as in 
their example "How to Write an Eclipse debugger": 
http://www.eclipse.org/articles/Article-Debugger/how-to.html

Well... just thoughts. :-)

 Another suggestions: a) allow the debugger to run in "for non-human"
 mode (with a flag), and b) to be able to specify two local ports on the
 machine, one to send requests, the other to recieve answers. This way:


i'm planning on adding GDB/MI support in one of the next releases. i'll
also add TCP sockets for interfacing then.

 In the case of requesting the stack frame, the last line is "->". There
 is no "standard" way the debugger is saying "here ends my answer". Each
 kind of answer line should start with a different symbol or letter, and
 another symbol should be used for "answer end".


the answer ends when "->" on a single line is printed. that should also
be the case for when breakpoints are hit.

Ary Manzana wrote:
 bobef escribió:
 The debugee's output must be distinguished from the debuggers's output
 by prefix or something. Otherwise it is impossible for non-human to
 say which one is which. A single character would do nicely.


 Another suggestions: a) allow the debugger to run in "for non-human"
 mode (with a flag), and b) to be able to specify two local ports on the
 machine, one to send requests, the other to recieve answers. This way:
 
 a) The UI (or any program) can communicate with the debugger in a more
 "computer", efficient way. For example for a human the stack frame
 currently is shown like this:
 
 #0  main.bla1 () at main.d:9
 #1 0x004027a4 in _main () from dmain2
 #2 0x0040ab05 in _mainCRTStartup () from constart
 #3 0x7c816fd7 in ?? () from KERNEL32.dll
 
 This is "hard" to parse (could be simpler). The #0 dosen't have an
 address, the last three don't have a line number or filename, etc.
 
 In the "non-human" mode they could be shown like this:
 
 // number, address, function, filename, line number (other parameters?)
 0, , main.bla1, main.d, 9
 1, 0x004027a4, _main, dmain2
 2, 0x0040ab05, _mainCRTStartup,
 3, 0x7c816fd7, ??,
 
 (I currently don't use the other parameters, all of these would have to
 be defined properly, but you get the point)
 
 Another example: when a breakpoint is set, you get the answer
 "Breakpoint set: main.d:9 0x402038"; when a breakpoint is hit, you get
 "Breakpoint 0 hit at main.d:9 0x402038". Again, they could be simpler to
 understand.
 
 Yet another improvement: in the case of a breakpoint hit you just get:
 
 Breakpoint 0 hit at main.d:9 0x402038
 void bla1(int x) {
 
 In the case of requesting the stack frame, the last line is "->". There
 is no "standard" way the debugger is saying "here ends my answer". Each
 kind of answer line should start with a different symbol or letter, and
 another symbol should be used for "answer end".
 
 b) The debuggers output is *just* the program's output (it dosen't
 interfere with the commands sent to the debugger and recieved from it),
 which is very suitable for showing in a console.
 
 The point b) is used in Eclipse for the Java debugger, as well as in
 their example "How to Write an Eclipse debugger":
 http://www.eclipse.org/articles/Article-Debugger/how-to.html
 
 Well... just thoughts. :-)

Jascha Wetzel escribió:
 Another suggestions: a) allow the debugger to run in "for non-human"
 mode (with a flag), and b) to be able to specify two local ports on the
 machine, one to send requests, the other to recieve answers. This way:


 i'm planning on adding GDB/MI support in one of the next releases. i'll
 also add TCP sockets for interfacing then.


Great!! Then I'll stop working on the debugger interface for Descent and 
wait for that, since there is no point in killing myself parsing things 
that will change in a few releases.

Really appreciated! :-)