www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Prioritizing bug fixes & improvements to D

reply 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>.
Aug 26 2007
next sibling parent reply "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.
Aug 26 2007
next sibling parent reply 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.
Aug 26 2007
next sibling parent 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>
Aug 26 2007
prev sibling parent reply "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.
Aug 26 2007
next sibling parent reply 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
Aug 26 2007
parent reply 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.
Aug 27 2007
parent 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
Aug 27 2007
prev sibling parent 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-----
Aug 27 2007
prev sibling parent reply "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.
Aug 28 2007
parent "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.
Aug 28 2007
prev sibling parent reply "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.
Aug 28 2007
parent reply 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.
Aug 31 2007
parent reply 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
Aug 31 2007
next sibling parent 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.
Aug 31 2007
prev sibling parent "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.
Aug 31 2007