On Tuesday, 28 January 2014 at 09:28:04 UTC, mongrel wrote:
> Well, I guess if the sock fits wear it :D
>
> I just know I'd be lost without my step-through code in larger projects with many people working on them.
>
> The current situation in D is actually adequate for us. GDB gets it wrong sometimes but never so badly that we cannot immediately see through it to the truth in the code.

Haha yea and GDB is getting better slowly.
Although I just hit a time when I needed one. Wowzers trying to debug string mixins galore and having values escape gah. Been porting dvorm to 2.065 beta 2 and adding struct support. A few surprises there!
Although I some how doubt any debugger is up for this just yet.

Now if only I had a code beautifier.. damn. Now thats a reasonable tool that could be made easily. Oh well no point being lazy.

On Monday, 27 January 2014 at 11:03:45 UTC, Russel Winder wrote:
[...]
>
> I find GtkD + Glade rather good actually. The problem is that this is
> not really a good direction for cross platform working since Gtk isn't a
> widely supported framework.
>

I'm probably still a bit new to GTK, but when I started on Qt I found it easier to pick up.

Ever since I used C++ Builder 4 and VCL I've been searching for a RAD GUI tool to match it; I haven't found one yet in C++ or Java.

Some may shudder :D but I really liked the Borland tools and APIs back then.


Cheers,
ed

On 28 January 2014 16:05, Temtaime <temtaime@gmail.com> wrote:

> Support of MSVC COFF is really needed for me.
>

Works fine...? (for x64 >_<)


> And x64 codegen without any dependencies like msvc's link.exe linker.
>

Ummm, your prior sentence just insisted for MSVC COFF... but it's a problem when that's you get that? Confused...

Personally, I'd say it's perfect how it is! (just needs x86 support)

On 2014-01-27 14:12, Manu wrote:
> On 27 January 2014 22:14, Jacob Carlborg <doob@me.com
> <mailto:doob@me.com>> wrote:
>
>     On 2014-01-27 09:11, Manu wrote:
>
>         In order:
>
>         1. A debugger (that works properly)
>         2. Go-to definition (that always works)
>         3. Auto-complete (that always works)
>
>
>     How well do these work for you in Visual Studio for C++? I'm finding
>     cases in Xcode where it doesn't always work, especially in DMD.
>
>
> The VC debugger is perfect for C/C++. I can't imagine how it would be
> improved. You can even edit your code and rebuild+relink while it's
> running to make minor runtime tweaks, and continue execution using the
> modified code.

Cool. I was mostly thinking of go-to definition and autocomplete. The debugger in Xcode has a couple of nice features as well. It support a bunch of value formatters, which are also customizable. Like if a value is an image (I assume NSImage) it will actually render the image.

> Go-to definition is not perfect, but it works 95% of the time.
> Auto-complete is very good in C/C++ but there are a few rough edges
> (possibly from complex preprocessor mess?),

Xcode has some problems with the DMD source code. It seems quite random, when go-to definition fails or resolves to the wrong symbol. But most of the time it works. I would assume it works even better for Objective-C.

> but C# is the clear benchmark for quality here.

Yeah, I remember Java in Eclipse. It's basically flawless.

> D doesn't have a preprocessor or a horrible network of text include, it
> should easily be able to match the C# experiences in general.

It does some other horrible things (from a source code analysis perspective, like template and string mixins.

> I say 'that always works' above, implying that it sometimes works...
> which is true, but it's in the realm of 30% for me, which is unreliable
> enough to be very annoying. Any time 'class' appears in D, it all goes
> south under VisualD.

I see.

-- 
/Jacob Carlborg

On 2014-01-28 04:59, Manu wrote:

> Yeah, good point. I've heard murmurings of kitting DMD frontend out as a
> lib for tooling being thrown around as long as I've been trolling here.
> It must be really hard... or really really uninteresting :)

We're just waiting for Daniel Murphy to finish the D port of the DMD frontend.

-- 
/Jacob Carlborg

On 28 January 2014 21:46, Jacob Carlborg <doob@me.com> wrote:

> On 2014-01-28 04:59, Manu wrote:
>
>  Yeah, good point. I've heard murmurings of kitting DMD frontend out as a
>> lib for tooling being thrown around as long as I've been trolling here. It must be really hard... or really really uninteresting :)
>>
>
> We're just waiting for Daniel Murphy to finish the D port of the DMD frontend.


How's that coming along? The guys basically started that at the last dconf.

Am Wed, 29 Jan 2014 01:41:55 +1100
schrieb Manu <turkeyman@gmail.com>:

> >
> > We're just waiting for Daniel Murphy to finish the D port of the DMD frontend.
> 
> 
> How's that coming along? The guys basically started that at the last dconf.
> 

I guess you didn't see this post? http://forum.dlang.org/thread/52E59C8F.9010100@yahoo.com#post-azarhavcmyzjflsktoke:40forum.dlang.org

On 29 January 2014 01:54, Johannes Pfau <nospam@example.com> wrote:

> Am Wed, 29 Jan 2014 01:41:55 +1100
> schrieb Manu <turkeyman@gmail.com>:
>
> > >
> > > We're just waiting for Daniel Murphy to finish the D port of the DMD frontend.
> >
> >
> > How's that coming along? The guys basically started that at the last dconf.
> >
>
> I guess you didn't see this post?
>
> http://forum.dlang.org/thread/52E59C8F.9010100@yahoo.com#post-azarhavcmyzjflsktoke:40forum.dlang.org
>

Indeed I missed that. Awesome! :)

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.121.1390920126.13884.digitalmars-d@puremagic.com...
> > We're just waiting for Daniel Murphy to finish the D port of the DMD frontend.
>
> How's that coming along? The guys basically started that at the last dconf.

I have successfully produced working D compilers on win32, linux32, and linux64.

The generated d code preserves comments and is split up into multiple source files.

Of the original hundred-and-something patches in https://github.com/D-Programming-Language/dmd/pull/1980 only 4 remain.

- Mangling of long/ulong (https://github.com/D-Programming-Language/dmd/pull/3158)
- Mangling of templated structs (https://github.com/D-Programming-Language/dmd/pull/3160)
- Clean up comments so the converter can do something sane with them (https://github.com/D-Programming-Language/dmd/pull/3123)
- Prevent g++ from emitting a vtable (will not be needed after the visitor refactoring)

On top of this, we need to refactor a bunch of virtual function hierarchies into visitor classes, unless we want cast.c/optimize.c/interpret.c to disappear and expression.d to become enormous (~25000 lines).

https://github.com/D-Programming-Language/dmd/pull/3164
https://github.com/D-Programming-Language/dmd/pull/3118
https://github.com/D-Programming-Language/dmd/pull/3111

Having a working compiler with no outstanding patches on all supported platforms within the next month is quite possible, but it will depend on the rate at which the pulls get reviewed and merged. 

Am Tue, 28 Jan 2014 10:28:03 +0000
schrieb "ed" <growlercab@gmail.com>:

> On Monday, 27 January 2014 at 11:03:45 UTC, Russel Winder wrote: [...]
> >
> > I find GtkD + Glade rather good actually. The problem is that
> > this is
> > not really a good direction for cross platform working since
> > Gtk isn't a
> > widely supported framework.
> >
> 
> I'm probably still a bit new to GTK, but when I started on Qt I found it easier to pick up.
> 
> Ever since I used C++ Builder 4 and VCL I've been searching for a RAD GUI tool to match it; I haven't found one yet in C++ or Java.
> 
> Some may shudder :D but I really liked the Borland tools and APIs back then.
> 
> 
> Cheers,
> ed

The Borland tools are great! That's the definition of an IDE. One program hosts the GUI builder, compiler, linker, debugger, editor with refactoring support, help system and package manager. And everything is actually integrated. A double-click on a button implements a click-handler, publishing a property of a component class and installing it as part of a package makes the property available in the GUI builder.

-- 
Marco