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.
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.
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? :)
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.
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.
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? :)
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.
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? :)
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.
<snip> 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.
<snip> 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?
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.
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?
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.
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.
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/.
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.
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/.
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.
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
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.
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.
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 reply 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
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 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 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 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 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 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
 is not seen as progress to a stable state. About 80% of bug fixes are co=
mmon
 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 t=
he
 higher priority stuff had been taken care of and someone took care of thi=
s
 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=
t
 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 goo=
d
 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=
at
 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 sen=
d a
 patch for every bug I find in my spreadsheet software, browser, programmi=
ng
 language, IM client, etc. That means that much of the software I use I ha=
ve
 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 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 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
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 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
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 reply 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
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 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
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?
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 reply 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
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 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 =
313
 while we're at it. =C2=A0Importing has been broken for years and instead =
D2
 is getting thread-local variables. =C2=A0It seems like a gross misdirecti=
on
 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 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 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 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
prev sibling next sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
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). 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.
Leadership, now there's an interesting concept! Maybe we should nominate a leader by popular acclaim, then let her lead. I don't think that Walter has time to be both supremo of development and D leader (pardon the pun) at the same time. In any case it's probably the case that the two roles require completely different mindsets. I remember John Haggins (Zortech), when Walter was working on one of the earliest versions of C++. They were as different as chalk and cheese. But commercially the combination worked for some time. So since D is now mostly open source, perhaps we should discuss democracy?
May 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:

 I remember John Haggins (Zortech), when Walter was working
 on one of the earliest versions of C++. They were as different as
 chalk and cheese. But commercially the combination worked for some
 time.
I enjoyed working with John. We were polar opposites - skills he had I utterly lacked and vice versa. The combination was much more than the sum.
May 12 2009
parent Steve Teale <steve.teale britseyeview.com> writes:
Walter Bright Wrote:

 Steve Teale wrote:
 
 I remember John Haggins (Zortech), when Walter was working
 on one of the earliest versions of C++. They were as different as
 chalk and cheese. But commercially the combination worked for some
 time.
I enjoyed working with John. We were polar opposites - skills he had I utterly lacked and vice versa. The combination was much more than the sum.
You can say that again!
May 12 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Steve Teale wrote:
 Andrei Alexandrescu Wrote:
...
 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.
Leadership, now there's an interesting concept! Maybe we should nominate a leader by popular acclaim, then let her lead. I don't think that Walter has time to be both supremo of development and D leader (pardon the pun) at the same time. In any case it's probably the case that the two roles require completely different mindsets. I remember John Haggins (Zortech), when Walter was working on one of the earliest versions of C++. They were as different as chalk and cheese. But commercially the combination worked for some time. So since D is now mostly open source, perhaps we should discuss democracy?
Democracy and leadership, mentioned in the same post. (By PP and PPP.) An oxymoron, if I ever saw one. Coming from a country where military service is compulsory to all, leadership, responsiblility, and comand, are not something you assign at will. That's common knowledge around here. They're toothless without matching authority, independence (within their domain), and (what I'd call) appropriate slack. And in practice, the individual assigned needs sufficient charisma, needless to say. Folks more eloquent than I have distilled this into two quaint sentences: "authority without responsibility equals dictatorship", and "responsibility without authority equals bureaucracy". Out of these two (in a D context), I fear the latter more.
May 12 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> 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
IMHO opponion, these should exactly match the severity categories in bugzilla.
 Throw into that how much work a bug is to fix, how many projects it 
 affects, if there's a patch submitted, etc.
If open bugs were marked with a difficulty level, that may reduce the barrier to entry for would-be hackers of the dmd source. I've been thinking lately that D needs a "help wanted" page that lists broad categories for contribution and instructions on getting started. The list posted in the promoting D thread seemed like a great start. I've also wondered a bit about the impression people have of Walter ignoring the things most important to them. Obviously, everyone can't talk to Walter directly. I wonder if it would be possible to have official delegates on specific aspects of D... People hand picked by Walter as expert proxies. For example, changes to std.algorithm (and all of Phobos?) should go through Andrei. I have not tried to come up with a list of categories. Having an exhaustive set of D-related concerns ans officisl proxies would help focus discussion/efforts. It also gives a way for a the most important concerns to be raised to Walter directly through back channels such as coffee shop discussions , phone calls, e-mail etc.
May 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 I've also wondered a bit about the impression people have of Walter
 ignoring the things most important to them. Obviously, everyone can't
 talk to Walter directly. I wonder if it would be possible to have
 official delegates on specific aspects of D... People hand picked by
 Walter as expert proxies. For example, changes to std.algorithm (and
 all of Phobos?)  should go through Andrei. I have not tried to come
 up with a list of categories. Having an exhaustive set of D-related
 concerns ans officisl proxies would help focus discussion/efforts. It
 also gives a way for a the most important concerns to be raised to
 Walter directly through back channels such as coffee shop discussions
 , phone calls, e-mail etc.
I've been wondering if it's time for another D conference.
May 12 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, May 12, 2009 at 3:53 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 I've been wondering if it's time for another D conference.
Yes! (Since I'm now living a lot closer than I used to be... :-) Depending on the timing, I could probably do a talk on something. Maybe the as-yet-nonexistent automatic differentiation in D, heh. --bb
May 12 2009
prev sibling next sibling parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
On Tue, 12 May 2009, Walter Bright wrote:

 Jason House wrote:
 I've also wondered a bit about the impression people have of Walter
 ignoring the things most important to them. Obviously, everyone can't
 talk to Walter directly. I wonder if it would be possible to have
 official delegates on specific aspects of D... People hand picked by
 Walter as expert proxies. For example, changes to std.algorithm (and
 all of Phobos?)  should go through Andrei. I have not tried to come
 up with a list of categories. Having an exhaustive set of D-related
 concerns ans officisl proxies would help focus discussion/efforts. It
 also gives a way for a the most important concerns to be raised to
 Walter directly through back channels such as coffee shop discussions
 , phone calls, e-mail etc.
I've been wondering if it's time for another D conference.
I'm pretty sure I could offer the space again (I'd need to reserve the rooms far in advance). Offering my time to schedule and gather speakers and people is what caused the last attempt to fizzle. I'd be happy to setup the same signup page (and even enhance it if there's desires for it to do more) again. Really, getting speakers committed and organized is the largest part of the work other than the actual event itself. If there's sufficient interest, and a range of dates chosen, I'll be glad to go see what I can arrange with our conferencing guys. Later, Brad
May 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Brad Roberts wrote:
 On Tue, 12 May 2009, Walter Bright wrote:
 
 Jason House wrote:
 I've also wondered a bit about the impression people have of Walter
 ignoring the things most important to them. Obviously, everyone can't
 talk to Walter directly. I wonder if it would be possible to have
 official delegates on specific aspects of D... People hand picked by
 Walter as expert proxies. For example, changes to std.algorithm (and
 all of Phobos?)  should go through Andrei. I have not tried to come
 up with a list of categories. Having an exhaustive set of D-related
 concerns ans officisl proxies would help focus discussion/efforts. It
 also gives a way for a the most important concerns to be raised to
 Walter directly through back channels such as coffee shop discussions
 , phone calls, e-mail etc.
I've been wondering if it's time for another D conference.
I'm pretty sure I could offer the space again (I'd need to reserve the rooms far in advance). Offering my time to schedule and gather speakers and people is what caused the last attempt to fizzle. I'd be happy to setup the same signup page (and even enhance it if there's desires for it to do more) again. Really, getting speakers committed and organized is the largest part of the work other than the actual event itself. If there's sufficient interest, and a range of dates chosen, I'll be glad to go see what I can arrange with our conferencing guys.
The stars are aligning themselves very nicely for a second D conference. However, I would like to suggest a few changes this time around that are aimed at improving the quality of the conference. * All submissions will be reviewed by a committee. They must be presented at least as abstract + slides for review. The committee will reject weak submissions even though there might be "space" left. No more "I think I can slap together something" this time around. * The conference should not be free. This may seem odd, but I am convinced that a non-free conference will end up being better than a free one. There will be a cost that's reasonable but non-null. Speakers will get appropriate discounts and transportation reimbursements, which encourages competitiveness and also allows us to bring an outside authority for e.g. a keynote talk. * We should put together one or more panels. I personally don't care much for panels/roundtables/etc., but somehow most people love them. For the state of D in particular, I believe the panel format will be very appropriate. In short, I'd like to hold a real, good-quality conference. Andrei
May 12 2009
next sibling parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
On Tue, 12 May 2009, Andrei Alexandrescu wrote:

 The stars are aligning themselves very nicely for a second D conference.
 However, I would like to suggest a few changes this time around that are aimed
 at improving the quality of the conference.
 
 * All submissions will be reviewed by a committee. They must be presented at
 least as abstract + slides for review. The committee will reject weak
 submissions even though there might be "space" left. No more "I think I can
 slap together something" this time around.
Two or whatever years ago, I was _lucky_ to get enough speakers to justify having the conference. I see no reason to expect that there will suddenly be a wealth of them such that proposed talks could be rejected. That'd be a wonderful place to be.
 * The conference should not be free. This may seem odd, but I am convinced
 that a non-free conference will end up being better than a free one. There
 will be a cost that's reasonable but non-null. Speakers will get appropriate
 discounts and transportation reimbursements, which encourages competitiveness
 and also allows us to bring an outside authority for e.g. a keynote talk.
Given the cost of attendance (airfare, lodging, etc), I'm reluctant to put additional barriers in place. But I wouldn't say no to the idea. I'll point out that last year some of the speakers who couldn't have otherwise attended were assisted flown in. What you're really saying is that there needs to be a budget. That doesn't imply cost to attend, though it would certainly help.
 * We should put together one or more panels. I personally don't care much for
 panels/roundtables/etc., but somehow most people love them. For the state of D
 in particular, I believe the panel format will be very appropriate.
I agree. I love panel discussions as they become actual discussions rather than presentations with Q/A sprinkled in or after.
 In short, I'd like to hold a real, good-quality conference.
I'm all for this, but I'd quibble about the definition. Later, Brad
May 12 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Brad,
 
 Two or whatever years ago, I was _lucky_ to get enough speakers to
 justify having the conference.  I see no reason to expect that there
 will suddenly be a wealth of them such that proposed talks could be
 rejected.  That'd be a wonderful place to be.
 
Tell someone they might not be good enough and sometime they will be even more willing to try.
 Given the cost of attendance (airfare, lodging, etc), I'm reluctant to
 put additional barriers in place.  But I wouldn't say no to the idea.
 I'll point out that last year some of the speakers who couldn't have
 otherwise attended were assisted flown in.  What you're really saying
 is that there needs to be a budget.  That doesn't imply cost to
 attend, though it would certainly help.
 
If $20 keeps someone out, they aren't that interested in the first place
 I agree.  I love panel discussions as they become actual discussions
 rather than presentations with Q/A sprinkled in or after.
 
Something over food would be really cool! Kinda like the dinner in the middle of that 1st conference but less spread out.
May 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 Hello Brad,
 Two or whatever years ago, I was _lucky_ to get enough speakers to
 justify having the conference.  I see no reason to expect that there
 will suddenly be a wealth of them such that proposed talks could be
 rejected.  That'd be a wonderful place to be.
Tell someone they might not be good enough and sometime they will be even more willing to try.
 Given the cost of attendance (airfare, lodging, etc), I'm reluctant to
 put additional barriers in place.  But I wouldn't say no to the idea.
 I'll point out that last year some of the speakers who couldn't have
 otherwise attended were assisted flown in.  What you're really saying
 is that there needs to be a budget.  That doesn't imply cost to
 attend, though it would certainly help.
If $20 keeps someone out, they aren't that interested in the first place
Yes. No doubt the first conference was an unqualified success (thanks, Brad!) but this time around the novelty factor has worn off. It's not the first step on the moon, it's going again on the moon. We must have quality to offer. And at the risk of annoying BCS and others, let me point out that I don't think this is the best way to go (although it does work and God knows I've done it): "I might (note I said might, I'm not committing to anything... yet) be able to put together a talk on something." The way it ideally goes is not starting from giving a talk on "something" and then figuring out the "something". Ideally /you have something specific to say/ in the first place, and completing a submission is a matter of chipping the extra marble away. About money: if the conference is free the perception is that you get what you paid for. Remember how many people said "yeah, I might make it" and then didn't show? I think people should get a lot this time around, and that the organizers and participants should make a mutual commitment by putting a monetary value on it. Andrei
May 12 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Andrei,

 We must have quality to offer. And at the risk of annoying BCS and
 others, let me point out that I don't think this is the best way to go
 (although it does work and God knows I've done it): "I might (note I
 said might, I'm not committing to anything... yet) be able to put
 together a talk on something."
For those who didn't spot the inside joke there: Last time around I said something non-committal about maybe having something I could present and the next thing I knew, I had an hour slot in the schedule to fill, talk about motivation to get something done! The nitty-gritty this time around is that I have a project in mind that, if I can get it working would make a reasonable presentation (but I haven't started it yet). If I /knew/ there was as call for presentations out and a deadline (and maybe funds to get speakers on site :) I'd *make* time to see what I could do with it and then commit, or not.
May 12 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 Hello Andrei,
 
 We must have quality to offer. And at the risk of annoying BCS and
 others, let me point out that I don't think this is the best way to go
 (although it does work and God knows I've done it): "I might (note I
 said might, I'm not committing to anything... yet) be able to put
 together a talk on something."
For those who didn't spot the inside joke there: Last time around I said something non-committal about maybe having something I could present and the next thing I knew, I had an hour slot in the schedule to fill, talk about motivation to get something done! The nitty-gritty this time around is that I have a project in mind that, if I can get it working would make a reasonable presentation (but I haven't started it yet). If I /knew/ there was as call for presentations out and a deadline (and maybe funds to get speakers on site :) I'd *make* time to see what I could do with it and then commit, or not.
That sounds great. Thank you for not getting offended, I'm glad you understood my point. Andrei
May 12 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 BCS wrote:
 Hello Brad,
 Two or whatever years ago, I was _lucky_ to get enough speakers to
 justify having the conference.  I see no reason to expect that there
 will suddenly be a wealth of them such that proposed talks could be
 rejected.  That'd be a wonderful place to be.
Tell someone they might not be good enough and sometime they will be even more willing to try.
 Given the cost of attendance (airfare, lodging, etc), I'm reluctant to
 put additional barriers in place.  But I wouldn't say no to the idea.
 I'll point out that last year some of the speakers who couldn't have
 otherwise attended were assisted flown in.  What you're really saying
 is that there needs to be a budget.  That doesn't imply cost to
 attend, though it would certainly help.
If $20 keeps someone out, they aren't that interested in the first place
Yes. No doubt the first conference was an unqualified success (thanks, Brad!) but this time around the novelty factor has worn off. It's not the first step on the moon, it's going again on the moon.
Yes, and this time around, we should *really* try to get an audience that represents the industry. While M$ might not attend, Google, Nokia, Apple, game developers, and others might be good targets.
 We must have quality to offer. And at the risk of annoying BCS and 
 others, let me point out that I don't think this is the best way to go 
 (although it does work and God knows I've done it): "I might (note I 
 said might, I'm not committing to anything... yet) be able to put 
 together a talk on something."
 
 The way it ideally goes is not starting from giving a talk on 
 "something"  and then figuring out the "something". Ideally /you have 
 something specific to say/ in the first place, and completing a 
 submission is a matter of chipping the extra marble away.
We should recognize such individuals, and offer them even help in writing their presentations. The main thing is, how important these are for D, the advancement of a perception of D as a Best Language, and the merits of such individuals' accomplishments.
 About money: if the conference is free the perception is that you get 
 what you paid for. Remember how many people said "yeah, I might make it" 
 and then didn't show? I think people should get a lot this time around, 
 and that the organizers and participants should make a mutual commitment 
 by putting a monetary value on it.
Prepaid attendance is a must. To achieve that, we have to offer big discounts for early (paid) registrations. That money can also be conveniently used for setting up the conference. A dedicated set of web pages, (or even a web site, or sub-site) has to be set up, designed and carefully written, or we won't get squat. A call for papers has to be attractive enough to not only attract potential presenters, but also to attract their employers so that these individuals get the resources (time off, funding, and guarantees of transport and lodging costs, should they not be chosen for presenting) necessary to make a serious attempt at a qualifiable entry.
May 12 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 Two or whatever years ago, I was _lucky_ to get enough speakers to justify 
 having the conference.  I see no reason to expect that there will suddenly 
 be a wealth of them such that proposed talks could be rejected.  That'd be 
 a wonderful place to be.
It's a fair amount of work to put together a presentation. Being able to offer a free ticket, plus perhaps some expense reimbursement for speakers, can be very motivating (and is only fair).
May 12 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Brad Roberts wrote:
 On Tue, 12 May 2009, Andrei Alexandrescu wrote:
 
 The stars are aligning themselves very nicely for a second D conference.
 However, I would like to suggest a few changes this time around that are aimed
 at improving the quality of the conference.

 * All submissions will be reviewed by a committee. They must be presented at
 least as abstract + slides for review. The committee will reject weak
 submissions even though there might be "space" left. No more "I think I can
 slap together something" this time around.
Two or whatever years ago, I was _lucky_ to get enough speakers to justify having the conference. I see no reason to expect that there will suddenly be a wealth of them such that proposed talks could be rejected. That'd be a wonderful place to be.
The more people that get to hear the "call for papers", the more stuff you have to choose from. Also helping, motivating, and enabling more people to (or even try to) write papers, increases the likelihood that a half dozen of them are adequate.
 * The conference should not be free. This may seem odd, but I am convinced
 that a non-free conference will end up being better than a free one. There
 will be a cost that's reasonable but non-null. Speakers will get appropriate
 discounts and transportation reimbursements, which encourages competitiveness
 and also allows us to bring an outside authority for e.g. a keynote talk.
Given the cost of attendance (airfare, lodging, etc), I'm reluctant to put additional barriers in place.
There are two kinds of attendees. Those who do D on their own, and then those who come paid by their employers. (Many of which don't even tinker with D, but who represent communities that are interested of D, or just in general want to stay up to date.) For the latter, it may even be easier to get funding, if the conference costs even 30% of the airfare + lodging cost. (Yes, I'm digging my own grave here, but it's D's cause I'm furthering here, not my own. And yes, that makes me stupid, agreed.)
  But I wouldn't say no to the idea.  I'll 
 point out that last year some of the speakers who couldn't have otherwise 
 attended were assisted flown in.  What you're really saying is that there 
 needs to be a budget.  That doesn't imply cost to attend, though it would 
 certainly help.
 
 * We should put together one or more panels. I personally don't care much for
 panels/roundtables/etc., but somehow most people love them. For the state of D
 in particular, I believe the panel format will be very appropriate.
I agree. I love panel discussions as they become actual discussions rather than presentations with Q/A sprinkled in or after.
 In short, I'd like to hold a real, good-quality conference.
I'm all for this, but I'd quibble about the definition. Later, Brad
May 12 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Brad Roberts wrote:
 On Tue, 12 May 2009, Walter Bright wrote:

 Jason House wrote:
 I've also wondered a bit about the impression people have of Walter
 ignoring the things most important to them. Obviously, everyone can't
 talk to Walter directly. I wonder if it would be possible to have
 official delegates on specific aspects of D... People hand picked by
 Walter as expert proxies. For example, changes to std.algorithm (and
 all of Phobos?)  should go through Andrei. I have not tried to come
 up with a list of categories. Having an exhaustive set of D-related
 concerns ans officisl proxies would help focus discussion/efforts. It
 also gives a way for a the most important concerns to be raised to
 Walter directly through back channels such as coffee shop discussions
 , phone calls, e-mail etc.
I've been wondering if it's time for another D conference.
I'm pretty sure I could offer the space again (I'd need to reserve the rooms far in advance). Offering my time to schedule and gather speakers and people is what caused the last attempt to fizzle. I'd be happy to setup the same signup page (and even enhance it if there's desires for it to do more) again. Really, getting speakers committed and organized is the largest part of the work other than the actual event itself. If there's sufficient interest, and a range of dates chosen, I'll be glad to go see what I can arrange with our conferencing guys.
The stars are aligning themselves very nicely for a second D conference. However, I would like to suggest a few changes this time around that are aimed at improving the quality of the conference. * All submissions will be reviewed by a committee. They must be presented at least as abstract + slides for review. The committee will reject weak submissions even though there might be "space" left. No more "I think I can slap together something" this time around.
Yes.
 * The conference should not be free. This may seem odd, but I am 
 convinced that a non-free conference will end up being better than a 
 free one. There will be a cost that's reasonable but non-null. Speakers 
 will get appropriate discounts and transportation reimbursements, which 
 encourages competitiveness and also allows us to bring an outside 
 authority for e.g. a keynote talk.
However I'd like to dislike this idea, I simply have to agree.
 * We should put together one or more panels. I personally don't care 
 much for panels/roundtables/etc., but somehow most people love them. For 
 the state of D in particular, I believe the panel format will be very 
 appropriate.
For such a conference, what's needed is a panel with Walter, another with Andrei, with Don Clugston, with Sean Kelly, and then, if time allows, some panels with varying combinations of the three. (What the headlines are for those, makes no difference! Folks will want to hear these people, period.)
 In short, I'd like to hold a real, good-quality conference.
May 12 2009
prev sibling parent BCS <none anon.com> writes:
Hello Walter,

 Jason House wrote:
 
 I've also wondered a bit about the impression people have of Walter
 ignoring the things most important to them. Obviously, everyone can't
 talk to Walter directly. I wonder if it would be possible to have
 official delegates on specific aspects of D... People hand picked by
 Walter as expert proxies. For example, changes to std.algorithm (and
 all of Phobos?)  should go through Andrei. I have not tried to come
 up with a list of categories. Having an exhaustive set of D-related
 concerns ans officisl proxies would help focus discussion/efforts. It
 also gives a way for a the most important concerns to be raised to
 Walter directly through back channels such as coffee shop discussions
 , phone calls, e-mail etc.
 
I've been wondering if it's time for another D conference.
I'm game. I might (note I said might, I'm not committing to anything... yet) be able to put together a talk on something.
May 12 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Jason House wrote:
 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
 IMHO opponion, these should exactly match the severity categories in
 bugzilla.
 
 Throw into that how much work a bug is to fix, how many projects it
  affects, if there's a patch submitted, etc.
If open bugs were marked with a difficulty level, that may reduce the barrier to entry for would-be hackers of the dmd source.
Whee, that's a new take on this one, and I wholeheartedly support the notion! (And, of course, an educated first-reading guess from a D guru is enough, nobody expects something that perfectly correlates with some a-posteriori notion of actual effort!)
 I've been thinking lately that D needs a "help wanted" page that
 lists broad categories for contribution and instructions on getting
 started. The list posted in the promoting D thread seemed like a
 great start.
Yes!
 I've also wondered a bit about the impression people have of Walter
 ignoring the things most important to them. Obviously, everyone can't
 talk to Walter directly. I wonder if it would be possible to have
 official delegates on specific aspects of D... People hand picked by
 Walter as expert proxies. For example, changes to std.algorithm (and
 all of Phobos?)  should go through Andrei. I have not tried to come
 up with a list of categories. Having an exhaustive set of D-related
 concerns ans officisl proxies would help focus discussion/efforts. It
 also gives a way for a the most important concerns to be raised to
 Walter directly through back channels such as coffee shop discussions
 , phone calls, e-mail etc.
Very valid points! As a precedent, I've always wondered how Linus Torvalds (of Linxu fame) made the transition from about 5 guys as helpers to 1000 guys, seeming to have *no* problem at all, expanding in less than a few months. I've always thought that he must've been lucky as hell, but then I realise that that's just lazy thinking, after the fact. The other explanation worries the daylights out of me: maybe he simply was a superior being. Meaning that, first of all, just reading Tanenbaum, he understood, and perceived as trivial, stuff that sent everybody else screaming to the woods. *And*, second, that creating, constantly modifying, and expanding, a hierarchy of aides, was no bigger a thing for him, than programming a balanced red-black tree. Actually, we're luckier than Linus, because we've already got Andrei, and Don ((and a few others, apologies for not mentioning here!!!)), (in addition to Walter, of course), but the rest of the "forest management" has been, ehh, haphazard, at the most, so far. Creating SIGs, hierarchies, work flows, compartmentalizing task groups, assigning responsibilities, letting go of "all threads in _my_ hands", distributing authority, even Specifying web page specs and arrays of them -- are all tasks that traditionally have *not* been the forte of "programming geeks" or 'auteurs'. As we approach the day when most of the things what we'd (as D geeks) believe should be met (to admittedly varying degrees of success), it becomes increasingly important to recognize (and *admit*) the things we *must deal with* as the next cohort of issues. ((I can only hope that this makes sense to more than half of the readers.))
May 12 2009
parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Wed, 13 May 2009, Georg Wrede wrote:

 As a precedent, I've always wondered how Linus Torvalds (of Linxu fame) made
 the transition from about 5 guys as helpers to 1000 guys, seeming to have *no*
 problem at all, expanding in less than a few months.
 
 I've always thought that he must've been lucky as hell, but then I realise
 that that's just lazy thinking, after the fact. The other explanation worries
 the daylights out of me: maybe he simply was a superior being. Meaning that,
 first of all, just reading Tanenbaum, he understood, and perceived as trivial,
 stuff that sent everybody else screaming to the woods. *And*, second, that
 creating, constantly modifying, and expanding, a hierarchy of aides, was no
 bigger a thing for him, than programming a balanced red-black tree.
 
 Actually, we're luckier than Linus, because we've already got Andrei, and Don
 ((and a few others, apologies for not mentioning here!!!)), (in addition to
 Walter, of course), but the rest of the "forest management" has been, ehh,
 haphazard, at the most, so far.
This one is relatively easy to answer. He's still got just a handfull of guys. THEY fan out to the multitudes and aggregate changes that he pulls in. There's a very high degree of trust between Linus and the next tier of developers. He does some level of spot checking, primarily in core areas and areas known to be problems, but by and large, there's a lot of code that's just directly funnelled through the others that own various subsystems. Similarly, asside from the odd code review here and there, Andrei's changes to Phobos are fully under his control. We're growing in baby steps, but there's a lot of 'em left. :) Later, Brad
May 12 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Jason House wrote:
 I've also wondered a bit about the impression people have of Walter
 ignoring the things most important to them. Obviously, everyone can't
 talk to Walter directly. I wonder if it would be possible to have
 official delegates on specific aspects of D... People hand picked by
 Walter as expert proxies. For example, changes to std.algorithm (and
 all of Phobos?)  should go through Andrei. I have not tried to come
 up with a list of categories. Having an exhaustive set of D-related
 concerns ans officisl proxies would help focus discussion/efforts. It
 also gives a way for a the most important concerns to be raised to
 Walter directly through back channels such as coffee shop discussions
 , phone calls, e-mail etc.
I've been wondering if it's time for another D conference.
I'm disapointed that you did not comment about any of the ideas I put in my post :( Maybe the implication is that you intend to talk about this issue at the conference just like the whole Phobos vs. Tango thing at the prior conference. Is that right? Sadly, I won't be at any D conferences unless my employer uses D, which I don't expect to happen for a long time :(
May 13 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 I'm disapointed that you did not comment about any of the ideas I put
 in my post :(
I spent most of my work time yesterday composing and posting. I'm sorry I did not comment on everything - it's just impossible. A conference, though, can be a far more effective and efficient way to have these kinds of conversations.
 Sadly, I won't be at any D conferences unless my employer uses D,
 which I don't expect to happen for a long time :(
Sounds like an opportunity! Every employer I've worked at welcomed 'tech' presentations by its employees. You can do one on D, which can spark further interest.
May 13 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 Jason House wrote:
 I'm disapointed that you did not comment about any of the ideas I put
 in my post :(
I spent most of my work time yesterday composing and posting. I'm sorry I did not comment on everything - it's just impossible.
I understand that, but I still reserve the right to be disappointed! Given how positive a response it got in the other reply, I was hoping you'd take a deeper consideration of the ideas. I'm trying to find ways to solve issues instead of complain about them.
 A conference,
 though, can be a far more effective and efficient way to have these
 kinds of conversations.
 
 
 Sadly, I won't be at any D conferences unless my employer uses D,
 which I don't expect to happen for a long time :(
Sounds like an opportunity! Every employer I've worked at welcomed 'tech' presentations by its employees. You can do one on D, which can spark further interest.
I've been doing a bit of that around the office ;)
May 13 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 I understand that, but I still reserve the right to be disappointed!
I don't blame you, I would be, too.
May 13 2009