Duncan Murdoch:
No, I don't think it's reasonable to expect you to write a patch, but
reporting the bugs in the R bug reporting system isn't that hard to do,
and does lead to fixes pretty rapidly in cases where the report contains
sample code to reproduce the problem.
Sometimes. Sometimes not. For instance, PR #14985, a significant set
of bugs, with an easy fix (patch provided), which took almost two
years to make it to an R Core release - perhaps because you were more
interested in trying to argue that they weren't really bugs at all...
"Fixed a problem in R_AllocStringBuffer that could result in a crash due
to an invalid memory access" sounds serious, but is just too vague to
follow up. I would expect that doing a diff on the source files is
going to find all sorts of stuff: pqR isn't just R with bugs fixed, it
has a lot of other changes too.
You might expect that if it was really that difficult, I would have
given more detail. I think if you actually looked at this procedure,
which is about 30 lines long, you might, seeing as you've been warned
that it has a bug, find the problem in about 30 seconds, even without
looking at the pqR source code, which of course isn't difficult to do.
it would be more
helpful to the community if the bugs actually got fixed.
Indeed.
I think all of
the bugs that you reported last June got fixed within a couple of weeks
Actually, the last six in the list I just posted are from the original
pqR release last June. Some of the six don't seem too crucial, but
two of them seem reasonably serious (one leads to R crashing).
Why not report them
more frequently than annually, and give the details you already have so
they are easier to fix?
I did report at least one bug not long ago (which got fixed), after
seeing (as now) that an R Core release was imminent, and therefore
thinking it would be best if a fix was put in before it went out.
You're of course welcome to look at the NEWS file at pqR-project.org
whenever you like.
Radford Neal