Re: [R-pkg-devel] Incorporating external library licensces (zstd license) within package
On 09.01.19 20:18, Travers Ching wrote: > * Use of the AGPL-3 license which seems to be able to cover the ZSTD > BSD licensce. ZSTD is dual license BSD and GPL-2. So AGPL-3 is fine, as would be GPL-2 or GPL-3. > * Attach APGL-3 notice to all my source code files (excluding > auto-generated Rcpp source code). Ok. > * Add Facebook as author/contributor and add copyright notice for the > ZSTD library -- should I add the main ZSTD contributor/author (Yann > Collet)? (Attached at the bottom is my DESCRIPTION file). I would use Yann Collet as author/contributor and Facebook only as copyright holder. > License: AGPL-3 | file LICENSE What is the content of the LICENSE file? My suggestion would be something like this: Files: src/ZSTD/* Copyright: License: BSD or GPL-2 URL: ... Files: * Copyright: 2019 Travers Ching License: (c.f. https://github.com/daqana/dqrng/blob/master/LICENSE) Greetings Ralf -- Ralf Stubner Senior Software Engineer / Trainer daqana GmbH Dortustraße 48 14467 Potsdam T: +49 331 23 61 93 11 F: +49 331 23 61 93 90 M: +49 162 20 91 196 Mail: ralf.stub...@daqana.com Sitz: Potsdam Register: AG Potsdam HRB 27966 Ust.-IdNr.: DE300072622 Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze signature.asc Description: OpenPGP digital signature __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] About a need for hooks from R CMD ... commands, and a question
It just ocurred to me the following. Instead of
R CMD build pkg
I've tried this:
cd pkg; R CMD build --log `pwd`
and voilà: the tarball includes a log file, and inside there's the
complete path to the DESCRIPTION.
Iñaki
On Wed, 9 Jan 2019 at 20:33, Duncan Murdoch wrote:
>
> On 09/01/2019 11:39 a.m., Dirk Eddelbuettel wrote:
> >
> > Hi Duncan and Iñaki,
> >
> > On 4 January 2019 at 14:13, Duncan Murdoch wrote:
> > | If you want a total hack, the help system can run R code during a build,
> > | e.g. \Sexpr[stage=build]{paste("Built at", Sys.time())}. Certainly it
> > | could embed some information in a help page; perhaps it could do more.
> > | Similarly, vignettes are typically built during R CMD build, so they
> > | might be able to have useful side effects.
> > |
> > | But it seems likely that something less of a kludge would be desirable.
> >
> > A first simple
> >
> >[...]
> >
> ><>=
> >user <- Sys.getenv("USER")
> >dir <- getwd()
> >@
> >
> >[...]
> >
> >Built by '\Sexpr{user}' in directory '\Sexpr{dir}'.
> >
> > did not work. By the time that chunk is evaluate, I am already in TEMPDIR.
> >
> > Any clever ideas about I could inject code into the part that creates the
> > tarball?
>
> Same seems to be true for macros in help pages.
>
> Duncan
--
Iñaki Úcar
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] About a need for hooks from R CMD ... commands, and a question
On 9 January 2019 at 17:57, Iñaki Ucar wrote:
| Did you check Sys.getenv("OLDPWD")? I checked with a knitr vignette
| and the correct path was there.
Code:
[...]
<>=
prettyVersion <- packageVersion("someNameHere")
prettyDate <- format(Sys.Date(), "%B %e, %Y")
user <- Sys.getenv("USER")
dir <- getwd()
olddir <- Sys.getenv("OLDPWD")
@
[...]
\date{Built on \Sexpr{prettyDate} using version \Sexpr{prettyVersion}}
\maketitle
Built by '\Sexpr{user}' in directory '\Sexpr{dir}' coming from directory
'\Sexpr{olddir}'.
Comes up with an empty / unset olddir when I do
R CMD build someNameHere; R CMD INSTALL someNameHere_1.2.3.tar.gz
No mas :-/
Your idea about the logfile is fair, but I would *much* prefer to have
something unconditional.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] About a need for hooks from R CMD ... commands, and a question
On Thu, 10 Jan 2019 at 21:55, Dirk Eddelbuettel wrote:
>
>
> On 9 January 2019 at 17:57, Iñaki Ucar wrote:
> | Did you check Sys.getenv("OLDPWD")? I checked with a knitr vignette
> | and the correct path was there.
>
> Code:
>
> [...]
>
> <>=
> prettyVersion <- packageVersion("someNameHere")
> prettyDate <- format(Sys.Date(), "%B %e, %Y")
> user <- Sys.getenv("USER")
> dir <- getwd()
> olddir <- Sys.getenv("OLDPWD")
> @
>
> [...]
>
> \date{Built on \Sexpr{prettyDate} using version \Sexpr{prettyVersion}}
>
> \maketitle
>
> Built by '\Sexpr{user}' in directory '\Sexpr{dir}' coming from directory
> '\Sexpr{olddir}'.
>
> Comes up with an empty / unset olddir when I do
>
> R CMD build someNameHere; R CMD INSTALL someNameHere_1.2.3.tar.gz
This is quite interesting. Because if you run
R CMD build someNameHere/; R CMD INSTALL someNameHere_1.2.3.tar.gz
(note the "/" after the package name) then the olddir is there.
Iñaki
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] About a need for hooks from R CMD ... commands, and a question
On 10 January 2019 at 22:33, Iñaki Ucar wrote: | On Thu, 10 Jan 2019 at 21:55, Dirk Eddelbuettel wrote: | > Comes up with an empty / unset olddir when I do | > | > R CMD build someNameHere; R CMD INSTALL someNameHere_1.2.3.tar.gz | | This is quite interesting. Because if you run | | R CMD build someNameHere/; R CMD INSTALL someNameHere_1.2.3.tar.gz | | (note the "/" after the package name) then the olddir is there. Not for me. Same result as before. (That is as work on CentOS 7.5 with R 3.5.1). Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] package fails with parallel make - would forcing a serial version work?
Dear R package developers I published a package on CRAN last year (sundialr) which is now failing with as it is not make to compile a static library with parallel make. In this package, I compile a static library (libsundials_all.a) from source files of a third party. The specifics of compiling the static library can be found at - https://github.com/sn248/sundialr/blob/master/src/Makevars Now, I got the following error message from CRAN (actually, I was informed of this before, but had neglected to fix it). Here is the message from one of the CRAN maintainers .. *** This have just failed to install for me with a parallel make: g++ -std=gnu++98 -std=gnu++98 -shared -L/data/blackswan/ripley/extras/lib64 -L/usrlocal/lib64 -o sundialr.so cvode.o RcppExports.o -L/data/blackswan/ripley/R/R-patched/lib -lRlapack -L/data/blackswan/ripley/R/R-patched/lib -lRblas -lgfortran -lm -lquadmath -L../inst/ ../inst/libsundials_all.a g++: error: ../inst/libsundials_all.a: No such file or directory make[1]: *** [/data/blackswan/ripley/R/R-patched/share/make/shlib.mk:6: sundialr.so] Error 1 * It seems the package fails to generate the static library with the parallel make. The easiest solution I could think of for this problem was to force a serial version of make using the .NOTPARALLEL phony command in Makevars and Makevars.win(https://github.com/sn248/sundialr/blob/master/src/Makevars). I have made this change and it seems to work on my machine and on testing with TravisCI and Appveyor(https://github.com/sn248/sundialr). However, before I re-submit to CRAN, I wanted to get an opinion as to will this be enough to get rid of the error with parallel make? Any suggestions would be very much appreciated, thank you! Satyaprakash [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] objects are masked _by_ '.GlobalEnv'
Dear friends - this is really a question I'm sorry about since it doesn't follow the requirements. I have made a R package via RStudio and it causes problems when I try to load some data from within the package. I'm on windows, R version 3.5.1 (2018-07-02). When I am in the directory with the package project (also with plain R) > data(Schell) > library(chaRBAL) Attaches package: 'chaRBAL'my translation from Danish The following objects are masked _by_ '.GlobalEnv': Na, TOTAL, WA # BUT: the values are correct from data(Schell): > Na [1] 0.008 0.024 0.044 0.064 0.082 0.098 0.114 0.128 0.142 0.154 0.166 0.176 0.188 0.198 0.206 0.214 0.224 0.232 [19] 0.242 0.252 0.264 0.278 0.292 0.310 0.330 0.348 0.364 0.374 0.384 0.390 > TOTAL [,1] [,2] [1,] 0.004 0.098 [2,] 0.012 0.094 [3,] 0.022 0.089 [4,] 0.032 0.084 [5,] 0.041 0.079 25 more so > WA $`buffs` $`buffs`[[1]] [1] "Phos" $`buffs`[[2]] [1] "Cit" $KA $KA[[1]] [1] 6.918310e-03 6.165950e-08 4.786301e-13 $KA[[2]] [1] 7.413102e-04 1.737801e-05 3.981072e-07 # Which is all OK # But when now I make the same call again > data(Schell) ls() # [1] "Alb" "Ca""Cl""K" "Lact" "Mg""Na""PCO2" "S1" #[10] "TOTAL" "WA" TOTAL # [,1] [,2] [,3] # [1,] 0.0267 0.0267 0.0267 # [2,] 0.0200 0.0200 0.0200 # which is wrong and belongs to another included dataset. How did that happen to be caught in globalenvironment, how can I avoid that and get rid # of it? I can see I need to know more about environments. What do you think happens? All best wishes Troels Ring, MD Aalborg [[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] About a need for hooks from R CMD ... commands, and a question
Will this work for you?
I had to stash the working directory (when R CMD build is run) in an
environment variable via ~/.R/build.Renviron`
$ cat ~/.R/build.Renviron
OLDWD=${PWD}
But a Makefile tucked in vignettes directory will run and the two
files will be there in the built package. For me, I couldn't get
OLDPWD so I saved it as OLDWD instead
$ tree vignettes/
vignettes/
├── Makefile
└── Untitled.Rmd
$ more vignettes/Makefile
all:
echo ${OLDWD} > ../inst/old.txt
echo ${PWD} > ../inst/current.txt
Kyle
On Thu, Jan 10, 2019 at 3:51 PM Dirk Eddelbuettel wrote:
>
>
> On 10 January 2019 at 22:33, Iñaki Ucar wrote:
> | On Thu, 10 Jan 2019 at 21:55, Dirk Eddelbuettel wrote:
> | > Comes up with an empty / unset olddir when I do
> | >
> | > R CMD build someNameHere; R CMD INSTALL someNameHere_1.2.3.tar.gz
> |
> | This is quite interesting. Because if you run
> |
> | R CMD build someNameHere/; R CMD INSTALL someNameHere_1.2.3.tar.gz
> |
> | (note the "/" after the package name) then the olddir is there.
>
> Not for me. Same result as before. (That is as work on CentOS 7.5 with R
> 3.5.1).
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Kyle Baron | Principal Scientist I
Metrum Research Group
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] About a need for hooks from R CMD ... commands, and a question
On Thu, 10 Jan 2019 at 23:27, Dirk Eddelbuettel wrote: > > > On 10 January 2019 at 22:33, Iñaki Ucar wrote: > | On Thu, 10 Jan 2019 at 21:55, Dirk Eddelbuettel wrote: > | > Comes up with an empty / unset olddir when I do > | > > | > R CMD build someNameHere; R CMD INSTALL someNameHere_1.2.3.tar.gz > | > | This is quite interesting. Because if you run > | > | R CMD build someNameHere/; R CMD INSTALL someNameHere_1.2.3.tar.gz > | > | (note the "/" after the package name) then the olddir is there. > > Not for me. Same result as before. (That is as work on CentOS 7.5 with R > 3.5.1). Silly me... It was showing my last cd! Of course! So what about the very hacky... cd ./anRpackage; cd ..; R CMD build anRpackage; R CMD INSTALL anRpackage_*.gz Iñaki __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] About a need for hooks from R CMD ... commands, and a question
We have a winner! (By bending the rules.)
On 10 January 2019 at 16:44, Kyle Baron wrote:
| Will this work for you?
|
| I had to stash the working directory (when R CMD build is run) in an
| environment variable via ~/.R/build.Renviron`
|
| $ cat ~/.R/build.Renviron
| OLDWD=${PWD}
That is less unconditional that I desired, but it works.
| But a Makefile tucked in vignettes directory will run and the two
| files will be there in the built package. For me, I couldn't get
| OLDPWD so I saved it as OLDWD instead
|
| $ tree vignettes/
| vignettes/
| ├── Makefile
| └── Untitled.Rmd
|
| $ more vignettes/Makefile
|
| all:
| echo ${OLDWD} > ../inst/old.txt
| echo ${PWD} > ../inst/current.txt
Then 'current.txt' is as before a temporary directory per R's build
conventions, but old.txt does indeed contain the source directory.
Close enought :)
Thanks very much for passing that creative hack along!
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] objects are masked _by_ '.GlobalEnv'
On 09/01/2019 2:16 a.m., Troels Ring wrote: Dear friends - this is really a question I'm sorry about since it doesn't follow the requirements. I have made a R package via RStudio and it causes problems when I try to load some data from within the package. I'm on windows, R version 3.5.1 (2018-07-02). When I am in the directory with the package project (also with plain R) data(Schell) library(chaRBAL) Attaches package: 'chaRBAL'my translation from Danish The following objects are masked _by_ '.GlobalEnv': Na, TOTAL, WA You have those objects in your workspace. If you refer to them by name (e.g. typing Na, TOTAL, or WA), you'll see the ones in the workspace, not in your package. To avoid this message, clean up your workspace, so there's nothing there. # BUT: the values are correct from data(Schell): Na [1] 0.008 0.024 0.044 0.064 0.082 0.098 0.114 0.128 0.142 0.154 0.166 0.176 0.188 0.198 0.206 0.214 0.224 0.232 [19] 0.242 0.252 0.264 0.278 0.292 0.310 0.330 0.348 0.364 0.374 0.384 0.390 That likely means that they are the same in both places. TOTAL [,1] [,2] [1,] 0.004 0.098 [2,] 0.012 0.094 [3,] 0.022 0.089 [4,] 0.032 0.084 [5,] 0.041 0.079 25 more so WA $`buffs` $`buffs`[[1]] [1] "Phos" $`buffs`[[2]] [1] "Cit" $KA $KA[[1]] [1] 6.918310e-03 6.165950e-08 4.786301e-13 $KA[[2]] [1] 7.413102e-04 1.737801e-05 3.981072e-07 # Which is all OK # But when now I make the same call again data(Schell) ls() # [1] "Alb" "Ca""Cl""K" "Lact" "Mg""Na""PCO2" "S1" #[10] "TOTAL" "WA" TOTAL # [,1] [,2] [,3] # [1,] 0.0267 0.0267 0.0267 # [2,] 0.0200 0.0200 0.0200 # which is wrong and belongs to another included dataset. How did that happen to be caught in globalenvironment, how can I avoid that and get rid # of it? I can see I need to know more about environments. What do you think happens? Something changed them. Duncan Murdoch All best wishes Troels Ring, MD Aalborg [[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
