New debugger for D!!!

[Sarath Kodali]

I'm planning to release a new debugger for D sometime during end
of February. This is a heads up for all those who are eagerly
looking for a good debugger for D.

Here is a sample debug session:

$ ./dbg ./dbg
New session s1 (./dbg) started
New process p1 (program dbg) created
p1.1 SUSPENDED [D main in dbg.d]
78: main(string[] args)
dbg> list 175
Source listing for thread p1.1, program dbg
175: if (srcpath !is null)
176: dv_dbgSrcpath(srcpath);
177: if (sympath !is null)
178: dv_dbgSympath(sympath);
179: auto cmd = new Command(uiType);
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
181: if (dbgrc is null)
182: {
183: dbgrc = homedir ~ "/" ~ DBGRC_FILE;
184: cmd.rc_exec(dbgrc); // home dir dbgrc
dbg> run -u 179
p1.1 SUSPENDED [D main in dbg.d]
179: auto cmd = new Command(uiType);
dbg> step -o
p1.1 STEPPED [D main in dbg.d]
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
dbg> help
Run help on the following topics to get additional help.
Start & Stop:
create, grab, quit, release, %follow, %srcpath, %sympath
Execution:
halt, jump, kill, run, step, wait, %thread
Events:
events, onstop, signal, stop, syscall, %lastevent, %thisevent
View or Modify:
dump, list, maps, print, regs, set, stack, status, symbols,
vars, which
%dbg_lang, %file, %frame, %func, %lang, %line, %list_file,
%list_line,
%loc, %num_lines
Convenience:
!, alias, help, logoff, logon, script, %cwd, %logfile,
%log_prefix,
%prompt, %result, %verbose

For a full list of help topics, run "help toc".
dbg> help create
SYNOPSIS:
create [-f <follow>] [-l] [-s <srcpath>] [-S <sympath>]
[<shell_cmd_string>]
DESCRIPTION:
Create a new debugging session for <shell_cmd_string>. The
existing debug
sessions are not affected by this command. One could
simultaneously
have multiple debug sessions. If <shell_cmd_string> is not
specified, the
<shell_cmd_string> from previous create command is used and
the previous
create session is destroyed. After the session is created,
this command
runs all the processes till their 'start' function.
OPTIONS:
-f follow 'prog', 'proc', 'thread' or 'all' or 'none'
-l load only; do not run new program / thread till its
'start' function
-s paths for source files
-S paths for debug symbol files
NOTES:
It is not possible to redirect or pipe the output of create
command.
EXAMPLES:
create test_prog1 arg1 arg2 2>/tmp/prog1.err | test_prog2
# creates a new debug session for test_prog1 and
test_prog2
create MANPAGER=more man 1p man
create xterm -e ./cmd
SEE ALSO:
events, quit, kill, release, run, shell_cmd_string, status,
step
%dbg_follow, %dbg_srcpath, %dbg_sympath, %follow, %srcpath,
%sympath
dbg>

[John Colvin]

Post by Sarath Kodali
I'm planning to release a new debugger for D sometime during
end of February. This is a heads up for all those who are
eagerly looking for a good debugger for D.
$ ./dbg ./dbg
New session s1 (./dbg) started
New process p1 (program dbg) created
p1.1 SUSPENDED [D main in dbg.d]
78: main(string[] args)
dbg> list 175
Source listing for thread p1.1, program dbg
175: if (srcpath !is null)
176: dv_dbgSrcpath(srcpath);
177: if (sympath !is null)
178: dv_dbgSympath(sympath);
179: auto cmd = new Command(uiType);
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
181: if (dbgrc is null)
182: {
183: dbgrc = homedir ~ "/" ~ DBGRC_FILE;
184: cmd.rc_exec(dbgrc); // home dir dbgrc
dbg> run -u 179
p1.1 SUSPENDED [D main in dbg.d]
179: auto cmd = new Command(uiType);
dbg> step -o
p1.1 STEPPED [D main in dbg.d]
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
dbg> help
Run help on the following topics to get additional help.
create, grab, quit, release, %follow, %srcpath, %sympath
halt, jump, kill, run, step, wait, %thread
events, onstop, signal, stop, syscall, %lastevent,
%thisevent
dump, list, maps, print, regs, set, stack, status, symbols,
vars, which
%dbg_lang, %file, %frame, %func, %lang, %line, %list_file,
%list_line,
%loc, %num_lines
!, alias, help, logoff, logon, script, %cwd, %logfile,
%log_prefix,
%prompt, %result, %verbose
For a full list of help topics, run "help toc".
dbg> help create
create [-f <follow>] [-l] [-s <srcpath>] [-S <sympath>]
[<shell_cmd_string>]
Create a new debugging session for <shell_cmd_string>. The
existing debug
sessions are not affected by this command. One could
simultaneously
have multiple debug sessions. If <shell_cmd_string> is not
specified, the
<shell_cmd_string> from previous create command is used and
the previous
create session is destroyed. After the session is created,
this command
runs all the processes till their 'start' function.
-f follow 'prog', 'proc', 'thread' or 'all' or 'none'
-l load only; do not run new program / thread till its
'start' function
-s paths for source files
-S paths for debug symbol files
It is not possible to redirect or pipe the output of create
command.
create test_prog1 arg1 arg2 2>/tmp/prog1.err | test_prog2
# creates a new debug session for test_prog1 and
test_prog2
create MANPAGER=more man 1p man
create xterm -e ./cmd
events, quit, kill, release, run, shell_cmd_string, status,
step
%dbg_follow, %dbg_srcpath, %dbg_sympath, %follow, %srcpath,
%sympath
dbg>

Without the nasty line-wrapping: http://pastebin.com/1Z4T4vep

[John Colvin]

Post by John Colvin

Post by Sarath Kodali
I'm planning to release a new debugger for D sometime during
end of February. This is a heads up for all those who are
eagerly looking for a good debugger for D.
$ ./dbg ./dbg
New session s1 (./dbg) started
New process p1 (program dbg) created
p1.1 SUSPENDED [D main in dbg.d]
78: main(string[] args)
dbg> list 175
Source listing for thread p1.1, program dbg
175: if (srcpath !is null)
176: dv_dbgSrcpath(srcpath);
177: if (sympath !is null)
178: dv_dbgSympath(sympath);
179: auto cmd = new Command(uiType);
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
181: if (dbgrc is null)
182: {
183: dbgrc = homedir ~ "/" ~ DBGRC_FILE;
184: cmd.rc_exec(dbgrc); // home dir dbgrc
dbg> run -u 179
p1.1 SUSPENDED [D main in dbg.d]
179: auto cmd = new Command(uiType);
dbg> step -o
p1.1 STEPPED [D main in dbg.d]
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);
dbg> help
Run help on the following topics to get additional help.
create, grab, quit, release, %follow, %srcpath, %sympath
halt, jump, kill, run, step, wait, %thread
events, onstop, signal, stop, syscall, %lastevent,
%thisevent
dump, list, maps, print, regs, set, stack, status, symbols,
vars, which
%dbg_lang, %file, %frame, %func, %lang, %line, %list_file,
%list_line,
%loc, %num_lines
!, alias, help, logoff, logon, script, %cwd, %logfile,
%log_prefix,
%prompt, %result, %verbose
For a full list of help topics, run "help toc".
dbg> help create
create [-f <follow>] [-l] [-s <srcpath>] [-S <sympath>]
[<shell_cmd_string>]
Create a new debugging session for <shell_cmd_string>. The
existing debug
sessions are not affected by this command. One could
simultaneously
have multiple debug sessions. If <shell_cmd_string> is not
specified, the
<shell_cmd_string> from previous create command is used and
the previous
create session is destroyed. After the session is created,
this command
runs all the processes till their 'start' function.
-f follow 'prog', 'proc', 'thread' or 'all' or 'none'
-l load only; do not run new program / thread till its
'start' function
-s paths for source files
-S paths for debug symbol files
It is not possible to redirect or pipe the output of create
command.
create test_prog1 arg1 arg2 2>/tmp/prog1.err | test_prog2
# creates a new debug session for test_prog1 and
test_prog2
create MANPAGER=more man 1p man
create xterm -e ./cmd
events, quit, kill, release, run, shell_cmd_string, status,
step
%dbg_follow, %dbg_srcpath, %dbg_sympath, %follow, %srcpath,
%sympath
dbg>

Without the nasty line-wrapping: http://pastebin.com/1Z4T4vep

woops, missed a couple: http://pastebin.com/t0sejnF9

[Sarath Kodali]

Post by John Colvin

Post by John Colvin
Without the nasty line-wrapping: http://pastebin.com/1Z4T4vep

woops, missed a couple: http://pastebin.com/t0sejnF9

Thanks!

[Alexander Bothe]

Post by Sarath Kodali
I'm planning to release a new debugger for D sometime during
end of February. This is a heads up for all those who are
eagerly looking for a good debugger for D.

Which OSs are supported?
Which compilers are supported, which debug info base is used?
Is the info directly extracted from the executable aka
Dwarf/CV4/PDB support?

The sample debug session looks cool, so I'd really like to know
this to estimate whether it's worth to integrate it into Mono-D
or other IDEs :-)

[Jeremy DeHaan]

Post by Alexander Bothe

Post by Sarath Kodali
I'm planning to release a new debugger for D sometime during
end of February. This is a heads up for all those who are
eagerly looking for a good debugger for D.

Which OSs are supported?
Which compilers are supported, which debug info base is used?
Is the info directly extracted from the executable aka
Dwarf/CV4/PDB support?
The sample debug session looks cool, so I'd really like to know
this to estimate whether it's worth to integrate it into Mono-D
or other IDEs :-)

Ditto to these. I'm planning a project that will need a multi
platform debugger, and would love to learn more about this.

[Sarath Kodali]

Post by Alexander Bothe
Which OSs are supported?
Which compilers are supported, which debug info base is used?
Is the info directly extracted from the executable aka
Dwarf/CV4/PDB support?
The sample debug session looks cool, so I'd really like to know
this to estimate whether it's worth to integrate it into Mono-D
or other IDEs :-)

Next month I will be releasing an alpha version with support for
Linux, x86, Elf+Dwarf, DMD and GCC. But in the coming months I
will add support for other 64 bit OSes and compilers. I'm also
planning to add a JSON or CSV output format so that it will be
easy to parse the output when integrating with IDEs. So I would
recommend that you wait till I release 1.0 version - sometime
before Dconf 2014 - hopefully!

Thanks for the interest,
Sarath

[Andrei Alexandrescu]

Post by Alexander Bothe
Which OSs are supported?
Which compilers are supported, which debug info base is used?
Is the info directly extracted from the executable aka Dwarf/CV4/PDB
support?
The sample debug session looks cool, so I'd really like to know this
to estimate whether it's worth to integrate it into Mono-D or other
IDEs :-)

Next month I will be releasing an alpha version with support for Linux,
x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support
for other 64 bit OSes and compilers. I'm also planning to add a JSON or
CSV output format so that it will be easy to parse the output when
integrating with IDEs. So I would recommend that you wait till I release
1.0 version - sometime before Dconf 2014 - hopefully!
Thanks for the interest,
Sarath

This does sound very interesting - and don't forget to submit a talk on
the topic to DConf!!!

Andrei

[yazd]

On Tuesday, 28 January 2014 at 05:19:13 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu
This does sound very interesting - and don't forget to submit a
talk on the topic to DConf!!!
Andrei

Yes please, it would be a very interesting talk.

[Sarath Kodali]

On Tuesday, 28 January 2014 at 05:19:13 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu
This does sound very interesting - and don't forget to submit a
talk on the topic to DConf!!!
Andrei

Can't commit but will try :( too many things in my hand ...

[Andrei Alexandrescu]

Post by Sarath Kodali

Post by Andrei Alexandrescu
This does sound very interesting - and don't forget to submit a talk
on the topic to DConf!!!
Andrei

Can't commit but will try :( too many things in my hand ...

Do it.

Andrei

[dennis luehring]

Post by Sarath Kodali
I'm also
planning to add a JSON or CSV output format so that it will be
easy to parse the output when integrating with IDEs. So I would
recommend that you wait till I release 1.0 version - sometime
before Dconf 2014 - hopefully!

why don't ease the IDE integration even more - for example
the pin tool from intel (ptools.org) is a normal executable (the server)
but you can give pin a tool/commander dll per commandline which is then
responsible for controling the debugger - this way its very easy to
integrate the debugger into any environment fast and performant

examples

pin.exe -t idadbg.dll <- starts pin with an IDA-tool-dll to be able to
control pin with the ida debugger

pin.exe -t vsdbg.dll <- starts pin with an vs-studio debug helper
this way you can use pin as an debugger for VStudio

etc.

csv and json is nice - but there a much nicer ways of doing ipc

[Sarath Kodali]

On Tuesday, 28 January 2014 at 06:34:50 UTC, dennis luehring

Post by dennis luehring

Post by Sarath Kodali
I'm also
planning to add a JSON or CSV output format so that it will be
easy to parse the output when integrating with IDEs. So I would
recommend that you wait till I release 1.0 version - sometime
before Dconf 2014 - hopefully!

why don't ease the IDE integration even more - for example
the pin tool from intel (ptools.org) is a normal executable
(the server)
but you can give pin a tool/commander dll per commandline which
is then responsible for controling the debugger - this way its
very easy to integrate the debugger into any environment fast
and performant
examples
pin.exe -t idadbg.dll <- starts pin with an IDA-tool-dll to be
able to
control pin with the ida debugger
pin.exe -t vsdbg.dll <- starts pin with an vs-studio debug
helper
this way you can use pin as an debugger for VStudio
etc.
csv and json is nice - but there a much nicer ways of doing ipc

I expect this is how it will be even with dbg and IDEs. The IDE
will have a plugin that sits between the debugger and IDE. The
communication between the IDE plugin and debugger will be over a
socket and the dbg output will be in JSON format so that IDE
plugin can parse it properly. Depending on the IDE, the plugin
will be either a library (dll) or an independent executable.

[dennis luehring]

Post by Sarath Kodali
I expect this is how it will be even with dbg and IDEs. The IDE
will have a plugin that sits between the debugger and IDE. The
communication between the IDE plugin and debugger will be over a
socket and the dbg output will be in JSON format so that IDE
plugin can parse it properly. Depending on the IDE, the plugin
will be either a library (dll) or an independent executable.

its a little bit different to pin because pin is the host
of the given tool-communication dll - so the dll interface is the
interface not JSON

(pin(tool dll<--)-- any protocol --> ide/whatever

in your idea

dbg <--- socker/JASON --> ide/whatever

the question is - debuggers needs to throw masses
of information around - why put a slow JSON parser between, every single
step command gets JSONed, parsed, singlestep, result gets JSOned etc...
millions of times - why?

[dennis luehring]

Post by dennis luehring

Post by Sarath Kodali
I expect this is how it will be even with dbg and IDEs. The IDE
will have a plugin that sits between the debugger and IDE. The
communication between the IDE plugin and debugger will be over a
socket and the dbg output will be in JSON format so that IDE
plugin can parse it properly. Depending on the IDE, the plugin
will be either a library (dll) or an independent executable.

its a little bit different to pin because pin is the host
of the given tool-communication dll - so the dll interface is the
interface not JSON
(pin(tool dll<--)-- any protocol --> ide/whatever
in your idea
dbg <--- socker/JASON --> ide/whatever
the question is - debuggers needs to throw masses
of information around - why put a slow JSON parser between, every single
step command gets JSONed, parsed, singlestep, result gets JSOned etc...
millions of times - why?

i would suggest an real tool api for loaded protocol-drivers - like pin
do - and implement a control_dbg_with_tcp_and_json.dll as a driver
this way its still possible to build a super fast tracing server on top
of dbg - else JSON will become a problem - without any need because
the same target is reachable with a driver-dll(plugin)

[Sarath Kodali]

On Tuesday, 28 January 2014 at 16:24:32 UTC, dennis luehring

Post by dennis luehring

Post by Sarath Kodali
I expect this is how it will be even with dbg and IDEs. The IDE
will have a plugin that sits between the debugger and IDE. The
communication between the IDE plugin and debugger will be over a
socket and the dbg output will be in JSON format so that IDE
plugin can parse it properly. Depending on the IDE, the plugin
will be either a library (dll) or an independent executable.

its a little bit different to pin because pin is the host
of the given tool-communication dll - so the dll interface is
the interface not JSON
(pin(tool dll<--)-- any protocol --> ide/whatever
in your idea
dbg <--- socker/JASON --> ide/whatever
the question is - debuggers needs to throw masses
of information around - why put a slow JSON parser between,
every single step command gets JSONed, parsed, singlestep,
result gets JSOned etc... millions of times - why?

I'm not fixated on JSON :) I thought that is more popular
now-a-days :). Today dbg outputs in human readable format. After
the alpha release, I will add the machine readable format - what
everyone prefers.

[dennis luehring]

Post by dennis luehring
the question is - debuggers needs to throw masses
of information around - why put a slow JSON parser between,
every single step command gets JSONed, parsed, singlestep,
result gets JSOned etc... millions of times - why?

I'm not fixated on JSON:) I thought that is more popular
now-a-days:). Today dbg outputs in human readable format. After
the alpha release, I will add the machine readable format - what
everyone prefers.

clear - i would just use a plugin system for adding json or whatever
communication (like pin do) so its still api based - not (text/binary)
protocol based from the very beginning

[Jacob Carlborg]

Next month I will be releasing an alpha version with support for Linux,
x86, Elf+Dwarf, DMD and GCC.

I'm waiting for the OS X version :)

But in the coming months I will add support
for other 64 bit OSes and compilers. I'm also planning to add a JSON or
CSV output format so that it will be easy to parse the output when
integrating with IDEs.

Why not make it useable as a library that can be directly integrated
into an IDE.

[evilrat]

Post by Jacob Carlborg

Post by Sarath Kodali
Next month I will be releasing an alpha version with support
for Linux,
x86, Elf+Dwarf, DMD and GCC.

I'm waiting for the OS X version :)

not going happen until dmd gets fixed. i'm not tested GDC yet,
but others compilers don't emit variable address info for debug
or it shown as "optimized out" values. i think it may be related
to TLS because __gshared variables CAN be debugged.

[Iain Buclaw]

Post by Jacob Carlborg

Next month I will be releasing an alpha version with support for Linux,
x86, Elf+Dwarf, DMD and GCC.

I'm waiting for the OS X version :)

not going happen until dmd gets fixed. i'm not tested GDC yet, but others
compilers don't emit variable address info for debug or it shown as
"optimized out" values. i think it may be related to TLS because __gshared
variables CAN be debugged.

1) If it's "optimised out" then I suggest not running a debugger with
-O generated code.

2) What debugger are you using? I am aware that gdb does not evaluate
D programs correctly in certain situations.

[evilrat]

Post by Iain Buclaw

On Tuesday, 28 January 2014 at 10:03:03 UTC, Jacob Carlborg

Post by Jacob Carlborg

Next month I will be releasing an alpha version with support for Linux,
x86, Elf+Dwarf, DMD and GCC.

I'm waiting for the OS X version :)

not going happen until dmd gets fixed. i'm not tested GDC yet,
but others
compilers don't emit variable address info for debug or it
shown as
"optimized out" values. i think it may be related to TLS
because __gshared
variables CAN be debugged.

1) If it's "optimised out" then I suggest not running a
debugger with
-O generated code.

it is optimized out with LDC compiled program, and simply not
present with DMD.

Post by Iain Buclaw
2) What debugger are you using? I am aware that gdb does not
evaluate
D programs correctly in certain situations.

both gdb and llvm. results are same.

From Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
<ola.fosheim.grostad+dlang at gmail.com> Tue Jan 28 07:15:33 2014
From: Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
<ola.fosheim.grostad+dlang at gmail.com> (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
<ola.fosheim.grostad+dlang at gmail.com>)
Date: Tue, 28 Jan 2014 15:15:33 +0000
Subject: David Nadlinger (klickverbot) gets $150 bounty
In-Reply-To: <lc7juh$n67$***@digitalmars.com>
References: <lc7juh$n67$***@digitalmars.com>
Message-ID: <***@forum.dlang.org>

On Tuesday, 28 January 2014 at 06:49:53 UTC, Andrei Alexandrescu

Post by Iain Buclaw
Please join me in congratulating David!

*envious*

[Iain Buclaw]

Post by Iain Buclaw

Post by Jacob Carlborg

Next month I will be releasing an alpha version with support for Linux,
x86, Elf+Dwarf, DMD and GCC.

I'm waiting for the OS X version :)

not going happen until dmd gets fixed. i'm not tested GDC yet, but others
compilers don't emit variable address info for debug or it shown as
"optimized out" values. i think it may be related to TLS because
__gshared
variables CAN be debugged.

1) If it's "optimised out" then I suggest not running a debugger with
-O generated code.

it is optimized out with LDC compiled program, and simply not present with
DMD.

This sounds promising for GDC (I'm yet to come across some that is
along the lines of what you describe).

[Sarath Kodali]

Post by Jacob Carlborg

Post by Sarath Kodali
Next month I will be releasing an alpha version with support
for Linux,
x86, Elf+Dwarf, DMD and GCC.

I'm waiting for the OS X version :)

Post by Sarath Kodali
But in the coming months I will add support
for other 64 bit OSes and compilers. I'm also planning to add
a JSON or
CSV output format so that it will be easy to parse the output
when
integrating with IDEs.

Why not make it useable as a library that can be directly
integrated into an IDE.

If dbg is a library, whenever the debugger hangs or crashes, the
IDE also hangs or crashes and you may loose all your data. It is
much safer to have dbg as a server and have an IDE plugin as a
client.

[Jacob Carlborg]

If dbg is a library, whenever the debugger hangs or crashes, the IDE
also hangs or crashes and you may loose all your data. It is much safer
to have dbg as a server and have an IDE plugin as a client.

Fair enough. JSON still doesn't sound like a very effective way to
communicate with.

[Nick Sabalausky]

Post by Jacob Carlborg

If dbg is a library, whenever the debugger hangs or crashes, the IDE
also hangs or crashes and you may loose all your data. It is much safer
to have dbg as a server and have an IDE plugin as a client.

Fair enough. JSON still doesn't sound like a very effective way to
communicate with.

Yea, I'd strongly recommend using a proper binary format. Protobuf can
help with that. Text-based data is overused, overrated, and completely
pointless for direct software->software communication (as opposed to
human->software or software->human).

[Bruno Medeiros]

Post by Alexander Bothe
Which OSs are supported?
Which compilers are supported, which debug info base is used?
Is the info directly extracted from the executable aka Dwarf/CV4/PDB
support?
The sample debug session looks cool, so I'd really like to know this
to estimate whether it's worth to integrate it into Mono-D or other
IDEs :-)

Next month I will be releasing an alpha version with support for Linux,
x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support
for other 64 bit OSes and compilers. I'm also planning to add a JSON or
CSV output format so that it will be easy to parse the output when
integrating with IDEs. So I would recommend that you wait till I release
1.0 version - sometime before Dconf 2014 - hopefully!
Thanks for the interest,
Sarath

Ok, going on the contrarian view here, but if those are your supported
OSes/compiler, isn't that need fairly adequately filled by GDB at the
moment? Why start work on a whole new compiler? Particularly, the
Windows debugging scene for D is much more lacking than Linux, so I'm
failing to see why all the enthusiasm around here...

[Bruno Medeiros]

Post by Alexander Bothe
Which OSs are supported?
Which compilers are supported, which debug info base is used?
Is the info directly extracted from the executable aka Dwarf/CV4/PDB
support?
The sample debug session looks cool, so I'd really like to know this
to estimate whether it's worth to integrate it into Mono-D or other
IDEs :-)

Next month I will be releasing an alpha version with support for Linux,
x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support
for other 64 bit OSes and compilers. I'm also planning to add a JSON or
CSV output format so that it will be easy to parse the output when
integrating with IDEs. So I would recommend that you wait till I release
1.0 version - sometime before Dconf 2014 - hopefully!
Thanks for the interest,
Sarath

Ok, going on the contrarian view here, but if those are your supported
OSes/compiler, isn't that need fairly adequately filled by GDB at the
moment? Why start work on a whole new debugger? Particularly since the
Windows debugging scene for D is much more lacking than Linux, so I'm
failing to see why all the enthusiasm around here...

[Idan Arye]

Post by Sarath Kodali
p1.1 SUSPENDED [D main in dbg.d]
179: auto cmd = new Command(uiType);
dbg> step -o
p1.1 STEPPED [D main in dbg.d]
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);

Would you mind putting the line number in the same line as the
file name? I'm working on a debugger plugin for Vim, and I would
obviously want to support your debugger once it's released. I
find it easy to interpret the debugger output line by line, and
it really makes things hard when I have to join data from
multiple lines...

You said you want to add JSON and\or CSV output formats, Vim
doesn't support JSON natively and CSV is still multiple lines.
So, if it wouldn't be too hard having data in the same line can
be really be helpful!

This is also true when printing values - having the expression
and the result printed at the same line makes things easier to
interpret.


BTW, would you mind picking a different name? I understand that
"dbg" stands for "D Debugger", but there is already a debugger
named "dbg"(http://www.php-debugger.com/dbg/) and with a name so
generic I would be surprised if there aren't other debuggers with
that name...

[Craig Dillabaugh]

Post by Idan Arye
BTW, would you mind picking a different name? I understand that
"dbg" stands for "D Debugger", but there is already a debugger
named "dbg"(http://www.php-debugger.com/dbg/) and with a name
so generic I would be surprised if there aren't other debuggers
with that name...

In the event that you take Idan's advice, I just want to be the
first to come up with a lame naming suggestion.

smackD

I thought I was being very original with that one, but of course
there is already a similarly named product used for Java in
Eclipse:

http://blog.teamextension.com/smack-enhanced-debugger-1278

but not being a Java person I have no idea if that is a popular
product at all.

[Sarath Kodali]

Post by Idan Arye

Post by Sarath Kodali
p1.1 SUSPENDED [D main in dbg.d]
179: auto cmd = new Command(uiType);
dbg> step -o
p1.1 STEPPED [D main in dbg.d]
180: cmd.rc_exec(GLOBAL_DBGRC_FILE);

Would you mind putting the line number in the same line as the
file name? I'm working on a debugger plugin for Vim, and I
would obviously want to support your debugger once it's
released. I find it easy to interpret the debugger output line
by line, and it really makes things hard when I have to join
data from multiple lines...
You said you want to add JSON and\or CSV output formats, Vim
doesn't support JSON natively and CSV is still multiple lines.
So, if it wouldn't be too hard having data in the same line can
be really be helpful!
This is also true when printing values - having the expression
and the result printed at the same line makes things easier to
interpret.

The output is configurable, independent of JSON or CSV, and
this is just one form. I will make it as easy of possible for
plug-ins to parse the output.

Post by Idan Arye
BTW, would you mind picking a different name? I understand that
"dbg" stands for "D Debugger", but there is already a debugger
named "dbg"(http://www.php-debugger.com/dbg/) and with a name
so generic I would be surprised if there aren't other debuggers
with that name...

I did not do any research on name; just shortened "debug" to
"dbg" :)
I'm bad at coming up with good names, so any suggestions are
always welcome.

- Sarath

[John J]

I did not do any research on name; just shortened "debug" to "dbg" :)
I'm bad at coming up with good names, so any suggestions are always
welcome.

bugD :)

[Francesco Cattoglio]

Post by John J

Post by Sarath Kodali
I did not do any research on name; just shortened "debug" to
"dbg" :)
I'm bad at coming up with good names, so any suggestions are
always
welcome.

bugD :)

buggeD?

[John J]

Post by Francesco Cattoglio

Post by John J

I did not do any research on name; just shortened "debug" to "dbg" :)
I'm bad at coming up with good names, so any suggestions are always
welcome.

bugD :)

buggeD?

Yes, the bugD pronounced as bugged! :)

[Namespace]

Post by Sarath Kodali
I did not do any research on name; just shortened "debug" to
"dbg" :)
I'm bad at coming up with good names, so any suggestions are
always welcome.
- Sarath

D!buger

[Meta]

Post by Namespace

Post by Sarath Kodali
I did not do any research on name; just shortened "debug" to
"dbg" :)
I'm bad at coming up with good names, so any suggestions are
always welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands for D
Debug.

[Rory McGuire]

+1. Same name I thought of :)

I did not do any research on name; just shortened "debug" to "dbg" :)

I'm bad at coming up with good names, so any suggestions are always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands for D Debug.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20140129/edc731b4/attachment.html>

[Andrei Alexandrescu]

Post by Namespace

I did not do any research on name; just shortened "debug" to "dbg" :)
I'm bad at coming up with good names, so any suggestions are always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands for D Debug.

noice

[Sarath Kodali]

On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei

Post by Namespace

I did not do any research on name; just shortened "debug" to "dbg" :)
I'm bad at coming up with good names, so any suggestions are always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands for D Debug.

noice

http://www.noicedebugger.com/ already exists!

[Gary Willoughby]

On Wednesday, 29 January 2014 at 16:20:33 UTC, Sarath Kodali

Post by Sarath Kodali
On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei

On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace

Post by Namespace

Post by Sarath Kodali
I did not do any research on name; just shortened "debug"
to "dbg" :)
I'm bad at coming up with good names, so any suggestions
are always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands for
D Debug.

noice

http://www.noicedebugger.com/ already exists!

I like bugD :o)

[Andrea Fontana]

On Wednesday, 29 January 2014 at 16:33:47 UTC, Gary Willoughby

Post by Gary Willoughby
On Wednesday, 29 January 2014 at 16:20:33 UTC, Sarath Kodali

Post by Sarath Kodali
On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei

On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace

Post by Namespace

Post by Sarath Kodali
I did not do any research on name; just shortened "debug"
to "dbg" :)
I'm bad at coming up with good names, so any suggestions
are always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands for D Debug.

noice

http://www.noicedebugger.com/ already exists!

I like bugD :o)

d-bugger

[Meta]

On Wednesday, 29 January 2014 at 16:45:20 UTC, Andrea Fontana

Post by Andrea Fontana
On Wednesday, 29 January 2014 at 16:33:47 UTC, Gary Willoughby

Post by Gary Willoughby
On Wednesday, 29 January 2014 at 16:20:33 UTC, Sarath Kodali

Post by Sarath Kodali
On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei

On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace

Post by Namespace

I did not do any research on name; just shortened "debug" to "dbg" :)
I'm bad at coming up with good names, so any suggestions
are always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands
for D Debug.

noice

http://www.noicedebugger.com/ already exists!

I like bugD :o)

d-bugger

That'll give anyone from the UK a good laugh.

[Andrea Fontana]

Post by Meta
On Wednesday, 29 January 2014 at 16:45:20 UTC, Andrea Fontana

Post by Andrea Fontana
On Wednesday, 29 January 2014 at 16:33:47 UTC, Gary Willoughby

Post by Gary Willoughby
On Wednesday, 29 January 2014 at 16:20:33 UTC, Sarath Kodali

Post by Sarath Kodali
On Wednesday, 29 January 2014 at 07:06:43 UTC, Andrei

On Wednesday, 29 January 2014 at 00:07:00 UTC, Namespace

Post by Namespace

Post by Sarath Kodali
I did not do any research on name; just shortened
"debug" to "dbg" :)
I'm bad at coming up with good names, so any suggestions are always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands
for D Debug.

noice

http://www.noicedebugger.com/ already exists!

I like bugD :o)

d-bugger

That'll give anyone from the UK a good laugh.

:)

Maybe d-bugging works better

[Russel Winder]

Post by Meta
On Wednesday, 29 January 2014 at 16:45:20 UTC, Andrea Fontana

[?]

Post by Meta

Post by Andrea Fontana
d-bugger

That'll give anyone from the UK a good laugh.

Sort of.

Remember bugger is colloquially a general purpose expletive as well as
being a synonym for sodomy.

[Russel Winder]

On Wed, 2014-01-29 at 16:45 +0000, Andrea Fontana wrote:
[?]

Post by Andrea Fontana
d-bugger

You may want to belay that suggestion:

http://en.wikipedia.org/wiki/Bugger
http://www.thefreedictionary.com/bugger
http://www.oxforddictionaries.com/definition/english/bugger
http://www.urbandictionary.com/define.php?term=bugger

[Justin Whear]

On Wed, 2014-01-29 at 16:45 +0000, Andrea Fontana wrote: [?]

Post by Andrea Fontana
d-bugger

http://en.wikipedia.org/wiki/Bugger
http://www.thefreedictionary.com/bugger
http://www.oxforddictionaries.com/definition/english/bugger
http://www.urbandictionary.com/define.php?term=bugger

bugger-d
Do it for the LOLs

[Andrei Alexandrescu]

Post by Sarath Kodali

Post by Namespace

I did not do any research on name; just shortened "debug" to "dbg" :)
I'm bad at coming up with good names, so any suggestions are always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands for D Debug.

noice

http://www.noicedebugger.com/ already exists!

"noice" = "nice" in Australian, i.e. I meant I like "Dug". See also
http://bostondanceparty.deviantart.com/art/Australia-162070359

Andrei

[Meta]

Great minds think alike ;-)

Post by Rory McGuire
+1. Same name I thought of :)
On Wed, Jan 29, 2014 at 2:26 AM, Meta <jared771 at gmail.com>

Post by Meta

Post by Sarath Kodali
I did not do any research on name; just shortened "debug" to
"dbg" :)

Post by Sarath Kodali
I'm bad at coming up with good names, so any suggestions are
always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands for D
Debug.

[John J]

Post by Namespace

I did not do any research on name; just shortened "debug" to "dbg" :)
I'm bad at coming up with good names, so any suggestions are always
welcome.
- Sarath

D!buger

Too complicated, keep it simple. Maybe Dug, which stands for D Debug.

Dug sounds good!

[Idan Arye]

Post by Namespace

Post by Sarath Kodali
I did not do any research on name; just shortened "debug" to
"dbg" :)
I'm bad at coming up with good names, so any suggestions are
always welcome.
- Sarath

D!buger

"!" is not a valid character for filenames, and that can be a
problem when you want to... you know... name the executable.

It can always be named "Dbangbugger", but that's a bit
cumbersome... maybe "Dbanger"? Eh... probably not a good idea...

[Martin Nowak]

Post by Sarath Kodali
I'm planning to release a new debugger for D sometime during
end of February. This is a heads up for all those who are
eagerly looking for a good debugger for D.

Do you know ngdb (https://github.com/MartinNowak/ngdb)?
It might be helpful for your implementation.

[Sarath Kodali]

Post by Martin Nowak

Post by Sarath Kodali
I'm planning to release a new debugger for D sometime during
end of February. This is a heads up for all those who are
eagerly looking for a good debugger for D.

Do you know ngdb (https://github.com/MartinNowak/ngdb)?
It might be helpful for your implementation.

Thanks for the link, I will take a look. Is this a working
debugger?

- Sarath

[Martin Nowak]

Thanks for the link, I will take a look. Is this a working debugger?

Kind of ;), I'm not the original author, but I fixed the build and tried
to improve it a little. Although I no longer plan to work on this,
the existing code might be helpful because it's a fairly
simple/straightforward implementation.