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=

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

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

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.

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

 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
/\*#,

A debugger integrated into an IDE is the most important feature
I'm missing. Debugging code in C# where I can step into easily,
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).

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/

Just out curiosity, who does the use of UNIX's tools like cflow?

Do any of the those tools mentioned here exist today?