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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
next sibling parent reply 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 2020
parent reply Berni44 <someone somemail.com> writes:
On Sunday, 9 February 2020 at 11:41:56 UTC, Jonathan Marler 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...


 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.


Better late, than never: The reason for my perspective was 
probably
not the community but a mental health problem on my side: I 
featured a
medium recidivating depression, which I didn't know at that time.
During corona lockdown this got worse. But the good news is: I'm
completely (and hopefully permanently) healed meanwhile.

I now can't say, what exactly I disliked at that time. But there 
are a
few things, that come to mind:

* There is a lot of off-topic discussion in this forum. Maybe, 
because
it doesn't feature private messages like other forum software 
(like
myBB) does. Better formatting features would also be nice.

* I'm missing a list of people with offical role including contact
information.

* I dislike very much bug preserving solutions in fear of code
breakage. The most prominent example is probably: writefln("My 
friends
are %-(%s, %).", ["John", "Nancy"]);

* "The best is the worst enemy of the better": I dislike comments 
on
PRs of the sort "This could also be fixed for ..., would you 
please
add this?" A better approach would be to accept my PR and then 
file a
second PR oneself.

* IMHO the focus should be more on removing bugs/improving docs 
than
on implementing new features. I also support the removal of stuff 
with
little use (std.zip, std.zlib, std.signals, std.uri, and maybe 
even
support for reals?) to reduce the load of stuff, that needs taken 
care
of.


 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?


No. With the two new PR managers there is some hope. ;-)

In ernest: I was really happy, when I read about them a few days 
ago.
And, coincidentially, I recently felt desire for working on phobos
again. So all in all: I'll give the D community a second chance 
(and
hope for a second chance myself). :-)
Jan 17 2021
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 17 January 2021 at 17:46:32 UTC, Berni44 wrote:

 on implementing new features. I also support the removal of 
 stuff with
 little use (std.zip, std.zlib, std.signals, std.uri


I actually use std.zip, std.zlib, and std.uri more often than any 
of the other modules aside from std.stdio, std.file, std.conv, 
and std.socket.

std.signals can go tho lol.
Jan 17 2021
prev sibling next sibling parent M.M. <matus email.cz> writes:
On Sunday, 17 January 2021 at 17:46:32 UTC, Berni44 wrote:

 And, coincidentially, I recently felt desire for working on 
 phobos again. So all in all: I'll give the D community a second 
 chance (and hope for a second chance myself). :-)


Great that your personal issues have been resolved, and that you 
are back with D.
Jan 17 2021
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
Welcome back with good news. :)

Ali
Jan 17 2021
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 17 January 2021 at 17:46:32 UTC, Berni44 wrote:

 On Sunday, 9 February 2020 at 11:41:56 UTC, Jonathan Marler 
 wrote:

 [...]


 Better late, than never: The reason for my perspective was 
 probably
 not the community but a mental health problem on my side: I 
 featured a
 medium recidivating depression, which I didn't know at that 
 time.
 During corona lockdown this got worse. But the good news is: I'm
 completely (and hopefully permanently) healed meanwhile.

 [...]


Many agree with you on *certain* issues, but maybe we're a bit 
more optimistic 😉

Thanks for all your efforts fwiw!
Jan 17 2021
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 17, 2021 at 05:46:32PM +0000, Berni44 via Digitalmars-d wrote:
[...]

 So all in all: I'll give the D community a second chance (and hope for
 a second chance myself). :-)


Welcome back!  We're happy to have you again.


T

-- 
Unix is my IDE. -- Justin Whear
Jan 18 2021
prev sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Sunday, 17 January 2021 at 17:46:32 UTC, Berni44 wrote:

 And, coincidentially, I recently felt desire for working on 
 phobos
 again. So all in all: I'll give the D community a second chance 
 (and
 hope for a second chance myself). :-)


I'm happy to hear that you're back in action, welcome again!

Be sure to visit Slack (I think I've sent you an invite a while 
back - let me know if you need me to send a new one), as that way 
you can have a more real-time discussion with other contributors 
and you can ping people for reviews. I know many people (myself 
included) are not able to keep up with notifications from GitHub 
and so asking for feedback on one of the public channels (say 
#phobos) or DM-ing people is much more effective way to have 
one's PRs reviewed in a timely manner. Of course, the new PR 
managers will help fix the slow process, but still, be sure to 
ping on Slack for feedback :P
Jan 18 2021
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020