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