On 6/20/22 15:40, Berwin A Turlach wrote:
G'day Tomas,
On Mon, 20 Jun 2022 14:46:04 +0200
Tomas Kalibera <tomas.kalib...@gmail.com> wrote:
Well, what puzzles me is that I had no problem with R-patched right
until the end of the 4.1 branch. And I have no problems with
R-devel, that is also still installing a 32bit and a 64bit version
just fine.
It is just R 4.2 that gives me the problem.
Ah, that's interesting. And could you perhaps bisect it to the
problematic commit? That might increase the chances you get attention
of the person who authored it. After all you could also send a patch
Well, I found via Google a command that could tell me the first revision
of a branch. Apparently revision 81976 is the first revision of the 4.2
branch:
------------------------------------------------------------------------
r81976 | pd | 2022-03-25 07:02:01 +0800 (Fri, 25 Mar 2022) | 1 line
Create R-4-2-branch
------------------------------------------------------------------------
I checked this branch out and it already displays the same problem,
the same test in reg-tests-1d.R falls over. But I am pretty sure that
R-devel (and R-patched) compiled fine on that day. So where was the
change made before the R-4.2-branch was created?
the R-4-2-branch was created from R-devel branch by that commit you
found, so the previous changes were on R-devel. So you could now
actually search for a commit on R-devel (after r81978) that fixed it,
perhaps it is something that could be ported to R-4-2-branch.
You could restrict the search for changes in the corresponding test
files, first, checking if the tests/the tolerances have changed (that
would be easy, "svn blame" would help: "svn blame", "svn blame -r xxxx",
"svn log --diff", etc). If it is not a change in the tests but rather in
the computations, that would be harder to guess, still bisecting should
find it.
Best
Tomas
Cheers,
Berwin
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
