www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Some Observations on the D Development Process

reply Mike Franklin <slavo5150 yahoo.com> writes:
This is in response to some of the frustrations offered in the 
thread staring with 
http://forum.dlang.org/post/oeigdutfphxhenexcqsn forum.dlang.org

I share some of those frustrations, and I've been vocal about 
such things myself.  However, in the last 2 months, at least in 
terms of the DMD repository, things may be starting to change for 
the better.

Recent Promising Progress
-------------------------
A few of us are working hard to revive old PRs and either see 
them across the finish line, or give them a quick path to 
closure. 2 months ago the DMD PR queue stood at about 190.  Now 
it's hovering between 140 and 150.  So, we're getting better; 
take a look at the graphs here for evidence:  
https://auto-tester.puremagic.com/chart.ghtml?projectid=1. Notice 
the spike in PR submissions in December, and we're still 40 PRs 
less than we were 2 months ago.

2 months ago, the oldest PR was dated 2012, believe it or not:  
https://github.com/dlang/dmd/pull/1145.  Our oldest is now 2013, 
which is still pretty bad, but it was partially revived recently 
at https://github.com/dlang/dmd/pull/7503.  Unfortunately, it's 
probably the most difficult PR we have.

I'll take the risk of arguing that we've widened the review 
bottleneck recently for straight-forward PRs.  However, for 
difficult, complex, or controversial PRs, it still looks like we 
lack contributors with the right skills that are willing 
volunteer their time, and tolerate some inconveniences.

There has also been a lot of work done on improving 
infrastructure for testing (e.g. Adding the Appveyor CI for 
testing Windows) and automating some of the mundane tasks (e.g. 
https://github.com/dlang/dmd/pull/7507).

A Few Observations About Our Talent
-----------------------------------
IMO, one of the most worrisome issues we have is a talent 
retention problem (at least for DMD).  It appears many of those 
with the talent to review and fix difficult compiler bugs are no 
longer active, or just pop in from time-to-time.  I'm not sure 
why that is. I know a few have left or don't participate much due 
to dissatisfaction in the way D is managed.  Others, I think, 
were working on D as students and now have blossoming careers 
outside of D to maintain.  I also know of at least one that found 
Rust to be a better alternative.  But, I can also understand how 
someone would just grow sick and tired of working on the same 
thing for months or years.

Walter seems to pop in daily, and occasionally reviews PRs, and 
his PRs of late are mostly just refactorings rather than fixing 
difficult bugs.  We desperately need his help on the more 
difficult issues (e.g. https://github.com/dlang/dmd/pull/7568 and 
https://github.com/dlang/dmd/pull/7566), but I don't know if he's 
well-aware of those items and just busy with other things, or if 
those items are simply not on his radar.  If it's the latter, and 
it would help, I'll publish a digest periodically.

Andrei pops in unpredictably, and sometimes goes on a PR review 
rampage.  The infrequency, however, makes it difficult to 
follow-up and maintain momentum on individual items that need his 
judgement (e.g. https://github.com/dlang/dmd/pull/7099)

That being said, there are some very talented software engineers 
active on this forum that are only seldom active in the PR queue. 
I don't know why that is; perhaps it's simply a matter of time 
and energy, or perhaps it's frustration.  As others have said, 
you don't need to have commit access to be a helpful reviewer. 
And, after showing a willingness to participate, demonstrating 
your abilities, and earning the confidence of the leadership, you 
might be asked to join the team, and then you'll really be able 
to make things happen.

Final Words
-----------
Due to recent changes, if you have a straight-forward, 
non-controversial PR, it will likely be merged in a week or two; 
usually less, and sometimes even within a few hours.  If the PR 
is difficult, complex, or controversial, then it may languish in 
PR purgatory for some time, unfortunately.  I don't know what can 
be done about that at this time without skilled, 
frequently-active talent.

My two-cents,

Mike
Jan 04 2018
next sibling parent rjframe <dlang ryanjframe.com> writes:
On Thu, 04 Jan 2018 10:34:05 +0000, Mike Franklin wrote:


 This is in response to some of the frustrations offered in the thread
 staring with
 http://forum.dlang.org/post/oeigdutfphxhenexcqsn forum.dlang.org
 
 I share some of those frustrations, and I've been vocal about such
 things myself.  However, in the last 2 months, at least in terms of the
 DMD repository, things may be starting to change for the better.
 
 Recent Promising Progress -------------------------
 A few of us are working hard to revive old PRs ...



This is an important post. It's easy to make a habit of complaining about 
things, but it's good to stop and say "but look where we are right now." 
You do this without acting like all problems are being solved, too. So 
thank you.

I do think it's important to mention that the improvements you've 
mentioned came about because some people said "we're going to fix this" 
rather than wait for someone else to do it. There are problems that can 
only be resolved by one or two people, but there are many others that 
anybody take can take care of.
Jan 04 2018
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 4 January 2018 at 10:34:05 UTC, Mike Franklin wrote:

 A few of us are working hard to revive old PRs and either see 
 them across the finish line, or give them a quick path to 
 closure. 2 months ago the DMD PR queue stood at about 190.  Now 
 it's hovering between 140 and 150.


DMD also has at least 30 PRs which have had no action from the 
author in over a year. There's no reason these should be kept 
open; they just take up auto-tester resources and lower the 
signal to noise ratio.

If the author comes back later, they can always ask a maintainer 
to reopen.
Jan 04 2018
next sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 4 January 2018 at 17:44:58 UTC, Jack Stouffer wrote:

 DMD also has at least 30 PRs which have had no action from the 
 author in over a year. There's no reason these should be kept 
 open; they just take up auto-tester resources and lower the 
 signal to noise ratio.


FYI: stalled PRs don't take up resources (except they target 
stable, which is why one of the reasons stable PRs should be 
merged ASAP). It's due to the auto-tester sorting PRs by their 
activity.

BTW: For those who haven't seen this, dlang-bot now detects these 
stalled PRs and for now labels them as "stalled":

https://github.com/dlang-bots/dlang-bot/blob/master/source/dlangbot/cron.d#L60

I'm not sure whether auto-closing them is a good idea, but we 
definitely need to do sth. about them.
Also one year without any activity is a very long time. Dlang-bot 
currently uses 90 days though imho that's already very 
conservative.

Example:

https://github.com/dlang/dmd/pulls?q=is%3Aopen+is%3Apr+label%3Astalled
Jan 04 2018
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Thursday, 4 January 2018 at 18:09:32 UTC, Seb wrote:

 On Thursday, 4 January 2018 at 17:44:58 UTC, Jack Stouffer 
 wrote:

 DMD also has at least 30 PRs which have had no action from the 
 author in over a year. There's no reason these should be kept 
 open; they just take up auto-tester resources and lower the 
 signal to noise ratio.


 FYI: stalled PRs don't take up resources (except they target 
 stable, which is why one of the reasons stable PRs should be 
 merged ASAP). It's due to the auto-tester sorting PRs by their 
 activity.


They waste resources of folks looking to review stuff that is 
actual and active.


 BTW: For those who haven't seen this, dlang-bot now detects 
 these stalled PRs and for now labels them as "stalled":

 https://github.com/dlang-bots/dlang-bot/blob/master/source/dlangbot/cron.d#L60

 I'm not sure whether auto-closing them is a good idea, but we 
 definitely need to do sth. about them.
 Also one year without any activity is a very long time.


It’s not like we loose anything, we don’t delete code of the 
author. So should he/she find time - just create a new PR. Also 
these willing to dig in the closed PRs are free to do so (it’s 
just a couple of passes to add a filter to your search).

Personally, I’d say 3 of months of silence usually enough to put 
off most except for seasoned contributors. Many opensource 
projects do even worse job but we should look at the best 
examples.


 Dlang-bot currently uses 90 days though imho that's already 
 very conservative.


Just tagging doesn’t really help, I already can sort by activity.


 Example:

 https://github.com/dlang/dmd/pulls?q=is%3Aopen+is%3Apr+label%3Astalled
Jan 04 2018
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 04, 2018 at 06:50:25PM +0000, Dmitry Olshansky via Digitalmars-d
wrote:

 On Thursday, 4 January 2018 at 18:09:32 UTC, Seb wrote:


[...]

 BTW: For those who haven't seen this, dlang-bot now detects these
 stalled PRs and for now labels them as "stalled":
 
 https://github.com/dlang-bots/dlang-bot/blob/master/source/dlangbot/cron.d#L60
 
 I'm not sure whether auto-closing them is a good idea, but we
 definitely need to do sth. about them.
 Also one year without any activity is a very long time.


 
 It’s not like we loose anything, we don’t delete code of the author.
 So should he/she find time - just create a new PR. Also these willing
 to dig in the closed PRs are free to do so (it’s just a couple of
 passes to add a filter to your search).


I used to think that it's OK to leave old PRs there, since they don't
actively cause harm.  But lately I'm changing my stance.  Having a PR
queue that's overly long conveys the wrong image to a potential
contributor.  Having PRs that are years old with no resolution is
discouraging to look at, and also a source of frustration to the
submitter, esp. when the change is not especially complicated.

So nowadays I'm inclined to suggest that if a PR hasn't had any response
from the submitter for, say, 2-3 months, it should be closed with a
comment to resubmit if the submitter still feels strongly about it. Note
that I'm measuring this by activity *from the submitter*; I don't think
it's a good idea to close a PR if the submitter is waiting for somebody
from the team to respond.  That would send the completely wrong message.

So I'd suggest that if a PR has had no activity from the submitter for,
say, 2 weeks, then send a ping. At the 1 month mark, send another ping.
At the 2 month mark, close it with a note to reopen if the submitter
later decides to work on it again.

If a PR has had no activity from the team for 1 week, then the onus is
upon us to do something about it.  I'm not sure what to do when the
reason is that none of the active team members feel qualified to handle
the proposed change.  For example, if the PR touches some numerical
algorithms, I would hesitate to review it, because of lack of expertise
in the area.  I guess this is where the lack of consistent talent is a
big liability: if the go-to person for a particular area isn't active,
or only rarely active, or just too busy, then there's really not much we
can reasonably do about it.  Perhaps one small thing that might help is
to acknowledge the PR, or take initiative to actively ping the go-to
person until he responds.  At the very least, this would send the right
message that the team cares about the contribution, but just doesn't
have the resources right now to deal with it yet.

Alternatively, and this is just a wild idea off the top of my head, if
the go-to person doesn't respond by X days (where X is some fixed number
we agree on), a non-expert team member can do a code-level review (i.e.,
check for obvious glaring problems, check for basic code sanity) and
then merge the PR.  Worse comes to worst, the revert button's always
there.  This has to be done with care, though.  Definitely should not be
done prior to an imminent release, so that we don't introduce problems
that are hard to fix later; but perhaps early in the release cycle it
might be OK, under the assumption that any obvious problem would
manifest itself sometime before the next release, and the PR can be
reverted if necessary.  But even then, we might need to mark certain
types of changes as off-limits, e.g., if they would be too disruptive,
or fundamentally changes the way things work with unknown consequences.
Ultimately, though, this is just a crutch in the face of lack of the
right talents to do a proper review.  Anyway, this is just a rough idea
that may hopefully lead to a better one.


T

-- 
"Computer Science is no more about computers than astronomy is about
telescopes." -- E.W. Dijkstra
Jan 04 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2018 9:44 AM, Jack Stouffer wrote:

 DMD also has at least 30 PRs which have had no action from the author in over
a 
 year. There's no reason these should be kept open; they just take up
auto-tester 
 resources and lower the signal to noise ratio.
 
 If the author comes back later, they can always ask a maintainer to reopen.


I can't agree with the "just close older bugs and PRs." There's good stuff in 
them. Even if the PR is no good, it provides insight to someone working on a 
better fix. Closing it means nobody will ever be aware of it or look at it
again.

Relying on the original author to revive it will not work.

It's similar with older bugs. They still have discussion on them that 
contributes valuable information and insight to anyone wishing to work on it. 
Closing them with no action means the information is all lost.

As for autotester resources, it should be easy enough to have it skip testing 
any PRs that have had no activity for XXX days.

I don't believe "Logan's Run" makes a good foundation for a functioning QA
system.
Jan 04 2018
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 5 January 2018 at 04:26:25 UTC, Walter Bright wrote:

 I can't agree with the "just close older bugs and PRs." There's 
 good stuff in them. Even if the PR is no good, it provides 
 insight to someone working on a better fix. Closing it means 
 nobody will ever be aware of it or look at it again.

 Relying on the original author to revive it will not work.

 It's similar with older bugs. They still have discussion on 
 them that contributes valuable information and insight to 
 anyone wishing to work on it. Closing them with no action means 
 the information is all lost.

 As for autotester resources, it should be easy enough to have 
 it skip testing any PRs that have had no activity for XXX days.

 I don't believe "Logan's Run" makes a good foundation for a 
 functioning QA system.


+1

A perfect project would be able to make quick decisions on PRs, 
but that doesn't mean closing PRs makes a better project. It's a 
little bit cargo-culty.
Jan 05 2018
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/5/18 5:08 AM, John Colvin wrote:

 On Friday, 5 January 2018 at 04:26:25 UTC, Walter Bright wrote:

 I can't agree with the "just close older bugs and PRs." There's good 
 stuff in them. Even if the PR is no good, it provides insight to 
 someone working on a better fix. Closing it means nobody will ever be 
 aware of it or look at it again.

 Relying on the original author to revive it will not work.

 It's similar with older bugs. They still have discussion on them that 
 contributes valuable information and insight to anyone wishing to work 
 on it. Closing them with no action means the information is all lost.

 As for autotester resources, it should be easy enough to have it skip 
 testing any PRs that have had no activity for XXX days.

 I don't believe "Logan's Run" makes a good foundation for a 
 functioning QA system.


 
 +1
 
 A perfect project would be able to make quick decisions on PRs, but that 
 doesn't mean closing PRs makes a better project. It's a little bit 
 cargo-culty.


Does anyone know how the statuses RESOLVED/LATER and RESOLVED/REMIND are 
usually employed? Thanks! -- Andrei
Jan 05 2018
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 5 January 2018 at 10:08:11 UTC, John Colvin wrote:

 A perfect project would be able to make quick decisions on PRs, 
 but that doesn't mean closing PRs makes a better project. It's 
 a little bit cargo-culty.


For my projects, even if a PR isn't perfect, unless it is just 
plain bad or goes in a direction I strongly disagree with, I'll 
merge it anyway pretty quickly and just fix up the bits I don't 
like later myself.

So if something is OK but not great.... don't close it, merge it! 
Just fix it up after and leave a note for the original PR author 
showing your fixup commit so they can learn from it next time.
Jan 05 2018
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/5/18 9:26 AM, Adam D. Ruppe wrote:

 On Friday, 5 January 2018 at 10:08:11 UTC, John Colvin wrote:

 A perfect project would be able to make quick decisions on PRs, but 
 that doesn't mean closing PRs makes a better project. It's a little 
 bit cargo-culty.


 
 For my projects, even if a PR isn't perfect, unless it is just plain bad 
 or goes in a direction I strongly disagree with, I'll merge it anyway 
 pretty quickly and just fix up the bits I don't like later myself.
 
 So if something is OK but not great.... don't close it, merge it! Just 
 fix it up after and leave a note for the original PR author showing your 
 fixup commit so they can learn from it next time.


You can actually change it first before merging as a repo owner.

-Steve
Jan 05 2018
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2018 6:26 AM, Adam D. Ruppe wrote:

 For my projects, even if a PR isn't perfect, unless it is just plain bad or
goes 
 in a direction I strongly disagree with, I'll merge it anyway pretty quickly
and 
 just fix up the bits I don't like later myself.
 
 So if something is OK but not great.... don't close it, merge it! Just fix it
up 
 after and leave a note for the original PR author showing your fixup commit so 
 they can learn from it next time.


The compiler is far too complex for that. It increases the technical debt.

I have pulled many PRs like that, and they've just resulted in regressions and 
even more work for me to do.
Jan 05 2018
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Friday, 5 January 2018 at 04:26:25 UTC, Walter Bright wrote:

 On 1/4/2018 9:44 AM, Jack Stouffer wrote:

 DMD also has at least 30 PRs which have had no action from the 
 author in over a year. There's no reason these should be kept 
 open; they just take up auto-tester resources and lower the 
 signal to noise ratio.
 
 If the author comes back later, they can always ask a 
 maintainer to reopen.


 I can't agree with the "just close older bugs and PRs." There's 
 good stuff in them. Even if the PR is no good, it provides 
 insight to someone working on a better fix. Closing it means 
 nobody will ever be aware of it or look at it again.


Sure, by surfing through 100-s of stalled PRs among real active 
work.

Somebodies archive currently is a burndown list of others. That 
can’t be good and is highly frustrating.

What I’m saying is that closing PR doesn’t evaporate it. Mark as 
stalled and close.
If someone is on treasure hunting, just click closed PRs and add 
‘stalled’ tag to search.


 Relying on the original author to revive it will not work.


Then by definition PR won’t get merged in the first place. It 
takes a fair amount of motivation and busy work by author even 
when all is good.

If we can’t merge it, why keep it around as OPEN?


 It's similar with older bugs. They still have discussion on 
 them that contributes valuable information and insight to 
 anyone wishing to work on it. Closing them with no action means 
 the information is all lost.


Piling them in bugzilla has the same downside - actionable items 
are intermingled with some “archived” and largely irrelevant 
non-actionable stuff. Bugzilla is though a lost case, so I will 
not suggest to move anything there.
Jan 09 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2018 2:34 AM, Mike Franklin wrote:

 Walter seems to pop in daily, and occasionally reviews PRs, and his PRs of
late 
 are mostly just refactorings rather than fixing difficult bugs.


There's a lot of technical debt I've been trying to fix with that, and nobody 
else seems willing to do it. For example, fixing the error messages so they
make 
use of color syntax highlighting. It's boring, tedious, unfun work, meaning I 
get to do it :-)

Another issue is I've had the flu for a while which makes me tired, and then 
it's best to work on things that don't require much mental energy.

(Yes, I got the flu shot, and the durned thing did not work.)
Jan 04 2018
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote:


 There's a lot of technical debt I've been trying to fix with 
 that, and nobody else seems willing to do it. For example, 
 fixing the error messages so they make use of color syntax 
 highlighting. It's boring, tedious, unfun work, meaning I get 
 to do it :-)


If you have simple, mundane work that needs to be done, make a 
list and send it my way; you should have my e-mail address.  But 
please be specific; "fix error messages" is just going to get a 
reply from me asking questions.

Mike
Jan 04 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2018 7:41 PM, Mike Franklin wrote:

 If you have simple, mundane work that needs to be done, make a list and send
it 
 my way; you should have my e-mail address.  But please be specific; "fix
error 
 messages" is just going to get a reply from me asking questions.


Ok, fix error messages, like you've seen me doing already. To find which files 
need work,

     grep "error(" *.d

does the trick, turning up:

ctfeexpr.d
dimport.d
dinterpret.d
dscope.d
e2ir.d
expression.d
expressionsem.d
func.d
glue.d
iasm.d
mtype.d
nogc.d
nspace.d
opover.d
optimize.d
s2ir.d

as needing ` `. There's a lot of work just there :-( It's best to resist the 
urge to do more than just add in ` ` where they are obviously appropriate.
Don't 
make perfection the enemy of better. I've found it best to have only one PR for 
this at a time, otherwise it's a lot of extra work rebasing.

A longer term goal is to find ways to refactor the code to make maximum use of 
pure, const, scope, and nothrow.

I appreciate any and all help with this.
Jan 04 2018
parent reply Seb <seb wilzba.ch> writes:
On Friday, 5 January 2018 at 04:20:06 UTC, Walter Bright wrote:

 On 1/4/2018 7:41 PM, Mike Franklin wrote:

 If you have simple, mundane work that needs to be done, make a 
 list and send it my way; you should have my e-mail address.  
 But please be specific; "fix error messages" is just going to 
 get a reply from me asking questions.


 Ok, fix error messages, like you've seen me doing already. To 
 find which files need work,

     grep "error(" *.d

 does the trick, turning up:

 ctfeexpr.d
 dimport.d
 dinterpret.d
 dscope.d
 e2ir.d
 expression.d
 expressionsem.d
 func.d
 glue.d
 iasm.d
 mtype.d
 nogc.d
 nspace.d
 opover.d
 optimize.d
 s2ir.d

 as needing ` `. There's a lot of work just there :-( It's best 
 to resist the urge to do more than just add in ` ` where they 
 are obviously appropriate. Don't make perfection the enemy of 
 better. I've found it best to have only one PR for this at a 
 time, otherwise it's a lot of extra work rebasing.

 A longer term goal is to find ways to refactor the code to make 
 maximum use of pure, const, scope, and nothrow.

 I appreciate any and all help with this.


We should put things like this somewhere where it can easily be 
seen by others.
The obvious candidates are the Wiki and Bugzilla, but both have 
historically proven to yield poor results, e.g.

https://wiki.dlang.org/Get_involved#Contribute_to_the_DMD_and_DRuntime

So let's try something new:

https://github.com/dlang/dmd/projects/2


Note that GitHub supports two labels for issues: "help wanted" 
and "good first issue" and provides many interfaces that let 
interested people discover such issues.
For details:

https://help.github.com/articles/finding-open-source-projects-on-github/
https://github.com/nodejs/admin/issues/20
https://github.com/showcases/great-for-new-contributors (<- Rust 
appears here)
...

Of course this only works for GitHub issues.
Jan 05 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2018 7:39 AM, Seb wrote:

 We should put things like this somewhere where it can easily be seen by others.
 The obvious candidates are the Wiki and Bugzilla, but both have historically 
 proven to yield poor results, e.g.


Sigh. Bugzilla is the answer, and lots of people do troll Bugzilla looking for 
things to do. Adding another list somewhere else is not going to improve things.

What's needed (from my perspective) is more people doing quality work. Not more 
process.

Mike Franklin is a standout here. He's actually going through the files I
listed 
and has already posted several PRs doing the modifications. That is what we
need.

--------------

Now, in my work highlighting error messages, I noticed that a number of them 
could be made better by relying less on compiler jargon and having a bit more 
exposition on what the problem is.

For example, there were several uses of the word 'ctor' instead of 
'constructor'. There are also uses of 'aggregate' instead of 'struct, union or 
class'.

These kind of improvements cannot be done en masse, because someone has to look 
at each specific message, the context which will generate it, and think about 
how better to express this to the user. A good message will present the
context, 
what is wrong, and perhaps suggest corrective action.

Some messages are generic for a diverse collection of actual errors, and should 
be broken out into different messages for each error.

This has been done already for many messages, such as the ones where I added 
spell checking so the message could suggest what might have been meant instead, 
but there are an awful lot of messages in the compiler which are workmanlike, 
but are a bit abrupt.
Jan 05 2018
next sibling parent rjframe <dlang ryanjframe.com> writes:
On Fri, 05 Jan 2018 18:53:38 -0800, Walter Bright wrote:


 On 1/5/2018 7:39 AM, Seb wrote:

 We should put things like this somewhere where it can easily be seen by
 others.
 The obvious candidates are the Wiki and Bugzilla, but both have
 historically proven to yield poor results, e.g.


 
 Sigh. Bugzilla is the answer, and lots of people do troll Bugzilla
 looking for things to do. Adding another list somewhere else is not
 going to improve things.


Note that Andrei (I think) set up a "bootcamp"[1] keyword on bugzilla for 
easy issues a while back; the problem has been solved though maybe not 
advertised consistently. The wiki's "Get Involved" page includes a link to 
preapproved and bootcamp issues. CONTRIBUTING.md also links to it - maybe 
it's just on the forums nobody talks about it...


[1]: https://issues.dlang.org/buglist.cgi?
component=dmd&keywords=bootcamp&product=D
Jan 06 2018
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 6 January 2018 at 02:53:38 UTC, Walter Bright wrote:


 For example, there were several uses of the word 'ctor' instead 
 of 'constructor'.


I couldn't find any cases like that.  If you know of them, please 
explicitly identify them for me.

Thanks,
Mike
Jan 09 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/9/2018 6:53 PM, Mike Franklin wrote:

 I couldn't find any cases like that.  If you know of them, please
 explicitly identify them for me.


I already fixed them.
Jan 12 2018
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/4/18 10:28 PM, Walter Bright wrote:

 (Yes, I got the flu shot, and the durned thing did not work.)


I had a flu shot once in my adult life. Never been sicker. Won't ever 
get it again.

-Steve
Jan 04 2018
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 5 January 2018 at 04:14:57 UTC, Steven Schveighoffer 
wrote:

 On 1/4/18 10:28 PM, Walter Bright wrote:

 (Yes, I got the flu shot, and the durned thing did not work.)


 I had a flu shot once in my adult life. Never been sicker. 
 Won't ever get it again.


The only people I ever saw with a flu (I mean a real influenza) 
had all one thing in common: they all had gotten the flu shot.
Jan 04 2018
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 5 January 2018 at 06:20:54 UTC, Patrick Schluter wrote:

 The only people I ever saw with a flu (I mean a real influenza) 
 had all one thing in common: they all had gotten the flu shot.


That's a case of selection bias: the people who get the shot tend 
to be those who are already at high risk of getting the flu.

The shots cover common strains - or at least what they think will 
be common strains - but they don't cover all of them. So consider 
the math: let's say you judge yourself to have a 20% chance of 
getting the flu, so you get the shot. It cuts your odds by about 
50%... but that still leaves you with a 10% chance of getting one 
of the other strains.

The general population, on average, has about a 5% chance of 
catching the flu... so even with the shot, you, in the very 
high-risk pool to begin with, are still more likely to get it 
than the average person, but that doesn't mean the shot was 
ineffective, and, of course, it certainly doesn't mean the shot 
CAUSED it.
Jan 05 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/5/18 9:39 AM, Adam D. Ruppe wrote:

 On Friday, 5 January 2018 at 06:20:54 UTC, Patrick Schluter wrote:

 The only people I ever saw with a flu (I mean a real influenza) had 
 all one thing in common: they all had gotten the flu shot.


 
 That's a case of selection bias: the people who get the shot tend to be 
 those who are already at high risk of getting the flu.


Flu shots are relentlessly promoted, and usually free. People get them 
because they think they should, not necessarily because they are at high 
risk.


 
 The shots cover common strains - or at least what they think will be 
 common strains - but they don't cover all of them. So consider the math: 
 let's say you judge yourself to have a 20% chance of getting the flu, so 
 you get the shot. It cuts your odds by about 50%... but that still 
 leaves you with a 10% chance of getting one of the other strains.
 
 The general population, on average, has about a 5% chance of catching 
 the flu... so even with the shot, you, in the very high-risk pool to 
 begin with, are still more likely to get it than the average person, but 
 that doesn't mean the shot was ineffective, and, of course, it certainly 
 doesn't mean the shot CAUSED it.


I don't know what caused it. I'm not at high risk, I never get the flu. 
I only got the shot because I had a baby and my wife cajoled me into it 

says "it's because I got the stupid shot". Note that I got sick pretty 
much right after the shot.

But there is also selective bias on the other side. If someone gets the 
flu and *hadn't* got a shot, there's a bunch of tut-tutting going on 
around them.

In any case, I still will not get one and probably won't until I'm in a 
nursing home and they make me :)

-Steve
Jan 05 2018
next sibling parent Russel Winder <russel winder.org.uk> writes:
Most people who say they have flu, do not have flu, they just have a
cold.

The flu jab does cause some people to have the appearance of a cold
immediately afterwards. For most there is no affect.

I have asthma, I get the flu jab. I still get colds, some occasionally
require anti-biotics because the cold has allowed a bacterial infection
to get into my lungs. Flu would be much worse. I don't want flu. Having
the flu jab is a zero loss situation.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Jan 05 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 05, 2018 at 10:00:18AM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
[...]

 I don't know what caused it. I'm not at high risk, I never get the
 flu. I only got the shot because I had a baby and my wife cajoled me

 internal bias says "it's because I got the stupid shot". Note that I
 got sick pretty much right after the shot.


It is likely just symptoms caused by your body's reaction to the shot,
not the actual virus. In all likelihood, these symptoms are much milder
than what you'd get from the real virus.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. --
Christopher
Jan 05 2018
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/5/18 10:11 AM, H. S. Teoh wrote:

 On Fri, Jan 05, 2018 at 10:00:18AM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
 [...]

 I don't know what caused it. I'm not at high risk, I never get the
 flu. I only got the shot because I had a baby and my wife cajoled me

 internal bias says "it's because I got the stupid shot". Note that I
 got sick pretty much right after the shot.


 
 It is likely just symptoms caused by your body's reaction to the shot,
 not the actual virus. In all likelihood, these symptoms are much milder
 than what you'd get from the real virus.


Haha, again, never been sicker :) I think it took me a month to get over 
it. But it doesn't mean that my experience justifies people who are at 
higher risk not getting the shot. I'm just not sure the insane push for 
EVERYONE to get the shot is really worth it.

-Steve
Jan 05 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2018 7:00 AM, Steven Schveighoffer wrote:

 In any case, I still will not get one and probably won't until I'm in a
nursing 
 home and they make me :)


You can get the flu and not show symptoms, and infect the people you're around. 
The elderly can die from the fule. The shot is free and a pinprick, I see no 
upside to avoiding it.
Jan 05 2018
parent codephantom <me noyb.com> writes:
On Saturday, 6 January 2018 at 02:58:44 UTC, Walter Bright wrote:

 On 1/5/2018 7:00 AM, Steven Schveighoffer wrote:

 In any case, I still will not get one and probably won't until 
 I'm in a nursing home and they make me :)


 You can get the flu and not show symptoms, and infect the 
 people you're around. The elderly can die from the fule. The 
 shot is free and a pinprick, I see no upside to avoiding it.


Yes, in Australia recently, we had a large number of elderly 
people in nursing homes die from the flu.

http://www.abc.net.au/news/2017-09-12/flu-deaths-rise-as-treatment-medication-runs-dry/8895230

A flu shot can mean the difference between life and death for 
many of these people.

Our government is introducing legislation that makes it 
compulsory for workers in aged-care, to get a flu shot. (although 
not compulsory for those just visiting ??)

http://www.health.gov.au/internet/ministers/publishing.nsf/Content/health-mediarel-yr2017-hunt090.htm

I think that air-borne viruses are the biggest threat to 
humanity, and will probably be the thing that wipes us out.
Jan 05 2018
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2018 10:20 PM, Patrick Schluter wrote:

 The only people I ever saw with a flu (I mean a real influenza) had all one 
 thing in common: they all had gotten the flu shot.


There was a 3 month gap between the shot and getting the flu, so there's no 
credible connection. I haven't gotten the flu in other years when I got the 
shot, even when unshot others were felled all around me :-)

I'm certainly going to continue getting the annual shot. I just rolled the dice 
this year and lost.
Jan 05 2018
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote:

 On 1/4/2018 2:34 AM, Mike Franklin wrote:

 Walter seems to pop in daily, and occasionally reviews PRs, 
 and his PRs of late are mostly just refactorings rather than 
 fixing difficult bugs.


 There's a lot of technical debt I've been trying to fix with 
 that, and nobody else seems willing to do it. For example, 
 fixing the error messages so they make use of color syntax 
 highlighting. It's boring, tedious, unfun work, meaning I get 
 to do it :-)

 Another issue is I've had the flu for a while which makes me 
 tired, and then it's best to work on things that don't require 
 much mental energy.

 (Yes, I got the flu shot, and the durned thing did not work.)


the flu is nothing to sneeze at, at your age..

or mine for that matter ;-(

take it easy and recover!
Jan 04 2018
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote:

 Another issue is I've had the flu for a while which makes me 
 tired, and then it's best to work on things that don't require 
 much mental energy.


I quess that applies easily twice as strongly if you code bigger 
things on the run, no? :D
Jan 05 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 04, 2018 at 07:28:10PM -0800, Walter Bright via Digitalmars-d wrote:

 On 1/4/2018 2:34 AM, Mike Franklin wrote:

 Walter seems to pop in daily, and occasionally reviews PRs, and his
 PRs of late are mostly just refactorings rather than fixing
 difficult bugs.


 There's a lot of technical debt I've been trying to fix with that, and
 nobody else seems willing to do it. For example, fixing the error
 messages so they make use of color syntax highlighting. It's boring,
 tedious, unfun work, meaning I get to do it :-)


[...]

I'm sad that it has to fall upon Walter to do these routine, mundane,
tedious work, when we greatly need his expertise elsewhere in D land.
Walter, what about posting a list of boring, tedious stuff that has
landed on your plate somewhere, so that those of us looking for
something to do can pick it up?


T

-- 
Stop staring at me like that! It's offens... no, you'll hurt your eyes!
Jan 05 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2018 7:41 AM, H. S. Teoh wrote:

 I'm sad that it has to fall upon Walter to do these routine, mundane,
 tedious work, when we greatly need his expertise elsewhere in D land.
 Walter, what about posting a list of boring, tedious stuff that has
 landed on your plate somewhere, so that those of us looking for
 something to do can pick it up?


I posted some in reply to Mike in this thread. Mike has taken up the cudgel and 
is submitting a flurry of PRs! :-)

Here's more:

1. try to reduce dependency of code on global variables

2. add missing/inadequate/incomplete Ddoc comments to functions

3. each source file now has a direct link at the top to the coverage report for 
it. Devise additions to the test suite to improve coverage
Jan 05 2018
prev sibling next sibling parent reply Random D user <no email.com> writes:
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote:

 On 1/4/2018 2:34 AM, Mike Franklin wrote:

 Walter seems to pop in daily, and occasionally reviews PRs, 
 and his PRs of late are mostly just refactorings rather than 
 fixing difficult bugs.


 There's a lot of technical debt I've been trying to fix


While not directly applicable to 'technical debt', has anyone 
ever written a fuzzer for dmd?

Basically a testing software that generates valid or almost valid 
(negative case) input (code using grammar rules) and tries to run 
it through the application (compiler) to see what happens. These 
things usually reveal tons of easy to fix bugs at the application 
interface level and some hard to fix corner cases that no one 
thought. Best of all, you will get easy to use test cases that 
some else can try to fix. Unfortunately fuzzers often get stuck 
in local maximums, so you need to spend some time with app 
coverage using the generated data and modify the fuzzer 
accordingly. But once it has been built and it tests large code 
coverage, it's an awesome tool to reveal bugs and test changes. 
Just make a change, run tests, run fuzzer for 5-15 mins, 1h or 
days if you want extra coverage.

I think there's also a variant of this that takes valid code and 
replace existing code constructs with equivalent but unusual 
constructs.
Jan 07 2018
next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 7 January 2018 at 17:52, Random D user via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote:

 On 1/4/2018 2:34 AM, Mike Franklin wrote:

 Walter seems to pop in daily, and occasionally reviews PRs, and his PRs
 of late are mostly just refactorings rather than fixing difficult bugs.


 There's a lot of technical debt I've been trying to fix



 While not directly applicable to 'technical debt', has anyone ever written a
 fuzzer for dmd?


Yes, its called Defuzzed.
Jan 07 2018
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 7 January 2018 at 16:52:55 UTC, Random D user wrote:

 While not directly applicable to 'technical debt', has anyone 
 ever written a fuzzer for dmd?


Johan Engelen has used LLVM libFuzzer on it.
Jan 09 2018
parent reply Johan Engelen <j j.nl> writes:
On Wednesday, 10 January 2018 at 05:46:04 UTC, Nicholas Wilson 
wrote:

 On Sunday, 7 January 2018 at 16:52:55 UTC, Random D user wrote:

 While not directly applicable to 'technical debt', has anyone 
 ever written a fuzzer for dmd?


 Johan Engelen has used LLVM libFuzzer on it.


And I've been working for a long time on a fuzzing article. It's 
almost done!

- Johan
Jan 11 2018
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 01/11/2018 02:15 PM, Johan Engelen wrote:


 And I've been working for a long time on a fuzzing article. It's almost 
 done!
 
 - Johan
 


A fuzzy font would suit that article. :o)

Ali
Jan 12 2018
prev sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote:


 There's a lot of technical debt I've been trying to fix with 
 that, and nobody else seems willing to do it. For example, 
 fixing the error messages so they make use of color syntax 
 highlighting. It's boring, tedious, unfun work, meaning I get 
 to do it :-)

 Another issue is I've had the flu for a while which makes me 
 tired, and then it's best to work on things that don't require 
 much mental energy.

 (Yes, I got the flu shot, and the durned thing did not work.)


Afaik, the flu shot only covers those viruses that are arlready 
known to scientists (which only makes sense). Since the darn 
things keep mutating all the time, we have to deal with new 
strains every year. So one could argue that the flu shots are 
only of limited usefulness. Maybe a new strain attacked you, and 
maybe, consciously or subconsciously, people who got the shot 
behave more carelessly, (wrongly) assuming that they are immune 
to the flu.
Jan 22 2018