• Walter Bright (21/21) Aug 26 2007 At the conference, I was asked in various ways how bug fixes and
• Jarrett Billingsley (4/9) Aug 26 2007 Would forward reference issues fit that description? I think they do. ...
• Walter Bright (2/12) Aug 26 2007 The problem is, forward references also have a high cost to fixing.
• Ary Manzana (3/17) Aug 26 2007 So you'll kick forward this problem, while not letting us kick forward
• Jarrett Billingsley (14/15) Aug 26 2007 They also have a high benefit: the compiler will no longer give errors (...
• Bill Baxter (4/20) Aug 26 2007 I hate those import bugs too, but are they really preventing anyone from...
• torhu (22/42) Aug 27 2007 It becomes a real problem when porting code from say, C, because then
• Bill Baxter (8/55) Aug 27 2007 Oh yeh, I'm totally in agreement that the forward referencing errors are...
• Downs (15/35) Aug 27 2007 -----BEGIN PGP SIGNED MESSAGE-----
• Stewart Gordon (6/16) Aug 28 2007 Why not just see 340, rather than singling out a few (one of which is a
• Jarrett Billingsley (9/12) Aug 28 2007 The point of mentioning the duplicate issue is that multiple people have...
• Stewart Gordon (6/10) Aug 28 2007
• Walter Bright (2/4) Aug 31 2007 Here.
• Brad Roberts (5/10) Aug 31 2007 Nit picky.. but not digitalmars.D.announce, surely. How about
• Walter Bright (2/11) Aug 31 2007 Right. My bad.
• Stewart Gordon (6/14) Aug 31 2007 Either way, I'm not sure about how one would fit a newsgroup into a

Walter Bright <newshound1 digitalmars.com> writes:

At the conference, I was asked in various ways how bug fixes and 
improvements are prioritized, given that so much needs to be done.

The short answer is, it's ad hoc. The longer answer is I have some vague 
notion of whatever bubbles to the top of a cost/benefit analysis.

The cost is how much work it is to implement plus how disruptive the 
change will be to others. That means that trivial issues with little 
benefit can get fixed quickly. An example of that would be something 
like a spelling error or an obvious one liner fix.

For more complex issues, I have to look at how much benefit will it 
produce. For example, a while back Don Clugston showed me that if 
certain improvements were made to constant folding of string literals 
were done, it would open the door to a whole new *class* of template 
metaprogramming capability. This made it quite a huge benefit, and so it 
bubbled up to the surface.

I also pay a lot more attention to issues people have that are blocking 
work they are currently engaged in, than to issues of "it would be nice 
to do this for other (unspecified) people." In other words, if there's a 
current, real live use for a change, and no reasonable workaround, it's 
a higher benefit for the cost.

Of course, sometimes it's leavened by just whatever catches interest du 
jour <g>.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fash0i$11ie$1 digitalmars.com...
 I also pay a lot more attention to issues people have that are blocking 
 work they are currently engaged in, than to issues of "it would be nice to 
 do this for other (unspecified) people." In other words, if there's a 
 current, real live use for a change, and no reasonable workaround, it's a 
 higher benefit for the cost.

Would forward reference issues fit that description?  I think they do.  See 
bugzilla 102, 282, 912, and probably others. 

Walter Bright <newshound1 digitalmars.com> writes:

Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fash0i$11ie$1 digitalmars.com...
 I also pay a lot more attention to issues people have that are blocking 
 work they are currently engaged in, than to issues of "it would be nice to 
 do this for other (unspecified) people." In other words, if there's a 
 current, real live use for a change, and no reasonable workaround, it's a 
 higher benefit for the cost.

 
 Would forward reference issues fit that description?  I think they do.  See 
 bugzilla 102, 282, 912, and probably others. 


The problem is, forward references also have a high cost to fixing.

Ary Manzana <ary esperanto.org.ar> writes:

Walter Bright escribió:
 Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fash0i$11ie$1 digitalmars.com...
 I also pay a lot more attention to issues people have that are 
 blocking work they are currently engaged in, than to issues of "it 
 would be nice to do this for other (unspecified) people." In other 
 words, if there's a current, real live use for a change, and no 
 reasonable workaround, it's a higher benefit for the cost.

 Would forward reference issues fit that description?  I think they 
 do.  See bugzilla 102, 282, 912, and probably others. 

 
 
 The problem is, forward references also have a high cost to fixing.

So you'll kick forward this problem, while not letting us kick forward 
declarations? <g>

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fasudc$1mvc$1 digitalmars.com...
 The problem is, forward references also have a high cost to fixing.

They also have a high benefit: the compiler will no longer give errors (that 
are impossible to workaround without serious redeisgns) on otherwise valid 
code.

Furthermore, delaying issues that are difficult to fix means they will never 
be fixed, at least not on any reasonable timescale.  You know that with all 
the new features you're going to be introducing that there will be tons of 
bugs, probably lots of little easy ones.  Keep squashing all the little 
ones, though, and the big ones will just fester.

Another one that comes to mind is broken selective/renamed import privacy 
(bugzilla 313/314).  These are not minor issues, and if they take a lot of 
time to fix -- so be it.  I'd be happy to wait another couple of months for 
all the cool new D2 features. 

Bill Baxter <dnewsgroup billbaxter.com> writes:

Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fasudc$1mvc$1 digitalmars.com...
 The problem is, forward references also have a high cost to fixing.

 
 They also have a high benefit: the compiler will no longer give errors (that 
 are impossible to workaround without serious redeisgns) on otherwise valid 
 code.
 
 Furthermore, delaying issues that are difficult to fix means they will never 
 be fixed, at least not on any reasonable timescale.  You know that with all 
 the new features you're going to be introducing that there will be tons of 
 bugs, probably lots of little easy ones.  Keep squashing all the little 
 ones, though, and the big ones will just fester.
 
 Another one that comes to mind is broken selective/renamed import privacy 
 (bugzilla 313/314).  

I hate those import bugs too, but are they really preventing anyone from 
getting work done?  It's not hard to work around usually.

--bb

torhu <no spam.invalid> writes:

Bill Baxter wrote:
 Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fasudc$1mvc$1 digitalmars.com...
 The problem is, forward references also have a high cost to fixing.

 
 They also have a high benefit: the compiler will no longer give errors (that 
 are impossible to workaround without serious redeisgns) on otherwise valid 
 code.
 
 Furthermore, delaying issues that are difficult to fix means they will never 
 be fixed, at least not on any reasonable timescale.  You know that with all 
 the new features you're going to be introducing that there will be tons of 
 bugs, probably lots of little easy ones.  Keep squashing all the little 
 ones, though, and the big ones will just fester.
 
 Another one that comes to mind is broken selective/renamed import privacy 
 (bugzilla 313/314).  

 
 I hate those import bugs too, but are they really preventing anyone from 
 getting work done?  It's not hard to work around usually.

It becomes a real problem when porting code from say, C, because then 
you don't want to reorganize the whole thing to avoid forward references 
errors.  If you're starting from scratch you can usually fix the 
problems with some amount of trial and error, but if you're starting 
with a couple of dozens of files ported from another language, it's a 
lot harder.

The problem is that it's very hard to figure out what exactly causes 
these errors, so fixing them can take a lot of time.  You don't know 
exactly what causes them, and you don't know exactly why it works if you 
manage to fix them.  It's just no fun.

To make matters worse, dmd 1.018 introduced a new forward reference 
error into one of my projects.  For now, I've just documented that you 
need to use dmd 1.017 or older to compile it.  Without a simple test 
case, reporting it in the bugzilla will only get me replies the likes of 
'dude, please post a minimal test case, or nothing will happen'.  Making 
such a test case could take me hours, and if it leads to the bug 
(regression, even) getting fixed, it's still just the tip of the iceberg 
when it comes to forward reference errors.

This kind of seemingly random errors have a really high pain-in-the-ass 
factor.  Please make them go away.  Or at least document the known bugs 
and their workarounds.

Bill Baxter <dnewsgroup billbaxter.com> writes:

torhu wrote:
 Bill Baxter wrote:
 Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fasudc$1mvc$1 digitalmars.com...
 The problem is, forward references also have a high cost to fixing.

 They also have a high benefit: the compiler will no longer give 
 errors (that are impossible to workaround without serious redeisgns) 
 on otherwise valid code.

 Furthermore, delaying issues that are difficult to fix means they 
 will never be fixed, at least not on any reasonable timescale.  You 
 know that with all the new features you're going to be introducing 
 that there will be tons of bugs, probably lots of little easy ones.  
 Keep squashing all the little ones, though, and the big ones will 
 just fester.

 Another one that comes to mind is broken selective/renamed import 
 privacy (bugzilla 313/314).  

 I hate those import bugs too, but are they really preventing anyone 
 from getting work done?  It's not hard to work around usually.

 
 It becomes a real problem when porting code from say, C, because then 
 you don't want to reorganize the whole thing to avoid forward references 
 errors.  If you're starting from scratch you can usually fix the 
 problems with some amount of trial and error, but if you're starting 
 with a couple of dozens of files ported from another language, it's a 
 lot harder.
 
 The problem is that it's very hard to figure out what exactly causes 
 these errors, so fixing them can take a lot of time.  You don't know 
 exactly what causes them, and you don't know exactly why it works if you 
 manage to fix them.  It's just no fun.
 
 To make matters worse, dmd 1.018 introduced a new forward reference 
 error into one of my projects.  For now, I've just documented that you 
 need to use dmd 1.017 or older to compile it.  Without a simple test 
 case, reporting it in the bugzilla will only get me replies the likes of 
 'dude, please post a minimal test case, or nothing will happen'.  Making 
 such a test case could take me hours, and if it leads to the bug 
 (regression, even) getting fixed, it's still just the tip of the iceberg 
 when it comes to forward reference errors.
 
 This kind of seemingly random errors have a really high pain-in-the-ass 
 factor.  Please make them go away.  Or at least document the known bugs 
 and their workarounds.

Oh yeh, I'm totally in agreement that the forward referencing errors are 
bad and need fixing.  I was only questioning whether the import issues 
(313/314) were also in the same category of seriousness.  The errors 
generated because of those issues would generally be pretty easy to work 
around I would think, even if they do make a mockery of module 
encapsulation.

--bb

Downs <default_357-line yahoo.de> writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fasudc$1mvc$1 digitalmars.com...
 The problem is, forward references also have a high cost to fixing.

 
 They also have a high benefit: the compiler will no longer give errors (that 
 are impossible to workaround without serious redeisgns) on otherwise valid 
 code.
 
 Furthermore, delaying issues that are difficult to fix means they will never 
 be fixed, at least not on any reasonable timescale.  You know that with all 
 the new features you're going to be introducing that there will be tons of 
 bugs, probably lots of little easy ones.  Keep squashing all the little 
 ones, though, and the big ones will just fester.
 
 Another one that comes to mind is broken selective/renamed import privacy 
 (bugzilla 313/314).  These are not minor issues, and if they take a lot of 
 time to fix -- so be it.  I'd be happy to wait another couple of months for 
 all the cool new D2 features. 
 
 

Strongly agreed. Granted, part of it is because I'm on GDC, but even so,
I'm regularly surprised how unstable stuff is, especially when you start
prodding corner cases. I'd choose a reliably-working 1.0 over a nice,
but borked 2.0 anyday.
Just my ¢2. --downs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG0wxrpEPJRr05fBERAu9oAKCj9IBiXsszGqSE+12ct1xFeKHXqwCgoSg2
OyEznmWWGt+g088IDH721nE=
=3jUE
-----END PGP SIGNATURE-----

"Stewart Gordon" <smjg_1998 yahoo.com> writes:

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:fasrq6$1iml$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fash0i$11ie$1 digitalmars.com...
 I also pay a lot more attention to issues people have that are blocking 
 work they are currently engaged in, than to issues of "it would be nice 
 to do this for other (unspecified) people." In other words, if there's a 
 current, real live use for a change, and no reasonable workaround, it's a 
 higher benefit for the cost.

 Would forward reference issues fit that description?  I think they do. 
 See bugzilla 102, 282, 912, and probably others.

Why not just see 340, rather than singling out a few (one of which is a 
duplicate of another anyway)?  Moreover, is 282 really a forward reference 
issue?

Stewart. 

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:fb1cdn$842$1 digitalmars.com...

 Why not just see 340, rather than singling out a few (one of which is a 
 duplicate of another anyway)?

The point of mentioning the duplicate issue is that multiple people have run 
into the same problem over a long period of time.

 Moreover, is 282 really a forward reference issue?

I can't find any other good explanation.  As far as I know those kinds of 
"type blah blah blah does not exist" when dealing with nested types comes up 
most often when one thing is semantically analyzed before the type it 
depends upon has been, so even though the error doesn't say "forward 
reference" it's a side effect of the same issue. 

"Stewart Gordon" <smjg_1998 yahoo.com> writes:

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fash0i$11ie$1 digitalmars.com...
 At the conference, I was asked in various ways how bug fixes and 
 improvements are prioritized, given that so much needs to be done.

 The short answer is, it's ad hoc. The longer answer is I have some vague 
 notion of whatever bubbles to the top of a cost/benefit analysis.

<snip>

Where do _discussions of_ improvements (whether your ideas or someone 
else's) fit into the prioritizing scheme?

Stewart. 

Walter Bright <newshound1 digitalmars.com> writes:

Stewart Gordon wrote:
 Where do _discussions of_ improvements (whether your ideas or someone 
 else's) fit into the prioritizing scheme?

Here.

Brad Roberts <braddr puremagic.com> writes:

On Fri, 31 Aug 2007, Walter Bright wrote:

 Stewart Gordon wrote:
 Where do _discussions of_ improvements (whether your ideas or someone
 else's) fit into the prioritizing scheme?

 
 Here.

Nit picky.. but not digitalmars.D.announce, surely.  How about 
digitalmars.D instead.

Later,
Brad

Walter Bright <newshound1 digitalmars.com> writes:

Brad Roberts wrote:
 On Fri, 31 Aug 2007, Walter Bright wrote:
 
 Stewart Gordon wrote:
 Where do _discussions of_ improvements (whether your ideas or someone
 else's) fit into the prioritizing scheme?

 Here.

 
 Nit picky.. but not digitalmars.D.announce, surely.  How about 
 digitalmars.D instead.

Right. My bad.

"Stewart Gordon" <smjg_1998 yahoo.com> writes:

"Brad Roberts" <braddr puremagic.com> wrote in message 
news:Pine.LNX.4.64.0708311727460.3074 bellevue.puremagic.com...
 On Fri, 31 Aug 2007, Walter Bright wrote:

 Stewart Gordon wrote:
 Where do _discussions of_ improvements (whether your ideas or someone
 else's) fit into the prioritizing scheme?

 Here.

 Nit picky.. but not digitalmars.D.announce, surely.  How about
 digitalmars.D instead.

Either way, I'm not sure about how one would fit a newsgroup into a 
prioritizing scheme ... they just don't seem the right shapes for each 
other.

Stewart.