www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - When will D1 be finished?

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
All this D2 work seems to have detracted from the task of finishing off D1.

There are 15 issues nominated as d1.0blocker, of which 7* are still 
outstanding, including two trackers having 39 dependencies between them.

* Well, 8 if you include 691, fixed only for D2.

http://d.puremagic.com/issues/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=substring&value0-0-0=d1.0blocker

While none of these nominations were ever answered, I think most would 
agree that being finished means, at the least:

(a) having a spec that the public agrees to be complete and consistent
(b) all language features implemented
(c) all of the most serious known bugs and most of the others fixed

677 and 690 are shortcomings in department (a). (OK, 690 seems to be 
almost fixed now, but I'm not sure.)  302 is a failure under (b).  While 
it's otherwise hard to lay hands on anything particular as why (c) is 
yet to be achieved, that just over 2/3 of 340's dependencies are still 
open at least says something.

This leaves 317 and 342, which are filed as enhancement requests, but 
which people felt important enough that they ought to be in the initial 
D1 distribution.  342 is straightforward and, while 317 is a much bigger 
task, at least it has progressed (albeit slowly).

But generally, it's about time D1 got a move on....


I'm made to wonder whether, if 1.0 had been held back until it could be 
a practical rather than just symbolic milestone, it would be at both by now.

I've just thought, given this brief inconclusive discussion
http://tinyurl.com/qayz9w
...when we reach this practical milestone, maybe we could call it D 1.1?

Stewart.
May 11 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Stewart Gordon wrote:
 All this D2 work seems to have detracted from the task of finishing off D1.
 
 There are 15 issues nominated as d1.0blocker, of which 7* are still 
 outstanding, including two trackers having 39 dependencies between them.
 
 * Well, 8 if you include 691, fixed only for D2.
 
 http://d.puremagic.com/issues/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=substring&va
ue0-0-0=d1.0blocker 
 
 
 While none of these nominations were ever answered, I think most would 
 agree that being finished means, at the least:
 
 (a) having a spec that the public agrees to be complete and consistent
 (b) all language features implemented
 (c) all of the most serious known bugs and most of the others fixed
 
 677 and 690 are shortcomings in department (a). (OK, 690 seems to be 
 almost fixed now, but I'm not sure.)  302 is a failure under (b).  While 
 it's otherwise hard to lay hands on anything particular as why (c) is 
 yet to be achieved, that just over 2/3 of 340's dependencies are still 
 open at least says something.
 
 This leaves 317 and 342, which are filed as enhancement requests, but 
 which people felt important enough that they ought to be in the initial 
 D1 distribution.  342 is straightforward and, while 317 is a much bigger 
 task, at least it has progressed (albeit slowly).
 
 But generally, it's about time D1 got a move on....
 
 
 I'm made to wonder whether, if 1.0 had been held back until it could be 
 a practical rather than just symbolic milestone, it would be at both by 
 now.
 
 I've just thought, given this brief inconclusive discussion
 http://tinyurl.com/qayz9w
 ...when we reach this practical milestone, maybe we could call it D 1.1?
 
 Stewart.

I think the major problem with this is that D2 has the same codebase as D1, so D2 will inherit most of it's bug, like forward references. Anyone wants to start an open source project to make a new front-end for D1? :)
May 11 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Ary Borenszweig (ary esperanto.org.ar)'s article
 Stewart Gordon wrote:
 All this D2 work seems to have detracted from the task of finishing off D1.

 There are 15 issues nominated as d1.0blocker, of which 7* are still
 outstanding, including two trackers having 39 dependencies between them.

 * Well, 8 if you include 691, fixed only for D2.


 While none of these nominations were ever answered, I think most would
 agree that being finished means, at the least:

 (a) having a spec that the public agrees to be complete and consistent
 (b) all language features implemented
 (c) all of the most serious known bugs and most of the others fixed

 677 and 690 are shortcomings in department (a). (OK, 690 seems to be
 almost fixed now, but I'm not sure.)  302 is a failure under (b).  While
 it's otherwise hard to lay hands on anything particular as why (c) is
 yet to be achieved, that just over 2/3 of 340's dependencies are still
 open at least says something.

 This leaves 317 and 342, which are filed as enhancement requests, but
 which people felt important enough that they ought to be in the initial
 D1 distribution.  342 is straightforward and, while 317 is a much bigger
 task, at least it has progressed (albeit slowly).

 But generally, it's about time D1 got a move on....


 I'm made to wonder whether, if 1.0 had been held back until it could be
 a practical rather than just symbolic milestone, it would be at both by
 now.

 I've just thought, given this brief inconclusive discussion
 http://tinyurl.com/qayz9w
 ...when we reach this practical milestone, maybe we could call it D 1.1?

 Stewart.

D1, so D2 will inherit most of it's bug, like forward references. Anyone wants to start an open source project to make a new front-end for D1? :)

This one is interesting and looks reasonably active:: http://code.google.com/p/dil/ It's a D1 front end written in D, and looks reasonably active. It also solves another problem: Although it's not a particularly urgent thing, eventually D compilers should be written in D. First, it would be one less things for skeptics to complain about. Secondly, I'm not sure if anyone else shares this experience, but I hack Phobos all the time, but don't touch DMD. Part of the reason is that DMD is in C++, which I don't know nearly as well as D and find much less pleasant to work with. If DMD were written in D I'd be more inclined to hack around with it. Of course, the other reason is because, with DMD you have to be familiar with large portions of the codebase to do simple things, whereas in Phobos, you just need to know about the part you want to mess with.
May 11 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
dsimcha wrote:
 == Quote from Ary Borenszweig (ary esperanto.org.ar)'s article
 Stewart Gordon wrote:
 All this D2 work seems to have detracted from the task of finishing off D1.

 There are 15 issues nominated as d1.0blocker, of which 7* are still
 outstanding, including two trackers having 39 dependencies between them.

 * Well, 8 if you include 691, fixed only for D2.


 While none of these nominations were ever answered, I think most would
 agree that being finished means, at the least:

 (a) having a spec that the public agrees to be complete and consistent
 (b) all language features implemented
 (c) all of the most serious known bugs and most of the others fixed

 677 and 690 are shortcomings in department (a). (OK, 690 seems to be
 almost fixed now, but I'm not sure.)  302 is a failure under (b).  While
 it's otherwise hard to lay hands on anything particular as why (c) is
 yet to be achieved, that just over 2/3 of 340's dependencies are still
 open at least says something.

 This leaves 317 and 342, which are filed as enhancement requests, but
 which people felt important enough that they ought to be in the initial
 D1 distribution.  342 is straightforward and, while 317 is a much bigger
 task, at least it has progressed (albeit slowly).

 But generally, it's about time D1 got a move on....


 I'm made to wonder whether, if 1.0 had been held back until it could be
 a practical rather than just symbolic milestone, it would be at both by
 now.

 I've just thought, given this brief inconclusive discussion
 http://tinyurl.com/qayz9w
 ...when we reach this practical milestone, maybe we could call it D 1.1?

 Stewart.

D1, so D2 will inherit most of it's bug, like forward references. Anyone wants to start an open source project to make a new front-end for D1? :)

This one is interesting and looks reasonably active:: http://code.google.com/p/dil/ It's a D1 front end written in D, and looks reasonably active. It also solves another problem: Although it's not a particularly urgent thing, eventually D compilers should be written in D. First, it would be one less things for skeptics to complain about.

Cool! I thought all of the D compilers were using DMD's front-end. I'll take a look at it and try to help.
May 11 2009
parent BLS <windevguy hotmail.de> writes:
Ary Borenszweig wrote:
 dsimcha wrote:
 == Quote from Ary Borenszweig (ary esperanto.org.ar)'s article
 Stewart Gordon wrote:
 All this D2 work seems to have detracted from the task of finishing 
 off D1.

 There are 15 issues nominated as d1.0blocker, of which 7* are still
 outstanding, including two trackers having 39 dependencies between 
 them.

 * Well, 8 if you include 691, fixed only for D2.


 While none of these nominations were ever answered, I think most would
 agree that being finished means, at the least:

 (a) having a spec that the public agrees to be complete and consistent
 (b) all language features implemented
 (c) all of the most serious known bugs and most of the others fixed

 677 and 690 are shortcomings in department (a). (OK, 690 seems to be
 almost fixed now, but I'm not sure.)  302 is a failure under (b).  
 While
 it's otherwise hard to lay hands on anything particular as why (c) is
 yet to be achieved, that just over 2/3 of 340's dependencies are still
 open at least says something.

 This leaves 317 and 342, which are filed as enhancement requests, but
 which people felt important enough that they ought to be in the initial
 D1 distribution.  342 is straightforward and, while 317 is a much 
 bigger
 task, at least it has progressed (albeit slowly).

 But generally, it's about time D1 got a move on....


 I'm made to wonder whether, if 1.0 had been held back until it could be
 a practical rather than just symbolic milestone, it would be at both by
 now.

 I've just thought, given this brief inconclusive discussion
 http://tinyurl.com/qayz9w
 ...when we reach this practical milestone, maybe we could call it D 
 1.1?

 Stewart.

D1, so D2 will inherit most of it's bug, like forward references. Anyone wants to start an open source project to make a new front-end for D1? :)

This one is interesting and looks reasonably active:: http://code.google.com/p/dil/ It's a D1 front end written in D, and looks reasonably active. It also solves another problem: Although it's not a particularly urgent thing, eventually D compilers should be written in D. First, it would be one less things for skeptics to complain about.

Cool! I thought all of the D compilers were using DMD's front-end. I'll take a look at it and try to help.

Just a few notes. 1 - DIL is able to lex and parse (partially) D2 2 - DIL is GPL 3 3 - semantic analysis requires some work 4 - DIL has a couple of very useful extensions, likewise D to XML 5 - compared to the C++ frontend DIL sources are readable and quite easy to extend. (save D to XML library information into Berkeley DB XML/ nice to have IDE feature/, just my opinion) Björn
May 11 2009
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Ary Borenszweig wrote:
<snip excessive quote>
 I think the major problem with this is that D2 has the same codebase as 
 D1, so D2 will inherit most of it's bug, like forward references.

Why's that a problem? AISI it's a benefit - DMD2 inherits DMD1's bug fixes, and to some degree vice versa. Stewart.
May 11 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Stewart Gordon wrote:
 Ary Borenszweig wrote:
 <snip excessive quote>
 I think the major problem with this is that D2 has the same codebase 
 as D1, so D2 will inherit most of it's bug, like forward references.

Why's that a problem? AISI it's a benefit - DMD2 inherits DMD1's bug fixes, and to some degree vice versa. Stewart.

The problem is that some serious bugs never got fixed, so they'll be as well in D2. Of course that's good *if* they get fixed, but...
May 11 2009
prev sibling next sibling parent reply =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques gmail.com> writes:
Stewart Gordon wrote:
 All this D2 work seems to have detracted from the task of finishing off D1.

As someone who as tried to use D in non-hobby projects, I want to add that I reasonably agree with the sentiment. When D1 was declared finished I thought it meant it would progress to a stable state, with nearly all non-minor problems fixed and a large set of companion libraries. I'm afraid I don't see that happening at an animating rate. My feeling is that D1 is being finished at a best-effort rate, with D2 taking much of the time. That leaves D1 as still being a somewhat risky, unpractical proposition for many "real-world" project (and D2 as the admittedly moving-target). This will always be true for a non-mainstream language, but it doesn't have to be to this extent. Good strides have been made with Learn to Tango with D, the Mac and BSD port, etc. But, for me, it would be more important to make sure that what currently exists is production-ready. I guess that's the point. Who currently thinks that D1 is production-ready, or is consistently getting there, and how long till it gets there? Best luck for the trip! Regards, Luís
May 11 2009
next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Luís Marques wrote:

 I guess that's the point. Who currently thinks that D1 is 
 production-ready, or is consistently getting there, and how long till it 
 gets there?

Already *before* D1 I wrote a non-trivial application, that is still used in the industry even as we speak. I wrote it in straight, honest, clean code, and had no problems. It runs two simultaneous tasks, controls industry processing hardware through the parallell port, has a command line language of its own, and it shows parameters of the process on the screen in real time, using graphs and colors. And it writes logs and output files as needed, at the same time. D1 is production ready, IMHO, now. But for such a question, you should define what production-ready means to you. If it means having all GUI programming environments, comprehensive libraries, etc., then even D2 won't get you there. Why? That's because the day D2 is "released", this newsgroup will start developing D3, and from that day on everyone will whine about all attention going to D3. And all kids writing libraries and porting stuff, obviously have to use the lastest version of D, or else their friends will call them wussies.
May 11 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Georg Wrede (georg.wrede iki.fi)'s article
 Luís Marques wrote:
 I guess that's the point. Who currently thinks that D1 is
 production-ready, or is consistently getting there, and how long till it
 gets there?

used in the industry even as we speak. I wrote it in straight, honest, clean code, and had no problems. It runs two simultaneous tasks, controls industry processing hardware through the parallell port, has a command line language of its own, and it shows parameters of the process on the screen in real time, using graphs and colors. And it writes logs and output files as needed, at the same time. D1 is production ready, IMHO, now. But for such a question, you should define what production-ready means to you. If it means having all GUI programming environments, comprehensive libraries, etc., then even D2 won't get you there. Why? That's because the day D2 is "released", this newsgroup will start developing D3, and from that day on everyone will whine about all attention going to D3. And all kids writing libraries and porting stuff, obviously have to use the lastest version of D, or else their friends will call them wussies.

One thing that would help is a roadmap of non-trivial breaking changes for D3 if/when it is started. By non-trivial, I mean breaking changes that require design changes rather than just mechanical things like search/replace. That way, D2 code could be designed with the possibility of eventually porting to D3 in the back of the developer's mind rather than being caught completely off guard.
May 11 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
dsimcha wrote:
 == Quote from Georg Wrede (georg.wrede iki.fi)'s article
 Luís Marques wrote:
 I guess that's the point. Who currently thinks that D1 is
 production-ready, or is consistently getting there, and how long till it
 gets there?

used in the industry even as we speak. I wrote it in straight, honest, clean code, and had no problems. It runs two simultaneous tasks, controls industry processing hardware through the parallell port, has a command line language of its own, and it shows parameters of the process on the screen in real time, using graphs and colors. And it writes logs and output files as needed, at the same time. D1 is production ready, IMHO, now. But for such a question, you should define what production-ready means to you. If it means having all GUI programming environments, comprehensive libraries, etc., then even D2 won't get you there. Why? That's because the day D2 is "released", this newsgroup will start developing D3, and from that day on everyone will whine about all attention going to D3. And all kids writing libraries and porting stuff, obviously have to use the lastest version of D, or else their friends will call them wussies.

One thing that would help is a roadmap of non-trivial breaking changes for D3 if/when it is started. By non-trivial, I mean breaking changes that require design changes rather than just mechanical things like search/replace. That way, D2 code could be designed with the possibility of eventually porting to D3 in the back of the developer's mind rather than being caught completely off guard.

That day, there will not be a single person on Earth who knows such changes. Just like when we started on D2, nobody could have had any notion of how D2 looks today. And we still have an unpredictable amount of changes ahead of us in D2. For example, who can predict if Andrei or somebody else writes a post here that turns half of D2 on its head, and then we postpone everything to get that done. It's happened before, you know.
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:
 That day, there will not be a single person on Earth who knows such 
 changes. Just like when we started on D2, nobody could have had any 
 notion of how D2 looks today. And we still have an unpredictable amount 
 of changes ahead of us in D2. For example, who can predict if Andrei or 
 somebody else writes a post here that turns half of D2 on its head, and 
 then we postpone everything to get that done. It's happened before, you 
 know.

I don't know of any language revision project that wound up where they said they were going at the outset.
May 11 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 11 May 2009 14:43:58 -0700, Walter Bright wrote:

 Georg Wrede wrote:
 That day, there will not be a single person on Earth who knows such 
 changes. Just like when we started on D2, nobody could have had any 
 notion of how D2 looks today. And we still have an unpredictable amount 
 of changes ahead of us in D2. For example, who can predict if Andrei or 
 somebody else writes a post here that turns half of D2 on its head, and 
 then we postpone everything to get that done. It's happened before, you 
 know.

I don't know of any language revision project that wound up where they said they were going at the outset.

LOL, I can attest to that! The road trip that has been the next version of Euphoria has taken a few sudden and unexpected turns, plus a couple of dead-ends. Even now as we are about to release the first beta edition, we are finding that certain aspects might need a total redesign - yuck. Thankfully, releasing a series of alpha editions has enabled the user community to generate great feedback that has guided the road trip (including telling us that we went the wrong way occasionally). D1 is not complete. That has nothing to do with the bugs it still contains. It is not complete because there is documented functionality for which no implementation has yet been attempted. This assumes that the documentation is complete and accurate. The D-Team should be dedicating resources to ensuring that the D1 implementation and D1 documentation are in alignment with each other. By dedicating, I mean that is all that this D1-subteam of the D-Team work on - no D2 work at all. Any D1 fixes that need to be propagated to D2 should be done by the D2-subteam. Priority should be given to getting D1 completed. Getting D1 stable can be a focus once D1 is complete. Unless of course, D1 is just a prototype for D2 and will thus be discarded the instant that D2 is released. What are the support plans for D1 after D2 is released? (I consider current D2 releases as beta editions at best). -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 11 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 D1 is not complete. That has nothing to do with the bugs it still contains.
 It is not complete because there is documented functionality for which no
 implementation has yet been attempted. This assumes that the documentation
 is complete and accurate.
 
 The D-Team should be dedicating resources to ensuring that the D1
 implementation and D1 documentation are in alignment with each other. By
 dedicating, I mean that is all that this D1-subteam of the D-Team work on -
 no D2 work at all. Any D1 fixes that need to be propagated to D2 should be
 done by the D2-subteam. Priority should be given to getting D1 completed.

Please help me understand - why is contract inheritance preventing you from using D1? Exported templates haven't stopped anyone from using C++ compilers from Microsoft/Sun/Intel/etc. I don't think anyone has made a feature complete C99 compiler, either.
 Unless of course, D1 is just a prototype for D2 and will thus be discarded
 the instant that D2 is released.
 
 What are the support plans for D1 after D2 is released? (I consider current
 D2 releases as beta editions at best).

D1 will continue to be supported as long as there is a significant userbase for it. I've said this many times. I also fail to understand this perception that D1 is abandoned. Every month an update is released for it that fixes a load of problems. D1 has led the way in ports to other platforms. What isn't being done with D1 is adding a boatload of new features - because that would destroy any pretense of it being a stable release.
May 11 2009
next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:
 I also fail to understand this perception that D1 is abandoned. Every 
 month an update is released for it that fixes a load of problems. D1 has 
 led the way in ports to other platforms.

Because this news group's name is not D2. Folks come here, and see no mention of D1 for weeks. (Other than people whining about "no support, D1 abandoned", etc.) All they see is (to a D newcomer, anyway) incomprehensible ruminations on esoterics. But they believe this is /the thing/, since nobody warned them that this is (in reality) a future versions newsgroup. From a (go ahead, call it "shrewd" and "marketing liar", I won't mind) perspective, _the_ newsgroup should be called D and it should contain D1 discussions. And then there should be a less conspicuous NG called "future releases discussions", which would be D2. This change looks too trivial to make a difference, but that's exactly why I have to bring it up. (Why do you think M$ pays mega$ for some consultancy to invent a name for the next Windows version? It's the subconscious things in customers' brains they f**k with. And they're doing a good job at it.) Old D guys are too used to the current naming to appreciate the difference.
 What isn't being done with D1 is adding a boatload of new features - 
 because that would destroy any pretense of it being a stable release.

That's as it should be (given our limited resources).
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:
  From a (go ahead, call it "shrewd" and "marketing liar", I won't mind) 
 perspective, _the_ newsgroup should be called D and it should contain D1 
 discussions. And then there should be a less conspicuous NG called 
 "future releases discussions", which would be D2.

Sounds like a good idea.
May 11 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Georg Wrede wrote:
  From a (go ahead, call it "shrewd" and "marketing liar", I won't 
 mind) perspective, _the_ newsgroup should be called D and it should 
 contain D1 discussions. And then there should be a less conspicuous NG 
 called "future releases discussions", which would be D2.

Sounds like a good idea.

I'm all for it. My guess, however, is that this is another case of couch quarterbacking that's unlikely to effect a touchdown. Today, the majority of discussions on digitalmars.d is about D2 because - surprise! - the stuff that people are interested in debating has mostly to do with D2. You can't tell people what they should be talking about. People vote with their pens. If a separate newsgroup is created for digitalmars.d.next, then that won't automatically increase the quantity and quality of D1-related traffic on digitalmars.d. Then the archetypal noob tunes to digitalmars.d, sees a tumbleweed rolling by, and moves on. Andrei
May 11 2009
next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Georg Wrede wrote:
  From a (go ahead, call it "shrewd" and "marketing liar", I won't 
 mind) perspective, _the_ newsgroup should be called D and it should 
 contain D1 discussions. And then there should be a less conspicuous 
 NG called "future releases discussions", which would be D2.

Sounds like a good idea.

I'm all for it. My guess, however, is that this is another case of couch quarterbacking that's unlikely to effect a touchdown. Today, the majority of discussions on digitalmars.d is about D2 because - surprise! - the stuff that people are interested in debating has mostly to do with D2. You can't tell people what they should be talking about. People vote with their pens. If a separate newsgroup is created for digitalmars.d.next, then that won't automatically increase the quantity and quality of D1-related traffic on digitalmars.d. Then the archetypal noob tunes to digitalmars.d, sees a tumbleweed rolling by, and moves on.

We could rename D.learn to D and D to D.future-issues. Then the two newsgroups would be /appropriately seeded/.
May 11 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Georg Wrede, el 12 de mayo a las 06:06 me escribiste:
 Andrei Alexandrescu wrote:
Walter Bright wrote:
Georg Wrede wrote:
 From a (go ahead, call it "shrewd" and "marketing liar", I won't mind) 
perspective, _the_ newsgroup should be called D and it should contain D1 
discussions. And then there should be a less conspicuous NG called "future 
releases discussions", which would be D2.

Sounds like a good idea.

quarterbacking that's unlikely to effect a touchdown. Today, the majority of discussions on digitalmars.d is about D2 because - surprise! - the stuff that people are interested in debating has mostly to do with D2. You can't tell people what they should be talking about. People vote with their pens. If a separate newsgroup is created for digitalmars.d.next, then that won't automatically increase the quantity and quality of D1-related traffic on digitalmars.d. Then the archetypal noob tunes to digitalmars.d, sees a tumbleweed rolling by, and moves on.

We could rename D.learn to D and D to D.future-issues. Then the two newsgroups would be /appropriately seeded/.

Other (mostly open source) projects tend to use -users and -devel. I guess d-users and d-devel could be used in this case too. -- 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 Georg Wrede <georg.wrede iki.fi> writes:
Leandro Lucarella wrote:
 Georg Wrede, el 12 de mayo a las 06:06 me escribiste:
 Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Georg Wrede wrote:
 From a (go ahead, call it "shrewd" and "marketing liar", I won't mind) 
 perspective, _the_ newsgroup should be called D and it should contain D1 
 discussions. And then there should be a less conspicuous NG called "future 
 releases discussions", which would be D2.


quarterbacking that's unlikely to effect a touchdown. Today, the majority of discussions on digitalmars.d is about D2 because - surprise! - the stuff that people are interested in debating has mostly to do with D2. You can't tell people what they should be talking about. People vote with their pens. If a separate newsgroup is created for digitalmars.d.next, then that won't automatically increase the quantity and quality of D1-related traffic on digitalmars.d. Then the archetypal noob tunes to digitalmars.d, sees a tumbleweed rolling by, and moves on.

Then the two newsgroups would be /appropriately seeded/.

Other (mostly open source) projects tend to use -users and -devel. I guess d-users and d-devel could be used in this case too.

Yes.
May 12 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 11 de mayo a las 17:27 me escribiste:
 Walter Bright wrote:
Georg Wrede wrote:
 From a (go ahead, call it "shrewd" and "marketing liar", I won't mind) 
perspective, _the_ newsgroup should be called D and it should contain D1 
discussions. And then there should be a less conspicuous NG called "future 
releases discussions", which would be D2.


I'm all for it. My guess, however, is that this is another case of couch quarterbacking that's unlikely to effect a touchdown. Today, the majority of discussions on digitalmars.d is about D2 because - surprise! - the stuff that people are interested in debating has mostly to do with D2. You can't tell

This is because D1 is frozen. If there would be a D1.1, D1.2, etc. series, my guess is people would be interested in debating about it. But there is not much to debate about D1 right now, unfortunately.
 people what they should be talking about. People vote with their pens. If a 
 separate newsgroup is created for digitalmars.d.next, then that won't 
 automatically increase the quantity and quality of D1-related traffic on 
 digitalmars.d. Then the archetypal noob tunes to digitalmars.d, sees a 
 tumbleweed rolling by, and moves on.

A D1 NG will be a bug-reporting NG by definition because right now D1 is not allowed to evolve. But I think it could be of help for people to better understand that D2 is in development. Adding a more visible indication that D2 is in development in the website would be helpful too (right now the only place I see something about it is in the download page, where it says D2 is alpha, but I you go to the homepage and jump into the documentation, you never get a hint that D2 is experimental). -- 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
prev sibling next sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 Derek Parnell wrote:
 D1 is not complete. That has nothing to do with the bugs it still 
 contains.
 It is not complete because there is documented functionality for which no
 implementation has yet been attempted. This assumes that the 
 documentation
 is complete and accurate.

 The D-Team should be dedicating resources to ensuring that the D1
 implementation and D1 documentation are in alignment with each other. By
 dedicating, I mean that is all that this D1-subteam of the D-Team work 
 on -
 no D2 work at all. Any D1 fixes that need to be propagated to D2 
 should be
 done by the D2-subteam. Priority should be given to getting D1 completed.

Please help me understand - why is contract inheritance preventing you from using D1? Exported templates haven't stopped anyone from using C++ compilers from Microsoft/Sun/Intel/etc. I don't think anyone has made a feature complete C99 compiler, either.

That's mainly because the language was designed by a committee, and not by a compiler author and his followers, isn't it? But you have full control about the language specification. If there are D1 features you're not going to implement, they simply should be removed from the language specification.
 Unless of course, D1 is just a prototype for D2 and will thus be 
 discarded
 the instant that D2 is released.

 What are the support plans for D1 after D2 is released? (I consider 
 current
 D2 releases as beta editions at best).

D1 will continue to be supported as long as there is a significant userbase for it. I've said this many times. I also fail to understand this perception that D1 is abandoned. Every month an update is released for it that fixes a load of problems. D1 has led the way in ports to other platforms. What isn't being done with D1 is adding a boatload of new features - because that would destroy any pretense of it being a stable release.

That's because we don't really know what we want. You gave us D1, but it turns out it's not really what we expected it to be. On one side, D1 users want a stable language. That means they don't want to update their code with each compiler release. I think D1 reached this goal. Or, at least it's getting better. On the other hand, we don't want to rely on a dead end. We don't want to put up with some trivial issues, that were solved in D2, but will stay in D1 forever. For example, D1 will never be able to support proper serialization, just because it lacks __traits(). That specific thing would (probably) be easy to port back to D1, and it wouldn't break any existing code. I know, you're saying introducing new features goes against stability. But it makes D1 frustrating to use. Everyone feels it's a dead end, and that you shouldn't rely on it. In the end, it might be rock-stable, but nobody wants to use it. Because it will still have some problems, which were solved in D2. D1 will simply vanish in some time. Now you could say, "If you want new features, use D2. If you want something stable, use D1. But the gap is simply too big: do you stick with the dead end D1, or with the heavily changing D2? The worst thing is, you can't really interface between D1 and D2. So you can't use it, if you're using the wrong D version. Or the library tries to work under both D versions, which makes maintenance harder and bloats up the code. This just causes endless pain. I propose the following: Make D1 open for new features again. As soon as backward compatible features get mature and stable enough in D2, add them to D1 too. To prevent regressions, use the test suite. A new version of the compiler will only be released, if the test suite doesn't report any new regressions. D2 will be bleeding edge. It will not need to care about _any_ breakages new versions might introduce. Right now, this isn't really possible, because there are people using D2 for "useful" stuff (instead of using D1). With the change, D2 would be a truly experimental testbed, and not the pseudo-stable "next generation D" it is today. From time to time, allow breaking changes to D1. It isn't really worth to maintain ancient versions of the compiler, like D1 will be if D3 is out. If someone doesn't want to deal with the breakages, he has to use an old compiler version. A steady transition in small increments is probably still better than requiring a user to do a D1 -> D2 sized switch all some years. While the former may require annoying but trivial fixes to the source code, the latter will always be a nightmare. But I don't really know what to do with breaking changes, that are just too big. Like const or the new threading model. Everyone, you just wasted your time reading this posting.
May 11 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
  Everyone, you just 
 wasted your time reading this posting.

Bestimmt. Andrei
May 11 2009
parent grauzone <none example.net> writes:
Andrei Alexandrescu wrote:
 grauzone wrote:
  Everyone, you just wasted your time reading this posting.

Bestimmt.

Reading and posting on the group is a great waste of time in general, so I hope it doesn't bother you too much.
 Andrei

May 11 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
grauzone, el 12 de mayo a las 02:24 me escribiste:
The D-Team should be dedicating resources to ensuring that the D1
implementation and D1 documentation are in alignment with each other. By
dedicating, I mean that is all that this D1-subteam of the D-Team work on -
no D2 work at all. Any D1 fixes that need to be propagated to D2 should be
done by the D2-subteam. Priority should be given to getting D1 completed.

using D1? Exported templates haven't stopped anyone from using C++ compilers from Microsoft/Sun/Intel/etc. I don't think anyone has made a feature complete C99 compiler, either.

That's mainly because the language was designed by a committee, and not by a compiler author and his followers, isn't it? But you have full control about the language specification. If there are D1 features you're not going to implement, they simply should be removed from the language specification.
Unless of course, D1 is just a prototype for D2 and will thus be discarded
the instant that D2 is released.

What are the support plans for D1 after D2 is released? (I consider
current D2 releases as beta editions at best).

userbase for it. I've said this many times. I also fail to understand this perception that D1 is abandoned. Every month an update is released for it that fixes a load of problems. D1 has led the way in ports to other platforms. What isn't being done with D1 is adding a boatload of new features - because that would destroy any pretense of it being a stable release.

That's because we don't really know what we want. You gave us D1, but it turns out it's not really what we expected it to be. On one side, D1 users want a stable language. That means they don't want to update their code with each compiler release. I think D1 reached this goal. Or, at least it's getting better. On the other hand, we don't want to rely on a dead end. We don't want to put up with some trivial issues, that were solved in D2, but will stay in D1 forever. For example, D1 will never be able to support proper serialization, just because it lacks __traits(). That specific thing would (probably) be easy to port back to D1, and it wouldn't break any existing code. I know, you're saying introducing new features goes against stability. But it makes D1 frustrating to use. Everyone feels it's a dead end, and that you shouldn't rely on it. In the end, it might be rock-stable, but nobody wants to use it. Because it will still have some problems, which were solved in D2. D1 will simply vanish in some time. Now you could say, "If you want new features, use D2. If you want something stable, use D1. But the gap is simply too big: do you stick with the dead end D1, or with the heavily changing D2? The worst thing is, you can't really interface between D1 and D2. So you can't use it, if you're using the wrong D version. Or the library tries to work under both D versions, which makes maintenance harder and bloats up the code. This just causes endless pain.

This is exactly my feeling.
 I propose the following:
 
 Make D1 open for new features again. As soon as backward compatible
 features get mature and stable enough in D2, add them to D1 too. To
 prevent regressions, use the test suite. A new version of the compiler
 will only be released, if the test suite doesn't report any new
 regressions.

My suggestion is to accumulate some new features in a new "minor" D1 version, like D1.1, release some betas, and release a D1.1 stable. D1.1 should no receive new features by then, but D1.2 should be started receiving new features. Python works this way, and is a very stable *AND* evolving language. Something that apparently Andrei and Walter think it's not possible to have.
 D2 will be bleeding edge. It will not need to care about _any_ breakages
 new versions might introduce. Right now, this isn't really possible,
 because there are people using D2 for "useful" stuff (instead of using
 D1). With the change, D2 would be a truly experimental testbed, and not
 the pseudo-stable "next generation D" it is today.
 
 From time to time, allow breaking changes to D1. It isn't really worth
 to maintain ancient versions of the compiler, like D1 will be if D3 is
 out. If someone doesn't want to deal with the breakages, he has to use
 an old compiler version. A steady transition in small increments is
 probably still better than requiring a user to do a D1 -> D2 sized
 switch all some years. While the former may require annoying but trivial
 fixes to the source code, the latter will always be a nightmare.

That's exactly what I've suggested some time ago, I even started a Wiki page for this with a proposed roadmap: http://www.prowiki.org/wiki4d/wiki.cgi?D1XProposal
 But I don't really know what to do with breaking changes, that are just
 too big.  Like const or the new threading model.

I think that should be kept as D2. Because programs needs a major rewrite to be ported to D2, not just some cosmetic name changes (caused by a class rename or a new keyword that you used as a variable name).
 Everyone, you just wasted your time reading this posting.

Not the first time, not the last time... =) -- 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
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 11 May 2009 16:25:24 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 D1 is not complete. That has nothing to do with the bugs it still contains.
 It is not complete because there is documented functionality for which no
 implementation has yet been attempted. This assumes that the documentation
 is complete and accurate.
 
 The D-Team should be dedicating resources to ensuring that the D1
 implementation and D1 documentation are in alignment with each other. By
 dedicating, I mean that is all that this D1-subteam of the D-Team work on -
 no D2 work at all. Any D1 fixes that need to be propagated to D2 should be
 done by the D2-subteam. Priority should be given to getting D1 completed.

Please help me understand - why is contract inheritance preventing you from using D1? Exported templates haven't stopped anyone from using C++ compilers from Microsoft/Sun/Intel/etc. I don't think anyone has made a feature complete C99 compiler, either.

Contract inheritance is NOT preventing me use D1. I have never, not once, said that it has. Is Contract Inheritance documented as being a part of D1's functionality? If yes, then is it implemented? If yes, then well done. If no, then is the documentation wrong or is DMD v1 incomplete? If Contract Inheritance is not documented as being a part of D1's functionality then why are we talking about it? I do NOT automatically associate completeness with worthiness. D1 is stable enough to use for production applications. I have never, not once, said otherwise. My thinking re completeness is just this ... Docs say X is a function point of D1. DMD v1 does not implement X. Therefore, DMD v1 is not a complete implementation of D1. That has NOTHING WHATSOEVER to do with deciding to use DMD v1 for important applications. It is an observation, not a criticism or a complaint. If was to complain, and I'm not, I might mention that sometimes the impression I get is that the D-team feels that DMD v1 is as complete as its ever going to be but won't admit it. If DMD v1 is intending to ever be a complete implementation of D1, then IMO there needs to be a concerted effort to reach a completed stage in DMD v1, independently of any work happening in the D2 arena. If this is not the intention, IMO, it ought to be stated clearly in the DMD v1 documentation that DMD v1 is not the definitive D1 implementation. That would slow down the rate of people complaining about it being incomplete.
 Unless of course, D1 is just a prototype for D2 and will thus be discarded
 the instant that D2 is released.
 
 What are the support plans for D1 after D2 is released? (I consider current
 D2 releases as beta editions at best).

D1 will continue to be supported as long as there is a significant userbase for it. I've said this many times.

Times change. People change. Policies change. Readers of this newsgroup change. I just wanted confirmation of what the current policy was. Is this policy recorded in the DMD v1 documentation? I couldn't find it.
 I also fail to understand this perception that D1 is abandoned. Every 
 month an update is released for it that fixes a load of problems. D1 has 
 led the way in ports to other platforms.

I have never said, not once, that D1 *is* abandoned. Stability and completeness are not the same thing, as you well know. In fact, I'm amazed at the amount of repairs that you are able to achieve, given the small resource pool that is available. All kudos to your good selves. What I have said was that D1 /might/ be abandoned in the future, if and only if, D1 is to be considered as merely a prototype for D2. However, from your recent comments I'm now convinced that you do not see D1 as merely a prototype. D2 is evolving from D1. D2 will be so significantly different from D1 as to almost class it as a different language. I'm sure that a lot of D1 code will not compile under D2, or if it does will have changed semantics. But that is not an issue for me either; just an observation and not a complaint.
 What isn't being done with D1 is adding a boatload of new features - 
 because that would destroy any pretense of it being a stable release.

Of course. Totally justifiable too. I am not asking for anything 'new' to be added to D1. But I do see that D1 and DMD v1 are not the same thing (yet). Ok, so what is stopping me using D1? Below are some off-the-cuff ideas and it may be that I'm mistaken in my beliefs, so take that into consideration. * I like what D2 has to offer, so I'll wait for that. I'm not in a hurry to use D as there is no current or approaching project that requires it. * Phobos has missing functionality, which means I have needed to write that code myself. (Adding the functionality to D1 Phobos is not an option because D1 is 'closed' for additions.) * Tango is too 'weird' for me to use. I'm not keen about the Everything-Is-An-Object style of coding. A personal preference, to be sure. * Tango means I need to do a special installation of DMD plus it assumes an older version of DMD. * I'm too busy to invest in something that I will need to rework for D2. I really like D. I want to use it. But ... oh well, maybe I should just 'bite the bullet' and begin my next D project using D1 anyway. I can only learn from the experience, right? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 11 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 Ok, so what is stopping me using D1? Below are some off-the-cuff ideas and
 it may be that I'm mistaken in my beliefs, so take that into consideration.
 
 * I like what D2 has to offer, so I'll wait for that. I'm not in a hurry to
 use D as there is no current or approaching project that requires it.

There's always going to be "Coming Soon To A Compiler Near You!" with D. It's been undergoing improvement for 7 years now.
 * Phobos has missing functionality, which means I have needed to write that
 code myself. (Adding the functionality to D1 Phobos is not an option
 because D1 is 'closed' for additions.)

There are a lot of add-on libraries. There's no reason anyone cannot write one to fit various needs.
 * Tango is too 'weird' for me to use. I'm not keen about the
 Everything-Is-An-Object style of coding. A personal preference, to be sure.
 
 * Tango means I need to do a special installation of DMD plus it assumes an
 older version of DMD.
 
 * I'm too busy to invest in something that I will need to rework for D2.

While (without using a text preprocessor) you can't make the source code work for both D1 and D2, the amount of rework necessary is quite minor.
 I really like D. I want to use it. But ... oh well, maybe I should just
 'bite the bullet' and begin my next D project using D1 anyway. I can only
 learn from the experience, right?

Reading about and using a language are entirely different things <g>.
May 11 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 The D-Team should be dedicating resources to ensuring that the D1 
 implementation and D1 documentation are in alignment with each other.
  By dedicating, I mean that is all that this D1-subteam of the D-Team
  work on - no D2 work at all. Any D1 fixes that need to be propagated
 to D2 should be done by the D2-subteam. Priority should be given to
 getting D1 completed.

Well thank you General :o). Derek, I have all respect for you and your contributions to D. The response below does not have the slightest intent to pick on you but to rein in an unhelpful pattern in this group. I invite you to see the paragraph quoted above through a different pair of eyes - the eyes of someone with a different vision of what should be done for D, and also (most importantly) who believes in it strongly enough to invest their own non-existing free time in effecting that vision. I confess that this couch quarterbacking is mightily frustrating for both Walter and myself. All the pieces are there for anyone with a vision to make it happen. I understand you wanted to share your opinion on what would be best for the future of D, and that's laudable in and by itself, but such opinions have lately become a choir of whines fulfilling a "if I want something from D, and I expect Walter to do it" pattern. We need the exact opposite - if you care, what can *you* do to make D better? D needs action and leadership. And why is D1 not finished? Most "finished" languages have implementation insufficiencies. I've read a couple of days ago that D1 is unfinished (and unusable by implication) because contracts aren't inherited. If I were Walter, that would be the exact kind of claim that causes high blood pressure. This is ridiculous! Is *that* the feature that the building of a system hinges on? Is that really what's stopping you? Then go back and use contracts in C++, Java, or C#. My guess is, if anyone is whining that D1 is unusable because it doesn't have contract inheritance, tomorrow (should contract inheritance be fixed) they'll whine that it doesn't have named arguments, template virtuals, or a gorram cherry on top. Sheesh. And finally - now that I got on to ranting - I won't out the innocent, but I find it tragicomic that one poster found out fit to rant at length about the need for stability, to then - within the space of 48 hours - to post requests for borderline uninteresting but mightily breaking changes to D1. I guess I'm done with my Spring rant :o). Andrei
May 11 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 11 May 2009 18:28:22 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 The D-Team should be dedicating resources to ensuring that the D1 
 implementation and D1 documentation are in alignment with each other.
  By dedicating, I mean that is all that this D1-subteam of the D-Team
  work on - no D2 work at all. Any D1 fixes that need to be propagated
 to D2 should be done by the D2-subteam. Priority should be given to
 getting D1 completed.

Well thank you General :o).

In spite of the smiley, I'm still feel that your "General" comment is out-of-line and not fair. If one cannot give opinions here then why do we bother.
 Derek, I have all respect for you and your contributions to D. The
 response below does not have the slightest intent to pick on you but to
 rein in an unhelpful pattern in this group.

Thank you and I understand.
 I invite you to see the paragraph quoted above through a different pair 
 of eyes - the eyes of someone with a different vision of what should be 
 done for D, and also (most importantly) who believes in it strongly 
 enough to invest their own non-existing free time  in effecting that 
 vision.

(btw, what exactly is that vision, and why do you think that it is different from mine?)
 I confess that this couch quarterbacking is mightily frustrating for 
 both Walter and myself. All the pieces are there for anyone with a 
 vision to make it happen. I understand you wanted to share your opinion 
 on what would be best for the future of D, and that's laudable in and by 
 itself, but such opinions have lately become a choir of whines 
 fulfilling a "if I want something from D, and I expect Walter to do it" 
 pattern. We need the exact opposite - if you care, what can *you* do to 
 make D better? D needs action and leadership.

I can only speak for myself here but I am not expecting Walter to do it all. In fact, I expect Walter to delegate tasks to others, but I get the feeling that is not the norm. I cannot influence in any practical manner what happens to D1. I cannot code in C++ (effectively) so I'm unable to contribute to fixing bugs. I cannot add to Phobos as 'additions' are closed. I could improve the unit tests and documentation, but ... well, I might be a little behind the times, for the mechanisms for contributing code changes to Phobos and the documentation have been, for me, counter-productive. It is not a simple process and there is no feeling that my efforts will even make a difference. Your phrase "All the pieces are there" needs to be fleshed out, I think. Are you referring to the process that enables one to submit work for consideration into D? If so, what exactly is that process - Bugzilla is fine for issues and bugs, but is that also the method that we need to use for documentation updates and unit tests?
 And why is D1 not finished? Most "finished" languages have 
 implementation insufficiencies. I've read a couple of days ago that D1 
 is unfinished (and unusable by implication) because contracts aren't 
 inherited. If I were Walter, that would be the exact kind of claim that 
 causes high blood pressure. This is ridiculous! Is *that* the feature 
 that the building of a system hinges on? Is that really what's stopping 
 you? Then go back and use contracts in C++, Java, or C#. My guess is, if 
 anyone is whining that D1 is unusable because it doesn't have contract 
 inheritance, tomorrow (should contract inheritance be fixed) they'll 
 whine that it doesn't have named arguments, template virtuals, or a 
 gorram cherry on top. Sheesh.

I realize your remarks above were not specifically directed towards myself, however I feel the need to respond. I am not saying that D1 is not finished, but I am saying that DMD-v1 is not finished. D1 documentation says X is a function of D1. DMD-v1 does not implement X. Therefore DMD-v1 is not a complete implementation of D1. Even though D1 is finished, DMD-v1 might not be finished. Either the documentation is wrong or DMD-v1 is not complete yet. I do not automatically associate incompleteness with unusable. They are not the same thing. There exists complete things that are unusable and incomplete things that are usable. I believe that D1 is very suitable for production applications today. DMD-v1 has a level of stability and completeness that enables it to be used for important works right now. I choose not to use D1 for totally different reasons that have nothing to do with functionality or defect rates. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 11 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Derek Parnell wrote:
 I am not saying that D1 is not finished, but I am saying that DMD-v1 is not
 finished.
 
    D1 documentation says X is a function of D1.
    DMD-v1 does not implement X.
    Therefore DMD-v1 is not a complete implementation of D1.
 
 Even though D1 is finished, DMD-v1 might not be finished.
 
 Either the documentation is wrong or DMD-v1 is not complete yet. 

So, make a list of the things mentioned in the docs that aren't in DMD, and I bet Walter and Andrei will take a hard look at your list, and probably remove most of those things from the docs. That's definitely a contribution that everyone would value and welcome.
May 11 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Georg Wrede wrote:
 Derek Parnell wrote:
 I am not saying that D1 is not finished, but I am saying that DMD-v1 
 is not
 finished.

    D1 documentation says X is a function of D1.
    DMD-v1 does not implement X.
    Therefore DMD-v1 is not a complete implementation of D1.

 Even though D1 is finished, DMD-v1 might not be finished.

 Either the documentation is wrong or DMD-v1 is not complete yet. 

So, make a list of the things mentioned in the docs that aren't in DMD, and I bet Walter and Andrei will take a hard look at your list, and probably remove most of those things from the docs. That's definitely a contribution that everyone would value and welcome.

Or start pushing patches.
May 12 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Luís Marques wrote:
 When D1 was declared finished I thought it meant it would progress to a 
 stable state, with nearly all non-minor problems fixed and a large set 
 of companion libraries. I'm afraid I don't see that happening at an 
 animating rate.

D1 regularly gets around 20 bug fixes a month. I don't understand why this is not seen as progress to a stable state. About 80% of bug fixes are common to both D2 and D1.
May 11 2009
next sibling parent reply =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques gmail.com> writes:
Walter Bright wrote:
 D1 regularly gets around 20 bug fixes a month. I don't understand why 
 this is not seen as progress to a stable state. About 80% of bug fixes 
 are common to both D2 and D1.

I think my perception (and I accept it may be a perception which does not reflect reality at large) comes from issues like the following. It's not a particularly important issue, but it's one for which I could find a bug report. Two years ago, I tried to use a particular construct and DMD incorrectly detected that a statement was not reachable [1]. OK, D1 had been frozen earlier that year, so I thought it would be only a matter of time until the higher priority stuff had been taken care of and someone took care of this issue. That's my experience with stable languages, even if they aren't particularly mainstream (say, Lua). Two years later I see this issue is still lingering. My perception is that unless I nag someone or send a fix myself no one will take care of it anytime soon. I guess they just have a huge pile of more important stuff, which is fair. But, 1) how long do you perceive it will take until more pressing matters delay fixing these kinds of bugs? I don't know if 20 bug fixes a month is enough or not to have DMD v1 rock solid in the next 5 years. Are most of the fixes for new bug reports? Is the list of old bugs being cleaned at a good rate? My perception, I said, was that the rate was a bit disapointing (compared with my experience using other language implementations) 2) Even if most bug fixes are common to D1 and D2, isn't it still true that if D2 is being discussed, elaborated, documented and implemented, most of those activities do not fix bugs and take time away from making D1 / DMD v1 stable and with few bugs? Some say "send a patch". I'll try, when that is possible. But I can't send a patch for every bug I find in my spreadsheet software, browser, programming language, IM client, etc. That means that much of the software I use I have to accept it as is. That applies to everyone which uses a large amount of software and is not a programming demigod.
May 12 2009
next sibling parent reply =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques gmail.com> writes:
Luís Marques wrote:
 Two years ago, I tried to use a particular construct and DMD incorrectly 
 detected that a statement was not reachable [1]. OK, D1 had been frozen 
 earlier that year, so I thought it would be only a matter of time until 
 the higher priority stuff had been taken care of and someone took care 
 of this issue. That's my experience with stable languages, even if they 
 aren't particularly mainstream (say, Lua).

I forgot the reference (even if, as I said, the bug itself is not very important): [1] http://d.puremagic.com/issues/show_bug.cgi?id=1115 (I later read a previous thread that talked about the compiler being brittle when it comes to the order of defining thing. I guess that might explain an even older bug I had posted? http://d.puremagic.com/issues/show_bug.cgi?id=792 )
May 12 2009
next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Luís Marques wrote:
 (I later read a previous thread that talked about the compiler being 
 brittle when it comes to the order of defining thing. I guess that might 
 explain an even older bug I had posted? 
 http://d.puremagic.com/issues/show_bug.cgi?id=792 )

This one seems OK with dmd 1.042.
May 12 2009
parent =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques gmail.com> writes:
Georg Wrede wrote:
 This one seems OK with dmd 1.042.

OK, thanks. I marked it as fixed. I didn't even remember about this bug anymore.
May 12 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Luís Marques wrote:
 Luís Marques wrote:
 Two years ago, I tried to use a particular construct and DMD 
 incorrectly detected that a statement was not reachable [1]. OK, D1 
 had been frozen earlier that year, so I thought it would be only a 
 matter of time until the higher priority stuff had been taken care of 
 and someone took care of this issue. That's my experience with stable 
 languages, even if they aren't particularly mainstream (say, Lua).

I forgot the reference (even if, as I said, the bug itself is not very important): [1] http://d.puremagic.com/issues/show_bug.cgi?id=1115

I wonder, if giving a higher priority to very old bugs would be a good idea?
May 12 2009
parent =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques gmail.com> writes:
Georg Wrede wrote:
 I wonder, if giving a higher priority to very old bugs would be a good 
 idea?

I find it a good idead having the house clean before receiving new guests :-) Tell me, as I don't follow the development close enough, are the priorities in the bugs actually being followed, in general? I see some people complaining about major bugs not receiving atention for a long time...
May 12 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Luís Marques wrote:
 Two years ago, I tried to use a particular construct and DMD incorrectly 
 detected that a statement was not reachable [1]. OK, D1 had been frozen 
 earlier that year, so I thought it would be only a matter of time until 
 the higher priority stuff had been taken care of and someone took care 
 of this issue. That's my experience with stable languages, even if they 
 aren't particularly mainstream (say, Lua).

That would be true if the bug list for D1 was shrinking. But it is not, it is growing. A bug's age does not indicate its importance to be fixed. (The growing number of bugs reflects the increasing usage of D, not that it is going unstable. The number of regressions is very small.)
May 12 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
 Luís Marques wrote:
 Two years ago, I tried to use a particular construct and DMD 
 incorrectly detected that a statement was not reachable [1]. OK, D1 
 had been frozen earlier that year, so I thought it would be only a 
 matter of time until the higher priority stuff had been taken care of 
 and someone took care of this issue. That's my experience with stable 
 languages, even if they aren't particularly mainstream (say, Lua).

That would be true if the bug list for D1 was shrinking. But it is not, it is growing. A bug's age does not indicate its importance to be fixed. (The growing number of bugs reflects the increasing usage of D, not that it is going unstable. The number of regressions is very small.)

The number of releases for which a bug went unreported is indicative of how seldom it is encountered. However, if a patch exists, there is only one excuse for not including it: lack of testing. And there is one huge reason that nobody submits additional test cases to your DMD test suite -- you've never released it, or even specified the required format.
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Christopher Wright wrote:
 However, if a patch exists, there is only one excuse for not including 
 it: lack of testing.

 And there is one huge reason that nobody submits 
 additional test cases to your DMD test suite -- you've never released 
 it, or even specified the required format.

That's because of its uncertain copyright status. It's a collection of everything that went wrong in the past, from a wide variety of sources. As to its format, it is designed to be run by a shell script. Each source file is expected to compile and run without error, error means terminating with an exception or a non-zero return from main(). In other words, the test suite is designed to not require manual inspection of results, and it halts on the first failure. A typical test case would look like: /***************************************************/ template A() { static T foo(T)(T t) { return 7 + t; } } struct Bar { mixin A!() a; } void test2() { auto i = A!().foo(1); assert(i == 8); i = Bar.a.foo!(int)(2); assert(i == 9); i = Bar.a.foo(3); assert(i == 10); } /*****************************************************/ along with a main() that calls the testNN() functions. The shell script I run is with a custom shell language http://www.digitalmars.com/ctg/shell.html The custom nature of it is its ability to keep rerunning a group of commands with different combinations of arguments. This is pretty handy for testing with the combinatorial explosion of compiler switches.
May 12 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
 Christopher Wright wrote:
 However, if a patch exists, there is only one excuse for not including 
 it: lack of testing.

 And there is one huge reason that nobody submits additional test cases 
 to your DMD test suite -- you've never released it, or even specified 
 the required format.

That's because of its uncertain copyright status. It's a collection of everything that went wrong in the past, from a wide variety of sources.

Understood.
 As to its format, it is designed to be run by a shell script. Each 
 source file is expected to compile and run without error, error means 
 terminating with an exception or a non-zero return from main().

Awesome! I'll add this to wiki4d. Might I also suggest adding it to some reasonable location on digitalmars.com and bugzilla? What do you do about examples that should explicitly not compile? For example, a test for the fix to an accepts-invalid bug? Do you have to use tricks with __traits(compiles) and static assert (!is (typeof))?
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Christopher Wright wrote:
 Awesome! I'll add this to wiki4d. Might I also suggest adding it to some 
 reasonable location on digitalmars.com and bugzilla?

I think the wiki is the best place.
 What do you do about examples that should explicitly not compile? For 
 example, a test for the fix to an accepts-invalid bug? Do you have to 
 use tricks with __traits(compiles) and static assert (!is (typeof))?

I'd eventually like to go that route, but currently it is a long list of files that are compiled one by one and tested to see if the compilation return a non-zero exit status.
May 12 2009
next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 12 May 2009 13:57:09 -0700, Walter Bright wrote:

 Christopher Wright wrote:
 Awesome! I'll add this to wiki4d. Might I also suggest adding it to some 
 reasonable location on digitalmars.com and bugzilla?

I think the wiki is the best place.

But the wiki is not authoritative, only your web site is with respect to D matters. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 12 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
 Christopher Wright wrote:
 Awesome! I'll add this to wiki4d. Might I also suggest adding it to 
 some reasonable location on digitalmars.com and bugzilla?

I think the wiki is the best place.
 What do you do about examples that should explicitly not compile? For 
 example, a test for the fix to an accepts-invalid bug? Do you have to 
 use tricks with __traits(compiles) and static assert (!is (typeof))?

I'd eventually like to go that route, but currently it is a long list of files that are compiled one by one and tested to see if the compilation return a non-zero exit status.

Okay, so you have two classes of test cases: those which should compile, run, and exit(0); and those which should not compile.
May 12 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:
 Christopher Wright wrote:
 Awesome! I'll add this to wiki4d. Might I also suggest adding it to 
 some reasonable location on digitalmars.com and bugzilla?

I think the wiki is the best place.
 What do you do about examples that should explicitly not compile? For 
 example, a test for the fix to an accepts-invalid bug? Do you have to 
 use tricks with __traits(compiles) and static assert (!is (typeof))?

I'd eventually like to go that route, but currently it is a long list of files that are compiled one by one and tested to see if the compilation return a non-zero exit status.

Now that you're more used to *nix, would it be productive to have all of the test harness on *nix? It would make it immensely easier to, say, have it made so that both "do not compile" and the opposite, merge smoothly in the whole.
May 12 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 I know.  How many months has bug 314* had the most votes?  And 313
 while we're at it.  Importing has been broken for years and instead D2
 is getting thread-local variables.  It seems like a gross misdirection
 of effort.

314 does not affect correct code, hence is an implicitly less important issue. The order of importance of bugs is roughly: 1. silently generating bad code 2. compiler crashes 3. regressions that break previously working code 4. not accepting valid code 5. accepting invalid code 6. poor error messages Throw into that how much work a bug is to fix, how many projects it affects, if there's a patch submitted, etc.
May 12 2009
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
Walter Bright wrote:
 314 does not affect correct code, hence is an implicitly less important 
 issue.

It does however include a patch, submitted almost a year ago I might add. With it having the most votes, applying the patch could give a lot of smiley faces :)
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Clipsham wrote:
 Walter Bright wrote:
 314 does not affect correct code, hence is an implicitly less 
 important issue.

It does however include a patch, submitted almost a year ago I might add.

Yes, but the patch is incomplete.
May 12 2009
next sibling parent Christian Kamm <kamm-incasoftware removethis.de> writes:
Walter Bright wrote:
 Robert Clipsham wrote:
 Walter Bright wrote:
 314 does not affect correct code, hence is an implicitly less
 important issue.

It does however include a patch, submitted almost a year ago I might add.

Yes, but the patch is incomplete.

I didn't know that was the reason for it not being applied! I'll dig out the changeset that folded it into LDC.
May 12 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 You can't honestly expect people to submit patches if you're not going
 to give feedback as to why you won't include them!

Quite a lot of the submitted patches have been incorporated. The patch report itself says it's incomplete.
May 12 2009
parent Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Jarrett Billingsley wrote:
 You can't honestly expect people to submit patches if you're not going
 to give feedback as to why you won't include them!

Quite a lot of the submitted patches have been incorporated. The patch report itself says it's incomplete.

It's very easy to imagine people making patches to show how they think an issue should be fixed without knowing enough to truly say it's right. A few words of encouragement to partial patchers may get them to polish it. If the last comment on a bug report is you saying the assignee saying the patch is too incomplete for inclusion with tips or a link to patch submission guidelines, then nobody will complain that the core D developers ignored them or a perfectly good patch...
May 12 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:
 Robert Clipsham wrote:
 Walter Bright wrote:
 314 does not affect correct code, hence is an implicitly less 
 important issue.

It does however include a patch, submitted almost a year ago I might add.

Yes, but the patch is incomplete.

At the time I'm reading this, I see in the thread window that Cristian and Jarrett have already answered this particular post. However, I take such an offence that I (against my normal behavior) post a reply here before even bothering to read theirs first. If you consider a patch incomplete, wouldn't it be more appropriate to address the issue, than waiting (days, years??) before you get put back-to-wall about it??? Just posting what's wrong or missing with the patch right away would catch the patch poster _while_ he's _still_ got it in his head. Geeezzzz...................................
May 12 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:
 If you consider a patch incomplete,

The author of the patch says it's incomplete in bugzilla.
 wouldn't it be more appropriate to 
 address the issue, than waiting (days, years??) before you get put 
 back-to-wall about it???

There's a long list of things to be done. There seem to be a hundred posts a day here wanting to be read and replied to. There's keeping an eye on the other programming sites for D stuff. There's the blogs I write for DDJ. There's the seminars I'm working up materials for. There's a thousand issues in bugzilla. *Everything* wants my attention. 314 is not breaking anyone's code, it isn't preventing anyone from doing their work. Fixing it completely is not trivial, it'll take some concerted effort to figure out a correct and complete fix. There are far more important issues in bugzilla to be concerned about. I *have* to triage things.
May 12 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:
 Walter Bright wrote:
 Robert Clipsham wrote:
 Walter Bright wrote:
 314 does not affect correct code, hence is an implicitly less 
 important issue.

It does however include a patch, submitted almost a year ago I might add.

Yes, but the patch is incomplete.

At the time I'm reading this, I see in the thread window that Cristian and Jarrett have already answered this particular post. However, I take such an offence that I (against my normal behavior) post a reply here before even bothering to read theirs first. If you consider a patch incomplete, wouldn't it be more appropriate to address the issue, than waiting (days, years??) before you get put back-to-wall about it??? Just posting what's wrong or missing with the patch right away would catch the patch poster _while_ he's _still_ got it in his head. Geeezzzz...................................

If this is important to you, wouldn't it be more appropriate to look into making the patch complete instead of complaining about it? Andrei
May 12 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:
 If this is important to you, wouldn't it be more appropriate to look 
 into making the patch complete instead of complaining about it?
 
 Andrei

The poster of the patch believes it to be complete. Walter looks at it and believes that it is not. It adds perhaps one minute to the time it takes Walter to deal with the patch to add a comment on the bug saying that the patch isn't complete and giving a brief description of the situation in which it fails. This is not the case with bugzilla 314, wherein the person who posted the patch claimed that it was incomplete.
May 13 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 12 May 2009 10:13:38 -0700, Walter Bright wrote:

 The order of importance of bugs is roughly:
 
 1. silently generating bad code
 2. compiler crashes
 3. regressions that break previously working code
 4. not accepting valid code
 5. accepting invalid code
 6. poor error messages
 
 Throw into that how much work a bug is to fix, how many projects it 
 affects, if there's a patch submitted, etc.

This is useful and important information. IMO it should be on your website ASAP. I think you have forgotten another criteria that should be on this list, the age of a bug report. Although a bug, which doesn't fall into the top priorities here, is old it does not mean that it shouldn't be looked at. From a product perspective you are correct - it is of low importance, but from a client perspective, submitting a bug report which is effectively placed in limbo is a let down - it can cause people to no longer want to help you. A trickle of older bugs being fixed would do wonders for client relationship management - especially those with higher votes. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 12 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Derek Parnell Wrote:

 On Tue, 12 May 2009 10:13:38 -0700, Walter Bright wrote:
 
 The order of importance of bugs is roughly:
 
 1. silently generating bad code
 2. compiler crashes
 3. regressions that break previously working code
 4. not accepting valid code
 5. accepting invalid code
 6. poor error messages
 
 Throw into that how much work a bug is to fix, how many projects it 
 affects, if there's a patch submitted, etc.

This is useful and important information. IMO it should be on your website ASAP. I think you have forgotten another criteria that should be on this list, the age of a bug report. Although a bug, which doesn't fall into the top priorities here, is old it does not mean that it shouldn't be looked at. From a product perspective you are correct - it is of low importance, but from a client perspective, submitting a bug report which is effectively placed in limbo is a let down - it can cause people to no longer want to help you. A trickle of older bugs being fixed would do wonders for client relationship management - especially those with higher votes. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell

A few other metrics that effect user perception 1. Has the assignee ever commented on the bug? 2. When will the bug be fixed? Has a milestone been assigned?
May 12 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Jason House (jason.james.house gmail.com)'s article
 Derek Parnell Wrote:
 On Tue, 12 May 2009 10:13:38 -0700, Walter Bright wrote:

 The order of importance of bugs is roughly:

 1. silently generating bad code
 2. compiler crashes
 3. regressions that break previously working code
 4. not accepting valid code
 5. accepting invalid code
 6. poor error messages

 Throw into that how much work a bug is to fix, how many projects it
 affects, if there's a patch submitted, etc.

This is useful and important information. IMO it should be on your website ASAP. I think you have forgotten another criteria that should be on this list, the age of a bug report. Although a bug, which doesn't fall into the top priorities here, is old it does not mean that it shouldn't be looked at. From a product perspective you are correct - it is of low importance, but from a client perspective, submitting a bug report which is effectively placed in limbo is a let down - it can cause people to no longer want to help you. A trickle of older bugs being fixed would do wonders for client relationship management - especially those with higher votes. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell

1. Has the assignee ever commented on the bug? 2. When will the bug be fixed? Has a milestone been assigned?

One thing I would add to prioritizing bug fixes is how many other bugs the feature has. Features that are severely buggy, such as array ops or alias this benefit relatively little from having a single bug fixed because anyone using those features still has to constantly remember that they're buggy and keep the workarounds in mind anyhow. Furthermore, bugs often overlap in how they limit functionality in real-world use cases. On the other hand, features that are pretty well debugged, but still have a few little gotchas, like variadic templates and auto return (See bug 2251 --you can't use both at the same time) or ddoc benefit much more from a single bug fix. Once these last few remaining issues are solved, these features can be used as "gotcha-free" and the user need not constantly feel like he/she is walking through a minefield when using them.
May 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 Just shows how seldom there's an obviously right path to choose.

I tend to deal with things in closely related groups, because the thing is complicated. Getting up to speed on one issue, then dealing with the issues closely related to it, is much more efficient than hopping around.
May 12 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:
 Jarrett Billingsley wrote:
 I know.  How many months has bug 314* had the most votes?  And 313
 while we're at it.  Importing has been broken for years and instead D2
 is getting thread-local variables.  It seems like a gross misdirection
 of effort.

314 does not affect correct code, hence is an implicitly less important issue. The order of importance of bugs is roughly: 1. silently generating bad code 2. compiler crashes 3. regressions that break previously working code 4. not accepting valid code 5. accepting invalid code 6. poor error messages Throw into that how much work a bug is to fix, how many projects it affects, if there's a patch submitted, etc.

Out of the blue, this gives a thought: Suppose you (Walter) encounter a bug report in bugzilla, and decide to not fix it right now. It would probably be very informative, and crowd-pacifying, to simply write two lines of text, describing why you *this time* want to prefer other things. Then (like 2months to 3years later), when you stumble upon the same BR, you might rewrite the "motivation of a not-now fix". The people who read the items, have an easier time accepting the omission of a bug fix, if there's a hint of motivation there. --------------------------- Sorry for asking, but is this somewhere in the path a newbie (or a semi-newbie who's frustrated) stumbles upon it:
 The order of importance of bugs is roughly:

 1. silently generating bad code
 2. compiler crashes
 3. regressions that break previously working code
 4. not accepting valid code
 5. accepting invalid code
 6. poor error messages

(I mean, this post instance in this particular newsgroup should not be the only place where that list is "encounterable".)
May 12 2009
prev sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Wed, 13 May 2009, dsimcha wrote:

 One thing I would add to prioritizing bug fixes is how many other bugs the
feature
 has.  Features that are severely buggy, such as array ops or alias this benefit
 relatively little from having a single bug fixed because anyone using those
 features still has to constantly remember that they're buggy and keep the
 workarounds in mind anyhow.  Furthermore, bugs often overlap in how they limit
 functionality in real-world use cases.
 
 On the other hand, features that are pretty well debugged, but still have a few
 little gotchas, like variadic templates and auto return (See bug 2251 --you
can't
 use both at the same time) or ddoc benefit much more from a single bug fix. 
Once
 these last few remaining issues are solved, these features can be used as
 "gotcha-free" and the user need not constantly feel like he/she is walking
through
 a minefield when using them.

To counter that a little, a few fixes all in one area are a great way to get a lot of bang for the buck. Less time spent due to already being in the right area of the code, and a potentially huge benefit from polishing a feature into being really usable. Just shows how seldom there's an obviously right path to choose. Later, Brad
May 12 2009
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Luís Marques wrote:
 When D1 was declared finished I thought it meant it would progress to 
 a stable state, with nearly all non-minor problems fixed and a large 
 set of companion libraries. I'm afraid I don't see that happening at 
 an animating rate.

D1 regularly gets around 20 bug fixes a month. I don't understand why this is not seen as progress to a stable state. About 80% of bug fixes are common to both D2 and D1.

Doesn't the d1.0blocker list speak for itself? Moreover, Robert has taken the words out of my mouth about why my point (a) is most important. With the amount of time that has passed since DMD 1.00 was released, people would have expected the language spec to be at a stable state by now. Stewart.
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Stewart Gordon wrote:
 With the amount of time that has passed since 
 DMD 1.00 was released, people would have expected the language spec to 
 be at a stable state by now.

Would you like to submit some revisions to it?
May 12 2009
parent Robert Clipsham <robert octarineparrot.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 With the amount of time that has passed since DMD 1.00 was released, 
 people would have expected the language spec to be at a stable state 
 by now.

Would you like to submit some revisions to it?

Maybe it would be a good idea for someone to go through the spec and look for any areas that aren't clear or need expanding? We could create posts on the newsgroup to figure out what needs to be added/changed etc then submit revisions to you.
May 12 2009
prev sibling next sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Mon, 11 May 2009 12:11:53 -0700, Walter Bright wrote:

 Luís Marques wrote:
 When D1 was declared finished I thought it meant it would progress to a
 stable state, with nearly all non-minor problems fixed and a large set
 of companion libraries. I'm afraid I don't see that happening at an
 animating rate.

D1 regularly gets around 20 bug fixes a month. I don't understand why this is not seen as progress to a stable state. About 80% of bug fixes are common to both D2 and D1.

I agree that D1 is getting its fair share of attention, and I support the earlier post that suggested getting in there and making contributions yourself if you don't like the rate of progress in your personal area of interest. D (especially D2 ;-) ) is far and away the best language I have ever worked with already, and I think the team needs to be congratulated for its efforts. I'm embarrassed that I can't contribute more because of other commitments, but when I do, it is done as constructively as possible.
May 11 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 11 May 2009 20:56:59 -0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Derek Parnell wrote:
  * I'm too busy to invest in something that I will need to rework for  
 D2.

While (without using a text preprocessor) you can't make the source code work for both D1 and D2, the amount of rework necessary is quite minor.

I'll have to step in here and say that's not a true statement. It quite heavily depends on your project. For example, Tango still isn't ported to D2, because there are so many designs to re-think. -Steve
May 12 2009
prev sibling next sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
2009/5/12 Lu=C3=ADs Marques <luismarques gmail.com>:
 Walter Bright wrote:
 D1 regularly gets around 20 bug fixes a month. I don't understand why th=


 is not seen as progress to a stable state. About 80% of bug fixes are co=


 to both D2 and D1.

I think my perception (and I accept it may be a perception which does not reflect reality at large) comes from issues like the following. It's not =

 particularly important issue, but it's one for which I could find a bug
 report.

 Two years ago, I tried to use a particular construct and DMD incorrectly
 detected that a statement was not reachable [1]. OK, D1 had been frozen
 earlier that year, so I thought it would be only a matter of time until t=

 higher priority stuff had been taken care of and someone took care of thi=

 issue. That's my experience with stable languages, even if they aren't
 particularly mainstream (say, Lua).

 Two years later I see this issue is still lingering. My perception is tha=

 unless I nag someone or send a fix myself no one will take care of it
 anytime soon. I guess they just have a huge pile of more important stuff,
 which is fair.

 But, 1) how long do you perceive it will take until more pressing matters
 delay fixing these kinds of bugs? I don't know if 20 bug fixes a month is
 enough or not to have DMD v1 rock solid in the next 5 years. Are most of =

 fixes for new bug reports? Is the list of old bugs being cleaned at a goo=

 rate? My perception, I said, was that the rate was a bit disapointing
 (compared with my experience using other language implementations)

 2) Even if most bug fixes are common to D1 and D2, isn't it still true th=

 if D2 is being discussed, elaborated, documented and implemented, most of
 those activities do not fix bugs and take time away from making D1 / DMD =

 stable and with few bugs?

 Some say "send a patch". I'll try, when that is possible. But I can't sen=

 patch for every bug I find in my spreadsheet software, browser, programmi=

 language, IM client, etc. That means that much of the software I use I ha=

 to accept it as is. That applies to everyone which uses a large amount of
 software and is not a programming demigod.

I think this is pretty spot on. The point is not that D1 isn't getting bugfixes, it's which bugs are actually fixed. I realise I've done my part of the whining now and in the past, something I'm going to try and change (by fixing bugs myself and sending patches), but ... I don't know anyone who tried out D seriously who haven't found some near-deal-breaking bug (most of the time already reported), which requires them to implement workarounds that often make some otherwise neat (and according to spec, value) design impossible. It's a huge demotivator. -Tomas P.S. I know we can vote for issues now, that's a really good development and has helped already, but the situation is still not perfect.
May 12 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 12, 2009 at 8:26 AM, Tomas Lindquist Olsen
<tomas.l.olsen gmail.com> wrote:

 P.S. I know we can vote for issues now, that's a really good
 development and has helped already, but the situation is still not
 perfect.

I know. How many months has bug 314* had the most votes? And 313 while we're at it. Importing has been broken for years and instead D2 is getting thread-local variables. It seems like a gross misdirection of effort. *http://d.puremagic.com/issues/show_bug.cgi?id=314
May 12 2009
prev sibling next sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Tue, May 12, 2009 at 2:52 PM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:
 On Tue, May 12, 2009 at 8:26 AM, Tomas Lindquist Olsen
 <tomas.l.olsen gmail.com> wrote:

 P.S. I know we can vote for issues now, that's a really good
 development and has helped already, but the situation is still not
 perfect.

I know. =C2=A0How many months has bug 314* had the most votes? =C2=A0And =

 while we're at it. =C2=A0Importing has been broken for years and instead =

 is getting thread-local variables. =C2=A0It seems like a gross misdirecti=

 of effort.

 *http://d.puremagic.com/issues/show_bug.cgi?id=3D314

Especially since Christian's patch has been in there for over a year - almost as long as it has been applied to LDC, where it still hasn't caused a false positive, only caught bugs!
May 12 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 12, 2009 at 2:00 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Robert Clipsham wrote:
 Walter Bright wrote:
 314 does not affect correct code, hence is an implicitly less important
 issue.

It does however include a patch, submitted almost a year ago I might add.

Yes, but the patch is incomplete.

Then where is your comment on the issue to that effect? You can't honestly expect people to submit patches if you're not going to give feedback as to why you won't include them!
May 12 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 13 May 2009 06:56:03 -0400, Christopher Wright  
<dhasenan gmail.com> wrote:

 Andrei Alexandrescu wrote:
 If this is important to you, wouldn't it be more appropriate to look  
 into making the patch complete instead of complaining about it?
  Andrei

The poster of the patch believes it to be complete. Walter looks at it and believes that it is not. It adds perhaps one minute to the time it takes Walter to deal with the patch to add a comment on the bug saying that the patch isn't complete and giving a brief description of the situation in which it fails. This is not the case with bugzilla 314, wherein the person who posted the patch claimed that it was incomplete.

314 is the subject of this thread. I have to side with Walter on this, the comment (by Christian) says: "Using a variation of this patch to fix the import issue bugs 313 and 314 describe should still be fine." Which seems to indicate using this patch directly would not fix it. -Steve
May 13 2009
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
Stewart Gordon wrote:
 (a) having a spec that the public agrees to be complete and consistent

I think this is probably the most important of your points. Without a complete and consistent spec, there's no possible way to make a correct compiler. All features need to be in there, explaining how they should work in detail. This is a blocker for anyone who wants to write a D compiler currently, they have to go by dmd in some cases rather than the spec.
 (b) all language features implemented

I think this is probably least important currently. Most (if not all) major features have been implemented in D1, and D2 is still in alpha so has no requirement for this.
 (c) all of the most serious known bugs and most of the others fixed

This comes right after a complete spec on what I'd rate as important. While some of these bug fixes might be seen as "breaking changes" that shouldn't be in D1, I think we'll live. I know I'd rather have to update a load of code to comply with the spec than have a load of invalid code that works forever, even if it is a pain to update. I think frontend bugs should take priority here, as they effect all compilers that use it, not just dmd.
 But generally, it's about time D1 got a move on....

Agreed. I've had trouble getting people to use D due to (mainly) those 3 rough edges. Having 3 year old unfixed bugs in the bug tracker doesn't help with persuasion.
 ...when we reach this practical milestone, maybe we could call it D 1.1?

I guess this is up to Walter. Would D 1.1 just be a milestone for D, or would it need a new spec? Maybe D 1.1 could be a fork of D1 which introduces the breaking changes and finalizes the spec? That way we don't have the issue of breaking D1.0. When it is complete D1.0 could be marked deprecated and D1.1 could take its place. Or of course the changes could take place in D1.0 and gradually introduce the breaking changes, making D1.1 the final result (or maybe just D1.098, however many revisions of the compiler it takes :P). Robert
May 12 2009
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Robert Clipsham wrote:
 Stewart Gordon wrote:
 (a) having a spec that the public agrees to be complete and consistent

I think this is probably the most important of your points. Without a complete and consistent spec, there's no possible way to make a correct compiler. All features need to be in there, explaining how they should work in detail. This is a blocker for anyone who wants to write a D compiler currently, they have to go by dmd in some cases rather than the spec.

Exactly what I had been trying to say. <snip>
 I guess this is up to Walter. Would D 1.1 just be a milestone for D, or 
 would it need a new spec? Maybe D 1.1 could be a fork of D1 which 
 introduces the breaking changes and finalizes the spec? That way we 
 don't have the issue of breaking D1.0. When it is complete D1.0 could be 
 marked deprecated and D1.1 could take its place. Or of course the 
 changes could take place in D1.0 and gradually introduce the breaking 
 changes, making D1.1 the final result (or maybe just D1.098, however 
 many revisions of the compiler it takes :P).

What would these breaking changes be? AISI the right time to declare D1.1 is once bug 677 is done and dusted and the remaining spec issues (currently there are 43 non-enhancement issues with the spec keyword filed against D1 and pre-D1 versions) have at least had a go-over. Stewart.
May 12 2009