www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is the D community lacking development tools?

reply "Roman D. Boiko" <rb d-coding.com> writes:
http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html
May 22 2012
next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 22 May 2012 at 10:03:36 UTC, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


My opinion - no.

We already have:
1) Mono-D, a MonoDevelop plugin - my personal favourite.
2) Code::Blocks - I used it for years, still provides excellent D 
support.
3) Visual D - for VisualStudio users.
4) DDT - for Eclipse users
5) NetbeansD - for NetBeans users
6) Geany and Kate - for those who want to write a quick D proggy.
7) VIM and Emacs

Sure, all of them can be better, provide more fancy features, 
etc...
May 22 2012
next sibling parent "Roman D. Boiko" <rb d-coding.com> writes:
On Tuesday, 22 May 2012 at 10:18:48 UTC, Dejan Lekic wrote:

 On Tuesday, 22 May 2012 at 10:03:36 UTC, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 My opinion - no.
 We already have:
 ...
 5) NetbeansD - for NetBeans users


Didn't know about that one.
May 22 2012
prev sibling next sibling parent "Roman D. Boiko" <rb d-coding.com> writes:
On Tuesday, 22 May 2012 at 10:18:48 UTC, Dejan Lekic wrote:

 On Tuesday, 22 May 2012 at 10:03:36 UTC, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 My opinion - no.
 We already have:
 ...
 5) NetbeansD - for NetBeans users


Didn't know about that one.
May 22 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, May 22, 2012 at 12:18:47PM +0200, Dejan Lekic wrote:

 On Tuesday, 22 May 2012 at 10:03:36 UTC, Roman D. Boiko wrote:

http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 
 My opinion - no.


[...]

+1. For me, vim + dmd/gdc is Good Enough(tm). Other tools are nice to
have, but not a must.

Having said that, though, having the reference compiler as a D-callable
library would be a big plus (for building pretty printers, code
analyzers, etc.).


T

-- 
Computerese Irregular Verb Conjugation: I have preferences.  You have biases. 
He/She has prejudices. -- Gene Wirchenko
May 22 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 22/05/2012 12:18, Dejan Lekic a écrit :

 On Tuesday, 22 May 2012 at 10:03:36 UTC, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 My opinion - no.

 We already have:
 1) Mono-D, a MonoDevelop plugin - my personal favourite.
 2) Code::Blocks - I used it for years, still provides excellent D support.
 3) Visual D - for VisualStudio users.
 4) DDT - for Eclipse users
 5) NetbeansD - for NetBeans users
 6) Geany and Kate - for those who want to write a quick D proggy.
 7) VIM and Emacs

 Sure, all of them can be better, provide more fancy features, etc...


Refactoring tools ? Static code analysis ? Formaters ?


yes, many things are missing.
May 22 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-05-22 18:21, deadalnix wrote:


 Refactoring tools ? Static code analysis ? Formaters ?


 yes, many things are missing.


I completely agree. I forgot about these.

-- 
/Jacob Carlborg
May 22 2012
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 22 May 2012 at 16:21:23 UTC, deadalnix wrote:

 Le 22/05/2012 12:18, Dejan Lekic a écrit :

 On Tuesday, 22 May 2012 at 10:03:36 UTC, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 My opinion - no.

 We already have:
 1) Mono-D, a MonoDevelop plugin - my personal favourite.
 2) Code::Blocks - I used it for years, still provides 
 excellent D support.
 3) Visual D - for VisualStudio users.
 4) DDT - for Eclipse users
 5) NetbeansD - for NetBeans users
 6) Geany and Kate - for those who want to write a quick D 
 proggy.
 7) VIM and Emacs

 Sure, all of them can be better, provide more fancy features, 
 etc...


 Refactoring tools ? Static code analysis ? Formaters ?


 know that yes, many things are missing.


Well, the OT was about lacking of development tools. The author 
did not specify the level of proficiency. Sure many things are 
missing from current tools, but come on, the fact is that one can 
do a serious D project with Mono-D. Well, at least I think 
without a second thought that it is possible.
May 25 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 25.05.2012 18:07, Dejan Lekic wrote:

 On Tuesday, 22 May 2012 at 16:21:23 UTC, deadalnix wrote:

 Le 22/05/2012 12:18, Dejan Lekic a écrit :

 On Tuesday, 22 May 2012 at 10:03:36 UTC, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 My opinion - no.

 We already have:
 1) Mono-D, a MonoDevelop plugin - my personal favourite.
 2) Code::Blocks - I used it for years, still provides excellent D
 support.
 3) Visual D - for VisualStudio users.
 4) DDT - for Eclipse users
 5) NetbeansD - for NetBeans users
 6) Geany and Kate - for those who want to write a quick D proggy.
 7) VIM and Emacs

 Sure, all of them can be better, provide more fancy features, etc...


 Refactoring tools ? Static code analysis ? Formaters ?


 that yes, many things are missing.


 Well, the OT was about lacking of development tools. The author did not
 specify the level of proficiency. Sure many things are missing from
 current tools, but come on, the fact is that one can do a serious D
 project with Mono-D. Well, at least I think without a second thought
 that it is possible.


I tried Mono-D. No dice, it uses about 1.5Gb of RAM on my 2 file "project".
And of course runs out of memory on every single click. Guess I'll wait 
till the end of GSOC. What it does is for now:
-looks nice
-shows errors in-line, I actually kind of liked it
-almost good auto-completion

But it lacks:
- fast editor ;)
- no crashes & mem leaks plz

-- 
Dmitry Olshansky
May 25 2012
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 25 May 2012 18:25:10 +0400
schrieb Dmitry Olshansky <dmitry.olsh gmail.com>:


 I tried Mono-D. No dice, it uses about 1.5Gb of RAM on my 2 file "project".


That's odd. I have a few open projects and 180 MB memory use after loading the
IDE. That's on 64-bit Linux. I've never had OOM issues with Mono-D.


 But it lacks:
 - fast editor ;)


That's in part due to how unprepared the poor GtkTextView was when it was told
to highlight source code. I think it is neither optimized for setting/switching
out thousands of tokens, nor for fixed width fonts where applicable (e.g.
calculating column/line pixel offsets). GEdit and MonoDevelop both use
GtkSourceView/GtkTextView btw.

-- 
Marco
May 28 2012
parent "Roman D. Boiko" <rb d-coding.com> writes:
On Monday, 28 May 2012 at 23:01:24 UTC, Marco Leise wrote:

 Am Fri, 25 May 2012 18:25:10 +0400
 schrieb Dmitry Olshansky <dmitry.olsh gmail.com>

 But it lacks:
 - fast editor ;)


 That's in part due to how unprepared the poor GtkTextView was 
 when it was told to highlight source code. I think it is 
 neither optimized for setting/switching out thousands of 
 tokens, nor for fixed width fonts where applicable (e.g. 
 calculating column/line pixel offsets). GEdit and MonoDevelop 
 both use GtkSourceView/GtkTextView btw.



(IIRC since v. 2.0)
May 29 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-05-25 16:07, Dejan Lekic wrote:


 Well, the OT was about lacking of development tools. The author did not
 specify the level of proficiency. Sure many things are missing from
 current tools, but come on, the fact is that one can do a serious D
 project with Mono-D. Well, at least I think without a second thought
 that it is possible.


I do all my D coding with TextMate with a customized D bundle and the 
command line.

-- 
/Jacob Carlborg
May 26 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On May 22, 2012, at 7:43 AM, "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 On Tue, May 22, 2012 at 12:18:47PM +0200, Dejan Lekic wrote:

 On Tuesday, 22 May 2012 at 10:03:36 UTC, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-to=






ols.html

=20
 My opinion - no.


 [...]
=20
 +1. For me, vim + dmd/gdc is Good Enough(tm). Other tools are nice to
 have, but not a must.


It depends on the platform. GDB works fine on Linux, but is pretty much brok=
en on OSX. Does Visual Studio work on Windows? Because that standalone debug=
ger bundled with DMD is garbage.=20=
May 22 2012
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
On Tuesday, 22 May 2012 at 10:18:48 UTC, Dejan Lekic wrote:

 On Tuesday, 22 May 2012 at 10:03:36 UTC, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 My opinion - no.
 Sure, all of them can be better, provide more fancy features, 
 etc...


+1, Sublime Text, dmd, gtkd.
May 22 2012
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On May 22, 2012, at 10:05 AM, H. S. Teoh wrote:


 On Tue, May 22, 2012 at 09:55:14AM -0700, Sean Kelly wrote:

=20
=20
 It depends on the platform. GDB works fine on Linux, but is pretty
 much broken on OSX. Does Visual Studio work on Windows? Because that
 standalone debugger bundled with DMD is garbage.=20


=20
 People will probably laugh at me, but over the years, I've found that
 well-placed printfs/writelns are much more effective in locating bugs
 than stepping through code with a debugger. Or inserting deliberate
 infinite loops at suspected problem spots and then using kill -11 to =


get

 a stacktrace.


I think a lot of this depends on the type of app.  Interactive debugging =
can be impractical for server apps, but is often easy for desktop apps.  =
Either way, I don't think anyone can say that debugger support isn't =
important for D in general :-)=
May 24 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-24 21:16, Sean Kelly wrote:


 I think a lot of this depends on the type of app.  Interactive debugging can
be impractical for server apps, but is often easy for desktop apps.  Either
way, I don't think anyone can say that debugger support isn't important for D
in general :-)


I think a proper stack trace is more useful in most of the cases for me. 
That's basically the only thing I use a debugger for. D won't show a 
stack trace on a segmentation fault and similar.

-- 
/Jacob Carlborg
May 24 2012
parent reply simendsjo <simendsjo gmail.com> writes:
On Fri, 25 May 2012 08:39:17 +0200, Jacob Carlborg <doob me.com> wrote:


 On 2012-05-24 21:16, Sean Kelly wrote:


 I think a lot of this depends on the type of app.  Interactive  
 debugging can be impractical for server apps, but is often easy for  
 desktop apps.  Either way, I don't think anyone can say that debugger  
 support isn't important for D in general :-)


 I think a proper stack trace is more useful in most of the cases for me.  
 That's basically the only thing I use a debugger for. D won't show a  
 stack trace on a segmentation fault and similar.


No stack trace sucks...

     class C { int a; }
     C c;
     c.a = 1; // --- killed by signal 11
     assert(c); // nice stack trace

Couldn't dmd automatically add an assert(c) in debug mode before accessing  
members?
I would really like to see (easy to use) non-null references. Non-null by  
default would have been best.
May 25 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, May 25, 2012 13:52:05 simendsjo wrote:

 Couldn't dmd automatically add an assert(c) in debug mode before accessing
 members?


That's been argued for ages. Walter is against it, because the OS already 
takes care of it with segfaults. you can either run the program again (which 
isn't necessarily true, but I believe with the programs that he seems to run 
normally, it is, so he's got somewhat of a skewed perspective on that), or if 
you have core dumps enabled, you can just examine the core dump to see what 
happened. Also, adding all of those assertions would also negatively impact 
non-release mode - and possibly by quite a bit, since it would be happening 
all over the place, so there's that to consider.

Regardless, it's a rather devisive subject. I think that _most_ people would 
like to have such assertions added in non-release mode, but since Walter's 
against it, it's never happened.

- Jonathan M Davis
May 25 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 25 May 2012 15:36:54 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Friday, May 25, 2012 13:52:05 simendsjo wrote:

 Couldn't dmd automatically add an assert(c) in debug mode before  
 accessing
 members?


 That's been argued for ages. Walter is against it, because the OS already
 takes care of it with segfaults. you can either run the program again  
 (which
 isn't necessarily true, but I believe with the programs that he seems to  
 run
 normally, it is, so he's got somewhat of a skewed perspective on that),  
 or if
 you have core dumps enabled, you can just examine the core dump to see  
 what
 happened. Also, adding all of those assertions would also negatively  
 impact
 non-release mode - and possibly by quite a bit, since it would be  
 happening
 all over the place, so there's that to consider.

 Regardless, it's a rather devisive subject. I think that _most_ people  
 would
 like to have such assertions added in non-release mode, but since  
 Walter's
 against it, it's never happened.


No, I'd rather have a stack trace printed from the signal handler...

-Steve
May 25 2012
parent simendsjo <simendsjo gmail.com> writes:
On Fri, 25 May 2012 22:00:21 +0200, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Fri, 25 May 2012 15:36:54 -0400, Jonathan M Davis  
 <jmdavisProg gmx.com> wrote:


 On Friday, May 25, 2012 13:52:05 simendsjo wrote:

 Couldn't dmd automatically add an assert(c) in debug mode before  
 accessing
 members?


 That's been argued for ages. Walter is against it, because the OS  
 already
 takes care of it with segfaults.




(...)

 No, I'd rather have a stack trace printed from the signal handler...


I asked about that in learn some time ago, but I seem to remember the  
discussion ended as not enough information is present when the signal  
handler is called or something..?
May 25 2012
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 05/25/12 21:36, Jonathan M Davis wrote:

 On Friday, May 25, 2012 13:52:05 simendsjo wrote:

 Couldn't dmd automatically add an assert(c) in debug mode before accessing
 members?


 
 That's been argued for ages. Walter is against it, because the OS already 
 takes care of it with segfaults. you can either run the program again (which 
 isn't necessarily true, but I believe with the programs that he seems to run 
 normally, it is, so he's got somewhat of a skewed perspective on that), or if 
 you have core dumps enabled, you can just examine the core dump to see what 
 happened. Also, adding all of those assertions would also negatively impact 
 non-release mode - and possibly by quite a bit, since it would be happening 
 all over the place, so there's that to consider.
 
 Regardless, it's a rather devisive subject. I think that _most_ people would 
 like to have such assertions added in non-release mode, but since Walter's 
 against it, it's never happened.


It's bad enough that such check is forced by the compiler in non-release mode
when calling methods. That means you get to choose between not supporting
non-release builds at all, or having an awkward, unnatural API, for no other
reason than this compiler limitation. 
Checking for non-null refs/pointers before accessing members would actually
be less problematic, as dereferencing null is *always* a bug, unlike the
method case, where it can be perfectly fine.
Tuning this behavior on a per-type basis via attributes would be best, but
that's not likely to happen soon, i guess.

artur
May 25 2012
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 24 May 2012 at 19:16:57 UTC, Sean Kelly wrote:

 On May 22, 2012, at 10:05 AM, H. S. Teoh wrote:


 On Tue, May 22, 2012 at 09:55:14AM -0700, Sean Kelly wrote:

 
 
 It depends on the platform. GDB works fine on Linux, but is 
 pretty
 much broken on OSX. Does Visual Studio work on Windows? 
 Because that
 standalone debugger bundled with DMD is garbage.


 
 People will probably laugh at me, but over the years, I've 
 found that
 well-placed printfs/writelns are much more effective in 
 locating bugs
 than stepping through code with a debugger. Or inserting 
 deliberate
 infinite loops at suspected problem spots and then using kill 
 -11 to get
 a stacktrace.


 I think a lot of this depends on the type of app.  Interactive 
 debugging can be impractical for server apps, but is often easy 
 for desktop apps.  Either way, I don't think anyone can say 
 that debugger support isn't important for D in general :-)


I find a debugger as very useful.

For me printf debugging always feel primitive from the time 
debuggers
didn't have nothing more than next/single step.

Now that the debuggers can provide so much visual information for 
data
structure navigation, postmortem debugging and REPL like features 
for
compiled languages, using plain printfs feels like stone age.

--
Paulo
May 25 2012
parent Sean Kelly <sean invisibleduck.org> writes:
On May 25, 2012, at 12:13 AM, "Paulo Pinto" <pjmlp progtools.org> wrote:


 On Thursday, 24 May 2012 at 19:16:57 UTC, Sean Kelly wrote:

 On May 22, 2012, at 10:05 AM, H. S. Teoh wrote:
=20

 On Tue, May 22, 2012 at 09:55:14AM -0700, Sean Kelly wrote:

 It depends on the platform. GDB works fine on Linux, but is pretty
 much broken on OSX. Does Visual Studio work on Windows? Because that
 standalone debugger bundled with DMD is garbage.


 People will probably laugh at me, but over the years, I've found that
 well-placed printfs/writelns are much more effective in locating bugs
 than stepping through code with a debugger. Or inserting deliberate
 infinite loops at suspected problem spots and then using kill -11 to get=







 a stacktrace.


=20
 I think a lot of this depends on the type of app.  Interactive debugging c=




an be impractical for server apps, but is often easy for desktop apps.  Eith=
er way, I don't think anyone can say that debugger support isn't important f=
or D in general :-)

=20
 I find a debugger as very useful.
=20
 For me printf debugging always feel primitive from the time debuggers
 didn't have nothing more than next/single step.
=20
 Now that the debuggers can provide so much visual information for data
 structure navigation, postmortem debugging and REPL like features for
 compiled languages, using plain printfs feels like stone age.


The problem with prints debugging IMO is that if you don't print the right s=
tuff at the right places you need to change the code, rebuild, and hope the b=
ug occurs again. I find that log output combined with a stack trace is typic=
ally enough to find a problem, but just logging isn't always enough. I do li=
ke printf debugging though. Just look at core.demangle :-p=
May 25 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-22 12:03, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


I agree with basically everything in that article.

-- 
/Jacob Carlborg
May 22 2012
parent reply "Roman D. Boiko" <rb d-coding.com> writes:
On Tuesday, 22 May 2012 at 10:59:04 UTC, Jacob Carlborg wrote:

 On 2012-05-22 12:03, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 I agree with basically everything in that article.


I would also appreciate any specific feedback
May 22 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-22 13:21, Roman D. Boiko wrote:

 On Tuesday, 22 May 2012 at 10:59:04 UTC, Jacob Carlborg wrote:

 On 2012-05-22 12:03, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 I agree with basically everything in that article.


 I would also appreciate any specific feedback


* do you think such project is worth the effort?

Yes

* do you feel that D ecosystem lacks tool support?

Yes

* Does this prevent many from using D?

Probably, not me though

* which tools are needed most? Which may be needed, but are not a high 
priority for you?

This is quite hard, that is, how to prioritize. This is my list, in no 
particular order:

* IDE
* Compiler (usable as a library)
* Build tool
* Testing framework
* GUI library
* Tool for automatically create bindings for C/C++/Objective-C
* ABI compatible with Objective-C, i.e. extern(Objective-C)
* Package manager
* Support for iOS

The hard thing is to prioritize. I'm thinking like this:

You need a compiler and an IDE/editor to write any tools. I would like 
and IDE that is just as good as Eclipse JDT. For that to happen we need 
a compiler usable as a library. I'm assuming we want to write as much as 
possible in D so a compiler written in D is necessary. A GUI library 
would be needed as well.

You would also need a build tool and testing framework to write new 
tools. Since we want to have everything as modularized and reusable as 
possible a package manager is also really needed.

If you also want to slap on a GUI on the tools you need a GUI library. 
For Mac OS X it would be a lot easier to be ABI compatible with 
Objective-C to create a GUI library.

For most of these tools, in particular: the build tool, testing 
framework and package manager it would be nice to have the compiler 
usable as a library. This would allow to have build scripts and other 
scripts written in D.

So to summarize:

A lot of the tools needed to be built depends on each other but I think 
most of the tools depend on a compiler, written in D, usable as a library.

* was this post useful? What could I change to make future posts in the 
series better?

Not really for me, nothing I didn't already know.

* should I add commenting on my blog, or dlang forum is better for that?

I prefer commenting here.

-- 
/Jacob Carlborg
May 22 2012
next sibling parent reply "s" <some one.com> writes:
+1 for a GUI lib, which is in sync with DMD releases.


On Tuesday, 22 May 2012 at 12:08:37 UTC, Jacob Carlborg wrote:

 On 2012-05-22 13:21, Roman D. Boiko wrote:

 On Tuesday, 22 May 2012 at 10:59:04 UTC, Jacob Carlborg wrote:

 On 2012-05-22 12:03, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 I agree with basically everything in that article.


 I would also appreciate any specific feedback


 * do you think such project is worth the effort?

 Yes

 * do you feel that D ecosystem lacks tool support?

 Yes

 * Does this prevent many from using D?

 Probably, not me though

 * which tools are needed most? Which may be needed, but are not 
 a high priority for you?

 This is quite hard, that is, how to prioritize. This is my 
 list, in no particular order:

 * IDE
 * Compiler (usable as a library)
 * Build tool
 * Testing framework
 * GUI library
 * Tool for automatically create bindings for C/C++/Objective-C
 * ABI compatible with Objective-C, i.e. extern(Objective-C)
 * Package manager
 * Support for iOS

 The hard thing is to prioritize. I'm thinking like this:

 You need a compiler and an IDE/editor to write any tools. I 
 would like and IDE that is just as good as Eclipse JDT. For 
 that to happen we need a compiler usable as a library. I'm 
 assuming we want to write as much as possible in D so a 
 compiler written in D is necessary. A GUI library would be 
 needed as well.

 You would also need a build tool and testing framework to write 
 new tools. Since we want to have everything as modularized and 
 reusable as possible a package manager is also really needed.

 If you also want to slap on a GUI on the tools you need a GUI 
 library. For Mac OS X it would be a lot easier to be ABI 
 compatible with Objective-C to create a GUI library.

 For most of these tools, in particular: the build tool, testing 
 framework and package manager it would be nice to have the 
 compiler usable as a library. This would allow to have build 
 scripts and other scripts written in D.

 So to summarize:

 A lot of the tools needed to be built depends on each other but 
 I think most of the tools depend on a compiler, written in D, 
 usable as a library.

 * was this post useful? What could I change to make future 
 posts in the series better?

 Not really for me, nothing I didn't already know.

 * should I add commenting on my blog, or dlang forum is better 
 for that?

 I prefer commenting here.
May 22 2012
parent reply Kevin Cox <kevincox.ca gmail.com> writes:
On May 22, 2012 12:13 PM, "s" <some one.com> wrote:

 +1 for a GUI lib, which is in sync with DMD releases.


Is there any way to bind Qt without the dreaded moc and friends?  Because
that would give you a cross platform solution without too much work.
May 22 2012
next sibling parent reply "Roman D. Boiko" <rb d-coding.com> writes:
On Tuesday, 22 May 2012 at 16:23:46 UTC, Kevin Cox wrote:

 On May 22, 2012 12:13 PM, "s" <some one.com> wrote:

 +1 for a GUI lib, which is in sync with DMD releases.


 Is there any way to bind Qt without the dreaded moc and 
 friends?  Because
 that would give you a cross platform solution without too much 
 work.


Well, for cross-platform Gtk+ should be enough, and it has C 
bindings.
May 22 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-22 18:42, Roman D. Boiko wrote:

 On Tuesday, 22 May 2012 at 16:23:46 UTC, Kevin Cox wrote:

 On May 22, 2012 12:13 PM, "s" <some one.com> wrote:

 +1 for a GUI lib, which is in sync with DMD releases.


 Is there any way to bind Qt without the dreaded moc and friends? Because
 that would give you a cross platform solution without too much work.


 Well, for cross-platform Gtk+ should be enough, and it has C bindings.


GTK+ suck at corss-platform, especially on Mac OS X.

-- 
/Jacob Carlborg
May 22 2012
prev sibling next sibling parent "Christian Manning" <cmanning999 gmail.com> writes:
On Tuesday, 22 May 2012 at 16:23:46 UTC, Kevin Cox wrote:

 On May 22, 2012 12:13 PM, "s" <some one.com> wrote:

 +1 for a GUI lib, which is in sync with DMD releases.


 Is there any way to bind Qt without the dreaded moc and 
 friends?  Because
 that would give you a cross platform solution without too much 
 work.


Surely much of the functionality moc provides can be replaced by 
proper D features?
May 22 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 22 May 2012 at 16:23:46 UTC, Kevin Cox wrote:

 On May 22, 2012 12:13 PM, "s" <some one.com> wrote:

 +1 for a GUI lib, which is in sync with DMD releases.


 Is there any way to bind Qt without the dreaded moc and 
 friends?  Because
 that would give you a cross platform solution without too much 
 work.


QtD? It includes a CTFE/template-based substitute for moc.

David
May 22 2012
prev sibling parent reply shd <alienballance gmail.com> writes:
 On Tuesday, 22 May 2012 at 10:59:04 UTC, Jacob Carlborg wrote:


 * do you think such project is worth the effort?

 Yes

 * do you feel that D ecosystem lacks tool support?

 Yes

 * Does this prevent many from using D?

 Probably, not me though

 * which tools are needed most? Which may be needed, but are not a high
 priority for you?

 This is quite hard, that is, how to prioritize. This is my list, in no
 particular order:

 * IDE
 * Compiler (usable as a library)
 * Build tool
 * Testing framework
 * GUI library
 * Tool for automatically create bindings for C/C++/Objective-C
 * ABI compatible with Objective-C, i.e. extern(Objective-C)
 * Package manager
 * Support for iOS


I agree in almost everything what Jacob said.
I would say, that binding generator improvement is even higher than
testing framework though.

Tools are good, but making compiler and library more reliable is crucial thing.

Still, some kind of library which would share (AST or i don't know how
to name that) implementation with compilers front-end is just after
that.
I'm not really sure if that's what you mean (since you mentioned more
high-level features), but without separating some code out from
compiler, different IDEs will rewrite the same code again and again.
And i guess we all agree that single IDE wont satisfy needs of
everyone (of course  there is more uses of library like that than only
IDEs)
May 22 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-22 18:22, shd wrote:


 I agree in almost everything what Jacob said.
 I would say, that binding generator improvement is even higher than
 testing framework though.


Absolutely, I just wrote the list in no particular order. But at the 
same time you need to be able to test the binding generator :)


 Tools are good, but making compiler and library more reliable is crucial thing.


Yeah, it always comes back to the compiler. And preferably it should be 
written in D as a library.


 Still, some kind of library which would share (AST or i don't know how
 to name that) implementation with compilers front-end is just after
 that.
 I'm not really sure if that's what you mean (since you mentioned more
 high-level features), but without separating some code out from
 compiler, different IDEs will rewrite the same code again and again.
 And i guess we all agree that single IDE wont satisfy needs of
 everyone (of course  there is more uses of library like that than only
 IDEs)


That was that I meant. One compiler library every tool can take 
advantage of. The actual compiler should use the library as well, of course.

-- 
/Jacob Carlborg
May 22 2012
prev sibling parent reply "Mikael Lindsten" <mikael lindsten.net> writes:
On Tuesday, 22 May 2012 at 11:21:14 UTC, Roman D. Boiko wrote:

 On Tuesday, 22 May 2012 at 10:59:04 UTC, Jacob Carlborg wrote:

 On 2012-05-22 12:03, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 I agree with basically everything in that article.


 I would also appreciate any specific feedback



I too agree with what you write!

* do you think such project is worth the effort?

Absolutely! A huge undertaking, but if successful, extremely 
valuable for the future of D.

* do you feel that D ecosystem lacks tool support?

I do. I believe the toolset is important for any serious language.

* Does this prevent many from using D?

I definitely think it does! It prevents me from doing anything 
other that simple experiments. I'm an IDE guy - I just won't do 
real work without a good IDE.

* which tools are needed most?

A good IDE is top prio for me, but an IDE should include a lot of 
other tools (compiler, refactoring, debugging, profiling, build 
tool, testing framework etc). Also a GUI library, as others have 
mentioned.

* Which may be needed, but are not a high priority for you?

Don't know. The more tools the better! ;)

* was this post useful?

Not in itself, but the topic is imporant and the DCT is a great 
initiative.

* What could I change to make future posts in the series better?

No comment.

* should I add commenting on my blog, or dlang forum is better 
for that?

dlang is fine.
May 24 2012
parent "Roman D. Boiko" <rb d-coding.com> writes:
On Thursday, 24 May 2012 at 07:55:28 UTC, Mikael Lindsten wrote:

 On Tuesday, 22 May 2012 at 11:21:14 UTC, Roman D. Boiko wrote:

 On Tuesday, 22 May 2012 at 10:59:04 UTC, Jacob Carlborg wrote:

 On 2012-05-22 12:03, Roman D. Boiko wrote:

 http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html


 I agree with basically everything in that article.


 I would also appreciate any specific feedback



 I too agree with what you write!

 * do you think such project is worth the effort?

 Absolutely! A huge undertaking, but if successful, extremely 
 valuable for the future of D.

 * do you feel that D ecosystem lacks tool support?

 I do. I believe the toolset is important for any serious 
 language.

 * Does this prevent many from using D?

 I definitely think it does! It prevents me from doing anything 
 other that simple experiments. I'm an IDE guy - I just won't do 
 real work without a good IDE.

 * which tools are needed most?

 A good IDE is top prio for me, but an IDE should include a lot 
 of other tools (compiler, refactoring, debugging, profiling, 
 build tool, testing framework etc). Also a GUI library, as 
 others have mentioned.

 * Which may be needed, but are not a high priority for you?

 Don't know. The more tools the better! ;)

 * was this post useful?

 Not in itself, but the topic is imporant and the DCT is a great 
 initiative.

 * What could I change to make future posts in the series better?

 No comment.

 * should I add commenting on my blog, or dlang forum is better 
 for that?

 dlang is fine.


Thanks!
May 24 2012