On Monday, 2 September 2013 at 12:14:30 UTC, Dicebot wrote:
> On Sunday, 1 September 2013 at 21:27:56 UTC, Adam D. Ruppe wrote:
>> On Sunday, 1 September 2013 at 20:47:56 UTC, Ludovit Lucenic wrote:
>>> Somehow neither Adam D. Ruppe's web stuff nor vibe.d server were not able to target my intention to have latest D2 compiler support (Dec 2012/Jan 2013)
>>
>> Do you remember exactly what it was? I often skip every other dmd release so if it was blah is deprecated that's probably what it was.
>
> Same question applies to vibe.d - I have been working on it quite intensively somewhere around Jan/Feb 2013 and am extremely surprised to hear any issues of that kind have existed. Most frustrating type of a problem is the one that never gets reported upstream.

The words I chose were rather confusing. I am sorry for that. I meant that vibe.d offered me something I could not really use because I was looking for something else. I wanted a standalone server that would offer some kind of 'servlet' configuration and I wanted to generate the output page on my very own. I found that vibe.d offers some kind of "template processing" engine and that really has not fit my need.
Thank you for your comment and once again, sorry for that confusion.

Ludovit

On Monday, 2 September 2013 at 07:52:09 UTC, Ludovit Lucenic wrote:
> You don't mean it, do you ? :-D

I don't use a debugger too often, I actually prefer to do asserts (and then, when possible, leave them there after the debugging is finished) and printf stuff.

But when I do use gdb, I don't have big problems with it. For me at least, the stack trace works with file and line numbers, disassembly and register dumping works, breakpoints work, getting variable contents usually (but not always) works.

So I just generally find it good enough.

> I wish we could say the same for them running on Windows...

Aye.

On Monday, 2 September 2013 at 12:29:29 UTC, Jacob Carlborg wrote:
> On 2013-09-01 22:47, Ludovit Lucenic wrote:
>
>>  1) only D1 version of majority of D code I could use, phobos vs. tango
>> incompatibility, ... (valid for January 2013)
>
> Tango for D2 is available here
>
> https://github.com/SiegeLord/Tango-D2
>
> It can be used side-by-side with Phobos without any problems. I use it like that.

Jacob,

finally I did find this version of Tango. I have described here the whole process and it was not easy and straightforward for me at that time to figure out that Tango-D2 is the way to go. I pointed out all the obstacles, from the beginning on. Actually, the Tango-D2 library was the most problem-free part for my project so far, although not without any problems :-) But these were more or less language specific, so that I needed to adapt some code based on the changed DMD compiler in the meanwhile or so.

Kind regards,
Ludovit

On 2013-09-02 09:48, Ludovit Lucenic wrote:

> However, I don't think I can move things much forward on Windows
> unless we have ready to use GDC/LDC executables (that one can
> download and install easily on Win platform) which would by-pass
> the DMD/GDB/Win problem then. Moreover, I don't like to code in
> C#, when there's D around :-) but for the beginning...

Have a look at this:

http://forum.dlang.org/thread/mailman.990.1370788529.13711.digitalmars-d-ldc@puremagic.com

That post contains links to LDC binaries.

-- 
/Jacob Carlborg

On Monday, 2 September 2013 at 13:30:38 UTC, Ludovit Lucenic wrote:
>> Same question applies to vibe.d - I have been working on it quite intensively somewhere around Jan/Feb 2013 and am extremely surprised to hear any issues of that kind have existed. Most frustrating type of a problem is the one that never gets reported upstream.
>
> The words I chose were rather confusing. I am sorry for that. I meant that vibe.d offered me something I could not really use because I was looking for something else. I wanted a standalone server that would offer some kind of 'servlet' configuration and I wanted to generate the output page on my very own. I found that vibe.d offers some kind of "template processing" engine and that really has not fit my need.
> Thank you for your comment and once again, sorry for that confusion.

Oh, for a moment I thought you had issues with vibe.d not supporting latest dmd version.

Anyway, if you have contacted devs you may have been pleasantly surprised :) For example, template processing engine your are speaking about (Diet) is an additional feature and not required at all. You can have request handlers that generate HTTP bodies manually and even have request handlers that render raw TCP.

And even if something wasn't supported, asking about it have had a good chance to make it implemented pretty fast :)

You're welcome.

On Monday, 2 September 2013 at 13:30:07 UTC, Adam D. Ruppe wrote:
> On Monday, 2 September 2013 at 07:22:31 UTC, Ludovit Lucenic wrote:
>> But the feeling I recall (which still persists) is that your code did not what I needed/wished to have, not that it would do things wrong that it did.
>
> Yeah, I often write just what I need and then leave it at that.
>
> But if you ever have feature requests, I might be able to add it if I'm not too busy with other stuff/it isn't too hard for me to slap together.

Thank you very much for your willingness. I appreciate that a lot.
I reconsider using some of your code later when I fix my debugging problems.
The mango library (at least the necessary part of it) I ported to D2 might have become corrupted by me doing the remedy engineer with little-to-no D experience :-) I don't trust this ported mango code that much... So, there's a big probability I let you know someday.

Ludovit

On Monday, 2 September 2013 at 12:00:43 UTC, Paolo Invernizzi wrote:
> ability to set a break (usually that's work, at least in OSX), AND being able to inspect locals.

Here's what happens with me:

dmd test30.d -debug -gc
gdb test30
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
[...]
This GDB was configured as "x86_64-slackware-linux".
[...]
(gdb) break test30.d:13
Breakpoint 1 at 0x8070846: file test30.d, line 13.
(gdb) r
Starting program: /home/me/test30
[Thread debugging using libthread_db enabled]

Breakpoint 1, _Dmain () at test30.d:13
13              assert(0, s);
(gdb) print s
$1 = {length = 7, ptr = 0xf7cf7fe0 "test 10\b"}
(gdb) c
Continuing.
core.exception.AssertError@test30.d(13): test 10
[...]
Program exited with code 01.



So you can see there that the breakpoint worked and the local variable check while not perfect (I hear the newer gdb works better, but I haven't updated mine since 2010), is good enough to get an idea of what is going on.


Setting breakpoints by function name is harder because you need to know the mangled version (again maybe this works better in future gdbs but not on mine). For extern(C) that's easy, it is just the name:

(gdb) break gc_malloc
Breakpoint 1 at 0x8079058

gc_malloc is extern(C) so it knows the name.


For a D function, or worse yet, a template, getting the mangled name is a pain. I've never actually bothered with this before, I just prefer to use the file and line number.

But if you wanted to, you could pragma(msg, funcname.mangleof) to get it from the compiler, then:

(gdb) break _D6test3015__T8myformatTiZ8myformatFNaNbNexAyaxiZAya
Breakpoint 1 at 0x8070870: file test30.d, line 4.
(gdb) r
Starting program: /home/me/test30
[Thread debugging using libthread_db enabled]

Breakpoint 1, _D6test3015__T8myformatTiZ8myformatFNaNbNexAyaxiZAya (
    _param_1=10, fmt=...) at test30.d:4
4                       return format(fmt, t);



So that works, it is just extremely awkward compared to the file+line number.







Another thing I do is compile every D file at once. dmd -gc -debug a.d everything.d here.d so.d on.d etc.d


Maybe that helps me too.

> I think we are not alone searching for such informations, so can you point me somewhere in the wiki, in the documentation, or similar, when there's a clear information about what version of gdb to use, what it is available as functionality and what not, and what compiler flags to use?

I don't really know except what works for me.

But Iain in another thread said gdb 4.6 or 4.7 works best though.

On Monday, 2 September 2013 at 13:33:29 UTC, Adam D. Ruppe wrote:
> On Monday, 2 September 2013 at 07:52:09 UTC, Ludovit Lucenic wrote:
>> You don't mean it, do you ? :-D
>
> I don't use a debugger too often, I actually prefer to do asserts (and then, when possible, leave them there after the debugging is finished) and printf stuff.
>
> But when I do use gdb, I don't have big problems with it. For me at least, the stack trace works with file and line numbers, disassembly and register dumping works, breakpoints work, getting variable contents usually (but not always) works.
>
> So I just generally find it good enough.
>
>> I wish we could say the same for them running on Windows...
>
> Aye.

Adam, I totally agree with you except for the point on "getting variable contents usually (but not always) works". In my case this point barely worked. Maybe I did something wrong or used older version of GDB (which I don't think was the case). Anyway, to comfortably browse the variables'/parameters'/globals' in memory while debugging I had to start working on something like Gdb.D for Mono-D (mentioned earlier). GDB alone was not giving me even the least help in this memory examination. I mean, write a code where you have classes, interfaces, you passed variables like this to functions and put a breakpoint in such a function. I always got 0x0012F64E and such values out of GDB...

Ludovit

On Monday, 2 September 2013 at 13:40:49 UTC, Dicebot wrote:
> On Monday, 2 September 2013 at 13:30:38 UTC, Ludovit Lucenic wrote:
>>> Same question applies to vibe.d - I have been working on it quite intensively somewhere around Jan/Feb 2013 and am extremely surprised to hear any issues of that kind have existed. Most frustrating type of a problem is the one that never gets reported upstream.
>>
>> The words I chose were rather confusing. I am sorry for that. I meant that vibe.d offered me something I could not really use because I was looking for something else. I wanted a standalone server that would offer some kind of 'servlet' configuration and I wanted to generate the output page on my very own. I found that vibe.d offers some kind of "template processing" engine and that really has not fit my need.
>> Thank you for your comment and once again, sorry for that confusion.
>
> Oh, for a moment I thought you had issues with vibe.d not supporting latest dmd version.
>
> Anyway, if you have contacted devs you may have been pleasantly surprised :) For example, template processing engine your are speaking about (Diet) is an additional feature and not required at all. You can have request handlers that generate HTTP bodies manually and even have request handlers that render raw TCP.
>
> And even if something wasn't supported, asking about it have had a good chance to make it implemented pretty fast :)
>
> You're welcome.

Thank you, Dicebot.

I may reconsider inspecting the vibe.d code as well :-D
Pleasant surprises I like the most. I guess I could not find the things you write about from the documentation. May be my fault, may be one of its.

But to the point. I guess we come together to the core of my posting and that is: however a newbie comes to the D to try it out, things mostly do not work out of the box. I wanted to do _my_ job and I have had hard time to figure out what tools, what already made code to use, how to reuse tango/mango, etc...
I mean, the D is worth it, therefore I hang around even after the months.
But in order to implement my intention, I am struggling all over again and again with what does not work for me in a 'find-download-install-learn-reuse' way. I would have been at least two months ahead with my project by now.

I found only today, that there is something like http://code.dlang.org ! Looks perfect, why have not I come accross this site already ? Well, that's the question.

Ludovit

On 2013-09-02 14:00, Paolo Invernizzi wrote:

> Me and my colleague are working full time for a project with DMD 2.063:
> I'm on OSX, so it's a different story, but he is on linux (Ubuntu 13.04
> 64bit).

The debugging experience is even worse on Mac OS X.

-- 
/Jacob Carlborg