www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Which tools do you miss in D?

reply "Oten" <lol.themask gmail.com> writes:
Which tools do you miss in the D language? it can be from any
language not from C or C++ only but from any language that you
have used and liked (might not liked but increased productivity
anyway)  A very common argument from peoples which do choose
other language than D is lack of your tools for D, even if they
want to get D they say can't switch. The most common tools which
they miss is debuggers/static analyzer/lint and so on. I think
that by sharing this list with community instead of just say it
like a criticizes is good because next time that some people say
that such a x tools isn't available you can say "No, there's a D
version for that". Also, totally new ideas are very welcome. If
you  have had a idea that for any reason you wouldn't implement
yourself, tell us too.
(sorry for english, not my native language)
Jan 26 2014
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 26 January 2014 at 20:29:30 UTC, Oten wrote:

 Which tools do you miss in the D language? it can be from any
 language not from C or C++ only but from any language that you
 have used and liked (might not liked but increased productivity
 anyway)  A very common argument from peoples which do choose
 other language than D is lack of your tools for D, even if they
 want to get D they say can't switch. The most common tools which
 they miss is debuggers/static analyzer/lint and so on. I think
 that by sharing this list with community instead of just say it
 like a criticizes is good because next time that some people say
 that such a x tools isn't available you can say "No, there's a D
 version for that". Also, totally new ideas are very welcome. If
 you  have had a idea that for any reason you wouldn't implement
 yourself, tell us too.
 (sorry for english, not my native language)


Detection of unused imports and variables!
Jan 26 2014
parent "Chris" <wendlec tcd.ie> writes:
On Sunday, 26 January 2014 at 21:14:59 UTC, Namespace wrote:


 Detection of unused imports and variables!


Yes, that would be nice. They just creep in after a while. Common 
auto-completion (as in Textadept) is not perfect for things like

MyStruct!string("hello"); // It stops after MyStruct

However, given the lack of tools for D (in comparison to other 
languages) it is amazing how far you get in D with only a text 
editor and a Terminal application.
Jan 28 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 26 January 2014 at 20:29:30 UTC, Oten wrote:

 Which tools do you miss in the D language? it can be from any
 language not from C or C++ only but from any language that you
 have used and liked (might not liked but increased productivity
 anyway)  A very common argument from peoples which do choose
 other language than D is lack of your tools for D, even if they
 want to get D they say can't switch. The most common tools which
 they miss is debuggers/static analyzer/lint and so on. I think
 that by sharing this list with community instead of just say it
 like a criticizes is good because next time that some people say
 that such a x tools isn't available you can say "No, there's a D
 version for that". Also, totally new ideas are very welcome. If
 you  have had a idea that for any reason you wouldn't implement
 yourself, tell us too.
 (sorry for english, not my native language)


Code formatter
import management tool (able to detect unused imports, 
duplicated, etc . . .)
Refactoring tool (change the name of something, signature, etc . 
. .)
REPL, so I can do some quick experiments.
Jan 26 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Sunday, 26 January 2014 at 20:29:30 UTC, Oten wrote:

 Which tools do you miss in the D language? it can be from any
 language not from C or C++ only but from any language that you
 have used and liked (might not liked but increased productivity
 anyway)  A very common argument from peoples which do choose
 other language than D is lack of your tools for D, even if they
 want to get D they say can't switch. The most common tools which
 they miss is debuggers/static analyzer/lint and so on. I think
 that by sharing this list with community instead of just say it
 like a criticizes is good because next time that some people say
 that such a x tools isn't available you can say "No, there's a D
 version for that". Also, totally new ideas are very welcome. If
 you  have had a idea that for any reason you wouldn't implement
 yourself, tell us too.
 (sorry for english, not my native language)


I'm not missing any tool.
For me the lack of std.logger and std.allocator very annoying 
though. This makes each library resemble to an island.
Jan 26 2014
prev sibling next sibling parent reply "Alessandro Stamatto" <astamatto gmail.com> writes:
A D backend for iPython would be cool. But first D needs a 
"pseudo-repl" using rdmd. It might be feasible with the ØMQD just 
announced (communication to the iPython frontend is done through 
ØMQ).

On libraries I really miss the Collections library, since 
sometimes I like to participate on programming competitions and a 
direct standard containers library would be great for that. But 
Allocators are - theoretically - blocking a Collections library ; 
- ;.
Jan 26 2014
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 26 January 2014 at 22:35:20 UTC, Alessandro Stamatto 
wrote:

 On libraries I really miss the Collections library, since 
 sometimes I like to participate on programming competitions and 
 a direct standard containers library would be great for that. 
 But Allocators are - theoretically - blocking a Collections 
 library ; - ;.


There are standard collections in std.container, but indeed the 
impending allocator design has been holding back further 
development of the module.
Jan 26 2014
prev sibling next sibling parent reply "ed" <growlercab gmail.com> writes:
On Sunday, 26 January 2014 at 20:29:30 UTC, Oten wrote:

 Which tools do you miss in the D language? it can be from any
 language not from C or C++ only but from any language that you
 have used and liked (might not liked but increased productivity
 anyway)  A very common argument from peoples which do choose
 other language than D is lack of your tools for D, even if they
 want to get D they say can't switch. The most common tools which
 they miss is debuggers/static analyzer/lint and so on. I think
 that by sharing this list with community instead of just say it
 like a criticizes is good because next time that some people say
 that such a x tools isn't available you can say "No, there's a D
 version for that". Also, totally new ideas are very welcome. If
 you  have had a idea that for any reason you wouldn't implement
 yourself, tell us too.
 (sorry for english, not my native language)


A quality GUI api with a decent GUI builder, something like the 
tools that come with Qt or that Window Builder for Java.

I find GTKD bindings are great but the GTK api itself, IMO, is 
less intuitive than Qt and GTK+Glade is a lot more work compared 
to other RAD tools in C++ or Java.


Cheers,
Ed
Jan 26 2014
parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2014-01-26 at 23:30 +0000, ed wrote:
[…]

 A quality GUI api with a decent GUI builder, something like the 
 tools that come with Qt or that Window Builder for Java.
 
 I find GTKD bindings are great but the GTK api itself, IMO, is 
 less intuitive than Qt and GTK+Glade is a lot more work compared 
 to other RAD tools in C++ or Java.


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.

Qt5 on the other hand is making great strides (now that it isn't a
Nokia/Microsoft technology). Go now has QML support and I am finding
this a nice combination.

Having QML support in D would be a good thing.

I haven't had time to work on the various QtD repositories to see if Qt5
and QML are or can easily be supported. 

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 27 2014
parent reply "ed" <growlercab gmail.com> writes:
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
Jan 28 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
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
Jan 28 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 29.01.2014 00:26, schrieb Marco Leise:

 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.


Yep, that is one reason why I never liked C, having learned Turbo Pascal 
before.

Even on MS-DOS, Borland tooling was already great.

--
Paulo
Jan 30 2014
prev sibling next sibling parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
I miss check_expect from racket.

It is used for unit testing

check_expect(expression, result)
Will test if expression equals result
if it is not it print "Got expression but expected result" with file and
line information.

In D making unit tests is more tedious.
When I develop in D I typical start with.

writeln(expression)
writeln(result)

then when the code is working I replace it with
assert(expression==result)

Then if I do some refactoring which don't work I change again
writeln(expression)
writeln(result)

When it is working again
assert(expression==result)

This back and forth process in D is very tedious compared to Racket.

I think the should be a buildin function called test or something
for-filing the same role as check_expect in racket.

Knud

On 2014-01-26 21:29, Oten wrote:

 Which tools do you miss in the D language? it can be from any
 language not from C or C++ only but from any language that you
 have used and liked (might not liked but increased productivity
 anyway)  A very common argument from peoples which do choose
 other language than D is lack of your tools for D, even if they
 want to get D they say can't switch. The most common tools which
 they miss is debuggers/static analyzer/lint and so on. I think
 that by sharing this list with community instead of just say it
 like a criticizes is good because next time that some people say
 that such a x tools isn't available you can say "No, there's a D
 version for that". Also, totally new ideas are very welcome. If
 you  have had a idea that for any reason you wouldn't implement
 yourself, tell us too.
 (sorry for english, not my native language)



-- 
Join me on
Skype	   knudhs
Facebook   http://www.facebook.com/profile.php?id=1198821880
Linkedin   http://www.linkedin.com/pub/0/117/a54
Twitter    http://twitter.com/knudsoerensen
bitcoin donations: 13ofyUKqFL43uRJHZtNozyMVP4qxKPsAR2
Jan 26 2014
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Monday, 27 January 2014 at 07:16:26 UTC, Knud Soerensen wrote:

 I miss check_expect from racket.

 It is used for unit testing

 check_expect(expression, result)
 Will test if expression equals result
 if it is not it print "Got expression but expected result" with 
 file and
 line information.

 In D making unit tests is more tedious.
 When I develop in D I typical start with.

 writeln(expression)
 writeln(result)

 then when the code is working I replace it with
 assert(expression==result)

 Then if I do some refactoring which don't work I change again
 writeln(expression)
 writeln(result)

 When it is working again
 assert(expression==result)

 This back and forth process in D is very tedious compared to 
 Racket.

 I think the should be a buildin function called test or 
 something
 for-filing the same role as check_expect in racket.

 Knud

 On 2014-01-26 21:29, Oten wrote:

 Which tools do you miss in the D language? it can be from any
 language not from C or C++ only but from any language that you
 have used and liked (might not liked but increased productivity
 anyway)  A very common argument from peoples which do choose
 other language than D is lack of your tools for D, even if they
 want to get D they say can't switch. The most common tools 
 which
 they miss is debuggers/static analyzer/lint and so on. I think
 that by sharing this list with community instead of just say it
 like a criticizes is good because next time that some people 
 say
 that such a x tools isn't available you can say "No, there's a 
 D
 version for that". Also, totally new ideas are very welcome. If
 you  have had a idea that for any reason you wouldn't implement
 yourself, tell us too.
 (sorry for english, not my native language)




import std.stdio;

void check_expect(A, B)(lazy A expression, B result, string file 
= __FILE__, size_t line = __LINE__)
{
	try
	{
		if (expression != result)
		{
			throw new Exception("Got expression but expected result", 
file, line);
		}
	}
	catch (Exception ex)
	{
		writefln("%s, file: %s, line: %s", ex.msg, ex.file, ex.line);
	}
}

unittest
{
	check_expect(1 + 2, 4);
}

You can find more usesful functions for unit testing here: 
https://github.com/nomad-software/dunit
Jan 27 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/14 11:16 PM, Knud Soerensen wrote:

 I miss check_expect from racket.

 It is used for unit testing

 check_expect(expression, result)
 Will test if expression equals result
 if it is not it print "Got expression but expected result" with file and
 line information.

 In D making unit tests is more tedious.
 When I develop in D I typical start with.

 writeln(expression)
 writeln(result)

 then when the code is working I replace it with
 assert(expression==result)

 Then if I do some refactoring which don't work I change again
 writeln(expression)
 writeln(result)

 When it is working again
 assert(expression==result)

 This back and forth process in D is very tedious compared to Racket.


I do the same. There's a enhancement request in bugzilla for having 
assert detect these patterns itself.

Andrei
Jan 27 2014
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, January 27, 2014 08:01:30 Andrei Alexandrescu wrote:

 On 1/26/14 11:16 PM, Knud Soerensen wrote:

 I miss check_expect from racket.
 
 It is used for unit testing
 
 check_expect(expression, result)
 Will test if expression equals result
 if it is not it print "Got expression but expected result" with file and
 line information.
 
 In D making unit tests is more tedious.
 When I develop in D I typical start with.
 
 writeln(expression)
 writeln(result)
 
 then when the code is working I replace it with
 assert(expression==result)
 
 Then if I do some refactoring which don't work I change again
 writeln(expression)
 writeln(result)
 
 When it is working again
 assert(expression==result)
 
 This back and forth process in D is very tedious compared to Racket.


 
 I do the same. There's a enhancement request in bugzilla for having
 assert detect these patterns itself.


assertPred took care of this - e.g. assertPred!"=="(lhs, rhs, expected) or 
assertPred!"<"(lhs, rhs, expected) - but it failed the review process with the 
consensus that assert should be changed to do this for you. However, as I 
understand it, it was ultimately decided by those who looked at implementing 
it that that wasn't going to work. std.datetime still uses a stripped-down 
version of it internally as _assertPred, but I'm fairly certain that it's 
introduced too much template bloat as a result and that it's the main cause 
for the large amount of memory that std.datetime requires when compiling its 
unit tests. So, while I like the idea of a templated function which prints out 
what the expected result and actual result on a test failure rather than just 
that the test failed, at this point, I'm not at all certain that it's worth 
the overhead. And if assert can't reasonably be made to take of it itself, a 
templated function like assertPred would pretty much be the way that you'd 
have to go.

- Jonathan M Davis
Jan 31 2014
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
That can be (and is) solved by D unit testing libraries.

Atila

On Monday, 27 January 2014 at 07:16:26 UTC, Knud Soerensen wrote:

 I miss check_expect from racket.

 It is used for unit testing

 check_expect(expression, result)
 Will test if expression equals result
 if it is not it print "Got expression but expected result" with 
 file and
 line information.

 In D making unit tests is more tedious.
 When I develop in D I typical start with.

 writeln(expression)
 writeln(result)

 then when the code is working I replace it with
 assert(expression==result)

 Then if I do some refactoring which don't work I change again
 writeln(expression)
 writeln(result)

 When it is working again
 assert(expression==result)

 This back and forth process in D is very tedious compared to 
 Racket.

 I think the should be a buildin function called test or 
 something
 for-filing the same role as check_expect in racket.

 Knud

 On 2014-01-26 21:29, Oten wrote:

 Which tools do you miss in the D language? it can be from any
 language not from C or C++ only but from any language that you
 have used and liked (might not liked but increased productivity
 anyway)  A very common argument from peoples which do choose
 other language than D is lack of your tools for D, even if they
 want to get D they say can't switch. The most common tools 
 which
 they miss is debuggers/static analyzer/lint and so on. I think
 that by sharing this list with community instead of just say it
 like a criticizes is good because next time that some people 
 say
 that such a x tools isn't available you can say "No, there's a 
 D
 version for that". Also, totally new ideas are very welcome. If
 you  have had a idea that for any reason you wouldn't implement
 yourself, tell us too.
 (sorry for english, not my native language)
Jan 27 2014
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
In order:

1. A debugger (that works properly)
2. Go-to definition (that always works)
3. Auto-complete (that always works)
4. Import management (missing/duplicate/unused imports)
5. Typical suite of modern refactoring tools
Jan 27 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 27 January 2014 at 08:12:14 UTC, Manu wrote:

 In order:

 1. A debugger (that works properly)
 2. Go-to definition (that always works)
 3. Auto-complete (that always works)
 4. Import management (missing/duplicate/unused imports)
 5. Typical suite of modern refactoring tools


Holly crap, I forgot the goto definition. That is really needed.
Jan 27 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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.


 4. Import management (missing/duplicate/unused imports)
 5. Typical suite of modern refactoring tools


I agree on all the above.

-- 
/Jacob Carlborg
Jan 27 2014
parent reply Manu <turkeyman gmail.com> writes:
On 27 January 2014 22:14, Jacob Carlborg <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.
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

for quality here.

D doesn't have a preprocessor or a horrible network of text include, it


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.


 4. Import management (missing/duplicate/unused imports)

 5. Typical suite of modern refactoring tools


 I agree on all the above.

 --
 /Jacob Carlborg
Jan 27 2014
next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 27 January 2014 at 13:12:56 UTC, Manu wrote:

 D doesn't have a preprocessor or a horrible network of text 
 include, it



No, it's much, much harder because of templates and string mixins.

The only way to get a solid auto-complete experience for D is to 
use a compiler-as-library, which is why I think the approach that 
VisualD and Mono-D (and DScanner to some extent, IIRC) takes is a 
colossal waste of time, as "good enough" will in fact never be 
good enough.
Jan 27 2014
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 28 January 2014 13:43, Jakob Ovrum <jakobovrum gmail.com> wrote:


 On Monday, 27 January 2014 at 13:12:56 UTC, Manu wrote:


 D doesn't have a preprocessor or a horrible network of text include, it



 No, it's much, much harder because of templates and string mixins.

 The only way to get a solid auto-complete experience for D is to use a
 compiler-as-library, which is why I think the approach that VisualD and
 Mono-D (and DScanner to some extent, IIRC) takes is a colossal waste of
 time, as "good enough" will in fact never be good enough.


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 :)
Jan 27 2014
parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 28 2014
parent reply Manu <turkeyman gmail.com> writes:
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.
Jan 28 2014
next sibling parent reply Johannes Pfau <nospam example.com> writes:
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
Jan 28 2014
parent Manu <turkeyman gmail.com> writes:
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! :)
Jan 28 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Jan 28 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-01-28 17:41, Daniel Murphy wrote:


 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.


This looks awesome, keep up the good work.

-- 
/Jacob Carlborg
Jan 29 2014
prev sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 28 January 2014 at 03:43:11 UTC, Jakob Ovrum wrote:

 On Monday, 27 January 2014 at 13:12:56 UTC, Manu wrote:

 D doesn't have a preprocessor or a horrible network of text 
 include, it



 No, it's much, much harder because of templates and string 
 mixins.


Agreed. D is a language that almost seems like it was designed to 
maximize the difficulty of creating a complete autocomplete 
engine. As soon as you hit a line that looks like

mixin (someRandomTemplate!(a, b, c)(d, e, f));

you need a full compiler front-end to provide complete 
autocomplete.


 The only way to get a solid auto-complete experience for D is 
 to use a compiler-as-library, which is why I think the approach 
 that VisualD and Mono-D (and DScanner to some extent, IIRC) 
 takes is a colossal waste of time, as "good enough" will in 
 fact never be good enough.


If they were a waste of time nobody would use them.
Jan 27 2014
parent reply "Temtaime" <temtaime gmail.com> writes:
Support of MSVC COFF is really needed for me.
And x64 codegen without any dependencies like msvc's link.exe 
linker.
Jan 27 2014
next sibling parent Danni Coy <danni.coy gmail.com> writes:
Better tooling is one of the things that makes me write less D Code.

Basically I want Semantic Analysis, code completion, refactoring tools
as good as what I get with KDevelop on Linux and Debugging support
that is better than that.
I really like rdmd but I still get occasional bugs with it.

On Tue, Jan 28, 2014 at 4:05 PM, Temtaime <temtaime gmail.com> wrote:

 Support of MSVC COFF is really needed for me.
 And x64 codegen without any dependencies like msvc's link.exe linker.
Jan 28 2014
prev sibling parent Manu <turkeyman gmail.com> writes:
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)
Jan 28 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
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.





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


 D doesn't have a preprocessor or a horrible network of text include, it



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
Jan 28 2014
prev sibling next sibling parent "terchestor" <terchestor gmail.com> writes:
On Monday, 27 January 2014 at 08:12:14 UTC, Manu wrote:

 In order:

 1. A debugger (that works properly)
 2. Go-to definition (that always works)
 3. Auto-complete (that always works)
 4. Import management (missing/duplicate/unused imports)
 5. Typical suite of modern refactoring tools


+1 for items 1, 4 and 5.
Jan 27 2014
prev sibling parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Monday, 27 January 2014 at 08:12:14 UTC, Manu wrote:

 In order:

 1. A debugger (that works properly)
 2. Go-to definition (that always works)
 3. Auto-complete (that always works)
 4. Import management (missing/duplicate/unused imports)
 5. Typical suite of modern refactoring tools


It amazed me that your post was the first that mentioned a 
working debugger!
Jan 27 2014
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 27 January 2014 18:11, Manu <turkeyman gmail.com> wrote:


 In order:

 1. A debugger (that works properly)
 2. Go-to definition (that always works)
 3. Auto-complete (that always works)
 4. Import management (missing/duplicate/unused imports)
 5. Typical suite of modern refactoring tools


I might add, the frequency to which I pine for these things is in the order
of minutes, perhaps even 10s of seconds >_<

I made an interesting observation recently... D has kind of ruined my
career ;)
Before I started using D a lot, I found C/C++ quite okay as a language. But
after extended time using D, I find C/C++ borderline intolerable, and don't
enjoy writing it at all.
But the tooling built around C/C++ is pretty good, and as such, I find the
tooling while working in D borderline intolerable.

So, before, I generally enjoyed my work, and felt generally productive. Now
days, whenever I do any work in either language, I find one aspect or the
other borderline intolerable, and I have trouble enjoying spending my time
programming for long periods before getting frustrated and going and doing
something else...

I'm quite serious, this is a true realisation of an unconscious behaviour.
D ruined C/C++ for me, but my expectations of C/C++'s tooling still remains
a barrier to my enjoyment of writing D code all time time... I'm fucked!
Jan 27 2014
next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Monday, 27 January 2014 at 08:24:07 UTC, Manu wrote:

 On 27 January 2014 18:11, Manu <turkeyman gmail.com> wrote:


 In order:

 1. A debugger (that works properly)
 2. Go-to definition (that always works)
 3. Auto-complete (that always works)
 4. Import management (missing/duplicate/unused imports)
 5. Typical suite of modern refactoring tools


 I might add, the frequency to which I pine for these things is 
 in the order
 of minutes, perhaps even 10s of seconds >_<

 I made an interesting observation recently... D has kind of 
 ruined my
 career ;)
 Before I started using D a lot, I found C/C++ quite okay as a 
 language. But
 after extended time using D, I find C/C++ borderline 
 intolerable, and don't
 enjoy writing it at all.
 But the tooling built around C/C++ is pretty good, and as such, 
 I find the
 tooling while working in D borderline intolerable.

 So, before, I generally enjoyed my work, and felt generally 
 productive. Now
 days, whenever I do any work in either language, I find one 
 aspect or the
 other borderline intolerable, and I have trouble enjoying 
 spending my time
 programming for long periods before getting frustrated and 
 going and doing
 something else...

 I'm quite serious, this is a true realisation of an unconscious 
 behaviour.
 D ruined C/C++ for me, but my expectations of C/C++'s tooling 
 still remains
 a barrier to my enjoyment of writing D code all time time... 
 I'm fucked!


I'm personally of the opinion that if you're resorting to a 
debugger, that you really don't understand the code you're 
writing and how to debug it.

Note my first language was vb.net 7 odd years ago. And I was 

have only used one once or twice for e.g. assembly which I don't 
truly understand.

Its strange for me to see people use it so much. Because its such 
a different approach.

So for me auto completion and refactoring is most important. 
Mono-D is quite close for auto completion but it needs to get a 
lot more stable before I'll be happy.

I would also like to point out that for a long time we didn't 
really have a standard build manager. I was designing my own 
based upon Maven when dub came along.

So I'm happy with the way the ecosystem is going for this.
Jan 27 2014
next sibling parent reply "mongrel" <sillymongrel gmail.com> writes:
On Monday, 27 January 2014 at 09:29:44 UTC, Rikki Cattermole 
wrote:

 On Monday, 27 January 2014 at 08:24:07 UTC, Manu wrote:

 On 27 January 2014 18:11, Manu <turkeyman gmail.com> wrote:


 In order:

 1. A debugger (that works properly)
 2. Go-to definition (that always works)
 3. Auto-complete (that always works)
 4. Import management (missing/duplicate/unused imports)
 5. Typical suite of modern refactoring tools


 I might add, the frequency to which I pine for these things is 
 in the order
 of minutes, perhaps even 10s of seconds >_<

 I made an interesting observation recently... D has kind of 
 ruined my
 career ;)
 Before I started using D a lot, I found C/C++ quite okay as a 
 language. But
 after extended time using D, I find C/C++ borderline 
 intolerable, and don't
 enjoy writing it at all.
 But the tooling built around C/C++ is pretty good, and as 
 such, I find the
 tooling while working in D borderline intolerable.

 So, before, I generally enjoyed my work, and felt generally 
 productive. Now
 days, whenever I do any work in either language, I find one 
 aspect or the
 other borderline intolerable, and I have trouble enjoying 
 spending my time
 programming for long periods before getting frustrated and 
 going and doing
 something else...

 I'm quite serious, this is a true realisation of an 
 unconscious behaviour.
 D ruined C/C++ for me, but my expectations of C/C++'s tooling 
 still remains
 a barrier to my enjoyment of writing D code all time time... 
 I'm fucked!


 I'm personally of the opinion that if you're resorting to a 
 debugger, that you really don't understand the code you're 
 writing and how to debug it.

 vb.net. Note my first language was vb.net 7 odd years ago. And 

 degree. I have only used one once or twice for e.g. assembly 
 which I don't truly understand.


I disagree. Your claim it might be true when:

1. *you* recently wrote the code (last 18 months)
2. your the code base is small < 50 000 LOC
3. You're single threaded.
4. You have no third-party dependencies/libraries.

But that has never been the case for me at work, only for 
personal stuff.

It is so much more efficient to track down problems with a good 
debugger. Good GDB support would be great ... I know it is being 
worked on so I'm happy :D


 So for me auto completion and refactoring is most important. 
 Mono-D is quite close for auto completion but it needs to get a 
 lot more stable before I'll be happy.


I don't understand the reliance on IDEs around here. Is there 
something lacking in computer science education at uni nowadays?

Package managers are nice, dub rocks!.

I'd much prefer to see D devs working on improving ARM support 
and improving the GC. Again this is happening already so I cannot 
way to see where it goes.

Cheers.
Jan 27 2014
parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
I can understand why you think about how I work, the way you do. 
Its like the difference between an introvert and an extravert. 
Its just so different way of working and thinking. Its 
unbelievable.

I have honestly never meet somebody who works even similar to me.
Jan 27 2014
parent reply "mongrel" <sillymongrel gmail.com> writes:
On Monday, 27 January 2014 at 10:28:29 UTC, Rikki Cattermole 
wrote:

 I can understand why you think about how I work, the way you 
 do. Its like the difference between an introvert and an 
 extravert. Its just so different way of working and thinking. 
 Its unbelievable.

 I have honestly never meet somebody who works even similar to 
 me.


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.
Jan 28 2014
parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
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.
Jan 28 2014
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 27 January 2014 19:29, Rikki Cattermole <alphaglosined gmail.com> wrote:


 On Monday, 27 January 2014 at 08:24:07 UTC, Manu wrote:


 On 27 January 2014 18:11, Manu <turkeyman gmail.com> wrote:

  In order:

 1. A debugger (that works properly)
 2. Go-to definition (that always works)
 3. Auto-complete (that always works)
 4. Import management (missing/duplicate/unused imports)
 5. Typical suite of modern refactoring tools


 I might add, the frequency to which I pine for these things is in the
 order
 of minutes, perhaps even 10s of seconds >_<

 I made an interesting observation recently... D has kind of ruined my
 career ;)
 Before I started using D a lot, I found C/C++ quite okay as a language.
 But
 after extended time using D, I find C/C++ borderline intolerable, and
 don't
 enjoy writing it at all.
 But the tooling built around C/C++ is pretty good, and as such, I find the
 tooling while working in D borderline intolerable.

 So, before, I generally enjoyed my work, and felt generally productive.
 Now
 days, whenever I do any work in either language, I find one aspect or the
 other borderline intolerable, and I have trouble enjoying spending my time
 programming for long periods before getting frustrated and going and doing
 something else...

 I'm quite serious, this is a true realisation of an unconscious behaviour.
 D ruined C/C++ for me, but my expectations of C/C++'s tooling still
 remains
 a barrier to my enjoyment of writing D code all time time... I'm fucked!


 I'm personally of the opinion that if you're resorting to a debugger, that
 you really don't understand the code you're writing and how to debug it.


That's one key point of a good debugger; when you don't understand the code
you're debugging at all, but you need to fix it, like, 3 hours ago.




 couple months ago in a course for my degree. I have only used one once or
 twice for e.g. assembly which I don't truly understand.

 Its strange for me to see people use it so much. Because its such a
 different approach.


I obviously use many other techniques when a debugger isn't available, but
I don't know any in which I feel similarly as productive as with good
runtime debug and analysis tools.

So for me auto completion and refactoring is most important. Mono-D is

 quite close for auto completion but it needs to get a lot more stable
 before I'll be happy.

 I would also like to point out that for a long time we didn't really have
 a standard build manager. I was designing my own based upon Maven when dub
 came along.

 So I'm happy with the way the ecosystem is going for this.


dub doesn't address my needs at all, but I've put crap loads of time/energy
into the D extension for premake, which works well (
https://bitbucket.org/premakeext), although for some reason has never
really gotten any attention from the D community :(

It generates cross-language build scripts (ie, C/C++ and D code all
together in the same project) for make and many popular IDE's.
I use it for large scale projects that involve C/C++ engine library, D
front end code, and other ancillary libraries bolted on the side.
Jan 27 2014
next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Monday, 27 January 2014 at 11:32:04 UTC, Manu wrote:
[:snip:]

 dub doesn't address my needs at all, but I've put crap loads of 
 time/energy
 into the D extension for premake, which works well (
 https://bitbucket.org/premakeext), although for some reason has 
 never
 really gotten any attention from the D community :(

 It generates cross-language build scripts (ie, C/C++ and D code 
 all
 together in the same project) for make and many popular IDE's.
 I use it for large scale projects that involve C/C++ engine 
 library, D
 front end code, and other ancillary libraries bolted on the 
 side.


I had a look at it and wow. If I had seen this a year ago I would 
have helped!
Here is my spec for my build system that I was designing back 
then[0].

[0] http://pastebin.com/agChTmPM
Jan 27 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
 dub doesn't address my needs at all, but I've put crap loads of 
 time/energy
 into the D extension for premake, which works well (
 https://bitbucket.org/premakeext), although for some reason has 
 never
 really gotten any attention from the D community :(


Never heard of the extension until now.


 It generates cross-language build scripts (ie, C/C++ and D code 
 all
 together in the same project) for make and many popular IDE's.
 I use it for large scale projects that involve C/C++ engine 
 library, D
 front end code, and other ancillary libraries bolted on the 
 side.


That's cool, and I might make use of this when mixing D and 
C/C++. What dub does do really well is just making any source 
package available. I wish I had that plus the full features of a 
build system like CMake all under one roof.

Atila
Jan 27 2014
next sibling parent Manu <turkeyman gmail.com> writes:
On 28 January 2014 01:47, Atila Neves <atila.neves gmail.com> wrote:


  dub doesn't address my needs at all, but I've put crap loads of

 time/energy
 into the D extension for premake, which works well (
 https://bitbucket.org/premakeext), although for some reason has never
 really gotten any attention from the D community :(


 Never heard of the extension until now.




 It generates cross-language build scripts (ie, C/C++ and D code all
 together in the same project) for make and many popular IDE's.
 I use it for large scale projects that involve C/C++ engine library, D
 front end code, and other ancillary libraries bolted on the side.


 That's cool, and I might make use of this when mixing D and C/C++. What
 dub does do really well is just making any source package available. I wish
 I had that plus the full features of a build system like CMake all under
 one roof.



premake does everything cmake does (that I care about), and also ticks some
boxes (that I make heavy use of) that cmake lacks; like supporting games
consoles and stuff like that.
I've never been happy with cmake, but premake is fairly nice, and it's
fully scriptable if it's idea of something is just not quite right.

Only problem is, there's been heaps of development on premake, homing in on
premake5, mainly in terms of extensibility. But it's not yet available as
binary packages. My extensions for D and other IDE's and toolchains all
work against the trunk premake5 code.
Jan 27 2014
prev sibling parent Manu <turkeyman gmail.com> writes:
On 28 January 2014 11:16, Manu <turkeyman gmail.com> wrote:


 On 28 January 2014 01:47, Atila Neves <atila.neves gmail.com> wrote:


  dub doesn't address my needs at all, but I've put crap loads of

 time/energy
 into the D extension for premake, which works well (
 https://bitbucket.org/premakeext), although for some reason has never
 really gotten any attention from the D community :(


 Never heard of the extension until now.




 It generates cross-language build scripts (ie, C/C++ and D code all
 together in the same project) for make and many popular IDE's.
 I use it for large scale projects that involve C/C++ engine library, D
 front end code, and other ancillary libraries bolted on the side.


 That's cool, and I might make use of this when mixing D and C/C++. What
 dub does do really well is just making any source package available. I wish
 I had that plus the full features of a build system like CMake all under
 one roof.



 premake does everything cmake does (that I care about), and also ticks
 some boxes (that I make heavy use of) that cmake lacks; like supporting
 games consoles and stuff like that.
 I've never been happy with cmake, but premake is fairly nice, and it's
 fully scriptable if it's idea of something is just not quite right.

 Only problem is, there's been heaps of development on premake, homing in
 on premake5, mainly in terms of extensibility. But it's not yet available
 as binary packages. My extensions for D and other IDE's and toolchains all
 work against the trunk premake5 code.


I should add, onthe plus side, premake is a single self-contained exe with
no runtime dependencies.
I typically build a binary, and just commit it to my project's bin/ folder,
and it just works, so others that want to build my projects don't have to
stuff around trying to build it.
Jan 27 2014
prev sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Monday, 27 January 2014 at 09:29:44 UTC, Rikki Cattermole
wrote:

 I'm personally of the opinion that if you're resorting to a 
 debugger, that you really don't understand the code you're 
 writing and how to debug it.


Having a debugger to make sense of core files is pretty handy.
Also, have you ever tried to sell a language to a team with the
caveat that it doesn't have a working debugger of any sort?
Finally, it's often not possible to re-run an app with additional
logging to figure out a problem.  And if you didn't think to log
something that turns out to be important for diagnosing some bug,
being able to attach to a running process with a debugger is
pretty handy.  Or dtrace or something.  I've been doing printf
debugging of low-level issues in D for... gosh, ten years now?  I
can handle it.  Really.  But isn't it time we moved into the
current century?
Jan 31 2014
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 27.01.2014 09:23, schrieb Manu:

 I made an interesting observation recently... D has kind of ruined my
 career ;)
 Before I started using D a lot, I found C/C++ quite okay as a language.
 But after extended time using D, I find C/C++ borderline intolerable,
 and don't enjoy writing it at all.
 But the tooling built around C/C++ is pretty good, and as such, I find
 the tooling while working in D borderline intolerable.

 So, before, I generally enjoyed my work, and felt generally productive.
 Now days, whenever I do any work in either language, I find one aspect
 or the other borderline intolerable, and I have trouble enjoying
 spending my time programming for long periods before getting frustrated
 and going and doing something else...

 I'm quite serious, this is a true realisation of an unconscious
 behaviour. D ruined C/C++ for me, but my expectations of C/C++'s tooling
 still remains a barrier to my enjoyment of writing D code all time
 time... I'm fucked!


So true for me, too... to the point that I'm sometimes mentally blocked 
from performing some simple kind of refactoring or implementing a little 
feature in C++ because my brain simply refuses to do that in such a 
sub-optimal way :(

With declining frequency of programming in C++ this got much worse (I 
was using D for some hobby projects besides my mostly C++ day job for 
some years until I finally also used it for a project at work before I 
quit and now use D almost exclusively).
Jan 27 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Manu:


 D ruined C/C++ for me, but my expectations of C/C++'s tooling 
 still remains
 a barrier to my enjoyment of writing D code all time time... 
 I'm fucked!


This is a recurring event in the Python world: Java/C++ 
programmers that try Python, find it much more productive and 
nice, and fall in love with it, and then can't use it because at 
work they are forced to use Java/C++ (or sometimes because Python 
is too much slow for their purposes). Sometimes the end result is 
that they are less happy than before in doing their daily work. 
So sometimes they end not suggesting Python to their colleagues 
to avoid them the same sad realization. I remember hearing 
something similar in Haskell community too, that is spoils you 
too much.

Bye,
bearophile
Jan 28 2014
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Monday, 27 January 2014 at 08:24:07 UTC, Manu wrote:


 I'm quite serious, this is a true realisation of an unconscious 
 behaviour.
 D ruined C/C++ for me, but my expectations of C/C++'s tooling 
 still remains
 a barrier to my enjoyment of writing D code all time time... 
 I'm fucked!


Similar experience here. D has ruined my enjoyment of writing 
code in any language including D :).
Jan 30 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 1/27/2014 3:23 AM, Manu wrote:

 I made an interesting observation recently... D has kind of ruined my
 career ;)
 Before I started using D a lot, I found C/C++ quite okay as a language. But
 after extended time using D, I find C/C++ borderline intolerable, and don't
 enjoy writing it at all.
 But the tooling built around C/C++ is pretty good, and as such, I find the
 tooling while working in D borderline intolerable.

 So, before, I generally enjoyed my work, and felt generally productive. Now
 days, whenever I do any work in either language, I find one aspect or the
 other borderline intolerable, and I have trouble enjoying spending my time
 programming for long periods before getting frustrated and going and doing
 something else...

 I'm quite serious, this is a true realisation of an unconscious behaviour.
 D ruined C/C++ for me, but my expectations of C/C++'s tooling still remains
 a barrier to my enjoyment of writing D code all time time... I'm fucked!


I had a similar experience a little over ten years back with C/C++ vs 
Java. I'd been a [relatively] happy C/C++ user, until I tried Java which 
destroyed my ability to tolerate C++'s import system and OOP. But Java 
(this was back around v1.2) came with plenty of its own pains, so I 
became extremely frustrated with programming in general.



some other things.) The debugger issues don't really bug [heh] me much 
because I've been in many situations in the past where I didn't have a 
debugger available, that I've become very comfortable with printf-style 
debugging, and usually even prefer it. (Not that a good debugger isn't a 
fantastic thing to have. It certainly is.)
Jan 31 2014
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
. Static analysis
. Automated refactoring plugins for different editors
. Go to definition plugins for different editors
. Unused import warnings
. Some way of figuring out which import a function is from

Right now I'm glad that flycheck highlights compilation errors 
for me in emacs, but unfortunately there is no way currently to 
pass it -I flags for different projects so any non-Phobos 
non-currentdir imports fail.

I was also surprised to find an unused variable in my code a day 
or two ago that the compiler never warned me about. I wasn't 
happy.

Atila

On Sunday, 26 January 2014 at 20:29:30 UTC, Oten wrote:

 Which tools do you miss in the D language? it can be from any
 language not from C or C++ only but from any language that you
 have used and liked (might not liked but increased productivity
 anyway)  A very common argument from peoples which do choose
 other language than D is lack of your tools for D, even if they
 want to get D they say can't switch. The most common tools which
 they miss is debuggers/static analyzer/lint and so on. I think
 that by sharing this list with community instead of just say it
 like a criticizes is good because next time that some people say
 that such a x tools isn't available you can say "No, there's a D
 version for that". Also, totally new ideas are very welcome. If
 you  have had a idea that for any reason you wouldn't implement
 yourself, tell us too.
 (sorry for english, not my native language)
Jan 27 2014
parent "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Monday, 27 January 2014 at 08:27:57 UTC, Atila Neves wrote:

 Right now I'm glad that flycheck highlights compilation errors 
 for me in emacs, but unfortunately there is no way currently to 
 pass it -I flags for different projects so any non-Phobos 
 non-currentdir imports fail.


Here's what I do for flymake. I'm not suggesting it's great, but 
it works for me:

https://gist.github.com/gmfawcett/8656475

You can specify compiler options in a project-local file, 
d.flymake.opts, which gets included to the compiler call using 
the ' ' directive.

Graham
Jan 27 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
Pretty much only thing I really miss compared to C++ is full 
valgrind support (including callgrind and helgrind).

There are a lot of things in tooling that could have been 
improved, but those are not a deal breakers are my typical 
development env is very minimalistic and does not rely on 
anything fancy.
Jan 27 2014
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/26/2014 09:29 PM, Oten wrote:

 Which tools do you miss in the D language? ...


A fully working compiler for the most recent language version.
Jan 27 2014
next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 27 January 2014 at 17:57:02 UTC, Timon Gehr wrote:

 On 01/26/2014 09:29 PM, Oten wrote:

 Which tools do you miss in the D language? ...


 A fully working compiler for the most recent language version.


Indeed, and robust documentation for it too.
Jan 27 2014
prev sibling parent reply "Asman01" <jckj33 gmail.com> writes:
On Monday, 27 January 2014 at 17:57:02 UTC, Timon Gehr wrote:

 On 01/26/2014 09:29 PM, Oten wrote:

 Which tools do you miss in the D language? ...


 A fully working compiler for the most recent language version.


So is dmd compiler not eable to compile the most recent language
version?
Jan 30 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/31/2014 12:00 AM, Asman01 wrote:

 On Monday, 27 January 2014 at 17:57:02 UTC, Timon Gehr wrote:

 On 01/26/2014 09:29 PM, Oten wrote:

 Which tools do you miss in the D language? ...


 A fully working compiler for the most recent language version.


 So is dmd compiler not eable to compile the most recent language
 version?


It is meant to and it often works.

https://d.puremagic.com/issues/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=
Jan 31 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Oten:


 Which tools do you miss in the D language?


A REPL, a static code analyzer, a code beautifier as indent, a 
profiler for LDC2, a memory profiler, a parallelism profiler.

Bye,
bearophile
Jan 28 2014
parent reply "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
On Wednesday, 29 January 2014 at 02:08:19 UTC, bearophile wrote:

 a code beautifier as indent


That. I really miss the Eclipse shortcut that makes all Java code 
indent the same way, swapping spaces for tabs or tabs for spaces, 
conforming to some max line length. It requires more than a tool 
though, someone needs to sit down and decide what things should 
look like by default. Even if you don't like Sun's style guide, 
it's still infinitely better than no guide and it can be modified 
quite easily.

I'm glad that at least D has a naming convention. I often wish 
for more though.
Jan 31 2014
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/31/14, "Casper Færgemand\" <shorttail hotmail.com>" puremagic.com
<"Casper Færgemand\" <shorttail hotmail.com>" puremagic.com> wrote:

 On Wednesday, 29 January 2014 at 02:08:19 UTC, bearophile wrote:

 a code beautifier as indent


 That.


Uncrustify[1] (and a GUI front-end like UniversalIndentGUI[2]) works
great with D code, I use it all the time. Note that UniversalIndentGUI
typically comes with an outdated version of Uncrustify, so you could
simply swap its version of the uncrustify binary with a new version to
support the latest C++/D syntax.

[1] : http://uncrustify.sourceforge.net/
[2] : http://universalindent.sourceforge.net/
Jan 31 2014
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, January 26, 2014 20:29:28 Oten wrote:

 Which tools do you miss in the D language? it can be from any
 language not from C or C++ only but from any language that you
 have used and liked (might not liked but increased productivity
 anyway) A very common argument from peoples which do choose
 other language than D is lack of your tools for D, even if they
 want to get D they say can't switch. The most common tools which
 they miss is debuggers/static analyzer/lint and so on. I think
 that by sharing this list with community instead of just say it
 like a criticizes is good because next time that some people say
 that such a x tools isn't available you can say "No, there's a D
 version for that". Also, totally new ideas are very welcome. If
 you have had a idea that for any reason you wouldn't implement
 yourself, tell us too.
 (sorry for english, not my native language)


About the only thing that I can think of would be a proper debugger that 
actually understood D. gdb kind of works but not all that well. Of course, gdb 
doesn't even properly understand C++, so in that respect, I'm not sure that 
we're all that much worse of than C++ is. But a proper debugger that actually 
understood D arrays and strings and whatnot would be fantastic. Most of the 
other features that folks like to list (like autocompletion, jump to 
definition, or many IDE-specific tools) are exactly the sort of thing that I 
don't even have or bother with in C++ (often because vim can't do them well), 
so while they might be nice to have, I generally don't even think about them 
much.

- Jonathan M Davis
Jan 31 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Saturday, 1 February 2014 at 01:34:32 UTC, Jonathan M Davis 
wrote:

 About the only thing that I can think of would be a proper 
 debugger that
 actually understood D. gdb kind of works but not all that well. 
 Of course, gdb
 doesn't even properly understand C++, so in that respect, I'm 
 not sure that
 we're all that much worse of than C++ is.


GDB works on Linux.  On OSX, I can't get more than a stack trace 
out of GDB / LLDB.  Or disassembly I suppose.  But all variable 
inspection is broken.
Feb 01 2014
parent reply "Jacob Carlborg" <doob me.com> writes:
On Saturday, 1 February 2014 at 17:21:32 UTC, Sean Kelly wrote:


 GDB works on Linux.  On OSX, I can't get more than a stack 
 trace out of GDB / LLDB.  Or disassembly I suppose.  But all 
 variable inspection is broken.


With LLDB I get stack trace with line numbers, breakpoints and it 
shows parts of the source code at breakpoints. Although using the 
mangled name is required for setting a breakpoint at a symbol.

--
/Jacob Carlborg
Feb 02 2014
parent "woh" <wojw yahoo.com> writes:
  My list is the same as Manu.

  For me tools are an intrinsic part of the language, D tools
are so bad that I prefer to write CPP to avoid the anger D IDE's 
instill in me
Feb 02 2014
prev sibling next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
A debugger integrated into an IDE is the most important feature

see all the code I'm in, see all the variables, all graphically,
is extremely useful. In D I have to resort to printf except for
using gdb/lldb to look at the stack-trace in a segfault.

Mono-D works nicely for coding, but I have not had any luck
getting debugging working in it in OSX (but I use OSX Mavericks
which replaces things like gcc with aliases to clang and includes
only lldb by default).
Feb 03 2014
parent "eles" <eles eles.com> writes:
On Monday, 3 February 2014 at 15:19:36 UTC, Kapps wrote:

 A debugger integrated into an IDE is the most important feature


Eclipse DDT is coming.

https://github.com/bruno-medeiros/DDT/
Feb 03 2014
prev sibling next sibling parent "Asman01" <jckj33 gmail.com> writes:
Just out curiosity, who does the use of UNIX's tools like cflow?
Feb 03 2014
prev sibling parent reply Liu <liiudk gmail.com> writes:
Do any of the those tools mentioned here exist today?
May 29 2020
next sibling parent welkam <wwwelkam gmail.com> writes:
On Friday, 29 May 2020 at 19:43:19 UTC, Liu wrote:

 Do any of the those tools mentioned here exist today?


you need to be more specific if you want to get an answer
May 29 2020
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 29 May 2020 at 19:43:19 UTC, Liu wrote:

 Do any of the those tools mentioned here exist today?


Yes.
May 31 2020
parent user <user user.com> writes:
On Sunday, 31 May 2020 at 08:22:12 UTC, Bastiaan Veelo wrote:

 On Friday, 29 May 2020 at 19:43:19 UTC, Liu wrote:

 Do any of the those tools mentioned here exist today?


 Yes.



Reading some posts in the original thread reminded me of this:

https://www.hillelwayne.com/post/learning-a-language/

-sb
Jun 05 2020