www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Who here actually uses D?

reply Robert Clipsham <robert octarineparrot.com> writes:
Having seen a post by Peter Alexander (in Re: D for game development), 
mentioning some of the issues he's hit I thought I'd post this. I've 
been in his shoes (every other time I use D it seems), and feel I should 
ask - who here uses D, and to what extent?

I'm mostly interested in those of you with 1000 Line plus projects in D, 
as that's when I've found I start hitting issues.

Just to clarify, for those D purists among you... I'm not trolling, just 
curious (I wouldn't normally have asked, but now I know I'm not paranoid 
and the only one having problems, I thought I'd ask).

-- 
Robert
http://octarineparrot.com/
Jan 01 2011
next sibling parent Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 1/1/2011 5:22 PM, Robert Clipsham wrote:

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


I've used D for the last 5 years.  My hobby, for-fun-and-not-profit game 
engine, Yage, is about 15-20Kloc.

It's D1+Tango.  I've only spent a very small amount of time with D2 but 
hope to migrate eventually.
Jan 01 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/1/11 4:22 PM, Robert Clipsham wrote:

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


I've done my doctoral work in D, which was a pretty large project for 
one person (I guess a few tens of KLOC).

I've also hit unpleasant bugs on occasion as those you mention - it's 
very jarring. I wonder how we could improve the process to give special 
priority to issues that (a) waste a lot of time tracking down, and (b) 
have no or difficult workarounds.


Andrei
Jan 01 2011
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 01/01/11 22:48, Andrei Alexandrescu wrote:

 I've done my doctoral work in D, which was a pretty large project for
 one person (I guess a few tens of KLOC).

 I've also hit unpleasant bugs on occasion as those you mention - it's
 very jarring. I wonder how we could improve the process to give special
 priority to issues that (a) waste a lot of time tracking down, and (b)
 have no or difficult workarounds.


Unfortunately, it's impossible to create such a system without people 
being paid to work on dmd and the runtime - people will fix the bugs 
they want to, you can't make them fix anything. Obviously you can 
influence what gets fixed, not to a huge extent though. Ideally the 
voting system would outline what needs the most effort, but people don't 
idle on bugzilla enough for it to work so well. I wonder if changing the 
'vote' button to a 'like' button would make any difference, if 
facebook's any indication, people like to like things ;p


 Andrei


I guess I should probably apologise if I sounded hot-headed at all in my 
post too - just had a rather stressful evening battling with compiler 
bugs - one of those ones that seems to morph into about 3 or 4 other 
bugs as you narrow it down, and each compiler you try yields a 
completely different result at the end of it. I decided to give up, 
rant, relax, and leave it for another day!

-- 
Robert
http://octarineparrot.com/
Jan 01 2011
parent reply Caligo <iteronvexor gmail.com> writes:
On Sat, Jan 1, 2011 at 6:14 PM, Robert Clipsham
<robert octarineparrot.com>wrote:


 On 01/01/11 22:48, Andrei Alexandrescu wrote:


 I've done my doctoral work in D, which was a pretty large project for
 one person (I guess a few tens of KLOC).

 I've also hit unpleasant bugs on occasion as those you mention - it's
 very jarring. I wonder how we could improve the process to give special
 priority to issues that (a) waste a lot of time tracking down, and (b)
 have no or difficult workarounds.


 Unfortunately, it's impossible to create such a system without people being
 paid to work on dmd and the runtime - people will fix the bugs they want to,
 you can't make them fix anything. Obviously you can influence what gets
 fixed, not to a huge extent though. Ideally the voting system would outline
 what needs the most effort, but people don't idle on bugzilla enough for it
 to work so well. I wonder if changing the 'vote' button to a 'like' button
 would make any difference, if facebook's any indication, people like to like
 things ;p

  Andrei


 I guess I should probably apologise if I sounded hot-headed at all in my
 post too - just had a rather stressful evening battling with compiler bugs -
 one of those ones that seems to morph into about 3 or 4 other bugs as you
 narrow it down, and each compiler you try yields a completely different
 result at the end of it. I decided to give up, rant, relax, and leave it for
 another day!

 --
 Robert
 http://octarineparrot.com/


I don't understand why so much time and effort as been spent, perhaps
wasted, on multiple compilers and standard libraries.  I also don't
understand why Walter insists on having his own compiler when D has finally
been declared an open source project.  LLVM and GCC are very mature projects
and they could have been used for the reference implementation.  If Walter
was in charge of the GDC or LDC project, then we would have had a better
compiler than what we have today.  That way I think D as a new modern
programming language could have been in a much better position.  You also
don't need to pay people to fix bugs or do whatever that is needed to be
done so long as you have a healthy and growing open source community.  I
don't think we have that yet, and perhaps the fact that Walter comes from
the closed-source proprietary world is part of the reason.

I highly recommend The Cathedral and the Bazaar by Eric Raymond:
http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

That's just me and I could be wrong.



 Jan 01 2011



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Caligo wrote:

 I don't understand why so much time and effort as been spent, perhaps 
 wasted, on multiple compilers and standard libraries.  I also don't 
 understand why Walter insists on having his own compiler when D has 
 finally been declared an open source project.  LLVM and GCC are very 
 mature projects and they could have been used for the reference 
 implementation.  If Walter was in charge of the GDC or LDC project, then 
 we would have had a better compiler than what we have today.  That way I 
 think D as a new modern programming language could have been in a much 
 better position.  You also don't need to pay people to fix bugs or do 
 whatever that is needed to be done so long as you have a healthy and 
 growing open source community.  I don't think we have that yet, and 
 perhaps the fact that Walter comes from the closed-source proprietary 
 world is part of the reason.


The problems D has had have rarely been the back end.



 Jan 01 2011



 next sibling parent reply Peter Alexander <peter.alexander.au gmail.com>  writes:


On 2/01/11 2:01 AM, Walter Bright wrote:

 Caligo wrote:

 I don't understand why so much time and effort as been spent, perhaps
 wasted, on multiple compilers and standard libraries. I also don't
 understand why Walter insists on having his own compiler when D has
 finally been declared an open source project. LLVM and GCC are very
 mature projects and they could have been used for the reference
 implementation. If Walter was in charge of the GDC or LDC project,
 then we would have had a better compiler than what we have today. That
 way I think D as a new modern programming language could have been in
 a much better position. You also don't need to pay people to fix bugs
 or do whatever that is needed to be done so long as you have a healthy
 and growing open source community. I don't think we have that yet, and
 perhaps the fact that Walter comes from the closed-source proprietary
 world is part of the reason.


 The problems D has had have rarely been the back end.


I don't use Windows personally, but OPTLINK seems to still be quite a 
major cause of pain, with the crashes (http://h3.gd/devlog/?p=31) and 
OMF format that no one uses.

Again, I don't experience this, I'm just going by what others have said. 
Seems to be a common complaint.



 Jan 01 2011



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Peter Alexander wrote:

 I don't use Windows personally, but OPTLINK seems to still be quite a 
 major cause of pain, with the crashes (http://h3.gd/devlog/?p=31) and 
 OMF format that no one uses.


As the link says, that problem was fixed.



 Jan 01 2011



  parent  Peter Alexander <peter.alexander.au gmail.com>  writes:


On 2/01/11 3:59 AM, Walter Bright wrote:

 Peter Alexander wrote:

 I don't use Windows personally, but OPTLINK seems to still be quite a
 major cause of pain, with the crashes (http://h3.gd/devlog/?p=31) and
 OMF format that no one uses.


 As the link says, that problem was fixed.


Well, the link says that it was fixed, but then Tomasz got the crash 
again (according to his blog post). Now he has completely given up on D 
and he was one of the most active D developers out there.



 Jan 02 2011



prev sibling next sibling parent reply Caligo <iteronvexor gmail.com>  writes:


On Sat, Jan 1, 2011 at 8:01 PM, Walter Bright <newshound2 digitalmars.com>wrote:


 Caligo wrote:


 I don't understand why so much time and effort as been spent, perhaps
 wasted, on multiple compilers and standard libraries.  I also don't
 understand why Walter insists on having his own compiler when D has finally
 been declared an open source project.  LLVM and GCC are very mature projects
 and they could have been used for the reference implementation.  If Walter
 was in charge of the GDC or LDC project, then we would have had a better
 compiler than what we have today.  That way I think D as a new modern
 programming language could have been in a much better position.  You also
 don't need to pay people to fix bugs or do whatever that is needed to be
 done so long as you have a healthy and growing open source community.  I
 don't think we have that yet, and perhaps the fact that Walter comes from
 the closed-source proprietary world is part of the reason.


 The problems D has had have rarely been the back end.


You don't get it!  If only one back-end was used then there wouldn't be
three different groups working on three different projects that try to
accomplish the same thing.

Also, whenever there is a failure in communication, you end up with forked
projects, hence Tango.



 Jan 01 2011



 next sibling parent  Peter Alexander <peter.alexander.au gmail.com>  writes:


On 2/01/11 2:18 AM, Caligo wrote:

 You don't get it!  If only one back-end was used then there wouldn't be
 three different groups working on three different projects that try to
 accomplish the same thing.


That's not true. If it were then we wouldn't have both GDC and LDC, as 
they would combine their efforts as suggested by your theory.

Also, people are free to support the DMD front-end, so we could still in 
theory have everyone on the same project (except only Walter could 
modify the back end, which is supposedly relatively bug free).



 Jan 01 2011



prev sibling next sibling parent  Robert Clipsham <robert octarineparrot.com>  writes:


On 02/01/11 02:18, Caligo wrote:

 On Sat, Jan 1, 2011 at 8:01 PM, Walter Bright
 <newshound2 digitalmars.com <mailto:newshound2 digitalmars.com>> wrote:

     Caligo wrote:

         I don't understand why so much time and effort as been spent,
         perhaps wasted, on multiple compilers and standard libraries.  I
         also don't understand why Walter insists on having his own
         compiler when D has finally been declared an open source
         project.  LLVM and GCC are very mature projects and they could
         have been used for the reference implementation.  If Walter was
         in charge of the GDC or LDC project, then we would have had a
         better compiler than what we have today.  That way I think D as
         a new modern programming language could have been in a much
         better position.  You also don't need to pay people to fix bugs
         or do whatever that is needed to be done so long as you have a
         healthy and growing open source community.  I don't think we
         have that yet, and perhaps the fact that Walter comes from the
         closed-source proprietary world is part of the reason.


     The problems D has had have rarely been the back end.


 You don't get it!  If only one back-end was used then there wouldn't be
 three different groups working on three different projects that try to
 accomplish the same thing.


Here's a great idea, why don't we make Walter spend a fortune on lawyers 
so he can work with LLVM or GCC without worrying about being sued, then 
let's get him to learn how all those thousands of lines of code work! 
That's definitely the best thing for D, it won't slow down its 
development at all.</sarcasm>

You complain about dmd not being open source enough, then say having 3 
compilers is a bad thing - that's how open source works! You get to 
choose what you work on, things will be buggy featureless and slow, that 
motivates the competition more, things progress, suddenly you've got 3 
mediocre compilers instead of 3 terrible ones. Sure, it's not so 
instantanious, you get my point though?


 Also, whenever there is a failure in communication, you end up with
 forked projects, hence Tango.


See above - if anything forks are better than seperate projects. Things 
can be merged back if they're good, people get a choice, everything can 
progress both on its own and with the rest of everything - github and 
bitbucket know this and make it simple to do.

-- 
Robert
http://octarineparrot.com/



 Jan 01 2011



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Caligo wrote:

 You don't get it!  If only one back-end was used then there wouldn't be 
 three different groups working on three different projects that try to 
 accomplish the same thing. 


Back when there was only one D compiler, people complained there was only one. 
They needed more to feel comfortable using it. Now that there are three, the 
complaints switch 180 degrees.



 Jan 01 2011



  parent reply Daniel Gibson <metalcaedes gmail.com>  writes:


Am 02.01.2011 05:00, schrieb Walter Bright:

 Caligo wrote:

 You don't get it! If only one back-end was used then there wouldn't be
 three different groups working on three different projects that try to
 accomplish the same thing.


 Back when there was only one D compiler, people complained there was
 only one. They needed more to feel comfortable using it. Now that there
 are three, the complaints switch 180 degrees.


It's just different (kinds of) people complaining ;-)
I guess most people (and especially people who have to decide whether to 
use D in a major project) appreciate the availability of multiple compilers.



 Jan 03 2011



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Daniel Gibson wrote:

 It's just different (kinds of) people complaining ;-)
 I guess most people (and especially people who have to decide whether to 
 use D in a major project) appreciate the availability of multiple 
 compilers.


I think multiple compilers is a very good thing for D.



 Jan 03 2011



  parent reply Robert Clipsham <robert octarineparrot.com>  writes:


On 03/01/11 21:39, Walter Bright wrote:

 I think multiple compilers is a very good thing for D.


I agree, when I hit a bug in one it's nice to be able to use another 
before resorting to compiler hacking instead of working on my own code, 
it's working out far nicer for me! Shame I'm currently at a point where 
none of the compilers want to make my app act the same at runtime (this 
only seems happens at a certain point in the evening, perhaps I should 
only code earlier/later in the day ;p)...

-- 
Robert
http://octarineparrot.com/



 Jan 03 2011



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Robert Clipsham wrote:

 Shame I'm currently at a point where 
 none of the compilers want to make my app act the same at runtime (this 
 only seems happens at a certain point in the evening, perhaps I should 
 only code earlier/later in the day ;p)...


I learned long ago not to attempt to write code past a certain level of 
tiredness. If I do, I always have to completely throw that work away and start
over.



 Jan 03 2011



prev sibling  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 03/01/2011 20:53, Daniel Gibson wrote:

 Am 02.01.2011 05:00, schrieb Walter Bright:

 Caligo wrote:

 You don't get it! If only one back-end was used then there wouldn't be
 three different groups working on three different projects that try to
 accomplish the same thing.


 Back when there was only one D compiler, people complained there was
 only one. They needed more to feel comfortable using it. Now that there
 are three, the complaints switch 180 degrees.


 It's just different (kinds of) people complaining ;-)


Indeed. But also, and in all fairness, I think some of the people that 
complained there was only one compiler, had in mind the desire to have a 
*different* implementation of a D compiler (this would be helpful, for 
example, to validate the "specification" of the D language). But that is 
not what we have, all current three compilers are based on DMD.

(note: I'm not implying having more compiler implementations is an 
important thing right now, or in the near future)


-- 
Bruno Medeiros - Software Engineer



 Feb 01 2011



prev sibling next sibling parent reply David Nadlinger <see klickverbot.at>  writes:


On 1/2/11 3:01 AM, Walter Bright wrote:

 The problems D has had have rarely been the back end.


Might I respectfully disagree here? The fact that DMD is emitting OMF on 
Windows has indeed been a major annoyance for me, especially back when I 
was new to D, and I suspect that many other people new to D might have 
felt the same. Even more so since on Windows there are virtually no 
alternatives to OPTLINK with its occasional bugs (yes, even though I 
develop mostly on Linux and, more recently, OS X, I hit an OPTLINK bug 
more than just once).

On a side note: My little software rasterizer was apparently one of the 
rare cases where LLVM and GCC generate significantly faster code 
(typically about 10x times faster in terms of frame time, if I remember 
correctly) than DMD, but I agree that a software renderer certainly does 
not qualify as common case.

No offense intended,
David



 Jan 01 2011



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


David Nadlinger wrote:

 Might I respectfully disagree here? The fact that DMD is emitting OMF on 
 Windows has indeed been a major annoyance for me, especially back when I 
 was new to D, and I suspect that many other people new to D might have 
 felt the same. Even more so since on Windows there are virtually no 
 alternatives to OPTLINK with its occasional bugs (yes, even though I 
 develop mostly on Linux and, more recently, OS X, I hit an OPTLINK bug 
 more than just once).


The optlink situation has gotten better, but it has a couple more issues I want 
to fix.



 On a side note: My little software rasterizer was apparently one of the 
 rare cases where LLVM and GCC generate significantly faster code 
 (typically about 10x times faster in terms of frame time, if I remember 
 correctly) than DMD, but I agree that a software renderer certainly does 
 not qualify as common case.


dmd does not use the xmm registers for floating point, so its performance tends 
to be worse on that for later CPUs.



 Jan 01 2011



  parent reply Eric Poggel <dnewsgroup2 yage3d.net>  writes:


On 1/1/2011 11:56 PM, Walter Bright wrote:

 dmd does not use the xmm registers for floating point, so its
 performance tends to be worse on that for later CPUs.


Granted, this should be lower priority than bug fixes, but out of 
curiosity, is this something that's hard to fix?  I see it come up 
frequently in the benchmark-related posts here.



 Jan 02 2011



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Eric Poggel wrote:

 On 1/1/2011 11:56 PM, Walter Bright wrote:

 dmd does not use the xmm registers for floating point, so its
 performance tends to be worse on that for later CPUs.


 
 Granted, this should be lower priority than bug fixes, but out of 
 curiosity, is this something that's hard to fix?  I see it come up 
 frequently in the benchmark-related posts here.


It requires a bunch of new code to be written.



 Jan 02 2011



prev sibling  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 02/01/2011 02:01, Walter Bright wrote:

 Caligo wrote:

 I don't understand why so much time and effort as been spent, perhaps
 wasted, on multiple compilers and standard libraries. I also don't
 understand why Walter insists on having his own compiler when D has
 finally been declared an open source project. LLVM and GCC are very
 mature projects and they could have been used for the reference
 implementation. If Walter was in charge of the GDC or LDC project,
 then we would have had a better compiler than what we have today. That
 way I think D as a new modern programming language could have been in
 a much better position. You also don't need to pay people to fix bugs
 or do whatever that is needed to be done so long as you have a healthy
 and growing open source community. I don't think we have that yet, and
 perhaps the fact that Walter comes from the closed-source proprietary
 world is part of the reason.


 The problems D has had have rarely been the back end.


Putting aside issues with bugs (not that they are not important), the 
choice of backend also has important consequences regarding what 
debugger tools one can use (at least on Windows).

-- 
Bruno Medeiros - Software Engineer



 Jan 28 2011



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"Caligo" <iteronvexor gmail.com> wrote in message 
news:mailman.342.1293933425.4748.digitalmars-d puremagic.com...

 I don't understand why so much time and effort as been spent, perhaps
 wasted, on multiple compilers and standard libraries.  I also don't
 understand why Walter insists on having his own compiler when D has 
 finally
 been declared an open source project.  LLVM and GCC are very mature 
 projects
 and they could have been used for the reference implementation.  If Walter
 was in charge of the GDC or LDC project, then we would have had a better
 compiler than what we have today.  That way I think D as a new modern
 programming language could have been in a much better position.  You also
 don't need to pay people to fix bugs or do whatever that is needed to be
 done so long as you have a healthy and growing open source community.  I
 don't think we have that yet, and perhaps the fact that Walter comes from
 the closed-source proprietary world is part of the reason.


GCC is a PITA to deal with, and LLVM is useless on Windows.



 Jan 01 2011



prev sibling next sibling parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com>  writes:


Hi,

I'm using D (D1,LDC+Tango) both professionally and for hobby-projects.

At work, I'm using it mainly for an in-house developed all-purpose
Mpeg2-TS processing library. (Records, streams, analyzes and clips
Mpeg2 Transport Streams). All-in all, it's working out fine. I've hit

Multicast on Linux), but no LDC-bugs here.

As a hobby, I'm developing a content-distribution-system at
www.bithorde.org. Here I've hit one LDC-bug AFAIR, and a few
Tango-bugs, in general problems with immaturity in the D ecosystem has
been more of a frustration. Not only the pure bug-frustrations, but
using libraries that turned out to be incompatible regarding the
Tango/Phobos-problems, missing documentation, some frustrated
community members, using libraries that turns out to be unsupported.
All in all, general problems related to uncharted territory.

My solution in both cases, since I use Ubuntu as the workstation both
at home and at work, have been to fork slightly old versions of Tango
and LDC and manually applied just the patches that looks safe, and
useful to me, instead of tracking the tips of either project. I've
then created a PPA at
https://launchpad.net/~rawler/+archive/d-packaging. It's worked
acceptably, although quite some hours have went into this of course.

All-in-all, I would rate my D-experience as a 3/5, not unacceptable,
but not reaching it's full potential either.

I still believe D has a lot of potential though, which is why I'm
sticking with it even when upfront-costs are a bit high. I.E. I'm
currently side-tracked working on developing and documenting a simple
safe Reference-Counting framework that might hopefully be included in
Tango and Druntime, instead of realizing my own ambitions of BitHorde.

/ Ulrik

2011/1/1 Robert Clipsham <robert octarineparrot.com>:

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've been in
 his shoes (every other time I use D it seems), and feel I should ask - who
 here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D, as
 that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid and
 the only one having problems, I thought I'd ask).

 --
 Robert
 http://octarineparrot.com/





 Jan 01 2011



  parent reply Robert Clipsham <robert octarineparrot.com>  writes:


On 01/01/11 22:53, Ulrik Mikaelsson wrote:

 All-in-all, I would rate my D-experience as a 3/5, not unacceptable,
 but not reaching it's full potential either.


I'm not sure I could rate my D experience with a single number, I'd 
probably have to plot it on an experience/time graph - guess it'd look 
somewhat like y=sin(x)+n, where n is just enough to tip me over the edge 
onto continued use of D, despite all the annoyances...


 I still believe D has a lot of potential though, which is why I'm
 sticking with it even when upfront-costs are a bit high. I.E. I'm
 currently side-tracked working on developing and documenting a simple
 safe Reference-Counting framework that might hopefully be included in
 Tango and Druntime, instead of realizing my own ambitions of BitHorde.


I've been using D for a good few years - and I have that same opinion - 
it has a lot of potential. In those years I'm yet to have seen that 
potential being released though. Wonder what's missing there.

As for realising your own ambitions - I'm finding myself in a similar 
situation - the more I try and work on my project, the more I find 
myself not working on it as I try and improve the toolchain/work out 
bugs. It gets rather stressful at times, guess it introduces some 
variation into what I'm doing though. What it does mean is I spend a lot 
of time using C++ rather than D though...


 / Ulrik


-- 
Robert
http://octarineparrot.com/



 Jan 01 2011



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/1/11 6:22 PM, Robert Clipsham wrote:

 On 01/01/11 22:53, Ulrik Mikaelsson wrote:

 All-in-all, I would rate my D-experience as a 3/5, not unacceptable,
 but not reaching it's full potential either.


 I'm not sure I could rate my D experience with a single number, I'd
 probably have to plot it on an experience/time graph - guess it'd look
 somewhat like y=sin(x)+n, where n is just enough to tip me over the edge
 onto continued use of D, despite all the annoyances...


 I still believe D has a lot of potential though, which is why I'm
 sticking with it even when upfront-costs are a bit high. I.E. I'm
 currently side-tracked working on developing and documenting a simple
 safe Reference-Counting framework that might hopefully be included in
 Tango and Druntime, instead of realizing my own ambitions of BitHorde.


 I've been using D for a good few years - and I have that same opinion -
 it has a lot of potential. In those years I'm yet to have seen that
 potential being released though. Wonder what's missing there.

 As for realising your own ambitions - I'm finding myself in a similar
 situation - the more I try and work on my project, the more I find
 myself not working on it as I try and improve the toolchain/work out
 bugs. It gets rather stressful at times, guess it introduces some
 variation into what I'm doing though. What it does mean is I spend a lot
 of time using C++ rather than D though...


Things are definitely improving. For example, I see there's some 
reminiscing about Variant. It was the first major Phobos component I 
wrote, and I remember when I was done I couldn't believe it the whole 
house of cards was standing together; I had to work little miracles 
around various compiler bugs.

The language has moved at a breakneck pace until this summer. Clearly 
there has been a change of phase since: no major features are being 
added and the focus has shifted on consolidating the implementation of 
what I believe is a very compelling design. The one thing that dampens 
progress on front-end quality is the 64 bit port, which is much slower 
than predicted. Even so, the recent releases have fixed an impressive 
number of bugs.

We also have a much extended library team. So I have good reasons to 
think that things are on a good course.


Andrei



 Jan 01 2011



prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


I use it every day, full time, and have for almost a year now,
and did for several years before that in hobby time.

My web app for work is about 20,000 lines. My (still incomplete)
personal D gui project is ~10,000 lines. I've written about another
12,000 lines of shared library code, and done some hobby games,
the three largest ones being 8000, 3000, and 2000 lines.

The games are written in D1, everything else is D2. These counts
come by doing wc *.d in the project directories, so they'd include
empty lines; it's an over-count surely.


But nevertheless, it's quite a bit of D code! And I find the bugs
people complain about to be incredibly rare; I've hit two or three
really annoying ones over the years, but that's not too bad. (one
is trivial to work around, one was only on Windows and was fixed
last year, and the third sticks around... regular usage of
opDispatch and opCall is good. Getting fancy and mixing it with
other stuff isn't quite ideal yet. But it's still usable. And hell
good but not perfect opDispatch still beats no opDispatch!)



 Jan 01 2011



  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday 01 January 2011 14:58:57 Adam D. Ruppe wrote:

 I use it every day, full time, and have for almost a year now,
 and did for several years before that in hobby time.
 
 My web app for work is about 20,000 lines. My (still incomplete)
 personal D gui project is ~10,000 lines. I've written about another
 12,000 lines of shared library code, and done some hobby games,
 the three largest ones being 8000, 3000, and 2000 lines.
 
 The games are written in D1, everything else is D2. These counts
 come by doing wc *.d in the project directories, so they'd include
 empty lines; it's an over-count surely.
 
 
 But nevertheless, it's quite a bit of D code! And I find the bugs
 people complain about to be incredibly rare; I've hit two or three
 really annoying ones over the years, but that's not too bad. (one
 is trivial to work around, one was only on Windows and was fixed
 last year, and the third sticks around... regular usage of
 opDispatch and opCall is good. Getting fancy and mixing it with
 other stuff isn't quite ideal yet. But it's still usable. And hell
 good but not perfect opDispatch still beats no opDispatch!)


I think that the fact that you've run into so few major bugs is very telling of 
which D2 features you use. As was discussed in another thread, you're fairly 
conservative in the D2-specific stuff that you use. Others of us who use D2-
specific stuff quite heavily run into serious bugs much more frequently. 
Personally, I use stuff like const, pure, and contracts heavily, and when you
do 
that, you run into problems fairly quickly.

- Jonathan M Davis



 Jan 01 2011



 next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Jonathan M Davis wrote:

 As was discussed in another thread, you're fairly
 conservative in the D2-specific stuff that you use.


Indeed. Though I've gone into the fancy stuff, I don't go
wild with it, which probably helps too. It seems the worst
bugs come from combinations of new-to-D2 features more than
any one individually.

For example, today I decided to play with adding more javascript
support to my html helpers. Properties work fine on their own.
opDispatch works fine on its own. Generic templates work well.
But mix them together and things that probably should work start
giving errors.

Nevertheless, scaling back on the ambition worked around it. I
ideally wanted

js.test = "hello";
js.alert(js.test);
js.test = 10;

To just work (that is, output a string
`test = "hello"; alert(test); test = 10;`
).

That didn't work, the property opDispatch and call opDispatch
screwed each other over. And the property opDispatch could take
a string, but not a templated argument, making it less than
ideal. It wouldn't overload opDispatch()(string) with ()(int) either. Bah. I'm
pretty sure all of that is supposed to work;
each piece does work, if I take the others out of the class.


But the thing did start working by introducing more objects
to keep any individual feature from mixing too much:

// the vars helper object has its own opDispatch for properties
js.vars.test = "hello";
js.alert(js.vars.test);
// the vars returns a Variable struct with a set helper template
// so it works with more than just strings
js.vars.test.set(10);

That produces the correct output, but it is a more roundabout
way of getting there. It keeps the features from intermingling
too much and hitting unimplemented or buggy interactions.



But I'm ok with it. D has always been able to do any job I throw
at it one way or another.



 Jan 01 2011



  parent reply Robert Clipsham <robert octarineparrot.com>  writes:


On 01/01/11 23:51, Adam D. Ruppe wrote:

 Jonathan M Davis wrote:

 As was discussed in another thread, you're fairly
 conservative in the D2-specific stuff that you use.


 Indeed. Though I've gone into the fancy stuff, I don't go
 wild with it, which probably helps too. It seems the worst
 bugs come from combinations of new-to-D2 features more than
 any one individually.


Maybe this is where I'm going wrong - if a feature's there, I feel I 
have to use it! It's like being confronted with a buffet, I can't stop 
eating! Even with D1 I find myself biting off more than I can chew so to 
speak.


 That didn't work, the property opDispatch and call opDispatch
 screwed each other over. And the property opDispatch could take
 a string, but not a templated argument, making it less than
 ideal. It wouldn't overload opDispatch()(string) with ()(int) either. Bah. I'm
 pretty sure all of that is supposed to work;
 each piece does work, if I take the others out of the class.


I hit the exact same issue recently but in D1 - seems templated methods 
don't like being overloaded. In this situation couldn't you use 
opDispatch(T:string)(T) and opDispatch(T:int)(T)? I'd guess not, but I 
don't know how opDispatch works, or what your code looks like!

-- 
Robert
http://octarineparrot.com/



 Jan 01 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Robert Clipsham wrote:

 I hit the exact same issue recently but in D1 - seems templated
 methods don't like being overloaded.


Yeah. Usually it's not a big deal, since you can just handle
it inside the template very easily (often moreso than a traditional
overload even, thanks to static if) but there's times when that
can't work either.


 In this situation couldn't you use
 opDispatch(T:string)(T) and opDispatch(T:int)(T)?
 I'd guess not, but I don't know how opDispatch works, or what
 your code looks like!


That, specifically, won't work for opDispatch because it needs
to have at least a string argument:

===
struct A {
    void opDispatch(string field)(string argument = null) {
           writeln(field, "=", argument);
    }
}

void main() {
    A a;

    a.field1; // calls a.opDispatch!("field1")();
    a.field2 = "whoa"; // yay property. a.opDispatch!("field2")("whoa");
}
===

Cool. But, what if you want to do a.field = 10;? That is, pass
an int instead of a string?

Now, it will work if you do:

===
    string opDispatch(string field, T)(T t) {
            // blah blah
    }

    A a;
    a.field1(10);
    a.field1("hello");
===

And you can specialize T however you want. But, take that same
code and write

auto whatever = a.field1;
a.field1 = "hello";
a.field2 = 10;

And things start to break down. The getter doesn't work because
it doesn't match the template definition. The setters I believe
do work here though. (I'm not compiling as I go, so I might be
forgetting something)

So you want the getter to work. Before it worked due to a
default argument. What if we overload the template for zero
arguments or one argument?

string opDispatch(string field)() {} // getter
string opDispatch(string field, T)(T t) {} // setter


At this point, you'd expect it all to work. The getter compiles...
but the setter then fails because it "matches multiple template
definitions". Uh, no it doesn't, but the compiler apparently
looked at the property, rewrote the first part to opDispatch,
and then gave up before getting into the actual arguments being
passed in.

(My actual code used T... because I'd like to be able to handle:

val = a.field;
a.field = val;
a.field(val);
a.field(val, arg2);

all with one class. But I'm pretty sure the plain T argument
did the same thing.


well together since once the property sugar is stripped off,
they are the same. If we could overload  property and regular
function, it would work, but that doesn't work today.


above.

So for today's little project, since each one works individually,
I just broke them down into separate functions and helper objects.
It no longer mimics Javascript as exactly as I'd like here, but
it does work.

I've previously tried to do all this with a dmdscript port too.
There, the problem I hit was templating opDispatch with a
recursive object:

MyObject obj;
MyObject obj2 = obj.field; // works
obj.field = "hello"; // works
obj2.field2; // works
obj2.field2 = obj.field; // works

obj.field.field2; // works
obj.field.field2 = "hello"; // fails, despite the fact we saw each
     //part working independently above. It complains about
     // the returned type not matching or something weird; I tried
     // this months ago and don't remember all the specifics.
)



But, oh well, I can live without the combination anyway. It's
more of a novelty than anything else to me anyway. (It'll be cool
to say "yeah we can basically write full javascript from inside
D" some day, but I doubt I'd actually put it to serious use.)



 Jan 01 2011



  parent  Adam D. Ruppe <destructionator gmail.com>  writes:


I wrote:

 (It'll be cool
 to say "yeah we can basically write full javascript from inside
 D" some day, but I doubt I'd actually put it to serious use.)


Oh my god, I almost did it. It took all bleeding day, but this
thing compiles and runs:

// skipping some boring stuff...
	auto js = new ClientSideScript(document);

	js.innerCode = {
		js.funclol = "10";    // parens are (currently) required when setting
		js.funclol = 10;      // works with a variety of basic types
		js.funclol = 10.4;
		js.funclol = js.rofl; // can also set to another js variable
		js.setVariable("name", [10, 20]); // try setVariable for complex types
		js.setVariable("name", 100); // it can also set with strings for names
		js.alert(js.funclol, dInt); // call functions with js and D arguments
		js.funclol().call;       // to call without arguments, use the call method.
This
is a needed compromise to also support getters
		js.funclol(10);        // calling with arguments looks normal
		js.funclol(10, "20");  // including multiple, varied arguments
		js.myelement = ele;    // works with DOM references too
		js.a = js.b + js.c;    // some operators work too
	};

      write(js.toString);




That D, when run, outputs this:
<script>
        funclol = "10";
        funclol = 10;
        funclol = 10.4;
        funclol = rofl;
        name = [10,20];
        name = 100;
        alert(funclol, 50);
        funclol();
        funclol(10);
        funclol(10, "20");
        myelement = document.getElementById("javascript-referenced-element-1");
        a = b+c;
</script>


It's just what the D did. But that D was so close to the javascript
itself that it was able to output the code without needing special
functions.

Naturally, reading a JS variable is impossible (perhaps unless
it is already set here - that's what the repository is for). They
have type of either Variable or Source though, so if you
accidentially tried to use one, you wouldn't get far.

Anyway:

The way it works is innerCode takes a delegate. It then sets the
js object to record mode and runs the delegate, then returns
to normal mode.

When in record mode, the js methods write their arguments to
strings and append them to a variable in a stack (so nested
innerCodes should, in theory, work).


That was the easy part. The hard thing was getting rid of the
vars helper object from the call site. I got an acceptable
compromise by doing opDispatch(string name, T...)(T t) if (T.length != 0) for
the
function calls, and opDispatch(string name)(...) for
the assignment.

So the variadic template put together an argument list. A traditional
variadic function passes its argument on to an opAssign template
on the Variable object.


The Variable's opBinary simply takes the string op and puts it
between its "names", creating a temporary with a name of the
operation.


D datatypes are passed in and converted to JSON for the assignment.
So Javascript sees a D variable in there as a literal value. My
existing toJsonValue template handled structs and arrays too,
so quite a few D variables could be passed in.


I special cased my DOM.Element class as well. Since client
JS can't actually make use of a D reference, it finds some
common ground - the Element's id attribute. If one is set, it
uses it directly. If not, it generates one and passes that to
the JS.



Conditionals and looping can't be easily translated like this.
If they can't be done server side, the all useful escape hatch
of js.appendSource("code here") will be necessary.





All in all, this is really just a toy, but that technique to
get opDispatch and properties working might be useful elsewhere.
I think it might work to go wild with a Javascript like object
system from inside native D.



Anyway I'm up super late. If you want to see my code, it is
available here:

http://arsdnet.net/dcode/html.d

It depends on this: http://arsdnet.net/dcode/dom.d


(Forgive the ugly code. I originally started this module as
just a collection of useful html transformation functions I wrote
elsewhere and wanted in one place. As you can see, I never actually
did that and went off on this script nonsense instead.

The worst part is having those validation functions in there is
legitimately useful. I'll probably never use this script thing
beyond this toying - simply using plain strings or json is easy
enough and does a decent job already... oh well)



 Jan 01 2011



prev sibling  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Son of a bitch!

$ dmd html.d dom.d
/usr/bin32/dmd: line 3: 32183 Segmentation fault      /lib/ld-linux.so.2
/home/me/d/dmd2/linux/bin/dmd $*


Ironically that I'd hit my first dmd segfault for quite a while
shortly after making a post saying these things are quite rare.

The line at fault:
   vars[name] = source;

context:
Variant[string] vars;
string name, source;

Workaround:
    Variant v = source;
    vars[name] = v;


A trivially easy workaround, but the timing is deliciously ironic.



 Jan 01 2011



 next sibling parent reply Robert Clipsham <robert octarineparrot.com>  writes:


On 02/01/11 00:29, Adam D. Ruppe wrote:

 Son of a bitch!

 $ dmd html.d dom.d
 /usr/bin32/dmd: line 3: 32183 Segmentation fault      /lib/ld-linux.so.2
 /home/me/d/dmd2/linux/bin/dmd $*


 Ironically that I'd hit my first dmd segfault for quite a while
 shortly after making a post saying these things are quite rare.

 The line at fault:
     vars[name] = source;

 context:
 Variant[string] vars;
 string name, source;

 Workaround:
      Variant v = source;
      vars[name] = v;


 A trivially easy workaround, but the timing is deliciously ironic.


Ah sweet irony! Maybe I'm just a bad omen! Don't suppose you've got a 
test case which will reproduce this? It'd be good to report it so it 
doesn't get lost.

-- 
Robert
http://octarineparrot.com/



 Jan 01 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


Robert Clipsham wrote:

 Don't suppose you've got a test case which will reproduce this?


===
import std.variant;

void main() {
	string a, b;
	Variant[string] v;

	v[a] = b;
}
===

I'm almost certain I've seen something similar in the bugzilla
before, but I can't find it now. I find that thing to be
incredibly hard to search.

My DMD is also a release or two behind, so it might already
be fixed. (I only update dmd when I'm a few days ahead on my
work, just in case I have to deal with a regression or breaking
change. While they haven't bothered me for many months now, I
still lag a bit to avoid the risk of breaking my production build
when the schedule is already packed.)



 Jan 01 2011



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/1/11 7:10 PM, Adam D. Ruppe wrote:

 Robert Clipsham wrote:

 Don't suppose you've got a test case which will reproduce this?


 ===
 import std.variant;

 void main() {
 	string a, b;
 	Variant[string] v;

 	v[a] = b;
 }
 ===

 I'm almost certain I've seen something similar in the bugzilla
 before, but I can't find it now. I find that thing to be
 incredibly hard to search.

 My DMD is also a release or two behind, so it might already
 be fixed. (I only update dmd when I'm a few days ahead on my
 work, just in case I have to deal with a regression or breaking
 change. While they haven't bothered me for many months now, I
 still lag a bit to avoid the risk of breaking my production build
 when the schedule is already packed.)


Yah, I remember it too. Just looked for it, couldn't find it because 
searching defaults to unresolved issues. Once you look for resolved ones...

http://d.puremagic.com/issues/show_bug.cgi?id=2451


Andrei



 Jan 01 2011



prev sibling  parent reply Jimmy Cao <jcao219 gmail.com>  writes:


On Sat, Jan 1, 2011 at 7:10 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 Robert Clipsham wrote:

 Don't suppose you've got a test case which will reproduce this?


 ===
 import std.variant;

 void main() {
        string a, b;
        Variant[string] v;

        v[a] = b;
 }
 ===

 I'm almost certain I've seen something similar in the bugzilla
 before, but I can't find it now. I find that thing to be
 incredibly hard to search.

 My DMD is also a release or two behind, so it might already
 be fixed. (I only update dmd when I'm a few days ahead on my
 work, just in case I have to deal with a regression or breaking
 change. While they haven't bothered me for many months now, I
 still lag a bit to avoid the risk of breaking my production build
 when the schedule is already packed.)


No segfault on Fedora 14, DMD 2.051.  Maybe updating will do the trick.



 Jan 01 2011



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/1/11 8:47 PM, Jimmy Cao wrote:

 On Sat, Jan 1, 2011 at 7:10 PM, Adam D. Ruppe <destructionator gmail.com
 <mailto:destructionator gmail.com>> wrote:

     Robert Clipsham wrote:
      > Don't suppose you've got a test case which will reproduce this?

     ===
     import std.variant;

     void main() {
             string a, b;
             Variant[string] v;

             v[a] = b;
     }
     ===

     I'm almost certain I've seen something similar in the bugzilla
     before, but I can't find it now. I find that thing to be
     incredibly hard to search.

     My DMD is also a release or two behind, so it might already
     be fixed. (I only update dmd when I'm a few days ahead on my
     work, just in case I have to deal with a regression or breaking
     change. While they haven't bothered me for many months now, I
     still lag a bit to avoid the risk of breaking my production build
     when the schedule is already packed.)


 No segfault on Fedora 14, DMD 2.051.  Maybe updating will do the trick.


Just verified, it crashes on 2.050 and works with 2.051.

Andrei



 Jan 01 2011



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


 Just verified, it crashes on 2.050 and works with 2.051.


That's awesome. The bugs have been fixed at an insane pace the
last several months. It wasn't long ago that Variant hit so many
bugs it was almost unusable.

It looks like as of this newest release, all those woes are gone.



 Jan 01 2011



  parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


== Quote from Adam D. Ruppe (destructionator gmail.com)'s article

 Just verified, it crashes on 2.050 and works with 2.051.


 That's awesome. The bugs have been fixed at an insane pace the
 last several months. It wasn't long ago that Variant hit so many
 bugs it was almost unusable.
 It looks like as of this newest release, all those woes are gone.


I'd beg to differ... ;)

There are still many issues related to standard C library implementation in
druntime. Silly mistakes that *shouldn't* have happened (std.socket.SocketSet is
broken because FD_ISSET was implemented wrong). Whilst other things have simply
never been correct in the first place (stat_t.sizeof is not equal to the
sizeof(stat) on Linux systems (using eglibc-2,12.1), and the alignment of it's
members is fairly off too. It's rather miraculous it even works on 32bit...
64bit segfaults. :o)



 Jan 01 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ifogsf$20le$1 digitalmars.com...

 Son of a bitch!

 $ dmd html.d dom.d
 /usr/bin32/dmd: line 3: 32183 Segmentation fault      /lib/ld-linux.so.2
 /home/me/d/dmd2/linux/bin/dmd $*


 Ironically that I'd hit my first dmd segfault for quite a while
 shortly after making a post saying these things are quite rare.

 The line at fault:
   vars[name] = source;

 context:
 Variant[string] vars;
 string name, source;

 Workaround:
    Variant v = source;
    vars[name] = v;


 A trivially easy workaround, but the timing is deliciously ironic.


Similar story, but not directly D related:

A few months ago my computer's onboard ethernet stopped working. The 
wonderfully ironic part is that this was no more than a day after I had 
finished one of my "Cranky-Kong"-esque rants defending my use of older 
computers. (The onboard ethernet seems to be working perfectly fine again 
now though. Maybe there was just some dust on the contacts or something.)



 Jan 01 2011



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Nick Sabalausky wrote:

 A few months ago my computer's onboard ethernet stopped working. The 
 wonderfully ironic part is that this was no more than a day after I had 
 finished one of my "Cranky-Kong"-esque rants defending my use of older 
 computers. (The onboard ethernet seems to be working perfectly fine again 
 now though. Maybe there was just some dust on the contacts or something.)


Over time, contacts can get dirty or corroded, resulting in erratic
connections. 
Reseating the connectors will fix that most of the time. Sometimes you might 
need to "polish" the connector a bit, a pencil eraser is just right for that.

Beyond that, most (nearly all) component failures I've had have been in the 
power supply. It's probably because of the heat.

My stereo runs all day every day, and has for the last 25 years! I'll be sorry 
when it finally croaks.



 Jan 01 2011



prev sibling next sibling parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


== Quote from Robert Clipsham (robert octarineparrot.com)'s article

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?
 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.
 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


I keep an eye on all D games in the Debian repository. Keeping track of language
changes that affect building/runtime, etc. There are about a dozen overall, and
range from 9K to 33K LOC in D1. Each use the SDL library for D, which is a rock-
solid library to use anyway, so I find it more or less suitably stable and pain
free.
The only change required in the next gdc package update will be to remove the
patches needed for them to work with d1.043 (those bugs have been fixed now ;)
and change the odd occurrence of 'auto file = new File' to 'scope file = new
File'.

All in all, very pleasant experience for me. :~)

Regards



 Jan 01 2011



prev sibling next sibling parent  Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 02.01.2011 1:22, Robert Clipsham wrote:

 Having seen a post by Peter Alexander (in Re: D for game development), 
 mentioning some of the issues he's hit I thought I'd post this. I've 
 been in his shoes (every other time I use D it seems), and feel I 
 should ask - who here uses D, and to what extent?


I started using it precisely for a hobby game project with a couple of 
friends. The project itself was soon abandoned due to lack of 
time/interest from most of its designers. Yet I decided to publish and 
maintain a port of DMDscript in D2, which would have been used as 
scripting engine. It's 27 KLOC as by wc *.d, but, yes, it's a very 
conservative D. I found two major bugs (both memory corruption) and 
still don't have time to narrow them down. One is somehow related to 
built-in AA, the other about throwing object not derived from Throwable. 
Workaround for the second one was trivial, as for the first one, I just 
use David Simcha's RandAA instead.

While the latest game techdemo is only 3kloc, all in more modern D2 with 
bells and whistles, because I also wanted to experiment with D2 features 
. It was written in days of dmd 2.40-2.41 with LRU array append  bugs 
and such, and I faced only some minor issues. The closest thing to 
blocker was http://d.puremagic.com/issues/show_bug.cgi?id=4481, but it 
has easy workaround. Besides, I can't reproduce it with latest dmd 
(maybe I should close it ).


 I'm mostly interested in those of you with 1000 Line plus projects in 
 D, as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, 
 just curious (I wouldn't normally have asked, but now I know I'm not 
 paranoid and the only one having problems, I thought I'd ask).


My recipe with D2 for now :
- stay away form inout & use immutability only with built-in types
- use malloc & emplace for big memory blocks
- don't push GC too hard, allocate only when it's really necessary (no 
Java style new-new-new)
- CTFE still has a long road to catch up with the rest, don't expect too 
much of it
- no *heavy* reliance on static introspection, and auto-magic things 
like array ops

So far, works just fine.

-- 
Dmitry Olshansky



 Jan 01 2011



prev sibling next sibling parent  Jesse Phillips <jessekphillips+D gmail.com>  writes:


Caligo Wrote:


 You don't get it!  If only one back-end was used then there wouldn't be
 three different groups working on three different projects that try to
 accomplish the same thing.
 
 Also, whenever there is a failure in communication, you end up with forked
 projects, hence Tango.


I don't think you understand the situation at all. There are 3 projects trying
to accomplish 3 different things and all use a common front-end. LDC is D for
LLVM (no exceptions in Windows), GDC is D for GCC, and Walter's company is
about writing compilers so he uses his compiler and is taking extreme cation to
not be sued.

Tango is not an example of a forked project/forked anything due to
communication issues. http://www.prowiki.org/wiki4d/wiki.cgi?StandardLib



 Jan 01 2011



prev sibling next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:ifo9jd$1kt9$1 digitalmars.com...

 Having seen a post by Peter Alexander (in Re: D for game development), 
 mentioning some of the issues he's hit I thought I'd post this. I've been 
 in his shoes (every other time I use D it seems), and feel I should ask - 
 who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D, 
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just 
 curious (I wouldn't normally have asked, but now I know I'm not paranoid 
 and the only one having problems, I thought I'd ask).


For a number a years, I've been using D for almost anything where I feel I 
really have a choice.

I have been doing a lot of web work in Haxe (PHP and Flash), but it's my 
intent to migrate over to D. The two main things holding me back on that are 
the lack of a real comprehensive web-oriented library/framework that's 
comparable to Haxe's Igniter (or Python's Django), and the inability to 
compile D code down to PHP or Flash so I won't have to worry about any 
servers that I might not be about to do custom CGI on (this issue I intend 
to remedy with my still-embryonic Dax: www.dsource.org/projects/dax --  
Speaking of which, what's happened to DDMD? The main guys behind it haven't 
had made any updates in quite awhile. Just got busy with other things?).

I've switched from D1/Tango to D2/Phobos fairly recently, and I haven't 
really had too much trouble with bugs or incomplete implementations, 
probably due in big part to not using too much of the more cutting-edge 
stuff. There have been some pains from bugs or unimplemented stuff, but it's 
always been far better than using a language that's mediocre to begin with.

I have been avoiding doing GUI work because I'm not quite sure how far along 
QtD is, and the other D GUI libs aren't really suitable for me various 
reasons.



 Jan 01 2011



 next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 1/2/11, Nick Sabalausky <a a.a> wrote:

 I have been avoiding doing GUI work because I'm not quite sure how far along
 QtD is, and the other D GUI libs aren't really suitable for me various
 reasons.


FWIW gtkD seems to work fine on D2 (but I've only tried a few small
samples). It seems to be one of the few multiplatform GUI libs that
works with D2. DFL works, and it has a GUI designer which is pretty
cool. But it's Windows only.

But yeah, ultimately I'd want to use Qt as well. I used Qt for a while
with Python, it was so damn easy to build some GUI apps that look &
behave nice.



 Jan 02 2011



 next sibling parent  Iain Buclaw <ibuclaw ubuntu.com>  writes:


== Quote from Andrej Mitrovic (andrej.mitrovich gmail.com)'s article

 On 1/2/11, Nick Sabalausky <a a.a> wrote:

 I have been avoiding doing GUI work because I'm not quite sure how far along
 QtD is, and the other D GUI libs aren't really suitable for me various
 reasons.


 FWIW gtkD seems to work fine on D2 (but I've only tried a few small
 samples). It seems to be one of the few multiplatform GUI libs that
 works with D2. DFL works, and it has a GUI designer which is pretty
 cool. But it's Windows only.
 But yeah, ultimately I'd want to use Qt as well. I used Qt for a while
 with Python, it was so damn easy to build some GUI apps that look &
 behave nice.


As far as I'm aware, gtkD is not 64bit-ready. A lot of the code (or so I've come
to assume from some comments made in IRC yesterday) assumes that sizeof .length
is 4 (as is on 32bits).

I've also ran into one or two bugs using gtkD applications with more recent gtk
releases. Some deadlocks when performing one or two actions.



 Jan 02 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.361.1293976216.4748.digitalmars-d puremagic.com...

 On 1/2/11, Nick Sabalausky <a a.a> wrote:

 I have been avoiding doing GUI work because I'm not quite sure how far 
 along
 QtD is, and the other D GUI libs aren't really suitable for me various
 reasons.


 FWIW gtkD seems to work fine on D2 (but I've only tried a few small
 samples). It seems to be one of the few multiplatform GUI libs that
 works with D2. DFL works, and it has a GUI designer which is pretty
 cool. But it's Windows only.


Yea, my three primary critera for a GUI lib are:

- Multiplatform
- Native controls
- Works on D2

To my knowledge, QtD is the only one that fits the bill. GTK fails horribly 



 But yeah, ultimately I'd want to use Qt as well. I used Qt for a while
 with Python, it was so damn easy to build some GUI apps that look &
 behave nice.





 Jan 02 2011



  parent reply "Patrick Kreft" <patrick_kreft gmx.net>  writes:


On Sun, 02 Jan 2011 19:28:07 +0100, Nick Sabalausky <a a.a> wrote:


 Yea, my three primary critera for a GUI lib are:

 - Multiplatform
 - Native controls
 - Works on D2



Qt has  self-drawn control, which could hold an native handler, if needed.  
But they are different from native control.



 Jan 02 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Patrick Kreft" <patrick_kreft gmx.net> wrote in message 
news:op.vopbqgqzq2mtfd zeus-pc.belkin...

 On Sun, 02 Jan 2011 19:28:07 +0100, Nick Sabalausky <a a.a> wrote:


 Yea, my three primary critera for a GUI lib are:

 - Multiplatform
 - Native controls
 - Works on D2



 Qt has  self-drawn control, which could hold an native handler, if needed. 
 But they are different from native control.


Qt has a compile-time setting to disable that and just use native controls 
like it always used to do. And since Qt added the self-drawing primarily 
just to decrease some redraw flicker, I suspect its self-drawing might not 
be too bad.



 Jan 02 2011



  parent reply "Patrick Kreft" <patrick_kreft gmx.net>  writes:


On Mon, 03 Jan 2011 06:53:36 +0100, Nick Sabalausky <a a.a> wrote:


 "Patrick Kreft" <patrick_kreft gmx.net> wrote in message
 news:op.vopbqgqzq2mtfd zeus-pc.belkin...

 On Sun, 02 Jan 2011 19:28:07 +0100, Nick Sabalausky <a a.a> wrote:


 Yea, my three primary critera for a GUI lib are:

 - Multiplatform
 - Native controls
 - Works on D2



 Qt has  self-drawn control, which could hold an native handler, if  
 needed.
 But they are different from native control.


 Qt has a compile-time setting to disable that and just use native  
 controls
 like it always used to do. And since Qt added the self-drawing primarily
 just to decrease some redraw flicker, I suspect its self-drawing might  
 not
 be too bad.


Sry there is no argument in your post.

You can enbale an native handler to the control in three ways. Look for Qt  
Documentation.
As i said qt controls haven't the look and behavior like native controls  
such as control created by winapi, mfc or winforms.



 Jan 03 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Patrick Kreft" <patrick_kreft gmx.net> wrote in message 
news:op.vop6g7wgq2mtfd zeus-pc.belkin...

 On Mon, 03 Jan 2011 06:53:36 +0100, Nick Sabalausky <a a.a> wrote:


 "Patrick Kreft" <patrick_kreft gmx.net> wrote in message
 news:op.vopbqgqzq2mtfd zeus-pc.belkin...

 On Sun, 02 Jan 2011 19:28:07 +0100, Nick Sabalausky <a a.a> wrote:


 Yea, my three primary critera for a GUI lib are:

 - Multiplatform
 - Native controls
 - Works on D2



 Qt has  self-drawn control, which could hold an native handler, if 
 needed.
 But they are different from native control.


 Qt has a compile-time setting to disable that and just use native 
 controls
 like it always used to do. And since Qt added the self-drawing primarily
 just to decrease some redraw flicker, I suspect its self-drawing might 
 not
 be too bad.


 Sry there is no argument in your post.

 You can enbale an native handler to the control in three ways. Look for Qt 
 Documentation.
 As i said qt controls haven't the look and behavior like native controls 
 such as control created by winapi, mfc or winforms.


There seems to be a lot of conflicting information about Qt then. I read a 
post from one of the Qt devs that said basically what I said above. So I 
guess at this point I haven't a clue what to make of Qt. Oh well, anyone 
know if wx is coming to D2?



 Jan 03 2011



 next sibling parent reply Robert Clipsham <robert octarineparrot.com>  writes:


On 03/01/11 16:53, Nick Sabalausky wrote:

 There seems to be a lot of conflicting information about Qt then. I read a
 post from one of the Qt devs that said basically what I said above. So I
 guess at this point I haven't a clue what to make of Qt. Oh well, anyone
 know if wx is coming to D2?


Having used both Qt and QtD on (Windows|Linux|OS X), I can say it looks 
native on all platforms (who cares if it actually is, it looks and feels 
it). I've never used QtD with D2, when I used it with D1/Tango it was 
pretty much fully functional GUI wise.

No idea about wx/D2, sorry.

-- 
Robert
http://octarineparrot.com/



 Jan 03 2011



 next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


I can report that QtD seems to work for D2 now. kilckverbot issued a
CTFE fix that was problematic for many examples that I've tried
yesterday. I am trying out all of the examples right now (a few
examples are using Tango and will have to be cloned and modified for
Phobos), so far they're compiling and running fine.

You will need cmake installed, fetch the repo from
https://bitbucket.org/qtd/repo/issues?status=new&status=open, follow
the instructions here
http://www.dsource.org/projects/qtd/wiki/BuildWindows, download Qt,
and might have to patch dmd with
http://www.dsource.org/projects/qtd/wiki/DmdPatch. I did the patching
manually since the patch was made for an older dmd release (It's just
a dozen lines of code, so it's easy).

After that just add the path to the import libs, copy the DLLs and
build the examples. Nick, if you want to give it a shot but have
trouble setting it up properly let me know and I'll help out.



 Jan 03 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.397.1294077039.4748.digitalmars-d puremagic.com...

I can report that QtD seems to work for D2 now. kilckverbot issued a
 CTFE fix that was problematic for many examples that I've tried
 yesterday. I am trying out all of the examples right now (a few
 examples are using Tango and will have to be cloned and modified for
 Phobos), so far they're compiling and running fine.

 You will need cmake installed, fetch the repo from
 https://bitbucket.org/qtd/repo/issues?status=new&status=open, follow
 the instructions here
 http://www.dsource.org/projects/qtd/wiki/BuildWindows, download Qt,
 and might have to patch dmd with
 http://www.dsource.org/projects/qtd/wiki/DmdPatch. I did the patching
 manually since the patch was made for an older dmd release (It's just
 a dozen lines of code, so it's easy).

 After that just add the path to the import libs, copy the DLLs and
 build the examples. Nick, if you want to give it a shot but have
 trouble setting it up properly let me know and I'll help out.


Cool, thanks. I'm not sure when I'll actually have a chance, but I 
definitely want to try that. 



 Jan 03 2011



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:ift0mt$60p$1 digitalmars.com...

 On 03/01/11 16:53, Nick Sabalausky wrote:

 There seems to be a lot of conflicting information about Qt then. I read 
 a
 post from one of the Qt devs that said basically what I said above. So I
 guess at this point I haven't a clue what to make of Qt. Oh well, anyone
 know if wx is coming to D2?


 Having used both Qt and QtD on (Windows|Linux|OS X), I can say it looks 
 native on all platforms (who cares if it actually is, it looks and feels 
 it).


The typical problem with things that look native but aren't technically 
native is that there's almost inevitably things that don't work right. For 
instance, they may ignore the system color scheme, they may fail to work 
with tools that inspect/manipulate other app's controls, they may not behave 
correctly outside of the most common use-cases, they may ignore system-wide 
skin settings (such things do, and should, exist for Windows), and I've even 
seen ones that actually go and emulate the wrong system style (For instance, 
Chrome/Iron's dialog windows look like Aero...but I'm on XP, and if I were 
on Win7 I'd be using the Classic theme anyway. Very very sloppy).

If it turns out that Qt's self-drawn controls doesn't have any of those 
issues, then I agree there's no problem at all. I'd also be incredibly 
impressed.



 Jan 03 2011



 next sibling parent reply Robert Clipsham <robert octarineparrot.com>  writes:


On 03/01/11 18:15, Nick Sabalausky wrote:

 The typical problem with things that look native but aren't technically
 native is that there's almost inevitably things that don't work right. For
 instance, they may ignore the system color scheme, they may fail to work
 with tools that inspect/manipulate other app's controls, they may not behave
 correctly outside of the most common use-cases, they may ignore system-wide
 skin settings (such things do, and should, exist for Windows), and I've even
 seen ones that actually go and emulate the wrong system style (For instance,
 Chrome/Iron's dialog windows look like Aero...but I'm on XP, and if I were
 on Win7 I'd be using the Classic theme anyway. Very very sloppy).

 If it turns out that Qt's self-drawn controls doesn't have any of those
 issues, then I agree there's no problem at all. I'd also be incredibly
 impressed.


I've not seen any such issues on Windows/Linux/OS X, could be others 
though *shrugg*. I'm pretty sure Qt uses the native API as a backend 
anyway, I remember reading an article about them transitioning from 
carbon to cocoa on OS X (the native APIs) on their blog at some point, 
I'd be surprised if they didn't do the same for Windows.

-- 
Robert
http://octarineparrot.com/



 Jan 03 2011



  parent reply "Patrick Kreft" <patrick_kreft gmx.net>  writes:


On Mon, 03 Jan 2011 19:36:05 +0100, Robert Clipsham  
<robert octarineparrot.com> wrote:


 On 03/01/11 18:15, Nick Sabalausky wrote:

 The typical problem with things that look native but aren't technically
 native is that there's almost inevitably things that don't work right.  
 For
 instance, they may ignore the system color scheme, they may fail to work
 with tools that inspect/manipulate other app's controls, they may not  
 behave
 correctly outside of the most common use-cases, they may ignore  
 system-wide
 skin settings (such things do, and should, exist for Windows), and I've  
 even
 seen ones that actually go and emulate the wrong system style (For  
 instance,
 Chrome/Iron's dialog windows look like Aero...but I'm on XP, and if I  
 were
 on Win7 I'd be using the Classic theme anyway. Very very sloppy).

 If it turns out that Qt's self-drawn controls doesn't have any of those
 issues, then I agree there's no problem at all. I'd also be incredibly
 impressed.


 I've not seen any such issues on Windows/Linux/OS X, could be others  
 though *shrugg*. I'm pretty sure Qt uses the native API as a backend  
 anyway, I remember reading an article about them transitioning from  
 carbon to cocoa on OS X (the native APIs) on their blog at some point,  
 I'd be surprised if they didn't do the same for Windows.


Look:  
http://labs.qt.nokia.com/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/

Qt doesn't build up a virtual api beside from winapi. Yes qt have to use  
system api, but they want the small amount of them.
Because they have to ask the system how is your state, and i want you to  
do that and that.
There are always some control they have native handler - i believe it is  
shown in the video. Like the MenuBar Qt Menubar in Windows feels like a  
Windows Menubar and on a Mac i believe it would feel like an Mac Menubar.  
But there are some components in Qt which are better than the native one  
like Qt Calendar it is beauty and have more function as the windows one- I  
want exchange them xd



 Jan 03 2011



  parent  "Patrick Kreft" <patrick_kreft gmx.net>  writes:


Oh damn wrong video



 Jan 03 2011



prev sibling  parent  Lutger Blijdestijn <lutger.blijdestijn gmail.com>  writes:


Nick Sabalausky wrote:


 "Robert Clipsham" <robert octarineparrot.com> wrote in message
 news:ift0mt$60p$1 digitalmars.com...

 On 03/01/11 16:53, Nick Sabalausky wrote:

 There seems to be a lot of conflicting information about Qt then. I read
 a
 post from one of the Qt devs that said basically what I said above. So I
 guess at this point I haven't a clue what to make of Qt. Oh well, anyone
 know if wx is coming to D2?


 Having used both Qt and QtD on (Windows|Linux|OS X), I can say it looks
 native on all platforms (who cares if it actually is, it looks and feels
 it).


 
 The typical problem with things that look native but aren't technically
 native is that there's almost inevitably things that don't work right. For
 instance, they may ignore the system color scheme, they may fail to work
 with tools that inspect/manipulate other app's controls, they may not
 behave correctly outside of the most common use-cases, they may ignore
 system-wide skin settings (such things do, and should, exist for Windows),
 and I've even seen ones that actually go and emulate the wrong system
 style (For instance, Chrome/Iron's dialog windows look like Aero...but I'm
 on XP, and if I were on Win7 I'd be using the Classic theme anyway. Very
 very sloppy).
 
 If it turns out that Qt's self-drawn controls doesn't have any of those
 issues, then I agree there's no problem at all. I'd also be incredibly
 impressed.


Qt uses the native theme managers on mac osx and windows for styling. I 
haven't tried it but Qt apps should be able to cope with custom color 
schemes, unless of course the developer has overridden that. Perhaps some 
animations / effects are different, but colors should be fine.



 Jan 03 2011



prev sibling  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Nick Sabalausky wrote:

 Oh well, anyone know if wx is coming to D2?


What does this mean ? If wxWidgets is being ported to D2 ?

Or if you can use wxWidgets from D2, if so: yes you can.
Or at least you could, back with DMD 2.049 (or whatever)

But what should be done is to regenerate it with SWIG/etc.

Even if wxD "works" with D2 and wx3 too, it's still a port
from wx.NET and wxWidgets 2.6.4 API - and 5 years old now.

--anders



 Jan 03 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Anders F Björklund" <afb algonet.se> wrote in message 
news:ift31b$alt$1 digitalmars.com...

 Nick Sabalausky wrote:

 Oh well, anyone know if wx is coming to D2?


 What does this mean ? If wxWidgets is being ported to D2 ?

 Or if you can use wxWidgets from D2, if so: yes you can.
 Or at least you could, back with DMD 2.049 (or whatever)

 But what should be done is to regenerate it with SWIG/etc.

 Even if wxD "works" with D2 and wx3 too, it's still a port
 from wx.NET and wxWidgets 2.6.4 API - and 5 years old now.


Ahh, I was under the impression there were currently no wd bindings for D2, 
just D1. Am I correct in my understanding that wx is cross-platform and uses 
native controls?

Also, as I haven't followed this real closely, what's the current state of 
SWIG for D? Fully-usable?



 Jan 03 2011



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:ift425$cf7$1 digitalmars.com...

 "Anders F Björklund" <afb algonet.se> wrote in message 
 news:ift31b$alt$1 digitalmars.com...

 Nick Sabalausky wrote:

 Oh well, anyone know if wx is coming to D2?


 What does this mean ? If wxWidgets is being ported to D2 ?

 Or if you can use wxWidgets from D2, if so: yes you can.
 Or at least you could, back with DMD 2.049 (or whatever)

 But what should be done is to regenerate it with SWIG/etc.

 Even if wxD "works" with D2 and wx3 too, it's still a port
 from wx.NET and wxWidgets 2.6.4 API - and 5 years old now.


 Ahh, I was under the impression there were currently no wd bindings for 
 D2, just D1. Am I correct in my understanding that wx is cross-platform 
 and uses native controls?

 Also, as I haven't followed this real closely, what's the current state of 
 SWIG for D? Fully-usable?


s/wd/wx/



 Jan 03 2011



prev sibling next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Nick Sabalausky wrote:

 What does this mean ? If wxWidgets is being ported to D2 ?

 Or if you can use wxWidgets from D2, if so: yes you can.
 Or at least you could, back with DMD 2.049 (or whatever)

 But what should be done is to regenerate it with SWIG/etc.

 Even if wxD "works" with D2 and wx3 too, it's still a port
 from wx.NET and wxWidgets 2.6.4 API - and 5 years old now.


 Ahh, I was under the impression there were currently no wd bindings for D2,
 just D1. Am I correct in my understanding that wx is cross-platform and uses
 native controls?


You are correct. Where native means Win32/Win64 or GTK+ or Carbon/Cocoa.
There's even a Qt4 port coming next to the GTK+, and an old limited X11.

wxD uses wx.NET as a base, where wxHaskell uses wxEiffel, but same idea.
Drew some images and stuff on http://wxd.sourceforge.net/ to explain it.


 Also, as I haven't followed this real closely, what's the current state of
 SWIG for D? Fully-usable?


No idea. But I saw that just like GCC it comes with Go language support.
Just saying that the "correct" approach is to generate it from the C++ ?

The current export "C" code is generated by a mix of Perl and monkeys...
See http://xkcd.com/224/ for some related information on how that works.

--anders



 Jan 03 2011



prev sibling  parent  Jimmy Cao <jcao219 gmail.com>  writes:


On Mon, Jan 3, 2011 at 12:18 PM, Nick Sabalausky <a a.a> wrote:


 Also, as I haven't followed this real closely, what's the current state of
 SWIG for D? Fully-usable?


It's usable (but not without a little bit of work in writing the .i files.)

Take a look at the thing I've been working on in my free time (with SWIG):
http://irrlichtd.codeplex.com/



 Jan 03 2011



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-01-02 05:13, Nick Sabalausky wrote:

 "Robert Clipsham"<robert octarineparrot.com>  wrote in message
 news:ifo9jd$1kt9$1 digitalmars.com...

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've been
 in his shoes (every other time I use D it seems), and feel I should ask -
 who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


 For a number a years, I've been using D for almost anything where I feel I
 really have a choice.

 I have been doing a lot of web work in Haxe (PHP and Flash), but it's my
 intent to migrate over to D. The two main things holding me back on that are
 the lack of a real comprehensive web-oriented library/framework that's
 comparable to Haxe's Igniter (or Python's Django), and the inability to
 compile D code down to PHP or Flash so I won't have to worry about any
 servers that I might not be about to do custom CGI on (this issue I intend
 to remedy with my still-embryonic Dax: www.dsource.org/projects/dax --
 Speaking of which, what's happened to DDMD? The main guys behind it haven't
 had made any updates in quite awhile. Just got busy with other things?).

 I've switched from D1/Tango to D2/Phobos fairly recently, and I haven't
 really had too much trouble with bugs or incomplete implementations,
 probably due in big part to not using too much of the more cutting-edge
 stuff. There have been some pains from bugs or unimplemented stuff, but it's
 always been far better than using a language that's mediocre to begin with.

 I have been avoiding doing GUI work because I'm not quite sure how far along
 QtD is, and the other D GUI libs aren't really suitable for me various
 reasons.


I've may have asked this before but how what about DWT? I see now that 
you've switch to D2 but when you used D1.

-- 
/Jacob Carlborg



 Jan 03 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Jacob Carlborg" <doob me.com> wrote in message 
news:ift7ig$j1s$1 digitalmars.com...

 On 2011-01-02 05:13, Nick Sabalausky wrote:

 "Robert Clipsham"<robert octarineparrot.com>  wrote in message
 news:ifo9jd$1kt9$1 digitalmars.com...

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've 
 been
 in his shoes (every other time I use D it seems), and feel I should 
 ask -
 who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


 For a number a years, I've been using D for almost anything where I feel 
 I
 really have a choice.

 I have been doing a lot of web work in Haxe (PHP and Flash), but it's my
 intent to migrate over to D. The two main things holding me back on that 
 are
 the lack of a real comprehensive web-oriented library/framework that's
 comparable to Haxe's Igniter (or Python's Django), and the inability to
 compile D code down to PHP or Flash so I won't have to worry about any
 servers that I might not be about to do custom CGI on (this issue I 
 intend
 to remedy with my still-embryonic Dax: www.dsource.org/projects/dax --
 Speaking of which, what's happened to DDMD? The main guys behind it 
 haven't
 had made any updates in quite awhile. Just got busy with other things?).

 I've switched from D1/Tango to D2/Phobos fairly recently, and I haven't
 really had too much trouble with bugs or incomplete implementations,
 probably due in big part to not using too much of the more cutting-edge
 stuff. There have been some pains from bugs or unimplemented stuff, but 
 it's
 always been far better than using a language that's mediocre to begin 
 with.

 I have been avoiding doing GUI work because I'm not quite sure how far 
 along
 QtD is, and the other D GUI libs aren't really suitable for me various
 reasons.


 I've may have asked this before but how what about DWT? I see now that 
 you've switch to D2 but when you used D1.


I looked into it at one point when I was using D1. It seemed promising but 
at the time there were still some bugs or something (don't remember exactly) 
that needed to be worked out (and I was busy with other things anyway). I'm 
sure that's probably all fixed by now though.



 Jan 03 2011



prev sibling next sibling parent  Jesse Phillips <jessekphillips+D gmail.com>  writes:


Robert Clipsham Wrote:


 Having seen a post by Peter Alexander (in Re: D for game development), 
 mentioning some of the issues he's hit I thought I'd post this. I've 
 been in his shoes (every other time I use D it seems), and feel I should 
 ask - who here uses D, and to what extent?
 
 I'm mostly interested in those of you with 1000 Line plus projects in D, 
 as that's when I've found I start hitting issues.


Most of my coding is done with smaller projects. But I have one project which
has grown to a couple thousands lines of D2 code. It is in use at my job and
makes use of a number of other libraries.

I tend to stay away from the newest features of D2, and those known to have
problems. I make some attempts to use const/pure but do not force it (that is
I'm not designing to require some attribute). This means most of the code I'm
writing would work with D1. However I do make use of some improvements and of
course Phobos.

I have come across a number of bugs through my use of D, though I couldn't say
how many come from my limited use of D2 as I do experiment at times.



 Jan 01 2011



prev sibling next sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <ludwig informatik.uni-luebeck.de>  writes:


Am 01.01.2011 23:22, schrieb Robert Clipsham:

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


My main project is abount 100.000 lines of code. Most of the time now, I 
stay away from new features - including pure and the new concurrency 
model. However, I use the const/immutable system since the beginning. 
Also quite some string-mixin stuff, templates and CTFE. (*)

At times I'm hitting multiple bugs a day, but by far the most 
devastating bugs are those freakin' unexpected OPTLINK terminations 
(e.g. http://d.puremagic.com/issues/show_bug.cgi?id=4808). With that 
code base it is practically impossible to make repro cases or 
workarounds for those bugs and they slip up every now and then (right 
now I have one of them). Unfortunately those are often bugs that lie 
there for years. I remember someone said there should be no known new 
regressions in the compiler - the reality seems to be quite different 
here and I quit D programming for multiple periods of months because of 
such beasts. (Fortunately most of the time there is one method of 
compilation or operating system that successfully builds).

The other kind of bug that I find really frustrating because it is hard 
to discover and takes a lot of time to track down and work around is 
that kind with corruped data/wrong code. Todays examples are 
http://d.puremagic.com/issues/show_bug.cgi?id=3863 and some postblit 
stuff that I have not yet been able to track down.

At least in times when it is possible to program without hitting those 
issues, D somehow is able to close the gap again with its nice and 
efficient language constructs. But I think the priority for fixing bugs 
really has to be changed because that is what is driving people away 
(for good reason):
Blockers, Regressions and maybe criticals should be taken more serious, 
as well as the top votes in bugzilla should be handled somehow.

Sönke


(*) I think the fact that only very few people use new features and the 
rest is mostly just doing smaller tests with them is a real problem in 
the language/compiler development. All of those people think "I will use 
it when it's ready", but it will never or really slowly reach that stage 
beause of missing input. This also means first use feedback for new 
features should be taken more serious - I've often seen important 
observations vanish in time and meanwhile the underlying problem was 
consolidated in the language.



 Jan 02 2011



 next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 1/2/11, S=F6nke Ludwig <ludwig informatik.uni-luebeck.de> wrote:

 My main project is abount 100.000 lines of code.


Wow, that's pretty big. Building an operating system? :-)



 Jan 02 2011



  parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <ludwig informatik.uni-luebeck.de>  writes:


Am 02.01.2011 14:51, schrieb Andrej Mitrovic:

 On 1/2/11, Sönke Ludwig<ludwig informatik.uni-luebeck.de>  wrote:

 My main project is abount 100.000 lines of code.


 Wow, that's pretty big. Building an operating system? :-)


Is a simulation/game engine plus some more that I ported some years ago 
from C++ along with an editor application for the engine. The project 
started in 2001, that's why it has grown considerably by now - but well 
I hope to have a public version this year...

Hmm by the way: the good news when talking abount LOC is, the number of 
lines went down by half during the C++ -> D conversion, which is really 
nice :)



 Jan 02 2011



  parent  bearophile <bearophileHUGS lycos.com>  writes:


Sönke Ludwig:


 Hmm by the way: the good news when talking abount LOC is, the number of 
 lines went down by half during the C++ -> D conversion, which is really 
 nice :)


When I convert a good amount of C code to D I've seen that another thing you
can do is to profile your D code and de-optimize parts of it that don't require
performance, rewriting them in a higher-level style. So you are able to shrink
the D code some more compared to the C or C++ starting code. In this shrinking
refactoring work it is useful to know some higher level language too, because
they train you a lot to write shorter code.

Bye,
bearophile



 Jan 02 2011



prev sibling  parent reply Don <nospam nospam.com>  writes:


Sönke Ludwig wrote:

 Am 01.01.2011 23:22, schrieb Robert Clipsham:

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


 
 My main project is abount 100.000 lines of code. Most of the time now, I 
 stay away from new features - including pure and the new concurrency 
 model. However, I use the const/immutable system since the beginning. 
 Also quite some string-mixin stuff, templates and CTFE. (*)
 
 At times I'm hitting multiple bugs a day, but by far the most 
 devastating bugs are those freakin' unexpected OPTLINK terminations 
 (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=4808). With that 
 code base it is practically impossible to make repro cases or 
 workarounds for those bugs and they slip up every now and then (right 
 now I have one of them). Unfortunately those are often bugs that lie 
 there for years. I remember someone said there should be no known new 
 regressions in the compiler - the reality seems to be quite different 
 here and I quit D programming for multiple periods of months because of 
 such beasts. (Fortunately most of the time there is one method of 
 compilation or operating system that successfully builds).
 
 The other kind of bug that I find really frustrating because it is hard 
 to discover and takes a lot of time to track down and work around is 
 that kind with corruped data/wrong code. Todays examples are 
 http://d.puremagic.com/issues/show_bug.cgi?id=3863 and some postblit 
 stuff that I have not yet been able to track down.
 
 At least in times when it is possible to program without hitting those 
 issues, D somehow is able to close the gap again with its nice and 
 efficient language constructs. But I think the priority for fixing bugs 
 really has to be changed because that is what is driving people away 
 (for good reason):
 Blockers, Regressions and maybe criticals should be taken more serious, 
 as well as the top votes in bugzilla should be handled somehow.


Here is the priority list:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#DMDCompilerStability

And here's my personal list of top-priority bugs:

-- Showstoppers --
4854 Regression(2.047, Mac 10.5 only) writefln Segmentation fault if no 
globals
3516 Destructor not called on temporaries
4437 copy construction bug with "return this;"
314  Static, renamed, and selective imports are always public

-- Critical wrong code --
4714 Cannot return ref this when struct has invariant
(= 3273, 1251, 3973)
4269 Regression(2.031) invalid type accepted if evaluated while errors 
are gagged

1350 delegate literal inside tuple; wrong values
1513 try/catch/finally misbehavior on windows
1759 Closures and With Statements
1841 Closure detection doesn't work when variable is used in a nested 
function
1899 AA of fixed-length arrays fails to initialize
2962 ICE(glue.c) or bad codegen passing variable as template value parameter
3824 An AA with an AA as key doesn't seem to work
3863 Various errors and ICE(todt.c) for struct constructors with ellipses

And BTW, that list used to be about ten times as long. There are not 
many nightmare bugs left. I'm personally not comfortable with heavily 
promoting the language until that list is reduced to practically zero. 
At the current rare, we're probably a couple of months away.



 Jan 02 2011



 next sibling parent  Peter Alexander <peter.alexander.au gmail.com>  writes:


On 2/01/11 9:13 PM, Don wrote:

 And BTW, that list used to be about ten times as long. There are not
 many nightmare bugs left. I'm personally not comfortable with heavily
 promoting the language until that list is reduced to practically zero.
 At the current rare, we're probably a couple of months away.


I agree, but that's good that we're only a couple of months off :-)



 Jan 02 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-01-02 22:13, Don wrote:

 Here is the priority list:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#DMDCompilerStability

 And here's my personal list of top-priority bugs:

 -- Showstoppers --
 4854 Regression(2.047, Mac 10.5 only) writefln Segmentation fault if no
 globals


I would hope that someone could comment on my patch for that issue.

-- 
/Jacob Carlborg



 Jan 03 2011



prev sibling next sibling parent  Jordi <jordi rovira.cat>  writes:


On 01/01/2011 11:22 PM, Robert Clipsham wrote:

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


I used D for one year now, converting my years-long C++ home project 
(50K lines). I recently quit my job and i am starting a new small 
venture (real-time graphics) in which i will use D for some of the 
components.

I am happy with it, and i will slowly move to the new features. I am 
specially interested in multithreading.

When it is worth (as in useful for somebody) i will open source some of 
the D components.

j.



 Jan 02 2011



prev sibling next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Robert Clipsham wrote:

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


I don't use D (anymore), but took some time during the holidays
to make sure that GDC and wxD works with 64-bit on all platforms.

The previous packages, from 2007 and 2008, were all 32-bit only:
http://gdcgnu.sourceforge.net/ ("FSF" GCC)
http://gdcmac.sourceforge.net/ (Apple GCC)
http://gdcwin.sourceforge.net/ (MinGW GCC)

This incidentally involved upgrading Mac from gcc-4.0 to gcc-4.2
and upgrading Win from Win32 to Win64, but now both of those work:

i686-apple-darwin10-gdc-4.2.1 (GCC) 4.2.1 20070719
x86_64-w64-mingw32-gdc (GCC) 4.5.1 20100731

For Mac OS X it also involved upgrading GUI from Carbon to Cocoa,
which included upgrading from wxWidgets 2.8 to wxWidgets 2.9...

hhttp://wxd.sourceforge.net/  (GUI)

And after the release of Fedora 14, LDC support was also added to
Code::Blocks in addition to the previously existing GDC and DMD.

http://www.codeblocks.org/    (IDE)


This also marks the fourth anniversary, from the first release:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=46121

I was also mainly interested in using D to make games with (SDL/GL),
and as a programming language offering an upgrade from C and Java.

--anders



 Jan 02 2011



prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet>  writes:


On Sat, 01 Jan 2011 22:22:35 +0000, Robert Clipsham wrote:


 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?
 
 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.
 
 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


I've been using D almost every day for the past 3 1/2 years as a part of 
my doctoral work, as well as for hobby programming.

The programs I've written at work have mostly been rather small ones, 
each of which typically performs a very specific calculation.  But since 
there weren't many preexisting numerics libraries for D, I've had to 
write quite a few numerical algorithms myself -- some from scratch, some 
ported from old FORTRAN code found on Netlib.  This has led to the SciD 
project, which is now almost 28,000 lines.  SciD is a combined hobby and 
professional project in that I add stuff when I need it for work, but the 
rest (probably the largest part) I've done on my spare time.

In my experience, D's bugginess is often very exaggerated.  Some people 
on this forum give the impression that D actively prevents them from 
doing what they need to do!  Granted, I do run into bugs at times, some 
of them pretty annoying, but only once (I think) have I run into one that 
didn't have a simple workaround, or which couldn't simply be ignored for 
the time being.  And the few annoyances I face with D are insignificant 
compared to the major PITA of using C/C++ (which is what I used for 
numerics before D) or Java (which I used for non-numerical programming 
before D).

Yes, most of the time I write numerical code, so there are parts of D and 
Phobos that I seldom use, and therefore there are lots of bugs I never 
run into.  However, comments from other non-pessimistic D users such as 
Adam R. tell me that the above is true in general.

-Lars



 Jan 03 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:ifs496$tg1$1 digitalmars.com...

 And the few annoyances I face with D are insignificant
 compared to the major PITA of using C/C++ [...] or Java [...].


That's exactly my experience with D: Sure, there are a few hiccups, but 
dealing with hiccups is FAR better than dealing with a language (like 
C/C++/Java) that just sucks to begin with.



 Jan 03 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:ifsvc4$3lt$1 digitalmars.com...

 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
 news:ifs496$tg1$1 digitalmars.com...

 And the few annoyances I face with D are insignificant
 compared to the major PITA of using C/C++ [...] or Java [...].


 That's exactly my experience with D: Sure, there are a few hiccups, but 
 dealing with hiccups is FAR better than dealing with a language (like 
 C/C++/Java) that just sucks to begin with.


For instance, DMD's bugs get fixed or at least worked around, but C++ will 
likely never get a real module system, strong typing (as opposed to the 
"*cough* 'strong typing' *cough*" it has now), or non-PITA metaprogramming.



 Jan 03 2011



prev sibling next sibling parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sat, 01 Jan 2011 17:22:35 -0500, Robert Clipsham  
<robert octarineparrot.com> wrote:


 Having seen a post by Peter Alexander (in Re: D for game development),  
 mentioning some of the issues he's hit I thought I'd post this. I've  
 been in his shoes (every other time I use D it seems), and feel I should  
 ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,  
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just  
 curious (I wouldn't normally have asked, but now I know I'm not paranoid  
 and the only one having problems, I thought I'd ask).


At my previous job, I used D1/Tango to implement a network client to allow  
remote execution of programs.  It was probably on the order of 5KLOC.   
Other than that, I wrote dcollections which is a fair size, but not really  
an 'end' product.  However, it is D2.

In my new job, I'm doing all web development (php+mysql) so, I have very  
little opportunity to use D professionally recently.

As far as bugs hit, I found quite a few while creating the unit tests for  
dcollections.

My experience with the bugs has been that you are playing sort of a game  
of roulette -- you could hit a bug that's annoying but has a workaround,  
or you could hit a blocker.  Hitting a blocker is horrible, because you  
basically are stuck in your tracks, and you are depending on someone else  
to fix the bug to get you going.

There was a time where dcollections was stalled for probably close to a  
year, if not more, because of a bizarre interface bug:  
http://d.puremagic.com/issues/show_bug.cgi?id=2061

Those are the bugs that can piss you off to the point of abandoning D.

-Steve



 Jan 03 2011



prev sibling next sibling parent reply Jean Crystof <news news.com>  writes:


Robert Clipsham Wrote:


 Having seen a post by Peter Alexander (in Re: D for game development), 
 mentioning some of the issues he's hit I thought I'd post this. I've 
 been in his shoes (every other time I use D it seems), and feel I should 
 ask - who here uses D, and to what extent?
 
 I'm mostly interested in those of you with 1000 Line plus projects in D, 
 as that's when I've found I start hitting issues.
 
 Just to clarify, for those D purists among you... I'm not trolling, just 
 curious (I wouldn't normally have asked, but now I know I'm not paranoid 
 and the only one having problems, I thought I'd ask).


We used D in a college project. It's a Wolfenstein 3D clone (simple ray caster
engine, untextured floor and ceil, our own software renderer, uses SDL) written
in D1 by 7 persons. Thanks to fast compile speed we were able to use TDD
heavily. The game is about 105 kLOC and the unittest suite 280 kLOC with
documents. We were impressed how tight code was possible to write in D (FPS
games can have millions lines of code) and how unittests were integrated in the
language. We would not have been able to implement anything as complex in C++
or Java in only 3 months. Maybe a tic tac toe or tetris. My role was porting
Java/C++ type coding style of other members in more like D as the repository
master. They quickly learned more advanced idioms.

We encountered one forward reference bug, but it disappeared when restructuring
program. No other bugs were found in D and we updated the compiler in 1-7 days
when a new came.



 Jan 03 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Jean Crystof" <news news.com> wrote in message 
news:ift3aj$b97$1 digitalmars.com...

 Robert Clipsham Wrote:


 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


 We used D in a college project. It's a Wolfenstein 3D clone (simple ray 
 caster engine, untextured floor and ceil, our own software renderer, uses 
 SDL) written in D1 by 7 persons. Thanks to fast compile speed we were able 
 to use TDD heavily. The game is about 105 kLOC and the unittest suite 280 
 kLOC with documents. We were impressed how tight code was possible to 
 write in D (FPS games can have millions lines of code) and how unittests 
 were integrated in the language. We would not have been able to implement 
 anything as complex in C++ or Java in only 3 months. Maybe a tic tac toe 
 or tetris. My role was porting Java/C++ type coding style of other members 
 in more like D as the repository master. They quickly learned more 
 advanced idioms.

 We encountered one forward reference bug, but it disappeared when 
 restructuring program. No other bugs were found in D and we updated the 
 compiler in 1-7 days when a new came.


Cool. I find raycasters very nostalgic. Out of curiosity, was there any book 
or reference that you used for the raycasting algorithm, or did you just 
work out the math and implement? There are a least a couple old DOS-based 
raycasting book I read cover-to-cover back in the day. Although I've never 
actually implemented anything other than a Mode7-style floor.



 Jan 03 2011



prev sibling next sibling parent reply "nedbrek" <nedbrek yahoo.com>  writes:


Hello all,
(there are a lot of posts here!  Just getting to this one :)

"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:ifo9jd$1kt9$1 digitalmars.com...

 Having seen a post by Peter Alexander (in Re: D for game development), 
 mentioning some of the issues he's hit I thought I'd post this. I've been 
 in his shoes (every other time I use D it seems), and feel I should ask - 
 who here uses D, and to what extent?


I first starting investigating D in Sep 2008.  My day job is C++, and I tend 
to think in that.  I also like Tcl, for rapid design.

I figured a good test project for D would be a cycle based microarchitecture 
simulator (that was my last job).  I've written several of them in C++.

The first stage is an architectural model.  I've made some progress on this 
(although I've been stalled a while), wc gives 2495 lines across 17 files. 
When it is more presentable, I will probably push it to github.

An achitectural model can be 10,000 lines or more in C++.  I think I am 
maybe halfway done - so I could be seeing a reduction of 50% similar to what 
others have reported.

I use a really old version of gdc/phobos for D1 on Windows (although I will 
probably use dmd on Linux).  I went with gdc because I need to link with a 
Tcl COFF lib on Windows.

I'm interested in D2, but at the time it wasn't an option.

I use an incremental build with Makefiles.

Hope that helps,
Ned



 Feb 13 2011



  parent reply =?iso-8859-1?b?Z/ZsZ2VsaXllbGU=?= <usuldan gmail.com>  writes:


 
 I use an incremental build with Makefiles.
 
 Hope that helps,
 Ned



Hi, 

  Can you tell me how you used incremental build with Makefiles? I 
don't know much about D1, but it most likely has similar module and 
build support as D2. I have been playing around with incremental build 
with dmd today (I couldn't find good info on the web). My solution was 
to use a makefile as well, but it required some advanced techniques, 
such as:

- dmd compiler's -deps option to find out what are the dependencies of 
a module, which required simple post processing 
- GNU make's auto-dependency generation capabilities (mostly the 
ability to generate dependency stuff during make and at the same time 
include them into the makefile)

I have too worries about this:
1) Requires experience with make and DMD, not easily gained through 
reading documentation
2) GNU make is not easily available on all platforms

If you have a solution that is more straightforward please let me 
know.

Also: How much time it takes for you to do a wholesale compilation 
versus incremental (say after changing a single file)?



 Feb 13 2011



  parent reply "nedbrek" <nedbrek yahoo.com>  writes:


Hello,

"gölgeliyele" <usuldan gmail.com> wrote in message 
news:9F28E8ED-939D-4EDB-AB1F-0A4F9B72DA44%usuldan gmail.com...

 I use an incremental build with Makefiles.


  Can you tell me how you used incremental build with Makefiles? I
 don't know much about D1, but it most likely has similar module and
 build support as D2. I have been playing around with incremental build
 with dmd today (I couldn't find good info on the web). My solution was
 to use a makefile as well, but it required some advanced techniques,
 such as:

 - dmd compiler's -deps option to find out what are the dependencies of
 a module, which required simple post processing


Yes, you have to build a dependency list for each .d file.  I use an Awk 
script, but I should probably use dmd -deps...


 - GNU make's auto-dependency generation capabilities (mostly the
 ability to generate dependency stuff during make and at the same time
 include them into the makefile)


Yes, I am also using some tricks I found on the web to support building 
outside of the source tree.

I currently have all the dependendcies in one file, and regenerate manually. 
I have gotten auto-dependency generation to work with C++ (it is just a 
matter of breaking the dependencies into separate files).


 I have too worries about this:
 1) Requires experience with make and DMD, not easily gained through
 reading documentation
 2) GNU make is not easily available on all platforms


I use Cygwin on Windows.  Make is somewhat hard to learn at first.  Once you 
have some tricks, you can apply them to all projects.


 If you have a solution that is more straightforward please let me
 know.

 Also: How much time it takes for you to do a wholesale compilation
 versus incremental (say after changing a single file)?


I find file I/O to be very slow on Windows.  Cygwin seems to compound this 
problem.  Build time on my project isn't real bad, maybe a few seconds for 
one or two files.  A full rebuild might take a minute (I seem to have broken 
my build, so I can't test it right now :)

Ned



 Feb 13 2011



  parent  =?iso-8859-1?b?Z/ZsZ2VsaXllbGU=?= <usuldan gmail.com>  writes:


"nedbrek" <nedbrek yahoo.com> wrote:

 
 Yes, I am also using some tricks I found on the web to support building 
 outside of the source tree.
 
 I currently have all the dependendcies in one file, and regenerate manually. 
 I have gotten auto-dependency generation to work with C++ (it is just a 
 matter of breaking the dependencies into separate files).
 


If it is of interest, below is the makefile I have created for this purpose. It 
has the dependency generation built-in. The part I don't like about it is that 
the -deps option of dmd creates a very large file with all the dependencies,
not 
just the one for the .d file being compiled. It is easy to filter out, but
there 
is unnecessary IO (something you mentioned as being slow).

======
PHONY: all clean

EXECUTABLE=foo
SOURCE_DIR=source
OUTPUT_DIR=output
BINARY_DIR=$(OUTPUT_DIR)/bin
BUILD_DIR=$(OUTPUT_DIR)/build

DMD=/path/to/dmd
DMD_FLAGS=-w -wi
LINK_FLAGS=$(DMD_FLAGS)
COMPILE_FLAGS=$(DMD_FLAGS) -I$(SOURCE_DIR)

SOURCE_FILES=$(shell find $(SOURCE_DIR) -name "*.d")
OBJECT_FILES=$(subst $(SOURCE_DIR), $(BUILD_DIR), \
                     $(SOURCE_FILES:%.d=%.o))
DEP_MAKEFILES=$(addsuffix .mk, $(OBJECT_FILES))

all: $(BINARY_DIR)/$(EXECUTABLE)

$(BINARY_DIR)/$(EXECUTABLE): $(OBJECT_FILES) 
	 echo "Linking '$ '..."	
	 $(DMD) $(LINK_FLAGS) -of$  $^

$(BUILD_DIR)/%.o: $(SOURCE_DIR)/%.d 
	 echo "Compiling '$<'..."	
	 mkdir -p `dirname $ `; \
	$(DMD) $(COMPILE_FLAGS) -c -deps=$ .dep -of$  $< && \
	  cat $ .dep | grep "^[^(]*($<" | \
	    sed 's;^.*(.*).*(\(.*\)).*;$  : \1;' > $ .mk

clean:
	rm -fr $(OUTPUT_DIR)

-include $(DEP_MAKEFILES)



 Feb 13 2011



prev sibling  parent reply "Simen kjaeraas" <simen.kjaras gmail.com>  writes:


Robert Clipsham <robert octarineparrot.com> wrote:


 Having seen a post by Peter Alexander (in Re: D for game development),  
 mentioning some of the issues he's hit I thought I'd post this. I've  
 been in his shoes (every other time I use D it seems), and feel I should  
 ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in D,  
 as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling, just  
 curious (I wouldn't normally have asked, but now I know I'm not paranoid  
 and the only one having problems, I thought I'd ask).


Having just landed a new job, I can now say that I will be using D in that
job (but aren't using it yet).


-- 
Simen



 Feb 13 2011



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Sunday 13 February 2011 21:59:58 Simen kjaeraas wrote:

 Robert Clipsham <robert octarineparrot.com> wrote:

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I should
 ask - who here uses D, and to what extent?
 
 I'm mostly interested in those of you with 1000 Line plus projects in D,
 as that's when I've found I start hitting issues.
 
 Just to clarify, for those D purists among you... I'm not trolling, just
 curious (I wouldn't normally have asked, but now I know I'm not paranoid
 and the only one having problems, I thought I'd ask).


 
 Having just landed a new job, I can now say that I will be using D in that
 job (but aren't using it yet).


Lucky dog!

I think that most of my co-workers have come to the conclusion that I'm a D-nut 
and might try it out at some point but aren't in a hurry to do so. Regardless, 
as long as the linker issues on Windows persist, I'm not going to be able to
use 
D at work. We have to be able to link with C and/or C++ code built by 
Microsoft's compiler. Also, as long as pretty much _any_ bugs that you're
likely 
to run into exist with the compiler, I'm going to be hard-pressed to convince 
them that switching any of our stuff to D would be worth it. So, I don't stand 
any chance of using D at work anytime soon. I think that some of my co-workers 
would be open to it if pretty much all of the major implementation issues of
dmd 
and the Windows linker were fixed, but until then, I can only dream...

A much more likely scenario would be to get to start using C++0x (which would
be 
a definite improvement), but even that is likely at least a couple of years off.

So, good luck with the new job! I envy you...

- Jonathan M Davis



 Feb 13 2011



prev sibling next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


Simen kjaeraas wrote:

 Having just landed a new job, I can now say that I will be using D in that
 job (but aren't using it yet).


Please keep us posted!



 Feb 13 2011



prev sibling  parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet>  writes:


On Mon, 14 Feb 2011 06:59:58 +0100, Simen kjaeraas wrote:


 Robert Clipsham <robert octarineparrot.com> wrote:
 

 Having seen a post by Peter Alexander (in Re: D for game development),
 mentioning some of the issues he's hit I thought I'd post this. I've
 been in his shoes (every other time I use D it seems), and feel I
 should ask - who here uses D, and to what extent?

 I'm mostly interested in those of you with 1000 Line plus projects in
 D, as that's when I've found I start hitting issues.

 Just to clarify, for those D purists among you... I'm not trolling,
 just curious (I wouldn't normally have asked, but now I know I'm not
 paranoid and the only one having problems, I thought I'd ask).


 
 Having just landed a new job, I can now say that I will be using D in
 that job (but aren't using it yet).


Gratulerer!  That is awesome.  Is it a company that uses D already, or 
did you convince them it was a good idea?  I'd be very interested to hear 
about any Norwegian companies that use D... ;)

-Lars



 Feb 14 2011



  parent  simendsjo <simen.endsjo pandavre.com>  writes:


Yes, gratulerer Simen!

We have used D on a couple of projects in the past. Due to the lack of
libraries and unstable toolchain, these projects are not updated
anymore. It was too much work having to work around compiler bugs and
each version broke external libraries too. This was around 1.007-1.028
and the big phobos/tango discussions. The lack of existing libraries
also made progress slow as we needed to do much ourselves.

We are lucky to work in a very pragmatic company that believes in "the
right tool for the job" and to let developers choose what they think
is the best tool. Hopefully we'll be able do more D in the future now
that Simen is onboard.



 Feb 14 2011