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 

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 

 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