www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - ddbg suggestion

reply bobef <valid email.kom> writes:
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.
Apr 03 2007
next sibling parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
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.

Apr 04 2007
parent reply bobef <asd asd.asd> writes:
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.


Apr 04 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
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.



Apr 04 2007
next sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
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.




Apr 04 2007
parent reply bobef <asdasd asdalfksdj85.asdasld> writes:
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.





Apr 04 2007
parent Jascha Wetzel <"[firstname]" mainia.de> writes:
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.






Apr 04 2007
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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?
Apr 04 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
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.
Apr 04 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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 :).
Apr 04 2007
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
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. :-)
Apr 20 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
 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. :-)

Apr 21 2007
parent Ary Manzana <ary esperanto.org.ar> writes:
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! :-)
Apr 23 2007