www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 3 months of waiting...

reply berni44 <dlang d-ecke.de> writes:
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
Feb 06
next sibling parent matheus <matheus gmail.com> writes:
On Thursday, 6 February 2020 at 16:26:43 UTC, berni44 wrote:
 ...
 Bye bye
Well that's sad! For such a small community and in need for developers, losing one so active is not good. I think the Top heads of the community should care more about this. 3 months without any answer is something very frustrating indeed. I hope you find a place that recognize you better. Good luck, Matheus.
Feb 06
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 2/6/20 11:26 AM, 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).
Many here don't speak German, and while it's cool that there's a new website that I can't really read (honestly didn't even click on it), you did not exactly solicit feedback on the announcement. Is there no activity there?
 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.
I've seen the PR and that stuff is way out of my league. So while I've looked at quite a few of your PRs (and merged some I think) and I was very glad to have you in there fixing stuff, I think it's a bit much to expect something so technically complex that few understand to receive a thorough review by everyone. There's a reason we use sprintf for floats -- it's a hard problem. I hope it's valid and gets merged at some point, but I really can't help except give a thumbs up.
 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.
That's too bad, I think your advent of bug fixes was an awesome initiative. One thing that is true about open source volunteer work, it's mostly thankless, and generally there are not enough people to work on it as it is. Sometimes good and productive people find that incompatible with their requirements, but I don't know how we could possibly fix that.
 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.
Thank you for leaving them open!
 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.
Thanks for your time and effort. -Steve
Feb 06
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 07/02/2020 5:50 AM, Steven Schveighoffer wrote:
 
 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.
I've seen the PR and that stuff is way out of my league. So while I've looked at quite a few of your PRs (and merged some I think) and I was very glad to have you in there fixing stuff, I think it's a bit much to expect something so technically complex that few understand to receive a thorough review by everyone. There's a reason we use sprintf for floats -- it's a hard problem. I hope it's valid and gets merged at some point, but I really can't help except give a thumbs up.
I looked into float to string handling (yay formattedWrite and friends not working at CT) a couple of weeks ago. Yeahhhh no way I am reviewing anything in that line of work beyond a thumbs up. Not that it would weigh much into getting it pulled unfortunately. It is appreciated of course, but I can't help beyond that.
Feb 06
prev sibling parent Les De Ridder <les lesderid.net> writes:
On Thursday, 6 February 2020 at 16:50:32 UTC, Steven 
Schveighoffer wrote:
 On 2/6/20 11:26 AM, berni44 wrote:
 [...]
 
 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.
That's too bad, I think your advent of bug fixes was an awesome initiative. One thing that is true about open source volunteer work, it's mostly thankless, and generally there are not enough people to work on it as it is. Sometimes good and productive people find that incompatible with their requirements, but I don't know how we could possibly fix that.
This is what's key here, imo. It can be very frustrating to have PRs or even issues open for months or years. If you have more maintainers, there's a higher probability at least one of them cares personally about getting your issue or PR closed. But finding knowledgeable maintainers is hard, because that's mostly a thankless job too. So I don't think there's an easy fix either. Something that might be valuable would be to actively encourage user involvement by voting on issues and PRs. This gets us strength in numbers and the social reward can be motivating for maintainers and contributors. This will become easier once the issue tracker for the core repos is moved over to GitHub[1]. 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. [1] https://github.com/dlang/projects/issues/43
Feb 06
prev sibling next sibling parent Andre Pany <andre s-e-a-p.de> writes:
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
Really sad to hear this. It was quite fascinating to see how much you achieved in such small amount of time. Thanks for your work. I planned to add a link to your site on my site (http://d-land.sepany.de/) but at the moment it is almost possible to find some time to do D in my spare time except reading the forum and write some posts from time to time. I assume it is the same situation for many others in the community. It is really a time problem to do D activities beside the regular job and family activities. I really hope you get back to D in the future. Kind regards Andre
Feb 06
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 06, 2020 at 04:26:43PM +0000, berni44 via Digitalmars-d wrote:
[...]
 Finally I came to the conclusion, that I do not fit in this community.
 So I will leave.
[...] I am very sad to hear this. You have been an extremely valuable contributor over the past so many months, fixing many things that have been neglected for a long time, and generally improving the quality of things. Honestly, if it were up to me, I'd add you to the Phobos team. We need more active contributors like you to keep things from stagnating. But alas, it's not my decision to make. In any case, I hope that one day you will decide to come back. T -- I am not young enough to know everything. -- Oscar Wilde
Feb 06
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
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.
Sorry to see you go. For what it's worth, you're far from alone in these experiences, so I don't think they're necessarily a sign of "not fitting in." It is, unfortunately, not unusual for a thread in the Announcements forum to receive few or even zero replies, or for a PR to sit unreviewed in the queue for months at a time. Engaging with the contribution process in a healthy way that avoids burnout while still achieving your goals is not easy, and I can't blame anyone who, having tried it, decides to seek greener pastures elsewhere. If you ever do decide to return, I'm sure the D community will be happy to welcome you back. Either way, thanks for all that you've given us, and best of luck in your future endeavors. :)
Feb 06
prev sibling next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
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
I've had similar experience. Waited months for someone to look at pull request with no response. The leadership of the D community does not have enough time to review all the Pull Requests that come in. There's too few people that can review, and too many good developers leave out of frustration or difference of opinion. From what I understand, the amount of work to review code in dlang's repositories is relatively low, but the number of people that can and do review is even smaller. Maybe the leadership needs to spend more time cultivating expertise among the community and delegating roles to sustain the influx of work that comes in? I do know that the leadership has a hard time finding the "right" people that can review code in a way that they are happy with. I recall Andrei talking about this, and he mentions that when he does try to "let go" he comes back later to find issues with code that got approved that he wasn't able to review. Of course, we can't all be as good as Andrei :) It's rare to find someone with his amount of talent and experience. My advice is to understand that working on the Dlang repositories is typically not going to be quick. As I've come to learn this, I've naturally come to spend less time working on D and more time working on other things. I still work on D if there are things I need, but in general I tend to dismiss most of my inclinations to work on things that I would otherwise do if I thought people would be there to review it. Unfortunately, there's not much you or I can do, it's in the hands of the leadership. They must be waiting for more developers to come along that can review code, but it seems like the current state is deturing those very people sticking around. Feels like a catch 22 situation.
Feb 06
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/6/2020 8:26 AM, 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
 
For reference (Phobos): 9 open: https://github.com/dlang/phobos/pulls/berni44 70 merged: https://github.com/dlang/phobos/pulls?q=is%3Apr+author%3Aberni44+is%3Aclosed It does look like you've got a solid track record of success. Thank you! ----------------- This one is always going to be a tough one: https://github.com/dlang/phobos/pull/7264 Floating point code is extremely difficult to get right, and contains a lot of very subtle traps for the unwary. (It's why people are still writing research papers on formatting floating point numbers.) 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. It's a bit harsh, but when working on this sort of thing that comes with the territory. 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.
Feb 06
prev sibling next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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
Feb 06
parent reply berni44 <dlang d-ecke.de> writes:
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...
Feb 07
next sibling parent Les De Ridder <les lesderid.net> writes:
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
Feb 07
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Feb 07
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 07
parent reply berni44 <dlang d-ecke.de> writes:
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
Feb 08
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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 :)
Feb 08
next sibling parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Saturday, 8 February 2020 at 17:21:04 UTC, Jonathan Marler 
wrote:
 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 :)
Maybe some structured tests could help, e.g. by using libfuzzer to instrument the new and old code. It's obviously not be an exhaustive tests but could result in a better coverage than random sampling.
Feb 08
parent sarn <sarn theartofmachinery.com> writes:
On Saturday, 8 February 2020 at 17:27:00 UTC, MoonlightSentinel 
wrote:
 On Saturday, 8 February 2020 at 17:21:04 UTC, Jonathan Marler 
 wrote:
 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 :)
Maybe some structured tests could help, e.g. by using libfuzzer to instrument the new and old code. It's obviously not be an exhaustive tests but could result in a better coverage than random sampling.
Another option is KLEE (https://theartofmachinery.com/2019/05/28/d_and_klee.html). Unfortunately the original KLEE doesn't support floating point or threads, but you could use the (unmaintained?) floating point fork to generate a pretty good test suite based on an existing libc snprintf or a betterC version of D floating point code.
Feb 08
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 8 February 2020 at 17:21:04 UTC, Jonathan Marler 
wrote:
 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 :)
It feels intuitively that there's got to be a more effective way of approaching this than brute-forcing all the cases, or randomly selecting a sufficient subset. I would anticipate that there has to be a well-defined subset of cases such that, if the formatter works for those, it'll work for everything else. (Yes, I get that in this case you're trying to compare the behaviour of 2 different functions, but I think the principle should still apply.)
Feb 10
parent sarn <sarn theartofmachinery.com> writes:
On Monday, 10 February 2020 at 11:23:16 UTC, Joseph Rushton 
Wakeling wrote:
 On Saturday, 8 February 2020 at 17:21:04 UTC, Jonathan Marler 
 wrote:
 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 :)
It feels intuitively that there's got to be a more effective way of approaching this than brute-forcing all the cases, or randomly selecting a sufficient subset. I would anticipate that there has to be a well-defined subset of cases such that, if the formatter works for those, it'll work for everything else. (Yes, I get that in this case you're trying to compare the behaviour of 2 different functions, but I think the principle should still apply.)
KLEE (which I mentioned earlier in the thread) uses constraints solvers to prove/disapprove assertions over all possible code paths. KLEE float uses the IEEE floating point theory in the Z3 solver. When you run KLEE against some code, you can get it to generate example inputs for each code path, which can be used as a regression suite. A regression suite like that is weaker than running KLEE again, but stronger than the typical code coverage test suite because it has code *path* coverage.
Feb 10
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
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:
 [...]
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:
 [...]
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
FYI: another easy option would be to add this to the project tester. It basically checks out a project and then does `dub test` on it. The downside is that the project tester is Linux only at the moment.
Feb 08
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/8/2020 9:35 AM, Seb wrote:
 FYI: another easy option would be to add this to the project tester. It 
 basically checks out a project and then does `dub test` on it.
 The downside is that the project tester is Linux only at the moment.
That shouldn't be a big problem here, as the floating point tests should be platform agnostic.
Feb 08
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/8/2020 8:29 AM, berni44 wrote:
 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
Good. It needs to be part of the D test suite.
Feb 08
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 07
parent reply Arine <arine123445128843 gmail.com> writes:
On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright wrote:
 A lot of algorithms really do care if 3.78612345 is more 
 accurate than 3.78612344.
What algorithms are those? You can get that kind of variance dependent on what hardware you are running on.
Feb 08
parent reply sarn <sarn theartofmachinery.com> writes:
On Saturday, 8 February 2020 at 22:44:26 UTC, Arine wrote:
 On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright 
 wrote:
 A lot of algorithms really do care if 3.78612345 is more 
 accurate than 3.78612344.
What algorithms are those? You can get that kind of variance dependent on what hardware you are running on.
Walter's possibly remembering the fuss that was made about this bug: https://en.wikipedia.org/wiki/Pentium_FDIV_bug
Feb 08
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 09, 2020 at 12:25:43AM +0000, sarn via Digitalmars-d wrote:
 On Saturday, 8 February 2020 at 22:44:26 UTC, Arine wrote:
 On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright wrote:
 A lot of algorithms really do care if 3.78612345 is more accurate
 than 3.78612344.
What algorithms are those? You can get that kind of variance dependent on what hardware you are running on.
Walter's possibly remembering the fuss that was made about this bug: https://en.wikipedia.org/wiki/Pentium_FDIV_bug
Dare I bring up this one too? https://issues.dlang.org/show_bug.cgi?id=15854 T -- Дерево держится корнями, а человек - друзьями.
Feb 08
prev sibling parent reply Arine <arine123445128843 gmail.com> writes:
On Sunday, 9 February 2020 at 00:25:43 UTC, sarn wrote:
 Walter's possibly remembering the fuss that was made about this 
 bug:
 https://en.wikipedia.org/wiki/Pentium_FDIV_bug
It's not a bug. Different hardware is built differently, they aren't going to all have the same results unless they are exactly the same. You aren't going to get that kind of behavior, especially across different assembly architectures.
Feb 09
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Sunday, 9 February 2020 at 15:28:21 UTC, Arine wrote:
 On Sunday, 9 February 2020 at 00:25:43 UTC, sarn wrote:
 Walter's possibly remembering the fuss that was made about 
 this bug:
 https://en.wikipedia.org/wiki/Pentium_FDIV_bug
It's not a bug. Different hardware is built differently, they aren't going to all have the same results unless they are exactly the same. You aren't going to get that kind of behavior, especially across different assembly architectures.
It's a simpler matter than that. Either a hardware FPU is compliant with the IEEE754 standard or not. There can be infinitely many implementations, but if they claim to implement the standard, they should all return either the same value or a value within the specified interval (for the same instruction and operands).
Feb 09
parent Arine <arine123445128843 gmail.com> writes:
On Sunday, 9 February 2020 at 16:08:58 UTC, Petar Kirov 
[ZombineDev] wrote:
 or a value within the specified interval
Really the only relevant part of your comment. If they aren't exactly the same, then there is going to be variance. Anyways I would like to know what algorithms he was referring to.
Feb 09
prev sibling parent reply berni44 <dlang d-ecke.de> writes:
On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
 I still don't know, if I will leave or stay...
I really don't fit in here...
Feb 09
next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Sunday, 9 February 2020 at 10:04:25 UTC, berni44 wrote:
 On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
 I still don't know, if I will leave or stay...
I really don't fit in here...
Social dynamics in open source is fascinating to me. Can you elaborate a bit on why you don't think you don't fit in? I'd like to learn from your perspective. I see that you had alot of the same thoughts that I've had. Issues with PRs and bugs that stay open forever with the focus on new features rather than fixing issues. Do you think this community is beyond hope? What would be different with a community that you feel like you would fit in with?
Feb 09
prev sibling parent reply berni44 <dlang d-ecke.de> writes:
On Sunday, 9 February 2020 at 10:04:25 UTC, berni44 wrote:
 On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
 I still don't know, if I will leave or stay...
I really don't fit in here...
I will delete my github account next week. If you want to keep anything from it copy it now or never.
Jun 01
next sibling parent berni44 <dlang d-ecke.de> writes:
On Monday, 1 June 2020 at 09:15:33 UTC, berni44 wrote:
 On Sunday, 9 February 2020 at 10:04:25 UTC, berni44 wrote:
 On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
 I still don't know, if I will leave or stay...
I really don't fit in here...
I will delete my github account next week. If you want to keep anything from it copy it now or never.
As it might be easily overlooked, I'd like to point out https://github.com/berni44/phobos/tree/formatS which is no PR yet, as it is incomplete. It's a rewrite (correcting several mistakes and adding not documented features) of the main documentation of std/format, including unittests.
Jun 01
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Monday, 1 June 2020 at 09:15:33 UTC, berni44 wrote:
 On Sunday, 9 February 2020 at 10:04:25 UTC, berni44 wrote:
 On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
 I still don't know, if I will leave or stay...
I really don't fit in here...
I will delete my github account next week.
I would keep it if I were you. One reason is that once out opening issues (e.g in a non D project) is impossible. You can just archive your repositories or make them private and take your distances, if it is about accompagning your disengagement with a strong symbol.
Jun 01
prev sibling next sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Monday, 1 June 2020 at 09:15:33 UTC, berni44 wrote:
 On Sunday, 9 February 2020 at 10:04:25 UTC, berni44 wrote:
 On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
 I still don't know, if I will leave or stay...
I really don't fit in here...
I will delete my github account next week. If you want to keep anything from it copy it now or never.
I suggest you don't delete it because it can be useful in future job applications as proof that you are a capable and self-motivated developer (even if applying for jobs in other languages).
Jun 01
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 1 June 2020 at 09:15:33 UTC, berni44 wrote:
 On Sunday, 9 February 2020 at 10:04:25 UTC, berni44 wrote:
 On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
 I still don't know, if I will leave or stay...
I really don't fit in here...
I will delete my github account next week. If you want to keep anything from it copy it now or never.
If you're no longer interested in working on a project, I would recommend using github's "archive" feature [1] to make it read-only. [1] https://help.github.com/en/github/creating-cloning-and-archiving-repositories/archiving-repositories
Jun 01
prev sibling next sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
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.
Feb 07
parent Walter Bright <newshound2 digitalmars.com> writes:
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/
Feb 07
prev sibling parent bauss <jj_1337 live.dk> writes:
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
I'm going to guess that my reply is the "negative" one but I wouldn't exactly call it negative. I didn't specifically say anything bad about your website, on the contrary I think it's great and everything. It was just wishful thinking that it would've been great to see it in D as D already lacks websites written in D. It's sad to see you wanting to leave, please don't. The community needs you and nobody wants you gone.
Feb 10