ddbg suggestion

[Jascha Wetzel]

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