www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's the current state of D?

reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
Hi all.
When I last used D a couple years ago, 2.0 was the experimental branch and 
1.0 was stable. Now that I have a little time on my hands I'm wondering: 
what is the current landscape? Is 2.0 approaching any sort of stability? Are 
there still two competing runtime libraries or have they been merged? 
Basically I want to know if it's worth using 2.0 for anything of importance 
or is it still in flux?
Thanks,

Ameer 
May 07 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Ameer,

 Hi all.
 When I last used D a couple years ago, 2.0 was the experimental branch and
 1.0 was stable.
still true
 Now that I have a little time on my hands I'm wondering:
 what is the current landscape? Is 2.0 approaching any sort of stability?
the const system is stable and now it's starting to play with threading
 Are
 there still two competing runtime libraries or have they been merged?
No not for 1.0 (and they never will be) but /when/ Tango gets ported to 2.0 they will coexist.
 Basically I want to know if it's worth using 2.0 for anything of
 importance
 or is it still in flux?
Don't use it for bet-the-bank code. Use it for, fun-n-games code. Between them, it's up to you.
 Thanks,
 Ameer
 
May 07 2009
parent reply Steve Teale <steve.teale britseyeview.com> writes:
BCS Wrote:

 Hello Ameer,
 
 Hi all.
 When I last used D a couple years ago, 2.0 was the experimental branch and
 1.0 was stable.
still true
 Now that I have a little time on my hands I'm wondering:
 what is the current landscape? Is 2.0 approaching any sort of stability?
the const system is stable and now it's starting to play with threading
 Are
 there still two competing runtime libraries or have they been merged?
No not for 1.0 (and they never will be) but /when/ Tango gets ported to 2.0 they will coexist.
 Basically I want to know if it's worth using 2.0 for anything of
 importance
 or is it still in flux?
Don't use it for bet-the-bank code. Use it for, fun-n-games code. Between them, it's up to you.
 Thanks,
 Ameer
 
This is the sort of answer that will kill D. The guy comes back after 2 years, asks a straight question, and get's told "business as usual, we're still arguing among ourselves about what it should be". Maybe Tiobe is right! Lots of others may not even bother to ask. They just visit the newsgroup, read a page of it, and conclude "same old, same old", and go away. D should be D, not maybe 1.043, or let's wait a while and see what happens with D2. Potential real users hate uncertainty. If they are going to commit, then D must do so too.
May 08 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".
 
 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.
 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
What bothers me about this sentiment is that every other mainstream language undergoes revision, sometimes major ones, but that never seems to be an excuse for people to not use it. For example, C++ is quite in flux with C++0x. The only languages that are not undergoing revision are dead ones.
May 08 2009
next sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
What bothers me about this sentiment is that every other mainstream language undergoes revision, sometimes major ones, but that never seems to be an excuse for people to not use it. For example, C++ is quite in flux with C++0x. The only languages that are not undergoing revision are dead ones.
But C++ programs still compile and run correctly with C++0x compilers. I bet none of the projects on dsource are even compilable with dmd2 (even if they were written for D2.0). And _many_ projects probably need minor fixes, before they compile with the latest dmd1 compiler.
May 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 But C++ programs still compile and run correctly with C++0x compilers.
True enough, but that wasn't true for C++98, or C89. Nobody refused to use C or C++ because of that.
 I bet none of the projects on dsource are even compilable with dmd2 (even 
 if they were written for D2.0).
Take any C++ project from 15 years ago and I bet it won't compile today, either.
 And _many_ projects probably need minor 
 fixes, before they compile with the latest dmd1 compiler.
Nearly all of those are due to inadvertent reliance on bugs in D1. You see this quite a bit in the C++ world. Every time g++ gets updated, I have to tweak something in my sources. Every binary release of dmd is available for download. If you require an unchanging compiler, it's trivial to operate that way. dmd isn't going to auto-update itself and break your compiles.
May 08 2009
next sibling parent reply grauzone <none example.net> writes:
 Nearly all of those are due to inadvertent reliance on bugs in D1. You 
 see this quite a bit in the C++ world. Every time g++ gets updated, I 
 have to tweak something in my sources.
In the case of D, the problem is that sometimes you don't really know if it's a bug or a feature.
May 08 2009
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
grauzone wrote:

 Nearly all of those are due to inadvertent reliance on bugs in D1. You  
 see this quite a bit in the C++ world. Every time g++ gets updated, I  
 have to tweak something in my sources.
In the case of D, the problem is that sometimes you don't really know if it's a bug or a feature.
So you file a bug, and if nothing else, the spec should be clarified. -- Simen
May 08 2009
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 grauzone wrote:

 And _many_ projects probably need minor
 fixes, before they compile with the latest dmd1 compiler.
Nearly all of those are due to inadvertent reliance on bugs in D1. You see this quite a bit in the C++ world. Every time g++ gets updated, I have to tweak something in my sources.
And this is often unavoidable. Look at all the workarounds in Boost code for various versions of the MS compiler, for example (particularly VC6 vs. later versions). I can't think of how much code I've written in C++ that used preprocessor switches to vary implementation between compiler versions, even though they all claimed to support C++98. Fortunately, a little experience with the quirks of each compiler makes transitioning code fairly mechanical in most cases.
May 08 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:

 grauzone wrote:
 But C++ programs still compile and run correctly with C++0x compilers.
True enough, but that wasn't true for C++98, or C89. Nobody refused to use C or C++ because of that.
 I bet none of the projects on dsource are even compilable with dmd2 (even
 if they were written for D2.0).
Take any C++ project from 15 years ago and I bet it won't compile today, either.
 And _many_ projects probably need minor
 fixes, before they compile with the latest dmd1 compiler.
Nearly all of those are due to inadvertent reliance on bugs in D1. You see this quite a bit in the C++ world. Every time g++ gets updated, I have to tweak something in my sources. Every binary release of dmd is available for download. If you require an unchanging compiler, it's trivial to operate that way. dmd isn't going to auto-update itself and break your compiles.
That's a really good thing imho. I remember when I got the Civilization 4 C++ SDK, it would only compile with the MS 2003 compiler. Which at the time was outdated and unavailable for download in a legal way. It was also 130K LoC and beyond my ability to fix of course, very frustrating.
May 08 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:
 grauzone wrote:
 But C++ programs still compile and run correctly with C++0x compilers.
True enough, but that wasn't true for C++98, or C89. Nobody refused to use C or C++ because of that.
At the time, C[++] users didn't feel like they exactly had a choice, did they?
 I bet none of the projects on dsource are even compilable with dmd2 
 (even if they were written for D2.0).
Take any C++ project from 15 years ago and I bet it won't compile today, either.
 And _many_ projects probably need minor fixes, before they compile 
 with the latest dmd1 compiler.
Nearly all of those are due to inadvertent reliance on bugs in D1. You see this quite a bit in the C++ world. Every time g++ gets updated, I have to tweak something in my sources. Every binary release of dmd is available for download. If you require an unchanging compiler, it's trivial to operate that way. dmd isn't going to auto-update itself and break your compiles.
Now, that is something the random user doesn't expect. Right? And his boss definitely not. As part of our Public Front (as in "keeping up appearances", the TV-show), shouldn't we make it a point not to lose public awareness of such good things? (Meaning, it's not enough to have it mentioned in an obscure niche of a corner of a second-level reference to documentation.) __________________________________________________________ ** The following is way off-topic, so don't read it ** And it's written on a Saturday night, before the pub. Yesterday, I got into a discussion about the merits of Picasso, Dali, and a third [local] painter. One of us had read the book written by Picasso's last wife. Picasso lived a life like any sane man would [or should] dream of: Wife, lover, and random paintees. Heads of state and celebrities bowing to their knees before him, etc. One day his wife and his mistress together approached him, stating that this can't go on, it's intolerable. You have to choose or do something!!! Picasso looked at them, took a sip of his wine, a slow puff of his cigar, and then remarked "I'm fine." To their astounded faces, he continued "If the two of you have a problem, then go sort it out between yourselves." No wonder he had it in hand. And, IMHO, with the crappy paintings he did [at the top of his time], nobody modest, honest and humble would have got a living off of that stuff. ________________________________________________________ What's the relevance of this story to us?? Well, it is all about how you handle things like the public opinion and the attitudes of folks around you. Even if D were an amateur language with bribed articles on CUJ and DDJ, with the right attitude, you could get away with having the world believe this is the Holy Grail of languages. So, let's not do the opposite, please. Things we have (like every binary release [and I assume, an implicit promise of keeping it that way] downloadable forever), the source code to /both/ the front end and the back end distributed every time -- for both reading example usage, learning by looking at unittests, and for a deep understanding of both the compiler and the library code in detail, ... it's stuff like this we don't advertise enough. (( Of course, not to mention actual language highlights that are really smashing! But they're outside of this post.)) And the parts of D that are unique, we don't see them splashed all over the net either. It can and should be possible without the PR budget of Oracle, too. Anybody over 40 knows that Pascal was an excellent language for programmming classes. (Yes, it was even created for that purpose, originally.) But then, nobody at all knows that out of all "known" languages, D is (by FAR!!) the one a university /should/ choose as the introductory language. Hah, and even fewer can imagine that D is the language they should use in advanced classes! And, thus, virtually nobody knows that being blessed with having originally learned a language that has the strength to carry you all the way from intro to PhD, makes you seriously privileged. And with a robust and solid mother tongue like this, forages into C++, Java, Ruby, Haskell, Scheme, ASM, and the like, will seem like a breeze, and don't destroy or *undo* /the very foundations of/ your world as a programmer.
May 09 2009
parent reply Steve Teale <steve.teale britseyeview.com> writes:
Georg Wrede Wrote:

 Things we have (like every binary release [and I assume, an implicit 
 promise of keeping it that way] downloadable forever), the source code 
 to /both/ the front end and the back end distributed every time -- for 
 both reading example usage, learning by looking at unittests, and for a 
 deep understanding of both the compiler and the library code in detail, 
 ... it's stuff like this we don't advertise enough. (( Of course, not to 
 mention actual language highlights that are really smashing! But they're 
 outside of this post.))
 
 And the parts of D that are unique, we don't see them splashed all over 
 the net either. It can and should be possible without the PR budget of 
 Oracle, too.
 
 Anybody over 40 knows that Pascal was an excellent language for 
 programmming classes. (Yes, it was even created for that purpose, 
 originally.) But then, nobody at all knows that out of all "known" 
 languages, D is (by FAR!!) the one a university /should/ choose as the 
 introductory language. Hah, and even fewer can imagine that D is the 
 language they should use in advanced classes! And, thus, virtually 
 nobody knows that being blessed with having originally learned a 
 language that has the strength to carry you all the way from intro to 
 PhD, makes you seriously privileged. And with a robust and solid mother 
 tongue like this, forages into C++, Java, Ruby, Haskell, Scheme, ASM, 
 and the like, will seem like a breeze, and don't destroy or *undo* /the 
 very foundations of/ your world as a programmer.
Yes! I may continue to bitch, but you are so right. D is extraordinarily cool! Poa sana as I could say in the domain of my current residency. Somehow we have to advance the announcements and learn newsgroups so that they are primary, and change perceptions such that the "suggestions for the next version of D" newsgroup - currently the main newsgroup - is a specialist affair that most readers think they can safely ignore. Walters logic is unchallengeable, but most of life isn't about logic, it's about perceptions. D is great. How do we spread that particular perception?
May 09 2009
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Steve Teale wrote:
 D is great. How do we spread that particular perception?
Use it. Tell people you're using it. Produce tools, libraries, applications, whatever.. that are interesting enough that people want to know more. Later, Brad
May 09 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Brad Roberts wrote:
 Steve Teale wrote:
 D is great. How do we spread that particular perception?
Use it. Tell people you're using it. Produce tools, libraries, applications, whatever.. that are interesting enough that people want to know more.
Also write about it. Of all programming languages of comparable breadth, D is probably the one that made it with the least (amazingly little) written material. Andrei
May 09 2009
prev sibling next sibling parent Daniel Toffetti <dtoffe yahoo.com.ar> writes:
Brad Roberts Wrote:

 Steve Teale wrote:
 D is great. How do we spread that particular perception?
Use it. Tell people you're using it. Produce tools, libraries, applications, whatever.. that are interesting enough that people want to know more. Later, Brad
I second this. A great language and compiler is often not enough to get a lot of people interested. Since a parent post mentioned Pascal, look at the Lazarus installer you can download for Windows for example. I've already seen a couple of posts in the Netbeans users forum asking for a D plugin, and there is one already for Eclipse. People _is_ interested in being more productive and enjoying its work. But developers nowadays take some things for granted, besides the compiler. But there are simpler things that could help a lot, IMHO. For example, recent news in the front page, updated regularly. It doesn't need to be big anouncements, minor revisions or community news are ok, just enough to let people know this is moving. A small roadmap of completed features, showing reached milestones and future milestones. You don't need to show expected release date for future milestones, but it's nice to show approximate date of completion of already reached milestones. This also helps to give a perception of progress. This two should be in the front page or, if not possible, at least in a clearly visible link near the top of front page. HTH, cheers, Daniel
May 09 2009
prev sibling parent Daniel Toffetti <dtoffe yahoo.com.ar> writes:
Brad Roberts Wrote:

 Steve Teale wrote:
 D is great. How do we spread that particular perception?
Use it. Tell people you're using it. Produce tools, libraries, applications, whatever.. that are interesting enough that people want to know more. Later, Brad
I second this. A great language and compiler is often not enough to get a lot of people interested. Since a parent post mentioned Pascal, look at the Lazarus installer you can download for Windows for example. I've already seen a couple of posts in the Netbeans users forum asking for a D plugin, and there is one already for Eclipse. People _is_ interested in being more productive and enjoying its work. But developers nowadays take some things for granted, besides the compiler. But there are simpler things that could help a lot, IMHO. For example, recent news in the front page, updated regularly. It doesn't need to be big anouncements, minor revisions or community news are ok, just enough to let people know this is moving. A small roadmap of completed features, showing reached milestones and future milestones. You don't need to show expected release date for future milestones, but it's nice to show approximate date of completion of already reached milestones. This also helps to give a perception of progress. This two should be in the front page or, if not possible, at least in a clearly visible link near the top of front page. HTH, cheers, Daniel
May 09 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:
 D is great. How do we spread that particular perception?
All these are free and effective: Write articles/blogs about your experiences using D. Submit patches for better D support for gnu tools like gdb. Give a presentation on D at your local programmers' club meeting. Submit presentation abstracts on D to conferences. Read programming articles and if they don't mention D, but should, email the author and point it out. Make relevant comments about D on programming threads on Reddit, Slashdot, Gamedev.net, stackoverflow, ycombinator, etc. Promote open source D applications that you or others have written. Email tool vendors and ask for D support. Email web sites that have categories for programming languages that don't include D, and ask for a D category. Improve Wikipedia pages that mention D. Add mention of D to Wikipedia pages that should mention it.
May 09 2009
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Steve Teale wrote:
 Georg Wrede Wrote:
 
 Things we have (like every binary release [and I assume, an implicit 
 promise of keeping it that way] downloadable forever), the source code 
 to /both/ the front end and the back end distributed every time -- for 
 both reading example usage, learning by looking at unittests, and for a 
 deep understanding of both the compiler and the library code in detail, 
 ... it's stuff like this we don't advertise enough. (( Of course, not to 
 mention actual language highlights that are really smashing! But they're 
 outside of this post.))

 And the parts of D that are unique, we don't see them splashed all over 
 the net either. It can and should be possible without the PR budget of 
 Oracle, too.

 Anybody over 40 knows that Pascal was an excellent language for 
 programmming classes. (Yes, it was even created for that purpose, 
 originally.) But then, nobody at all knows that out of all "known" 
 languages, D is (by FAR!!) the one a university /should/ choose as the 
 introductory language. Hah, and even fewer can imagine that D is the 
 language they should use in advanced classes! And, thus, virtually 
 nobody knows that being blessed with having originally learned a 
 language that has the strength to carry you all the way from intro to 
 PhD, makes you seriously privileged. And with a robust and solid mother 
 tongue like this, forages into C++, Java, Ruby, Haskell, Scheme, ASM, 
 and the like, will seem like a breeze, and don't destroy or *undo* /the 
 very foundations of/ your world as a programmer.
Yes! I may continue to bitch, but you are so right. D is extraordinarily cool! Poa sana as I could say in the domain of my current residency. Somehow we have to advance the announcements and learn newsgroups so that they are primary, and change perceptions such that the "suggestions for the next version of D" newsgroup - currently the main newsgroup - is a specialist affair that most readers think they can safely ignore.
I agree. When someone clicks the "D Forum" link on the front page, they should get to the D.learn newsgroup. Also, said link should be more prominent, not tucked away at the bottom of the menu. -Lars
May 11 2009
prev sibling next sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
Walter Bright Wrote:

 Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".
 
 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.
 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
What bothers me about this sentiment is that every other mainstream language undergoes revision, sometimes major ones, but that never seems to be an excuse for people to not use it. For example, C++ is quite in flux with C++0x. The only languages that are not undergoing revision are dead ones.
Yes Walter, but C++ went through a tedious standardization process - itself a long argument. So there was some basis for people to think that it had 'got there'. But to come back after 2 years and find the same stuff still going on is depressing - been there done that. OK, it didn't put me off, I'm still in there, but it bothers me. I'd be dishonest if I said otherwise. I am not criticizing you. I think you are doing a great job under the pressure of a slew of suggestions. But maybe a line in the sand at some point? OK so for those who crave stability there is D1.x, but when all the focus appears to be on D2, what level of confidence is afforded to D1 users. Can a project Manager cross his heart and say that D1 will still be alive and well in five years time?
May 08 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:
 I am not criticizing you. I think you are doing a great job under the
 pressure of a slew of suggestions. But maybe a line in the sand at
 some point?
But there *is* a line in the sand - D1.
 OK so for those who crave stability there is D1.x, but when all the
 focus appears to be on D2, what level of confidence is afforded to D1
 users. Can a project Manager cross his heart and say that D1 will
 still be alive and well in five years time?
This just makes me very frustrated. Every fix going into D2 that also applies to D1 has been folded into D1. There are even some fixes that only apply to D1 that only go into D1. These average about 20 per month. D1 even got the FreeBSD port before D2. What other language gets that kind of support?
May 08 2009
next sibling parent grauzone <none example.net> writes:
Nobody is saying that you don't put enough effort into making it stable 
or so. It's just sad reality, that the unstable state of the D toolchain 
drives away users and potential users.

Anyway, having a stable version of D and making the full compiler source 
available were great steps into the right direction.
May 08 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Steve Teale wrote:
 I am not criticizing you. I think you are doing a great job under the
 pressure of a slew of suggestions. But maybe a line in the sand at
 some point?
But there *is* a line in the sand - D1.
 OK so for those who crave stability there is D1.x, but when all the
 focus appears to be on D2, what level of confidence is afforded to D1
 users. Can a project Manager cross his heart and say that D1 will
 still be alive and well in five years time?
This just makes me very frustrated. Every fix going into D2 that also applies to D1 has been folded into D1. There are even some fixes that only apply to D1 that only go into D1. These average about 20 per month. D1 even got the FreeBSD port before D2. What other language gets that kind of support?
This sometimes makes me wonder if D1 and D2 are going to evolve into separate but related languages with separate niches at some point, something like Scheme vs. Common Lisp or C vs. C++. D1, with its simplicity and the availability of Tango, seems well suited to be a Java++ kind of language. D2, with its extremely powerful metaprogramming, greater complexity and the availability of Phobos2, seems more like a (C++0x)++.
May 08 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 This sometimes makes me wonder if D1 and D2 are going to evolve into separate
but
 related languages with separate niches at some point, something like Scheme vs.
 Common Lisp or C vs. C++.  D1, with its simplicity and the availability of
Tango,
 seems well suited to be a Java++ kind of language.  D2, with its extremely
 powerful metaprogramming, greater complexity and the availability of Phobos2,
 seems more like a (C++0x)++.
D1, by definition, isn't going to evolve any more than C++98 is going to evolve.
May 08 2009
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Fri, May 8, 2009 at 8:56 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Steve Teale wrote:
 I am not criticizing you. I think you are doing a great job under the
 pressure of a slew of suggestions. But maybe a line in the sand at
 some point?
But there *is* a line in the sand - D1.
 OK so for those who crave stability there is D1.x, but when all the
 focus appears to be on D2, what level of confidence is afforded to D1
 users. Can a project Manager cross his heart and say that D1 will
 still be alive and well in five years time?
This just makes me very frustrated. Every fix going into D2 that also applies to D1 has been folded into D1. There are even some fixes that only apply to D1 that only go into D1. These average about 20 per month. D1 even got the FreeBSD port before D2. What other language gets that kind of support?
A lot of good points have been brought forward in this thread. To me the big problem with D1 is that we *still* don't have a conforming (what does that even mean with D) compiler. Yes I'm thinking forward reference problems and such. Sure, these are hard problems to fix in the compiler, at least at this point. It's something that should have been fixed immediately when the first bug report came in. From my work on LDC I've seen a lot of the DMD frontend source code, its glitches, but of course also those "wow, that's neat" moments. However, one thing is very certain, it has some horrible problems with order-of-things issues, which the spec says should not matter. I'm talking about forward references, differing semantic trees depending on the order of declarations, imports etc. even the order in which modules are passed on the command line can affect the resulting semantic trees (yes I mean AST, but DMD has no distinction, it rewrites the AST happily until it thinks the result is sane). The main feeling I've come to settle on during the soon two years I've spent with LDC, is: we need a new frontend! D1 and D2 both have these problems, and they're not going away by themselves. -Tomas
May 09 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Tomas Lindquist Olsen escribió:
 On Fri, May 8, 2009 at 8:56 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Steve Teale wrote:
 I am not criticizing you. I think you are doing a great job under the
 pressure of a slew of suggestions. But maybe a line in the sand at
 some point?
But there *is* a line in the sand - D1.
 OK so for those who crave stability there is D1.x, but when all the
 focus appears to be on D2, what level of confidence is afforded to D1
 users. Can a project Manager cross his heart and say that D1 will
 still be alive and well in five years time?
This just makes me very frustrated. Every fix going into D2 that also applies to D1 has been folded into D1. There are even some fixes that only apply to D1 that only go into D1. These average about 20 per month. D1 even got the FreeBSD port before D2. What other language gets that kind of support?
A lot of good points have been brought forward in this thread. To me the big problem with D1 is that we *still* don't have a conforming (what does that even mean with D) compiler. Yes I'm thinking forward reference problems and such. Sure, these are hard problems to fix in the compiler, at least at this point. It's something that should have been fixed immediately when the first bug report came in. From my work on LDC I've seen a lot of the DMD frontend source code, its glitches, but of course also those "wow, that's neat" moments. However, one thing is very certain, it has some horrible problems with order-of-things issues, which the spec says should not matter. I'm talking about forward references, differing semantic trees depending on the order of declarations, imports etc. even the order in which modules are passed on the command line can affect the resulting semantic trees (yes I mean AST, but DMD has no distinction, it rewrites the AST happily until it thinks the result is sane). The main feeling I've come to settle on during the soon two years I've spent with LDC, is: we need a new frontend! D1 and D2 both have these problems, and they're not going away by themselves. -Tomas
That's my feeling also. A new front-end must be done, and the specification of the language must be clear in every aspect. No surprises.
May 09 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Tomas Lindquist Olsen, el  9 de mayo a las 15:55 me escribiste:
 The main feeling I've come to settle on during the soon two years I've
 spent with LDC, is: we need a new frontend! D1 and D2 both have these
 problems, and they're not going away by themselves.
Are you saying Dlang is comming? 8-)~ -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- cederrón. (De CD-ROM, y este sigla del ingl. Compact Disc Read-Only Memory). 1. m. Inform. CD-ROM. -- Real Academia Española
May 11 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  8 de mayo a las 11:56 me escribiste:
 Steve Teale wrote:
I am not criticizing you. I think you are doing a great job under the
pressure of a slew of suggestions. But maybe a line in the sand at
some point?
But there *is* a line in the sand - D1.
OK so for those who crave stability there is D1.x, but when all the
focus appears to be on D2, what level of confidence is afforded to D1
users. Can a project Manager cross his heart and say that D1 will
still be alive and well in five years time?
This just makes me very frustrated. Every fix going into D2 that also applies to D1 has been folded into D1. There are even some fixes that only apply to D1 that only go into D1. These average about 20 per month. D1 even got the FreeBSD port before D2. What other language gets that kind of support?
D1 is INCOMPLETE (for example pre/post conditions inheritance are missing). I tend to forget which features are there for real what aren't (there are a few, true, but still). Another very *BIG* issue is lack of mainstream tools support. C++98 was finished before starting C++0x. A lot of effort was made to make mainstream tools to support C++. Most tools demangle C++ names (even when they aren't standard!). At least GDB should be able to do that, and Valgrind and GNU binutils, if you want people to be comfortable working with D. There are patches here and there but nothing works out of the box. I think what D1 is *really* missing is that 2 things: completeness and tools support. Without that is really hard to take it seriously. I think the D team should be working more in that direction before finishing D2. I know is very boring comparing it to making D2, but I think that is what is transmitted from D maintainers: "D1 is boring, don't pay attention to it, D2 is fun, let's play with that!". And this is what happening. People are playing with D2 and forgetting to finish D1. The Tango vs. Phobos is still a *BIG* issue for D1. I think don't addressing that is a huge error. It's only hurting D1 and preventing its adoption. The result is 2 incomplete, unsupported (by mainstream tools) languages. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- No existe nada más intenso que un reloj, ni nada más flaco que una bicicleta. No intenso como el café, ni flaco como escopeta. -- Ricardo Vaporeso
May 09 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 D1 is INCOMPLETE (for example pre/post conditions inheritance are
 missing). I tend to forget which features are there for real what aren't
 (there are a few, true, but still).
Array ops weren't there for a long time, many argued that D1 wasn't complete without them, and a few months ago I added them in. As far as I can tell, nobody cared about array ops. In C++ land, only one compiler actually completely implements C++98, and this is after more than 10 years. (Exported templates and template name lookup rules remain unimplemented by major compilers.) (P.S. Digital Mars C++ does the correct name lookup rules!) The fact is, nobody actually cares about those incomplete features. Nobody uses exported templates, even if they are using a compiler that supports it. So that leaves contract inheritance. I find it hard to see how not having it is a showstopper for using D1. Contracts in D haven't been the big win I thought they might be at first. They aren't use much at all. There are a lot of other issues that do make a big difference, and those are the issues that get attention. We've got only so many chips (time) to play with, and it's real important that we play them for maximum effect.
 Another very *BIG* issue is lack of mainstream tools support.
 
 C++98 was finished before starting C++0x. A lot of effort was made to make
 mainstream tools to support C++. Most tools demangle C++ names (even when
 they aren't standard!). At least GDB should be able to do that, and
 Valgrind and GNU binutils, if you want people to be comfortable working
 with D. There are patches here and there but nothing works out of the box.
GDB does have an official D mode. There are demanglers for D identifiers. Can you submit patches for GDB to the official source tree?
 I think what D1 is *really* missing is that 2 things: completeness and
 tools support. Without that is really hard to take it seriously.
 
 I think the D team should be working more in that direction before
 finishing D2. I know is very boring comparing it to making D2, but I think
 that is what is transmitted from D maintainers: "D1 is boring, don't pay
 attention to it, D2 is fun, let's play with that!". And this is what
 happening. People are playing with D2 and forgetting to finish D1.
It isn't about boring. It's about allocating our very limited resources for maximum effect. If I thought that contract inheritance was a showstopper for D1, it'd move way up on the priority list. But I have a hard time believing it is a showstopper, like array ops turned out to not be. Most of the work I do on dmd is bug fixes, and nearly all of those wind up in D1 as well. It's just not true that D1 is being overlooked or ignored, and the D1 changelog should amply illustrate that. http://www.digitalmars.com/d/1.0/changelog.html
 The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
 addressing that is a huge error. It's only hurting D1 and preventing its
 adoption.
Doing a merge would be a very breaking change. D2's support for Tango is probably the biggest breaking change in moving D1 code to D2.
 The result is 2 incomplete, unsupported (by mainstream tools) languages.
May 09 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  9 de mayo a las 11:23 me escribiste:
 Leandro Lucarella wrote:
D1 is INCOMPLETE (for example pre/post conditions inheritance are
missing). I tend to forget which features are there for real what aren't
(there are a few, true, but still).
Array ops weren't there for a long time, many argued that D1 wasn't complete without them, and a few months ago I added them in. As far as I can tell, nobody cared about array ops. In C++ land, only one compiler actually completely implements C++98, and this is after more than 10 years. (Exported templates and template name lookup rules remain unimplemented by major compilers.) (P.S. Digital Mars C++ does the correct name lookup rules!) The fact is, nobody actually cares about those incomplete features. Nobody uses exported templates, even if they are using a compiler that supports it. So that leaves contract inheritance. I find it hard to see how not having it is a showstopper for using D1. Contracts in D haven't been the big win I thought they might be at first. They aren't use much at all. There are a lot of other issues that do make a big difference, and those are the issues that get attention.
Exported templates was unpractical and unimplementable AFAIK (but I guess you know that better than me). And C++ is an ISO standard language. D is not. If something is unpractical and unimplementable in D (I don't think is the case of contract inheritance) why didn't you removed a long time ago when you decided that it wasn't useful? And maybe you are right, but the bottom line is how D is perceived. People usually don't go through the C++98 standard to learn C++, but it goes through the D specs to learn D. Nobody talks about exported templates in C++ because they don't exist in reality, but the D specs talks about features that are missing in what is supposed to be a finished version. And that makes D looks bad.
Another very *BIG* issue is lack of mainstream tools support.
C++98 was finished before starting C++0x. A lot of effort was made to make
mainstream tools to support C++. Most tools demangle C++ names (even when
they aren't standard!). At least GDB should be able to do that, and
Valgrind and GNU binutils, if you want people to be comfortable working
with D. There are patches here and there but nothing works out of the box.
GDB does have an official D mode. There are demanglers for D identifiers. Can you submit patches for GDB to the official source tree?
Official? I don't see any official support for D in GDB. I can only find this patches: http://www.dsource.org/projects/gdb-patches/ And this thread about integrating the patches in GDB: http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html But I can't see any mention in the official GDB documentation and certainly it doesn't automatically recognize D programs as such.
I think what D1 is *really* missing is that 2 things: completeness and
tools support. Without that is really hard to take it seriously.
I think the D team should be working more in that direction before
finishing D2. I know is very boring comparing it to making D2, but I think
that is what is transmitted from D maintainers: "D1 is boring, don't pay
attention to it, D2 is fun, let's play with that!". And this is what
happening. People are playing with D2 and forgetting to finish D1.
It isn't about boring. It's about allocating our very limited resources for maximum effect. If I thought that contract inheritance was a showstopper for D1, it'd move way up on the priority list. But I have a hard time believing it is a showstopper, like array ops turned out to not be.
I don't think it's a *showtopper*. I'm trying to explain one of the reasons I think D is perceived as a toy/incomplete/not-ready-for-business language. But I certainly think D 1.0 should be finished before 2.0 though =)
 Most of the work I do on dmd is bug fixes, and nearly all of those wind
 up in D1 as well. It's just not true that D1 is being overlooked or
 ignored, and the D1 changelog should amply illustrate that.
 
 http://www.digitalmars.com/d/1.0/changelog.html
I know that. Everybody knows that. And I don't think anybody is arguing that. Lack of bug-fixing is not a mentioned problem AFAIK.
The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
addressing that is a huge error. It's only hurting D1 and preventing its
adoption.
Doing a merge would be a very breaking change. D2's support for Tango is probably the biggest breaking change in moving D1 code to D2.
How is that? Most runtime code is not used by the user directly. And for this item I think not merging it does more damage than introducing a breaking change (is much better to introduce a breaking change to solve this problem than to add a predefined Posix version ;). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 09 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Official? I don't see any official support for D in GDB. I can only find
 this patches:
 http://www.dsource.org/projects/gdb-patches/
Dwarf has an official value for the language, DW_LANG_D = 0x13.
 How is that? Most runtime code is not used by the user directly. And for
 this item I think not merging it does more damage than introducing
 a breaking change (is much better to introduce a breaking change to solve
 this problem than to add a predefined Posix version ;).
Tango chose to use a number of incompatible names and a fundamentally different class hierarchy for the same thing(s).
May 09 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  9 de mayo a las 22:05 me escribiste:
 Leandro Lucarella wrote:
Official? I don't see any official support for D in GDB. I can only find
this patches:
http://www.dsource.org/projects/gdb-patches/
Dwarf has an official value for the language, DW_LANG_D = 0x13.
I'm talking about GDB. GDB has no official D support. There was a thread in the NG asking for possible copyright issues to include the GDB patch upstream, and it had no answer for example. I don't think you *have* to answer that mail, but I think helping this kind of things happening instead of ignoring them is good for D promotion too =)
How is that? Most runtime code is not used by the user directly. And for
this item I think not merging it does more damage than introducing
a breaking change (is much better to introduce a breaking change to solve
this problem than to add a predefined Posix version ;).
Tango chose to use a number of incompatible names and a fundamentally different class hierarchy for the same thing(s).
How many people is using that? How bad would it be to call the next version of DMD that include the Tango/Druntime runtime D 1.100 or something (is really hard to pick right version numbers under the version scheme you use[*]) to make clear there is compatibility break in that version? Seriously, there were several (silly) compatibility breaks since 1.0 was out, I think is a huge issue that deserves it... [*] I really wonder how would you call D2 when it's stable. You will just say D 2.134 is D2 final/stable? I think this is another problem with D, version naming is really confusing and lame. You can't know anything from a D version number. And DMD compiler and D specs are too much coupled. It would be nice to have separate version numbers if you really want to encourage some kind of D standard and compiler vendors to start making D compilers. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- MATAN AL PERRO: DICEN QUE ESTABA POSEIDO POR EL DEMONIO... -- Crónica TV
May 10 2009
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:

 How many people is using that? How bad would it be to call the next
 version of DMD that include the Tango/Druntime runtime D 1.100 or
 something (is really hard to pick right version numbers under the version
 scheme you use[*]) to make clear there is compatibility break in that
 version?
 
 [*] I really wonder how would you call D2 when it's stable. You will just
     say D 2.134 is D2 final/stable? I think this is another problem with
     D, version naming is really confusing and lame. You can't know
     anything from a D version number. And DMD compiler and D specs are too
     much coupled. It would be nice to have separate version numbers if you
     really want to encourage some kind of D standard and compiler vendors
     to start making D compilers.
For what it's worth, there's at least one other major product that follows a similar versioning scheme.. mysql. Later, Brad
May 10 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el 10 de mayo a las 10:12 me escribiste:
 Leandro Lucarella wrote:
 
 How many people is using that? How bad would it be to call the next
 version of DMD that include the Tango/Druntime runtime D 1.100 or
 something (is really hard to pick right version numbers under the version
 scheme you use[*]) to make clear there is compatibility break in that
 version?
 
 [*] I really wonder how would you call D2 when it's stable. You will just
     say D 2.134 is D2 final/stable? I think this is another problem with
     D, version naming is really confusing and lame. You can't know
     anything from a D version number. And DMD compiler and D specs are too
     much coupled. It would be nice to have separate version numbers if you
     really want to encourage some kind of D standard and compiler vendors
     to start making D compilers.
For what it's worth, there's at least one other major product that follows a similar versioning scheme.. mysql.
At least MySQL uses major, minor, and patchlevel version numbering scheme ;) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- The biggest lie you can tell yourself is When I get what I want I will be happy
May 10 2009
parent Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:
 Brad Roberts, el 10 de mayo a las 10:12 me escribiste:
 Leandro Lucarella wrote:

 How many people is using that? How bad would it be to call the next
 version of DMD that include the Tango/Druntime runtime D 1.100 or
 something (is really hard to pick right version numbers under the version
 scheme you use[*]) to make clear there is compatibility break in that
 version?

 [*] I really wonder how would you call D2 when it's stable. You will just
     say D 2.134 is D2 final/stable? I think this is another problem with
     D, version naming is really confusing and lame. You can't know
     anything from a D version number. And DMD compiler and D specs are too
     much coupled. It would be nice to have separate version numbers if you
     really want to encourage some kind of D standard and compiler vendors
     to start making D compilers.
For what it's worth, there's at least one other major product that follows a similar versioning scheme.. mysql.
At least MySQL uses major, minor, and patchlevel version numbering scheme ;)
Mysql uses an x.y.z numbering scheme. DMD uses a y.z numbering scheme. With mysql's x.y being equavilent to dmd's y. The use of z in both is the same. Given that mysql's increase of its x.y component being somewhat arbitrary, it might as well just be one number. Either way, the transition of the z component through various stages from alpha to release being at arbitrary points along the number line, my point still stands. :) Later, Brad
May 10 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el  9 de mayo a las 22:05 me escribiste:
 Leandro Lucarella wrote:
 Official? I don't see any official support for D in GDB. I can only find
 this patches:
 http://www.dsource.org/projects/gdb-patches/
Dwarf has an official value for the language, DW_LANG_D = 0x13.
I'm talking about GDB. GDB has no official D support.
GDB officially supports Dwarf, and Dwarf officially has a D identifier. While gdb may not go any further than that, it's a start.
 There was a thread
 in the NG asking for possible copyright issues to include the GDB patch
 upstream, and it had no answer for example. I don't think you *have* to
 answer that mail, but I think helping this kind of things happening
 instead of ignoring them is good for D promotion too =)
Can you point me to that thread? There are an awful lot of posts, and I miss things.
 How is that? Most runtime code is not used by the user directly. And for
 this item I think not merging it does more damage than introducing
 a breaking change (is much better to introduce a breaking change to solve
 this problem than to add a predefined Posix version ;).
Tango chose to use a number of incompatible names and a fundamentally different class hierarchy for the same thing(s).
How many people is using that? How bad would it be to call the next version of DMD that include the Tango/Druntime runtime D 1.100 or something (is really hard to pick right version numbers under the version scheme you use[*]) to make clear there is compatibility break in that version?
Given all the beating of breasts and rending of robes about D1 not being stable and breaking code even when a bug is fixed in it, I just can't see coming out with a new D1 that substantially breaks every existing D1 code base.
 Seriously, there were several (silly) compatibility breaks since 1.0 was
 out, I think is a huge issue that deserves it...
This is what I mean when I say that it's simply impossible to ask for breaking changes for D1 while pillorying D1 for breaking changes. I also believe it is impractical to divide D1 into two incompatible versions - then there'd be 3 D versions to simultaneously support. D2 has already taken the steps necessary to support both Phobos and Tango.
May 10 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 10 de mayo a las 11:21 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el  9 de mayo a las 22:05 me escribiste:
Leandro Lucarella wrote:
Official? I don't see any official support for D in GDB. I can only find
this patches:
http://www.dsource.org/projects/gdb-patches/
Dwarf has an official value for the language, DW_LANG_D = 0x13.
I'm talking about GDB. GDB has no official D support.
GDB officially supports Dwarf, and Dwarf officially has a D identifier. While gdb may not go any further than that, it's a start.
There was a thread
in the NG asking for possible copyright issues to include the GDB patch
upstream, and it had no answer for example. I don't think you *have* to
answer that mail, but I think helping this kind of things happening
instead of ignoring them is good for D promotion too =)
Can you point me to that thread? There are an awful lot of posts, and I miss things.
I posted it in this very same thread, just before the link to the GDB patches link. Here it is again: http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html
How is that? Most runtime code is not used by the user directly. And for
this item I think not merging it does more damage than introducing
a breaking change (is much better to introduce a breaking change to solve
this problem than to add a predefined Posix version ;).
Tango chose to use a number of incompatible names and a fundamentally different class hierarchy for the same thing(s).
How many people is using that? How bad would it be to call the next version of DMD that include the Tango/Druntime runtime D 1.100 or something (is really hard to pick right version numbers under the version scheme you use[*]) to make clear there is compatibility break in that version?
Given all the beating of breasts and rending of robes about D1 not being stable and breaking code even when a bug is fixed in it, I just can't see coming out with a new D1 that substantially breaks every existing D1 code base.
It would break all existing D1 code base?
Seriously, there were several (silly) compatibility breaks since 1.0 was
out, I think is a huge issue that deserves it...
This is what I mean when I say that it's simply impossible to ask for breaking changes for D1 while pillorying D1 for breaking changes. I also believe it is impractical to divide D1 into two incompatible versions - then there'd be 3 D versions to simultaneously support.
If the compiler were really open source, and the frontend were in a public repository, and fixes would be well separated patches, you wouldn't have to maintain 3 D version. You probably even have to maintain 2 D versions. Other people could take over and apply fixes to the stable D branches while you with D2. The problem is doing that right now is really hard, because to see what changed in the DMDFE from one version to another you have to download 2 complete compiler version, make a diff yourself and you end up with a big diff that you can't possible break in small chunks with individual bugfixes.
 D2 has already taken the steps necessary to support both Phobos and Tango.
But D2 is not nearly ready for production use. D1 is almost there... Is missing so little that it's frustrating. In case you are not following the thread about interior pointers, here is another drawback for the Tango vs. Phobos problem, here is copy&pasted fragment: I think it would be great to have a centralized place where to put this improvements. This is another situation where I think Tango vs. Phobos issue is killing D. When I started my work in the thesis I had to decide whether to work with Phobos or Tango. I finally decided for Tango, because is the only option for LDC and because is way better organized (and more receptive to patches). But I hate knowing that my work will be available (in the best case) only for people using Tango. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- De tan fina la condesa, por no cagarse, reza. -- Ricardo Vaporeso
May 10 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el 10 de mayo a las 11:21 me escribiste:
 I posted it in this very same thread, just before the link to the GDB
 patches link. Here it is again:
 http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html
Thank you.
 Given all the beating of breasts and rending of robes about D1 not being
 stable and breaking code even when a bug is fixed in it, I just can't
 see coming out with a new D1 that substantially breaks every existing D1
 code base.
It would break all existing D1 code base?
I suspect it would break pretty much all the non-trivial code.
 If the compiler were really open source, and the frontend were in a public
 repository, and fixes would be well separated patches, you wouldn't have
 to maintain 3 D version.
It's not just me, it's the poor sap who has to maintain 3 different versions of his library.
 D2 has already taken the steps necessary to support both Phobos and Tango.
But D2 is not nearly ready for production use. D1 is almost there... Is missing so little that it's frustrating.
I don't believe that contract inheritance is the key to production use. There shouldn't be anything standing in the way of using D1 for production use, and in fact it is being used that way.
 In case you are not following the thread about interior pointers, here is
 another drawback for the Tango vs. Phobos problem, here is copy&pasted
 fragment:
 
   I think it would be great to have a centralized place where to put this
   improvements. This is another situation where I think Tango vs. Phobos
   issue is killing D. When I started my work in the thesis I had to decide
   whether to work with Phobos or Tango. I finally decided for Tango, because
   is the only option for LDC and because is way better organized (and more
   receptive to patches). But I hate knowing that my work will be available
   (in the best case) only for people using Tango.
I don't believe that splitting D into yet another separate version can fix this, as then the user has to decide which D to use.
May 10 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 10 de mayo a las 15:42 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 10 de mayo a las 11:21 me escribiste:
I posted it in this very same thread, just before the link to the GDB
patches link. Here it is again:
http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html
Thank you.
You are welcome. I'm very glad this is taking some attention =) In case you missed my other mail, I opened a bug report in GDB bugzilla to keep track of the patch: http://sourceware.org/bugzilla/show_bug.cgi?id=10142
Given all the beating of breasts and rending of robes about D1 not being
stable and breaking code even when a bug is fixed in it, I just can't
see coming out with a new D1 that substantially breaks every existing D1
code base.
It would break all existing D1 code base?
I suspect it would break pretty much all the non-trivial code.
What are exactly the user-visible changes?
If the compiler were really open source, and the frontend were in a public
repository, and fixes would be well separated patches, you wouldn't have
to maintain 3 D version.
It's not just me, it's the poor sap who has to maintain 3 different versions of his library.
This is not fixable by adding a aliases for old names and leave them as deprecated?
D2 has already taken the steps necessary to support both Phobos and Tango.
But D2 is not nearly ready for production use. D1 is almost there... Is missing so little that it's frustrating.
I don't believe that contract inheritance is the key to production use. There shouldn't be anything standing in the way of using D1 for production use, and in fact it is being used that way.
Honestly I'm not confident enough in D1 for production use if it's incomplete and if the Tango/Druntime runtime is not merged because 2 codebases should be maintained and you can't use the few libraries available for one runtime with the other (without using some hackish wrappers). Lack of support in mainstream tools is the other thing preventing me to use D at work. I *can't* use D for something serious (sadly, because I'd love to).
In case you are not following the thread about interior pointers, here is
another drawback for the Tango vs. Phobos problem, here is copy&pasted
fragment:
  I think it would be great to have a centralized place where to put this
  improvements. This is another situation where I think Tango vs. Phobos
  issue is killing D. When I started my work in the thesis I had to decide
  whether to work with Phobos or Tango. I finally decided for Tango, because
  is the only option for LDC and because is way better organized (and more
  receptive to patches). But I hate knowing that my work will be available
  (in the best case) only for people using Tango.
I don't believe that splitting D into yet another separate version can fix this, as then the user has to decide which D to use.
Use the latest stable version, as you do with any serious language =) You shouldn't introduce breaking changes too often. I think a language version bump every (half) year is very acceptable. I mean, just see how Python/Ruby/PHP/Java/Haskel/<pick any other language> development model works, all very evolving languages that don't break backwards compatibility very often and with a lot of well maintained programs and libraries. But this is getting repetitive, so I guess it has no point to keep discussing it. Once in a while I have the crazy idea that you can be convinced otherwise (hey! You finally got convinced to fork D2 from D1! =)... Maybe I'll try again in a few months... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Si ella es el sol, yo soy la luna Si ella es el mar, soy el desierto Y estamos en eclipse total Y estamos en eclipse total
May 10 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 In case you missed my other mail, I opened a bug report in GDB bugzilla to
 keep track of the patch:
 http://sourceware.org/bugzilla/show_bug.cgi?id=10142
This is great. I'm glad you're pushing this.
May 10 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 10 de mayo a las 21:03 me escribiste:
 Leandro Lucarella wrote:
In case you missed my other mail, I opened a bug report in GDB bugzilla to
keep track of the patch:
http://sourceware.org/bugzilla/show_bug.cgi?id=10142
This is great. I'm glad you're pushing this.
I just hope one day in a near future we have D support in the tools I use daily to develop as good as C++ so I can have a chance to convince my boss to be able to use it at work =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Are you such a dreamer? To put the world to rights? I'll stay home forever Where two & two always makes up five
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 I just hope one day in a near future we have D support in the tools I use
 daily to develop as good as C++ so I can have a chance to convince my boss
 to be able to use it at work =)
Hoping is one thing, but submitting patches, bug reports, etc. to the tool developers is much more effective!
May 11 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 11 de mayo a las 11:46 me escribiste:
 Leandro Lucarella wrote:
I just hope one day in a near future we have D support in the tools I use
daily to develop as good as C++ so I can have a chance to convince my boss
to be able to use it at work =)
Hoping is one thing, but submitting patches, bug reports, etc. to the tool developers is much more effective!
Sure, but people already done that and got ignore. I'm just glad you only overlooked that mail and you're willing to help to iron out any licensing issue. GDB people have spoken (I don't see you subscribed to the bug report so I transcribe the comment from GDB): -------------------------------------------------------------------------- For a patch this size we would need copyright assignments from all the authors of the patch. I would suggest emailing the gdb list and asking for the paperwork; one of the maintainers will get you started. Also, send the patch to the gdb-patches list, as described here: http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/CONTRIBUTE?content-type=text/x-cvsweb-markup&cvsroot=src gdb doesn't really use bugzilla for patch tracking, much. I glanced quickly at the patch; it will need some reformatting and it will need to be rebased to the current cvs. It may require other changes, too, but I didn't read that closely. -------------------------------------------------------------------------- When all licensing issues are resolved I can do any adjustments to the patch to comply with GDB coding style and rebase it to current CVS if the original author is missing. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 11 2009
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Leandro Lucarella wrote:
 GDB people have spoken (I don't see you subscribed to the bug report so
 I transcribe the comment from GDB):
 
 --------------------------------------------------------------------------
 For a patch this size we would need copyright assignments from all
 the authors of the patch.  I would suggest emailing the gdb list
 and asking for the paperwork; one of the maintainers will get you started.
 
 Also, send the patch to the gdb-patches list, as described here:
 http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/CONTRIBUTE?content-type=text/x-cvsweb-markup&cvsroot=src
 gdb doesn't really use bugzilla for patch tracking, much.
 
 I glanced quickly at the patch; it will need some reformatting and it will
 need to be rebased to the current cvs.  It may require other changes, too,
 but I didn't read that closely.
 --------------------------------------------------------------------------
 
 When all licensing issues are resolved I can do any adjustments to the
 patch to comply with GDB coding style and rebase it to current CVS if the
 original author is missing.
If the original author is missing, you have a bigger problem. He presumably needs to sign the paperwork they mentioned...
May 11 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Frits van Bommel, el 11 de mayo a las 22:15 me escribiste:
 Leandro Lucarella wrote:
GDB people have spoken (I don't see you subscribed to the bug report so
I transcribe the comment from GDB):
--------------------------------------------------------------------------
For a patch this size we would need copyright assignments from all
the authors of the patch.  I would suggest emailing the gdb list
and asking for the paperwork; one of the maintainers will get you started.
Also, send the patch to the gdb-patches list, as described here:
http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/CONTRIBUTE?content-type=text/x-cvsweb-markup&cvsroot=src
gdb doesn't really use bugzilla for patch tracking, much.
I glanced quickly at the patch; it will need some reformatting and it will
need to be rebased to the current cvs.  It may require other changes, too,
but I didn't read that closely.
--------------------------------------------------------------------------
When all licensing issues are resolved I can do any adjustments to the
patch to comply with GDB coding style and rebase it to current CVS if the
original author is missing.
If the original author is missing, you have a bigger problem. He presumably needs to sign the paperwork they mentioned...
Yes, I meant if he is alive and willing to give the rights to GDB but don't want to bother to fix the style and rebase the patch himself. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Skepticism is the beginning of failure
May 11 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Hoping is one thing, but submitting patches, bug reports, etc. to the tool 
 developers is much more effective!
Sure, but people already done that and got ignore. I'm just glad you only overlooked that mail and you're willing to help to iron out any licensing issue.
I'm not the tool vendor for gdb. I also looked over the patches to gdb and don't see anything that requires approval or action from me.
 GDB people have spoken (I don't see you subscribed to the bug report so
 I transcribe the comment from GDB):
 
 --------------------------------------------------------------------------
 For a patch this size we would need copyright assignments from all
 the authors of the patch.  I would suggest emailing the gdb list
 and asking for the paperwork; one of the maintainers will get you started.
 
 Also, send the patch to the gdb-patches list, as described here:
 http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/CONTRIBUTE?content-type=text/x-cvsweb-markup&cvsroot=src
 gdb doesn't really use bugzilla for patch tracking, much.
 
 I glanced quickly at the patch; it will need some reformatting and it will
 need to be rebased to the current cvs.  It may require other changes, too,
 but I didn't read that closely.
 --------------------------------------------------------------------------
 
 When all licensing issues are resolved I can do any adjustments to the
 patch to comply with GDB coding style and rebase it to current CVS if the
 original author is missing.
It would be great if you could be the champion for this and get it through. It'll help out a lot!
May 11 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 11 de mayo a las 14:03 me escribiste:
 Leandro Lucarella wrote:
Hoping is one thing, but submitting patches, bug reports, etc. to the tool
developers is much more effective!
Sure, but people already done that and got ignore. I'm just glad you only overlooked that mail and you're willing to help to iron out any licensing issue.
I'm not the tool vendor for gdb. I also looked over the patches to gdb and don't see anything that requires approval or action from me.
Isn't the demangle code taken from DMDFE? -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Y2K <Aztech_> hmm, nothing major has happend, what an anticlimax <CaPS> yeah <CaPS> really sucks <CaPS> I expected for Australia to sink into the sea or something <CaPS> but nnoooooooo
May 11 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Isn't the demangle code taken from DMDFE?
It didn't look like it, especially since the DMDFE doesn't have a demangler in it! The one in Phobos is explicitly listed as Public Domain.
May 11 2009
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Leandro Lucarella wrote:
 Isn't the demangle code taken from DMDFE?
Why would DMDFE need a demangler? It can just not mangle in the first place :).
May 12 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Frits van Bommel (fvbommel REMwOVExCAPSs.nl)'s article
 Leandro Lucarella wrote:
 Isn't the demangle code taken from DMDFE?
Why would DMDFE need a demangler? It can just not mangle in the first place :).
You need name mangling for templates and function overloading to work.
May 12 2009
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
dsimcha wrote:
 == Quote from Frits van Bommel (fvbommel REMwOVExCAPSs.nl)'s article
 Leandro Lucarella wrote:
 Isn't the demangle code taken from DMDFE?
Why would DMDFE need a demangler? It can just not mangle in the first place :).
You need name mangling for templates and function overloading to work.
Mangling, yes. Demangling, no. (i.e. anywhere it needs the un-mangled name it can just look it up directly, without running the mangler)
May 12 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Frits van Bommel, el 12 de mayo a las 16:28 me escribiste:
 Leandro Lucarella wrote:
Isn't the demangle code taken from DMDFE?
Why would DMDFE need a demangler? It can just not mangle in the first place :).
Yes, yes, yes, I get the point. I meant Phobos... ¬¬ -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Yes, yes, yes, I get the point. I meant Phobos...
Which is (std.demangle) explicitly public domain. If FSF has a problem with public domain submissions, please let me know. (The FSF can change one byte of it and copyright the "derived work" however way they please, and so can anyone else.)
May 12 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 12 de mayo a las 10:18 me escribiste:
 Leandro Lucarella wrote:
Yes, yes, yes, I get the point. I meant Phobos...
Which is (std.demangle) explicitly public domain. If FSF has a problem with public domain submissions, please let me know. (The FSF can change one byte of it and copyright the "derived work" however way they please, and so can anyone else.)
I took a quick look at phobos demangle code and it doesn't look similar to the one in the GDB patch. I guess I should checked first, my apologies for bugging you when it looks like you have nothing to do with this patch. I was under the impression that it used your code for some reason. Now the only think to do is wait until Mihail Zenkov answer my mail (no news for now =( ). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Now the only think to do is wait until Mihail Zenkov answer my mail (no
 news for now =( ).
If he doesn't, just recode the patch and submit it. There doesn't look like there's much to it. My understanding from the FSF is the only concern is with patches that are more than 10 lines. The single line changes here and there in the gdb patch don't need to be redone. The point of making std.demangle public domain is so that other tools can freely incorporate it and support D!
May 12 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:
 Leandro Lucarella wrote:
 Now the only think to do is wait until Mihail Zenkov answer my mail (no
 news for now =( ).
If he doesn't, just recode the patch and submit it. There doesn't look like there's much to it. My understanding from the FSF is the only concern is with patches that are more than 10 lines. The single line changes here and there in the gdb patch don't need to be redone. The point of making std.demangle public domain is so that other tools can freely incorporate it and support D!
OK, Leandro, so quoting to them the above post, and quoting the beginning of the file demangle.d ought to do the trick: * Placed into the Public Domain. ... /* Authors: * Walter Bright, Digital Mars, www.digitalmars.com * Thomas Kuehne * Frits van Bommel --------------- Knowing what (*seriously excuse* the wording here) fascists the FSF guys are, they obviously assume similar behavior of any opposition. That explains why they appear paranoid and unreasonable in their demands of the copyright statements for any code even remotely considered for inclusion. PS: even if the intent is benign, there's no reason for anti-benign action or attitudes. That's why their track record forced me to use harsh language, above. ((( please don't nobody get me started on this one )))
May 12 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Georg Wrede wrote:
 Knowing what (*seriously excuse* the wording here) fascists the FSF guys 
 are, they obviously assume similar behavior of any opposition. That 
 explains why they appear paranoid and unreasonable in their demands of 
 the copyright statements for any code even remotely considered for 
 inclusion.
Copyright assignment makes management a hell of a lot easier for them. They have the authority to sue anyone who uses any part of their projects, and they don't have to go through their records to determine this. This is one reason why public domain code is not particularly interesting for them. Of course, they can put a comment the relevant code to the effect that the original is in the public domain, which should take care of the problem.
May 12 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Christopher Wright wrote:
 Georg Wrede wrote:
 Knowing what (*seriously excuse* the wording here) fascists the FSF 
 guys are, they obviously assume similar behavior of any opposition. 
 That explains why they appear paranoid and unreasonable in their 
 demands of the copyright statements for any code even remotely 
 considered for inclusion.
Copyright assignment makes management a hell of a lot easier for them. They have the authority to sue anyone who uses any part of their projects, and they don't have to go through their records to determine this. This is one reason why public domain code is not particularly interesting for them. Of course, they can put a comment the relevant code to the effect that the original is in the public domain, which should take care of the problem.
Well (still resisting opening Pandora's box!!!!), I see Public Domain as a superset of any of the OSS &co licenses. Oper source simply means (to me, anyway), free to use anyway you want, including selling and incorporating into other people's apps. So, licencing somethign as Public Domain, ought to make FSF and others, to be able (er, willing would be the word) to incorporate the code, as they see fit.
May 12 2009
parent reply BCS <none anon.com> writes:
Hello Georg,

 Well (still resisting opening Pandora's box!!!!), I see Public Domain
 as a superset of any of the OSS &co licenses. Oper source simply means
 (to me, anyway), free to use anyway you want, including selling and
 incorporating into other people's apps.
 
 So, licencing somethign as Public Domain, ought to make FSF and
 others, to be able (er, willing would be the word) to incorporate the
 code, as they see fit.
 
The issue might be that the GPL code forbids some thing and unless FSF owns the original code, the question can come up of if someone is misusing the GPL copy or correctly using the public domain copy.
May 12 2009
parent Brad Roberts <braddr puremagic.com> writes:
BCS wrote:
 Hello Georg,
 
 Well (still resisting opening Pandora's box!!!!), I see Public Domain
 as a superset of any of the OSS &co licenses. Oper source simply means
 (to me, anyway), free to use anyway you want, including selling and
 incorporating into other people's apps.

 So, licencing somethign as Public Domain, ought to make FSF and
 others, to be able (er, willing would be the word) to incorporate the
 code, as they see fit.
The issue might be that the GPL code forbids some thing and unless FSF owns the original code, the question can come up of if someone is misusing the GPL copy or correctly using the public domain copy.
Suggestion.. avoid speculation about the FSF motives or requirements and the reasons behind them. Let's let whoever can/will pursue it with them and see how it unfolds.
May 12 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 There was a thread
 in the NG asking for possible copyright issues to include the GDB patch
 upstream, and it had no answer for example. I don't think you *have* to
 answer that mail, but I think helping this kind of things happening
 instead of ignoring them is good for D promotion too =)
Can you point me to that thread? There are an awful lot of posts, and I miss things.
I posted it in this very same thread, just before the link to the GDB patches link. Here it is again: http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html
If someone has a patch ready to submit to GDB, and needs some licensing change for it, I'm happy to provide that.
May 10 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 10 de mayo a las 20:54 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 10 de mayo a las 15:44 me escribiste:
  
Leandro Lucarella wrote:
    
There was a thread
in the NG asking for possible copyright issues to include the GDB patch
upstream, and it had no answer for example. I don't think you *have* to
answer that mail, but I think helping this kind of things happening
instead of ignoring them is good for D promotion too =)
          
Can you point me to that thread? There are an awful lot of posts, and I miss things.
I posted it in this very same thread, just before the link to the GDB patches link. Here it is again: http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html
If someone has a patch ready to submit to GDB, and needs some licensing change for it, I'm happy to provide that.
I've opened a new "bug" in GDB bugzilla to keep track of D support patch. It would be great if people that has anything to do with the patch (the patch author and Walter, I guess, if the demangle code is from DMD) can follow the bug report.
URL, please!
http://sourceware.org/bugzilla/show_bug.cgi?id=10142
 (Also, did you mean to post this in the n.g.?)
Yes, sorry! -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- CHINO ATRAPA COTORRAS -- Crónica TV
May 11 2009
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:
 
 Another very *BIG* issue is lack of mainstream tools support.
 
 C++98 was finished before starting C++0x. A lot of effort was made to make
 mainstream tools to support C++. Most tools demangle C++ names (even when
 they aren't standard!). At least GDB should be able to do that, and
 Valgrind and GNU binutils, if you want people to be comfortable working
 with D. There are patches here and there but nothing works out of the box.
A critical error that keeps being made.. in MOST compiled languages, the authors of the compilers are not the ones that are producing the eco-systems above them. Even for the VM based languages, the language/compiler/runtime authors rarely venture much above those. Eclipse isn't a sun invention, nor are any of the other development environments. Microsoft is about the only one that produces an large tool chain, but the groups that do the various parts are different. The compiler team doesn't produce (or in many cases even use) Visual Studio. Etc.. So, want the tool chain to mature.. go to work. Work with the GDB community to build and incorporate changes. The same with all the things you want to see changed or created. If there's things that need to change in what the compiler emits, Walter has shown himself to be willing to rapidly change them where the required changes are clearly described in terms of both 'what' and 'why'. In other words, "it's broken" isn't sufficient but "if the frobble was changed to frobnosticator for each wobble, it would work" results in the next release having that change made.
 I think what D1 is *really* missing is that 2 things: completeness and
 tools support. Without that is really hard to take it seriously.
 
 I think the D team should be working more in that direction before
 finishing D2. I know is very boring comparing it to making D2, but I think
 that is what is transmitted from D maintainers: "D1 is boring, don't pay
 attention to it, D2 is fun, let's play with that!". And this is what
 happening. People are playing with D2 and forgetting to finish D1.
If you've gotten the impression that "d1 is boring" is the message from whatever this "the d team" (team suggests many people, but there's really just a tiny few involved -- this isn't microsoft or sun with hundreds of worker ants) is, then you're impression is off. The message is "d1 is only receiving bug fixes -- and only those with the right balance of risk/reward".
 The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
 addressing that is a huge error. It's only hurting D1 and preventing its
 adoption.
 
 The result is 2 incomplete, unsupported (by mainstream tools) languages.
This is, in my honest opinion, the most clearly debatable point. I happen to have originally been on the side of "we must do something for D1" but since then I've agreed that the effort is best spent moving forward than disrupting the current. --- All of the above is _my_ opinion, and everyone is entitled to their own. Later, Brad
May 09 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el  9 de mayo a las 12:31 me escribiste:
 Leandro Lucarella wrote:
 
 Another very *BIG* issue is lack of mainstream tools support.
 
 C++98 was finished before starting C++0x. A lot of effort was made to make
 mainstream tools to support C++. Most tools demangle C++ names (even when
 they aren't standard!). At least GDB should be able to do that, and
 Valgrind and GNU binutils, if you want people to be comfortable working
 with D. There are patches here and there but nothing works out of the box.
A critical error that keeps being made.. in MOST compiled languages, the authors of the compilers are not the ones that are producing the eco-systems above them. Even for the VM based languages, the language/compiler/runtime authors rarely venture much above those. Eclipse isn't a sun invention, nor are any of the other development environments. Microsoft is about the only one that produces an large tool chain, but the groups that do the various parts are different. The compiler team doesn't produce (or in many cases even use) Visual Studio. Etc..
I know that, but the "language" should push forward in that direction. I don't know why this happen with D, what can be made to improve the situation, but I think putting all the attention in D2 doesn't help, and doesn't encourage people to work on D1. I've decided to work in D1 GC instead of D2 partially because of this. I think D1 is a great language, very *very* close to be complete. It's a shame to through that because D2 is cooler. For example, I can't use D for work. I can't convince my bosses to use D when you have to compile your own toolchain to get a debugger that works with it. C++ sucks, but I'm stucked with that as long as it has better tools support than D. And I think this is where D1 can start taking off, when it's ready for busyness, because unfortunatelly is really hard to produce things for D just as a hobby. And why this only happen to D? Really, don't you even ask yourselves? I think there is a "social" problem with D, or a "leadership" problem. I think people is not encouraged to work on D1.
 So, want the tool chain to mature.. go to work.  Work with the GDB community to
 build and incorporate changes.  The same with all the things you want to see
 changed or created.
Unfortunatelly I'm putting my work in the GC now. I was so annoyed a weak ago about not being able to use gdb, valgrind or nm with D that I downloaded valgrind to see how hard it would be to add D support to it, but I had to desist because I don't have the time right now.
 I think what D1 is *really* missing is that 2 things: completeness and
 tools support. Without that is really hard to take it seriously.
 
 I think the D team should be working more in that direction before
 finishing D2. I know is very boring comparing it to making D2, but I think
 that is what is transmitted from D maintainers: "D1 is boring, don't pay
 attention to it, D2 is fun, let's play with that!". And this is what
 happening. People are playing with D2 and forgetting to finish D1.
If you've gotten the impression that "d1 is boring" is the message from whatever this "the d team" (team suggests many people, but there's really just a tiny few involved -- this isn't microsoft or sun with hundreds of worker ants) is, then you're impression is off. The message is "d1 is only receiving bug fixes -- and only those with the right balance of risk/reward".
When I say "D team" I mean Walter, Andrei and Bartoz mostly, maybe Don and Seam too =) The impression is what it is. It can't be off. If something gives an impression it doesn't matter if you don't want to make that impression, that's the point (I know this maybe has no sense as it is written, english is not my first language and I don't know how to explain it better). And I think ignoring that that impression is made, when every month (or weak!) there is a thread about it, is dumb. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Es mas posible, que un elefante maneje un cero km a que un camello habite un departamento de un ambiente. -- Peperino Pómoro
May 09 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el  9 de mayo a las 12:31 me escribiste:
 If there's things that need to change in what the compiler emits, Walter has
 shown himself to be willing to rapidly change them where the required changes
 are clearly described in terms of both 'what' and 'why'.  In other words, "it's
 broken" isn't sufficient but "if the frobble was changed to frobnosticator for
 each wobble, it would work" results in the next release having that change
made.
BTW, here is something that should be fixed in the compiler to improve GNU binutils support =) http://d.puremagic.com/issues/show_bug.cgi?id=2932 -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Un paracaidista, que no deja de caer. Lo que me lleva hacia arriba, es lo que me tira hacia abajo.
May 09 2009
parent reply Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:
 Brad Roberts, el  9 de mayo a las 12:31 me escribiste:
 If there's things that need to change in what the compiler emits, Walter has
 shown himself to be willing to rapidly change them where the required changes
 are clearly described in terms of both 'what' and 'why'.  In other words, "it's
 broken" isn't sufficient but "if the frobble was changed to frobnosticator for
 each wobble, it would work" results in the next release having that change
made.
BTW, here is something that should be fixed in the compiler to improve GNU binutils support =) http://d.puremagic.com/issues/show_bug.cgi?id=2932
A great illustration of a less than ideal bug report. "A tool breaks in some way, fix the compiler." It's entirely possible that dmd is producing the wrong thing, but there's an definite lack of specificity about what's wrong on the compiler side. Those errors are coming out of the linker. It's not even particularly clear that the bug is with dmd and not the new linker (one that's not shipped as the default linker on any distribution yet, unless I've lost track again). In other words, it's not at all surprising to me that the bug report hasn't received a lot of attention yet. Prioritization is a difficult exercise, and there's no way everyone will ever be happy. Later, Brad
May 09 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el  9 de mayo a las 21:42 me escribiste:
 Leandro Lucarella wrote:
 Brad Roberts, el  9 de mayo a las 12:31 me escribiste:
 If there's things that need to change in what the compiler emits, Walter has
 shown himself to be willing to rapidly change them where the required changes
 are clearly described in terms of both 'what' and 'why'.  In other words, "it's
 broken" isn't sufficient but "if the frobble was changed to frobnosticator for
 each wobble, it would work" results in the next release having that change
made.
BTW, here is something that should be fixed in the compiler to improve GNU binutils support =) http://d.puremagic.com/issues/show_bug.cgi?id=2932
A great illustration of a less than ideal bug report. "A tool breaks in some way, fix the compiler." It's entirely possible that dmd is producing the wrong thing, but there's an definite lack of specificity about what's wrong on the compiler side. Those errors are coming out of the linker. It's not even particularly clear that the bug is with dmd and not the new linker (one that's not shipped as the default linker on any distribution yet, unless I've lost track again).
No, it's not (it's shipped but not as the default linker), because they are making sure that it works well with other tools. Usually when you use a tool that is a de facto standard and have some bug, people start relying in that bug as a feature. I know I had some linking bugs because of this, and I spotted them thanks to Gold. I'm not saying that Gold is perfect, but since it's a complete rewrite there are some bugs fixed (or things where is more strict than the old GNU ld) that should be adjusted to work well with the new linker. I reported the bug because I think that could be the case. If is not, it's a Gold bug and it should be reported. If it is, it should be fixed in DMD. I don't have the knowlegde to check that myself, and that's why I reported the bug to both tools.
 In other words, it's not at all surprising to me that the bug report
 hasn't received a lot of attention yet.
So you are saying you have to be a compiler hacker to report a bug? Great, that make sense! I think the error message is pretty clear (the ELF header size is supposed to be wrong). I think somebody that know the compiler can check if this bug report is right or if it's a bug in GNU Gold in a couple of minutes (maybe seconds). And BTW GDC and LDC works just fine. I guess you can argue that GDC uses the GCC backend which can be tightly coupled with GNU binutils being both a GNU product, but LDC is not. So the bug report has a high probability to be right, I wasn't saw the error message and run to the D bugzilla to report the bug, I tested other tools first, and from my own experience with Gold, when it said there was an error and I thought the error was in Gold, I was wrong and Gold was right (because what I said before, I was relying on some bugs in the old GNU ld), so I have some degree of confidence in that Gold is not a piece of crap full of bugs. And you may take a look to the GNU Gold linker bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=10126 It is having attention. That's why GNU tools are widely used and D isn't. This kind of things make very sad... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- VECINOS RESCATARON A CABALLITO ATROPELLADO -- Crónica TV
May 10 2009
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:

 I reported the bug because I think that could be the case. If is not, it's
 a Gold bug and it should be reported. If it is, it should be fixed in DMD.
 I don't have the knowlegde to check that myself, and that's why I reported
 the bug to both tools.
 
 In other words, it's not at all surprising to me that the bug report
 hasn't received a lot of attention yet.
So you are saying you have to be a compiler hacker to report a bug? Great, that make sense!
You seem to have missed my point. The point was, the more detailed the report, the clearer the steps to reproduce, the more obvious it is that the compiler is what's broken.. all of these things increase the likelihood of a bug report having a higher priority. The incoming rate is higher than the fix rate (as evidenced by the number of open bugs) and so something has to give. All I was doing was illustrating some reasons that might have contributed to that specific report not having been fixed yet. Do I encourage filing bugs without the level of detail I suggest help get bugs fixed fast? Absolutely. An un-filed bug is an un-fixed bug. Take these points as ways to help make sure your important issues can be addressed quickly and easily. Later, Brad
May 10 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el 10 de mayo a las 16:08 me escribiste:
 Leandro Lucarella wrote:
 
 I reported the bug because I think that could be the case. If is not, it's
 a Gold bug and it should be reported. If it is, it should be fixed in DMD.
 I don't have the knowlegde to check that myself, and that's why I reported
 the bug to both tools.
 
 In other words, it's not at all surprising to me that the bug report
 hasn't received a lot of attention yet.
So you are saying you have to be a compiler hacker to report a bug? Great, that make sense!
You seem to have missed my point. The point was, the more detailed the report, the clearer the steps to reproduce, the more obvious it is that the compiler is what's broken.. all of these things increase the likelihood of a bug report having a higher priority. The incoming rate is higher than the fix rate (as evidenced by the number of open bugs) and so something has to give. All I was doing was illustrating some reasons that might have contributed to that specific report not having been fixed yet. Do I encourage filing bugs without the level of detail I suggest help get bugs fixed fast? Absolutely. An un-filed bug is an un-fixed bug. Take these points as ways to help make sure your important issues can be addressed quickly and easily.
I totally agree, but you put my bug report as an example of a bad bug report. I don't think it is a bad bug report, so please let me know if you think I can improve it without being a compiler hacker. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- He used to do surgery On girls in the eighties But gravity always wins
May 10 2009
prev sibling parent reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20090509161148.GA23213 homero.springfield.home...
 The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
 addressing that is a huge error. It's only hurting D1 and preventing its
 adoption.
Yes. This is the showstopper for me and what caused me to quietly walk away from D to begin with. In my opinion the fact that having two runtimes is not only tolerable but acceptable as normal has and will continue to hurt D1. We have Phobos, the "official" runtime and then we have Tango, the "community" runtime. Moreover having two runtimes casts doubt on the state of D as a whole; if we can't even decide on a uniform runtime then people will wonder what other unknown traps of incompleteness are in store. The fact that nobody bothered to work all this out makes perfect sense- it's a lot more fun to be hashing out new features- but if we intend to gain some semblance of mainstream respect then it will be much easier with a single robust runtime. Ameer
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ameer Armaly wrote:
 Yes. This is the showstopper for me and what caused me to quietly walk away 
 from D to begin with. In my opinion the fact that having two runtimes is not 
 only tolerable but acceptable as normal has and will continue to hurt D1. We 
 have Phobos, the "official" runtime and then we have Tango, the "community" 
 runtime. Moreover having two runtimes casts doubt on the state of D as a 
 whole; if we can't even decide on a uniform runtime then people will wonder 
 what other unknown traps of incompleteness are in store. The fact that 
 nobody bothered to work all this out makes perfect sense- it's a lot more 
 fun to be hashing out new features- but if we intend to gain some semblance 
 of mainstream respect then it will be much easier with a single robust 
 runtime.
It has been bashed out for D2. Doing such changes to D1 will break everyone's D1 code, which destroys its mission of being stable.
May 11 2009
parent reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gua3u3$19c1$2 digitalmars.com...
 Ameer Armaly wrote:
 Yes. This is the showstopper for me and what caused me to quietly walk 
 away from D to begin with. In my opinion the fact that having two 
 runtimes is not only tolerable but acceptable as normal has and will 
 continue to hurt D1. We have Phobos, the "official" runtime and then we 
 have Tango, the "community" runtime. Moreover having two runtimes casts 
 doubt on the state of D as a whole; if we can't even decide on a uniform 
 runtime then people will wonder what other unknown traps of 
 incompleteness are in store. The fact that nobody bothered to work all 
 this out makes perfect sense- it's a lot more fun to be hashing out new 
 features- but if we intend to gain some semblance of mainstream respect 
 then it will be much easier with a single robust runtime.
It has been bashed out for D2. Doing such changes to D1 will break everyone's D1 code, which destroys its mission of being stable.
Really? I was under the impression that Tango will be ported to D2 to continue the battle of standard libs but if I'm mistaken, then it's a lot better than I originally figured.
May 11 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Ameer Armaly Wrote:

 
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gua3u3$19c1$2 digitalmars.com...
 Ameer Armaly wrote:
 Yes. This is the showstopper for me and what caused me to quietly walk 
 away from D to begin with. In my opinion the fact that having two 
 runtimes is not only tolerable but acceptable as normal has and will 
 continue to hurt D1. We have Phobos, the "official" runtime and then we 
 have Tango, the "community" runtime. Moreover having two runtimes casts 
 doubt on the state of D as a whole; if we can't even decide on a uniform 
 runtime then people will wonder what other unknown traps of 
 incompleteness are in store. The fact that nobody bothered to work all 
 this out makes perfect sense- it's a lot more fun to be hashing out new 
 features- but if we intend to gain some semblance of mainstream respect 
 then it will be much easier with a single robust runtime.
It has been bashed out for D2. Doing such changes to D1 will break everyone's D1 code, which destroys its mission of being stable.
Really? I was under the impression that Tango will be ported to D2 to continue the battle of standard libs but if I'm mistaken, then it's a lot better than I originally figured.
The druntime project is mostly a port of the Tango runtime to D2. On top of that, Don has ported the Tango math stuff to D2 Phobos. The stage is set for D2 Tango to be smaller and be installed alongside Phobos in D2. There really is only three reasons I'm aware of that stop D2 Tango from existing today: 1. There is no practical way to write code that compiles with both D1 and D2 2. There are bugs that limit how easily Tango can be ported to D2 3. D2 is a moving target make D2 a reality.
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 There really is only three reasons I'm aware of that stop D2 Tango
 from existing today:
 [...]
 2.  There are bugs that limit how easily Tango can be ported to D2
I've heard this now and then, along with a bugzilla number or two. I've fixed every one those problems brought to my attention weeks (months?) ago. If there are other bugzilla issues that prevent Tango from working with D2, please let me know what they are.
May 11 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Jason House wrote:
 There really is only three reasons I'm aware of that stop D2 Tango
 from existing today:
> [...]
 2.  There are bugs that limit how easily Tango can be ported to D2
I've heard this now and then, along with a bugzilla number or two. I've fixed every one those problems brought to my attention weeks (months?) ago. If there are other bugzilla issues that prevent Tango from working with D2, please let me know what they are.
Obviously, Tango devs should answer, but... IIRC, the whole "return const" thing is still an issue
May 11 2009
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Jason House (jason.james.house gmail.com)'s article
 Walter Bright Wrote:
 Jason House wrote:
 There really is only three reasons I'm aware of that stop D2 Tango
 from existing today:
> [...]
 2.  There are bugs that limit how easily Tango can be ported to D2
I've heard this now and then, along with a bugzilla number or two. I've fixed every one those problems brought to my attention weeks (months?) ago. If there are other bugzilla issues that prevent Tango from working with D2, please let me know what they are.
Obviously, Tango devs should answer, but... IIRC, the whole "return const" thing is still an issue
Yeah, I can see why noone wanted to design a half-baked solution to this before shared was implemented, since that's going to need a similar fix. Shared is coming next release. Therefore, I think it will soon be high time to address this issue.
May 11 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ameer Armaly wrote:
 It has been bashed out for D2. Doing such changes to D1 will break 
 everyone's D1 code, which destroys its mission of being stable.
Really? I was under the impression that Tango will be ported to D2 to continue the battle of standard libs but if I'm mistaken, then it's a lot better than I originally figured.
D2 has the "druntime" core which is designed to be the common root of Phobos and Tango. Switching to it involved a lot of changes to Phobos that broke existing user code.
May 11 2009
parent reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:guafcv$1tmg$3 digitalmars.com...
 Ameer Armaly wrote:
 It has been bashed out for D2. Doing such changes to D1 will break 
 everyone's D1 code, which destroys its mission of being stable.
Really? I was under the impression that Tango will be ported to D2 to continue the battle of standard libs but if I'm mistaken, then it's a lot better than I originally figured.
D2 has the "druntime" core which is designed to be the common root of Phobos and Tango. Switching to it involved a lot of changes to Phobos that broke existing user code.
I see. What about the actual "standard library bits" for common tasks like file I/O, strings, date and time, filesystem manipulation, etc. My main gripe is having two regularly accepted libraries that do the same extremely common functions; it makes us look unpolished, especially when there is the "community" versus "official" difference I mentioned earlier. Why not just merge the two libraries into the one D standard library and be done with it? I have yet to see a language with two standard libraries like we have now. [1] Thanks though for what's already been done. Ameer [1] I haven't really seen that many though- probably about a dozen.
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ameer Armaly wrote:
 I see. What about the actual "standard library bits" for common tasks like 
 file I/O, strings, date and time, filesystem manipulation, etc. My main 
 gripe is having two regularly accepted libraries that do the same extremely 
 common functions; it makes us look unpolished, especially when there is the 
 "community" versus "official" difference I mentioned earlier. Why not just 
 merge the two libraries into the one D standard library and be done with it?
That's being done for D2. It is not for D1, as that would break everyone's code.
May 11 2009
next sibling parent "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:guakkp$285n$1 digitalmars.com...
 Ameer Armaly wrote:
 I see. What about the actual "standard library bits" for common tasks 
 like file I/O, strings, date and time, filesystem manipulation, etc. My 
 main gripe is having two regularly accepted libraries that do the same 
 extremely common functions; it makes us look unpolished, especially when 
 there is the "community" versus "official" difference I mentioned 
 earlier. Why not just merge the two libraries into the one D standard 
 library and be done with it?
That's being done for D2. It is not for D1, as that would break everyone's code.
Ah. If we're aiming for one standard library, then I'll shut up and try and understand const.
May 11 2009
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:
 Ameer Armaly wrote:
 I see. What about the actual "standard library bits" for common tasks
 like file I/O, strings, date and time, filesystem manipulation, etc.
 My main gripe is having two regularly accepted libraries that do the
 same extremely common functions; it makes us look unpolished,
 especially when there is the "community" versus "official" difference
 I mentioned earlier. Why not just merge the two libraries into the one
 D standard library and be done with it?
That's being done for D2. It is not for D1, as that would break everyone's code.
Well, one runtime library. Anything beyond that isn't at all clear, is it? There's some rather fundamental design differences -- neither right nor wrong -- between Phobos and Tango. I don't see those converging at this point. Regardless, able to sit side by side is still a big step forward. Later, Brad
May 11 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steve Teale (steve.teale britseyeview.com)'s article
 OK so for those who crave stability there is D1.x, but when all the focus
appears to be on D2, what level of confidence is afforded to
D1 users. Can a project Manager cross his heart and say that D1 will still be alive and well in five years time? Will that project manager care? Most build teams don't update compiler versions very often--once a version has been settled upon that's pretty much it, unless a show-stopping bug appears during development that for some reason can't be worked around. In fact, I can't even see a team bothering to speculate about the future popularity of a language when choosing it for a project. The only thing that matters is whether it's a good decision today, not five years from now. If that weren't the case, then there would have never been a call for COBOL programmers during the Y2K transition.
May 08 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Will that project manager care?  Most build teams don't update compiler
 versions very often--once a version has been settled upon that's pretty
 much it, unless a show-stopping bug appears during development that
 for some reason can't be worked around.  In fact, I can't even see a team
 bothering to speculate about the future popularity of a language when
 choosing it for a project.  The only thing that matters is whether it's a
 good decision today, not five years from now.  If that weren't the case,
 then there would have never been a call for COBOL programmers
 during the Y2K transition.
Back in the 80's, the company I worked for did a project in a particular dialect of pascal. The company making that dialect went bust, and the company was left holding the bag with mission critical app. The compiler was binary only, had bugs, required old hardware to run on, etc. The dmd compiler source being available goes a very long way to alleviating such problems. Also, any significant dev project needs to archive the compiler used to build it along with the project. Regardless of the language. That just only makes sense.
May 08 2009
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Back in the 80's, the company I worked for did a project in a particular
 dialect of pascal. The company making that dialect went bust, and the
 company was left holding the bag with mission critical app. The compiler
 was binary only, had bugs, required old hardware to run on, etc.
 The dmd compiler source being available goes a very long way to
 alleviating such problems.
Definitely. A big build team would want the compiler source code available to future-proof their investment. This obviously also supports the assertion that such teams aren't likely to upgrade compiler versions very often :-)
May 08 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Sean Kelly wrote:
 == Quote from Steve Teale (steve.teale britseyeview.com)'s article
 OK so for those who crave stability there is D1.x, but when all the focus
appears to be on D2, what level of confidence is afforded to
D1 users. Can a project Manager cross his heart and say that D1 will still be alive and well in five years time? Will that project manager care? Most build teams don't update compiler versions very often--once a version has been settled upon that's pretty much it, unless a show-stopping bug appears during development that for some reason can't be worked around. In fact, I can't even see a team bothering to speculate about the future popularity of a language when choosing it for a project. The only thing that matters is whether it's a good decision today, not five years from now. If that weren't the case, then there would have never been a call for COBOL programmers during the Y2K transition.
In the Windows world, you get a new compiler every two to three years, so that's hardly an issue. Similarly with Java. Open source projects tend to have to support wider ranges of compilers. I've seen OSS projects where they prioritized issues specific to gcc-3.4.2 as highly as any other issue, even if the developers typically used the 4.x branch.
May 08 2009
parent reply torhu <no spam.invalid> writes:
On 09.05.2009 00:29, Christopher Wright wrote:
 Open source projects tend to have to support wider ranges of compilers.
 I've seen OSS projects where they prioritized issues specific to
 gcc-3.4.2 as highly as any other issue, even if the developers typically
 used the 4.x branch.
That's probably because they wanted to be cross-platform, since 3.4.2 was the latest GCC supported by minGw for a long time.
May 08 2009
parent Christopher Wright <dhasenan gmail.com> writes:
torhu wrote:
 On 09.05.2009 00:29, Christopher Wright wrote:
 Open source projects tend to have to support wider ranges of compilers.
 I've seen OSS projects where they prioritized issues specific to
 gcc-3.4.2 as highly as any other issue, even if the developers typically
 used the 4.x branch.
That's probably because they wanted to be cross-platform, since 3.4.2 was the latest GCC supported by minGw for a long time.
No; there has sadly never been a release of Enlightenment DR17 for MinGW.
May 09 2009
prev sibling parent reply "Tyro[a.c.edwards]" <nospam home.com> writes:
On 5/9/2009 3:38 AM, Steve Teale wrote:
 Walter Bright Wrote:

 Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
What bothers me about this sentiment is that every other mainstream language undergoes revision, sometimes major ones, but that never seems to be an excuse for people to not use it. For example, C++ is quite in flux with C++0x. The only languages that are not undergoing revision are dead ones.
Yes Walter, but C++ went through a tedious standardization process - itself a long argument. So there was some basis for people to think that it had 'got there'. But to come back after 2 years and find the same stuff still going on is depressing - been there done that. OK, it didn't put me off, I'm still in there, but it bothers me. I'd be dishonest if I said otherwise. I am not criticizing you. I think you are doing a great job under the pressure of a slew of suggestions. But maybe a line in the sand at some point? OK so for those who crave stability there is D1.x, but when all the focus appears to be on D2, what level of confidence is afforded to D1 users. Can a project Manager cross his heart and say that D1 will still be alive and well in five years time?
This is quite interesting! Before there was D1, I can remember the same requests being submitted over and over again. Tool developers complained that they could not use D for anything serious because of its constant state of flux. They continuously requested that a line be drawn. Shortly after that line was drawn in January 2007, a good majority of the community complained that it wasn't exactly what they asked for and a majority of the most active members of the community disappeared into thin air. The sad thing is, even after D1 became stable following a number of bug fixes, very few people used it for much of anything. Those "advocates of stability" all disappeared; abandoning their tools/projects in the process. The same thing is beginning again and it seems to me that instead of something that is actually useful, people a waiting for MicroMoney or some other name brand begins to invest in their own D compiler. As far as I see it, there will come a time when D language will soar above all the rest (not only in capability, which it already does, but also commercial usage), I will continue to support it until then and well beyond and I'm quite sure that I'm not the only one. For all the Naysayers out there... Keep saying nay and go the hell away. D2 is just where it is supposed to be. Let’s not end up in the same mess we did by trying to make impatient people happy and releasing D1. Andrew
May 08 2009
next sibling parent reply grauzone <none example.net> writes:
 beyond and I'm quite sure that I'm not the only one. For all the 
 Naysayers out there... Keep saying nay and go the hell away. D2 is just 
 where it is supposed to be. Let’s not end up in the same mess we did by 
 trying to make impatient people happy and releasing D1.
What about the people who want to use D for something actually useful?
May 08 2009
next sibling parent reply "Tyro[a.c.edwards]" <nospam home.com> writes:
On 5/9/2009 11:24 AM, grauzone wrote:
 beyond and I'm quite sure that I'm not the only one. For all the
 Naysayers out there... Keep saying nay and go the hell away. D2 is
 just where it is supposed to be. Let’s not end up in the same mess we
 did by trying to make impatient people happy and releasing D1.
What about the people who want to use D for something actually useful?
Well, for those cases, there is D1. Which, if I may add, is extremely stable. Take a network administrator running his server or firewall on say DragonFly or any of the many flavors of BSD or Linux; he does not upgrade his server with nightly builds, he sticks instead with a "stable," well tested branch of the OS and experiments with "current." When current becomes stable, the OS developer does not stop developing his OS, he continues on with his vision while the "users" further stress-tests the newly stabilized branch and take steps to find and correct any holes in the system. And our system administrator, well, he doesn't switch until he is comfortable that the newly stabilized branch meets all his criteria for upgrade. If they are not met... he waits until the OS branches again. We cannot expect the compiler developer to stop developing compilers until after the tools developers decide to build tools. He has done his job, which is to develop a stable, documented compiler. Use it to develop your tools which will in turn allow the compiler/language to gain popularity. Report any bug reports on anything that seems out of the ordinary so that it can either be clarified in documentation or corrected with code. Walter is a damn good Engineer but I don't think his interests lie in writing tools (IDE and the like). So those people that do write those tools may want to take the "stable" compiler and start developing. So what if this feature "that is in D2" is not in D1? Use what you have in D1 and develop your tools and simply stay abreast with the development of D2 so that when it is time to switch, you are not in the dark. Andrew
May 08 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Tyro[a.c.edwards] wrote:
 On 5/9/2009 11:24 AM, grauzone wrote:
 beyond and I'm quite sure that I'm not the only one. For all the
 Naysayers out there... Keep saying nay and go the hell away. D2 is
 just where it is supposed to be. Let’s not end up in the same mess we
 did by trying to make impatient people happy and releasing D1.
What about the people who want to use D for something actually useful?
Well, for those cases, there is D1. Which, if I may add, is extremely stable.
Agreed -- I haven't had to update my D1 code due to compiler changes, even if it's over a year old. Only library changes force me to update it. The only reason I bother updating my compiler is because of bugfixes and Tango updates which require those bugfixes.
May 09 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 beyond and I'm quite sure that I'm not the only one. For all the 
 Naysayers out there... Keep saying nay and go the hell away. D2 is 
 just where it is supposed to be. Let’s not end up in the same mess we 
 did by trying to make impatient people happy and releasing D1.
What about the people who want to use D for something actually useful?
They can if they really want, just as much as others can keep on naysaying if they really want :o). Andrei
May 08 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tyro[a.c.edwards] wrote:
 On 5/9/2009 3:38 AM, Steve Teale wrote:
 Walter Bright Wrote:

 Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
What bothers me about this sentiment is that every other mainstream language undergoes revision, sometimes major ones, but that never seems to be an excuse for people to not use it. For example, C++ is quite in flux with C++0x. The only languages that are not undergoing revision are dead ones.
Yes Walter, but C++ went through a tedious standardization process - itself a long argument. So there was some basis for people to think that it had 'got there'. But to come back after 2 years and find the same stuff still going on is depressing - been there done that. OK, it didn't put me off, I'm still in there, but it bothers me. I'd be dishonest if I said otherwise. I am not criticizing you. I think you are doing a great job under the pressure of a slew of suggestions. But maybe a line in the sand at some point? OK so for those who crave stability there is D1.x, but when all the focus appears to be on D2, what level of confidence is afforded to D1 users. Can a project Manager cross his heart and say that D1 will still be alive and well in five years time?
This is quite interesting! Before there was D1, I can remember the same requests being submitted over and over again. Tool developers complained that they could not use D for anything serious because of its constant state of flux. They continuously requested that a line be drawn. Shortly after that line was drawn in January 2007, a good majority of the community complained that it wasn't exactly what they asked for and a majority of the most active members of the community disappeared into thin air. The sad thing is, even after D1 became stable following a number of bug fixes, very few people used it for much of anything. Those "advocates of stability" all disappeared; abandoning their tools/projects in the process. The same thing is beginning again and it seems to me that instead of something that is actually useful, people a waiting for MicroMoney or some other name brand begins to invest in their own D compiler. As far as I see it, there will come a time when D language will soar above all the rest (not only in capability, which it already does, but also commercial usage), I will continue to support it until then and well beyond and I'm quite sure that I'm not the only one. For all the Naysayers out there... Keep saying nay and go the hell away. D2 is just where it is supposed to be. Let’s not end up in the same mess we did by trying to make impatient people happy and releasing D1. Andrew
Very well and heartfelt put. D needs many things, but probably above all it needs the dedication of bright people. I've had a great time at BoostCon, and enjoyed many interesting conversations with as many bright people. Beman Dawes, the originator of Boost and an extraordinary gentleman, gave me a little history of Boost. Essentially Boost has been toiling in anonymity until Dave Abrahams came about. Dave is a design, coding, and organizational powerhouse all in one. He not only contributed a great deal of design and code to Boost, but also managed organizational and logistics aspects, in addition to exercising the charisma necessary for attracting other extraordinarily qualified people to dedicate their prime to Boost. And it has snowballed ever since. It was amazing just being at Boostcon to see how much expertise punch those people packed. We are lacking such a powerhouse for D. Walter is a great lone wolf kind of coder, but not a team organizer and charismatic leader. Things have been changed to the better since he has made Phobos accessible on dsource.org and since he released the source of the compiler. Integration with druntime was another great step forward (thanks Sean!) Soon we may convince Walter to put the entire dmd source on dsource.org, which would improve things even more. But the role of "Dave" for D is still up for grabs. Of course it's not that easy to find that, but in the meantime there's a lot of good things to be done. If you do something great, sooner or later it will be picked up. The perfect example is Don, who became a prominent contributor solely through the sheer quality and quantity of his work. (There are many others that come to mind, but please allow me to stay with one because as soon as I mention more than one, I'd feel I'm unjust to others that I might even forget for the moment.) So what I think D really needs is your heart and soul :o). Let me (re)try to make a step in that direction by reopening the Phobos czar position. Gregor Richards has held that position for a while but hasn't done anything with it. (I'm not saying this with reproach; Gregor has been busy with school and if I don't know what that means...) I can hardly imagine what someone like Dave could do with that role. So if anyone is interested, speak up! Andrei
May 08 2009
parent Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 Tyro[a.c.edwards] wrote:
 On 5/9/2009 3:38 AM, Steve Teale wrote:
 Walter Bright Wrote:

 Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
What bothers me about this sentiment is that every other mainstream language undergoes revision, sometimes major ones, but that never seems to be an excuse for people to not use it. For example, C++ is quite in flux with C++0x. The only languages that are not undergoing revision are dead ones.
Yes Walter, but C++ went through a tedious standardization process - itself a long argument. So there was some basis for people to think that it had 'got there'. But to come back after 2 years and find the same stuff still going on is depressing - been there done that. OK, it didn't put me off, I'm still in there, but it bothers me. I'd be dishonest if I said otherwise. I am not criticizing you. I think you are doing a great job under the pressure of a slew of suggestions. But maybe a line in the sand at some point? OK so for those who crave stability there is D1.x, but when all the focus appears to be on D2, what level of confidence is afforded to D1 users. Can a project Manager cross his heart and say that D1 will still be alive and well in five years time?
This is quite interesting! Before there was D1, I can remember the same requests being submitted over and over again. Tool developers complained that they could not use D for anything serious because of its constant state of flux. They continuously requested that a line be drawn. Shortly after that line was drawn in January 2007, a good majority of the community complained that it wasn't exactly what they asked for and a majority of the most active members of the community disappeared into thin air. The sad thing is, even after D1 became stable following a number of bug fixes, very few people used it for much of anything. Those "advocates of stability" all disappeared; abandoning their tools/projects in the process. The same thing is beginning again and it seems to me that instead of something that is actually useful, people a waiting for MicroMoney or some other name brand begins to invest in their own D compiler. As far as I see it, there will come a time when D language will soar above all the rest (not only in capability, which it already does, but also commercial usage), I will continue to support it until then and well beyond and I'm quite sure that I'm not the only one. For all the Naysayers out there... Keep saying nay and go the hell away. D2 is just where it is supposed to be. Let’s not end up in the same mess we did by trying to make impatient people happy and releasing D1. Andrew
Very well and heartfelt put. D needs many things, but probably above all it needs the dedication of bright people. I've had a great time at BoostCon, and enjoyed many interesting conversations with as many bright people. Beman Dawes, the originator of Boost and an extraordinary gentleman, gave me a little history of Boost. Essentially Boost has been toiling in anonymity until Dave Abrahams came about. Dave is a design, coding, and organizational powerhouse all in one. He not only contributed a great deal of design and code to Boost, but also managed organizational and logistics aspects, in addition to exercising the charisma necessary for attracting other extraordinarily qualified people to dedicate their prime to Boost.
That's a rather rare find. Typically, that would require the contribution of many individuals to achieve the same effect. Even if you only consider the time required to do all that, it can be a tall order!
 And it has snowballed 
 ever since. It was amazing just being at Boostcon to see how much 
 expertise punch those people packed.
 
 We are lacking such a powerhouse for D. Walter is a great lone wolf kind 
 of coder, but not a team organizer and charismatic leader. Things have 
 been changed to the better since he has made Phobos accessible on 
 dsource.org and since he released the source of the compiler. 
 Integration with druntime was another great step forward (thanks Sean!) 
 Soon we may convince Walter to put the entire dmd source on dsource.org, 
 which would improve things even more. 
I've been hoping for that! I tried to create a thread about that a while back, but it passed silently into oblivion.
 But the role of "Dave" for D is 
 still up for grabs.
 
 Of course it's not that easy to find that, but in the meantime there's a 
 lot of good things to be done. If you do something great, sooner or 
 later it will be picked up. The perfect example is Don, who became a 
 prominent contributor solely through the sheer quality and quantity of 
 his work. (There are many others that come to mind, but please allow me 
 to stay with one because as soon as I mention more than one, I'd feel 
 I'm unjust to others that I might even forget for the moment.)
 
 So what I think D really needs is your heart and soul :o). Let me 
 (re)try to make a step in that direction by reopening the Phobos czar 
 position. Gregor Richards has held that position for a while but hasn't 
 done anything with it. (I'm not saying this with reproach; Gregor has 
 been busy with school and if I don't know what that means...) I can 
 hardly imagine what someone like Dave could do with that role. So if 
 anyone is interested, speak up!
Like many, I can't become a/the czar, but will slowly contribute from the sidelines. I submitted a weak reference library for druntime and am now working on a high throughput lockless hashmap.
 
 Andrei
May 09 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
What bothers me about this sentiment is that every other mainstream language undergoes revision, sometimes major ones, but that never seems to be an excuse for people to not use it. For example, C++ is quite in flux with C++0x. The only languages that are not undergoing revision are dead ones.
Exactly my feelings, but I'll add that the time to make huge, sweeping changes like the ones we're seeing now is before the language becomes mainstream. Once the language has a large base of crufty production code that nobody still understands and can fix quickly and easily when the language changes, it becomes much harder to make these kinds of changes.
May 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 Exactly my feelings, but I'll add that the time to make huge, sweeping changes
 like the ones we're seeing now is before the language becomes mainstream.  Once
 the language has a large base of crufty production code that nobody still
 understands and can fix quickly and easily when the language changes, it
becomes
 much harder to make these kinds of changes.
Yes. The next D2 update will have one such change, which has been planned for maybe the past year. All static and global variables will default to being thread local (instead of being implicitly shared). Doing this is disruptive, but is critical to credibly supporting multithreaded programming. In testing this out, I've uncovered at least a dozen implicit sharing bugs in Phobos. I think this change will have a big payoff for multithreaded code.
May 08 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 dsimcha wrote:
 Exactly my feelings, but I'll add that the time to make huge, sweeping changes
 like the ones we're seeing now is before the language becomes mainstream.  Once
 the language has a large base of crufty production code that nobody still
 understands and can fix quickly and easily when the language changes, it
becomes
 much harder to make these kinds of changes.
Yes. The next D2 update will have one such change, which has been planned for maybe the past year. All static and global variables will default to being thread local (instead of being implicitly shared). Doing this is disruptive, but is critical to credibly supporting multithreaded programming. In testing this out, I've uncovered at least a dozen implicit sharing bugs in Phobos. I think this change will have a big payoff for multithreaded code.
Awesome. I actually found a few of these bugs in the past few days, and was meaning to report them. I guess I don't need to now. Just out of curiosity, though, you use __gshared in a lot of places and I haven't seen it in any of the discussions. What is it?
May 08 2009
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from dsimcha (dsimcha yahoo.com)'s article
 Awesome.  I actually found a few of these bugs in the past few days, and was
 meaning to report them.  I guess I don't need to now.  Just out of curiosity,
 though, you use __gshared in a lot of places and I haven't seen it in any of
the
 discussions.  What is it?
It's a way to declare something as "classic global" so you can sidestep any bugs that crop up with the implementation of 'shared'. The hope is that you'll eventually just be able to do a search/replace of '__gshared' to 'shared' once everything is working correctly.
May 08 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 It's a way to declare something as "classic global" so you can sidestep any
bugs
 that crop up with the implementation of 'shared'.  The hope is that you'll
 eventually just be able to do a search/replace of '__gshared' to 'shared' once
 everything is working correctly.
I like the moniker "classic global", or perhaps even better, "global classic" as a term for it.
May 08 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 Just out of curiosity,
 though, you use __gshared in a lot of places and I haven't seen it in any of
the
 discussions.  What is it?
__gshared is the "cowboy" approach, it means make it global and I don't care about any weenie synchronization or type checking. It's handy for initial ports of "I just want it to compile, I'll fix it later". Naturally, it won't be allowed in safe mode.
May 08 2009
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Walter Bright schrieb:
 dsimcha wrote:
 Exactly my feelings, but I'll add that the time to make huge, sweeping
 changes
 like the ones we're seeing now is before the language becomes
 mainstream.  Once
 the language has a large base of crufty production code that nobody still
 understands and can fix quickly and easily when the language changes,
 it becomes
 much harder to make these kinds of changes.
Yes. The next D2 update will have one such change, which has been planned for maybe the past year. All static and global variables will default to being thread local (instead of being implicitly shared). Doing this is disruptive, but is critical to credibly supporting multithreaded programming. In testing this out, I've uncovered at least a dozen implicit sharing bugs in Phobos. I think this change will have a big payoff for multithreaded code.
can you allow "shared" or "__gshared" in D1 as do-nothing keywords? That will make it more easy to write code that compiles for D1 and D2. Or is there a trick to accomplish this?
May 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Frank Benoit wrote:
 can you allow "shared" or "__gshared" in D1 as do-nothing keywords? That
 will make it more easy to write code that compiles for D1 and D2.
 Or is there a trick to accomplish this?
I think that making code that will compile under both is an impractical task.
May 08 2009
parent Derek Parnell <derek psych.ward> writes:
On Fri, 08 May 2009 16:20:48 -0700, Walter Bright wrote:

 Frank Benoit wrote:
 can you allow "shared" or "__gshared" in D1 as do-nothing keywords? That
 will make it more easy to write code that compiles for D1 and D2.
 Or is there a trick to accomplish this?
I think that making code that will compile under both is an impractical task.
I'm thinking that D1 is really the prototype edition of D, and D2 will be the first release edition of the "D Programming Language". By this I mean that D1 has worked out to be a sounding board that has helped define what the design requirements for "D" have really been. The process is not over as usage of D1 is still pointing out things that need to be in D2. This is a good thing. And if we end up with two languages (D1=D_proto and D2=D_proper) in which both are stable, then that is not such a bad outcome. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 08 2009
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:

 Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".
 
 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.
 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
What bothers me about this sentiment is that every other mainstream language undergoes revision, sometimes major ones, but that never seems to be an excuse for people to not use it. For example, C++ is quite in flux with C++0x. The only languages that are not undergoing revision are dead ones.
There are some differences though: - other mainstream languages release new compilers and features every couple of years, you do so every couple of months! - these other languages go out of their way to make new releases backwards compatible, sometimes at great costs. They almost never completely succeed though. To be clear, I do think these are good things for D evolution, but most people are wary to invest energy in change. Reflecting back on the commitment to D1, I think this was a good move in two ways: it allowed larger programs and libraries to rely on it and may have freed the way for D2 to incorporate bolder changes.
May 08 2009
next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Lutger wrote:
 - other mainstream languages release new compilers and features every couple 
 of years, you do so every couple of months!
Rapid evolution is a good thing. For every improvement that will be made to the D2 language, I'd rather see that improvement in a week than in a couple of years. *Especially* for improvements that break backwards compatibility. D2 is incomplete right now. The faster it evolves, the sooner it'll reach completion, at which point it should be as stable as any language. -- Rainer Deyke - rainerd eldwood.com
May 08 2009
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Lutger wrote:

 - these other languages go out of their way to make new releases  
 backwards
 compatible, sometimes at great costs. They almost never completely  
 succeed
 though.
And D1 makes an effort to follow the spec, and will not incorporate breaking changes. D2 is, in many ways, a whole new language. Sure, you could argue that D1 code should be compilable in D2, but it would matter no more than the argument that C code should be compilable in D1. -- Simen
May 08 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Simen Kjaeraas wrote:

 Lutger wrote:
 
 - these other languages go out of their way to make new releases  
 backwards
 compatible, sometimes at great costs. They almost never completely  
 succeed
 though.
And D1 makes an effort to follow the spec, and will not incorporate breaking changes. D2 is, in many ways, a whole new language. Sure, you could argue that D1 code should be compilable in D2, but it would matter no more than the argument that C code should be compilable in D1. -- Simen
I'm certainly not making that argument. In the talk Andrei and Walter gave at the D conference they mentioned the design goal 'no issue left behind' This is what makes D evolution so much more interesting. (C is not fair, too old): you can easily upgrade from 2.0 to 3.5 and beyond. Most important part of that ease is the ability to use older libraries in a
May 08 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Steve,

 BCS Wrote:
 
 Hello Ameer,
 
 Hi all.
 When I last used D a couple years ago, 2.0 was the experimental
 branch and
 1.0 was stable.
still true
 Now that I have a little time on my hands I'm wondering: what is the
 current landscape? Is 2.0 approaching any sort of stability?
 
the const system is stable and now it's starting to play with threading
 Are
 there still two competing runtime libraries or have they been
 merged?
No not for 1.0 (and they never will be) but /when/ Tango gets ported to 2.0 they will coexist.
 Basically I want to know if it's worth using 2.0 for anything of
 importance
 or is it still in flux?
Don't use it for bet-the-bank code. Use it for, fun-n-games code. Between them, it's up to you.
 Thanks,
 Ameer
This is the sort of answer that will kill D. The guy comes back after 2 years, asks a straight question, and get's told "business as usual, we're still arguing among ourselves about what it should be".
What, should I lie? Of am I smoking something? If what I said is true and will kill D than we need to fix something. (that said...)
 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
 
I don't see how that can be done. For people to use it there needs to be a stable platform to work with. For it to evolve it needs to be able to make breaking changers. These fundamentally conflict. The only solution I can see is that D1.0 is the first and should be used for things that need stability and 2.0 is the evolving version and shouldn't be used for things that need stability until it stabilizes. How would you have it done?
May 08 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after 2 years,
asks a straight question, and get's told "business as usual, we're still
arguing among ourselves about what it should be".
Last week I asked Andrei what DMD2/Phobos to use, looking for something stable. I wanted to use D2, but he couldn't answer that question. So why is it a problem to give this person an honest answer? I don't want D2 to be a rush job. Cool things are happening with it. I am, however, impatient for it to be stable, but I'm not upset that it isn't. It just means I won't use D2 for most of my projects just yet.
May 08 2009
prev sibling next sibling parent reply F <x y.com> writes:
I agree. Yes, I still use D/D2 for my home-based projects and not in my work.
So, you could say it is (still) a toy. But, with every release and bug fix, it
becomes better and better language. I upgrade to the new release with joy, but
I am not forced to do so if that will break my code.

Finally, new releases are provided as optional, not as compulsory. If someone
wants to stick with one compiler version, he/she could do the job with that
version and that's all.

I don't think stability should become an obstacle in looking for better. Life
evolves, compilers and languages should do that too. It is us, people, which
should come at length with that truth.



Walter Bright Wrote:

 Steve Teale wrote:
 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".
 
 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.
 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
What bothers me about this sentiment is that every other mainstream language undergoes revision, sometimes major ones, but that never seems to be an excuse for people to not use it. For example, C++ is quite in flux with C++0x. The only languages that are not undergoing revision are dead ones.
May 08 2009
parent reply BCS <ao pathlink.com> writes:
Reply to F,

 Finally, new releases are provided as optional, not as compulsory. If
 someone wants to stick with one compiler version, he/she could do the
 job with that version and that's all.
 
The one issue with that re 2.0 is that you can be faced with choosing between working thought a breaking change or not getting bug fixes ever again.
May 08 2009
parent Don <nospam nospam.com> writes:
BCS wrote:
 Reply to F,
 
 Finally, new releases are provided as optional, not as compulsory. If
 someone wants to stick with one compiler version, he/she could do the
 job with that version and that's all.
The one issue with that re 2.0 is that you can be faced with choosing between working thought a breaking change or not getting bug fixes ever again.
Yes, but there's no way it would make sense to standardize on a particular release of D2 -- it's still in way too much of an alpha state. In another six months, I think it would make sense.
May 09 2009
prev sibling next sibling parent reply mpt <mpt ikikiki.fi> writes:
I keep making 2 mistakes in my D programs, and fixing them feels
troublesome.

1. Null references. I get a segfault and gdb is useless (ldc thing maybe).
2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
the real cause of error.

Shouldn't there be an automatic null check for references and stack
traces? Sometimes I think I'm using the wrong tool as others have
solutions for these.
May 09 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"mpt" <mpt ikikiki.fi> wrote in message 
news:gu4unq$16e2$1 digitalmars.com...
I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing maybe).
 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.
These are two very common complaints, and there has been a lot of disussion about both. Hopefully they'll get taken care of.
May 09 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gu51vu$1e2f$1 digitalmars.com...
 "mpt" <mpt ikikiki.fi> wrote in message 
 news:gu4unq$16e2$1 digitalmars.com...
I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing 
 maybe).
 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.
These are two very common complaints, and there has been a lot of disussion about both. Hopefully they'll get taken care of.
To elaborate: Pretty much everyone agrees we need stack traces on exceptions. I'm actually kind of surprised DMD still doesn't have them, I wouldn't think it would be a real major change (at least compared to some other things). IIRC, I think the Linux LDC already has this feature. About the null references, most people seem to agree that the right way to fix that is with some sort of "non-nullable". But there's a lot of disagreement on exactly how non-nullables should work.
May 09 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Nick Sabalausky wrote:
 About the null references, most people seem to agree that the right way to 
 fix that is with some sort of "non-nullable". But there's a lot of 
 disagreement on exactly how non-nullables should work.
And whether they *can* work. D2 has struct constructors, so structs can have non-nullable fields, but you can't have an array of non-nullable elements (you can set the length, and suddenly your non-nullable-element array has a bunch of nulls in it). Similarly, no arrays of structs containing non-nullable types, etc. There are a lot of things to look into with non-nullables, and Walter doesn't have the time.
May 10 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Christopher Wright wrote:

 About the null references, most people seem to agree that the right way
 to fix that is with some sort of "non-nullable". But there's a lot of
 disagreement on exactly how non-nullables should work.
And whether they *can* work. D2 has struct constructors, so structs can have non-nullable fields, but you can't have an array of non-nullable elements (you can set the length, and suddenly your non-nullable-element array has a bunch of nulls in it). Similarly, no arrays of structs containing non-nullable types, etc.
The point of non-nullables would be to detect improper usage at compile-time, right? Then I don't believe this problem has an elegant solution until compilers can do a rigorous control-flow analysis. Specifying default pointer values other than null doesn't seem very nice. Nonetheless, a good step forward would be to recognize the distinction between `null' and `uninitialized'. Reading a variable that's uninitialized is an error. Reading a null pointer is fine, but dereferencing it is an error. This effectively solves your non-nullable problems, but you'd basically be replacing them with another problem. In general, you can only know if a variable is initialized at run-time. And then only if you reserve memory for the `uninitialized' state. So effectively, what's the difference between that and the original null reference problem? You'd basically get the runtime error when you read the pointer, but before you dereference it. Until compilers are smart enough. -- Michiel Helvensteijn
May 10 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Michiel Helvensteijn wrote:
 ...
 
 The point of non-nullables would be to detect improper usage at
 compile-time, right? Then I don't believe this problem has an elegant
 solution until compilers can do a rigorous control-flow analysis.
 Specifying default pointer values other than null doesn't seem very nice.
You don't need control-flow analysis. You just need a type system which supports nullables like D2's supports const.
 Nonetheless, a good step forward would be to recognize the distinction
 between `null' and `uninitialized'. Reading a variable that's uninitialized
 is an error. Reading a null pointer is fine, but dereferencing it is an
 error.
Uninitialised variables is only a symptom. The larger issue is that it doesn't make sense for most functions to accept null object arguments. It's quite rare, at least in my code, to have a function that can do anything sensible with "nothing" other than HCF [1].
 This effectively solves your non-nullable problems, but you'd basically be
 replacing them with another problem.
No, it doesn't.
 ...
 
 So effectively, what's the difference between that and the original null
 reference problem? You'd basically get the runtime error when you read the
 pointer, but before you dereference it.
 
 Until compilers are smart enough.
The whole point of having non-nullable types is so that you can't even STORE a null in the first place. We already have a runtime check, and it's not good enough. The major issue is that it notifies us of a problem at a time when we generally do not have any useful information on how to solve it. The problem isn't dereferencing nulls. It's when they get STORED that's the problem. -- Daniel [1] HCF - Halt and Catch Fire; old instruction on the PDP machines. :P
May 10 2009
parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
It seems I didn't explain myself very clearly.

Daniel Keep wrote:

 The point of non-nullables would be to detect improper usage at
 compile-time, right? Then I don't believe this problem has an elegant
 solution until compilers can do a rigorous control-flow analysis.
 Specifying default pointer values other than null doesn't seem very nice.
You don't need control-flow analysis. You just need a type system which supports nullables like D2's supports const.
You need control-flow analysis to know at compile-time if: * an uninitialized value is read, or * a null pointer is dereferenced.
 Nonetheless, a good step forward would be to recognize the distinction
 between `null' and `uninitialized'. Reading a variable that's
 uninitialized is an error. Reading a null pointer is fine, but
 dereferencing it is an error.
Uninitialised variables is only a symptom. The larger issue is that it doesn't make sense for most functions to accept null object arguments. It's quite rare, at least in my code, to have a function that can do anything sensible with "nothing" other than HCF [1].
I understand the issue. In my idea, there are non-nullable pointers. In fact, they would probably be the default kind of pointer. But Christopher explained those kinds of pointers have their own problems. How to initialize an array of non-nullables? Or a struct? So formally introduce the notion of `uninitialized' variables, or in particular, pointers. No need to initialize (even non-nullables) right away. Just initialize anytime. I believe in D you specify this with =void. But don't you see, you've replaced your null-dereference problem with a uninitialized-reading problem. That's basically the same deal.
 We already have a runtime check, and
 it's not good enough.  The major issue is that it notifies us of a
 problem at a time when we generally do not have any useful information
 on how to solve it.
Exactly. This brings me back to the need for rigorous control-flow analysis. Without it, you can't get your info at compile-time in the general case. -- Michiel Helvensteijn
May 10 2009
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Sun, May 10, 2009 at 12:05 AM, mpt <mpt ikikiki.fi> wrote:
 I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing maybe).
Useless how? Generally LDC debug info should be decent. If not, we'd be glad to look into why that is!
 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.
May 09 2009
parent mpt <mpt ikikiki.fi> writes:
Tomas Lindquist Olsen wrote:
 On Sun, May 10, 2009 at 12:05 AM, mpt <mpt ikikiki.fi> wrote:
 I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing maybe).
Useless how? Generally LDC debug info should be decent. If not, we'd be glad to look into why that is!
I had a problem in the past where gdb would only output a bunch of ???'s like it does for stripped or optimized executables. This seems no longer to be the case. I stand corrected.
May 10 2009
prev sibling parent reply torhu <no spam.invalid> writes:
On 10.05.2009 00:05, mpt wrote:
 I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing maybe).
 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.
Tango trunk has stacktrace functionality for both Windows and linux I think. There's also a Phobos backtrace patch.
May 09 2009
parent Christopher Wright <dhasenan gmail.com> writes:
torhu wrote:
 On 10.05.2009 00:05, mpt wrote:
 I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing 
 maybe).
 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.
Tango trunk has stacktrace functionality for both Windows and linux I think. There's also a Phobos backtrace patch.
Though the Linux one just prints out the addresses and not the line numbers. Licensing issues with linking to libbfd to extract that information.
May 10 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:

I think this is another problem with D, version naming is really confusing and
lame. You can't know anything from a D version number.<
Yes, improving such small things is positive. So I suggest to start using a "language.version.releaseStatus" numbering scheme for D2 (and maybe for D2 too). So the current D2 becomes: 2.0.30alpha and the current D1 becomes: 1.0.45 Once D2 gets out of alpha it may become: 2.1.0 Bye, bearophile
May 15 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
bearophile wrote:
 Leandro Lucarella:
 
 I think this is another problem with D, version naming is really confusing and
lame. You can't know anything from a D version number.<
Yes, improving such small things is positive. So I suggest to start using a "language.version.releaseStatus" numbering scheme for D2 (and maybe for D2 too). So the current D2 becomes: 2.0.30alpha and the current D1 becomes: 1.0.45 Once D2 gets out of alpha it may become: 2.1.0 Bye, bearophile
I don't think this is sufficient. What we really need is to treat each part of the version as a complex number. In this way, non-stable releases can have imaginary components to distinguish them from release versions. So the current series of D 2.x compilers would become D 2i.x. Release candidates would be D 2i.xi. And of course, a stable release which has unreleased modifications could be D 1.x+yi So much more intuitive than the current system plus a big, red label reading "WARNING: not stable, do not use." -- Daniel
May 16 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, May 16, 2009 at 11:07 PM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:
 I don't think this is sufficient. =A0What we really need is to treat each
 part of the version as a complex number.

 In this way, non-stable releases can have imaginary components to
 distinguish them from release versions.

 So the current series of D 2.x compilers would become D 2i.x. =A0Release
 candidates would be D 2i.xi. =A0And of course, a stable release which has
 unreleased modifications could be D 1.x+yi
Why restrict yourself to a two-dimensional complex plane when we have quaternions and octonions?
May 16 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

As far as I can tell, nobody cared about array ops.<
So that leaves contract inheritance. I find it hard to see how not having it is
a showstopper for using D1. Contracts in D haven't been the big win I thought
they might be at first. They aren't use much at all. There are a lot of other
issues that do make a big difference, and those are the issues that get
attention.<
This is interesting. Some features are a failure because they need to be tried and tested before knowing they are not good, because you can't tell everything from theory. Once you know they aren't good you can remove them. Other features are good, but in practice they aren't much used. Such low usage may come from various sources: - They aren't part of the culture of most D programmers (I am thinking about useful things like typedef, nested functions and closures). This can be partially solved adding the D site tutorial pages about the usefulness & purposes & several usage examples of typedef, nested functions and closures. - They are clumsy to use, maybe because their syntax is long, ugly or not easy to understand. This can be solved with a better design, like asking the community to design the syntax of a feature before implementing it. And before that, asking people what features they want/need more in the first place. We'll have to create another thread of the most wanted things. - They aren't well integrated with other features of the D language, so such features become like islands, so they can't become much useful, and in the D body such feature-transplant has a reject. In a language like Chapel array operations are natural, and in a language like Eiffel contracts are natural, because in both language such features are well integrated with other features of the language. This can be solved adding more bridges from such features to other parts of the language and making the syntax of the new features better merged with the other parts of the language. I have never used array ops yet, but for example I'd like to have array comprehensions (lazy too), they are something I'd use every day in D (Walter is currently focused in adding features that allow to write big programs with D. But it's good to also improve the language to make it fitter for small things too. It's the difference between scaling up and scaling down. Both directions are useful, because big programs are written of small chunks of code. And an array comprehension allows you to write smaller class methods/functions, reducing the overall line count of the program). --------------------- Few more mixed things that I'd like to see done regarding D: - A simpler, cleaner and easier to use site. The current site is a mess. I am able to list where I think it needs to be improved. - Having dmd source code online on Git. - Remove some things that are less useful from D2. - To give more attention to what D programmers want and ask for. From what I have seen the community here is quite smart, so it's often better to implement what many of them ask for, instead of other things few/none ask for. Often smart people are right in asking for faster horses instead of a car. - Having an official D front-end written in D is something good, but now it's too much early, I think. - Reducing the number of D newsgroups, and renaming few of them can be good. Bye, bearophile
May 15 2009