Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio
Without code we are guessing. A bug is possible but I will make another guess
suggestion.
Delete all binary files created by devtools during compilation in your package
directory.
devtools::load_all() is so fast partly because it recompiles the C/Fortran
files only when necessary
but sometimes compilation may be needed even if devtools thinks otherwise.
Georgi Boshnakov
-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Sent: 07 November 2018 00:26
To: Rampal Etienne; Georgi Boshnakov; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio
On 06/11/2018 5:17 PM, Rampal Etienne wrote:
> Dear Duncan,
>
> I don't get it when using R CMD check.
>
> I only get it when building/loading using roxygen2 or when I call
> load_all (which roxygen2 does too, I think). load_all calls load_dll
> which then throws this error. I have registered my routines in
> R_init_secsse.c:
>
> void R_init_secsse(DllInfo *dll)
> {
> R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
> R_useDynamicSymbols(dll, FALSE);
> }
>
> Any suggestions?
Nope! Sounds like a bug in devtools/roxygen2, but I don't know either
of those packages well.
Duncan Murdoch
>
> Cheers, Rampal
>
>
> On 06-Nov-18 22:50, Duncan Murdoch wrote:
>> On 06/11/2018 3:27 PM, Rampal Etienne wrote:
>>> Dear Georgi,
>>>
>>> Thanks for your suggestions. I have tried to install the development
>>> version of roxygen2, but to no avail.
>>>
>>> I don't have a Collate field in DESCRIPTION.
>>>
>>> devtools::check() gives me:
>>>
>>> Updating secsse documentation Loading secsse Registered S3 method
>>> overwritten by 'dplyr': method from as.data.frame.tbl_df tibble
>>> Registered S3 method overwritten by 'geiger': method from
>>> unique.multiPhylo ape Error in nativeRoutines[[lib]] <- routines :
>>> object 'nativeRoutines' not found
>>
>> Do you get that error if you run "R CMD check" on the tarball of your
>> package?
>>
>> If so, how comfortable are you with debugging R code? I can tell you
>> how to debug the check process, but it's a little tricky.
>>
>> Duncan Murdoch
>>
>>>
>>>
>>> Any other suggestions?
>>>
>>> Cheers, Rampal
>>>
>>> On 02-Nov-18 08:33, Georgi Boshnakov wrote:
Try installing the latest development version of roxygen2, if you
are not using it already.
There was a bug in the released version preventing installation in
some cases.
If you don't want to use development version of roxygen2,
try putting all filenames in the Collate field in DESCRIPTION on one
line and make sure that there is a single space
between them. This should work if your problem is what I think.
By the way, in such cases you will get more informative messages if
you run devtools::check().
--
Georgi Boshnakov
From: R-package-devel [r-package-devel-boun...@r-project.org] on
behalf of Rampal Etienne [rampaletie...@gmail.com]
Sent: 01 November 2018 22:40
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] nativeRoutines error when using roxygen2 in
RStudio
Since a few weeks (after updating R-devel and Rtools) I get the
following error when trying to build a package or document it, when
using roxygen2 in RStudio:
In R CMD INSTALL Error in nativeRoutines[[lib]] <- routines : object
'nativeRoutines' not found Calls: suppressPackageStartupMessages ...
withCallingHandlers -> -> load_all -> load_dll Execution
halted
When I disable roxygen2, I do not get this error, but of course the
documentation is not created.
I have installed the latest versions of RStudio, Rtools, R-devel,
roxygen2, pkgload, but the problem persists.
Does anybody have a clue what is causing this? I am using Windows 10,
and the package contains Fortran code.
Kind regards,
Rampal Etienne
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio
Dear Georgi,
Thanks for the suggestion, but that does not work either.
I can send the code if that would help. But note that the code was
working fine until I installed a new R-devel version. But perhaps there
is an update in how the routines should be registered. I am doing it
like this:
#include
#include
#include // for NULL
#include
/* .Fortran calls */
extern void F77_NAME(fill1d)(double *vec, int *DIMP, double *parms, int
*II);
extern void F77_NAME(initmod)(void (*steadyparms)(int *, double *));
extern void F77_NAME(runmod)(int *neq, double *t, double *Conc, double
*dConc, double *yout, int *ip);
static const R_FortranMethodDef FortranEntries[] = {
{"fill1d", (DL_FUNC) &F77_NAME(fill1d), 4},
{"initmod", (DL_FUNC) &F77_NAME(initmod), 1},
{"runmod", (DL_FUNC) &F77_NAME(runmod), 6},
{NULL, NULL, 0}
};
void R_init_secsse(DllInfo *dll)
{
R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
R_useDynamicSymbols(dll, FALSE);
}
Does that look OK?
Cheers, Rampal
On 7-11-2018 12:45, Georgi Boshnakov wrote:
> Without code we are guessing. A bug is possible but I will make another
> guess suggestion.
>
> Delete all binary files created by devtools during compilation in your
> package directory.
> devtools::load_all() is so fast partly because it recompiles the C/Fortran
> files only when necessary
> but sometimes compilation may be needed even if devtools thinks otherwise.
>
> Georgi Boshnakov
>
>
> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Sent: 07 November 2018 00:26
> To: Rampal Etienne; Georgi Boshnakov; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio
>
> On 06/11/2018 5:17 PM, Rampal Etienne wrote:
>> Dear Duncan,
>>
>> I don't get it when using R CMD check.
>>
>> I only get it when building/loading using roxygen2 or when I call
>> load_all (which roxygen2 does too, I think). load_all calls load_dll
>> which then throws this error. I have registered my routines in
>> R_init_secsse.c:
>>
>> void R_init_secsse(DllInfo *dll)
>> {
>> R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
>> R_useDynamicSymbols(dll, FALSE);
>> }
>>
>> Any suggestions?
> Nope! Sounds like a bug in devtools/roxygen2, but I don't know either
> of those packages well.
>
> Duncan Murdoch
>
>> Cheers, Rampal
>>
>>
>> On 06-Nov-18 22:50, Duncan Murdoch wrote:
>>> On 06/11/2018 3:27 PM, Rampal Etienne wrote:
Dear Georgi,
Thanks for your suggestions. I have tried to install the development
version of roxygen2, but to no avail.
I don't have a Collate field in DESCRIPTION.
devtools::check() gives me:
Updating secsse documentation Loading secsse Registered S3 method
overwritten by 'dplyr': method from as.data.frame.tbl_df tibble
Registered S3 method overwritten by 'geiger': method from
unique.multiPhylo ape Error in nativeRoutines[[lib]] <- routines :
object 'nativeRoutines' not found
>>> Do you get that error if you run "R CMD check" on the tarball of your
>>> package?
>>>
>>> If so, how comfortable are you with debugging R code? I can tell you
>>> how to debug the check process, but it's a little tricky.
>>>
>>> Duncan Murdoch
>>>
Any other suggestions?
Cheers, Rampal
On 02-Nov-18 08:33, Georgi Boshnakov wrote:
> Try installing the latest development version of roxygen2, if you
> are not using it already.
> There was a bug in the released version preventing installation in
> some cases.
> If you don't want to use development version of roxygen2,
> try putting all filenames in the Collate field in DESCRIPTION on one
> line and make sure that there is a single space
> between them. This should work if your problem is what I think.
>
> By the way, in such cases you will get more informative messages if
> you run devtools::check().
>
> --
> Georgi Boshnakov
>
>
>
> From: R-package-devel [r-package-devel-boun...@r-project.org] on
> behalf of Rampal Etienne [rampaletie...@gmail.com]
> Sent: 01 November 2018 22:40
> To: r-package-devel@r-project.org
> Subject: [R-pkg-devel] nativeRoutines error when using roxygen2 in
> RStudio
>
> Since a few weeks (after updating R-devel and Rtools) I get the
> following error when trying to build a package or document it, when
> using roxygen2 in RStudio:
>
> In R CMD INSTALL Error in nativeRoutines[[lib]] <- routines : object
> 'nativeRoutines' not found Calls: suppressPackageStartupMessages ...
> withCallingHandlers -> -> load_all -> load_dll Execution
> halted
>
> When I disable roxygen2, I do not get this error, but of course the
> documentation is not created.
>
> I have installed the latest versions of RStudio, Rtools, R-devel,
> roxygen2, pkgload, but the p
Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio
After installing a new version of R the OP may have to rebuild (and retest)
packages like pkgload that define functions by grabbing functions from the
base package and modifying them, as in pkgload/R/namespace-env.r:
onload_assign("makeNamespace",
eval(
modify_lang(
extract_lang(body(loadNamespace),
# Find makeNamespace definition
comp_lang, y = quote(makeNamespace <- NULL), idx = 1:2)[[3]],
# Replace call to .Internal(registerNamespace()) is replaced by a
call to
# register_namespace
function(x) {
if (comp_lang(x, quote(.Internal(registerNamespace(name, env) {
quote(register_namespace(name, env))
} else {
x
}
}))
)
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Wed, Nov 7, 2018 at 3:45 AM, Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:
> Without code we are guessing. A bug is possible but I will make another
> guess suggestion.
>
> Delete all binary files created by devtools during compilation in your
> package directory.
> devtools::load_all() is so fast partly because it recompiles the C/Fortran
> files only when necessary
> but sometimes compilation may be needed even if devtools thinks otherwise.
>
> Georgi Boshnakov
>
>
> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Sent: 07 November 2018 00:26
> To: Rampal Etienne; Georgi Boshnakov; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in
> RStudio
>
> On 06/11/2018 5:17 PM, Rampal Etienne wrote:
> > Dear Duncan,
> >
> > I don't get it when using R CMD check.
> >
> > I only get it when building/loading using roxygen2 or when I call
> > load_all (which roxygen2 does too, I think). load_all calls load_dll
> > which then throws this error. I have registered my routines in
> > R_init_secsse.c:
> >
> > void R_init_secsse(DllInfo *dll)
> > {
> > R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
> > R_useDynamicSymbols(dll, FALSE);
> > }
> >
> > Any suggestions?
>
> Nope! Sounds like a bug in devtools/roxygen2, but I don't know either
> of those packages well.
>
> Duncan Murdoch
>
> >
> > Cheers, Rampal
> >
> >
> > On 06-Nov-18 22:50, Duncan Murdoch wrote:
> >> On 06/11/2018 3:27 PM, Rampal Etienne wrote:
> >>> Dear Georgi,
> >>>
> >>> Thanks for your suggestions. I have tried to install the development
> >>> version of roxygen2, but to no avail.
> >>>
> >>> I don't have a Collate field in DESCRIPTION.
> >>>
> >>> devtools::check() gives me:
> >>>
> >>> Updating secsse documentation Loading secsse Registered S3 method
> >>> overwritten by 'dplyr': method from as.data.frame.tbl_df tibble
> >>> Registered S3 method overwritten by 'geiger': method from
> >>> unique.multiPhylo ape Error in nativeRoutines[[lib]] <- routines :
> >>> object 'nativeRoutines' not found
> >>
> >> Do you get that error if you run "R CMD check" on the tarball of your
> >> package?
> >>
> >> If so, how comfortable are you with debugging R code? I can tell you
> >> how to debug the check process, but it's a little tricky.
> >>
> >> Duncan Murdoch
> >>
> >>>
> >>>
> >>> Any other suggestions?
> >>>
> >>> Cheers, Rampal
> >>>
> >>> On 02-Nov-18 08:33, Georgi Boshnakov wrote:
> Try installing the latest development version of roxygen2, if you
> are not using it already.
> There was a bug in the released version preventing installation in
> some cases.
> If you don't want to use development version of roxygen2,
> try putting all filenames in the Collate field in DESCRIPTION on one
> line and make sure that there is a single space
> between them. This should work if your problem is what I think.
>
> By the way, in such cases you will get more informative messages if
> you run devtools::check().
>
> --
> Georgi Boshnakov
>
>
>
> From: R-package-devel [r-package-devel-boun...@r-project.org] on
> behalf of Rampal Etienne [rampaletie...@gmail.com]
> Sent: 01 November 2018 22:40
> To: r-package-devel@r-project.org
> Subject: [R-pkg-devel] nativeRoutines error when using roxygen2 in
> RStudio
>
> Since a few weeks (after updating R-devel and Rtools) I get the
> following error when trying to build a package or document it, when
> using roxygen2 in RStudio:
>
> In R CMD INSTALL Error in nativeRoutines[[lib]] <- routines : object
> 'nativeRoutines' not found Calls: suppressPackageStartupMessages ...
> withCallingHandlers -> -> load_all -> load_dll Execution
> halted
>
> When I disable roxygen2, I do not get this error, but of course the
> documentation is not created.
>
> I have installed the latest versions of RStudio, Rtools, R-devel,
> roxygen2, pkgload, but the problem persists.
>
> Does anybody have a clue what is causing this? I
Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio
The problem was resolved by installing again a new version of devtools.
However, this new version gives other problems: devtools::check() says
the DESCRIPTION file is missing a License field, but there IS a license
field in this file.
On 7-11-2018 16:59, William Dunlap wrote:
> After installing a new version of R the OP may have to rebuild (and
> retest) packages like pkgload that define functions by grabbing
> functions from the base package and modifying them, as in
> pkgload/R/namespace-env.r:
>
> onload_assign("makeNamespace",
> eval(
> modify_lang(
> extract_lang(body(loadNamespace),
>
> # Find makeNamespace definition
> comp_lang, y = quote(makeNamespace <- NULL), idx = 1:2)[[3]],
>
> # Replace call to .Internal(registerNamespace()) is replaced by
> a call to
> # register_namespace
> function(x) {
> if (comp_lang(x, quote(.Internal(registerNamespace(name,
> env) {
> quote(register_namespace(name, env))
> } else {
> x
> }
> }))
> )
>
>
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Wed, Nov 7, 2018 at 3:45 AM, Georgi Boshnakov
> > wrote:
>
> Without code we are guessing. A bug is possible but I will make
> another guess suggestion.
>
> Delete all binary files created by devtools during compilation in
> your package directory.
> devtools::load_all() is so fast partly because it recompiles the
> C/Fortran files only when necessary
> but sometimes compilation may be needed even if devtools thinks
> otherwise.
>
> Georgi Boshnakov
>
>
> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com
> ]
> Sent: 07 November 2018 00:26
> To: Rampal Etienne; Georgi Boshnakov;
> r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] nativeRoutines error when using
> roxygen2 in RStudio
>
> On 06/11/2018 5:17 PM, Rampal Etienne wrote:
> > Dear Duncan,
> >
> > I don't get it when using R CMD check.
> >
> > I only get it when building/loading using roxygen2 or when I call
> > load_all (which roxygen2 does too, I think). load_all calls load_dll
> > which then throws this error. I have registered my routines in
> > R_init_secsse.c:
> >
> > void R_init_secsse(DllInfo *dll)
> > {
> > R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
> > R_useDynamicSymbols(dll, FALSE);
> > }
> >
> > Any suggestions?
>
> Nope! Sounds like a bug in devtools/roxygen2, but I don't know
> either
> of those packages well.
>
> Duncan Murdoch
>
> >
> > Cheers, Rampal
> >
> >
> > On 06-Nov-18 22:50, Duncan Murdoch wrote:
> >> On 06/11/2018 3:27 PM, Rampal Etienne wrote:
> >>> Dear Georgi,
> >>>
> >>> Thanks for your suggestions. I have tried to install the
> development
> >>> version of roxygen2, but to no avail.
> >>>
> >>> I don't have a Collate field in DESCRIPTION.
> >>>
> >>> devtools::check() gives me:
> >>>
> >>> Updating secsse documentation Loading secsse Registered S3 method
> >>> overwritten by 'dplyr': method from as.data.frame.tbl_df tibble
> >>> Registered S3 method overwritten by 'geiger': method from
> >>> unique.multiPhylo ape Error in nativeRoutines[[lib]] <- routines :
> >>> object 'nativeRoutines' not found
> >>
> >> Do you get that error if you run "R CMD check" on the tarball
> of your
> >> package?
> >>
> >> If so, how comfortable are you with debugging R code? I can
> tell you
> >> how to debug the check process, but it's a little tricky.
> >>
> >> Duncan Murdoch
> >>
> >>>
> >>>
> >>> Any other suggestions?
> >>>
> >>> Cheers, Rampal
> >>>
> >>> On 02-Nov-18 08:33, Georgi Boshnakov wrote:
> Try installing the latest development version of roxygen2, if you
> are not using it already.
> There was a bug in the released version preventing
> installation in
> some cases.
> If you don't want to use development version of roxygen2,
> try putting all filenames in the Collate field in DESCRIPTION
> on one
> line and make sure that there is a single space
> between them. This should work if your problem is what I think.
>
> By the way, in such cases you will get more informative
> messages if
> you run devtools::check().
>
> --
> Georgi Boshnakov
>
>
>
> From: R-package-devel [r-package-devel-boun...@r-project.org
> ] on
> behalf of Rampal Etienne [rampaletie...@gma
Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio
Also note that William's suggestion is documented at the bottom of the
"Generic Functions and Methods" section of Writing R Extensions.
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Generic-functions-and-methods
"... as a package can take over a function in the base package and
make it generic by something like
foo <- function(object, ...) UseMethod("foo")
foo.default <- function(object, ...) base::foo(object)
"Earlier versions of this manual suggested assigning foo.default <-
base::foo. This is not a good idea, as it captures the base function
at the time of installation and it might be changed as R is patched or
updated."
Best,
Josh
On Wed, Nov 7, 2018 at 10:45 AM Rampal S. Etienne
wrote:
>
> The problem was resolved by installing again a new version of devtools.
>
> However, this new version gives other problems: devtools::check() says
> the DESCRIPTION file is missing a License field, but there IS a license
> field in this file.
>
>
> On 7-11-2018 16:59, William Dunlap wrote:
> > After installing a new version of R the OP may have to rebuild (and
> > retest) packages like pkgload that define functions by grabbing
> > functions from the base package and modifying them, as in
> > pkgload/R/namespace-env.r:
> >
> > onload_assign("makeNamespace",
> > eval(
> > modify_lang(
> > extract_lang(body(loadNamespace),
> >
> > # Find makeNamespace definition
> > comp_lang, y = quote(makeNamespace <- NULL), idx = 1:2)[[3]],
> >
> > # Replace call to .Internal(registerNamespace()) is replaced by
> > a call to
> > # register_namespace
> > function(x) {
> > if (comp_lang(x, quote(.Internal(registerNamespace(name,
> > env) {
> > quote(register_namespace(name, env))
> > } else {
> > x
> > }
> > }))
> > )
> >
> >
> >
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> >
> > On Wed, Nov 7, 2018 at 3:45 AM, Georgi Boshnakov
> > > > wrote:
> >
> > Without code we are guessing. A bug is possible but I will make
> > another guess suggestion.
> >
> > Delete all binary files created by devtools during compilation in
> > your package directory.
> > devtools::load_all() is so fast partly because it recompiles the
> > C/Fortran files only when necessary
> > but sometimes compilation may be needed even if devtools thinks
> > otherwise.
> >
> > Georgi Boshnakov
> >
> >
> > -Original Message-
> > From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com
> > ]
> > Sent: 07 November 2018 00:26
> > To: Rampal Etienne; Georgi Boshnakov;
> > r-package-devel@r-project.org
> > Subject: Re: [R-pkg-devel] nativeRoutines error when using
> > roxygen2 in RStudio
> >
> > On 06/11/2018 5:17 PM, Rampal Etienne wrote:
> > > Dear Duncan,
> > >
> > > I don't get it when using R CMD check.
> > >
> > > I only get it when building/loading using roxygen2 or when I call
> > > load_all (which roxygen2 does too, I think). load_all calls load_dll
> > > which then throws this error. I have registered my routines in
> > > R_init_secsse.c:
> > >
> > > void R_init_secsse(DllInfo *dll)
> > > {
> > > R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
> > > R_useDynamicSymbols(dll, FALSE);
> > > }
> > >
> > > Any suggestions?
> >
> > Nope! Sounds like a bug in devtools/roxygen2, but I don't know
> > either
> > of those packages well.
> >
> > Duncan Murdoch
> >
> > >
> > > Cheers, Rampal
> > >
> > >
> > > On 06-Nov-18 22:50, Duncan Murdoch wrote:
> > >> On 06/11/2018 3:27 PM, Rampal Etienne wrote:
> > >>> Dear Georgi,
> > >>>
> > >>> Thanks for your suggestions. I have tried to install the
> > development
> > >>> version of roxygen2, but to no avail.
> > >>>
> > >>> I don't have a Collate field in DESCRIPTION.
> > >>>
> > >>> devtools::check() gives me:
> > >>>
> > >>> Updating secsse documentation Loading secsse Registered S3 method
> > >>> overwritten by 'dplyr': method from as.data.frame.tbl_df tibble
> > >>> Registered S3 method overwritten by 'geiger': method from
> > >>> unique.multiPhylo ape Error in nativeRoutines[[lib]] <- routines :
> > >>> object 'nativeRoutines' not found
> > >>
> > >> Do you get that error if you run "R CMD check" on the tarball
> > of your
> > >> package?
> > >>
> > >> If so, how comfortable are you with debugging R code? I can
> > tell you
> > >> how to debug the check process, but it's a little tricky.
> > >>
> > >> Duncan Murdoch
> > >>
> > >>>
> > >>>
> > >>> Any other suggestions?
> > >>>
> > >>> Cheers, Rampal
> > >>>
> > >>> On 02-Nov-18
[R-pkg-devel] ICU init failed: U_FILE_ACCESS_ERROR
I am considering a CRAN release of a new package and was using R-winbuilder as
a check. The check was successful with all but the "old-release" version (see
https://win-builder.r-project.org/UhyHnNyn4Ukz/00check.log). The two errors
both appear to be related to tests using testhtat::expect_output() and begin
with the "ICU init failed: U_FILE_ACCESS_ERROR" error message. The full output
for the first error is pasted below. My internet searches suggest (to me, but I
am not confident) that this error is related to the stringr or stringi
packages, which both appear to be used by testthat::expect_output(). Given that
I don't receive this error in any other checking, I am not sure how to
troubleshoot it (besides simply removing this test). Any thoughts would be
greatly appreciated. Thank you.
** running tests for arch 'i386' ... [5s] ERROR
Running 'test-all.R' [4s]
Running the tests in 'tests/test-all.R' failed.
Complete output:
> library(testthat)
> test_check("RFishBC")
Loading required package: RFishBC
## RFishBC v0.0.13.9000. See vignettes at derekogle.com/RFishBC/.
-- 1. Error: backCalc() output types (@test_OUTPUTS.R#272)
ICU init failed: U_FILE_ACCESS_ERROR
1: expect_output(backCalc(SMBassWB, lencap, BCM = "DALE", inFormat = "wide",
digits = 0),
"Dahl-Lea") at testthat/test_OUTPUTS.R:272
2: quasi_capture(enquo(object), capture_output, label = label)
3: capture(act$val <- eval_bare(get_expr(quo), get_env(quo)))
4: capture_output_lines(code, print, width = width)
5: eval_with_output(code, print = print, width = width)
6: withr::with_output_sink(temp, withVisible(code))
7: force(code)
8: withVisible(code)
9: eval_bare(get_expr(quo), get_env(quo))
10: backCalc(SMBassWB, lencap, BCM = "DALE", inFormat = "wide", digits = 0)
11: stringr::str_replace_all
12: getExportedValue(pkg, name)
13: asNamespace(ns)
14: getNamespace(ns)
15: tryCatch(loadNamespace(name), error = function(e) stop(e))
16: tryCatchList(expr, classes, parentenv, handlers)
17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
18: value[[3L]](cond)
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] ICU init failed: U_FILE_ACCESS_ERROR
Does it happen consistently? If it's only happened once, could be a
transient glitch in package dependencies. I'd try re-testing, as a
start. Alternatively, if you're willing to add an R >= 3.5.1 dependency
to your package, presumably CRAN won't mind if it fails tests on
old-release ...
On 2018-11-07 4:55 p.m., Derek Ogle wrote:
> I am considering a CRAN release of a new package and was using R-winbuilder
> as a check. The check was successful with all but the "old-release" version
> (see https://win-builder.r-project.org/UhyHnNyn4Ukz/00check.log). The two
> errors both appear to be related to tests using testhtat::expect_output() and
> begin with the "ICU init failed: U_FILE_ACCESS_ERROR" error message. The full
> output for the first error is pasted below. My internet searches suggest (to
> me, but I am not confident) that this error is related to the stringr or
> stringi packages, which both appear to be used by testthat::expect_output().
> Given that I don't receive this error in any other checking, I am not sure
> how to troubleshoot it (besides simply removing this test). Any thoughts
> would be greatly appreciated. Thank you.
>
> ** running tests for arch 'i386' ... [5s] ERROR
> Running 'test-all.R' [4s]
> Running the tests in 'tests/test-all.R' failed.
> Complete output:
> > library(testthat)
> > test_check("RFishBC")
> Loading required package: RFishBC
> ## RFishBC v0.0.13.9000. See vignettes at derekogle.com/RFishBC/.
>
> -- 1. Error: backCalc() output types (@test_OUTPUTS.R#272)
>
> ICU init failed: U_FILE_ACCESS_ERROR
> 1: expect_output(backCalc(SMBassWB, lencap, BCM = "DALE", inFormat =
> "wide", digits = 0),
> "Dahl-Lea") at testthat/test_OUTPUTS.R:272
> 2: quasi_capture(enquo(object), capture_output, label = label)
> 3: capture(act$val <- eval_bare(get_expr(quo), get_env(quo)))
> 4: capture_output_lines(code, print, width = width)
> 5: eval_with_output(code, print = print, width = width)
> 6: withr::with_output_sink(temp, withVisible(code))
> 7: force(code)
> 8: withVisible(code)
> 9: eval_bare(get_expr(quo), get_env(quo))
> 10: backCalc(SMBassWB, lencap, BCM = "DALE", inFormat = "wide", digits = 0)
> 11: stringr::str_replace_all
> 12: getExportedValue(pkg, name)
> 13: asNamespace(ns)
> 14: getNamespace(ns)
> 15: tryCatch(loadNamespace(name), error = function(e) stop(e))
> 16: tryCatchList(expr, classes, parentenv, handlers)
> 17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 18: value[[3L]](cond)
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] ICU init failed: U_FILE_ACCESS_ERROR
My package had this issue and still got accepted. I think it is a known
transient glitch. Just mention it when you submit.
On Wed, 7 Nov 2018 at 22:05, Ben Bolker wrote:
>
> Does it happen consistently? If it's only happened once, could be a
> transient glitch in package dependencies. I'd try re-testing, as a
> start. Alternatively, if you're willing to add an R >= 3.5.1 dependency
> to your package, presumably CRAN won't mind if it fails tests on
> old-release ...
>
>
>
> On 2018-11-07 4:55 p.m., Derek Ogle wrote:
> > I am considering a CRAN release of a new package and was using
> R-winbuilder as a check. The check was successful with all but the
> "old-release" version (see
> https://win-builder.r-project.org/UhyHnNyn4Ukz/00check.log). The two
> errors both appear to be related to tests using testhtat::expect_output()
> and begin with the "ICU init failed: U_FILE_ACCESS_ERROR" error message.
> The full output for the first error is pasted below. My internet searches
> suggest (to me, but I am not confident) that this error is related to the
> stringr or stringi packages, which both appear to be used by
> testthat::expect_output(). Given that I don't receive this error in any
> other checking, I am not sure how to troubleshoot it (besides simply
> removing this test). Any thoughts would be greatly appreciated. Thank you.
> >
> > ** running tests for arch 'i386' ... [5s] ERROR
> > Running 'test-all.R' [4s]
> > Running the tests in 'tests/test-all.R' failed.
> > Complete output:
> > > library(testthat)
> > > test_check("RFishBC")
> > Loading required package: RFishBC
> > ## RFishBC v0.0.13.9000. See vignettes at derekogle.com/RFishBC/.
> >
> > -- 1. Error: backCalc() output types (@test_OUTPUTS.R#272)
>
> > ICU init failed: U_FILE_ACCESS_ERROR
> > 1: expect_output(backCalc(SMBassWB, lencap, BCM = "DALE", inFormat =
> "wide", digits = 0),
> > "Dahl-Lea") at testthat/test_OUTPUTS.R:272
> > 2: quasi_capture(enquo(object), capture_output, label = label)
> > 3: capture(act$val <- eval_bare(get_expr(quo), get_env(quo)))
> > 4: capture_output_lines(code, print, width = width)
> > 5: eval_with_output(code, print = print, width = width)
> > 6: withr::with_output_sink(temp, withVisible(code))
> > 7: force(code)
> > 8: withVisible(code)
> > 9: eval_bare(get_expr(quo), get_env(quo))
> > 10: backCalc(SMBassWB, lencap, BCM = "DALE", inFormat = "wide", digits
> = 0)
> > 11: stringr::str_replace_all
> > 12: getExportedValue(pkg, name)
> > 13: asNamespace(ns)
> > 14: getNamespace(ns)
> > 15: tryCatch(loadNamespace(name), error = function(e) stop(e))
> > 16: tryCatchList(expr, classes, parentenv, handlers)
> > 17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> > 18: value[[3L]](cond)
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Sent from Gmail Mobile
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] ICU init failed: U_FILE_ACCESS_ERROR
Ben ... I tried two more times today and still the same issue. Perhaps it is
transient on a different time scale than what I have tested. I was hoping to
not raise the R dependency level, but had thought about that as well. Thank you
for your thoughts.
David ... thank you for the experience and advice. I will try noting that on my
submission to CRAN and see what happens. I will report back so others can see
my experience with this issue.
-Original Message-
From: R-package-devel On Behalf Of
David Hugh-Jones
Sent: Wednesday, November 7, 2018 4:24 PM
To: Ben Bolker
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] ICU init failed: U_FILE_ACCESS_ERROR
My package had this issue and still got accepted. I think it is a known
transient glitch. Just mention it when you submit.
On Wed, 7 Nov 2018 at 22:05, Ben Bolker wrote:
>
> Does it happen consistently? If it's only happened once, could be a
> transient glitch in package dependencies. I'd try re-testing, as a
> start. Alternatively, if you're willing to add an R >= 3.5.1
> dependency to your package, presumably CRAN won't mind if it fails
> tests on old-release ...
>
>
>
> On 2018-11-07 4:55 p.m., Derek Ogle wrote:
> > I am considering a CRAN release of a new package and was using
> R-winbuilder as a check. The check was successful with all but the
> "old-release" version (see
> https://win-builder.r-project.org/UhyHnNyn4Ukz/00check.log). The two
> errors both appear to be related to tests using
> testhtat::expect_output() and begin with the "ICU init failed:
> U_FILE_ACCESS_ERROR" error message.
> The full output for the first error is pasted below. My internet
> searches suggest (to me, but I am not confident) that this error is
> related to the stringr or stringi packages, which both appear to be
> used by testthat::expect_output(). Given that I don't receive this
> error in any other checking, I am not sure how to troubleshoot it
> (besides simply removing this test). Any thoughts would be greatly
> appreciated. Thank you.
> >
> > ** running tests for arch 'i386' ... [5s] ERROR
> > Running 'test-all.R' [4s]
> > Running the tests in 'tests/test-all.R' failed.
> > Complete output:
> > > library(testthat)
> > > test_check("RFishBC")
> > Loading required package: RFishBC
> > ## RFishBC v0.0.13.9000. See vignettes at derekogle.com/RFishBC/.
> >
> > -- 1. Error: backCalc() output types (@test_OUTPUTS.R#272)
>
> > ICU init failed: U_FILE_ACCESS_ERROR
> > 1: expect_output(backCalc(SMBassWB, lencap, BCM = "DALE", inFormat
> > =
> "wide", digits = 0),
> > "Dahl-Lea") at testthat/test_OUTPUTS.R:272
> > 2: quasi_capture(enquo(object), capture_output, label = label)
> > 3: capture(act$val <- eval_bare(get_expr(quo), get_env(quo)))
> > 4: capture_output_lines(code, print, width = width)
> > 5: eval_with_output(code, print = print, width = width)
> > 6: withr::with_output_sink(temp, withVisible(code))
> > 7: force(code)
> > 8: withVisible(code)
> > 9: eval_bare(get_expr(quo), get_env(quo))
> > 10: backCalc(SMBassWB, lencap, BCM = "DALE", inFormat = "wide",
> > digits
> = 0)
> > 11: stringr::str_replace_all
> > 12: getExportedValue(pkg, name)
> > 13: asNamespace(ns)
> > 14: getNamespace(ns)
> > 15: tryCatch(loadNamespace(name), error = function(e) stop(e))
> > 16: tryCatchList(expr, classes, parentenv, handlers)
> > 17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> > 18: value[[3L]](cond)
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Sent from Gmail Mobile
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] ICU init failed: U_FILE_ACCESS_ERROR
I think this error has to do with the binary version of stringi for
Windows oldrel being out-of-date in CRAN (version 1.1.7 while source is
at 1.2.4). The current version of stringi under Windows gives a
compilation note, so the binary is not available in CRAN. This causes
difficulties even with indirect dependencies (e.g. on lubridate). Even
lubridate itself is failing CRAN tests on Windows oldrel. Also one of my
packages is failing CRAN tests because it depends on lubridate. These
packages have been accepted by CRAN. The compilation note triggered when
building the stringi binary under Windows oldrel seems not to affect
stringi in use (circumstantial evidence rather than systematic checking)
and the current version of stringi can be installed from sources under
Windows oldrel and at least locally this seems to solve the type of
problems you are seeing.
Best regards,
Pedro.
On 2018-11-08 04:06, Derek Ogle wrote:
> Ben ... I tried two more times today and still the same issue. Perhaps it is
> transient on a different time scale than what I have tested. I was hoping to
> not raise the R dependency level, but had thought about that as well. Thank
> you for your thoughts.
>
> David ... thank you for the experience and advice. I will try noting that on
> my submission to CRAN and see what happens. I will report back so others can
> see my experience with this issue.
>
> -Original Message-
> From: R-package-devel On Behalf Of
> David Hugh-Jones
> Sent: Wednesday, November 7, 2018 4:24 PM
> To: Ben Bolker
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] ICU init failed: U_FILE_ACCESS_ERROR
>
> My package had this issue and still got accepted. I think it is a known
> transient glitch. Just mention it when you submit.
>
> On Wed, 7 Nov 2018 at 22:05, Ben Bolker wrote:
>
>>Does it happen consistently? If it's only happened once, could be a
>> transient glitch in package dependencies. I'd try re-testing, as a
>> start. Alternatively, if you're willing to add an R >= 3.5.1
>> dependency to your package, presumably CRAN won't mind if it fails
>> tests on old-release ...
>>
>>
>>
>> On 2018-11-07 4:55 p.m., Derek Ogle wrote:
>>> I am considering a CRAN release of a new package and was using
>> R-winbuilder as a check. The check was successful with all but the
>> "old-release" version (see
>> https://win-builder.r-project.org/UhyHnNyn4Ukz/00check.log). The two
>> errors both appear to be related to tests using
>> testhtat::expect_output() and begin with the "ICU init failed:
>> U_FILE_ACCESS_ERROR" error message.
>> The full output for the first error is pasted below. My internet
>> searches suggest (to me, but I am not confident) that this error is
>> related to the stringr or stringi packages, which both appear to be
>> used by testthat::expect_output(). Given that I don't receive this
>> error in any other checking, I am not sure how to troubleshoot it
>> (besides simply removing this test). Any thoughts would be greatly
>> appreciated. Thank you.
>>> ** running tests for arch 'i386' ... [5s] ERROR
>>>Running 'test-all.R' [4s]
>>> Running the tests in 'tests/test-all.R' failed.
>>> Complete output:
>>>> library(testthat)
>>>> test_check("RFishBC")
>>>Loading required package: RFishBC
>>>## RFishBC v0.0.13.9000. See vignettes at derekogle.com/RFishBC/.
>>>
>>>-- 1. Error: backCalc() output types (@test_OUTPUTS.R#272)
>>
>>>ICU init failed: U_FILE_ACCESS_ERROR
>>>1: expect_output(backCalc(SMBassWB, lencap, BCM = "DALE", inFormat
>>> =
>> "wide", digits = 0),
>>> "Dahl-Lea") at testthat/test_OUTPUTS.R:272
>>>2: quasi_capture(enquo(object), capture_output, label = label)
>>>3: capture(act$val <- eval_bare(get_expr(quo), get_env(quo)))
>>>4: capture_output_lines(code, print, width = width)
>>>5: eval_with_output(code, print = print, width = width)
>>>6: withr::with_output_sink(temp, withVisible(code))
>>>7: force(code)
>>>8: withVisible(code)
>>>9: eval_bare(get_expr(quo), get_env(quo))
>>>10: backCalc(SMBassWB, lencap, BCM = "DALE", inFormat = "wide",
>>> digits
>> = 0)
>>>11: stringr::str_replace_all
>>>12: getExportedValue(pkg, name)
>>>13: asNamespace(ns)
>>>14: getNamespace(ns)
>>>15: tryCatch(loadNamespace(name), error = function(e) stop(e))
>>>16: tryCatchList(expr, classes, parentenv, handlers)
>>>17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
>>>18: value[[3L]](cond)
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> --
> Sent from Gmail Mobile
>
> [[alternative HTML version deleted]]
>
> __
> R-package-
