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! :-)