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 "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
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 "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
prev sibling next sibling 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 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
parent 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
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--f46d0444ea99f121b404f0ef41ea
Content-Type: text/plain; charset=UTF-8

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

--f46d0444ea99f121b404f0ef41ea
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div>In order:</div><div><br></div><div>1. A debugger (that
works properly)</div><div>2. Go-to definition (that always works)</div>3.
Auto-complete (that always works)<div>4. Import management
(missing/duplicate/unused imports)<br>
</div><div>5. Typical suite of modern refactoring tools</div></div>

--f46d0444ea99f121b404f0ef41ea--
Jan 27 2014
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
next 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.
 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
Jan 28 2014
prev sibling 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 "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 next sibling parent reply Manu <turkeyman gmail.com> writes:
--089e015384d6bc7e5a04f0ef6d96
Content-Type: text/plain; charset=UTF-8

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! --089e015384d6bc7e5a04f0ef6d96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 7 January 2014 18:11, Manu <span dir=3D"ltr">&lt;<a href=3D"mailto:turkeyma= n gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt;</span> wrote:<br=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=

<div dir=3D"ltr"><div>In order:</div><div><br></div><div>1. A debugger (tha= t works properly)</div><div>2. Go-to definition (that always works)</div>3.= Auto-complete (that always works)<div>4. Import management (missing/duplic= ate/unused imports)<br> </div><div>5. Typical suite of modern refactoring tools</div></div> </blockquote></div><br></div><div class=3D"gmail_extra">I might add, the fr= equency to which I pine for these things is in the order of minutes, perhap= s even 10s of seconds &gt;_&lt;</div><div class=3D"gmail_extra"><br></div> <div class=3D"gmail_extra">I made an interesting observation recently... D = has kind of ruined my career ;)</div><div class=3D"gmail_extra">Before I st= arted using D a lot, I found C/C++ quite okay as a language. But after exte= nded time using D, I find C/C++ borderline intolerable, and don&#39;t enjoy= writing it at all.</div> <div class=3D"gmail_extra">But the tooling built around C/C++ is pretty goo= d, and as such, I find the tooling while working in D borderline intolerabl= e.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So,= before, I generally enjoyed my work, and felt generally productive. Now da= ys, whenever I do any work in either language, I find one aspect or the oth= er borderline intolerable, and I have trouble enjoying spending my time pro= gramming for long periods before getting frustrated and going and doing som= ething else...</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I&#39;m qui= te serious, this is a true realisation of an unconscious behaviour. D ruine= d C/C++ for me, but my expectations of C/C++&#39;s tooling still remains a = barrier to my enjoyment of writing D code all time time... I&#39;m fucked!<= /div> </div> --089e015384d6bc7e5a04f0ef6d96--
Jan 27 2014
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 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. Luckily D fixed all that for me (and to a lesser extent, C#, but that was before I got fed up with C#'s near-total lack of metaprogramming and 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 "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 "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
prev sibling next sibling parent "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. I've only really needed it in .net languages like c# and vb.net. Note my first language was vb.net 7 odd years ago. And I was doing c# up to a 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. 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
prev sibling next sibling parent "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. I've only really needed it in .net languages like c# and vb.net. Note my first language was vb.net 7 odd years ago. And I was doing c# up to a 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.

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
prev sibling 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 "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
prev sibling next sibling parent 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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e0149c506ba32bc04f0f11a5e
Content-Type: text/plain; charset=UTF-8

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

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. I've only really needed it in .net languages like c# and vb.net. Note my
 first language was vb.net 7 odd years ago. And I was doing c# up to a
 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. --089e0149c506ba32bc04f0f11a5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 7 January 2014 19:29, Rikki Cattermole <span dir=3D"ltr">&lt;<a href=3D"mai= lto:alphaglosined gmail.com" target=3D"_blank">alphaglosined gmail.com</a>&= gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div>On Monday, 27 January 2014 at 08:24:07 UTC, Manu wrot= e:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s= olid;padding-left:1ex"><div> On 27 January 2014 18:11, Manu &lt;<a href=3D"mailto:turkeyman gmail.com" t= arget=3D"_blank">turkeyman gmail.com</a>&gt; wrote:<br> <br> </div><div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le= ft-style:solid;padding-left:1ex"> In order:<br> <br> 1. A debugger (that works properly)<br> 2. Go-to definition (that always works)<br> 3. Auto-complete (that always works)<br> 4. Import management (missing/duplicate/unused imports)<br> 5. Typical suite of modern refactoring tools<br> <br> </blockquote> <br></div></div><div> I might add, the frequency to which I pine for these things is in the order= <br> of minutes, perhaps even 10s of seconds &gt;_&lt;<br> <br> I made an interesting observation recently... D has kind of ruined my<br> career ;)<br> Before I started using D a lot, I found C/C++ quite okay as a language. But= <br> after extended time using D, I find C/C++ borderline intolerable, and don&#= 39;t<br> enjoy writing it at all.<br> But the tooling built around C/C++ is pretty good, and as such, I find the<= br> tooling while working in D borderline intolerable.<br> <br> So, before, I generally enjoyed my work, and felt generally productive. Now= <br> days, whenever I do any work in either language, I find one aspect or the<b= r> other borderline intolerable, and I have trouble enjoying spending my time<= br> programming for long periods before getting frustrated and going and doing<= br> something else...<br> <br> I&#39;m quite serious, this is a true realisation of an unconscious behavio= ur.<br> D ruined C/C++ for me, but my expectations of C/C++&#39;s tooling still rem= ains<br> a barrier to my enjoyment of writing D code all time time... I&#39;m fucked= !<br> </div></blockquote> <br> I&#39;m personally of the opinion that if you&#39;re resorting to a debugge= r, that you really don&#39;t understand the code you&#39;re writing and how= to debug it.<br></blockquote><div><br></div><div>That&#39;s one key point = of a good debugger; when you don&#39;t understand the code you&#39;re debug= ging at all, but you need to fix it, like, 3 hours ago.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"> I&#39;ve only really needed it in .net languages like c# and <a href=3D"htt= p://vb.net" target=3D"_blank">vb.net</a>. Note my first language was <a hre= f=3D"http://vb.net" target=3D"_blank">vb.net</a> 7 odd years ago. And I was= doing c# up to a couple months ago in a course for my degree. I have only = used one once or twice for e.g. assembly which I don&#39;t truly understand= .<br> <br> Its strange for me to see people use it so much. Because its such a differe= nt approach.<br></blockquote><div><br></div><div>I obviously use many other= techniques when a debugger isn&#39;t available, but I don&#39;t know any i= n which I feel similarly as productive as with good runtime debug and analy= sis tools.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"> So for me auto completion and refactoring is most important. Mono-D is quit= e close for auto completion but it needs to get a lot more stable before I&= #39;ll be happy.<br> <br> I would also like to point out that for a long time we didn&#39;t really ha= ve a standard build manager. I was designing my own based upon Maven when d= ub came along.<br> <br> So I&#39;m happy with the way the ecosystem is going for this.<br> </blockquote></div><br></div><div class=3D"gmail_extra">dub doesn&#39;t add= ress my needs at all, but I&#39;ve put crap loads of time/energy into the D= extension for premake, which works well (<a href=3D"https://bitbucket.org/= premakeext" target=3D"_blank">https://bitbucket.org/premakeext</a>), althou= gh for some reason has never really gotten any attention from the D communi= ty :(</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">It generate= s cross-language build scripts (ie, C/C++ and D code all together in the sa= me project) for make and many popular IDE&#39;s.</div><div class=3D"gmail_e= xtra"> I use it for large scale projects that involve C/C++ engine library, D fron= t end code, and other ancillary libraries bolted on the side.</div></div> --089e0149c506ba32bc04f0f11a5e--
Jan 27 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 next sibling parent Manu <turkeyman gmail.com> writes:
--f46d04479f93b58b7f04f0f376fb
Content-Type: text/plain; charset=UTF-8

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 (possibly from complex preprocessor mess?), but C# is the clear benchmark for quality here. 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. 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

--f46d04479f93b58b7f04f0f376fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 7 January 2014 22:14, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailt= o:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"> <div class=3D"im">On 2014-01-27 09:11, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> In order:<br> <br> 1. A debugger (that works properly)<br> 2. Go-to definition (that always works)<br> 3. Auto-complete (that always works)<br> </blockquote> <br></div> How well do these work for you in Visual Studio for C++? I&#39;m finding ca= ses in Xcode where it doesn&#39;t always work, especially in DMD.</blockquo= te><div><br></div><div>The VC debugger is perfect for C/C++. I can&#39;t im= agine how it would be improved. You can even edit your code and rebuild+rel= ink while it&#39;s running to make minor runtime tweaks, and continue execu= tion using the modified code.</div> <div>Go-to definition is not perfect, but it works 95% of the time.</div><d= iv>Auto-complete is very good in C/C++ but there are a few rough edges (pos= sibly from complex preprocessor mess?), but C# is the clear benchmark for q= uality here.</div> <div><br></div><div>D doesn&#39;t have a preprocessor or a horrible network= of text include, it should easily be able to match the C# experiences in g= eneral.</div><div><br></div><div>I say &#39;that always works&#39; above, i= mplying that it sometimes works... which is true, but it&#39;s in the realm= of 30% for me, which is unreliable enough to be very annoying. Any time &#= 39;class&#39; appears in D, it all goes south under VisualD.</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"= im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> 4. Import management (missing/duplicate/unused imports)<br> 5. Typical suite of modern refactoring tools<br> </blockquote> <br></div> I agree on all the above.<span class=3D"HOEnZb"><font color=3D"#888888"><br=

-- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br></div></div> --f46d04479f93b58b7f04f0f376fb--
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 "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 next 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 "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
prev sibling next 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 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
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 "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 next sibling 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 Manu <turkeyman gmail.com> writes:
--089e0116150aab25d704f0fd9306
Content-Type: text/plain; charset=UTF-8

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. --089e0116150aab25d704f0fd9306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 8 January 2014 01:47, Atila Neves <span dir=3D"ltr">&lt;<a href=3D"mailto:a= tila.neves gmail.com" target=3D"_blank">atila.neves gmail.com</a>&gt;</span=
 wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div><br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> dub doesn&#39;t address my needs at all, but I&#39;ve put crap loads of tim= e/energy<br> into the D extension for premake, which works well (<br> <a href=3D"https://bitbucket.org/premakeext" target=3D"_blank">https://bitb= ucket.org/<u></u>premakeext</a>), although for some reason has never<br> really gotten any attention from the D community :(<br> </blockquote> <br></div> Never heard of the extension until now.<div><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> <br> It generates cross-language build scripts (ie, C/C++ and D code all<br> together in the same project) for make and many popular IDE&#39;s.<br> I use it for large scale projects that involve C/C++ engine library, D<br> front end code, and other ancillary libraries bolted on the side.<br> </blockquote> <br></div> That&#39;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 wis= h I had that plus the full features of a build system like CMake all under = one roof.</blockquote> <div><br></div><div>premake does everything cmake does (that I care about),= and also ticks some boxes (that I make heavy use of) that cmake lacks; lik= e supporting games consoles and stuff like that.</div><div>I&#39;ve never b= een happy with cmake, but premake is fairly nice, and it&#39;s fully script= able if it&#39;s idea of something is just not quite right.</div> <div><br></div><div>Only problem is, there&#39;s been heaps of development = on premake, homing in on premake5, mainly in terms of extensibility. But it= &#39;s not yet available as binary packages. My extensions for D and other = IDE&#39;s and toolchains all work against the trunk premake5 code.</div> </div></div></div> --089e0116150aab25d704f0fd9306--
Jan 27 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--f46d0445178f72d79c04f0fdb281
Content-Type: text/plain; charset=UTF-8

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. --f46d0445178f72d79c04f0fdb281 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 8 January 2014 11:16, Manu <span dir=3D"ltr">&lt;<a href=3D"mailto:turkeyma= n gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt;</span> wrote:<br=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
<div class=3D"h5">On 28 January 2014 01:47, Atila Neves <span dir=3D"ltr">=

gmail.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div><br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> dub doesn&#39;t address my needs at all, but I&#39;ve put crap loads of tim= e/energy<br> into the D extension for premake, which works well (<br> <a href=3D"https://bitbucket.org/premakeext" target=3D"_blank">https://bitb= ucket.org/<u></u>premakeext</a>), although for some reason has never<br> really gotten any attention from the D community :(<br> </blockquote> <br></div> Never heard of the extension until now.<div><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> <br> It generates cross-language build scripts (ie, C/C++ and D code all<br> together in the same project) for make and many popular IDE&#39;s.<br> I use it for large scale projects that involve C/C++ engine library, D<br> front end code, and other ancillary libraries bolted on the side.<br> </blockquote> <br></div> That&#39;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 wis= h I had that plus the full features of a build system like CMake all under = one roof.</blockquote> <div><br></div></div></div><div>premake does everything cmake does (that I = care about), and also ticks some boxes (that I make heavy use of) that cmak= e lacks; like supporting games consoles and stuff like that.</div><div> I&#39;ve never been happy with cmake, but premake is fairly nice, and it&#3= 9;s fully scriptable if it&#39;s idea of something is just not quite right.= </div> <div><br></div><div>Only problem is, there&#39;s been heaps of development = on premake, homing in on premake5, mainly in terms of extensibility. But it= &#39;s not yet available as binary packages. My extensions for D and other = IDE&#39;s and toolchains all work against the trunk premake5 code.</div> </div></div></div> </blockquote></div><br></div><div class=3D"gmail_extra">I should add, onthe= plus side, premake is a single self-contained exe with no runtime dependen= cies.</div><div class=3D"gmail_extra">I typically build a binary, and just = commit it to my project&#39;s bin/ folder, and it just works, so others tha= t want to build my projects don&#39;t have to stuff around trying to build = it.</div> </div> --f46d0445178f72d79c04f0fdb281--
Jan 27 2014
prev sibling next sibling parent "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
 should easily be able to match the C# experiences in general.

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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b5d58b4c5a60404f0ffdaf9
Content-Type: text/plain; charset=UTF-8

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
 should easily be able to match the C# experiences in general.

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 :) --047d7b5d58b4c5a60404f0ffdaf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 8 January 2014 13:43, Jakob Ovrum <span dir=3D"ltr">&lt;<a href=3D"mailto:j= akobovrum gmail.com" target=3D"_blank">jakobovrum gmail.com</a>&gt;</span> = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Monday, 27 January 2014= at 13:12:56 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> D doesn&#39;t have a preprocessor or a horrible network of text include, it= <br> should easily be able to match the C# experiences in general.<br> </blockquote> <br></div> No, it&#39;s much, much harder because of templates and string mixins.<br> <br> The only way to get a solid auto-complete experience for D is to use a comp= iler-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 &= quot;good enough&quot; will in fact never be good enough.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Yeah, good point. I= &#39;ve heard murmurings of kitting DMD frontend out as a lib for tooling b= eing thrown around as long as I&#39;ve been trolling here.</div><div class= =3D"gmail_extra"> It must be really hard... or really really uninteresting :)</div></div> --047d7b5d58b4c5a60404f0ffdaf9--
Jan 27 2014
prev sibling next sibling parent "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
 should easily be able to match the C# experiences in general.

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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling 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 "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 "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b471d26c60f5104f1054a4a
Content-Type: text/plain; charset=UTF-8

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) --047d7b471d26c60f5104f1054a4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 8 January 2014 16:05, Temtaime <span dir=3D"ltr">&lt;<a href=3D"mailto:temt= aime gmail.com" target=3D"_blank">temtaime gmail.com</a>&gt;</span> wrote:<= br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> Support of MSVC COFF is really needed for me.<br></blockquote><div><br></di= v><div>Works fine...? (for x64 &gt;_&lt;)</div><div>=C2=A0</div><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"> And x64 codegen without any dependencies like msvc&#39;s link.exe linker.<b= r> </blockquote></div><br></div><div class=3D"gmail_extra">Ummm, your prior se= ntence just insisted for MSVC COFF... but it&#39;s a problem when that&#39;= s you get that? Confused...</div><div class=3D"gmail_extra"><br></div><div = class=3D"gmail_extra"> Personally, I&#39;d say it&#39;s perfect how it is! (just needs x86 support= )</div></div> --047d7b471d26c60f5104f1054a4a--
Jan 28 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a1133096468dbd104f108d31a
Content-Type: text/plain; charset=UTF-8

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. --001a1133096468dbd104f108d31a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 8 January 2014 21:46, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailt= o:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"> <div class=3D"im">On 2014-01-28 04:59, Manu wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Yeah, good point. I&#39;ve heard murmurings of kitting DMD frontend out as = a<br> lib for tooling being thrown around as long as I&#39;ve been trolling here.= <br> It must be really hard... or really really uninteresting :)<br> </blockquote> <br></div> We&#39;re just waiting for Daniel Murphy to finish the D port of the DMD fr= ontend.</blockquote><div><br></div><div>How&#39;s that coming along? The gu= ys basically started that at the last dconf.</div></div></div></div> --001a1133096468dbd104f108d31a--
Jan 28 2014
prev sibling next sibling parent 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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e013d0dc087163904f109453d
Content-Type: text/plain; charset=UTF-8

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! :) --089e013d0dc087163904f109453d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 9 January 2014 01:54, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mailto= :nospam example.com" target=3D"_blank">nospam example.com</a>&gt;</span> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"> Am Wed, 29 Jan 2014 01:41:55 +1100<br> schrieb Manu &lt;<a href=3D"mailto:turkeyman gmail.com">turkeyman gmail.com= </a>&gt;:<br> <div class=3D"im"><br> &gt; &gt;<br> &gt; &gt; We&#39;re just waiting for Daniel Murphy to finish the D port of = the DMD<br> &gt; &gt; frontend.<br> &gt;<br> &gt;<br> </div><div class=3D"im">&gt; How&#39;s that coming along? The guys basicall= y started that at the last<br> &gt; dconf.<br> &gt;<br> <br> </div>I guess you didn&#39;t see this post?<br> <a href=3D"http://forum.dlang.org/thread/52E59C8F.9010100 yahoo.com#post-az= arhavcmyzjflsktoke:40forum.dlang.org" target=3D"_blank">http://forum.dlang.= org/thread/52E59C8F.9010100 yahoo.com#post-azarhavcmyzjflsktoke:40forum.dla= ng.org</a><br> </blockquote></div><br></div><div class=3D"gmail_extra">Indeed I missed tha= t. Awesome! :)</div></div> --089e013d0dc087163904f109453d--
Jan 28 2014
prev sibling next sibling parent 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
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 "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
prev sibling next sibling parent "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
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 next sibling parent "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
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/31/14, "Casper Frgemand\" <shorttail hotmail.com>" puremagic.com
<"Casper Frgemand\" <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 "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 "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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "Kapps" <opantm2+spam gmail.com> writes:
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).
Feb 03 2014
prev sibling next sibling 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 parent "Asman01" <jckj33 gmail.com> writes:
Just out curiosity, who does the use of UNIX's tools like cflow?
Feb 03 2014