On Thursday, 6 February 2020 at 16:26:43 UTC, berni44 wrote:
> Last week, I was quite disappointed when no one replied on my anouncement of a new website about D (meanwhile there are three replies, one negative, two positive, but it's somewhat too late). I'm also waiting for almost three months now for a review of my PRs concerning replacing sprintf (just doing thumbs up isn't enough). Together this made me quite sad.
>
> So I decided to stay away for a week to calm down and to have time to think about this. Finally I came to the conclusion, that I do not fit in this community. So I will leave.
>
> I kept all PRs open, because I think they are all ripe to be merged (there is one, where n8sh commented in the last week and his suggestions should be added), but I will neither care for them anymore. Close them, use them or continue to ignore them; I don't mind.
>
> Recently I was working on a complete rewrite of the documentation of std.format with some improvements, bug fixes and stuff. I added also unittests to verify the documentation. It's still work in progress, but it's about 80% finished. Again I will not continue work on this. But I uploaded it on github [1]. You can use it, if you like.
>
> Bye bye
>
> [1] https://github.com/berni44/phobos/blob/formatS/std/format.d

Hello Bernie,

From what I have seen you have been doing an excellent job and your skills and dedication would be missed. I really hope you would reconsider. You can be sure that the problem is not with you, nor that you "do not fit in the community", but just the lack of people with sufficient time and experience to review your work at a given moment.

From my observation it's really periods of high followed by low concentration of activity and responsiveness on GitHub. Sometimes you can be lucky and have stuff merged within hours or even minutes and sometimes it may take days, weeks, or even months. The only recipe for getting things in is:
- splitting your work on as small as possible chunks, so it can be reviewed more easily
- persistence
- pushing people from time to time ;)
- not taking things personal

even if no one chimes in on a PR of yours for long time, it's not because they don't like you or they don't think your work is important. It's most likely because no one was available at that time and unfortunately after a while PRs go under the radar if they stay without activity for a while. If that happens just ping people to remind them and eventually things will turn around.

I hope in the future we can do a better job as a community of respective contributors' time.

Thank you for your efforts, focus and persistence. I hope to see you around again!

All the best,
Petar

On Thursday, 6 February 2020 at 22:53:19 UTC, Petar Kirov [ZombineDev] wrote:
> I really hope you would reconsider.

Mixed feelings currently. Today the %e-PR was merged. I don't know if that is a coincidence (as I never have seen Nicholas Wilson posting anything in the forum) or just because of my posting here. Anyway, I decided to remove the merge conflicts of the %f-PR, as this is for me a matter of some minutes while others might need long to understand what's going on.

I've been thinking a lot on this today, and I still came to no conclusion. A few things, that crossed my mind:

On Thursday, 6 February 2020 at 20:29:31 UTC, Walter Bright wrote:
> This one is always going to be a tough one:
>
> https://github.com/dlang/phobos/pull/7264

Yes, that's the one I'm talking about.

> Floating point code is extremely difficult to get right, and
> contains a lot of very subtle traps for the unwary.

The nice thing about this is, that it has almost nothing to do with floating point. The first step is to copy the floating point bit patterns to ulong (if ucent where available, the algorithm could also be used for reals by the way), and from there on it's integer arithmetics with the expression a * 2^^b. The difficult thing is to get the mix of all the flags, precission, width and rounding right.

> If there's a mistake in it that subtly breaks someone's floating point code, it would cause them to not trust
> D. Just finding someone capable of reviewing it thoroughly
> would be very difficult for any community.

I question this a little bit. Not, that it would not be nice to have such reviewers. But I fear we do not have them and so an other way of dealing with such PRs is needed. Here, for example, one could run test scripts comparing the output of snprintf with the new function. This is something one could do, without understanding the details of the function. (I even provided several such test script, which I used myself to find corner cases I got wrong, when implementing.) Doing this for say 24h without finding any difference (other than the fixed bugs), would be a high evidence that the code has no bugs.

> One thing you can do when things are being overlooked is to get
> behind and push. I often do that - people don't just pull
> things because I wrote them.

This is something I quite dislike. Maybe it's my personality - I often feel importunate, when doing so.

On Thursday, 6 February 2020 at 17:35:36 UTC, H. S. Teoh wrote:
> Honestly, if it were up to me, I'd add you to the Phobos team.

I didn't even know that such a team exists... Maybe it would indeed help to be in such a team, because I'd have some people I can ask without the need to discuss everything here in the forum. On the other hand I'm not sure if being added to such a team comes with expectations I cannot meet...

On Thursday, 6 February 2020 at 17:47:14 UTC, Jonathan Marler wrote:
> Unfortunately, there's not much you or I can do, it's in the
> hands of the leadership.

Again: I even don't know exactly who this is. OK, Walter, that's clear. And I could guess a few others - Mike, Atila, Nicholas, Vladimir and Andrei come to my mind (and the foundation page list Ali too).

Maybe it would be a good thing to have some overview about the teams and groups somewhere.

On Thursday, 6 February 2020 at 17:24:52 UTC, Les De Ridder wrote:

> Also, while the core issue here may not have an obvious solution, we
> should make sure we don't worsen it by arbitrarily closing old/'stale'
> issues or PRs. Some open-source projects have recently fallen into this
> trap, e.g. by using a GitHub bot to automatically close old issues
> and/or PRs, which is confusing for users and discouraging for
> contributors.

I would actally recommend to close old PRs. I allready thought about going through all the old PRs and checking if anything of them can still be used. I think, this would considerably reduce the amount of open PRs and make it less likely, that PRs are missed.

But of course, this should not be done by a bot. At least, before closing an issue, a thorough statement, why this is closed, should be given. For example

https://github.com/dlang/phobos/pull/7297

is IMHO a candidate to be closed. I gave a statement there where I pointed out, why this PR would worsen the result of the pow function. Actually, this PR even shows, that the x^^-2 special case should be removed too, which has the same problem (and maybe the x^^2 special case too, which is not of a problem, but IMHO completely unnecessary, because the general case is doing identical calculations). So finally, that PR helps to improve this function, though not the way it was originally intended. But maybe, this is some sort of consolation for the PRs author.


And some other things that crossed my mind and where not touched by your replies:

* Recently the testers had a lot of false positives, mainly because of missing internet. That doesn't feel good. The PRs get red for no real reason and I've got no real means to do anything about it. Just rebase and push, rebase and push, ..., but I do not want to do that all the time. Maybe the missing internet errors could be caught and the result of the tests postponed somehow? I have no experience with this, so I cannot say, if this is lot of work or simple to implement. Just a suggestion.

* Labels. I havn't found a way to add labels to my PR. I guess, I just can't. Some of them would be helpful, especially WIP (and auto-merge ;-) ). Maybe the bot could recognise +WIP and -WIP and just add and remove this label.

* IMHO there are too many DIPs. If it were my decission, I would stop the DIPs for, let's say 3 months (maybe more or a repetition in a year is needed), and proclaim this time to be dedicated to bugfixes and documentation. So everyone would be asked to help to remove bugs and improve the documentation during this period. IMHO in the long run this makes for a faster improvement, because it's much easier to implement new things, when not having to hack around several bugs. And it would make for a stable version which deserves this name.


Enough for today. I still don't know, if I will leave or stay...

On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
> [...]
>
> * Labels. I havn't found a way to add labels to my PR. I guess, I just can't. Some of them would be helpful, especially WIP (and auto-merge ;-) ). Maybe the bot could recognise +WIP and -WIP and just add and remove this label.

GitHub introduced 'draft' PRs[1] for this last year. Sadly it's not
yet[2] possible to turn a normal PR (back) into a draft PR.

More generally however, I agree it would be useful to allow contributors
to set certain labels.

[1] https://github.blog/2019-02-14-introducing-draft-pull-requests/
[2] https://github.community/t5/-/-/td-p/19107

On Thursday, 6 February 2020 at 16:26:43 UTC, berni44 wrote:
> Last week, I was quite disappointed when no one replied on my anouncement of a new website about D (meanwhile there are three replies, one negative, two positive, but it's somewhat too late).
Sorry I missed it.

Just a thought or two...

I started my GtkD blog over a year ago and it took nearly a month before anyone seemed to pay attention. I have no idea if they were or not because I just put up the posts, announced them, and went back to work on the next post. I suspect that any community wants to know that a new site isn't going to end up with one or two posts and then fold. No point in getting excited (or, perhaps, even interested) if that's the case.

Another thing to keep in mind is this: If you like the D language and you like doing the site, then just do it... because it's what you want to do. If you really don't care one way or the other, then you're right to find something else to occupy your time.

On Fri, Feb 07, 2020 at 08:00:16PM +0000, berni44 via Digitalmars-d wrote: [...]
> On Thursday, 6 February 2020 at 20:29:31 UTC, Walter Bright wrote:
[...]
> > If there's a mistake in it that subtly breaks someone's floating point code, it would cause them to not trust D. Just finding someone capable of reviewing it thoroughly would be very difficult for any community.
> 
> I question this a little bit. Not, that it would not be nice to have such reviewers. But I fear we do not have them and so an other way of dealing with such PRs is needed. Here, for example, one could run test scripts comparing the output of snprintf with the new function. This is something one could do, without understanding the details of the function. (I even provided several such test script, which I used myself to find corner cases I got wrong, when implementing.) Doing this for say 24h without finding any difference (other than the fixed bugs), would be a high evidence that the code has no bugs.

If you could provide such a tool that does this verification, and maybe include it in phobos/std/internal somewhere (optionally with a rule in the makefile for running it, so that people can easily check for themselves), then run it for I dunno, a week or something to go through all possible 32-bit floats and a significant subset of 64-bit floats, then we'd have solid evidence that your code has no bugs, as least as far as snprintf is concerned. (This of course assumes snprintf itself has no bugs, which I'm actually not 100% confident of, but at least it's been around for long enough and tested by enough people that the chances of a bug in some really obscure corner case seems negligibly small.)

I was going to suggest adding this to the Phobos unittests, but I fear that exhaustive tests of this sort will only add unnecessary burden on the autotesters and slow everything down for no good cause. So a separate tool seems to be the best solution.


> > One thing you can do when things are being overlooked is to get behind and push. I often do that - people don't just pull things because I wrote them.
> 
> This is something I quite dislike. Maybe it's my personality - I often feel importunate, when doing so.

It's OK, back when I still had time to contribute to D regularly, I used to leaf through old, stagnant PRs, and @ping people to get moving on it. Some of my pings fell on deaf ears, but I did manage to get a few stagnant PRs to start moving again, after "annoying" them with regular pings.


> On Thursday, 6 February 2020 at 17:35:36 UTC, H. S. Teoh wrote:
> > Honestly, if it were up to me, I'd add you to the Phobos team.
> 
> I didn't even know that such a team exists...

Huh, weird. Github used to have icons on a page somewhere that shows everyone that belonged to a particular organization/team, but it seems that has disappeared.

As far as Phobos is concerned, basically it just means you get write access to the repository.  Some years back I was regularly contributing and complaining that the PR queue was too slow, then suddenly overnight somebody gave me commit access to Phobos (which I was not expecting). Then later on I got added to dlang.org and druntime, though not dmd (I didn't contribute regularly enough, plus I don't think I have the expertise to review dmd PRs, so that's OK).

Of course, as a committer, it's bad form to pull your own PRs, but at least you can pull others' PRs (or otherwise ping people, etc.) to get things moving when the PR queue gets clogged up.


> Maybe it would indeed help to be in such a team, because I'd have some people I can ask without the need to discuss everything here in the forum. On the other hand I'm not sure if being added to such a team comes with expectations I cannot meet...

I think the only expectation, as far as I'm aware anyway, is that you don't pull your own PRs, or pull stuff without being reasonably sure there are no bugs or problems, and that you're familiar enough with idiomatic D to be able to tell whether a piece of code is good or not. Other than that, I don't think there are any other expectations.  As far as my own experience with contributing to Phobos is concerned, I just refrain from touching PRs that I'm not qualified to review, and everything else is fair game, I guess. (Although as I said, I do leaf through old PRs and give them a kick every now and then just to get things unclogged.)

For a while, the D Foundation was paying Nicholas Wilson to monitor the PR queue and keep things moving; I'm not sure if they're still doing that.  From the sound of what you said, though, he's still around *somewhere*.


> On Thursday, 6 February 2020 at 17:47:14 UTC, Jonathan Marler wrote:
> > Unfortunately, there's not much you or I can do, it's in the hands of the leadership.
> 
> Again: I even don't know exactly who this is. OK, Walter, that's clear. And I could guess a few others - Mike, Atila, Nicholas, Vladimir and Andrei come to my mind (and the foundation page list Ali too).
> 
> Maybe it would be a good thing to have some overview about the teams and groups somewhere.

I'm pretty sure Github used to have a list of these people, but I can't seem to find that page anymore.


[...]
> * Recently the testers had a lot of false positives, mainly because of missing internet. That doesn't feel good. The PRs get red for no real reason and I've got no real means to do anything about it. Just rebase and push, rebase and push, ..., but I do not want to do that all the time. Maybe the missing internet errors could be caught and the result of the tests postponed somehow? I have no experience with this, so I cannot say, if this is lot of work or simple to implement. Just a suggestion.

I used to complain loudly when the autotester got stuck. But these days, with the increasingly complex CI infrastructure, I don't even know what's going on anymore.

But either way, false positives from the testers is a problem that needs to be addressed.  I'd ping the people responsible for it (Vladimir, IIRC, and Brad perhaps? I forget who else, the Github "conveniently" disappeared the Dlang organization member list page).


> * Labels. I havn't found a way to add labels to my PR. I guess, I just can't. Some of them would be helpful, especially WIP (and auto-merge ;-) ).  Maybe the bot could recognise +WIP and -WIP and just add and remove this label.
[...]

If you're given commit access, you'd be able to add labels.  For the time being, though, I'd just stick "[WIP]" in front of the PR title and leave it at that.  I think that gets the message across.


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- Sammy

On 2/7/2020 12:00 PM, berni44 wrote:
> I would actally recommend to close old PRs.
I strongly oppose closing PRs just because they are old, and the corollary of closing old Bugzilla issues just because they are old.

The only time I ever approved of this was when we decided that we would no longer support D1. The outstanding issues for D1 that only had relevance to D1 were marked "WONTFIX".

Sweeping problems under the rug is not what we're about.

On 2/7/2020 12:00 PM, berni44 wrote:
> The difficult thing is to get the mix of all the flags, precission, width and rounding right.

Of course :-)

The other problem I neglected to mention is D does not have a thorough test suite for floating point formatting. Writing one seemed pointless as we were relying on the C standard library to do it, and presumably the C people had tested it properly.

This assumption did turn out to be false, at least for the transcendental functions. Many C targets turned out to have precision problems.

A lot of algorithms really do care if 3.78612345 is more accurate than 3.78612344.

In other words, writing a better implementation is one thing, showing that it is at least as correct as what it replaces is also necessary.

One way to shortcut that is to use an algorithm that is generally accepted by the industry to be correct, then the problem is reduced to showing that the algorithm is implemented correctly. (This is what I've done, for example, in the compiler optimization that replaces divides with multiplications by a constant.)

Another way is to construct a tester that randomly generates bit patterns, then formats the result with both sprintf and the new implementation, and they must match exactly. Then it's a matter of how many of these test cases are run.

On 2/7/2020 1:38 PM, Ron Tarrant wrote:
> I started my GtkD blog over a year ago and it took nearly a month before anyone seemed to pay attention. I have no idea if they were or not because I just put up the posts, announced them, and went back to work on the next post. I suspect that any community wants to know that a new site isn't going to end up with one or two posts and then fold. No point in getting excited (or, perhaps, even interested) if that's the case.

Hollywood has a fantasy of "build it and they will come". It's complete nonsense. It doesn't matter how good it is - unless and until some sort of promotion is done for it, it isn't going anywhere. It's the brutal truth.

This article, "1000 True Fans", gives an idea of what is necessary:

  https://a16z.com/2020/02/06/100-true-fans/

On Saturday, 8 February 2020 at 01:40:36 UTC, Walter Bright wrote:
> On 2/7/2020 12:00 PM, berni44 wrote:
>> I would actally recommend to close old PRs.
> I strongly oppose closing PRs just because they are old, and the corollary of closing old Bugzilla issues just because they are old.

I'm sorry, maybe I didn't express myself clearly enough: I do not want to close them, just because they are old, but to actually handle them somehow. As far as I know, several of them could either be merged (maybe with some minor changes) or it is quite clear, that they will never be merged (for example because the issue has been addressed in a different way meanwhile).

On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright wrote:
> Another way is to construct a tester that randomly generates bit patterns, then formats the result with both sprintf and the new implementation, and they must match exactly. Then it's a matter of how many of these test cases are run.

That's what I did - see [1]. H. S. Teoh suggested above to put them into std/internals to preserve them and have a possibility to let others run the tests too. I'll have to see. Havn't peeked into std/internals yet...

[1] https://github.com/berni44/printFloat

On Saturday, 8 February 2020 at 16:29:18 UTC, berni44 wrote:
> On Saturday, 8 February 2020 at 01:40:36 UTC, Walter Bright wrote:
>> On 2/7/2020 12:00 PM, berni44 wrote:
>>> I would actally recommend to close old PRs.
>> I strongly oppose closing PRs just because they are old, and the corollary of closing old Bugzilla issues just because they are old.
>
> I'm sorry, maybe I didn't express myself clearly enough: I do not want to close them, just because they are old, but to actually handle them somehow. As far as I know, several of them could either be merged (maybe with some minor changes) or it is quite clear, that they will never be merged (for example because the issue has been addressed in a different way meanwhile).
>
> On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright wrote:
>> Another way is to construct a tester that randomly generates bit patterns, then formats the result with both sprintf and the new implementation, and they must match exactly. Then it's a matter of how many of these test cases are run.
>
> That's what I did - see [1]. H. S. Teoh suggested above to put them into std/internals to preserve them and have a possibility to let others run the tests too. I'll have to see. Havn't peeked into std/internals yet...
>
> [1] https://github.com/berni44/printFloat

for 32-bit floats it doesn't take too long to do an exhaustive test (maybe 30 minutes or so).  I did this with my port of the "ryu" float to string implementation (https://github.com/dragon-lang/mar/blob/master/src/mar/ryu.d).  That being said, an exhaustive 64-bit test may not finish until the inevitable heat death of the universe :)