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 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 ? I'd say, just compare to what exists in Java or C# and you'll know that 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 ?

 I'd say, just compare to what exists in Java or C# and you'll know that
 yes, many things are missing.

I completely agree. I forgot about these. -- /Jacob Carlborg
May 22 2012
prev sibling next sibling parent 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 ? I'd say, just compare to what exists in Java or C# and you'll 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.

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
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 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 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 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

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

May 22 2012
prev sibling next 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 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 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 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 next sibling parent "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
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 "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
prev sibling next sibling parent shd <alienballance gmail.com> writes:
 On Tuesday, 22 May 2012 at 10:59:04 UTC, Jacob Carlborg wrote:

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
prev sibling next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
--000e0cdff910cf7fd404c0a270da
Content-Type: text/plain; charset=UTF-8

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. --000e0cdff910cf7fd404c0a270da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p><br> On May 22, 2012 12:13 PM, &quot;s&quot; &lt;<a href=3D"mailto:some one.com"=
some one.com</a>&gt; wrote:<br>

&gt; +1 for a GUI lib, which is in sync with DMD releases.<br> &gt;</p> <p>Is there any way to bind Qt without the dreaded moc and friends?=C2=A0 B= ecause that would give you a cross platform solution without too much work.= </p> --000e0cdff910cf7fd404c0a270da--
May 22 2012
prev sibling next sibling parent "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
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 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=



=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 "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.

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 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 next sibling parent "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
prev sibling next sibling 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
prev sibling next sibling parent 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

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 =

 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling 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.

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 c=


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 next sibling parent "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 ? I'd say, just compare to what exists in Java or C# and you'll 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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent 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
prev sibling 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