Re: Would You Bet $100,000,000 on D?
On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, and I suspect that given the current issues with the GC, if you were working on a AAA game, then you'd probably want the folks doing it to be good C/C++ programmers so that they would know how to do what needed doing when they can't use the GC or most of the standard libraries. For projects where performance isn't quite as critical, then D stands a much better chance of working. It _is_ easier to learn and has some definite advantages over C++. And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). I'm sure there are smaller reasons too, but I'm convinced the primary reason why AAA game dev is C++ instead of D is ultimately because of inertia, not the languages themselves, or even the tools (If the AAA game dev industry genuinely wanted to be using D, you can bet that any tools they needed would get made). As long as you stand much chance of running into a compiler bug, dmd just won't be up to snuff for many people. Most programmers are used to not having to worry at all about bugs in the compiler that they use. And tools are _very_ important to people, so D's lack of tools on par with many other, more popular languages is a major impediment. Yes, there's a lot of inertia that needs to be overcome for D to make a lot of traction in domains where C++ is currently king, but it's a lot more than just getting people to take a look at D. There are fundamental issues with D's current implementation which are a definite impediment. The situation is improving without a doubt, but it's still too rough for many programmers. I'm sure there are a lot of pet languages out that wouldn't measure up to this test, even for the people who are fans of such langauges, but I've been with D *specifically* because I see it as a genuinely compelling contender. Languages that have limited suitability automatically turn me off. For instance, I'm a huge fan of what I've seen about Nemerle: But because it's .NET-only and doesn't have much (if anything) in the way of low-level abilities, I've never even gotten around to downloading the compiler itself, let alone starting any projects in it. I really don't even see D as a pet language. To me it's a bread-and-butter langauge. And I took to it because the other bread-and-butter languages were getting to be anything but: C++'s bread was getting moldy and it's butter rancid, and Java is more of a Wonderbread with buttery-spread. Sure, sometimes the slices aren't even, and it might have some air bubbles, but that's still one hell of an improvement over rotten and/or manufactured. I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. - Jonathan M Davis
[OT] Schools and sheeple (was: Would You Bet $100,000,000 on D?)
Xavier x...@nospam.net wrote in message news:j50v3o$1gbb$1...@digitalmars.com... I think the public schools are teaching how to be a sheeple. What other reason could there be? Although I probably have about zero business sense, I absolutely agree on this part of what you said. At one point, I went to Bowling Green State University, well known to be an accept anyone and everyone even if we don't have enough room party school. Most of the students there generally thought for themselves (even if most of them weren't particularly bright.) Then I transfered to John Carroll University: a private school that, well, it's no Ivy-league, but it's fairly well-regarded, at least around the Cleveland area. Unlike BGSU, JCU is known to be fairly selective. But the vast majority of JCU students were complete mindless sheep. I'm being completely honest when I say it was actually somewhat disturbing how sheep-like they were. Of course, they were also just as dumb as the BGSU students, but unlike BGSU, most of them were uppity, conceited and had a noticeable tendency to mistake slogan and lecture regurgitation for intelligence, ability and independent thought. Conclusion: High schools specifically cultivate sheeple, which is a quality preferred by respectable colleges. I couldn't begin to speculate on why it's this way, or whether or not it's intentional by anyone who's still around. But whatever the reason, that's definitely how things are.
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com...
On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote:
People who are *good* at C++ are hard to find, and even harder to
cultivate.
And that's never going to change. It's a fundamental limitation of the
langauge (at least until the Vulcans finally introduce themselves to us).
But D's a lot easier for people to become good at.
It's a _lot_ easier to find good C++ programmers than good D programmers,
Oh, definitely. But what I meant was that good D programmers can be
cultivated. People can learn to be good at D. And while the same might
*technically* be true of C++, the curve is so steep that it may as well be
what's out there is what's out there. It's, more or less, a non-renewable
resource.
And then there's the enurmous savings in build times alone. Full
recompiles
of AAA C++ games are known to take upwards of a full day (not sure
whether
that's using a compile farm, but even if it is, D could still cut down on
compile farm expenses, or possibly even the need for one).
I'm sure there are smaller reasons too, but I'm convinced the primary
reason
why AAA game dev is C++ instead of D is ultimately because of inertia,
not
the languages themselves, or even the tools (If the AAA game dev industry
genuinely wanted to be using D, you can bet that any tools they needed
would get made).
As long as you stand much chance of running into a compiler bug, dmd just
won't be up to snuff for many people. Most programmers are used to not
having
to worry at all about bugs in the compiler that they use. And tools are
_very_
important to people, so D's lack of tools on par with many other, more
popular
languages is a major impediment.
Yes, there's a lot of inertia that needs to be overcome for D to make a
lot of
traction in domains where C++ is currently king, but it's a lot more than
just
getting people to take a look at D. There are fundamental issues with D's
current implementation which are a definite impediment. The situation is
improving without a doubt, but it's still too rough for many programmers.
I realize I've said this other times in the past, but I find that the
compiler bugs in DMD are much less severe than the language deficiencies of
a fully-bug-free C++ implementation.
Plus there's the idea of investing in the future to keep in mind: It's like
the old quote: I may be fat, but you're stupid. I can excersise and diet,
but stupid will always be stupid. D may have some bugs, but investing the
effort to deal with them will lead to further improvements. Dealing with
C++'s problems, OTOH, will hardly do a damn thing. Sure, a few things can be
mitigated somewhat, such as the C++0x^H^H1x^H^H2x^H^H3x improvents. But in
general, investing the effort to deal with C++'s shortcomings won't lead to
significant improvements - it *can't* because it's constrained by its
existing legacy design (not that that won't eventually happen to D, too, but
D is one generation past C++). Ie., D may be buggy, but C++ is crappy. Bugs
can be fixed, but crappy will always be crappy.
I definitely prefer D to C++, but I honestly think that your hatred of C++
(which you have expressed on several occasions) clouds your judgement on
the
matter.
FWIW, I had been a huge fan of C++ for many years and used it extensively
('course, that was quite awhile ago now...). And I *do* think it was a great
language back in it's time. I just think that time is long since past. When
I say C++ is crappy, I mean within today's context, and moving forward
from here. It's like the Apple II: I respect it, and I have fond (and a few
not-so-fond) memories of it, but neither of them would be among my first
choices for serious work anymore.
Many, many programmers are fine with C++, and while many programmers
may like C++ to be improved or would like a language that's similar to C++
but
without as many warts, that doesn't mean that they're going to be in a
hurry
to try out D. And many, many of the people who have problems with C++ use
languages such as C# and Java instead and are fine with that. D has a
major
uphill battle to truly become as relevant as any of those languages are
regardless of how much better it may be.
I'm certainly aware of all that, and I do understand. But the question here
wasn't Do you think OTHER people feel language X is suitable for serious
work? It was Do YOU think language X is suitable for serious work? I
don't doubt other people would disagree with me (especially people who
haven't used D, and even probably some who have), but my own answer is Yes,
I think D is suitable for such projects, and in such a situation, yes, I
would be willing to put my money where my mouth is.
Re: Would You Bet $100,000,000 on D?
Josh Simmons simmons...@gmail.com wrote in message news:mailman.2920.1316237301.14074.digitalmar...@puremagic.com... On Sat, Sep 17, 2011 at 2:55 PM, Sean Kelly s...@invisibleduck.org wrote: On Sep 16, 2011, at 7:09 PM, Xavier wrote: Peter Alexander wrote: I recently stumbled across this (old) blog post: http://prog21.dadgum.com/13.html In summary, the author asks if you were offered $100,000,000 for some big software project, While this is a silly little hypothetical thread (and it is Friday afterall so that probably explains the OP), I cannot fathom that amount being spent on just software on one project (though I've worked on one system, i.e., software + hardware, project worth 10's of millions). Maybe someone here can? Examples please, or give the largest one you can think of (it can be hypothetical). Remember, it's just software, not a system. Top-tier computer game budgets are tens of millions of dollars. Writing a AAA game in D would mean fixing a whole bunch of D, way easier to stick to what's proven. You'd have to disable the collector or make it better than every existing one, which in turn means you're not using most of the standard library. This is OK though since AAA games generally don't use standard library stuff anyway. You'd have to fix the codegen too (or maybe develop further ldc or gdc) and build new tools for just about everything. So basically sure you could do anything with enough money, but why would you do it the hard way? Keep in mind, most of a AAA game's codebase is externally-developed middleware these days. I think the middleware development sector would be willing to fix those issues if it meant being able to provide a more competitive offering (ie, their customers can use an easier to use/learn language, and don't need as many C++ gurus, etc). Of course, D will need more buzz in the game world to give middleware developers that push. But middleware provides a way around the question of Why would game developers do it the hard way? Their product may (arguably) end up the same either way for a game developer. But doing that hard stuff could make a middleware developer's product be more attractive (It's kinda like moving from C++ to C#, except you don't have that 5% performance hit, you have all this metaprogramming and concurrency stuff C++ and C# don't have, and you're not locked into MS platforms.). So there's the motivation for the hard way. Of course, personally, I'd consider using an already-working-but-C++-based toolchain to be the hard way, but that's me.
Re: Would You Bet $100,000,000 on D?
Nick Sabalausky a@a.a wrote in message news:j51ia4$2ivm$1...@digitalmars.com... (It's kinda like moving from C++ to C#, That is, C# and/or XNA. except you don't have that 5% performance hit, you have all this metaprogramming and concurrency stuff C++ and C# don't have, and you're not locked into MS platforms.).
Re: Would You Bet $100,000,000 on D?
Nick Sabalausky a@a.a wrote in message
news:j51h52$2h0e$1...@digitalmars.com...
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com...
On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote:
People who are *good* at C++ are hard to find, and even harder to
cultivate.
And that's never going to change. It's a fundamental limitation of
the
langauge (at least until the Vulcans finally introduce themselves to
us).
But D's a lot easier for people to become good at.
It's a _lot_ easier to find good C++ programmers than good D
programmers,
Oh, definitely. But what I meant was that good D programmers can be
cultivated. People can learn to be good at D. And while the same might
*technically* be true of C++, the curve is so steep that it may as well
be what's out there is what's out there. It's, more or less, a
non-renewable resource.
It's not nearly as steep as it used to be, for C++, the tools, the
techniques, the documentation, the users have matured and one need not
struggle through everything on one's own anymore while learning it, but
rather just go look up or ask for the answer, and it is still improving.
Sure, if one exploits every stupid template trick and similarly with
the other language features, then you will have steep, but it is quite
tractable these days if one isn't overzealous and able to separate all
the jabber about metaprogramming and the like from the meat of the
language. It will always have its warts, but D has many of the same ones.
I realize I've said this other times in the past, but I find that the
compiler bugs in DMD are much less severe than the language
deficiencies of a fully-bug-free C++ implementation.
That's an interesting, if not odd, statement considering that C++ are
more alike than they are different.
Plus there's the idea of investing in the future to keep in mind: It's
like the old quote: I may be fat, but you're stupid. I can excersise
and diet, but stupid will always be stupid.
The truth of the matter is, though, that she won't exercise to any
significant degree and has been on a diet her whole life and her weight
has continually increased. On top of that, the fact that one can study,
research and learn escapes the fat dumb blonde bimbo because she indeed
is stupid, and that's why her dieting causes her to gain weight instead
of lose it.
D may have some bugs, but investing the effort to deal with them will
lead to further improvements. Dealing with C++'s problems, OTOH, will
hardly do a damn thing.
Again, I find that a curious statement for reason noted. The language
names even fit together: C/C++/D. There is no denying that they are all
related. Just look at those noses! C'mon!
Sure, a few things can be mitigated somewhat, such as the
C++0x^H^H1x^H^H2x^H^H3x improvents. But in general, investing the
effort to deal with C++'s shortcomings won't lead to significant
improvements - it *can't* because it's constrained by its existing
legacy design (not that that won't eventually happen to D, too, but D
is one generation past C++).
One generation away, but still the same family. So what?
Ie., D may be buggy, but C++ is crappy. Bugs can be fixed, but crappy
will always be crappy.
All adolescents conflict with their parents and say things like that.
When D grows up, the D++ or E kids will be maligning D and then D will
remember back how it was just the same when it was just a youngster.
I definitely prefer D to C++, but I honestly think that your hatred of
C++
(which you have expressed on several occasions) clouds your judgement
on the
matter.
FWIW, I had been a huge fan of C++ for many years and used it
extensively ('course, that was quite awhile ago now...). And I *do*
think it was a great language back in it's time. I just think that time
is long since past.
I think C++ is now coming into it's own and it sucked in the past much
more. D is now in it's sucky period IMO, and may have it's day in the
future. Time will tell.
When I say C++ is crappy, I mean within today's context, and moving
forward from here.
Tomorrow is surely something else, probably not D, IMO, but today is all
C++.
I'm certainly aware of all that, and I do understand. But the question
here wasn't Do you think OTHER people feel language X is suitable for
serious work? It was Do YOU think language X is suitable for serious
work? I don't doubt other people would disagree with me (especially
people who haven't used D, and even probably some who have), but my own
answer is Yes, I think D is suitable for such projects, and in such a
situation, yes, I would be willing to put my money where my mouth is.
Ha! I inadvertently just answered those questions. Well, I guess you know
what I think now (not that I was going to hide it).
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be better somehow, maybe for some of it's neat features? Perhaps D just has to grow up before it can battle anywhere, let alone on hills?
Re: Would You Bet $100,000,000 on D?
On Sat, Sep 17, 2011 at 5:30 PM, Nick Sabalausky a@a.a wrote: Keep in mind, most of a AAA game's codebase is externally-developed middleware these days. I think the middleware development sector would be willing to fix those issues if it meant being able to provide a more competitive offering (ie, their customers can use an easier to use/learn language, and don't need as many C++ gurus, etc). You need high performance code gurus, the need for C++ people in non-performance critical code is already alleviated by the scripting world. I disagree with your middleware statement too, most middleware at this level is created by in house teams and then sold on for other titles. For example CryEngine, Unreal Engine, id tech, source engine. Other AAA engines are used entirely in-studio for example IW's engine(s) for the CoD series games and Frostbite for the newer battlefield games. The other problem with this idea is that the middleware needs to play nice with other middleware like physics libraries, ai libraries and other specialised bits of software like speedtree, which typically are written in C++. All of these layers need to be highly tuned for performance across many platforms including the console world. At this level the switch to C# provides much more than a 5% performance hit too, it makes the whole thing unfeasible. My feeling is that the same is true of D due mostly to immature tooling. The indie world however, is much more accommodating, the budgets are lower and programmer productivity more important. Their performance requirements are much lower and their willingness to play with new tools is much greater. Make these guys happy and then down the track the rest of the gaming world might follow.
Re: Would You Bet $100,000,000 on D?
On Saturday, September 17, 2011 02:26:12 Xavier wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be better somehow, maybe for some of it's neat features? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? The language itself is superior. It's the implementation which has issues, though those have been being resolved at a fairly fast pace of late. - Jonathan M Davis
Re: [OT] Schools and sheeple (was: Would You Bet $100,000,000 on D?)
Nick Sabalausky a@a.a wrote in message news:j51ef3$2a0d$1...@digitalmars.com... Xavier x...@nospam.net wrote in message news:j50v3o$1gbb$1...@digitalmars.com... I think the public schools are teaching how to be a sheeple. What other reason could there be? Although I probably have about zero business sense, I absolutely agree on this part of what you said. At one point, I went to Bowling Green State University, well known to be an accept anyone and everyone even if we don't have enough room party school. Most of the students there generally thought for themselves (even if most of them weren't particularly bright.) Then I transfered to John Carroll University: a private school that, well, it's no Ivy-league, but it's fairly well-regarded, at least around the Cleveland area. Unlike BGSU, JCU is known to be fairly selective. But the vast majority of JCU students were complete mindless sheep. I'm being completely honest when I say it was actually somewhat disturbing how sheep-like they were. Of course, they were also just as dumb as the BGSU students, but unlike BGSU, most of them were uppity, conceited and had a noticeable tendency to mistake slogan and lecture regurgitation for intelligence, ability and independent thought. Conclusion: High schools specifically cultivate sheeple, which is a quality preferred by respectable colleges. I couldn't begin to speculate on why it's this way, or whether or not it's intentional by anyone who's still around. But whatever the reason, that's definitely how things are. The most surprising thing to me is that it seems to work! It could be that most people simply are not very smart from the get go so they believe everything they read and are told and trust anyone and everyone. That's not it. (Well at first it may be, but surely at some point one becomes able to discern information of value from BS). It's not an intelligence thing. It's something else. I think I know what it is, but this is not the place to get into it. I do think that some of it shows thru a little in some of my posts. Then again, maybe the fat blonde bimbo is skinny now and I'm still stupid. Nah, that's not it. Certainly not.
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2923.1316247041.14074.digitalmar...@puremagic.com... On Saturday, September 17, 2011 02:26:12 Xavier wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be better somehow, maybe for some of it's neat features? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? The language itself is superior. A family of languages goes from crappy to superior in one generation? Umm, I don't think so, fan boy. ;) It's the implementation which has issues, though those have been being resolved at a fairly fast pace of late. It's not just that, though I believe that you think that.
Re: Would You Bet $100,000,000 on D?
On Saturday, September 17, 2011 03:17:27 Xavier wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2923.1316247041.14074.digitalmar...@puremagic.com... The language itself is superior. A family of languages goes from crappy to superior in one generation? Umm, I don't think so, fan boy. ;) ??? I didn't say anything about the family of languages. I said that D, as a language, is superior to C++. - Jonathan M Davis
Re: Would You Bet $100,000,000 on D?
Xavier x...@nospam.net wrote in message news:j51jsp$2lln$1...@digitalmars.com... Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be better somehow, maybe for some of it's neat features? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? In both this and your other post, you're conflating the notions of the language quality vs implementation quality. The two are not the same. Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So no, it's NOT a contradiction that D can be a better language while still having implementation issues.
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2924.1316247900.14074.digitalmar...@puremagic.com... On Saturday, September 17, 2011 03:17:27 Xavier wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2923.1316247041.14074.digitalmar...@puremagic.com... The language itself is superior. A family of languages goes from crappy to superior in one generation? Umm, I don't think so, fan boy. ;) ??? I didn't say anything about the family of languages. I know you didn't, I did. Read my post in response to Nick's post. I said that D, as a language, is superior to C++. Yeah, yeah... OK fan boy. ;)
Re: Would You Bet $100,000,000 on D?
Xavier x...@nospam.net wrote in message
news:j51jsp$2lln$2...@digitalmars.com...
Nick Sabalausky a@a.a wrote in message
news:j51h52$2h0e$1...@digitalmars.com...
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com...
On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote:
People who are *good* at C++ are hard to find, and even harder to
cultivate.
And that's never going to change. It's a fundamental limitation of the
langauge (at least until the Vulcans finally introduce themselves to
us).
But D's a lot easier for people to become good at.
It's a _lot_ easier to find good C++ programmers than good D
programmers,
Oh, definitely. But what I meant was that good D programmers can be
cultivated. People can learn to be good at D. And while the same might
*technically* be true of C++, the curve is so steep that it may as well
be what's out there is what's out there. It's, more or less, a
non-renewable resource.
It's not nearly as steep as it used to be, for C++, the tools, the
techniques, the documentation, the users have matured and one need not
struggle through everything on one's own anymore while learning it, but
rather just go look up or ask for the answer, and it is still improving.
Sure, if one exploits every stupid template trick and similarly with the
other language features, then you will have steep, but it is quite
tractable these days if one isn't overzealous and able to separate all the
jabber about metaprogramming and the like from the meat of the language.
It will always have its warts, but D has many of the same ones.
In other words, C++ is easy^H^H^H^Hless hard than it used to be, as long as
you don't use any of the advanced features that are already trivial in D
anyway.
I realize I've said this other times in the past, but I find that the
compiler bugs in DMD are much less severe than the language deficiencies
of a fully-bug-free C++ implementation.
That's an interesting, if not odd, statement considering that C++ are more
alike than they are different.
I don't understand what you're saying here. Did you mean D and C++ are more
alike than different, or C++ implementations are more alike than are
different. Either way, it doesn't make much sense.
Plus there's the idea of investing in the future to keep in mind: It's
like the old quote: I may be fat, but you're stupid. I can excersise and
diet, but stupid will always be stupid.
The truth of the matter is, though, that she won't exercise to any
significant degree and has been on a diet her whole life and her weight
has continually increased. On top of that, the fact that one can study,
research and learn escapes the fat dumb blonde bimbo because she indeed is
stupid, and that's why her dieting causes her to gain weight instead of
lose it.
You've just completely broken the analogy because D's bugs *DO* get fixed.
And they're getting fixed rather quickly now, too.
D may have some bugs, but investing the effort to deal with them will
lead to further improvements. Dealing with C++'s problems, OTOH, will
hardly do a damn thing.
Again, I find that a curious statement for reason noted. The language
names even fit together: C/C++/D. There is no denying that they are all
related. Just look at those noses! C'mon!
Umm, yea, they're related. So what? Don't tell me you're trying to imply
that just because they're related they're inherently equal in everything but
implementation.
Sure, a few things can be mitigated somewhat, such as the
C++0x^H^H1x^H^H2x^H^H3x improvents. But in general, investing the effort
to deal with C++'s shortcomings won't lead to significant improvements -
it *can't* because it's constrained by its existing legacy design (not
that that won't eventually happen to D, too, but D is one generation past
C++).
One generation away, but still the same family. So what?
Ie., D may be buggy, but C++ is crappy. Bugs can be fixed, but crappy
will always be crappy.
All adolescents conflict with their parents and say things like that. When
D grows up, the D++ or E kids will be maligning D and then D will remember
back how it was just the same when it was just a youngster.
Are you seriously trying say that that implies each successive one is
inherently no better than the previous? If so, then that's just patently
absurd. If not, then what in the world *is* your point? Just to troll?
I definitely prefer D to C++, but I honestly think that your hatred of
C++
(which you have expressed on several occasions) clouds your judgement on
the
matter.
FWIW, I had been a huge fan of C++ for many years and used it extensively
('course, that was quite awhile ago now...). And I *do* think it was a
great language back in it's time. I just think that time is long since
past.
I think C++ is now coming into it's own and it sucked in the past
Re: [OT] Schools and sheeple (was: Would You Bet $100,000,000 on D?)
Xavier x...@nospam.net wrote in message news:j51kmt$2n7t$1...@digitalmars.com... Nick Sabalausky a@a.a wrote in message news:j51ef3$2a0d$1...@digitalmars.com... Xavier x...@nospam.net wrote in message news:j50v3o$1gbb$1...@digitalmars.com... I think the public schools are teaching how to be a sheeple. What other reason could there be? Although I probably have about zero business sense, I absolutely agree on this part of what you said. At one point, I went to Bowling Green State University, well known to be an accept anyone and everyone even if we don't have enough room party school. Most of the students there generally thought for themselves (even if most of them weren't particularly bright.) Then I transfered to John Carroll University: a private school that, well, it's no Ivy-league, but it's fairly well-regarded, at least around the Cleveland area. Unlike BGSU, JCU is known to be fairly selective. But the vast majority of JCU students were complete mindless sheep. I'm being completely honest when I say it was actually somewhat disturbing how sheep-like they were. Of course, they were also just as dumb as the BGSU students, but unlike BGSU, most of them were uppity, conceited and had a noticeable tendency to mistake slogan and lecture regurgitation for intelligence, ability and independent thought. Conclusion: High schools specifically cultivate sheeple, which is a quality preferred by respectable colleges. I couldn't begin to speculate on why it's this way, or whether or not it's intentional by anyone who's still around. But whatever the reason, that's definitely how things are. The most surprising thing to me is that it seems to work! It could be that most people simply are not very smart from the get go so they believe everything they read and are told and trust anyone and everyone. That's not it. I almost wish it were. Then I could just say, No, it's like this... Problem solved. Or better yet, Go make me a sandwich. Better problem solved :) (Well at first it may be, but surely at some point one becomes able to discern information of value from BS). It's not an intelligence thing. It's something else. I think I know what it is, but this is not the place to get into it. I do think that some of it shows thru a little in some of my posts. Then again, maybe the fat blonde bimbo is skinny now and I'm still stupid. Nah, that's not it. Certainly not.
Re: Would You Bet $100,000,000 on D?
On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalausky a@a.a wrote: Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? No I believe the implication is that absolute quality is so absurdly impossible to define that it's somewhat irrelevant to even contemplate it. And it's certainly overly simplistic to consider it without putting it in the context of a given problem. Yes C++ is crap, but so is D, they're both crappy in their own ways, to suggest otherwise is to assume that you're so much more intelligent than all that have come before you that you've managed to create a perfect product when all else have failed. To make analogy, it's like saying that OOP is inherently better than any paradigm before it. Ultimately though the issue is that C++'s crap is well explored and known, D's crap is significantly less so. Whether this is an issue for you depends entirely on your context.
Re: Would You Bet $100,000,000 on D?
On 09/17/2011 10:40 AM, Xavier wrote: Jonathan M Davisjmdavisp...@gmx.com wrote in message news:mailman.2924.1316247900.14074.digitalmar...@puremagic.com... On Saturday, September 17, 2011 03:17:27 Xavier wrote: Jonathan M Davisjmdavisp...@gmx.com wrote in message news:mailman.2923.1316247041.14074.digitalmar...@puremagic.com... The language itself is superior. A family of languages goes from crappy to superior in one generation? Umm, I don't think so, fan boy. ;) ??? I didn't say anything about the family of languages. I know you didn't, I did. Read my post in response to Nick's post. I said that D, as a language, is superior to C++. Yeah, yeah... OK fan boy. ;) Don't feed the troll.
Re: [OT] Schools and sheeple
On 9/17/11 10:51 AM, Nick Sabalausky wrote: I almost wish it were. Then I could just say, No, it's like this... Problem solved. Or better yet, Go make me a sandwich. Better problem solved :) Have you tried using »sudo go make me a sandwich«? ;) David
Re: Would You Bet $100,000,000 on D?
Nick Sabalausky a@a.a wrote in message news:j51m0l$2prg$1...@digitalmars.com... Xavier x...@nospam.net wrote in message news:j51jsp$2lln$1...@digitalmars.com... Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be better somehow, maybe for some of it's neat features? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? In both this and your other post, you're conflating the notions of the language quality vs implementation quality. The two are not the same. They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language quality issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like D is better than the POS that C++ is. To be markedly different from C++, D would have to be thought of as being in a different category than which is the better POS?, but of course it cannot, for it comes from the same family, one generation newer than C++. Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas. An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that. And notice too that for software development that is not that, intellisense dramatically reduces the number of times a programmer hits the compile button. That one thing is not as big an issue and certainly it pales in comparison to other language design flaws, which C++ and D both share. So no, it's NOT a contradiction that D can be a better language while still having implementation issues. Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship.
Re: Would You Bet $100,000,000 on D?
On 09/17/2011 10:57 AM, Josh Simmons wrote: On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalauskya@a.a wrote: Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? No I believe the implication is that absolute quality is so absurdly impossible to define that it's somewhat irrelevant to even contemplate it. And it's certainly overly simplistic to consider it without putting it in the context of a given problem. Well, my pragmatic and simplistic definition of language quality is how fast work is done using that particular language. And in my experience I get hella lot of more work done in less time in D. Yes C++ is crap, but so is D, they're both crappy in their own ways, What matters is the amount of crap. And D wins that game. to suggest otherwise is to assume that you're so much more intelligent than all that have come before you that you've managed to create a perfect product when all else have failed. D has the advantage of hindsight. One is always more intelligent afterwards, so assuming that one knows more than the ones before is realistic. That is how progress works. To make analogy, it's like saying that OOP is inherently better than any paradigm before it. Ultimately though the issue is that C++'s crap is well explored and known, D's crap is significantly less so. Whether this is an issue for you depends entirely on your context. Exploring crap is lost time. (and you stink afterwards, ftw!) If a language forces you to explore it's crap well to save your legs from being blown off, that is quite poor imho. You have to know what _works_.
Re: Would You Bet $100,000,000 on D?
Josh Simmons simmons...@gmail.com wrote in message news:mailman.2922.1316246434.14074.digitalmar...@puremagic.com... On Sat, Sep 17, 2011 at 5:30 PM, Nick Sabalausky a@a.a wrote: Keep in mind, most of a AAA game's codebase is externally-developed middleware these days. I think the middleware development sector would be willing to fix those issues if it meant being able to provide a more competitive offering (ie, their customers can use an easier to use/learn language, and don't need as many C++ gurus, etc). You need high performance code gurus, the need for C++ people in non-performance critical code is already alleviated by the scripting world. Hmm, perhaps. Although I kinda have to agree with Carmack on game scripting not being such a great idea in the first place (Not that I feel that way because he said it). He also said said something in his last keynote that caught my attention, something about all that game scripting actually being more costly to performance than most people think. I don't know/remember the details, though. Although, coming from a guy who's idea of high-performace seems to have turned into require a super-computer with expensive game-dedicated hardware these days, I'm not sure how much I can still trust his stance on what code is/isn't fast anymore...But I guess I'm just being cynical... I disagree with your middleware statement too, most middleware at this level is created by in house teams and then sold on for other titles. For example CryEngine, Unreal Engine, id tech, source engine. Renderware, Gamebryo, Unity, Vision Engine, and none-engine stuff like Havok, Although I admit I wouldn't know anything about maketshare. Other AAA engines are used entirely in-studio for example IW's engine(s) for the CoD series games and Frostbite for the newer battlefield games. The other problem with this idea is that the middleware needs to play nice with other middleware like physics libraries, ai libraries and other specialised bits of software like speedtree, which typically are written in C++. Yea, I suppose engine would be the key one. All of these layers need to be highly tuned for performance across many platforms including the console world. At this level the switch to C# provides much more than a 5% performance hit too, it makes the whole thing unfeasible. My feeling is that the same is true of D due mostly to immature tooling. With D it's not an intractable issue, though. The indie world however, is much more accommodating, the budgets are lower and programmer productivity more important. Their performance requirements are much lower and their willingness to play with new tools is much greater. Make these guys happy and then down the track the rest of the gaming world might follow. Oh, absolutely. Totally agree. In fact that's where I am...Or...would be...if I wasn't stuck in this perpetual web-dev hell...
Re: Would You Bet $100,000,000 on D?
On 2011-09-17 00:34, Peter Alexander wrote: This is exactly what I was thinking, and it's even more true now that D has two fully open-source compilers. GDC is almost usable on x86 already. (Almost here means there's one showstopper bug that keeps me from using it for real work.) I'm sure you could hire a dev or two to get it working well on ARM and/or PowerPC. Think of all the money you'd save by not having to hire a bunch of extra people to write and maintain mountains of boilerplate. Remember: 1. You don't get the money until the job is done. Is that really realistic for a large project like this. I assume it's a large project regarding the money involved. Wouldn't you divide the project in several smaller projects and get paid for the smaller projects? -- /Jacob Carlborg
Re: Would You Bet $100,000,000 on D?
On 09/17/2011 11:17 AM, Xavier wrote: Nick Sabalauskya@a.a wrote in message news:j51m0l$2prg$1...@digitalmars.com... Xavierx...@nospam.net wrote in message news:j51jsp$2lln$1...@digitalmars.com... Jonathan M Davisjmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be better somehow, maybe for some of it's neat features? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? In both this and your other post, you're conflating the notions of the language quality vs implementation quality. The two are not the same. They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language quality issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like D is better than the POS that C++ is. To be markedly different from C++, D would have to be thought of as being in a different category than which is the better POS?, but of course it cannot, for it comes from the same family, one generation newer than C++. Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas. An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that. And notice too that for software development that is not that, intellisense dramatically reduces the number of times a programmer hits the compile button. I don't need intellisense, I'm fine with emacs. And compiling D code is usually so much faster than compiling C++ code that it is not even funny. Recompiling is not costly at all. That one thing is not as big an issue and certainly it pales in comparison to other language design flaws, which C++ and D both share. Exactly which flaws are you talking about? Either get concrete so that your statements can be discussed and someone gets smarter in the process or stop making noise please. So no, it's NOT a contradiction that D can be a better language while still having implementation issues. Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). Well, nobody wants to convince you that D and C++ don't belong to the same category. (as far language design goes). Whatever that means to you. But talking is worthless indeed. All your arguments are based on the wrong assumption that C++
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis wrote: On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, and I suspect that given the current issues with the GC, if you were working on a AAA game, then you'd probably want the folks doing it to be good C/C++ programmers so that they would know how to do what needed doing when they can't use the GC or most of the standard libraries. For projects where performance isn't quite as critical, then D stands a much better chance of working. It _is_ easier to learn and has some definite advantages over C++. Any programmer should be able to learn any language on the job. This doesn't make sense for small projects, but for larger projects the overhead can be small enough to warrant hiring competent programmers without any knowledge of the language. D is familiar enough for C++/C#/Java programmers to pick it up quickly. Especially for C++ programmers, given a sufficiently large timescale, it is not unthinkable that all time spent learning is recuperated by the productivity and scalability gains. I just cannot image a good C++ programmer having difficulty picking up D quickly.
Re: Would You Bet $100,000,000 on D?
Xavier x...@nospam.net wrote in message news:j51p5q$2utg$1...@digitalmars.com... Nick Sabalausky a@a.a wrote in message news:j51m0l$2prg$1...@digitalmars.com... In both this and your other post, you're conflating the notions of the language quality vs implementation quality. The two are not the same. They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language quality issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like D is better than the POS that C++ is. To be markedly different from C++, D would have to be thought of as being in a different category than which is the better POS?, but of course it cannot, for it comes from the same family, one generation newer than C++. Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas. What you're ultimately saying is that if a guitar has a crappy first and second string (and therefore sounds lousy), then you also have to replace the other four strings, the pickups, the head, the body, the amp, the neck and the carrying case to make it sound good again. Replacing the two crappy strings won't be enough to make it sound significantly better. What you're missing is that a minority portion *can* ruin a whole. If you consider D and C++ to be mostly the same, then C++ is crappy because of, what you're perceiving to be, a minority subset of it's design. D cuts out the cancer and saves the whole. Your notion that a big imporvement requires a big change is just plain false. An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that. You know perfectly well those were just examples. And notice too that for software development that is not that, intellisense dramatically reduces the number of times a programmer hits the compile button. That one thing is not as big an issue and certainly it pales in comparison to other language design flaws, which C++ and D both share. 1. IDE features are not substitutes for language improvement. 2. Such features don't end up in a IDE for free. There's cost associated with actually putting them in there for a given language. You're not factoring that in. Additionally, this also implies that not everyone always has such features available. So no, it's NOT a contradiction that D can be a better language while still having implementation issues. Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship. Yes, because if one boat starts sinking, they're all about to start sinking... And if you felt sick due to kidney failure, you'd insist that replacing the kidney will just make you slightly less sick. So you'd insist the doctor also replace your
Re: Would You Bet $100,000,000 on D?
On Sat, Sep 17, 2011 at 7:34 PM, Nick Sabalausky a@a.a wrote: Renderware, Gamebryo, Unity, Vision Engine, and none-engine stuff like Havok, Although I admit I wouldn't know anything about maketshare. Well RenderWare doesn't exist anymore, Bing Gordon, an EA executive, has stated that RenderWare didn't perform well enough for next-gen[clarification needed] and that RenderWare didn't stand up to competition from Epic Games. He has also stated that the RenderWare team is mostly a dev house (indicating that EA is reluctant to still use RenderWare)., Gamebryo at last I heard was no longer developed since the parent company went bust, Unity is really an indie outfit, and I don't know much about Vision Engine. There's also no way you could write Havok in D since nobody would purchase middleware they couldn't use in their existing codebases. (with their existing tools, too) If you wanted to break into Unity's market (good luck with that) though, D might be a reasonable choice. Although the language flexibility of Mono seems to be working in their favor.
Re: [OT] Schools and sheeple
David Nadlinger s...@klickverbot.at wrote in message news:j51nfi$2rjc$1...@digitalmars.com... On 9/17/11 10:51 AM, Nick Sabalausky wrote: I almost wish it were. Then I could just say, No, it's like this... Problem solved. Or better yet, Go make me a sandwich. Better problem solved :) Have you tried using »sudo go make me a sandwich«? ;) XKCD FTW :) Absolutely fantastic comic. Since it's so late and I'm therefore so tired that I'm impulsive again, I'm going to list some other fantastic webcomics: - Bunny - Extra Life - VG Cats - Sexy Losers (NSFW, although I'm not sure it's even around anymore) - Perry Bible Fellowship (not at all what it sounds like)
Re: [OT] Schools and sheeple
David Nadlinger s...@klickverbot.at wrote in message news:j51nfi$2rjc$1...@digitalmars.com... On 9/17/11 10:51 AM, Nick Sabalausky wrote: I almost wish it were. Then I could just say, No, it's like this... Problem solved. Or better yet, Go make me a sandwich. Better problem solved :) Have you tried using »sudo go make me a sandwich«? ;) David Ah yes - the old favourite... :-) http://xkcd.com/149/ -=mike=-
Re: Issue 4705
Am 16.09.2011 23:38, schrieb Andrei Alexandrescu: On 9/16/11 3:54 PM, Timon Gehr wrote: On 09/16/2011 10:35 PM, Simen Kjaeraas wrote: On Fri, 16 Sep 2011 22:16:59 +0200, Timon Gehr timon.g...@gmx.ch wrote: I suggest: * Introduce the algorithm extremum with a required predicate. What would that do? The range has more than one extremum if it is non-constant. extremum!ab([1,2,3,1,2,3]) would be equal to [1,1]. (BTW I thought of just returning the first found, so only 1.) That is not extremum. It is min. Indeed extremum is not as good a name because it means an extreme value of a unary function over an interval. Extending this to relations is a bit forced. The example shows min, but the difficulty in finding a good name is that such a name would be meaningful in both of these cases: xyz!ab([1,2,3,1,2,3]) is 1 xyz!ab([1,2,3,1,2,3]) is 3 Question is what's a good name for xyz. It returns the element X of the range such that pred(E, X) is false for all E in the range. Then we'd defined xyzCount and xyzPos and call it a day. [...] Andrei What about ultimum? It means the last or the outermost.
Re: Issue 4705
On 09/17/2011 03:55 PM, Mafi wrote: Am 16.09.2011 23:38, schrieb Andrei Alexandrescu: On 9/16/11 3:54 PM, Timon Gehr wrote: On 09/16/2011 10:35 PM, Simen Kjaeraas wrote: On Fri, 16 Sep 2011 22:16:59 +0200, Timon Gehr timon.g...@gmx.ch wrote: I suggest: * Introduce the algorithm extremum with a required predicate. What would that do? The range has more than one extremum if it is non-constant. extremum!ab([1,2,3,1,2,3]) would be equal to [1,1]. (BTW I thought of just returning the first found, so only 1.) That is not extremum. It is min. Indeed extremum is not as good a name because it means an extreme value of a unary function over an interval. Extending this to relations is a bit forced. The example shows min, but the difficulty in finding a good name is that such a name would be meaningful in both of these cases: xyz!ab([1,2,3,1,2,3]) is 1 xyz!ab([1,2,3,1,2,3]) is 3 Question is what's a good name for xyz. It returns the element X of the range such that pred(E, X) is false for all E in the range. Then we'd defined xyzCount and xyzPos and call it a day. [...] That is the definition of a minimum. pred is the order relation and the range gives the set. Ergo xyz=min. But that is were we are. Andrei What about ultimum? It means the last or the outermost. As long as the function computes a least element, any names other than leastElem* or min* are just confusing. 'ultimum' is not specific enough. Does it compute a least element or a greatest element? The approach of having a name that includes both max and min cannot work in a satisfiable way for that reason.
Re: Would You Bet $100,000,000 on D?
On 17/09/11 3:09 AM, Xavier wrote: Peter Alexander wrote: I recently stumbled across this (old) blog post: http://prog21.dadgum.com/13.html In summary, the author asks if you were offered $100,000,000 for some big software project, While this is a silly little hypothetical thread (and it is Friday afterall so that probably explains the OP), I cannot fathom that amount being spent on just software on one project (though I've worked on one system, i.e., software + hardware, project worth 10's of millions). Maybe someone here can? Examples please, or give the largest one you can think of (it can be hypothetical). Remember, it's just software, not a system. The number is unimportant. It's just a placeholder. Could just be $100k if that makes it easier. It's just a thought experiment: being honest, would you use D for a large project with high stakes?
Re: Would You Bet $100,000,000 on D?
On 9/17/11 9:53 AM, Peter Alexander wrote: On 17/09/11 3:09 AM, Xavier wrote: Peter Alexander wrote: I recently stumbled across this (old) blog post: http://prog21.dadgum.com/13.html In summary, the author asks if you were offered $100,000,000 for some big software project, While this is a silly little hypothetical thread (and it is Friday afterall so that probably explains the OP), I cannot fathom that amount being spent on just software on one project (though I've worked on one system, i.e., software + hardware, project worth 10's of millions). Maybe someone here can? Examples please, or give the largest one you can think of (it can be hypothetical). Remember, it's just software, not a system. The number is unimportant. It's just a placeholder. Could just be $100k if that makes it easier. It's just a thought experiment: being honest, would you use D for a large project with high stakes? Well I did (which makes it less of a Gedankenexperiment). My doctorate is in machine learning applied to NLP, and a lot of research in this field consists of systems building. (It's quite surprising, really - once you have the data, the paper can be written the night before the submission.) The stakes were quite high to me personally - I had just switched fields (and statistically most who do give up later on), the field was new to me, I'd started a family, not to mention I was incurring opportunity losses in income. Being unable to complete my doctorate or spending much longer on it would have been quite a disaster. Andrei
Re: Would You Bet $100,000,000 on D?
On 9/17/11 4:17 CDT, Xavier wrote: Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship. One's favorite language has most to do with a handful of fundamental dimensions (dominant paradigm(s), approach to typing, look and feel, regard to efficiency, connection to problem domain vs. machine, and a few more). A coworker of mine, for example, doesn't mind a speed penalty of 2-5x, likes modeling power and semantic cleanliness, and is okay with some amount of code duplication. His favorite language is OCaml, and I'd probably choose the same if I had the same preferences. For those who want at the same time like low-level access, modeling power, generic programming, and efficiency, OCaml wouldn't rank high in the list of preferences, and there wouldn't be many games in town. In your metaphor, swimming from a ship to an island would entail trading something that C++ offers for something it can't offer - which is fine. If, on the other hand, you'd rather keep to the fundamentals above, D is arguably a better language. One other thing is flexibility once the choice has been made. Python is a great Python but an awful C++, not to mention the converse. D, on the other hand, is arguably a much better C++ and also a pretty good Python. Andrei
Re: Would You Bet $100,000,000 on D?
On 17/09/11 6:53 AM, Nick Sabalausky wrote: Peter Alexanderpeter.alexander...@gmail.com wrote in message For example, if the job was to produce a AAA video game that ran on PC, PS3 and XBox 360, I'm sure you could *do it* with D if you paid people to develop the compiler tech and tools to produce PowerPC code and interface with all MS's and Sony's libraries and tools. But would you? People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. You don't need people that are especially good at C++. You don't need to know metaprogramming or generic programming or the intricacies of templates to ship a product. Just look at the DMD compiler: there's no advanced C++ in there at all. It still works. And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. I am unaware of any distributed, incremental build systems for D, so I see no particular speed advantage to using D (certainly not orders of magnitude anyway). I'm sure there are smaller reasons too, but I'm convinced the primary reason why AAA game dev is C++ instead of D is ultimately because of inertia, not the languages themselves, or even the tools (If the AAA game dev industry genuinely wanted to be using D, you can bet that any tools they needed would get made). Tools are not free. Don't assume just because a company is large that it has unlimited funds. Creating tools, converting libraries all take lots of time and money that have to be justified. I work at a very large game studio and I can assure you that I would *never* be able to justify using D for a project. Even if all our code magically transformed into D, and all our programmers knew D, I still wouldn't be able to justify the creation of all the necessary tools and dev systems to do something that we can already do.
Re: Would You Bet $100,000,000 on D?
Josh Simmons wrote: So basically sure you could do anything with enough money, but why would you do it the hard way? Because it will pay off in the longer term. When I started writing web apps in D, it looked hard. I'd have to get it compiling for the production server. Have to get my app to interact with the web server somehow. Have to talk to the database server. Have to read input from the browser. That's just to get started. Then, it'd have to interact with existing code, talk to external web services (http client and oauth), maintain user sessions, and do html templating in some kind of remotely sane way. I might have to explain to clients and investors the advantages too, and deal with whatever else comes up as time goes on - images, desktop ports, and more ended up being needed too. Sounds like a lot of effort when I could just write PHP or any number of other existing things right now. But, I knew that would pay for itself over time... and it was actually even /better/ than I expected. Writing those libraries went faster than I thought, partially thanks to being able to use C libraries, and partially because it wasn't really that hard anyway once I sat down and got started. Compiling ended up being trivial - just a make -f posix.mak on the server environment did the job making my dmd. Justifying the choice was simple too: it's significantly more productive, both to code and to write, than the alternatives, and someone reasonably competent can learn it in a single day. This up front investment has paid for itself a hundred times over. Is my project representative of the OP's scenario? I don't know for sure. But I'd be willing to place a big bet on yes.
Re: Unittesting in static libraries
Steven Schveighoffer wrote:
On Fri, 16 Sep 2011 15:14:50 -0400, Jérôme M. Berger jeber...@free.fr
wrote:
Andrej Mitrovic wrote:
I'd like to turn some attention to unittests, which don't seem to work
with static libraries. Consider:
.\main.d:
import mylib.test;
void main()
{
auto x = foo();
}
.\mylib\test.d
module mylib.test;
int foo() { return 1; }
unittest { assert(0); }
$ dmd -unittest main.d mylib\test.d main.exe
core.exception.asserter...@mylib.test(5): unittest failure
[snip]
I think that it is not a bug, it is a feature (sort of). Could you
look at the assembly generated for your main.d file? My guess is
that it does not reference foo at all, either because the call to
foo was inlined or because it was discarded (since you do not use x
after initializing it).
The reason it works with the first form is that all object files
that are specifically put on the command line are included in the
executable when linking even if they are not used.
The reason it does not work with the library is that library
objects are only included if they are referenced (to save executable
size).
That isn't true, the library is not passed to the linker as a library,
it's passed as an archive of object files.
Forgive my ignorance of OPTLINK syntax, I'll make my point with linux
linker:
dmd main.d mylib/libtest.a - compile in all object files from libtest.a
dmd main.d -L-Lmylib -L-ltest - only compile in parts of libtest.a that
are referenced
I just double checked and this is not true (at least with gnu ld
v2.21.1, but AFAIR it never was true). Both forms only link in the
parts of libtest.a that are referenced.
In spite of all this, such inlining or optimizations are only made if
you use -O or -inline. And I think just importing the module includes it.
Have you disassembled the object file to make sure? Have you tried
using x (for example printing it) to see what happens?
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: Would You Bet $100,000,000 on D?
On 9/17/11 10:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. Then Facebook would love your application (I'm not kidding; send me private email if interested). We have a dedicated team of bright engineers who worked valiantly on this (I also collaborated), and a dedicated server farm. Compile times are still a huge bottleneck. Andrei
Re: Would You Bet $100,000,000 on D?
Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? My slowest D compile except my one attempt into qtd is about 30,000 lines of template using code that takes about 5 seconds on my computer. (I compile and link it all at once) I could see this getting annoying if it continued to scale that way to 3 million, but that's still the exception in my experience: my typical D program builds in under one second, including a 14,000 line hobby game.
Re: Would You Bet $100,000,000 on D?
On Sun, Sep 18, 2011 at 1:32 AM, Adam D. Ruppe destructiona...@gmail.com wrote: Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? My slowest D compile except my one attempt into qtd is about 30,000 lines of template using code that takes about 5 seconds on my computer. (I compile and link it all at once) I could see this getting annoying if it continued to scale that way to 3 million, but that's still the exception in my experience: my typical D program builds in under one second, including a 14,000 line hobby game. As a general rule I think, most things don't scale linearly, they scale considerably worse.
Re: Would You Bet $100,000,000 on D?
Josh Simmons wrote:
As a general rule I think, most things don't scale linearly, they
scale considerably worse.
Let's try something:
===
import std.file;
import std.conv;
import std.string;
void main() {
string m;
foreach(i; 0 .. 1000) {
string code;
foreach(a; 0 .. 1000) {
code ~= format(q{
int someGlobal%d;
void someFunction%d() {
someGlobal%d++;
}
}, a, a, a);
}
std.file.write(file ~ to!string(i) ~ .d, code);
m ~= import file ~ to!string(i) ~ ;;
}
std.file.write(main.d, m ~ void main() {} );
}
===
$ ./generate
$ wc *.d
500 7001004 83684906 total
$ time dmd *.d
Segmentation fault
real0m29.915s
user0m26.208s
sys 0m3.684s
Holy shit, 3.6 GB of memory used! Aaaand segmentation fault.
OK, something's not good here :-P
Let's try this:
$ time ../dmd2/linux/bin64/dmd *.d
real0m45.363s
user0m26.009s
sys 0m14.193s
About 6 GB total memory used at the peak. Wow. I never thought
I'd actually use that much ram (but it was cheap).
$ ls -lh *.o
-rw-r--r-- 1 me users 371M 2011-09-17 12:40 file0.o
For some reason, there's no executable...
$ time ld file0.o ../dmd2/linux/lib64/libphobos2.a -lm -lpthread
ld: warning: cannot find entry symbol _start; defaulting to 00400f20
real0m10.439s
user0m9.304s
sys 0m0.915s
$ ls -lh ./a.out
-rwxr-xr-x 1 me users 102M 2011-09-17 12:43 ./a.out
Wow.
Anyway, one minute to compile 5,000,000 lines of (bullshit) code
isn't really bad. It took a lot of memory, but that's not
a dealbreaker - I got this 8 gb dirt cheap, and the price has
gone down even more since then. Worst case, we can just throw
more hardware at it.
This code is nothing fancy, of course.
Now, what about an incremental build.
$ echo 'rm *.o; for i in *.d; do dmd -c ; done; dmd *.o' build
$ time bash build
waiting... lots of hard drive activity here. (BTW, I realize in
a real build, you could do a lot of this in parallel, so this
isn't really a fair scenario. I'm just curious how it will
turn out.)
ld is running now. I guess dmd did it's thing in about one
minute
Anyway, it's complete:
$ time bash build.sh
rm: cannot remove `*.o': No such file or directory
real1m44.632s
user1m17.358s
sys 0m10.275s
Two minutes for compile+link incrementally. The memory usage
never became significant.
$ ls -l file0
-rwxr-xr-x 1 me users 214M 2011-09-17 12:50 file0
This is probably double unrealistic since I didn't have any of
the modules import other modules.
But, I did feed 5,000,000 lines of code spread over 1,000 modules
to the D compiler, and it managed to work in a fairly reasonable
time - one minute is decent.
Of course, if you bring in fancier things than this trivial example,
who knows.
Re: Would You Bet $100,000,000 on D?
On 17/09/11 4:28 PM, Andrei Alexandrescu wrote: On 9/17/11 10:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. Then Facebook would love your application (I'm not kidding; send me private email if interested). We have a dedicated team of bright engineers who worked valiantly on this (I also collaborated), and a dedicated server farm. Compile times are still a huge bottleneck. Andrei It's not my application. We use Incredibuild: http://www.xoreax.com/ And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/
Re: Would You Bet $100,000,000 on D?
On 17/09/11 4:32 PM, Adam D. Ruppe wrote: Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? Nope. I use some parts of the standard library, not much of it though. I also use Derelict, but again, not much of it. I'm talking about a -release -inline -O build btw. For a normal build it's only 1.7 seconds.
Aligning data in memory
I posted this is d.learn, and also on stackoverflow.com with no
satisfactory answer. Can anyone help me with this?
http://stackoverflow.com/questions/7375165/aligning-stack-variables-in-d
---
Is there a way to align data on the stack? In particular, I want to
create an 16-byte aligned array of floats to load into XMM registers
using movaps, which is significantly faster than movups.
e.g.
void foo()
{
float[4] v = [1.0f, 2.0f, 3.0f, 4.0f];
asm
{
movaps XMM0, v; // v must be 16-byte aligned for this to work.
...
}
}
Re: Would You Bet $100,000,000 on D?
Ah, that explains it. I usually don't use the -O switch.
Re: Would You Bet $100,000,000 on D?
Hmmm. If $100M was on the line, the project code base must be extremely large. Correct? With a code base of that size, more than half would be common or boilerplate functionality, e.g. read a config file, read a data file, write/update a file, parse the command line, maintain a list, put up a window, etc. All been done before, all mundane, all boring. There would be 20-30% of truly new code specific to the project. Not really boring code, not really exciting code. Probably wouldn't require any specific language features. I would worry about large-scale project support from the language, e.g. package/module isolation, minimal compilation time, debug support, etc. IDE availability and tool support in general would be factors too. And finally there would be 5-10%, perhaps less, of the code base which was exciting. It would require certain language features or capabilities that only a language like D could provide. Given that project layout, what I would want then is a language *and* development kit that had the full project requirements covered. If the exciting stuff could be covered by Java or C#, I'd use Java/C# since the vast majority of the boring functionality would be already available to me in the JDK/CLR. If the exciting stuff, could only be covered by D, then I'd worry how I was going to write all that boring code in time, especially if I had to guarantee some level of defect rate. The JDK/CLR rides on top of Java/C#, both OK languages with OK features. Having the JDK/CLR available and tested by millions of developers? Very, very appealing. I could of course redevelop or convert, for example, a DOM XML parser in D, but that takes time. Would I want to spend the development time and debug time in this project to hit a low defect rate on boring code? Or would I just go with a language development kit that already had a wide code base and known defect rate. Generally speaking I believe low defect rates are due to time passing - get a large number of people kicking at a bunch of code over a long period of time, eventually the bugs get fixed. The concern is will there be enough time in the project for that effect to naturally run its course? So D right now has Phobos and Tango. Both are good, but not fully featured and, relatively speaking, untried. I could plan for a roll-yer-own development kit from scratch. Daunting. I could plan to patch together a whole set of converted C/C++ libraries. I could start with a conversion of Boost or something similar to D and add to it as I needed. But all this pales when compared to the 5,000/3,000 classes already written for me in JDK/CLR. That's a heck of a lot of code, all with a relatively low (and at least known) defect rate that I don't have to write. The less code I write, the more of that $100M stays in my pocket, right? In short, it's not D itself that would drive my decision to use or not use D. It is the extent and quality of the development kit that goes along with it. Of course, if the exciting part of the project was a solid fit with D then my decision would naturally swing that way. But if a language like Java/C# could do that part for me, I'd go with it and its JDK/CLR in a heartbeat. As a side note: the interesting twist here to me is that D language features themselves promote the possibility of a very high quality DeeDK. It would certainly be faster, and with enough unit testing and diligence, of a better quality than JDK/CLR could ever hope to be. John
Re: Aligning data in memory
Perhaps:
void foo() {
struct V { align(16) float[4] v = [1.0f, 2.0f, 3.0f, 4.0f]; }
V v;
asm {
movaps XMM0, v;
}
}
It compiles, but I'm not sure if it's actually correct.
Re: Aligning data in memory
On 17/09/11 7:11 PM, Adam D. Ruppe wrote:
Perhaps:
void foo() {
struct V { align(16) float[4] v = [1.0f, 2.0f, 3.0f, 4.0f]; }
V v;
asm {
movaps XMM0, v;
}
}
It compiles, but I'm not sure if it's actually correct.
If I am correct, that only aligns it within the struct, it doesn't align
the struct itself.
Re: Would You Bet $100,000,000 on D?
Am 17.09.2011, 20:01 Uhr, schrieb Adam D. Ruppe destructiona...@gmail.com: Ah, that explains it. I usually don't use the -O switch. During development when you recompile several times an hour, you really don't need -O either. For my hobby projects I usually set up the IDE with a compile command without -O and place a Makefile in the directory that has optimizations enabled. Sure, there are times when you run performance tests, but they aren't the usual case, so I think it is fair to compare compiles without optimizations in this context.
Re: Would You Bet $100,000,000 on D?
Adam D. Ruppe destructiona...@gmail.com wrote in message news:j52eia$133v$1...@digitalmars.com... Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? My slowest D compile except my one attempt into qtd is about 30,000 lines of template using code that takes about 5 seconds on my computer. (I compile and link it all at once) DDMD takes 1-2 minutes to build for me.
Re: Would You Bet $100,000,000 on D?
On 9/17/2011 8:08 AM, Peter Alexander wrote: I work at a very large game studio and I can assure you that I would *never* be able to justify using D for a project. Even if all our code magically transformed into D, and all our programmers knew D, I still wouldn't be able to justify the creation of all the necessary tools and dev systems to do something that we can already do. This is true in any industry that has a large investment in an existing technology. Eventually the pressure to make the change becomes overwhelming.
Re: Would You Bet $100,000,000 on D?
On 09/17/2011 12:55 PM, Peter Alexander wrote: On 17/09/11 4:28 PM, Andrei Alexandrescu wrote: On 9/17/11 10:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. Then Facebook would love your application (I'm not kidding; send me private email if interested). We have a dedicated team of bright engineers who worked valiantly on this (I also collaborated), and a dedicated server farm. Compile times are still a huge bottleneck. Andrei It's not my application. I meant employment application. We use Incredibuild: http://www.xoreax.com/ Is it available on Linux? And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/ That thing when you concatenate everything to be compiled, right? We don't do that although the technique is known. I'll ask why. Off the top of my head, incremental compilation is difficult. I also wonder how the whole thing can be distributed if it's all in one file. Thanks, Andrei
Re: Would You Bet $100,000,000 on D?
On Sat, 17 Sep 2011 20:55:38 +0300, Peter Alexander peter.alexander...@gmail.com wrote: And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/ I've always wondered if the overhead that unity builds are supposed to reduce was mainly because of all the build tools which force the OS to flush intermediate files to disk. Has anyone compared the performance advantages of using unity builds versus building everything on a RAM drive? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Would You Bet $100,000,000 on D?
On 17/09/11 8:52 PM, Andrei Alexandrescu wrote: On 09/17/2011 12:55 PM, Peter Alexander wrote: On 17/09/11 4:28 PM, Andrei Alexandrescu wrote: On 9/17/11 10:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. Then Facebook would love your application (I'm not kidding; send me private email if interested). We have a dedicated team of bright engineers who worked valiantly on this (I also collaborated), and a dedicated server farm. Compile times are still a huge bottleneck. Andrei It's not my application. I meant employment application. We use Incredibuild: http://www.xoreax.com/ Is it available on Linux? From what I can tell from the website, it's Windows only. And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/ That thing when you concatenate everything to be compiled, right? We don't do that although the technique is known. I'll ask why. Off the top of my head, incremental compilation is difficult. I also wonder how the whole thing can be distributed if it's all in one file. You don't need to concatenate everything into a single file. Just put maybe 50 source files per unity file (group ones that #include common headers) and then compile all the unity files separately. That way you can distribute individual unity files, and it also means that you don't have to rebuild the entire solution when changing a single source file. It's a bit of a balancing act getting the right number of unity files.
Re: Would You Bet $100,000,000 on D?
On 17/09/11 8:59 PM, Vladimir Panteleev wrote: On Sat, 17 Sep 2011 20:55:38 +0300, Peter Alexander peter.alexander...@gmail.com wrote: And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/ I've always wondered if the overhead that unity builds are supposed to reduce was mainly because of all the build tools which force the OS to flush intermediate files to disk. Has anyone compared the performance advantages of using unity builds versus building everything on a RAM drive? I have no idea if anyone has done that comparison. That's certainly not the only advantage though. If you went with the single unity file approach then it means that each header needs to only be parsed once. It also means that unique template instantiations are only emitted once, making things easier for the linker. I once measured that it takes GCC 30ms on my laptop to emit an std::sort of an int array.
Re: Would You Bet $100,000,000 on D?
On 17/09/11 7:52 PM, Marco Leise wrote: Am 17.09.2011, 20:01 Uhr, schrieb Adam D. Ruppe destructiona...@gmail.com: Ah, that explains it. I usually don't use the -O switch. During development when you recompile several times an hour, you really don't need -O either. For my hobby projects I usually set up the IDE with a compile command without -O and place a Makefile in the directory that has optimizations enabled. Sure, there are times when you run performance tests, but they aren't the usual case, so I think it is fair to compare compiles without optimizations in this context. I suppose that's true for most people, but not for games developers. When testing changes, you need the game to be running at interactive framerates, and it's very difficult to achieve that in a debug build, so we generally always run optimized, and just use MSVC++'s #pramga optimize(off, ) directive to unoptimize specific sections of code for debugging. To be fair, my hobby project still runs fast without optimizations, but I definitely need to repeatedly compile with optimizations on when performance tuning.
Re: [OT] Schools and sheeple (was: Would You Bet $100,000,000 on D?)
On Sep 16, 2011, at 11:24 PM, Nick Sabalausky wrote: Conclusion: High schools specifically cultivate sheeple, which is a quality preferred by respectable colleges. Depends on the college and even on the professor, though it's obviously difficult for universities with large class sizes to accommodate any other form of teaching and grading than a basic regurgitation of facts. Particularly in entry-level courses where the point of the course is to gain a basic knowledge of the field.
Re: Would You Bet $100,000,000 on D?
On Sep 17, 2011, at 8:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. Linking can still be pretty time consuming. My last big project was several million LOC broken into a tree of projects that all eventually produced a handful of large applications. This was a originally SPARC Solaris app so we couldn't spread the build across PCs, but rather built in parallel on big fancy machines. When I started, a full build took the better part of a work day, and before I left a full build was perhaps 30 minutes (my memory is a bit fuzzy here, but that sounds like a reasonable ballpark). The average level of parallelism was 10-20 cores working on the build using make -j. I suppose it's worth mentioning that building on Opteron was significantly faster, even using fewer cores. The code used almost no templates, which is a significant factor in total compile time. In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. I am unaware of any distributed, incremental build systems for D, so I see no particular speed advantage to using D (certainly not orders of magnitude anyway). My current project builds in 15 minutes on its current, ancient build machine at work. Written in C. A full build on my PC is under 5 minutes. Obviously, compile time isn't the only reason to choose D over some other language though. I'm sure there are smaller reasons too, but I'm convinced the primary reason why AAA game dev is C++ instead of D is ultimately because of inertia, not the languages themselves, or even the tools (If the AAA game dev industry genuinely wanted to be using D, you can bet that any tools they needed would get made). Tools are not free. Don't assume just because a company is large that it has unlimited funds. Creating tools, converting libraries all take lots of time and money that have to be justified. I work at a very large game studio and I can assure you that I would *never* be able to justify using D for a project. Even if all our code magically transformed into D, and all our programmers knew D, I still wouldn't be able to justify the creation of all the necessary tools and dev systems to do something that we can already do. It's absolutely about the toolchain. I'd be curious to hear from anyone who has tried developing for the Xbox 360 using D, or any of the big 3 consoles, really.
Re: Would You Bet $100,000,000 on D?
On Sep 16, 2011, at 10:28 PM, Josh Simmons wrote: On Sat, Sep 17, 2011 at 2:55 PM, Sean Kelly s...@invisibleduck.org wrote: On Sep 16, 2011, at 7:09 PM, Xavier wrote: Peter Alexander wrote: I recently stumbled across this (old) blog post: http://prog21.dadgum.com/13.html In summary, the author asks if you were offered $100,000,000 for some big software project, While this is a silly little hypothetical thread (and it is Friday afterall so that probably explains the OP), I cannot fathom that amount being spent on just software on one project (though I've worked on one system, i.e., software + hardware, project worth 10's of millions). Maybe someone here can? Examples please, or give the largest one you can think of (it can be hypothetical). Remember, it's just software, not a system. Top-tier computer game budgets are tens of millions of dollars. Writing a AAA game in D would mean fixing a whole bunch of D, way easier to stick to what's proven. You'd have to disable the collector or make it better than every existing one, which in turn means you're not using most of the standard library. This is OK though since AAA games generally don't use standard library stuff anyway. You'd have to fix the codegen too (or maybe develop further ldc or gdc) and build new tools for just about everything. So basically sure you could do anything with enough money, but why would you do it the hard way? I didn't say I would. That was merely an example of a multi-million dollar software project.
Re: Aligning data in memory
On Sat, 17 Sep 2011 14:01:19 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
I posted this is d.learn, and also on stackoverflow.com with no
satisfactory answer. Can anyone help me with this?
http://stackoverflow.com/questions/7375165/aligning-stack-variables-in-d
---
Is there a way to align data on the stack? In particular, I want to
create an 16-byte aligned array of floats to load into XMM registers
using movaps, which is significantly faster than movups.
e.g.
void foo()
{
float[4] v = [1.0f, 2.0f, 3.0f, 4.0f];
asm
{
movaps XMM0, v; // v must be 16-byte aligned for this to work.
...
}
}
It depends. OS X requires 16-byte alignment, which DMD complies with. So on Mac
the above code is okay. However, on PC, the only way to get aligned memory is
to a) use the heap or b) request extra stack space and align it yourself. (i.e.
declare a float[7] and then slice it appropriately)
The other option is to just use movups. movups on aligned data had (IIRC) the
same speed on aligned data as movaps did on my CPU (Core 2) and I'd really be
surprised if on any modern architecture this wasn't true. (That said, movups
does slow down on unaligned memory)
Also, you could use alloca or region allocator to get aligned memory.
Go and generic programming on reddit, also touches on D
Quite interesting. http://www.reddit.com/r/programming/comments/kikut/think_in_go_gos_alternative_to_the/ Andrei
Re: Formal Review of region allocator begins
Ok, implemented. It definitely makes the design cleaner. Thanks again.
The delay was just because I had waited a while to see if any other
comments came up that would make me change my mind or turn the whole
design upside down.
Code:
https://github.com/dsimcha/TempAlloc/tree/master/std/allocators
Docs:
http://cis.jhu.edu/~dsimcha/d/phobos/std_allocators_allocator.html
http://cis.jhu.edu/~dsimcha/d/phobos/std_allocators_gc.html
http://cis.jhu.edu/~dsimcha/d/phobos/std_allocators_region.html
On 9/11/2011 7:28 PM, Martin Nowak wrote:
Looks good.
Maybe nesting is a good name for the whole concept.
This would require further introductory explanation at the module header.
Possibly this can be partly merge with the explanation of stack pointer
bumping.
/*
* ...
* Multiple instances of RegionAllocator may use the same stack in which
case
* they are nested instances.
* When a nested RegionAllocator is destroyed, all memory allocated by it
* is returned to its stack.
* Memory may only be allocated by the most nested RegionAllocator.
*/
/*
* Creates a RegionAllocator using a thread local stack.
* If the thread local stack is already used by a RegionAllocator
* the returned RegionAllocator will be nested.
*/
newRegionAllocator();
/*
* Creates a RegionAllocator using a new stack.
* The stack will be freed when the returned RegionAllocator is destroyed.
*/
newRegionAllocator(size_t segmentSize, GCScan scan = GCScan.no);
struct RegionAllocator
{
/*
* Returns a new RegionAllocator using the same stack as this instance.
* When the nested allocator is destroyed all memory allocated by
* it will be freed. Memory allocated by this instance is unaffected.
* You may only allocate memory using the most nested instance.
*/
RegionAllocator nestedAllocator();
}
Re: Would You Bet $100,000,000 on D?
Nick Sabalausky a@a.a wrote in message news:j51mq9$2r1t$1...@digitalmars.com... Xavier x...@nospam.net wrote in message news:j51jsp$2lln$2...@digitalmars.com... Nick Sabalausky a@a.a wrote in message news:j51h52$2h0e$1...@digitalmars.com... Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@puremagic.com... On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, Oh, definitely. But what I meant was that good D programmers can be cultivated. People can learn to be good at D. And while the same might *technically* be true of C++, the curve is so steep that it may as well be what's out there is what's out there. It's, more or less, a non-renewable resource. It's not nearly as steep as it used to be, for C++, the tools, the techniques, the documentation, the users have matured and one need not struggle through everything on one's own anymore while learning it, but rather just go look up or ask for the answer, and it is still improving. Sure, if one exploits every stupid template trick and similarly with the other language features, then you will have steep, but it is quite tractable these days if one isn't overzealous and able to separate all the jabber about metaprogramming and the like from the meat of the language. It will always have its warts, but D has many of the same ones. In other words, C++ is easy^H^H^H^Hless hard than it used to be, as long as you don't use any of the advanced features that are already trivial in D anyway. No, but rather that most programmers don't know how to program yet and they think they need those things all the time. I realize I've said this other times in the past, but I find that the compiler bugs in DMD are much less severe than the language deficiencies of a fully-bug-free C++ implementation. That's an interesting, if not odd, statement considering that C++ are more alike than they are different. I don't understand what you're saying here. Did you mean D and C++ are more alike than different, or C++ implementations are more alike than are different. Either way, it doesn't make much sense. The first one. Plus there's the idea of investing in the future to keep in mind: It's like the old quote: I may be fat, but you're stupid. I can excersise and diet, but stupid will always be stupid. The truth of the matter is, though, that she won't exercise to any significant degree and has been on a diet her whole life and her weight has continually increased. On top of that, the fact that one can study, research and learn escapes the fat dumb blonde bimbo because she indeed is stupid, and that's why her dieting causes her to gain weight instead of lose it. You've just completely broken the analogy because D's bugs *DO* get fixed. And they're getting fixed rather quickly now, too. To be honest, I was just spouting on, and having fun with, the phrase and not it's applicability to anything in this thread. D may have some bugs, but investing the effort to deal with them will lead to further improvements. Dealing with C++'s problems, OTOH, will hardly do a damn thing. Again, I find that a curious statement for reason noted. The language names even fit together: C/C++/D. There is no denying that they are all related. Just look at those noses! C'mon! Umm, yea, they're related. So what? Don't tell me you're trying to imply that just because they're related they're inherently equal in everything but implementation. Ah, see now you're backing down. Now you are just trying to prove unequality rather than significant difference. Sure, a few things can be mitigated somewhat, such as the C++0x^H^H1x^H^H2x^H^H3x improvents. But in general, investing the effort to deal with C++'s shortcomings won't lead to significant improvements - it *can't* because it's constrained by its existing legacy design (not that that won't eventually happen to D, too, but D is one generation past C++). One generation away, but still the same family. So what? Ie., D may be buggy, but C++ is crappy. Bugs can be fixed, but crappy will always be crappy. All adolescents conflict with their parents and say things like that. When D grows up, the D++ or E kids will be maligning D and then D will remember back how it was just the same when it was just a youngster. Are you seriously trying say that that implies each successive one is inherently no better than the previous? I was alluding to the fact that you are overstating the significance of the difference
Re: Would You Bet $100,000,000 on D?
Timon Gehr wrote: On 09/17/2011 10:57 AM, Josh Simmons wrote: On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalauskya@a.a wrote: Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? No I believe the implication is that absolute quality is so absurdly impossible to define that it's somewhat irrelevant to even contemplate it. And it's certainly overly simplistic to consider it without putting it in the context of a given problem. Well, my pragmatic and simplistic definition of language quality is Oh curb it already.
Re: Would You Bet $100,000,000 on D?
Jacob Carlborg wrote: On 2011-09-17 00:34, Peter Alexander wrote: This is exactly what I was thinking, and it's even more true now that D has two fully open-source compilers. GDC is almost usable on x86 already. (Almost here means there's one showstopper bug that keeps me from using it for real work.) I'm sure you could hire a dev or two to get it working well on ARM and/or PowerPC. Think of all the money you'd save by not having to hire a bunch of extra people to write and maintain mountains of boilerplate. Remember: 1. You don't get the money until the job is done. Is that really realistic for a large project like this. It is if you are stupid enough to actually bite on that Craigslist-type ad! I assume it's a large project Well aren't you the brightest knob on the door! regarding the money involved. Ah, so THAT is what tipped you off, huh. Wouldn't you divide the project in several smaller projects and get paid for the smaller projects? You're not as dumb as I look! (Good for you, but I don't think we even want the project).
Re: Would You Bet $100,000,000 on D?
J Arrizza wrote: Hmmm. If $100M was on the line, the project code base must be extremely large. Correct? Hello. Next!
Re: Would You Bet $100,000,000 on D?
Josh Simmons simmons...@gmail.com wrote in message news:mailman.2925.1316249875.14074.digitalmar...@puremagic.com... On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalausky a@a.a wrote: Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? No I believe the implication is that absolute quality is so absurdly impossible to define that it's somewhat irrelevant to even contemplate it. And it's certainly overly simplistic to consider it without putting it in the context of a given problem. Yes C++ is crap, but so is D, they're both crappy in their own ways, to suggest otherwise is to assume that you're so much more intelligent than all that have come before you that you've managed to create a perfect product when all else have failed. To make analogy, it's like saying that OOP is inherently better than any paradigm before it. Ultimately though the issue is that C++'s crap is well explored and known, D's crap is significantly less so. Whether this is an issue for you depends entirely on your context. See Nick, I'm not the only one thinking it.
Re: Would You Bet $100,000,000 on D?
Nick Sabalausky wrote: Xavier x...@nospam.net wrote in message news:j51p5q$2utg$1...@digitalmars.com... Nick Sabalausky a@a.a wrote in message news:j51m0l$2prg$1...@digitalmars.com... In both this and your other post, you're conflating the notions of the language quality vs implementation quality. The two are not the same. They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language quality issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like D is better than the POS that C++ is. To be markedly different from C++, D would have to be thought of as being in a different category than which is the better POS?, but of course it cannot, for it comes from the same family, one generation newer than C++. Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas. What you're ultimately saying Uh, uh... do NOT tell me what I am ultimately saying, K? K. (Your stupid use of the language, noted :P). is that if a guitar has a crappy first and second string (and therefore sounds lousy), then you also have to replace the other four strings, the pickups, the head, the body, the amp, the neck and the carrying case to make it sound good again. You are so confused, you don't even know which way is up, let alone forward. In my experience (not to quote James Kanze, though :P), I learned (was whipped by that soundbox one too many times... or YOU CAN'T HANDLE THE TRUTH!) to pluck those strings differently, and a stupid lil box with steel strings, became my... someone.. oh fuck you already and get the fuck out of my face. Compile that with your semicolon synchronization crutch. That aside (read, ignore it), why take you take you AMP, and shove it. Whatch ya gonna do without electricity, fan boy, huh? Replacing the two crappy strings won't be enough to make it sound significantly better. You are way out of your league. What you're missing Don't you tell me what I'm missing. is that a minority portion *can* ruin a whole. Take your politics elsewhere, I am not your audience. If you consider D and C++ to be mostly the same, then C++ is crappy because of, what you're perceiving to be, a minority subset of it's design. D cuts out the cancer and saves the whole. Like I say, I reject your drugs. Push on me, I may get mad. Push on someone else, I may get furious. Your notion that a big imporvement requires a big change is just plain false. And maybe if you try to put words in my mouth one more time, you will taste aligator skin? An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that. You know perfectly well those were just examples. Contraire!! You were politicing, bitch. Dish it out... take it. Changing your story now? And notice too that for software development that is not that, intellisense dramatically reduces the number of times a programmer hits the compile button. That one thing is not as big an issue and certainly it pales in comparison to other language design flaws, which C++ and D both share. 1. IDE features are not substitutes for language improvement. Numbering stuff does not make it significant. I don't
Re: Would You Bet $100,000,000 on D?
Andrei Alexandrescu wrote: On 9/17/11 4:17 CDT, Xavier wrote: Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship. One's favorite language Nuh uh.. don't you even start that (or do it, but leave me out of it). has most to do with a handful of fundamental dimensions (dominant paradigm(s), approach to typing, look and feel, regard to efficiency, connection to problem domain vs. machine, and a few more). Dude, I think you your fundamental sword, carefully. For instance, I am not likely to entertain, that kind of crap. I'd go on with the absurdity, and maybe want to (don't count on it, audience), but I don't want to maybe. A coworker of mine, for example, doesn't mind a speed penalty of 2-5x, OK, you are trying to fish me. Why?? likes modeling power and semantic cleanliness, and is okay with some amount of code duplication. His favorite language is OCaml, and I'd probably choose the same if I had the same preferences. For those who want at the same time like low-level access, modeling power, generic programming, and efficiency, OCaml wouldn't rank high in the list of preferences, and there wouldn't be many games in town. In your metaphor, I'm not sorry for missing your interjecting point, at al, FYI. And don't tell me what my metaphor is/was, because you will only annoy me more. swimming from a ship to an island would entail It was my thought, so get the fuck out of it. OK? [snippage} I painted on the wall and you want to know what it means? (Don't dare me Andrei, to TELL YOU THE TRUTH!). :P
Re: Would You Bet $100,000,000 on D?
Lutger Blijdestijn wrote: Jonathan M Davis wrote: On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, and I suspect that given the current issues with the GC, if you were working on a AAA game, then you'd probably want the folks doing it to be good C/C++ programmers so that they would know how to do what needed doing when they can't use the GC or most of the standard libraries. For projects where performance isn't quite as critical, then D stands a much better chance of working. It _is_ easier to learn and has some definite advantages over C++. Any programmer should be able to learn any language on the job. I got your job right here, rapist.
Re: Would You Bet $100,000,000 on D?
Peter Alexander wrote: This is false.
Re: Would You Bet $100,000,000 on D?
On Saturday, September 17, 2011 23:32:20 Xavier wrote: I got your job right here, rapist. If you're not going to be civil, then please stop posting. It's one thing to discuss something. It's something else entirely to be rude about it. It's completely unproductive and just wastes everyone's time. - Jonathan M Davis
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis wrote: On Saturday, September 17, 2011 23:32:20 Xavier wrote: I got your job right here, rapist. If you're not going to be civil, then please stop posting. I dare you to make me vote. Bring it, asshat. I dare you. It's one thing to discuss something. It's something else entirely to be rude about it. It's completely unproductive and just wastes everyone's time. It's quite another to ween away from mommies tit.
Re: Would You Bet $100,000,000 on D?
Andrei Alexandrescu wrote: My doctorate And what about it?
Re: Would You Bet $100,000,000 on D?
Andrei Alexandrescu wrote: My doctorate I dare you to cry me a fucking river with your doctorat give it up man, rape is wrong. no need for war.
[Issue 6352] Regression(2.054) Implicit pure/nothrow/@safe messes up delegate arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6352 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2011-09-16 23:28:30 PDT --- https://github.com/D-Programming-Language/dmd/commit/77bed134d06e6314c5b65465068f554b3f2c2e8d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3180] Covariance of delegates/function pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3180 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch Severity|normal |critical Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from yebblies yebbl...@gmail.com 2011-09-06 02:02:19 PDT --- Part was fixed by https://github.com/D-Programming-Language/dmd/commit/dfb683f63ec89709b0bf2760ef3b2a249ce320eb Raising importance as while not a regression, this fixes one. (bug 6352) Pull for the remaining common type bugs: https://github.com/D-Programming-Language/dmd/pull/368 --- Comment #13 from yebblies yebbl...@gmail.com 2011-09-06 02:03:45 PDT --- Part was fixed by https://github.com/D-Programming-Language/dmd/commit/dfb683f63ec89709b0bf2760ef3b2a249ce320eb Raising importance as while not a regression, this fixes one. (bug 6352) Pull for the remaining common type bugs: https://github.com/D-Programming-Language/dmd/pull/368 --- Comment #14 from Walter Bright bugzi...@digitalmars.com 2011-09-16 23:28:48 PDT --- https://github.com/D-Programming-Language/dmd/commit/77bed134d06e6314c5b65465068f554b3f2c2e8d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6684] New: Wrong code for null-initializing a class with alias this.
http://d.puremagic.com/issues/show_bug.cgi?id=6684
Summary: Wrong code for null-initializing a class with alias
this.
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2011-09-17 02:22:42 PDT ---
class Foo{
string bar;
alias bar this;
}
void main(){
Foo foo = null; // segmentation fault at runtime
}
The compiler attempts to assign to foo's 'bar' field, instead of initializing
the class reference with zero. That always results in a segmentation fault.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5522] std.range.zip fails on arrays of Object.
http://d.puremagic.com/issues/show_bug.cgi?id=5522 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||dmitry.o...@gmail.com Resolution||FIXED --- Comment #2 from Dmitry Olshansky dmitry.o...@gmail.com 2011-09-17 04:17:27 PDT --- Fixed in: https://github.com/D-Programming-Language/phobos/commit/65a0c2158b1d2ea8e9d3094746739da636266089 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3180] Covariance of delegates/function pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3180
--- Comment #15 from Haruki Shigemori rayerd@gmail.com 2011-09-17
09:04:50 PDT ---
import std.stdio;
class Base {}
class Derived : Base {}
class X
{
Base foo() { return new Base; }
}
class Y : X
{
Derived foo() { return new Derived; }
}
void main()
{
// Covariance is good
{
Base delegate() f = delegate Derived() { return new Derived; };
writefln(delegate convariance is %s, f().toString() == a.Derived
? OK : NG);
}{
static Derived fp() { return new Derived; }
Base function() f = fp;
writefln(function pointer covariance is %s, f().toString() ==
a.Derived ? OK : NG);
}
// Contravariance is BAD
{
auto c = new class { void foo(Base){} };
// GOOD
void delegate(Base) f = c.foo;
f(new Base);
f(new Derived);
// BAD
void delegate(Derived) g = c.foo;
g(new Derived);
}
}
a.d(33): Error: cannot implicitly convert expression (c.foo) of type void
delegate(Base) to void delegate(Derived)
---
Why is Status RESOLVED-FIXED?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6685] New: Allow using with with rvalues
http://d.puremagic.com/issues/show_bug.cgi?id=6685 Summary: Allow using with with rvalues Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: thecybersha...@gmail.com --- Comment #0 from Vladimir Panteleev thecybersha...@gmail.com 2011-09-17 11:13:19 PDT --- The most common use of WithStatements in my D1 codebase was: with (someFunction(...)) ... D2 disallows this - for some reason it demands that the expression be an lvalue. I don't see this in the spec, either. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6686] New: bitmanip bitfields are broken at 64 bits
http://d.puremagic.com/issues/show_bug.cgi?id=6686
Summary: bitmanip bitfields are broken at 64 bits
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: paul.d.ander...@comcast.net
--- Comment #0 from Paul D. Anderson paul.d.ander...@comcast.net 2011-09-17
13:12:53 PDT ---
The bitfields setters give incorrect results if the bitfield is 64 bits long
and the first field is = 32.
The following program returns the correct result:
import std.bitmanip;
import std.string;
public static void main() {
union S {
// entire 64-bit unsigned integer
ulong bits = ulong.max;
// split in two
mixin (bitfields!(
ulong, back, 31,
ulong, front, 33)
);
const string toHex() { return format(0x%016X, bits); }
}
S num;
num.bits = ulong.max;
writeln(num1 = , num.toHex);
num.back = 1;
writeln(num2 = , num.toHex);
}
Output:
num1 = 0x
num2 = 0xFFFE0001
But if you change the bitfields to this:
mixin (bitfields!(
ulong, back, 32,
ulong, front, 32)
);
Output:
num1 = 0x
num2 = 0x0001
The front half, which shouldn't be changed, is converted to zeros.
Or:
mixin (bitfields!(
ulong, back, 31,
ulong, front, 33)
);
Output:
num1 = 0x
num2 = 0x8001
I experimented a little bit.
1) The sizes of the fields (ubyte, ushort, etc.) don't seem to matter as long
as they are long enough to hold the value.
2) It's only the first field that is broken, as far as I can tell.
3) Additional fields don't solve the problem.
I looked at the code for std.bitmanip but it's beyond my ability to modify. So
I'll have to rely on the kindness of strangers for a fix.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6682] Template function that has lazy parameter is not inferred as pure
http://d.puremagic.com/issues/show_bug.cgi?id=6682 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-09-17 14:04:33 PDT --- https://github.com/D-Programming-Language/dmd/commit/74a94cfb9347164ade633973105aeda1d96a2998 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3050] Allow exception in CTFE (patch)
http://d.puremagic.com/issues/show_bug.cgi?id=3050 --- Comment #4 from Kenji Hara k.hara...@gmail.com 2011-09-17 14:49:45 PDT --- I have modified his patch based on git master. https://github.com/9rnsr/dmd/commits/ctfeException -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6669] Compiler seg fault when using square brackets in inline assembly
http://d.puremagic.com/issues/show_bug.cgi?id=6669 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||bra...@puremagic.com AssignedTo|nob...@puremagic.com|bra...@puremagic.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6634] std.path.globMatch throws wrong assertion
http://d.puremagic.com/issues/show_bug.cgi?id=6634 Brad Roberts bra...@puremagic.com changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #1 from Brad Roberts bra...@puremagic.com 2011-09-17 17:16:28 PDT --- Care to turn this into a pull request with a unittest? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4284] empty string[] alias lacks .length in a template
http://d.puremagic.com/issues/show_bug.cgi?id=4284 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-09-17 17:19:59 PDT --- https://github.com/D-Programming-Language/dmd/commit/4ff28a3be1a35013cb6046b21c43a55f1b87f676 https://github.com/D-Programming-Language/dmd/commit/70174180cbfc83c9cde9d745ca367b08b49af398 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6669] Compiler seg fault when using square brackets in inline assembly
http://d.puremagic.com/issues/show_bug.cgi?id=6669
--- Comment #1 from Brad Roberts bra...@puremagic.com 2011-09-17 17:56:09 PDT
---
I can't reproduce this with tip of trunk:
$ uname -a
Darwin nexus 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011;
root:xnu-1699.22.81~1/RELEASE_X86_64 x86_64
$ cat bug6669.d
void main()
{
asm { mov EAX, [EAX]; }
}
$ ./dmd -v ../../bugs/bug6669.d
binary./dmd
version v2.056
configdmd.conf
parse bug6669
importall bug6669
importobject(./../../druntime/import/object.di)
semantic bug6669
semantic2 bug6669
semantic3 bug6669
code bug6669
function main
gcc bug6669.o -o bug6669 -m32 -Xlinker -L./../../druntime/lib -Xlinker
-L./../../phobos/generated/osx/release/32 -lphobos2 -lpthread -lm
What's different about your env than mine? I also tried on linux/32 and /64
with no better luck.
Assuming you can still reproduce the problem, running dmd under gdb and getting
a stack trace might help even if I can't repro.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3180] Covariance of delegates/function pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3180 --- Comment #16 from yebblies yebbl...@gmail.com 2011-09-18 12:17:32 EST --- (In reply to comment #15) Why is Status RESOLVED-FIXED? I assume you're asking why this report was marked as fixed when delegate contravariance hasn't been implemented? See comment #6 and issue 3075, this is covered by another report which has been rejected. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6518] break inside a static foreach inside a switch
http://d.puremagic.com/issues/show_bug.cgi?id=6518 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2011-09-17 19:26:30 PDT --- https://github.com/D-Programming-Language/dmd/commit/9c958300bf88d75489bdc542d0a0464d66274a15 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6670] Compiler seg fault using std.concurrency.atomicOp
http://d.puremagic.com/issues/show_bug.cgi?id=6670
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||bra...@puremagic.com
AssignedTo|nob...@puremagic.com|bra...@puremagic.com
--- Comment #2 from Brad Roberts bra...@puremagic.com 2011-09-17 20:09:02 PDT
---
I'm not seeing a dmd crash with this bug (much like not seeing the crash in bug
6669), but I am seeing something odd:
import std.concurrency;
void main()
{
int a;
atomicOp!+=(a, 1);
}
yields:
./../../druntime/import/core/atomic.di(108): Error: cast(shared(const(int)))val
is not an lvalue
s/std.concurrency/core.atomic/
And it builds.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6656] static alias this broken in 2.055
http://d.puremagic.com/issues/show_bug.cgi?id=6656
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords|rejects-valid |diagnostic
Severity|regression |normal
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-09-17 20:31:37 PDT ---
This is not regression, is diagnostic issue.
Originally alias this only accepts a member symbol of an aggregate itself
belongs. Therefore the code in comment #0 is invalid because A is lies outside
of B.
By fixing bug 6561, it has been fixed in 2.055, invalid alias this always
prints undefined identifier error. In this case, we cannot use A as B's alias
this symbol, but we can lookup A from inside B. Then this is *diagnostic* issue
that the message is not sufficiently descriptive.
In 2.054, following code doesn't work.
struct A
{
static void foo(){}
}
struct B
{
static alias A this;
}
void main()
{
B.foo(); // want to call A.foo, but fails
}
If this issue is 'regression', above code should work in 2.054, but doesn't.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6656] static alias this broken in 2.055
http://d.puremagic.com/issues/show_bug.cgi?id=6656 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Priority|P2 |P3 --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com 2011-09-17 20:36:07 PDT --- You're right, thanks. I was mistaken in thinking that it worked in 2.054. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6656] static alias this broken in 2.055
http://d.puremagic.com/issues/show_bug.cgi?id=6656 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #3 from Kenji Hara k.hara...@gmail.com 2011-09-17 20:37:06 PDT --- https://github.com/D-Programming-Language/dmd/pull/390 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6670] Compiler seg fault using std.concurrency.atomicOp
http://d.puremagic.com/issues/show_bug.cgi?id=6670
--- Comment #3 from Brad Roberts bra...@puremagic.com 2011-09-17 21:01:43 PDT
---
My current reduction:
template isMutable(T)
{
enum isMutable = !is(T == const) !is(T == immutable);
}
unittest
{
static assert(isMutable!(shared const(int)[]));
}
int atomicLoad( ref const shared int val )
{
return 0;
}
void main()
{
int a;
atomicLoad(a);
}
$ dmd bug6670.d
bug6670.d(20): Error: cast(shared(const(int)))a is not an lvalue
Not sure why the unused isMutable template is required, nor why the unittest
block is required when -unittest isn't part of the dmd arguments, but they are
and without them the code compiles.
Don or Daniel, either of you want to take this? I took it because I originally
thought it was a iasm or backend bug, which are areas I'm more familiar with.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6687] New: [64bit] error in GC on FreeBSD (amd64), so any program does not work
http://d.puremagic.com/issues/show_bug.cgi?id=6687 Summary: [64bit] error in GC on FreeBSD (amd64), so any program does not work Product: D Version: D1 Platform: x86_64 OS/Version: FreeBSD Status: NEW Severity: critical Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: so...@sohgo.dyndns.org --- Comment #0 from Sohgo Takeuchi so...@sohgo.dyndns.org 2011-09-18 13:08:39 JST --- I wrote a hello world program, and compiled it using DMD1 on FreeBSD(amd64) 8.2R. When I run it, the program exits with segmentation fault. % ./hello [5]195 segmentation fault ./hello Sep 18 13:02:56 maroon kernel: pid 195 (hello), uid 10103: exited on signal 11 I run the program with gdb. % gdb ./hello GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... (gdb) r Starting program: /home/sohgo/work/d/d-freebsd-amd64-current/phobos1/hello [New LWP 100186] [New Thread 800c041c0 (LWP 100186)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 800c041c0 (LWP 100186)] 0x0041c427 in _D3gcx3Gcx4markMFPvPvZv (this=0x800c0e100, ptop=0x533c48, pbot=0x422c42) at gcx.d:1781 1781byte *p = cast(byte *)(*p1); (gdb) bt #0 0x0041c427 in _D3gcx3Gcx4markMFPvPvZv (this=0x800c0e100, ptop=0x533c48, pbot=0x422c42) at gcx.d:1781 #1 0x0041c95f in _D3gcx3Gcx11fullcollectMFPvZm (this=0x800c0e100, stackTop=0x0) at gcx.d:2050 #2 0x0041c623 in _D3gcx3Gcx16fullcollectshellMFZm (this=0x800c0e100) at gcx.d:1885 #3 0x00419fbf in _D3gcx2GC12mallocNoSyncMFmZPv (this=0x800c0d040, size=112) at gcx.d:374 #4 0x00419e31 in _D3gcx2GC6mallocMFmZPv (this=0x800c0d040, size=112) at gcx.d:318 #5 0x00417480 in _d_newclass (ci=0x52fd58) at gc.d:190 #6 0x00422248 in _D3std6thread6Thread11thread_initFZv () at std/thread.d:1094 #7 0x00417401 in gc_init () at gc.d:167 #8 0x0041edcc in _d_run_main (argc=1, argv=0x7fffe7a0, p=0x402370) at internal/dmain2.d:109 #9 0x0041ed5f in main (argc=1, argv=0x7fffe7a0) at internal/dmain2.d:59 (gdb) p p1 $1 = (void **) 0x428ffa (gdb) p *p1 Error accessing memory address 0x428ffa: Bad address. (gdb) Therefore, unittest for phobos1 exit with segmentation fault too. Any unittest does not pass. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6688] New: An struct that has @disable constructor does not work with template constraint
http://d.puremagic.com/issues/show_bug.cgi?id=6688
Summary: An struct that has @disable constructor does not work
with template constraint
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: repeate...@gmail.com
--- Comment #0 from Masahiro Nakagawa repeate...@gmail.com 2011-09-17
21:13:34 PDT ---
Following code causes compilation error in dmd 2.055.
code:
-
struct S
{
@disable this();
this(int a) {}
}
S s = S(10);
writeln(s);
-
output:
-
/path/to/phobos/std/stdio.d(1483): Error: variable std.stdio.writeln(T...) if
(T.length == 0).writeln._args_field_0 initializer required for type S
/path/to/phobos/std/stdio.d(1495): Error: variable std.stdio.writeln(T...) if
(T.length == 1 is(typeof(args[0]) : const(char)[])).writeln._args_field_0
initializer required for type S
/path/to/phobos/std/stdio.d(1508): Error: variable std.stdio.writeln(T...) if
(T.length 1 || T.length == 1 !is(typeof(args[0]) :
const(char)[])).writeln._args_field_0 initializer required for type S
-
I think this is a regression.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6670] Compiler seg fault using std.concurrency.atomicOp
http://d.puremagic.com/issues/show_bug.cgi?id=6670
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #4 from yebblies yebbl...@gmail.com 2011-09-18 15:26:19 EST ---
Urrgh.
Reduced test case:
shared(const(int)[]) g;
int atomicLoad( ref const shared int val )
{
return 0;
}
void main()
{
int a;
atomicLoad(a);
}
Due to issue 5493, ref is completely ignored when looking at parameter type
matching. Therefore int matches const(shared(int)), when it really shouldn't.
This gets turned into cast(const(shared(int)))a
The compiler then optimizes cast(const(shared(int)))a, which it shouldn't do
when an lvalue is required. (like bug 2521)
Finally, a bug in CastExp::optimize uses constOf rather than
addMod(MODconst)/implicitConvTo=MATCHconst to see if the cast can be ignored,
and constOf's wacky behaviour interacts with the previous usage of
shared(const(int)) in the declaration of g.
So yeah, no segfault, and nothing to do with inline asm.
This bug is probably a dupe of bug 6669 and you've had the pleasure of
discovering a new one!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
