Hey,
I am not a laywer but their terms are quite explicitly prohibiting
redistribution of their data without written consent.
Now you might build a package that does not collect, store and
redistributes the data but only allows to access the data provided there
'live' via some convenience
On 24 January 2018 at 07:55, William Dunlap wrote:
| On Linux you can trace all the getenv calls with ltrace. It only
| works on ELF files, not sh scripts:
|
| % R CMD ltrace -e getenv `R RHOME`/bin/*/R
| libR.so->getenv("R_HOME")
|= "/home/R/R-3.4.3/lib64/R"
|
On Linux you can trace all the getenv calls with ltrace. It only
works on ELF files, not sh scripts:
% R CMD ltrace -e getenv `R RHOME`/bin/*/R
libR.so->getenv("R_HOME")
= "/home/R/R-3.4.3/lib64/R"
libR.so->getenv("R_TRANSLATIONS")
= nil
The advice at the link you cite ([1]
https://stackoverflow.com/a/8638902/1664978) is not quite right:
> I believe it is a requirement that if package A imports package B, and
> package B lists package C in Depends: then package A must also list
> package C in Depends:
> A popular stackoverflow
This is implicitly OK:
If A suggests B and B depends on some R version, then B is only
available if you are running that R version anyway, hence the additional
declaration is not needed.
The typical cause of trouble is as follows:
A depends on B and B suggests C.
Then A has to suggest C in
On 24 January 2018 at 07:03, luke-tier...@uiowa.edu wrote:
| If you are picking up an R 3.4.x that is trying to load a package
| built by R-devel you should also see a warning that the package was
| built under R version 3.5.0
Yes, I am of course very aware of the issue.
But we had to separate
I believe it is a requirement that if package A imports package B, and
package B lists package C in Depends: then package A must also list
package C in Depends:
A popular stackoverflow answer states this.[1] I can't find any other
source but it makes sense.
What if package B is suggested by
On Wed, 24 Jan 2018, Uwe Ligges wrote:
On 24.01.2018 12:00, Martin Maechler wrote:
Uwe Ligges
on Wed, 24 Jan 2018 11:23:50 +0100 writes:
> On 24.01.2018 03:20, Dirk Eddelbuettel wrote:
>>
>> I am going in circles here and have lost my
Thanks to Martin, my 'RD' script now points to
~/.R/check.Renviron-Rdevel
in which I also set (or re-set)
R_LIBS="/usr/local/lib/R-devel/site-library/"
after having added this (for good measure) to my 'RD' script:
unset R_PROFILE R_RENVIRON R_LIBS
export
On 24 January 2018 at 12:00, Martin Maechler wrote:
| > Uwe Ligges
| > I guess you actually pick up anotehr version of R.
| > Carefully check what is on your PATH and perhaps some Renviron files
| > that may be around?
I did, a million times,
On 24.01.2018 12:00, Martin Maechler wrote:
Uwe Ligges
on Wed, 24 Jan 2018 11:23:50 +0100 writes:
> On 24.01.2018 03:20, Dirk Eddelbuettel wrote:
>>
>> I am going in circles here and have lost my way. I used to have means to
>> build
> Uwe Ligges
> on Wed, 24 Jan 2018 11:23:50 +0100 writes:
> On 24.01.2018 03:20, Dirk Eddelbuettel wrote:
>>
>> I am going in circles here and have lost my way. I used to have means to
>> build R-devel (still do) and use it for local
On 24.01.2018 03:20, Dirk Eddelbuettel wrote:
I am going in circles here and have lost my way. I used to have means to
build R-devel (still do) and use it for local testing (no longer do).
- Fresh build of R-devel
- One entry in .libPaths()
- I can install Rcpp, it ends up in that
13 matches
Mail list logo