Advent of bugfixes
timon.gehr at gmx.ch
Mon Dec 23 20:52:11 UTC 2019
On 23.12.19 18:16, berni44 wrote:
> On Monday, 23 December 2019 at 12:02:39 UTC, Timon Gehr wrote:
>> Both of my issues you have attempted to close should not have been.
> Actually, when I remember right, there where three issues, which I
> closed, because I considered them invalid (and in each of them I gave a
> reason, why I was doing so), which where reopened by the reporter. 
>  and . I still consider two of them invalid, only one of them 
> is from you and maybe I got something wrong there, but as long, as I do
> understand this issue like I do at the moment I judge it invalid.
That judgement makes no sense, you have not backed it up with anything
but your own bias, and I feel I have invested appropriate time and
effort into explaining why. (But I'll try again: You can do something
that's called a "signed right shift" on an unsigned value and it does
not matter whether there is a sign bit or not, its definition is based
purely on the bit representation. You can disagree that this terminology
makes sense, but it is standard enough to be _explicitly clarified_ in
the first few sentences of the Wikipedia article I linked, which for me
is the first result on Google for the query "signed right shift" .
Why is it not disrespectful to ask me to do this Google search for you?)
If for the original reporter, the required action was indeed as simple
as just reopening the issue, Steve's argumentation would make a little
> other one from you  got a separate thread in this forum. After you
> clearified it there, I understood, what you wanted and filed a PR which
> exactly does, what you want (and it would probably allready be merged,
> if dup would not have been down).
Yes, that PR seems close enough. However, I basically spent an entire
day fighting against misconceptions in that thread (which is to a large
extent my own fault, of course, I cared too much). The amount of
additional work that resulted for me is not nearly proportional to the
impact of the PR. Thanks though; that PR _will_ have an actual impact.
> And for reference, in  the reporter
> arguments, that we should add a bug, for consistency with an other bug;
> at least, that's my perception.
The behavior you call "an other bug" is explicitly documented. The
Phobos documentation plainly states:
"* Unsigned or signed integers to strings.
Convert integral value to string in radix radix. radix must be a value
from 2 to 36. value is treated as a signed value only if radix is 10.
The characters A through Z are used to represent values 10 through 36
and their case is determined by the letterCase parameter."
I don't know if that's the best possible design, but it makes sense for
common bases like 2, 8 and 16. Certainly not a bug though.
There is no related documentation about std.conv.parse that I could
find, but the fact that it doesn't consume its argument in case it
starts with a "-" and (only) if the radix is not 10 is a very strong
hint that it should be roundtrip-compatible.
I.e., leave that bug report open or fix the issue. There's no reason to
harass the original reporter about it any further. The issue is that you
didn't think to pull out the related documentation. You wanted to close
a bug report about std.conv.parse without understanding the (admittedly
not fully intuitive) interfaces of std.conv.to and std.conv.parse. There
is no good reason for you to do this though, I think you could easily do
better. It's a matter of following the right process. (E.g., once you
think someone is wrong about something, try to refute your own opinion
and only if you fail to do that, write your post. It helps to include a
trusted third-party source that the other person can then use to refute
their own opinion, but if it is the first result in a popular search
engine, I think it is justifiable to be a bit grumpy about being forced
to bear the burden of proof.)
>> it appears your judgement can be rather biased towards closing issues.
> I found several bug reports, where I think, that they could be closed
> too, but where I felt, that I cannot decide upon. In most cases I wrote
> a question, asking for clearification, sometimes I just ignored them.
> But well yes, I might have made mistakes. That's normal, because I'm a
> human being.
So am I, but whether you are human or not is not a particularly
important parameter. If you are _fallible_, there's typically a
trade-off between time invested and number of mistakes. Valid bug
reports have high positive value and invalid ones are only slightly
negative. Therefore, it pays to be careful about what you close.
If you have a team of people working on something (particularly code or
research), and different people apply different amounts of care, there
is bound to be a certain amount of conflict about it, and if careless
people don't adapt, the careful ones eventually leave or burn out. I am
not the bad guy here, and I think your intentions are good as well. I'm
just telling you how to be more effective at transforming your labor
into actual value. Andrei wrote a related post some time ago, though it
is not a perfect fit .
>  https://issues.dlang.org/show_bug.cgi?id=18290
>  https://issues.dlang.org/show_bug.cgi?id=7006
>  https://issues.dlang.org/show_bug.cgi?id=8007
More information about the Digitalmars-d