On Sep 2, 2013 1:26 AM, "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
>
> On Sunday, September 01, 2013 17:14:01 H. S. Teoh wrote:
> > Well, I'm not an IDE person, so I have nothing to say on that front.
> >
> > But I will say that debugging can and must be improved. Currently, about the only thing usable for dmd -g is to get a stacktrace of a program crash. Nothing else seems to be properly supported (I use gdb). Stepping through statements and setting breakpoints more-or-less works, but I can't get at most variables (keeps complains about being unable to reference 'this' or something similar), sometimes variable values are outright wrong or completely unrelated to the actual value, sometimes variables shown right on the source line being debugged don't exist in the debugger ('no such symbol'). Unable to look into nested structs without hitting odd behaviour. Doesn't understand D naming conventions (or does so poorly).
> >
> > Basically, I've given up trying to use gdb on D programs except when I need to find out where a crash is happening. Using writeln debugging is far more productive, sadly to say. I can imagine this state of affairs is quite disappointing to many potential D adopters.
>
> This more or less mirrors my sentiments. I use (g)vim pretty much
exclusively,
> so I don't really care about IDEs aside from how they help the community
at
> large (your typical IDE's editing capabilites are so much of a joke
compared
> to those of vim, that using an IDE really makes no sense for editing -
for me
> at least).
>
> However, I would definitely like improved debugger support. I almost
always end
> up using writeln debugging except when I need to track down a segfault. Of course, gdb support for _C++_ sucks in my experience. It can't understand basic stuff like operator overloading. So, I wouldn't expect much from D support either - though it would be really nice if gdb could at least understand D strings. I certainly wouldn't be opposed to someone writing a solid debugger which was D-centric, as it would really improve debugging,
but
> I'm not holding my hopes up at this point. That's a major undertaking.
>
> - Jonathan M Davis

I thought the problem with D strings was dmd, not gdb. As gdb has basic debugging capability with D (from experience with gdc).  Such as the ability to set breakpoints using pretty names, and it also recognises D arrays and prints them out in a pretty manner too.  Ie:  {1, 2, 3} and not {.length=3, .ptr=0x7ffff7ed0ff0}  (it does this by probing the type fields, if it sees a two field struct with the member names length and ptr then it works.  If it sees a ulong (see ABI page for dmd) then it will print you a ulong value.

If anyone has any suggestions for improving gdb support, just let me know as I intend to get round to improving some bits and pieces here and there someday.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, September 02, 2013 06:43:28 Iain Buclaw wrote:
> I thought the problem with D strings was dmd, not gdb. As gdb has basic debugging capability with D (from experience with gdc).  Such as the ability to set breakpoints using pretty names, and it also recognises D arrays and prints them out in a pretty manner too.  Ie:  {1, 2, 3} and not {.length=3, .ptr=0x7ffff7ed0ff0}  (it does this by probing the type fields, if it sees a two field struct with the member names length and ptr then it works.  If it sees a ulong (see ABI page for dmd) then it will print you a ulong value.
> 
> If anyone has any suggestions for improving gdb support, just let me know as I intend to get round to improving some bits and pieces here and there someday.

I don't think that I've ever seen gdb be able to print out a d string properly by itself. Ideally, if you have

string s = "hello world";

then in gdb, I should be able to do

print s

and have it print "hello world", but I don't recall that ever working. IIRC, you had to have it print s.ptr and give it the length from s.length. Maybe it handles that better than I remember, and maybe I was doing something wrong, but that's what I recall from the last time I tried to mess with it.

However, my experience with gdb and C++ is also that gdb sucks at it, as it can't even handle basic stuff like operator overloading. So, I've come to the conclusion that the only thing that gdb can handle correctly is actual C code, and that if you want to do anything else, you have to fight it. But maybe I just suck at using gdb.

- Jonathan M Davis

On Sep 2, 2013 6:52 AM, "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
>
> On Monday, September 02, 2013 06:43:28 Iain Buclaw wrote:
> > I thought the problem with D strings was dmd, not gdb. As gdb has basic debugging capability with D (from experience with gdc).  Such as the ability to set breakpoints using pretty names, and it also recognises D arrays and prints them out in a pretty manner too.  Ie:  {1, 2, 3} and
not
> > {.length=3, .ptr=0x7ffff7ed0ff0}  (it does this by probing the type
fields,
> > if it sees a two field struct with the member names length and ptr then
it
> > works.  If it sees a ulong (see ABI page for dmd) then it will print
you a
> > ulong value.
> >
> > If anyone has any suggestions for improving gdb support, just let me
know
> > as I intend to get round to improving some bits and pieces here and
there
> > someday.
>
> I don't think that I've ever seen gdb be able to print out a d string
properly
> by itself. Ideally, if you have
>
> string s = "hello world";
>
> then in gdb, I should be able to do
>
> print s
>
> and have it print "hello world", but I don't recall that ever working.
IIRC,
> you had to have it print s.ptr and give it the length from s.length.
Maybe it
> handles that better than I remember, and maybe I was doing something
wrong,
> but that's what I recall from the last time I tried to mess with it.
>
> However, my experience with gdb and C++ is also that gdb sucks at it, as
it
> can't even handle basic stuff like operator overloading. So, I've come to
the
> conclusion that the only thing that gdb can handle correctly is actual C
code,
> and that if you want to do anything else, you have to fight it. But maybe
I
> just suck at using gdb.
>
> - Jonathan M Davis

Guess it also depends on what version of gdb you use too I guess, as iirc D support I described came in at around 7.4 release.

If you are a gdc 4.8 user of course, you would have gdb 7.5 at least (as it doesn't work with earlier gdb versions).  And current development would recommend gdb 7.6

Have you given cgdb a try?  It's a curses front end to gdb, I added D syntax highlighting support a while ago for.  :)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, September 02, 2013 06:59:00 Iain Buclaw wrote:
> Guess it also depends on what version of gdb you use too I guess, as iirc D support I described came in at around 7.4 release.

I recall it being 7.2, but it's been a while since I tried D with gdb, so I don't know. And it may have improved quite a bit since the last time I tried (it's probably been well over a year now since I tried it with anything other than tracking down a segfault). Part of my problem is that I'm so used to using printf debugging now that I don't even think about using a proper debugger even when I should. I usually only end up using a debugger when I have no other choice (which is not the best of habits).

> If you are a gdc 4.8 user of course, you would have gdb 7.5 at least (as it doesn't work with earlier gdb versions).  And current development would recommend gdb 7.6
> 
> Have you given cgdb a try?  It's a curses front end to gdb, I added D syntax highlighting support a while ago for.  :)

I recall running into cgdb in the Arch repo and thinking of checking it out, but I don't recall if I did anything beyond install it. I'll have to make sure that I check it out some time soon.

- Jonathan M Davis

On 2 September 2013 07:03, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Monday, September 02, 2013 06:59:00 Iain Buclaw wrote:
>> Guess it also depends on what version of gdb you use too I guess, as iirc D support I described came in at around 7.4 release.
>
> I recall it being 7.2, but it's been a while since I tried D with gdb, so I don't know. And it may have improved quite a bit since the last time I tried (it's probably been well over a year now since I tried it with anything other than tracking down a segfault). Part of my problem is that I'm so used to using printf debugging now that I don't even think about using a proper debugger even when I should. I usually only end up using a debugger when I have no other choice (which is not the best of habits).
>

Yep, that's probably the one...  I think the main problem around that time was that dmd still emitted D arrays as longs.   So of course you won't get any useful information from gdb.  Giving 2.064 development a whirl, I see that it has now switched to emitting D arrays as structs so it strings (and other types of D arrays) should show up with no problem when debugging code generated by dmd.


>> If you are a gdc 4.8 user of course, you would have gdb 7.5 at least (as it doesn't work with earlier gdb versions).  And current development would recommend gdb 7.6
>>
>> Have you given cgdb a try?  It's a curses front end to gdb, I added D syntax highlighting support a while ago for.  :)
>
> I recall running into cgdb in the Arch repo and thinking of checking it out, but I don't recall if I did anything beyond install it. I'll have to make sure that I check it out some time soon.
>

I'd recommending checking out the latest development on github, as it includes some minor fixes to properly highlighting binary numbers, numbers with optional exponent, wysiwyg string literals r"...", hex strings x"...", and string postfixes that were added after the 0.6.7 release.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 2 September 2013 04:56, Ramon <spam@thanks.no> wrote:
> Sorry, if I sound somewhat p*ssed but that's what I just am after wasting half a day with weird catch-me with D.
>
> Following a friendly advice given to me today I compiled (DMD on
> linux) with the -gc switch (rather than simply -g) and ...
> debugging is still useless. GDB doesn't grok it.
>
> Being somewhat desperate but still good-willing (or stubborn?) I want to try GDC. After all the gnu backend is supposed to properly feed the gnu debugger, right.
>
> This must be A JOKE!
>
> I have to clone from github (which I don't like but OK ...) then
> I have to f*cking compile gcc!!!! After that I will be allowed to
> compile GDC. Great. How about compiling a whole bloody OS before
> finally having a D compiler that kind of works?
> And, of course (if the GDC wiki doesn't lie) it'll be version
> 2.062 which probably opens another can of problems ...
>

It's 2.063.  That wiki you looked at is under read-only mode and due to be closed off / moved to http://wiki.dlang.org/GDC



> But again, I'm good-willing and so I do what I really, really HATE. But for D I do it: I install a windoze VM and install the Windoze version. Following the instructions I learn, I'll have to download 2 Visual Blah related thingies. Of course I'll have to register first with Microsoft.
>
> Excuse me, but when some Gambas or FreePascal hobby guys can do *considerably better* (and accordingly have quite many loyal and happily coding followers), shouldn't it strike us boldly that something is going terribly wrong on the practical and useability side of D?!

GCC for Windows doesn't get that much love in terms of easy of distribution.  So expect the same treatment from GDC  (because, really, at the end of the day you are just building GCC with a D front-end enabled, nothing more, no special fixes).

Best route to go through for Windows would possibly be getting it in distribution with mingw packages - or even easier, cygwin's repository.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 2 September 2013 at 05:41:50 UTC, Manu wrote:
> Would you believe that you can't watch Game of Thrones in Australia unless
> you pay at least $80/month for a foxtel (cable tv) subscription? And they
> wonder why all the statistics appear to show that Australians are the worst
> media pirates on earth...

Dude, you can't watch it in most countries, even paying. And that
isn't specific to game of throne, the same apply for most program
that you watch FOR FREE.

On Monday, 2 September 2013 at 00:15:28 UTC, H. S. Teoh wrote:
> But I will say that debugging can and must be improved. Currently, about
> the only thing usable for dmd -g is to get a stacktrace of a program
> crash. Nothing else seems to be properly supported (I use gdb). Stepping
> through statements and setting breakpoints more-or-less works, but I
> can't get at most variables (keeps complains about being unable to
> reference 'this' or something similar), sometimes variable values are
> outright wrong or completely unrelated to the actual value, sometimes
> variables shown right on the source line being debugged don't exist in
> the debugger ('no such symbol'). Unable to look into nested structs
> without hitting odd behaviour. Doesn't understand D naming conventions
> (or does so poorly).
>
> Basically, I've given up trying to use gdb on D programs except when I
> need to find out where a crash is happening. Using writeln debugging is
> far more productive, sadly to say. I can imagine this state of affairs
> is quite disappointing to many potential D adopters.
>
>
> T

I *strongly* agree.

- Paolo

On 09/01/2013 08:43 PM, Andrej Mitrovic wrote:
> On 9/1/13, Manu <turkeyman@gmail.com> wrote:
>> None of the others could be bothered creating yet-another-webpage-account to log bugs
>> they encountered. I suggested they do so a few times. I was promptly ignored.
>> It's just that manually logging in to non-ajax websites is so last decade. People are
>> growing very weary of creating and managing accounts on every website they visit.
> Alternatively maybe we should allow unregistered user bug reports, but use a captcha or something to fight spam. I don't know how doable this is. Some other projects use this system (e.g. Tcl).
Migrating Bugzilla to Github issues might be a start. https://github.com/rowanj/BugzillaMigrate helps with this task. And while we're at it, lets also move the wiki to github.

On Monday, 2 September 2013 at 08:06:09 UTC, Paolo Invernizzi wrote:
>> (or does so poorly).
>>
>> Basically, I've given up trying to use gdb on D programs except when I
>> need to find out where a crash is happening. Using writeln debugging is
>> far more productive, sadly to say. I can imagine this state of affairs
>> is quite disappointing to many potential D adopters.
>>
>>
>> T
>
> I *strongly* agree.
>
> - Paolo

Yes, it sucks.