[Rd] strtoi output of empty string inconsistent across platforms
Identified as root cause of a bug in data.table:
https://github.com/Rdatatable/data.table/issues/3267
On my machine, strtoi("", base = 2L) produces NA_integer_ (which seems
consistent with ?strtoi: "Values which cannot be interpreted as integers or
would overflow are returned as NA_integer_").
But on all the other machines I've seen, 0L is returned. This seems to be
consistent with the output of a simple C program using the underlying
strtol function (see data.table link for this program, and for full
sessionInfo() of some environments with differing output).
So, what is the correct output of strtoi("", base = 2L)? Is the
cross-platform inconsistency to be expected/documentable?
Michael Chirico
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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
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] 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
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
[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
[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
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
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 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: [Rd] setClass accepts slot-mismatch between slots and prototype arguments
Thanks for the report. There is a comment from 2001 in the header for
reconcilePropertiesAndPrototype() that states:
"The prototype may imply slots not in the properties list. It is not
required that the extends classes be define at this time. Should it
be?"
But somewhere in the mid 2000's, I think, it became necessary for the
extends classes to be defined, so it may be safe to add this
constraint.
I'll commit a fix soon. While fixing, I found that the type
consistency check for slots shared with superclasses was completely
broken ever since it was written in 2002.
Michael
On Thu, Jan 10, 2019 at 8:31 AM William Dunlap via R-devel
wrote:
>
> I was installing the 'diffobj' package into TERR and got an error from the
> call
> StyleSummary <- setClass("StyleSummary",
> slots=c(container="ANY", body="ANY", map="ANY"),
> prototype=list(
> container=function(x) sprintf("\n%s\n", paste0(x, collapse="")),
> body=identity,
> detail=function(x) sprintf("\n%s\n", paste0(" ", x, collapse="")),
> map=function(x) sprintf("\n%s", paste0(" ", x, collapse="\n"))
> ))
> because the prototype contained components not in the slots list. R does
> not complain about the mismatch, but new("StyleSummary") does name make
> something with a 'detail' slot. Should this be an error?
>
> I suspect that the package writer intended to include 'detail' in the slots
> argument.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setClass accepts slot-mismatch between slots and prototype arguments
Indeed that was on oversight on my part. It is surprising that things like
this work:
> setClass('test', slots=c(a='ANY'), prototype=list(a=NULL, b='hello'))
> new('test')@b
[1] "hello"
> slotNames(new('test'))
[1] "a"
I'm planning a release of diffobj right now so I will fix this, but I agree
that R should probably throw an error here.
Best,
B.
On Thursday, January 10, 2019, 11:30:13 AM EST, William Dunlap
wrote:
I was installing the 'diffobj' package into TERR and got an error from the call
StyleSummary <- setClass("StyleSummary",
slots=c(container="ANY", body="ANY", map="ANY"),
prototype=list(
container=function(x) sprintf("\n%s\n", paste0(x, collapse="")),
body=identity,
detail=function(x) sprintf("\n%s\n", paste0(" ", x, collapse="")),
map=function(x) sprintf("\n%s", paste0(" ", x, collapse="\n"))
))
because the prototype contained components not in the slots list. R does not
complain about the mismatch, but new("StyleSummary") does name make something
with a 'detail' slot. Should this be an error?
I suspect that the package writer intended to include 'detail' in the slots
argument.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setClass accepts slot-mismatch between slots and prototype arguments
I was installing the 'diffobj' package into TERR and got an error from the
call
StyleSummary <- setClass("StyleSummary",
slots=c(container="ANY", body="ANY", map="ANY"),
prototype=list(
container=function(x) sprintf("\n%s\n", paste0(x, collapse="")),
body=identity,
detail=function(x) sprintf("\n%s\n", paste0(" ", x, collapse="")),
map=function(x) sprintf("\n%s", paste0(" ", x, collapse="\n"))
))
because the prototype contained components not in the slots list. R does
not complain about the mismatch, but new("StyleSummary") does name make
something with a 'detail' slot. Should this be an error?
I suspect that the package writer intended to include 'detail' in the slots
argument.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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: [Rd] Bug in dt() function in stats - accuracy only 6 dp.
> mark chappell via R-devel > on Wed, 9 Jan 2019 13:10:26 +1100 writes: > Hi I believe the dt() function in stats has small areas of > inaccuracy. > SmallRangeMostDetaileddf150.png shows this occurring in > the 10-11th decimal place. > MyD4 is computed using Myt_NC(), at the bottom of BugL.R - > my function is very slow due to using mpfr, but i believe > accurate to the accuracy of genhypergeo() which it uses - > 14-15 dp. > LargeRangeDiffdf150.png, which is difference between dt() > and my function, shows spikes across -1.5 < x < 1.5. > I assumed probably only a problem for large df, but > SmallRangeCloseZerodf20.png, shows actually more of a > problem with > df = 20. Accuracy seems to be only to 6 decimal places. We did not get a single piece of R code. Maybe you've wanted to attach the 'BugL.R' R script mentioned above, but failed to use 'text/plain' MIME encoding? Note: If this is about using *non*central t-distribution (as the above "NC" suggests), then this is *not* a bug per se, as the help page *does* mention that the acuracy there is reduced. Still, I have created an R bugzilla account for you to report there, i.e., https://bugs.r-project.org/ Best, Martin > Using R version 3.5.2. > Cheers > Mark > [DELETED ATTACHMENT SmallRangeMostDetaileddf150.png, PNG image] > [DELETED ATTACHMENT LargeRangeDiffdf150.png, PNG image] > [DELETED ATTACHMENT SmallRangeCloseZerodf20.png, PNG image] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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
