On 27 April 2017 at 12:01, Johannes Ranke wrote:
|
| > so it seems to me this must affect all packages in Debian sid that were
| > built before the release of R 3.4.0!
|
| or rather before 14 April 2017, which is when R from revision r72510 was
| uploaded to sid as pre-release candidate.
Another example with KernSmooth:
> library(KernSmooth)
KernSmooth 2.23 loaded
Copyright M. P. Wand 1997-2009
>
> example(bkde)
bkde> data(geyser, package="MASS")
bkde> x <- geyser$duration
bkde> est <- bkde(x, bandwidth=0.25)
Error in linbin(x, gpoints, truncate) : object 'F_linbin' not found
>
Maybe this part of NEWS is what matters:
* Packages which register native routines for .C or .Fortran need
to be re-installed for this version (unless installed with
R-devel SVN revision r72375 or later).
KernSmooth surely has .Fortran. Your spatial example had VR_frset failing,
and that too is called by the old .C.
A counter-example is eg my RcppEigen package -- I can load it and run
example(fastLm) just fine as that uses .Call rather than .C or .Fortran.
I think you are
-- correct in that we need rebuilds
-- but only for packages using .C and .Fortran calls to compiled
This may be a use case for r-api-4. Or not as it doesn't break _all_
packages
so I am not sure we should force _all_ packages to be rebuilt.
Can we not find the ones that use .C and .Fortran ?
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Am Donnerstag, 27. April 2017, 06:32:13 schrieb Dirk Eddelbuettel:> On 27 April 2017 at 12:01, Johannes Ranke wrote: > | > so it seems to me this must affect all packages in Debian sid that were > | > built before the release of R 3.4.0! > | > | or rather before 14 April 2017, which is when R from revision r72510 was > | uploaded to sid as pre-release candidate. > > Another example with KernSmooth: > > library(KernSmooth) > > KernSmooth 2.23 loaded > Copyright M. P. Wand 1997-2009 > > > example(bkde) > > bkde> data(geyser, package="MASS") > > bkde> x <- geyser$duration > > bkde> est <- bkde(x, bandwidth=0.25) > Error in linbin(x, gpoints, truncate) : object 'F_linbin' not found > > > Maybe this part of NEWS is what matters: > > * Packages which register native routines for .C or .Fortran need > to be re-installed for this version (unless installed with > R-devel SVN revision r72375 or later).Yes, that is what Martin M?chler referred to in the answer to Bj?ran's call for help on r-help.> KernSmooth surely has .Fortran. Your spatial example had VR_frset failing, > and that too is called by the old .C. > > A counter-example is eg my RcppEigen package -- I can load it and run > example(fastLm) just fine as that uses .Call rather than .C or .Fortran. > > I think you are > > -- correct in that we need rebuilds > -- but only for packages using .C and .Fortran calls to compiledYes.> This may be a use case for r-api-4. Or not as it doesn't break _all_ > packages so I am not sure we should force _all_ packages to be rebuilt. > > Can we not find the ones that use .C and .Fortran ?I do not understand how the use of r-api-x works, but my feeling is that it will not allow to differentiate between packages using .C and .Fortan and the rest. I am surprised that I did not see a related bug report in the Debian BTS yet, did I overlook something? I only looked for r-base.
On 27 April 2017 at 13:58, Johannes Ranke wrote:
| Am Donnerstag, 27. April 2017, 06:32:13 schrieb Dirk Eddelbuettel:
| > On 27 April 2017 at 12:01, Johannes Ranke wrote:
| > | > so it seems to me this must affect all packages in Debian sid that
were
| > | > built before the release of R 3.4.0!
| > |
| > | or rather before 14 April 2017, which is when R from revision r72510
was
| > | uploaded to sid as pre-release candidate.
| >
| > Another example with KernSmooth:
| > > library(KernSmooth)
| >
| > KernSmooth 2.23 loaded
| > Copyright M. P. Wand 1997-2009
| >
| > > example(bkde)
| >
| > bkde> data(geyser, package="MASS")
| >
| > bkde> x <- geyser$duration
| >
| > bkde> est <- bkde(x, bandwidth=0.25)
| > Error in linbin(x, gpoints, truncate) : object 'F_linbin' not
found
| >
| >
| > Maybe this part of NEWS is what matters:
| >
| > * Packages which register native routines for .C or .Fortran need
| > to be re-installed for this version (unless installed with
| > R-devel SVN revision r72375 or later).
|
| Yes, that is what Martin M?chler referred to in the answer to Bj?ran's
call
| for help on r-help.
|
| > KernSmooth surely has .Fortran. Your spatial example had VR_frset
failing,
| > and that too is called by the old .C.
| >
| > A counter-example is eg my RcppEigen package -- I can load it and run
| > example(fastLm) just fine as that uses .Call rather than .C or .Fortran.
| >
| > I think you are
| >
| > -- correct in that we need rebuilds
| > -- but only for packages using .C and .Fortran calls to compiled
|
| Yes.
Here is a quick script snippet. Looks like about 1/3 of my r-cran-* packages
use .C() or .Fortran() and need a rebuild for R 3.4.0 (which some may already
have gotten as some upstream packages got updates):
-----------------------------------------------------------------------------
#!/bin/bash
## source directories are all named foo-1.2.3
dirs=$(find . -maxdepth 1 -type d -name \*-\* | sort)
for d in ${dirs}; do
if test -d ${d}/src; then
if grep -q -r \\.Fortran\( ${d}/R; then
echo ".Fortran in ${d}"
fi
if grep -q -r \\.C\( ${d}/R; then
echo ".C in ${d}"
fi
fi
done
-----------------------------------------------------------------------------
|
| > This may be a use case for r-api-4. Or not as it doesn't break _all_
| > packages so I am not sure we should force _all_ packages to be rebuilt.
| >
| > Can we not find the ones that use .C and .Fortran ?
|
| I do not understand how the use of r-api-x works, but my feeling is that it
| will not allow to differentiate between packages using .C and .Fortan and the
| rest.
Right. And therefore cast too wide a net.
| I am surprised that I did not see a related bug report in the Debian BTS yet,
| did I overlook something? I only looked for r-base.
They may not know yet. I should write to debian-devel.
Any debian-med or debian-science readers here?
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org