www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why isn't dip1000 fully implemented yet?

reply 12345swordy <alexanderheistermann gmail.com> writes:
Or rather more importantly why haven't this pull request been 
reviewed yet?
https://github.com/dlang/dlang.org/pull/2453

It been documented already, just review it and merge it. I 
literately can't find the words to describe the unnecessarily 
stubbornness being displayed without came across as 
unprofessional.

The work has been done! Just review it and merge it! I don't what 
to do, other then to beg here.

-Alex
Nov 19 2018
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:

 Or rather more importantly why haven't this pull request been 
 reviewed yet?
 https://github.com/dlang/dlang.org/pull/2453

 It been documented already, just review it and merge it. I 
 literately can't find the words to describe the unnecessarily 
 stubbornness being displayed


Join the club!


 without came across as unprofessional.


Been there, done that.


 The work has been done! Just review it and merge it!


IKR, unfortunately only Walter or Andrei can do that because only 
they understand DIP1000, and unfortunately Walter has ignored 
almost all attempts to communicate this, except once recently to 
the tune of "thanks for doing something about this rather than 
complaining about it, but no thanks because [insert some 
bureaucratic reason]" which raised the ire of quite a number of 
people.


 I don't what to do, other then to beg here.


Done that too.
Nov 19 2018
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:

 Or rather more importantly why haven't this pull request been 
 reviewed yet?
 https://github.com/dlang/dlang.org/pull/2453


I really want to know too! He's been pushing for DIP1000 so hard, 
yet doesn't leave even a single post to co-operate when people 
are helping.

It might be that he doesn't have time for reviewing, or that 
DIP1000 is still moving too fast to properly document, but that's 
hard to imagine since he has already prepared and given two 
presentations at DConf about the very topic.

Walter, whatever the reason for this is, at least you need to say 
it! Otherwise, people don't know what to do, and demoralize a LOT.
Nov 20 2018
parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 20 November 2018 at 15:40:00 UTC, Dukc wrote:

 but that's hard to imagine since he has already prepared and 
 given two presentations at DConf about the very topic.


Remembered wrong. One. But the point stands.
Nov 20 2018
prev sibling next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:

 Just review it and merge it! I don't what to do, other then to 
 beg here.


I completely agree.
Nov 21 2018
prev sibling next sibling parent Bauss <jj_1337 live.dk> writes:
On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:

 Or rather more importantly why haven't this pull request been 
 reviewed yet?
 https://github.com/dlang/dlang.org/pull/2453

 It been documented already, just review it and merge it. I 
 literately can't find the words to describe the unnecessarily 
 stubbornness being displayed without came across as 
 unprofessional.

 The work has been done! Just review it and merge it! I don't 
 what to do, other then to beg here.

 -Alex


Please. It feels like it has been forever since it was first 
proposed.
Nov 21 2018
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:

 The work has been done! Just review it and merge it! I don't 
 what to do, other then to beg here.


People are different and have different goals of their 
development with D. In my experience, the only productive way 
forward is to encourage, reward and help out. And that not only 
with the things you are interested in. Walter has recently been 
swamped and very productive with porting the backend to DMD which 
is a great step forward that's gonna reduce many bugs in the long 
run. Walter likes bugzilla. If you add things there and send him 
the ref he will sooner or later do something about it. He has 
fixed bugs regarding dip1000 I have filed there. If you start 
asking people what they need help with, the chance of DIP-1000 
getting in is gonna increase.

Ask not what D can do for you, but
What You can do for D.

/Per
Nov 22 2018
parent reply Daniel N <no public.email> writes:
On Thursday, 22 November 2018 at 08:44:10 UTC, Per Nordlöw wrote:

 On Tuesday, 20 November 2018 at 02:43:11 UTC, 12345swordy wrote:

 The work has been done! Just review it and merge it! I don't 
 what to do, other then to beg here.


 People are different and have different goals of their 
 development with D. In my experience, the only productive way 
 forward is to encourage, reward and help out. And that not only 
 with the things you are interested in. Walter has recently been 
 swamped and very productive with porting the backend to DMD 
 which is a great step forward that's gonna reduce many bugs in 
 the long run. Walter likes bugzilla. If you add things there 
 and send him the ref he will sooner or later do something about 
 it. He has fixed bugs regarding dip1000 I have filed there. If 
 you start asking people what they need help with, the chance of 
 DIP-1000 getting in is gonna increase.

 Ask not what D can do for you, but
 What You can do for D.

 /Per


I believe the real issue is that...
https://github.com/dlang/dmd/pull/8504
... has not been merged.

If Walters fix is approved the spec can be merged directly 
afterwards.

The first parameter, like it or not, has special status in many 
situations, ex:
* implicit this
* properties
* chaining UFCS

Now Walter wants to add a 4th item to this list, someone either 
needs to approve it or come up with a better idea, otherwise we 
won't get anywhere, I for one would happily approve it but I 
obviously don't have the authority to do so.

If an entirely different solution is chosen, then this spec pull 
would document something which never even existed, that's why 
it's key to pull 8504 first imho, as then the semantics is 
cemented.
Nov 22 2018
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 22 November 2018 at 09:05:59 UTC, Daniel N wrote:

 I believe the real issue is that...
 https://github.com/dlang/dmd/pull/8504
 ... has not been merged.

 If Walters fix is approved the spec can be merged directly 
 afterwards.

 The first parameter, like it or not, has special status in many 
 situations, ex:
 * implicit this
 * properties
 * chaining UFCS

 Now Walter wants to add a 4th item to this list, someone either 
 needs to approve it or come up with a better idea, otherwise we 
 won't get anywhere, I for one would happily approve it but I 
 obviously don't have the authority to do so.

 If an entirely different solution is chosen, then this spec 
 pull would document something which never even existed, that's 
 why it's key to pull 8504 first imho, as then the semantics is 
 cemented.



round, for the sole reason that without knowing what it is 
supposed to do, it is impossible to review (the bugzilla issues 
are not helpful).


that walter has made and has chosen not to document (just 
recently I had to inform Razvan who is otherwise a very capable 
compiler developer what the situation was because there is no 
documentation), which makes the whole process even worse because 
the implementation bears less and less resemblance to the 
documentation and keeping track of interactions gets 
combinatorially more difficult, and when reviewers are faced with 
that they simply just do not review.
Nov 22 2018
parent reply Daniel N <no public.email> writes:
On Thursday, 22 November 2018 at 10:12:12 UTC, Nicholas Wilson 
wrote:


 round, for the sole reason that without knowing what it is 
 supposed to do, it is impossible to review (the bugzilla issues 
 are not helpful).


 dip1000 that walter has made and has chosen not to document 
 (just recently I had to inform Razvan who is otherwise a very 
 capable compiler developer what the situation was because there 
 is no documentation), which makes the whole process even worse 
 because the implementation bears less and less resemblance to 
 the documentation and keeping track of interactions gets 
 combinatorially more difficult, and when reviewers are faced 
 with that they simply just do not review.


"impossible to review" is a very strong statement, how then were 
you able to write the spec? I had no issues understanding what 
Walter meant both comments and the test cases speak for 
themselves, he also offered to answer any questions.

If there is any corner case which you don't understand, it would 
imho be more constructive to ask him to add a new test case for 

regressions prevented and coverage improved. It's very easy to 
misunderstand a written explanation, but code can only be 
interpreted one way. This is even more so for an international 
project where not everyone is a native English speaker.

In my world the spec/doc/changelog is just a release blocker for 
the next official external compiler release, but by all means 
merge them simultaneously, now that they both are available.
Nov 22 2018
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 22 November 2018 at 11:55:14 UTC, Daniel N wrote:

 "impossible to review" is a very strong statement, how then 
 were you able to write the spec?


I guessed, well, I wrote it the way I think what he has done 
ought to work.
Hence why Walter needs to review it.


 I had no issues understanding what Walter meant both comments 
 and the test cases speak for themselves, he also offered to 
 answer any questions.





 If there is any corner case which you don't understand, it 
 would imho be more constructive to ask him to add a new test 

 future regressions prevented and coverage improved. It's very 
 easy to misunderstand a written explanation, but code can only 
 be interpreted one way. This is even more so for an 
 international project where not everyone is a native English 
 speaker.

 In my world the spec/doc/changelog is just a release blocker 
 for the next official external compiler release, but by all 
 means merge them simultaneously, now that they both are 
 available.


The second issue at play is that there have been a number of 
undocumented changes to dip1000, and those changes were pulled on 
the understanding that it will be documented. That hasn't 
happened yet, and won't until Walter approves the documentation 
(it won't merge due to some weird LaTeX errors in the doc builder 
but that is beside the point).
Nov 22 2018
next sibling parent Daniel N <no public.email> writes:
On Thursday, 22 November 2018 at 12:32:30 UTC, Nicholas Wilson 
wrote:

 The second issue at play is that there have been a number of 
 undocumented changes to dip1000, and those changes were pulled 
 on the understanding that it will be documented. That hasn't 
 happened yet, and won't until Walter approves the documentation 
 (it won't merge due to some weird LaTeX errors in the doc 
 builder but that is beside the point).


Well, my proposal is that we instead are strict about 
documentation being hard release blockers for the next release.

That approach would facilitate core-devs to work efficiently in 
between releases, not wasting resources on rebasing multiple 
times for many months or years(looking at you multiple this).

It's much easier to rebase old docs, than to rebase old code 
commits when internal API:s were refactored.
Nov 22 2018
prev sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Thu, 22 Nov 2018 12:32:30 +0000, Nicholas Wilson wrote:

 On Thursday, 22 November 2018 at 11:55:14 UTC, Daniel N wrote:

 "impossible to review" is a very strong statement, how then were you
 able to write the spec?


 
 I guessed, well, I wrote it the way I think what he has done ought to
 work.
 Hence why Walter needs to review it.


In other words, you need the spec PR to demonstrate intent. The most you 
can get from reviewing the dmd PR is that the code does something that 
seems reasonable on the face of it and probably won't blow up in anyone's 
face too much.
Nov 22 2018
parent Daniel N <no public.email> writes:
On Thursday, 22 November 2018 at 16:35:15 UTC, Neia Neutuladh 
wrote:

 On Thu, 22 Nov 2018 12:32:30 +0000, Nicholas Wilson wrote:

 On Thursday, 22 November 2018 at 11:55:14 UTC, Daniel N wrote:

 "impossible to review" is a very strong statement, how then 
 were you able to write the spec?


 
 I guessed, well, I wrote it the way I think what he has done 
 ought to
 work.
 Hence why Walter needs to review it.


 In other words, you need the spec PR to demonstrate intent. The 
 most you can get from reviewing the dmd PR is that the code 
 does something that seems reasonable on the face of it and 
 probably won't blow up in anyone's face too much.


There is a big difference between:
a) Sorry, *I* am not able to review this but maybe someone else 
can?
b) Adding a Label which prevents everyone from reviewing/pulling.
(At least I normally don't even look at blocked work, since then 
PR probably needs to be updated in the future and then anyway 
reviewed once again...)
Nov 23 2018