Is there rational for COMPILED_BY (a make variable on Windows) and
R_COMPILED_BY (an environment variable on Windows) differing?
> system(intern=TRUE, paste(file.path(R.home("bin"), "R"), "CMD config
COMPILED_BY"))
[1] "gcc-4.9.3"
> Sys.getenv("R_COMPILED_BY")
[1] "gcc 4.9.3"
The NEWS file for R-
Interestingly, when I removed the code related to package ordinal (and hence
package ucminf), I got the same error from another package (gee) that I
suggested in the description file. So, the issue is not with package ucfminf
and probably not package gee, but something else.
My solution for now
It appears that the ucminf package was installed properly:
#> * installing *binary* package ‘ucminf’ ...
#> * ‘ucminf’ was already a binary package and will not be rebuilt
#> * creating tarball
#> packaged installation of ‘ucminf’ as
‘ucminf_1.1-4_R_x86_64-pc-linux-gnu.tar.gz’
#> * DONE (ucminf)
I think this means that the ucminf package was not installed properly.
There is probably something about it in the log
G.
On Thu, Feb 7, 2019 at 5:15 PM Goldfeld, Keith
wrote:
>
> I did just take a look at the log, which may provide some insight, though not
> to me.
>
> This is the key part
I did just take a look at the log, which may provide some insight, though not
to me.
This is the key part of the message where things go awry:
#> Error in dyn.load(file, DLLpath = DLLpath, ...) :
#> unable to load shared object '/home/docker/R/ucminf/libs/ucminf.so':
#> : cannot open shared
You probably have an error earlier in the R-hub build log that
explains why ordinal failed to install.
Gabor
On Thu, Feb 7, 2019 at 4:44 PM Goldfeld, Keith
wrote:
>
> I am using devtools::check_rhub() before submitting a new version of my
> package simstudy to CRAN. I am getting an error messag
I am using devtools::check_rhub() before submitting a new version of my package
simstudy to CRAN. I am getting an error message about a package I use in the
vignette from the Ubuntu Linux platform:
* checking package dependencies ... ERROR
Package suggested but not available: ‘ordinal’
The sugg
The obvious solution is to contact the maintainer of the package generating the
spurious warning and have it addressed 'at source'.
Probably it helps to be specific about the package generating the warning, the
nature of the warning, and a link to your package.
I would view assignInNamespace as
This in not well thought through, but what about using `sink` to capture
any messages from the call? Then you might be able to remove the
expected warning and output any remaining warnings if they are there...
However, note this part of `help(sink)`:
Sink-ing the messages stream should be done
Hello,
I'm considering a package submission. I have used assignInNamespace,
which is hideous but seems better than the alternatives. I see that it
returns a NOTE on R CMD check, suggesting that it is not absolutely
prohibited, but would require justification.
The justification I would make is tha
10 matches
Mail list logo
