Re: [R-pkg-devel] NOTE: Error while checking: invalid 'envir'-argument
Hi Alexandra, Is it possible to narrow down a bit more where the message comes from? That error message doesn't give much of a clue. -pd > On 09 Jul 2015, at 15:07 , Alexandra Kuznetsova wrote: > > Hi all, > > I am checking the package with the -as-cran option using R Under development > (unstable) (2015-07-08 r68642). I get the following NOTE: Error while > checking: invalid 'envir'-argument. Does anyone know how to fix that NOTE? I > do not get it with the R 2.3.1 > > Alexandra > > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE: Error while checking: invalid 'envir'-argument
> On 09 Jul 2015, at 20:56 , Martin Maechler wrote:
>
>
>> Alexandra,
>> I got the same error for this line of code:
>
>> e <- new.env()
>> data("mydataset", envir=e)
>
>> As you said it doesn't appear for R 3.2.1. I don't know why that should
>> be wrong and would be interested to know, but my hack is this:
>
>> e <- new.env()
>> do.call("data", list("mydataset", envir=e))
>
>> Hana
>
> Hmm, that would look like a bug in your version of R-devel.
> In my version of "R-devel" (and R 3.2.1, and "R 3.2.1 patched"),
> I get
>
>> rm(e); e <- new.env(); data(votes.repub, envir=e); ls(e); dim(e$votes.repub)
> [1] "votes.repub"
> [1] 50 31
>>
>
>> R.version.string
> [1] "R Under development (unstable) (2015-07-07 r68640)"
>>
>
> What is your R.version.string very you see the problem?
> What's
> sessionInfo() ?
>
> Best,
> Martin
I suspect that that is not the way to check it, Martin. As I understand it, the
warning comes during R CMD check, possibly via one of the static code analysis
checks. So what you really should do is write a package with the construction
inside one of its functions or help files, and then try R CMD check --as-cran
on it. I tried a simpler way:
> library(codetools)
> foo <- function(){e <- new.env(); data("airquality", envir=e); e}
> checkUsage(foo, all=TRUE)
but that doesn't trigger the issue either...
-pd
>
>> On 7/9/15 10:24 AM, peter dalgaard wrote:
>>> Hi Alexandra,
>>>
>>> Is it possible to narrow down a bit more where the message comes from? That
>>> error message doesn't give much of a clue.
>>>
>>> -pd
>>>
>>>> On 09 Jul 2015, at 15:07 , Alexandra Kuznetsova wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I am checking the package with the -as-cran option using R Under
>> development (unstable) (2015-07-08 r68642). I get the following NOTE:
>> Error while checking: invalid 'envir'-argument. Does anyone know how to
>> fix that NOTE? I do not get it with the R 2.3.1
>>>>
>>>> Alexandra
>>>>
>>>>
>>>>[[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
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel
gt; }
> onClick <- function() tkfocus(packageBox)
> tkbind(packageBox, "", onClick)
> onOK <- function(){
> datasetName <-
> datasets[as.numeric(tkcurselection(datasetBox)) + 1]
> dsnameValue <- tclvalue(dsname)
> if (dsnameValue != "" && is.null(package)){
> closeDialog()
> if (is.element(dsnameValue, listDataSets())) {
> if ("no" ==
> tclvalue(checkReplace(dsnameValue, gettextRcmdr("Data set"{
> if (GrabFocus()) tkgrab.release(top)
> tkdestroy(top)
> readDataFromPackage()
> return()
> }
> }
> save.options <- options(warn=2)
> check <- try(eval(parse(text=logger(paste("data(",
> dsnameValue, ")", sep=""))),
> envir=.GlobalEnv),
> silent=TRUE)
> options(save.options)
> if (class(check) == "try-error"){
> errorCondition(recall=readDataFromPackage,
>
> message=sprintf(gettextRcmdr("Data set %s does not exit"), dsnameValue))
> return()
> }
> activeDataSet(dsnameValue)
> tkfocus(CommanderWindow())
> }
> else{
> if (is.null(package)) {
> errorCondition(recall=readDataFromPackage,
> message=gettextRcmdr("You must select a package."))
> return()
> }
> if (length(datasetName) == 0) {
> errorCondition(recall=readDataFromPackage,
> message=gettextRcmdr("You must select a data set."))
> return()
> }
> if (is.element(datasetName, listDataSets())) {
> if ("no" ==
> tclvalue(checkReplace(datasetName, gettextRcmdr("Data set"{
> if (GrabFocus()) tkgrab.release(top)
> tkdestroy(top)
> readDataFromPackage()
> return()
> }
> }
> closeDialog()
> command <- paste("data(", datasetName, ',
> package="', package, '")', sep="")
> result <- justDoIt(command)
> logger(command)
> if (class(result)[1] != "try-error")
> activeDataSet(datasetName)
> tkfocus(CommanderWindow())
> }
> }
> onDataHelp <- function(){
>datasetName <- datasets[as.numeric(tkcurselection(datasetBox)) + 1]
> dsnameValue <- tclvalue(dsname)
> if (dsnameValue == "") dsnameValue <- datasetName
> if (length(dsnameValue) == 0) Message(gettextRcmdr("No data
> set selected."), type="warning")
> else if (is.null(package)) doItAndPrint(paste('help("',
> dsnameValue, '")', sep=""))
> else doItAndPrint(paste('help("', dsnameValue, '",
> package="', package, '")', sep=""))
> }
> OKCancelHelp(helpSubject="data")
> dataHelpButton <- buttonRcmdr(top, text=gettextRcmdr("Help on
> selected data set"), command=onDataHelp)
> tkgrid(labelRcmdr(packageDatasetFrame, text=gettextRcmdr("Package
> (Double-click to select)"), fg=getRcmdr("title.color"),
> font="RcmdrTitleFont"),
> labelRcmdr(packageDatasetFrame, text=" "),
> labelRcmdr(packageDatasetFrame, text=gettextRcmdr("Data set (Double-click to
> select)"),
> fg=getRcmdr("title.color"),
> font="RcmdrTitleFont"), sticky="w")
> tkgrid(packageBox, packageScroll, sticky="nw")
> tkgrid(datasetBox, datasetScroll, sticky="nw")
> tkgrid(packageFrame, labelRcmdr(packageDatasetFrame, text=" "),
> datasetFrame, sticky="nw")
> tkgrid(packageDatasetFrame, sticky="w")
> tkgrid(labelRcmdr(top, text=gettextRcmdr("OR"), fg="red"),
> sticky="w")
> tkgrid(labelRcmdr(enterFrame, text=gettextRcmdr("Enter name of data
> set: "), fg=getRcmdr("title.color"), font="RcmdrTitleFont"), entryDsname,
> sticky="w")
> tkgrid(enterFrame, sticky="w")
> tkgrid(dataHelpButton, sticky="w")
> tkgrid(buttonsFrame, sticky="ew")
> tkgrid.configure(packageScroll, sticky="ns")
> tkgrid.configure(datasetScroll, sticky="ns")
> tkbind(packageBox, "", onPackageSelect)
> tkbind(datasetBox, "", onDatasetSelect)
> dialogSuffix(focus=entryDsname)
> }
>
> snip --
>
> Any insight into the problem would be appreciated.
>
> Thanks,
> John
>
> ---
> John Fox, Professor
> McMaster University
> Hamilton, Ontario, Canada
> http://socserv.socsci.mcmaster.ca/jfox/
>
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel
The danger of minimal examples is that you risk working around only one aspect.
The ones Alexandra had (from the sensR package) didn't (all?) involve data(). A
couple of them were like the one below, in which the FORTRANesque style of
naming the function the same as the variable with the eventual return value is
a bit curious, but hardly illegal.
Then again, the version of sensR that she linked to hadn't had the namespace
issues sorted, so there was quite a bit of "no visible global" messages as
well.
twoAFC <- function() {
twoAFC <- binomial()
twoAFC$link <- "Link for the 2-AFC test"
twoAFC$linkinv <- function(eta) {
ok <- eta > 0
eta[!ok] <- 0.5
eta[ok] <- pnorm(eta[ok] / sqrt(2))
pmin(pmax(eta, 0.5), 1) ## restrict to [0.5, 1] - just to be sure
}
twoAFC$mu.eta <- function(eta) {
ok <- eta >= 0
eta[!ok] <- 0
if(any(ok)) {
sqrt.2 <- sqrt(1/2)
eta[ok] <- dnorm(eta[ok] * sqrt.2) * sqrt.2
}
pmax(eta, 0) ## gradient cannot be negative.
}
twoAFC$linkfun <- function(mu) {
ok <- mu > 0.5 & mu < 1
mu[mu <= 0.5] <- 0
mu[mu >= 1] <- Inf
mu[ok] <- sqrt(2) * qnorm(mu[ok])
pmax(mu, 0) ## delta cannot be negative
}
twoAFC
}
-pd
(In a hotel room in Aarhus, so not going to spend time on this for a couple of
days.)
> On 14 Jul 2015, at 01:01 , Duncan Murdoch wrote:
>
> It happened in r68597. In my example, I hadn't imported the data()
> function from utils; when I did that, it was fixed.
>
> Not sure why the error is complaining about the envir argument.
>
> Duncan Murdoch
>
> On 13/07/2015 6:47 PM, John Fox wrote:
>> Dear Duncan and Peter,
>>
>> I've just arrived at more or less the same thing:
>>
>> foo <- function() data(package="MASS")
>>
>> bar <- function() data(package="MASS", envir=.GlobalEnv)
>>
>> baz <- function() data(package="MASS", envir=globalenv())
>>
>> all trigger the note when included with the Rcmdr sources:
>>
>> * checking R code for possible problems ... NOTE
>> bar: Error while checking: invalid 'envir' argument
>> baz: Error while checking: invalid 'envir' argument
>> foo: Error while checking: invalid 'envir' argument
>>
>> The envir argument to data() defaults to .GlobaEnv .
>>
>> I hope this helps,
>> John
>>
>>> -Original Message-
>>> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
>>> Sent: July-13-15 6:32 PM
>>> To: John Fox; 'peter dalgaard'
>>> Cc: r-package-devel@r-project.org
>>> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-devel
>>>
>>> On 13/07/2015 5:23 PM, John Fox wrote:
>>>> Dear Peter,
>>>>
>>>>> -Original Message-
>>>>> From: peter dalgaard [mailto:pda...@gmail.com]
>>>>> Sent: July-13-15 4:52 PM
>>>>> To: John Fox
>>>>> Cc: r-package-devel@r-project.org
>>>>> Subject: Re: [R-pkg-devel] "invalid 'envir' argument" note from R-
>>> devel
>>>>>
>>>>> Yes, there was a similar note from Alexandra Kuznetsova a couple of
>>> days
>>>>
>>>> Sorry, I didn't notice that.
>>>>
>>>>> ago. Look unintentional, but it is not easy to spot what triggers it.
>>> If
>>>>> someone could cook up a minimal example, or - maybe easier given the
>>>>> relatively short timeframe - bisect their way to the exact svn
>>> revision
>>>>> that triggered it, it might help in getting it fixed.
>>>>
>>>> I'm afraid that I'm not set up to build R-devel and I'm about to leave
>>> town
>>>> for three weeks. I'll see if I can produce a simpler example
>>> triggering the
>>>> error, however.
>>>
>>> Hana Sevcikova posted a simple example. I'll bisect on it.
>>>
>>> Here's her example:
>>>
>>> e <- new.env()
>>> data("mydataset", envir=e)
>>>
>>> I've substituted USArrests for "mydataset".
>>>
>>> Duncan Murdoch
>>>
>>>>
>>>> Thanks for this,
>>>> John
>>>>
>>>>>
>>>>> -pd
>>>>>
>>>>>> On 13 Jul 2015, at 22:31 , John Fox wrote:
>>
Re: [R-pkg-devel] Setting up R-devel in Linux Mint 17.1 64-bit
me/hzambran/SVN/R-devel/trunk/src/extra/tre' > make[4]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/extra/tre' > make[4]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/extra/tre' > make[4]: `libtre.a' is up to date. > make[4]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/extra/tre' > make[3]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/extra/tre' > make[2]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/extra' > make[2]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/appl' > make[3]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/appl' > make[3]: `libappl.a' is up to date. > make[3]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/appl' > make[2]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/appl' > make[2]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/nmath' > make[3]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/nmath' > make[3]: `libnmath.a' is up to date. > make[3]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/nmath' > make[2]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/nmath' > make[2]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/unix' > make[3]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/unix' > make[3]: `libunix.a' is up to date. > make[3]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/unix' > make[3]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/unix' > ccache gcc -I. -I../../src/include -I../../src/include > -I/usr/local/include -DHAVE_CONFIG_H -fopenmp -fpic -ggdb -pipe > -std=gnu99 -Wall -pedantic -L/usr/local/lib > -DR_HOME='"/home/hzambran/SVN/R-devel/trunk"' \ > -o Rscript ./Rscript.c > make[3]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/unix' > make[2]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/unix' > make[2]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/main' > make[3]: Entering directory `/home/hzambran/SVN/R-devel/trunk/src/main' > ccache gcc -shared -fopenmp -L/usr/local/lib -o libR.so > CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o > arithmetic.o array.o attrib.o bind.o builtin.o character.o coerce.o > colors.o complex.o connections.o context.o cum.o dcf.o datetime.o > debug.o deparse.o devices.o dotcode.o dounzip.o dstruct.o duplicate.o > edit.o engine.o envir.o errors.o eval.o format.o gevents.o gram.o > gram-ex.o graphics.o grep.o identical.o inlined.o inspect.o internet.o > iosupport.o lapack.o list.o localecharset.o logic.o main.o mapply.o > match.o memory.o names.o objects.o options.o paste.o platform.o plot.o > plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o > qsort.o random.o raw.o registration.o relop.o rlocale.o saveload.o > scan.o seq.o serialize.o sort.o source.o split.o sprintf.o startup.o > subassign.o subscript.o subset.o summary.o sysutils.o times.o unique.o > util.o version.o g_alab_her.o g_cntrlify.o g_fontdb.o g_her_glyph.o > xxxpr.o `ls ../unix/*.o ../appl/*.o ../nmath/*.o` > ../extra/tre/libtre.a-lblas -lgfortran -lm -lquadmath -lreadline > -lpcre -llzma -lbz2 -lz -lrt -ldl -lm -licuuc -licui18n > /usr/bin/ld: ../appl/dchdc.o: relocation R_X86_64_32 against `.rodata' > can not be used when making a shared object; recompile with -fPIC > ../appl/dchdc.o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > make[3]: *** [libR.so] Error 1 > make[3]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/main' > make[2]: *** [R] Error 2 > make[2]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src/main' > make[1]: *** [R] Error 1 > make[1]: Leaving directory `/home/hzambran/SVN/R-devel/trunk/src' > make: *** [R] Error 1 > *** Done -- now run 'make install' > > > Any thoughts what I'm doing wrong ? > > > Mauricio > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Setting up R-devel in Linux Mint 17.1 64-bit
> On 21 Jul 2015, at 08:12 , Johannes Ranke wrote: > >>> >>> Could you guys move to r-devel? This has nothing to do with _package_ >>> development. > > OK, the details of how to configure a build are maybe a bit too far off... > But > in general, testing with a recent development build is an important part of > submitting packages to CRAN, so it seems to me that this list may serve to > collect information on how this can be done? In a word: No. So is getting R installed in the first place, running it on a Mac, sorting out library dependencies, etc. All of these things have their own mailing lists, full of people that know about stuff. We do not want to duplicate their content here, possibly with lesser competence. Plus, it clogs up the archives of _this_ list. -pd -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Bug? Makevars ignores FC=mpif90
> On 10 Aug 2015, at 19:25 , Ignacio Martinez wrote: > > Hi, > > I'm learning to develop R packages that use Fortran (and MPI). I recently > asked a question on stack-overflow and I was told to contact this list with > a followup question. > > When I add to src/Makevars the follwoing line > > FC=mpif90 > > Rstudio ignores it when I click `Build and Reload`. But, if I create a > Makevars file in a .R/ directory in my$HOME directory with that line, > Rstudio uses mpif90. > > Is the fact that R is ignoring the src/Makevars a bug? If not, am I doing > something wrong? > Ask differently: Does it say anywhere that the build process should use src/Makevars? Also notice that an important part of the package concept is that packages can be distributed. The recipient's Fortran compiler is not necessarily "mpif90". So, generally speaking, build configuration belongs in the build environment, not in the package. -pd > Thanks, > > Ignacio > > > PS: I hope this is the right place to ask this question. > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Bug? Makevars ignores FC=mpif90
> On 10 Aug 2015, at 19:47 , Ignacio Martinez wrote: > > Thanks peter. > > 1. Does it say anywhere that the build process should use src/Makevars? > I'm not sure, where should it say that? I'm using the default options in > Rstudio to create a package It actually is discussed in Writing R Extensions. (I was half-expecting it not to be there.) But you should read it very carefully, in particular the sections about which variables you want to set in it, and which ones you do not. In very concrete terms, notice that src/Makevars is read _before_ $RHOME/etc/Makeconf. The latter sets FC, so overwrites whatever it was set to in src/Makevars. > 2. Also notice that an important part of the package concept is that packages > can be distributed. > The package that i want to build uses MPI. Is that a problem? My > understanding is that in order to use MPI i have to set FC to mpif90. Is that > wrong? It's wrong (or at least not right) to set it in the package sources, because someone else might have to set FC differently. > 3. build configuration belongs in the build environment > I'm not sure if I follow. What is the correct way of telling Rstudio that the > package i'm building uses MPI? Wouldn't know. You already know how to do it by settings in a personal Makevars file. It is not obvious that there is a general way of specifying that one needs to use a special kind of compiler. -pd > Thanks again! > > PS: This is the link to my question in stack-overflow > > > > On Mon, Aug 10, 2015 at 1:41 PM peter dalgaard wrote: > > > On 10 Aug 2015, at 19:25 , Ignacio Martinez wrote: > > > > Hi, > > > > I'm learning to develop R packages that use Fortran (and MPI). I recently > > asked a question on stack-overflow and I was told to contact this list with > > a followup question. > > > > When I add to src/Makevars the follwoing line > > > > FC=mpif90 > > > > Rstudio ignores it when I click `Build and Reload`. But, if I create a > > Makevars file in a .R/ directory in my$HOME directory with that line, > > Rstudio uses mpif90. > > > > Is the fact that R is ignoring the src/Makevars a bug? If not, am I doing > > something wrong? > > > > Ask differently: Does it say anywhere that the build process should use > src/Makevars? > > Also notice that an important part of the package concept is that packages > can be distributed. The recipient's Fortran compiler is not necessarily > "mpif90". So, generally speaking, build configuration belongs in the build > environment, not in the package. > > -pd > > > Thanks, > > > > Ignacio > > > > > > PS: I hope this is the right place to ask this question. > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com > > > > > > > > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Using the correct R binary in configure script
> On 26 Sep 2015, at 17:43 , Dirk Eddelbuettel wrote: > > R_HOME is set to the result of the command R RHOME if and only it is unset. > > And it usually is unset. Did you actually mean that, Dirk? I would expect that R_HOME would be set by "myR CMD whatever" before it got to the configure script, so that the default R would only be used as a last resort. And R rather actively defends itself against R_HOME being set in its environment. E.g. $ R_HOME=/tmp R CMD env | grep R_HOME WARNING: ignoring environment value of R_HOME R_HOME=/Library/Frameworks/R.framework/Resources (I'm not sure that it is actually supposed to work, but apparently R CMD foo executes 'foo' in the same environment as R CMD check et al.) -pd -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check NOTE - Long paths in package
On 13 Oct 2015, at 09:42 , Uwe Ligges wrote: > > > On 13.10.2015 09:01, Barry Rowlingson wrote: >> On Tue, Oct 13, 2015 at 4:16 AM, Dirk Eddelbuettel wrote: >>> >>> On 12 October 2015 at 13:13, Charles Determan wrote: >>> | Greetings, >>> | >>> | I have a package which provides headers for a C++ library (similar to the >>> | BH package). However, the C++ library has some heavily nested components >>> | within its' structure so when I run R CMD check I get the following NOTE: >>> | >>> | Tarballs are only required to store paths of up to 100 bytes and cannot >>> | store those of more than 256 bytes, with restrictions including to 100 >>> | bytes for the final component. >>> | >>> | Is this a major problem? >>> >>> Yes. >>> >>> | As this is a 'NOTE' I am under the impression >>> | that the long paths are not critical but I want to make sure. >>> >>> Wrong. >>> >>> 'BH' is called 'BH', believe it or not, to save a few letters, or else I >>> would have a dozen or more files complain for the very same reason (and CRAN >>> reject it for non-suitable path/filenames). Hence not 'BoostHeaders' but >>> just 'BH'. And see the ChangeLog of BH and revel in how _each_ release has >>> to >>> rename one of the Runge-Kutta integration files to make the 'net' path >>> length >>> be suitable for R packing. >>> >>> There is no point in ignoring the output of R CMD check unless you _really_ >>> know better. >> >> But is it worth asking if the NOTE's restriction could be lifted, >> given that from what I read on wikipedia that the "tar" file format >> has been happy with long path names since 2001? Given that R-Core/CRAN >> sometimes refer to R versions from a year ago as "obsolete", how can >> they complain about sticking with a file format restriction from the >> last century? I've just happily made a tar file with a path that is >> 1300 chars long containing a file with a name of 160 chars . >> >> Or are there still old versions of tar around, or other file systems >> with restrictive naming practices (in which case the error should be >> about the names/paths of the files themselves, not that old versions >> of tar can't cope with them)? > > Yes, some Unixes seem to have old tar versions installed. Yes, it is somewhat harder to deem entire OSs obsolete... But: How old versions and how common is the issue? Mainstream Unix is essentially Linux and OS X these days. OS X seems to be stuck in 2010 (BSD tar 2.8.3), at least up until Yosemite. Linux distros usually keep themselves up to date, except for the enterprise/long upgrade cycle ones that can be like 5 years outdated. Less common, but still in use, are FreeBSD, Solaris and AIX. It _is_ a valid question for how long we want out-of-the-box support for OSs that use obsolete tools. At some point we could decide that the more obscure Unices would have to install a recent version (with the R configuration arranging to set TAR=/usr/local/bin/gtar or somesuch). -pd > > Best, > Uwe Ligges > >> >> It now seems to have bothered at least two people and Dirk sounds >> like he's had to implement a little hack to keep the path names down. >> >> Barry >> >> __ >> 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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R-devel installation and libcurl
> On 16 Oct 2015, at 18:33 , Martyn Plummer wrote:
>
> On Fri, 2015-10-16 at 21:46 +1100, Jim Lemon wrote:
>> Hi,
>> I have been attempting to install R-devel to check updated packages for
>> CRAN. After reading the relevant section in R Installation and
>> Administration, searching and a lot of unsuccessful fiddling with
>> "configure", I thought I might as well ask.
>>
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Fedora 21 (Twenty One)
>>
>> locale:
>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
>> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
>> [9] LC_ADDRESS=C LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> configure hits the wall when checking for libcurl. I installed libcurl
>> v7.37.0 and while it is recognized, I have not succeeded in getting it to
>> find curl.h (it's in /usr/include/curl/curl.h). R Installation ahd
>> Administration seems to suggest that the path information should be put in
>> MkRules.local. However, that file is nowhere to be found. Neither can I
>> find any variable in "configure" that specifies where to look for curl.h.
>>
>> I'm sure that this is very simple, but if anyone can provide a method to
>> stop the:
>>
>> ...
>> checking curl/curl.h usability... no
>> checking curl/curl.h presence... no
>> checking for curl/curl.h... no
>> configure: error: libcurl >= 7.28.0 library and headers are required with
>> support for https
>>
>> error I would be most grateful.
>
> This may be a little bit off topic for this list, since it is not an
> issue with your package, but I'll try to answer anyway.
Also, a generic piece of advice: configure doesn't always get its error
messages precisely right. Sometimes it is useful to go through the config.log
and see exactly what program failed to compile with what error message. It's
not that unusual to see an include file test program failing due to wrong
compiler flags or libraries.
-pd
> The header file /usr/include/curl/curl.h is provided by both the 32-bit
> and 64-bit versions of libcurl-devel. I can reproduce your error if I
> have libcurl-devel.i686 installed (which provides the header) but not
> libcurl-devel.x86_64 (which is needed to compile the 64-bit version of
> R). This gives me the following output:
>
> checking for curl-config... /usr/bin/curl-config
> checking libcurl version ... 7.37.0
> Package libcurl was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libcurl.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'libcurl' found
> checking curl/curl.h usability... no
> checking curl/curl.h presence... no
> checking for curl/curl.h... no
> configure: error: libcurl >= 7.28.0 library and headers are required
> with support for https
>
> Martyn
>
>> Jim
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> ---
> This message and its attachments are strictly confidenti...{{dropped:8}}
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Namespace: summary of all undefined globals
The "release branch", currently 3.2.x, by principle contains patch releases of 3.2.0 (i.e. bug fix releases; we do occasionally let new features slip in, but only if they are truly orthogonal to existing code, which is usually not the case in the QA/QC areas). If something was in r-devel in July, then it will have been slated for 3.3.0. The most obvious way to get hold of the feature is to install/build a current version of R-devel. Otherwise, you have to port the code to the release branch yourself. -pd > On 22 Dec 2015, at 11:34 , Patrick Giraudoux > wrote: > > Dear listers, > > Kurt (subject "CRAN packages maintained by you" sent on 02/07/2015) was > mentionning to package maintainers that "with current versions of r-devel, > one can get a convenient summary of all undefined globals" and describing how > to get a summary conveniently. > > Now I am using R 3.2.3 but cannot get this by using rcmd check --as-cran > mypackage, the "traditionnal" namespace with obviously incomplete declaration > going through the check 'checking R code for possible problems' with no note. > > Can you confirm that the implementation of R-devel in July, is still NOT in R > 3.2.3 and that one should still use the current version of r-devel to get a > summary of undefined globals (through notes after 'checking R code for > possible problems) ? Is there a way to get it from R 3.2.3 ? > > Thanks in advance, > > Patrick > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Namespace error
On 17 Feb 2016, at 10:25 , Gábor Csárdi wrote: > On Wed, Feb 17, 2016 at 1:04 AM, Duncan Murdoch > wrote: >> On 16/02/2016 12:14 PM, Glenn Schultz wrote: >>> >>> All >>> >>> I am not sure why I am getting this error and I cannot find anything on >>> the net other than try to restart R. I am >>> using Roxygen2 and it clearly says don't edit by hand at the top of the >>> namespace so I am stuck as what to do or look for. >> >> >> You will need to contact the Roxygen2 maintainers about this. We don't >> support it. > > So, this mailing list is about developing packages using base R > packages only and exclusively? > > I suggest that the owners clarify this on the "about" page, because I > totally missed it, and almost answered this question. :) Well, by all means, then It's like r-help. Sometimes a question seems better directed at RStudio support or the platform specific mailing lists, and people get redirected, but hey, we're supposed to be friendly in here, so if you happen to know the answer, just tell. (The list was mainly set up to facilitate issues between CRAN and package maintainers, so the expertise that you can assume to be present is that of people who know why CRAN is being picky, etc. There's little point in keeping the expertise of others out, but there's a blurry line towards doing 3rd party maintainers' work for them.) -pd > > Gabor > >> Duncan Murdoch > [...] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package was removed from CRAN "despite reminders" -- but I did not receive any such messages
& check your spam folders... -pd > On 01 Jun 2016, at 15:31 , Mark van der Loo wrote: > > Mail the CRAN team. > > On Wed, Jun 1, 2016, 10:24 Dean Attali wrote: > >> My package 'ddpcr' was accepted into CRAN in 2016-02-19 and then updated on >> 2016-03-17. There were no errors or warnings or notes in my submission and >> it was accepted right away. >> >> I just tried going to its CRAN page and I found out that the package was >> removed a month ago. >> https://cran.r-project.org/web/packages/ddpcr/index.html >> >> The text on the page reads "Archived on 2016-05-02 as check problems were >> not corrected despite reminders." I'm not sure what check problems it's >> referring to as I never received any communication from CRAN or from >> anybody else about this. Neither did I receive any "reminders". >> >> Is there any way for me to see what problems exactly it was having? Is it >> ok for me to try to just re-submit the package? >> >> Thanks >> >> --- >> http://deanattali.com >> >>[[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Recommendation on qr method export
Not strictly what you're asking, but at some point it may be important to note that the "QR" method used by lm() and friends (notably anova() and aov()) actually relies on successive orthogonalization. This does yield a QR decomposition but the reverse is not true. A generic X=QR decomposition does orthogonalize, but it does not necessarily hold that the first k columns of Q spans the same subspace as the first k columns of X. LINPACK's QR happens to be implemented as successive orthogonalization, but LAPACK's is not, so only the former is usable with lm(). So, I suppose what I am getting at is that not even lm() uses qr(), it calls LINPACK directly. -pd > On 02 Aug 2016, at 21:17 , Charles Determan wrote: > > Hello, > > I am currently working on an implementation of QR decomposition (leveraging > a C++ library via Rcpp). Naturally I would like to have the R syntax as > similar as possible to base R 'qr' function. Given the class structure of > my package my instinct was to export an S4/S3 method. > > However, the QR decomposition doesn't store the final QR matrix in the same > format as base R via LINPACK, nor does it return 'qraux', 'rank' or 'pivot' > objects but instead a 'betas' object. The final 'R' and 'Q' matrices are > in fact identical to those ultimately returned by qr.R or qr.Q. > > So my question is, given these differences, should I just create a > different function name or would creating a qr.myclass dispatch be > acceptable (whether S3 or S4)? I would prefer the latter as I would like > the classes to potentially take advantage of previously written code using > 'qr'. > > Thanks, > Charles > > [[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] Pkgs with ToS violations
On 04 Aug 2016, at 05:21 , Dirk Eddelbuettel wrote: > > On 3 August 2016 at 22:26, Bob Rudis wrote: > | I came across https://cran.rstudio.com/web/packages/boxoffice/index.html > | in CRAN today and while I don't expect CRAN to be a legal authority, > | should there not be some kind of policy for excluding R packages that > | deliberately violate (data) site ToS? (I'm asking this here vs sending > | a note to CRAN folks since I tend to be a bit sensitive to this > | particular issue). > | > | Box Office Mojo - which is really just Amazon - clearly states that > | the activities this package facilitates are in violation of their ToS. > | Unlike examples on blogs that also violate BOM ToS, this pkg in CRAN > | is almost legitimizing the violations. > | > | Amazon only goes after a few folks a year and it's unlikely R folks > | will be their target (for now) but that doesn't make it OK IMO. > | > | Is this worth bringing up to CRAN? > > I think so. > By all means bring it up. But there's the usual tools-vs-action discussion, and I do notice that the ToS has • Licensing IMDb's Content; Consent to Use Robots and Crawlers: If you are interested in receiving our express written permission to use our content for your non-personal (including commercial) use, please contact our Licensing Department. We do allow the limited use of robots and crawlers, such as those from certain search engines, with our express written consent. I.e., it could be a matter of suitable flagging of the software as requiring permission. You likely don't wnat CRAN to run automated tests that run scrapers, though. -pd > 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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)
I don't have hard info on ABI compatibility between gcc versions, but there have been issues in the past, at least with with gfortran. Now, many people/schools will have R-3.2.x installed, built with gcc 4.6.y. We cannot retroactively recompile their installation, nor expect them to install a new version built with gcc 4.9.z. This raises a specific question and a generic one: - specific: Will a package binary of gower built with 4.9 work with R built with 4.6? - generic: Is is sufficiently likely that a given package if compiled with a different compiler version that CRAN would consider having a mechanism to specify a particular compiler version? I suspect that the answer to the second question is no. Whether to condition on R >= 3.3 is a good idea largely depends on two things - the user base (would they upgrade R anyways?) - are there other packages that depends on gower? (CRAN keeps only the newest version of a package so requiring a newer R could affect users with less aggressive update policies. This already happened when the pbkrtest package update rendered the car package unloadable.) You do have a 4th option: conditionalize the _code_ on the R version, then remove old-style code when 3.2.x becomes history. -pd On 25 Aug 2016, at 11:20 , Mark van der Loo wrote: > Dear listers, > > > Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure > that this is because it uses gcc 4.6.3 which has limited support for OpenMP > (the errors are the same as I got on the old travis-ci build environment, > see my related question[1]). > > Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3 > toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now > included." Not sure what that says about CRAN, but I'm hoping/guessing it > uses Rtools the same way as we do. > > So I guess I have the following options: > > - make my package depend on R>=3.3 > - Alter my code (as kindly suggested by Ott Toomet in [1]) > - Tell CRAN to use the modern compiler. > > Obviously, the latter would be easiest. Is this is even possible? For a > local installation I could set an environment variable[3], but how about > doing this at CRAN? > > Thanks, > Mark > > > [1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html > [2] https://cran.r-project.org/bin/windows/Rtools/ > [3] > https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation > > [[alternative HTML version deleted]] > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R Packages Never Finish Check
gt;> * using session charset: ISO8859-1 >> * using options '--no-manual --as-cran' >> * checking for file 'linkedata/DESCRIPTION' ... OK >> * checking extension type ... Package >> * this is package 'linkedata' version '0.1.0' >> * checking package namespace information ... OK >> * checking package dependencies ... NOTE >> Package suggested but not available for checking: 'pvsolcalcs' >> * checking if this is a source package ... OK >> * checking if there is a namespace ... OK >> * checking for executable files ... OK >> * checking for hidden files and directories ... OK >> * checking for portable file names ... OK >> * checking whether package 'linkedata' can be installed ... OK >> * checking installed package size ... >> >> >> >> >> >> ** >> This e-mail and any attachments thereto may contain confidential information >> and/or information protected by intellectual property rights for the >> exclusive attention of the intended addressees named above. If you have >> received this transmission in error, please immediately notify the sender by >> return e-mail and delete this message and its attachments. Unauthorized use, >> copying or further full or partial distribution of this e-mail or its >> contents is prohibited. >> ** >> >> [[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R-3.3.2 on October 31
Just a quick heads-up, mostly for those who want to keep their packages up to date with respect to updates of R: We intend to have a patch release on October 31. Nickname and detailed schedule will be made available on developer.r-project.org in due course. For the R Core Team Peter Dalgaard -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help package checks using valgrind
tput? >(for Fedora or any other platforms using docker) > > 3) Any alternative methods recommended for tracking this down instead of > using valgrind? > > > > Thanks! > Merlise > >> sessionInfo() > R version 3.4.0 (2017-04-21) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Fedora 23 (Twenty Three) > > Matrix products: default > BLAS: /usr/local/lib64/R/lib/libRblas.so > LAPACK: /usr/local/lib64/R/lib/libRlapack.so > > > source code is at http://github.com/merliseclyde/BAS > > > > Merlise A Clyde > Professor & Chair Department of Statistical Science > Duke University > http://stat.duke.edu/~clyde > > cl...@duke.edu<mailto:cl...@duke.edu> > > > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help package checks using valgrind
I don't think I can offer anything beyond the Valgrind FAQ at this point. I kind of suspect that the other trace -- pointing to where the offending piece of memory was allocated --would provide the better clue about the source of the problem. -pd > On 25 May 2017, at 04:47 , Merlise Clyde, Ph.D. wrote: > > Thanks - I missed that one! After identifying the problem there, and > increasing --num-callers in my .valgrindrc file I can see more of the trace, > however, I still have short entries like > > > cleanEx() > ==2044952== Conditional jump or move depends on uninitialised value(s) > ==2044952==at 0x405A0CB: ??? > ==2044952==by 0x189D0A5F: ??? > ==2044952==by 0x189D0A5F: ??? > ==2044952==by 0x189D0A7B: ??? > ==2044952==by 0xFFEFED09F: ??? > ==2044952== > detaching package:MASS > > Any suggestions on how to get more details on what is occurring at that > point? > > Thanks! > Merlise > From: peter dalgaard > Sent: Tuesday, May 23, 2017 6:40 PM > To: Merlise Clyde, Ph.D. > Cc: r-package-devel@r-project.org > Subject: Re: [R-pkg-devel] Help package checks using valgrind > > > > On 23 May 2017, at 23:40 , Merlise Clyde, Ph.D. wrote: > > > > I am trying to resolve the Additional Issues reported by CRAN @ > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.stats.ox.ac.uk_pub_bdr_memtests_valgrind_BAS-2DEx.Rout&d=DwIFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=NOkxkvdFOOffXzeTY2kgZQ&m=NwjTuJcFlu_aiLanr5CmvC1iVoHoWRZ7GZRFeq3WOBE&s=58920PEhsbU1YFCH1hHuLt2t9FcOYIAvfZq_swf1lLc&e= > > for my package BAS which calls C and Fortran. > > > > The output from the above URL is not particularly informative (at least to > > me) for identifying where the problems are in the source code, as there are > > missing file names and line numbers as seen in this snippet from the above > > url: > > > > The first of those traces does actually point to something that should be > useful to you: > > > cleanEx() > ==9861== Conditional jump or move depends on uninitialised value(s) > ==9861==at 0x403DBF3: ??? > ==9861==by 0x1702DE57: ??? > ==9861==by 0x1702DE57: ??? > ==9861==by 0x1702DE73: ??? > ==9861==by 0xFFEFF861F: ??? > ==9861== Uninitialised value was created by a heap allocation > ==9861==at 0x4C2BBAD: malloc > (/builddir/build/BUILD/valgrind-3.11.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299) > ==9861==by 0x4E5AFE: GetNewPage (svn/R-devel/src/main/memory.c:875) > ==9861==by 0x4E77AF: Rf_allocVector3 (svn/R-devel/src/main/memory.c:2651) > ==9861==by 0x14B29729: sampleworep > (packages/tests-vg/BAS/src/sampleworep.c:395) > ==9861==by 0x47C36D: R_doDotCall (svn/R-devel/src/main/dotcode.c:617) > > i.e. you are allocating something at sampleworep.c:395 but it isn't > initialized before something somewhere uses its value to make a decision. So > possibly you should initialize the vector immediately after allocation. > > In the other cases, you seem to be too deep in R internals to let you see the > origin in your package, i.e., your stack traces are too short. According to > the Valgrind FAQ, you can use --num-callers to make them longer. Figuring out > how to pass that to valgrind as invoked by R is, um, left as an exercise for > the reader. > > -pd > > > > >> cleanEx() > > ==9861== Conditional jump or move depends on uninitialised value(s) > > ==9861==at 0x403DBF3: ??? > > ==9861==by 0x1A694397: ??? > > ==9861==by 0x1A694397: ??? > > ==9861==by 0x1A6943B3: ??? > > ==9861==by 0xFFEFF861F: ??? > > ==9861== Uninitialised value was created by a heap allocation > > ==9861==at 0x4C2BBAD: malloc > > (/builddir/build/BUILD/valgrind-3.11.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299) > > ==9861==by 0x4E5AFE: GetNewPage (svn/R-devel/src/main/memory.c:875) > > ==9861==by 0x4E77AF: Rf_allocVector3 > > (svn/R-devel/src/main/memory.c:2651) > > ==9861==by 0x4E79A8: Rf_allocVector > > (svn/R-devel/src/include/Rinlinedfuns.h:196) > > ==9861==by 0x4E79A8: R_alloc (svn/R-devel/src/main/memory.c:2160) > > ==9861==by 0x540C52: logicalSubscript > > (svn/R-devel/src/main/subscript.c:563) > > ==9861==by 0x5437BE: realSubscript > > (svn/R-devel/src/main/subscript.c:723) > > ==9861==by 0x5437BE: Rf_makeSubscript > > (svn/R-devel/src/main/subscript.c:980) > > ==9861==by 0x5455AB: VectorSubset (svn/R-devel/src/main/subset.c:188) > > ==9861==by 0x5455AB: do_subset_dflt (svn/R-devel/src/main/subset.c:826) > > ==9861=
[R-pkg-devel] R 3.4.1 at end of June
Just a quick note to say that we intend to have a patch release, probably on June 30, mainly to pick up a few balls that were dropped on the 3.4.0 release. Full schedule to appear later (just need a little time to actually set it up + checking that the date doesn't collide with schedules of other people). - Peter Dalgaard -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] -fbounds-check on develop version of Win-builder
Hi Beanie,
Hmm, a bit of googling (on the error message) suggests that you are not
alone... Several other CRAN package have recent ERRORs on Windows. I would
suspect that gfortran 4.9.x is the culprit, generating false positives, but it
is not really my area of expertise.
Maybe just lean back and see what the CRAN crew makes of it?
- Peter
> On 9 Jun 2017, at 14:44 , Benjamin Christoffersen wrote:
>
> Dear sirs
>
> I am writing regarding a question for the package dynamichazard which
> I am the author of and the -fbounds-check flag used in R develop in
> Win-Builder.
>
> R develop version has following flags added to the Fortran rule
> compared with R release on Win-builder: -pedantic -fbounds-check
>
> Particularly, the line for dchur.o when building dynamichazard on the
> release version is:
> d:/Compiler/gcc-4.9.3/mingw_32/bin/gfortran -O3 -mtune=core2 -c
> dchur.f -o dchur.o
>
> and the line on the develop version is:
> d:/Compiler/gcc-4.9.3/mingw_32/bin/gfortran -pedantic -fbounds-check
> -O3 -mtune=core2 -c dchur.f -o dchur.o
>
> The latter causes the following error when the tests on the package is run:
> At line 1 of file dchur.f
> Fortran runtime error: Actual string length is shorter than the
> declared one for dummy argument 'uplo' (0/1)
>
> The version of dynamichazard I submitted to the Win-Builder is at:
> https://github.com/boennecd/dynamichazard/tree/d3a8b7d5f39fbfcc14df008f1fdd71f4f38ac25a
>
> The relevant code in dynamichazard/src/LAPACK_BLAS_wrapper.cpp is:
> #include
> #include
> #include
>
> extern "C"
> {
> void F77_NAME(dchur)(
> const char *, // UPLO
> const char *, // TRANS
> int*,// N
> int*,// M
> double*, // R
> int*,// LDR
> double*, // X
> double*, // Z
> int*,// LDZ
> double*, // Y
> double*, // RHO
> double*, // C
> double*, // S
> int* // INFO
> );
> }
>
> void ddhazard_dchur(double *R, double *x, int n, int ldr){
> int info;
>
> double *c = new double[n];
> double *s = new double[n];
>
> int m = 0;
> int ldz = 1;
> double z, y, rho;
>
> F77_CALL(dchur)(
> "L",
> "N",
> &n, &m, R, &ldr,
> x, &z, &ldz, &y, &rho, c, s, &info);
>
> // code abbreviated
> };
>
> // code abbreviated
>
> I have tried to re-produce the error with R release on my own laptop
> running Windows but failed to do so. Here is an example:
> $ ./tmp.sh
> + cat foo.cpp
> #include
>
> extern "C" {
>void bar_(const char *in);
> }
>
> int main()
> {
>std::cout << "Running main" << std::endl;
>bar_("F");
>return 0;
> }
> + cat bar.f
> subroutine bar(INPUT)
> CHARACTER INPUT
>
> print *, input
> end
> + c:/Rtools/mingw_32/bin/g++ -std=gnu++11 -O2 -Wall -mtune=core2 -c
> foo.cpp -o foo.o
> + c:/Rtools/mingw_32/bin/gfortran -pedantic -fbounds-check -O3 -c bar.f -o
> bar.o
> + c:/Rtools/mingw_32/bin/g++ -o foo foo.o bar.o -lgfortran -lm -lquadmath
> + ./foo.exe
> Running main
> F
> + Rscript.exe -e R.version
> _
> platform x86_64-w64-mingw32
> arch x86_64
> os mingw32
> system x86_64, mingw32
> status
> major 3
> minor 4.0
> year 2017
> month 04
> day21
> svn rev72570
> language R
> version.string R version 3.4.0 (2017-04-21)
> nickname You Stupid Darkness
> + head -1 c:/Rtools/Rtools.txt
> Rtools Collection 3.4.0.1962
>
> The example is not with a dynamic link library but comparable to the
> example here:
> https://code.launchpad.net/~fluidity-core/fluidity/gmsh-on-sphere/+merge/99395/comments/216834
>
> I stupidly tried to solve the problem in the current version 0.3.1 of
> dynamichazard on CRAN by adding this rule in Makevars.win:
> dchur.o:
> $(F77) $(filter-out -fbounds-check,$(ALL_FFLAGS)) -c dchur.f -o dchur.o
>
> This makes all my tests pass including those that uses the
> ddhazard_dchur C++ function on the develop version of Win-builder.
> However, it violates the second paragraph of "1.2.1 Using Makevars" in
> "Writing R Extensions".
>
> Please, let me know if I have made an obvious mistake or if there is a
> straightforward solution.
>
> Sincerely yours
> Benjamin Christoffersen
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] package dependencies not detected?
> On 16 Aug 2017, at 11:11 , Berry Boessenkool
> wrote:
>
>
> Hi,
>
>
> if a function in a package uses graphics::legend in the code, but does not
> import it in the namespace, shouldn't there be a warning in the check?
>
Er, no... Importing into a namespace is used to avoid the graphics:: qualifier.
This is conceptually different from having a dependency.
-pd
> There is not, also not on CRAN (one of my packages did this with
> stats::density).
>
> Should I report this to the CRAN team?
>
>
> Regards,
>
> Berry
>
>
> Here's a minimal working example using devtools:
>
> ### install.packages(c("devtools","roxygen2"))
>
> # create package structure
> getwd()
> devtools::create("testPack", description=list(License="GPL (>=2)"))
> setwd("testPack/")
> devtools::check() # everything is fine
>
> # add function
> cat("
> #' @title test function
> #' @description test function
> #' @export
> #' @importFrom graphics plot
> #' @examples testFun(1:6, col=2)
> #' @param x Values
> #' @param args List of arguments passed to legend
> #' @param \\dots Further arguments passed to plot
> #'
> testFun <- function(
> x,
> args=list(x='topright', legend=c('A','B'), lty=1),
> ...
> )
> {
> plot(x, ...)
> do.call(graphics::legend, args)
> }
> ", file="R/testFun.R")
>
> devtools::check() # no problems - even though I only import plot, not legend
> # same thing if I use graphics::legend directly (outside of do.call)
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Warning "Dependence on R version '3.3.3' not with patchlevel 0"
Yep. Bear in mind that many system-wide installation, e.g. in universities, are of .0 or .1 releases and upgraded yearly. If we end up with packages depending on packages depending on a later version, bad things can happen (and _did_ happen in the 3.2.* series). For the same reason, we have become very careful not to add features into R-patched,so it should be rather unlikely that packages that work with x.y.z do not also work with x.y.0. -pd > On 3 Jan 2018, at 14:33 , Uwe Ligges wrote: > > > > On 03.01.2018 13:59, Hockemeyer, Cord (cord.hockeme...@uni-graz.at) wrote: >> Hi everybody, >> on submitting a new package I got a rejection because of the above warning >> in the CRAN-check. I guess it is because of the "Depends" entry "R (>= >> 3.3.3)" in the DESCRIPTION file but I have no idea how to do this otherwise. >> Any hel�p would be highly appreciated. > > If sufficient, use R (>= 3.3.0), otherwise R (>= 3.4.0): If you rely on a > specific patchlevel, binary repositories are inconsistant on CRAN and > typically you should be able to rely on a x.y.0 release. > > Best, > Uwe Ligges > > >> Best regards, >>Cord >> Cord Hockemeyer >> Institut f�r Psychologie, Universit�t Graz >> Tel.: +43 316 380 8531 >> https://psychologie.uni-graz.at/allgemeine/hockemeyer >> [[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Assignments to the Global environment
You probably need to tell us what you are trying to achieve. Why do you want to assign temp3 to a variable with its name in s into the global environment? Not doing that would clearly eliminate the Note:, but presumably it has a function. However, writing to the global environment, especially to variables with arbitrary names, is potentially antisocial behaviour, since it may overwrite user variables. Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is as intended? -pd > On 6 Jan 2018, at 20:36 , Saeb wrote: > > * checking R code for possible problems ... [4s] NOTE > Found the following assignments to the global environment: > File 'TSEtools/R/getTSE.R': > assign(as.character(s), temp3, envir = as.environment(1)) > > Please let me know, how can I eliminate this problem? I didn't find out > any good information on websites! -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Invalid UTF-8
> On 18 Oct 2022, at 16:37 , Dirk Eddelbuettel wrote: > > > On 17 October 2022 at 13:20, Göran Broström wrote: > > | G;ran (US keyboard) > > :) > > A fortunes candidate? > Incidentally, he's Gæran on a DK keyboard but Gøran on an NO one. The three Scandinavian languages have the same three extra letters (æøå), but Swedish writes the former two with diaeresis (like German), reverses their order in the alphabet (åöä), and switches ö and ä on the keyboard (compared to Danish, that is). Norwegian writes and sorts like Danish, but has the same key reversion as Swedish. "Brotherly love"... -pd -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission Rpolyhedra 0.2.2
The NOTEs look harmless, the WARNING is this (InternalException (HostCannotConnect "badges.ropensci.org" [connect: failed (Connection refused (WSAECONNREFUSED))])) so badges did not want to speak to win-builder. Doesn't look like something you can deal with, except by removing the offending badge from README.md. The "Current CRAN" business is about the previous version, so likely irrelevant. It seems reasonable for you to take the "false positive" route. -pd > On 15 Mar 2018, at 06:38 , alejandro baranek > wrote: > > Hi list: > > Please someone can help me with the stranges errors I recivied after a > minor bugfix in my package? tests ok, devtools::check() ok, TRAVIS CI ok... > What is the problem? > > Best, Ale. > > -- Forwarded message -- > From: > Date: 2018-03-15 1:39 GMT-03:00 > Subject: [CRAN-pretest-archived] CRAN submission Rpolyhedra 0.2.2 > To: abara...@dc.uba.ar > Cc: cran-submissi...@r-project.org > > > Dear maintainer, > > package Rpolyhedra_0.2.2.tar.gz does not pass the incoming checks > automatically, please see the pre-test at: > <https://win-builder.r-project.org/incoming_pretest/180315_ > 032641_Rpolyhedra_022/00check.log> > Status: 1 WARNING, 2 NOTEs > > Current CRAN status: ERROR: 5, NOTE: 3, OK: 4 > See: <https://CRAN.R-project.org/web/checks/check_results_Rpolyhedra.html> > > Please fix all problems and resubmit a fixed version via the webform. > If you are not sure how to fix the problems shown, please ask for help on > the R-package-devel mailing list: > <https://stat.ethz.ch/mailman/listinfo/r-package-devel> > If you are fairly certain the rejection is a false positive, please > reply-all to this message and explain. > > More details are given in the directory: > <https://win-builder.r-project.org/incoming_pretest/180315_ > 032641_Rpolyhedra_022> > The files will be removed after roughly 7 days. > > > Best regards, > CRAN teams' auto-check service > > > > > -- > alejandro baranek > @ken4rab <https://twitter.com/ken4rab> > qbotics <http://qbotics.tumblr.com/> | surferinvaders > <http://surferinvaders.tumblr.com> | algebraic-soundscapes > <http://imaginary.org/content/algebraic-soundscapes> | surfer-shuffle > <http://imaginary.org/program/surfer-shuffle> > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] win-builder 3.3.3 libcurl error + NOTE
Given that R-oldrelease will become 3.4.4 when we branch for 3.5.0 on Monday, perhaps you could just wait it out? -pd > On 23 Mar 2018, at 17:59 , Tyler wrote: > > I am getting a NOTE only on R-oldrelease when checking my package on > win-builder: > > * checking CRAN incoming feasibility ... NOTE > Maintainer: 'Tyler Morgan-Wall ' > > Found the following (possibly) invalid URLs: > URL: http://github.com/tylermorganwall/skpr >From: DESCRIPTION >Status: Error >Message: libcurl error code 35 > error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert > protocol version > URL: http://github.com/tylermorganwall/skpr/issues >From: DESCRIPTION >Status: Error >Message: libcurl error code 35 > error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert > protocol version > > I checked the version of the package currently on the CRAN that passed > without any libcurl errors or NOTEs back in January, and it too displayed > this NOTE, which again only occurred on R-oldrelease. Is there a way to > prevent this or should I just mention this NOTE in my CRAN submission > comment? > > Tyler > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] win-builder 3.3.3 libcurl error + NOTE
Sorry, I forgot: We don't switch until _release_ of 3.5.0, four weeks further down the line. Still, it doesn't seem worth it making much of a fuss about 3.3.3. -pd > On 24 Mar 2018, at 10:10 , peter dalgaard wrote: > > Given that R-oldrelease will become 3.4.4 when we branch for 3.5.0 on Monday, > perhaps you could just wait it out? > > -pd > >> On 23 Mar 2018, at 17:59 , Tyler wrote: >> >> I am getting a NOTE only on R-oldrelease when checking my package on >> win-builder: >> >> * checking CRAN incoming feasibility ... NOTE >> Maintainer: 'Tyler Morgan-Wall ' >> >> Found the following (possibly) invalid URLs: >> URL: http://github.com/tylermorganwall/skpr >> From: DESCRIPTION >> Status: Error >> Message: libcurl error code 35 >> error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert >> protocol version >> URL: http://github.com/tylermorganwall/skpr/issues >> From: DESCRIPTION >> Status: Error >> Message: libcurl error code 35 >> error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert >> protocol version >> >> I checked the version of the package currently on the CRAN that passed >> without any libcurl errors or NOTEs back in January, and it too displayed >> this NOTE, which again only occurred on R-oldrelease. Is there a way to >> prevent this or should I just mention this NOTE in my CRAN submission >> comment? >> >> Tyler >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > Email: pd@cbs.dk Priv: pda...@gmail.com > > > > > > > > > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Warnings and error message in CRAN Package Check Results
> On 25 Mar 2018, at 00:42 , Wenchao Ma wrote: > >arma::vec Pj = Calc_Pj(par = par, designMj = designMj, linkfunc = > linkfunc, boundary = boundary, eps = eps); I was never any good at C++, but that syntax looks like R code. Does C++ allow tag=value argument specification? Aren't all the subexpressions of type "par = par" just assignments?? -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] updating my package to fix if () condition has length > 1
Um, what are you saying here? You are (AFAIK) not going to get that Error
unless "method" has length > 1. It is not a synthetic check inserted by the
CRAN nitpickers... Rather than "break the thermometer" by doing method[1],
perhaps you should diagnose the problem, say by inserting something like
if (length(method) >= 1) {
warning("'method' has length > 1:")
print(method)
}
just before the "if (!is.element..." stuff.
-pd
> On 4 May 2018, at 19:38 , Lawrence, John P wrote:
>
> In the check results, it has this message:
> "
> Error in if (!is.element(substr(method, 1, 1), c("b", "P"))) { :
>the condition has length > 1
> Calls: AsympDiscSurv
> Execution halted
> "
>
> But, I had already changed that line to this:
>
> if (!is.element(substr(method[1], 1, 1), c("b", "P"))) {
>
>
> I know the variable "method" is a single character string, but to handle the
> error checking, I now explicitly tell it to use "method[1]".
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Replicate solaris errors
Have you tried asking CRAN for help? I mean, if you don't fix an obvious error, with a well-known cause, like the log thing, they'll get fed up and throw you off. However, fixing and then discovering an issue elsewhere is different, especially if you cannot easily reproduce it at your end. -pd > On 11 Aug 2018, at 20:41 , Thibault Vatter wrote: > > Yes, the non-portable call to log which causes the current build to fail on > solaris has been corrected in a development version. However, the segfault > that we don't understand and were asked to correct was present in the > previous versions (e.g., 0.2.8.1.0 and 0.2.7.1.0), and we believe that it > is likely to reappear if we resubmit with only the non-portable log call > corrected. > > This is why, in order to avoid resubmitting with the segfault still there > and having the package removed from CRAN, we would like to be able to > replicate the solaris build. > > On Sat, Aug 11, 2018 at 2:17 PM Iñaki Úcar wrote: > >> El sáb., 11 ago. 2018 a las 19:30, Thibault Vatter >> () escribió: >>> >>> Dear package developers, >>> >>> We've recently received an email letting us know that our package >>> rvinecopulib ( >>> https://cran.r-project.org/web/packages/rvinecopulib/index.html) would >> be >>> removed from CRAN unless the errors from the solaris build were >> corrected. >>> >>> Note that the package compile and the unit tests pass on the other test >>> platforms from CRAN and even a local R devel build with ASAN / UBSAN >>> sanitizers. On solaris, the package compiles but a segfault is produced >> by >>> one unit test for a reason that we still don't understand. >> >> Are you talking about a new development version that is not still on >> CRAN? Because the current CRAN version fails to install. >> >> Iñaki >> >>> >>> To replicate the issue, I tried to mimic CRAN's solaris config ( >>> https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86) in a >>> virtual machine following the steps in the gist below (based on >> Jeroen's): >>> >>> https://gist.github.com/tvatter/b2503f03fcd604ff764ffe4b979afcb6 >>> >>> Note that the "--with-readline=no" configure option at the end was added >>> because I got "configure: error: --with-readline=yes (default) and >>> headers/libs are not available" without it. >>> >>> Unfortunately, I then got the "configure: error: a suitable iconv is >>> essential" and could not proceed to build R. >>> >>> I know that I should get GNU iconv as specified in the installation >> manual, >>> hence the "/opt/csw/bin/pkgutil -y -i libiconv_dev" in the gist above. I >>> verified that iconv is in /opt/csw/lib as expected and I thought that >>> adding /opt/csw/lib to R_LD_LIBRARY_PATH as suggested in the manual would >>> then do the trick, but it does not seem to be the case. >>> >>> Two questions: >>> >>> 1) What did I miss or do wrong? >>> >>> 2) Anyone found a way to replicate solaris CRAN builds to test packages? >> I >>> tried to use https://builder.r-hub.io/, but some of my package's >>> dependencies fail to install because of udunits2 is missing on their >> system >>> if I recall correctly. >>> >>> Thibault >>> >>>[[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R graphics 'text' package 'adj' parameter order wrong incorrect reversed?
Exactly. And left alignment means that the left end of the text is aligned with the anchor point, etc. So documentation is correct. -pd > On 19 Sep 2018, at 01:33 , Jim Lemon wrote: > > Hi Simon, > I think the conventions of typesetting are to blame. Think of an > invisible box around the text being displayed. > __ > |Left justification | > |-| > meaning that the text _starts_ at the left of the field and is to the > right of the text position specified > __ > |Right justification| > |-| > > meaning that the text _ends_ at the right of the field and is to the > left of the text position. Can't do the top and bottom justification > this way, but I think you get the idea. > > Jim > > On Wed, Sep 19, 2018 at 9:13 AM Simon Dedman wrote: >> >> Original stack overflow post here: >> https://stackoverflow.com/questions/52194719/r-graphic-text-package-adj-parameter-order-wrong-incorrect-reversed >> >> Hopefully this is now the appropriate place to post this as the above post >> got a single comment of agreement. >> >> Content: >> >> I believe R core package graphics text function's adj parameter is >> incorrectly described in the manual >> <https://stat.ethz.ch/R-manual/R-devel/library/graphics/html/text.html> and >> would be grateful if someone could confirm this before I submit a bug report >> <https://www.r-project.org/bugs.html>. >> >> adj text: >> >> adj allows adjustment of the text with respect to (x, y). Values of 0, 0.5, >> and 1 specify left/bottom, middle and right/top alignment, respectively. >> >> Since text controls these labels and not the points which have already been >> plotted, I can't see how "with respect to x,y" can mean anything other than >> "in this direction relative to their points". >> >> However the order is reversed: 0,0 (supposedly left & bottom) is top & >> right; 1,1 (supposedly right & top) is left and bottom. >> >> Reproducible example: >> >> tens = 1:10 >> plot(tens, tens, xlab = "adj 0,0 left/bottom") >> text(tens, tens, labels = letters[tens], adj = c(0,0)) >> plot(tens, tens, xlab = "adj 0.5,0.5 middle") >> text(tens, tens, labels = letters[tens], adj = c(0.5,0.5)) >> plot(tens, tens, xlab = "adj 1,1 right/top") >> text(tens, tens, labels = letters[tens], adj = c(1,1)) >> >> Thanks. >> >>[[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Unexpected symbol when checking package examples
Not just a capitalization issue (mertools vs. merTools)? Barring that, maybe locale trouble? Can you also do things like LC_ALL=C R < merTools-Ex.R ? Also, check for lines starting with "else" (I think you shouldn't be able to run it line-by-line if that was the issue, though). -pd > On 11 Nov 2018, at 21:39 , Jared Knowles wrote: > > Hi! > > I have a bit of a weird issue when I'm trying to check my package merTools > (source repo available here: https://github.com/jknowles/merTools > > On Windows and Linux builds for R-release and R-devel, when R CMD CHECK > checks examples, it returns the following error below: > > Warning: parse error in file 'merTools-Ex.R': > 1: unexpected symbol > 117: cleanEx() > 118: nameEx > > > Upon inspecting the example file generated by R CMD CHECK (mertools-Ex.R) - > it contains only valid R code. I can run it line by line or source the > whole file in R without any errors. But, during the check process, this > error occurs. > > The functions cleanEx() and nameEx() appear to be created as part of the > checking process. > > I have not changed the examples in the code since the last time I ran R CMD > CHECK so I am quite confident that the example code for all functions is > valid R code. > > Any ideas on what might be the source of this problem? > > Thanks! > Jared > > > > Jared Knowles > President, Civilytics Consulting LLC > www.jaredknowles.com > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Effieciency drop in do.call?
If it was just about args evaluation, then the slowness would be in the list()
call, no?
An accidental deparse of a large structure could well be the culprit.
-pd
> On 19 Nov 2018, at 18:53 , Gabor Grothendieck wrote:
>
> The do.call version evaluates all arguments while the normal version
> may not depending on the function. There could also be a difference
> if the function uses non-standard evaluation since in that case the
> two could be passing different different argument values.
>
> For an example of the second case,
>
> f <- function(x) deparse(substitute(x))
>
> f(pi)
> ## [1] "pi"
>
> do.call("f", list(pi))
> ## [1] "3.14159265358979"
>
> On Mon, Nov 19, 2018 at 11:50 AM Paul Buerkner
> wrote:
>>
>> Hi all,
>>
>> today, I stumbled upon a puzzling (to me) problem apparently related to
>> do.call() that resulted
>> in an efficiency drop of multiple orders of magnitudes compared to just
>> calling the function directly (multiple minutes as compared to one second).
>>
>> That is
>>
>> fun(a = a, b = b, c = c, ...)
>>
>> took one second, while
>>
>> args <- list(a = a, b = b, c = c, ...)
>> do.call(fun, args)
>>
>> took multiple minutes.
>>
>> In my package (brms), I use do.call in various places but only in one it
>> resulted in this
>> efficiency drop.
>>
>> Before I try to make a reproducible example, I wanted to ask if there are
>> any known issues
>> with do.call that may explain this?
>>
>> Paul
>>
>>[[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Effieciency drop in do.call?
A classical way of encountering this is
x <- rnorm(1000)
do.call("plot", list(x))
A way out is
do.call("plot", list(quote(x)))
-pd
> On 19 Nov 2018, at 22:32 , peter dalgaard wrote:
>
> If it was just about args evaluation, then the slowness would be in the
> list() call, no?
> An accidental deparse of a large structure could well be the culprit.
>
> -pd
>
>
>> On 19 Nov 2018, at 18:53 , Gabor Grothendieck
>> wrote:
>>
>> The do.call version evaluates all arguments while the normal version
>> may not depending on the function. There could also be a difference
>> if the function uses non-standard evaluation since in that case the
>> two could be passing different different argument values.
>>
>> For an example of the second case,
>>
>> f <- function(x) deparse(substitute(x))
>>
>> f(pi)
>> ## [1] "pi"
>>
>> do.call("f", list(pi))
>> ## [1] "3.14159265358979"
>>
>> On Mon, Nov 19, 2018 at 11:50 AM Paul Buerkner
>> wrote:
>>>
>>> Hi all,
>>>
>>> today, I stumbled upon a puzzling (to me) problem apparently related to
>>> do.call() that resulted
>>> in an efficiency drop of multiple orders of magnitudes compared to just
>>> calling the function directly (multiple minutes as compared to one second).
>>>
>>> That is
>>>
>>> fun(a = a, b = b, c = c, ...)
>>>
>>> took one second, while
>>>
>>> args <- list(a = a, b = b, c = c, ...)
>>> do.call(fun, args)
>>>
>>> took multiple minutes.
>>>
>>> In my package (brms), I use do.call in various places but only in one it
>>> resulted in this
>>> efficiency drop.
>>>
>>> Before I try to make a reproducible example, I wanted to ask if there are
>>> any known issues
>>> with do.call that may explain this?
>>>
>>> Paul
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
>>
>> --
>> Statistics & Software Consulting
>> GKX Group, GKX Associates Inc.
>> tel: 1-877-GKX-GROUP
>> email: ggrothendieck at gmail.com
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk Priv: pda...@gmail.com
>
>
>
>
>
>
>
>
>
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package update submission to CRAN fails on pretest
Hmm, no ERRORs in the CRAN checks at this moment? Re. utf-8, on Mac OS, the CRAN checks have a note about 90 strings marked as utf8. I see 57 of them in > life$Country[Encoding(life$Country)!="unknown"] [1] "Korea, Dem. People’s Rep." "Korea, Dem. People’s Rep." [3] "Korea, Dem. People’s Rep." "Korea, Dem. People’s Rep." [5] "Korea, Dem. People’s Rep." "Korea, Dem. People’s Rep." ... and 32 more in "mortality". You go find the remaining 1... This seems to be an issue with the quote symbol: > u <- life$Country[Encoding(life$Country)!="unknown"][1] > Encoding(u) [1] "UTF-8" > Encoding(u) <- "bytes" > u [1] "Korea, Dem. People\\xe2\\x80\\x99s Rep." I have no clue why this is not an issue on only some platforms. -pd > On 7 Dec 2018, at 08:54 , Wolfgang Lenhard > wrote: > > Dear list, > I am getting problems when trying to submit an update of the package > cNORM to CRAN. I am developing the package with RStudio and devtools and > I am using Travis for automatic testing. The package is tested locally > on Win10 and Mac OS X and on Travis with Ubuntu and Mac both for > development and release versions of R. All local tests and tests on > Travis work flawlessly - no errors, warning or notes. When submitting to > CRAN, a note and an error show up on some of the Linux OS (Fedora & > Solaris) and Mac OS X, while others display an 'OK' (Win, Debian). The > results: https://cran.r-project.org/web/checks/check_results_cNORM.html > > - error: This seems to be related to the vignette with the following > message: >> * checking examples ... ERROR >> Running examples in ‘cNORM-Ex.R’ failed > I can however not identify the location of the error > > - Note: Check: data for non-ASCII characters > > The strange thing is: I checked all data files multiple times. They > mainly consist of data.frames with numerics and all colnames are ASCII. > I am not able to replicate the issue. The same is true for the error, > which does not show up on Travis and as well locally. And finally, the > results state, that the version of the package is 1.0.1, which had been > the first submission to CRAN a month ago. The current version of the > package is 1.1.1. Could this be the reason for the problem? > > Do you have an idea how to progress with the testing or how to locate > the errors? Any help is welcome. > > Best regards, > Wolfgang Lenhard > > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] RData files with identical objects in package
I think it is illegal if you use the lazyload database, because that is indexed
by name and contains every object that would be created by data(). This creates
an obvious issue if two objects share a name.
Once you use the lazyload database, loading the package creates an environment
which is initially full of promises, one for each object. Evaluating one of
these makes the actual object appear in the environment.
Using data() causes the corresponding promise(s) to be created in the global
environment. IIRC, there is a registry that says which objects are created by
which arguments to data(), but as they are still taken from the lazydata
database, the last one created with a given name still wins.
-ps
> On 13 Jan 2019, at 14:13 , Troels Ring wrote:
>
> Thanks a lot - I'm sure you are right that I could just use different names
> but I cannot understand why it could cause problem to have two different well
> formated .RData files in the /data directory both with an "x" - is that
> really illegal? I cannot see it stated in the official munual - but it is
> long (wrting r extensions)
> -BW
> Troels
>
> -Oprindelig meddelelse-
> Fra: Michael Dewey
> Sendt: 13. januar 2019 12:56
> Til: Troels Ring ; package-develop
>
> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>
> Dear Troels
>
> Perhaps I misunderstand what you are trying to do but would it be possible to
> put each x and y into a list or a dataframe with different names and then
> modify your usgae to pull them from there? Then there would be no danger of
> users getting the wrong x and y
>
> Michael
>
> On 13/01/2019 08:38, Troels Ring wrote:
>> Dear friends - I have a package under creation making heavy
>> calculations on chemical/clinical data and I plan to include as
>> "examples" the use of some literature data used in my papers. To
>> illustrate what then occurs, I made two RData files consisting only of
>> x and y with different values for x and y like
>>
>> X <- 100
>>
>> Y <- 1000
>>
>> save(x,y,file="first.RData")
>>
>> and then a new x and y in "second" with x <- 45 and y <- 32
>>
>> When I put these in a "data" directory of a new package without
>> further ado in RStudio
>>
>> Ctrl-shift-L
>>
>> Ctrl-shift-B
>>
>>
>>
>> .there is a warning
>>
>> * installing *source* package 'try' ...
>>
>> ** R
>>
>> ** data
>>
>> *** moving datasets to lazyload DB
>>
>> warning: objects 'x', 'y' are created by more than one data call
>>
>> ** byte-compile and prepare package for lazy loading
>>
>> ** help
>>
>> converting help for package 'try'
>>
>> *** installing help indices
>>
>> finding HTML links ...hello html
>>
>> done
>>
>>
>>
>> Now, when I clear the workspace:
>>
>>> ls()
>> character(0)
>>> devtools::load_all(".")
>> Loading try
>>
>> Restarting R session...
>>
>>> library(try)
>>> ls()
>> character(0)
>>> x #-- so even if workspace Is empty x is still kept
>> [1] 45
>>> data(first) # and "first" is not seen x
>> [1] 45
>>
>>
>>
>> x is still present - and y
>>
>>
>>
>> I have been reading and searching in "Writing R extensions" but so far
>> didn't find the clue.
>>
>> Seemingly it is the file with the last name that is assessed - when I rename
>> first.RData to "xfile.RData" we get 100 and 1000.
>>
>> Now and then when running ctrl-shift-L and - B we see
>>
>>
>>
>> Attaches package: 'try'
>>
>> The following objects are masked _by_ '.GlobalEnv':
>> x, y
>>
>>
>>
>> Sorry for these problems -
>>
>> BW
>> Troels
>>
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
> --
> Michael
> http://www.dewey.myzen.co.uk/home.html
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] RData files with identical objects in package
There is (of course) a difference between what is the default for a (missing)
field in DESCRIPTION and what shells like RStudio put into the field by
default...
I don't think there is a discrepancy between what is in the official
documentation and what R and R CMD * actually does.
-pd
> On 14 Jan 2019, at 07:10 , Troels Ring wrote:
>
> Thank you so much! Perhaps it could be mentioned in the official
> documentation on writing R extensions - even if - if I can read English -
> the
> default is to avoid "lazyData" loading - and "laxyData" loading is in some
> opposition to loading using data() - whereas - if we use RStudio, and make
> an R documentation file for data, we have it ending with:
> \examples{
> data(ddd)
> ## maybe str(ddd) ; plot(ddd) ...
> }
> \keyword{datasets}
>
> At the same time as "lazyData" is used default in DESCRIPTION ?
>
> 1.1.6 Data in packages
> The data subdirectory is for data files, either to be made available via
> lazy-loading or for loading using data(). (The choice is made by the
> 'LazyData' field in the DESCRIPTION file: the default is not to do so.) It
> should not be used for other data files needed by the package, and the
> convention has grown up to use directory inst/extdata for such files.
>
> All best wishes
> Troels
>
>
> -Oprindelig meddelelse-
> Fra: peter dalgaard
> Sendt: 13. januar 2019 22:00
> Til: Troels Ring
> Cc: Michael Dewey ; package-develop
>
> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>
> I think it is illegal if you use the lazyload database, because that is
> indexed by name and contains every object that would be created by data().
> This creates an obvious issue if two objects share a name.
>
> Once you use the lazyload database, loading the package creates an
> environment which is initially full of promises, one for each object.
> Evaluating one of these makes the actual object appear in the environment.
>
> Using data() causes the corresponding promise(s) to be created in the global
> environment. IIRC, there is a registry that says which objects are created
> by which arguments to data(), but as they are still taken from the lazydata
> database, the last one created with a given name still wins.
>
> -ps
>
>> On 13 Jan 2019, at 14:13 , Troels Ring wrote:
>>
>> Thanks a lot - I'm sure you are right that I could just use different
>> names but I cannot understand why it could cause problem to have two
>> different well formated .RData files in the /data directory both with
>> an "x" - is that really illegal? I cannot see it stated in the
>> official munual - but it is long (wrting r extensions) -BW Troels
>>
>> -Oprindelig meddelelse-
>> Fra: Michael Dewey
>> Sendt: 13. januar 2019 12:56
>> Til: Troels Ring ; package-develop
>>
>> Emne: Re: [R-pkg-devel] RData files with identical objects in package
>>
>> Dear Troels
>>
>> Perhaps I misunderstand what you are trying to do but would it be
>> possible to put each x and y into a list or a dataframe with different
>> names and then modify your usgae to pull them from there? Then there
>> would be no danger of users getting the wrong x and y
>>
>> Michael
>>
>> On 13/01/2019 08:38, Troels Ring wrote:
>>> Dear friends - I have a package under creation making heavy
>>> calculations on chemical/clinical data and I plan to include as
>>> "examples" the use of some literature data used in my papers. To
>>> illustrate what then occurs, I made two RData files consisting only
>>> of x and y with different values for x and y like
>>>
>>> X <- 100
>>>
>>> Y <- 1000
>>>
>>> save(x,y,file="first.RData")
>>>
>>> and then a new x and y in "second" with x <- 45 and y <- 32
>>>
>>> When I put these in a "data" directory of a new package without
>>> further ado in RStudio
>>>
>>> Ctrl-shift-L
>>>
>>> Ctrl-shift-B
>>>
>>>
>>>
>>> .there is a warning
>>>
>>> * installing *source* package 'try' ...
>>>
>>> ** R
>>>
>>> ** data
>>>
>>> *** moving datasets to lazyload DB
>>>
>>> warning: objects 'x', 'y' are created by more than one data call
>>>
>>> ** byte-compile and prepare package for lazy loading
>>>
>>> ** help
>>>
>>>
Re: [R-pkg-devel] Win-builder: Author field differs from that derived from Authors@R
The difference is obviously in the "con" men. The definition of role="con" in
the MARC code list is
Conservator [con]
A person or organization responsible for documenting, preserving, or treating
printed or manuscript material, works of art, artifacts, or other media
UF Preservationist
Is this as intended?
-pd
> On 6 Feb 2019, at 13:26 , Ivan Krylov wrote:
>
> Hi!
>
> I'm relying on Authors@R to generate the Author: and Maintainer:
> headers. When checking my package at win-builder using R-unstable, I
> got a NOTE that Author field differs from that derived from Authors@R:
>
>>> Author: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [cph], Alexander Semke [cph], Tilman Benkert [cph], Kasper Peeters
>>> [cph], Russell Standish [cph], Ivan Krylov [cre, cph]'
>
>>> Authors@R: 'Miquel Garriga [aut, cph], Stefan Gerlach [aut, cph],
>>> Ion Vasilief [aut, cph], Alex Kargovsky [aut, cph], Knut Franke
>>> [con, cph], Alexander Semke [con, cph], Tilman Benkert [con, cph],
>>> Kasper Peeters [con, cph], Russell Standish [con, cph], Ivan Krylov
>>> [cre, cph]'
>
> Link to full check output:
> https://win-builder.r-project.org/EWz9zWS0niO3/
>
> The actual field from DESCRIPTION now looks like this:
>
>>> Authors@R: c(person('Miquel', 'Garriga', email =
>>> 'gbmiq...@gmail.com', role = c('aut', 'cph')), person('Stefan',
>>> 'Gerlach', email = 'stefan.gerl...@uni-konstanz.de', role = c('aut',
>>> 'cph')), person('Ion', 'Vasilief', email = 'ion_vasil...@yahoo.fr',
>>> role = c('aut', 'cph')), person('Alex', 'Kargovsky', email =
>>> 'kargov...@yumr.phys.msu.su', role = c('aut', 'cph')),
>>> person('Knut', 'Franke', email = 'knut.fra...@gmx.de', role =
>>> c('con', 'cph')), person('Alexander', 'Semke', email =
>>> 'alexander.se...@web.de', role = c('con', 'cph')), person('Tilman',
>>> 'Benkert', email = 't...@gmx.net', role = c('con', 'cph')),
>>> person('Kasper', 'Peeters', email = 'kasper.peet...@aei.mpg.de',
>>> role = c('con', 'cph')), person('Russell', 'Standish', role =
>>> c('con', 'cph')), person('Ivan', 'Krylov', email =
>>> 'krylov.r...@gmail.com', role = c('cre', 'cph')))
>
> The version of R I'm currently using is 3.3.3 (2017-03-06) from Debian
> stable, which might explain the differences in utils:::format.person.
>
> What should I do to avoid the NOTE?
>
> --
> Best regards,
> Ivan
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled
It's not "stealth fixed"! It was never there... (on the release branch)
The timestamp checking code is still present in R-devel. I presume something
needs to be done about the breakage.
- pd
> On 7 Mar 2019, at 14:38 , Bob Rudis wrote:
>
> It's fixed in the RC that's GA on the 11th.
>
> I think perhaps "stealth fixed" may be more appropro since it's not in SVN
> logs, Bugzilla nor noted prominently in any of the various NEWS* files.
>
> Then there's the "why was the core R installation using a third party,
> non-HTTPS site for this to begin with".
>
> And, in other news, there are tests in the R source that rely on a check of
> `foo.bar` for connectivity. `.bar` is a valid domain and `foo.bar` is
> registered. Thankfully there's no current IP address associated with it.
> Anything under `*.invalid` (https://en.wikipedia.org/wiki/.invalid) might be
> a better choice as well since that won't break the reason for the
> connectivity checks and won't arbitrarily send telemetry pings to third
> parties in the even anyone outside of R Core decides to run the tests (say,
> when patching something in R).
>
> -boB
>
>> On Mar 7, 2019, at 07:54, Rainer M Krug wrote:
>>
>> I can confirm the same when checking on travis with r-devel.
>>
>> And thanks for the tip with
>>
>> env:
>> - _R_CHECK_SYSTEM_CLOCK_=0
>>
>> In .travis.yml
>>
>> Seems to be working now
>>
>> Rainer
>>
>>
>>
>>> On 7 Mar 2019, at 12:48, Ralf Herold wrote:
>>>
>>> Dear All,
>>>
>>> Checking a new package under development produces a warning in a local
>>> R-devel MS Windows environment (output below).
>>>
>>> Building it with R-devel on Travis fails (because warnings are changed to
>>> errors), but is successful when setting environment variable
>>> _R_CHECK_SYSTEM_CLOCK_ to zero.
>>>
>>> No issue occurs when checking and building with R-stable and R-oldrel on
>>> Travis, or with any R version on win-builder.r-project.org.
>>>
>>> The warning concerns using http://worldclockapi.com/, which however seems
>>> out of service ("The web app you have attempted to reach is currently
>>> stopped and does not accept any requests."). This is referenced in the main
>>> function for R CMD check
>>> (https://svn.r-project.org/R/trunk/src/library/tools/R/check.R) and may
>>> concern more R-devel than R-package-devel. I am posting here to check if
>>> the issue was noticed by other package developers and to check the impact.
>>>
>>> Thanks for any suggestions.
>>> Best regards,
>>> Ralf
>>>
>>>
>>> PS C:\Users\username> & 'C:\Program Files\R\R-devel\bin\R.exe' CMD check
>>> E:\mypackage_0.1.2.3.tar.gz --as-cran
>>> * using log directory 'C:/Users/username/ctrdata.Rcheck'
>>> * using R Under development (unstable) (2019-03-05 r76200)
>>> * using platform: x86_64-w64-mingw32 (64-bit)
>>> * using session charset: ISO8859-1
>>> * using option '--as-cran'
>>> [...]
>>> * checking package directory ... OK
>>> * checking for future file timestamps ...Warning in file(con, "r") :
>>> cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status
>>> was '403 Site Disabled'
>>> WARNING
>>> unable to verify current time
>>> * checking 'build' directory … OK
>>> [...]
>>>
>>>
>>>
>>> ## Ralf Herold
>>> ## mailto: ralf.her...@mailbox.org [S/MIME]
>>> ## https://paediatricdata.eu/
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
>>
>>
>> --
>> Rainer M. Krug
>> email: Rainerkrugsde
>> PGP: 0x0F52F982
>>
>>
>> [[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
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] obscure syntax error
It could use a little whitespace, but I (and the Rstudio script editor) can't
spot anything wrong, like mismatching braces or parens, and all
else-at-beginning-of-line is inside the function.
Could it be an incomplete last line?
-pd
> On 22 Mar 2019, at 11:18 , Jim Lemon wrote:
>
> Hi,
> I have been attempting to check a new version of the prettyR package,
> and have struck a difficult problem. The check fails at the
> installation, and when I track the error, it is "Unexpected end of
> input" in the xtab function. I have tried a number of things as I
> thought that it was a non-printing character (I have had that happen
> before). I can paste the entire function into an R session and there
> is no error. Has anyone struck an error like this before?
>
> xtab<-function(formula,data,varnames=NULL,or=TRUE,chisq=FALSE,phi=FALSE,
> html=FALSE,bgcol="lightgray") {
>
> if(missing(formula))
> stop("Usage:
> xtab(formula,data,varnames=NULL,or=TRUE,chisq=FALSE,phi=FALSE\n")
> ft<-as.character(attr(terms(formula),"variables")[-1])
> nft<-length(ft)
> if(nft>2) {
> xt<-list()
> by.factor<-as.factor(data[[ft[nft]]])
> factor.levels<-levels(by.factor)
> factor.labels<-attr(data[,ft[nft]],"value.labels")
> if(!is.null(names(factor.labels))) factor.labels<-names(factor.levels)
> if(is.null(factor.labels)) factor.labels<-factor.levels
> nlevels<-length(factor.levels)
> for(i in 1:nlevels) {
> currentdata<-subset(data,by.factor==factor.levels[i])
> for(j in 1:dim(currentdata)[2])
>attr(currentdata[,j],"value.labels")<-attr(data[,j],"value.labels")
> currentcount<-length(currentdata[[nft]])
> totalcount<-length(data[[nft]])
> cat("\nCount for",ft[nft],"=",factor.labels[i],"is",currentcount,
>"(",round(100*currentcount/totalcount,1),"%)\n\n")
> rightside<-ifelse(nft>3,paste(ft[2:(nft-1)],sep="",collapse="+"),ft[2])
> next.formula<-as.formula(paste(ft[1],rightside,sep="-",collapse=""))
> xt[[i]]<-xtab(next.formula,data=currentdata,varnames=varnames,chisq=chisq,
>phi=phi,html=html,bgcol=bgcol)
> }
> }
> else {
> if(missing(data)) xt<-calculate.xtab(get(ft[1]),get(ft[2]),varnames=varnames)
> else xt<-calculate.xtab(data[,ft[1]],data[,ft[2]],varnames=varnames)
> }
> attr(xt,"class")<-"xtab"
> return(xt)
> }
> Thanks for any pointers.
>
> Jim
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] attempt to re-insert old removed package
For most packages[*], I assume that you can just take on the role as maintainer, bump the version number and resubmit. If you don't actually maintain it, then of course it might fall of CRAN again after a while. -pd [*] Actually, I expect that CRAN policy implies "all" here; I just can't be bothered to check... > On 5 Apr 2019, at 10:24 , Ramón Fallon wrote: > > Hi, > > I've been searching for some procedures to try an get an old package back > into CRAN. > > It's package that has the re exclamation mark on cran github and is not > available via install.packages() for modern version of R. > > However some small changes to the source were enough to get it installed > via R CMD INSTALL, so I thought I might how difficult it would be to get it > back into the CRAN repo, but I have been able to find procedures for that > process. > > Any body who has managed this already? Helpful links appreciated, many > thanks. > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] dtrti2 error on CRAN checks
Kurt Hornik submitted a bug report to the gfortran maintainers yesterday, and yes, it seems to have a lot to do with this. He and Brian Ripley have been able to pinpoint it to certain gfortran revisions (specifically gfortran-9 at least r268992, or gfortran-8 at least r269349), but we're lacking a simple test case. -pd > On 18 Apr 2019, at 07:53 , Benjamin Christoffersen wrote: > > Thanks for the quick reply. First a correction. I meant Ubuntu 18.04.2 > of course, sorry. > >> In short, you need to look more closely. > Is there a way to tell which BLAS and LAPACK is used on the Debian > machines on CRAN? I checked the "CRAN Package Check Flavors" page but > there is no information there regarding BLAS or LAPACK. > > I have tried to test the package with Atlas, OpenBlas, and the > reference implementation with gcc 7.3.0 and 8.2.0. It all worked > without any errors. > > It seems that gcc has changed since January from version 8.2.0 and > 7.3.0 to 8.3.0 on the tests on CRAN. Further, it is now Debian version > 8.3.0-2 instead of Debian 8.2.0-7 and Debian 7.3.0-29. I do not know > whether this can matter. > > Sincerely yours, > Benjamin Christoffersen > > > > > > > > Den ons. 17. apr. 2019 kl. 11.38 skrev Dirk Eddelbuettel : >> >> >> On 17 April 2019 at 11:06, Benjamin Christoffersen wrote: >> | Since the start of April, I have gotten some errors on the Debian >> | machines on the check on CRAN for my package dynamichazard. The places >> | where I get the errors seems to come down to LAPACK's dtrtri routine. >> | I have tried to reproduce the error on Debian 18.04.2 with clang 8.0.0 >> | but I cannot reproduce them. >> | >> | The errors came suddenly and the tests passed before. I see similar >> | issues (I think) in the following package: >> | - RcppHMM >> | - BNPmix >> | - themetagenomics >> | - tidytext >> | - stm >> | >> | Any ideas what the error may be? Here is the relevant code parts for >> | one of the failed tests: >> | >> https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/for_tests.cpp#L216 >> | >> https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/BLAS_LAPACK/arma_BLAS_LAPACK.cpp#L26 >> | >> https://github.com/boennecd/dynamichazard/blob/c42105feea5e2d16a8d461b7c606245a743b3e0a/src/BLAS_LAPACK/R_BLAS_LAPACK.cpp#L67 >> >> There are four or more different sources of LAPACK and BLAS on Debian as we >> (since the late 1990s !!) utilize the nature of the _interface_ allowing >> different packages to fill in. >> >> So there could be >> i) the R internal source with a partial library -- Fedora/CentOS use this >> but the Debian distro builds do not >> ii) "reference BLAS", external, unoptimized >> iii) OpenBLAS, the successor to Goto, parallel via multithreading >> iv) Atlas, "tuned" but not mulitthreading >> and more as eg Intel MKL via a quick script (see my blog). >> >> As a historical aside, and way-back-when, ii) earned us year's long growling >> from the direction of Oxfordshire because some early/old versions of LAPACK >> had bugs. But it cuts both ways: the external versions tend to be complete >> whereas what R ships with internally contains a subset -- and at least one >> (early) user of RcppArmadillo was bitten when R built from sources using >> defaults would not have the complex operations he needed. To R Core's credit >> these missing functions got filled in over the years. >> >> In short, you need to look more closely. On the Ubuntu 18.10 machine that I >> type this on, sessionInfo()'s second paragraph has >> >> Matrix products: default >> BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 >> LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.3.so >> >> which IIRC is also the default (via some Debian/Ubuntu internal 'ordering' of >> the available alternatives). >> >> Hth, 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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Whack-a-mole base::assign(".ptime", proc.time(), pos = "CheckExEnv")
That line is a generic part of the timing (it records current time so that at
the end you can do what amounts to "Time used:" proc.time() - .ptime).
It is not likely to contain the actual error -- notice that the message just
gives you a best guess of the error location and that may fail. You probably
need to have a look at the actual radsafer-Ex.R file and its output to find the
true culprit.
If you have catastrophic failures, yes, you see them only one at a time.
-pd
> On 30 Apr 2019, at 03:16 , Mark Hogue wrote:
>
> (The subject title is in reference to the arcade game where fake mole heads
> pop up and the contestant is challenged to smash them down as more and more
> keep popping up.)
>
> I made some changes to a package and when I run the R CMD check, I get one
> error with this lead-in notification:
>
> Running examples in 'radsafer-Ex.R' failed
> The error most likely occurred in:
> *base::assign(".ptime", proc.time(), pos = "CheckExEnv")*
>
> When I do something with the affected function, I get a similar error on
> another function.
>
> Could it have something to do with my having added argument checks on these
> functions? Could someone advise where to go to understand this error
> better? And is it normal to get only one error at a time like this?
>
> Thanks,
>
> Mark
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Misspelled words in DESCRIPTION
I'd write "PK/PD" though. Or did the world change while I was looking the other way? -pd > On 20 Aug 2019, at 00:42 , John Harrold wrote: > > Yeah that's it. Thanks Uwe and Ben. > > On Mon, Aug 19, 2019 at 3:21 PM Ben Bolker wrote: > >> >> I suspect the NOTE said something about "*possibly* misspelled words" >> (emphasis added). This should be OK; just put the explanation below in >> your notes to CRAN about the submission, clarifying that this is indeed >> a false positive. >> >> cheers >>Ben Bolker >> >> On 2019-08-19 6:13 p.m., John Harrold wrote: >>> Hello, >>> >>> I am attempting to submit my first package to CRAN. I believe I've >>> successfully gotten rid of all the notes, but there is one that I'm >> unable >>> to eliminate. In the DESCRIPTION file in both the Title and Description >>> fields I use the term PKPD. This stands for Pharmacokinetics and >>> Pharmacodynamics. It seems that none of these are recognized as words >> that >>> are spelled correctly. They are kind of important in the context of the >>> package and there are no other better or more accurate descriptors that I >>> can use. >>> >>> Is there a way to get around this? >>> >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > > > -- > John > :wq > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] script translation - good practice?
Not a lawyer, but... I would expect that it depends on what license it was published under originally. If it doesn't explicitly allow the creation of derivative works, then I would be wary. -pd > On 18 Sep 2019, at 13:59 , Raphael Bonnet > wrote: > > Hi everyone, > > I just rewrote a bit of Matlab code into R and that I would like to make it > available for the community. > Unfortunately this bit of code has been published by authors that I've never > contacted. > > I was wondering if I could submit a package to CRAN by keeping the same > license as the journal in which the code was published and citing the paper > and the authors. > Can I associate myself as [cre, trl] in the description file? > > Thanks, > Raphael > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] script translation - good practice?
Yes. Check out https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses and also note that CC-BY is not recommended as a software license (by CC themselves). As there is one-way compatibility, it should be possible to clarify the situation by putting your derivative work under the GPL. Although not legally required, it would probably be good manners to inform the original authors. -pd > On 18 Sep 2019, at 14:20 , Raphael Bonnet > wrote: > > Thank you Peter for your response, > > It looks ok for the license. The journal's content appears to be under this > license: > https://creativecommons.org/licenses/by/3.0/ > > Raphael > > Le 18/09/2019 à 14:11, peter dalgaard a écrit : >> Not a lawyer, but... >> >> I would expect that it depends on what license it was published under >> originally. If it doesn't explicitly allow the creation of derivative works, >> then I would be wary. >> >> -pd >> >>> On 18 Sep 2019, at 13:59 , Raphael Bonnet >>> wrote: >>> >>> Hi everyone, >>> >>> I just rewrote a bit of Matlab code into R and that I would like to make it >>> available for the community. >>> Unfortunately this bit of code has been published by authors that I've >>> never contacted. >>> >>> I was wondering if I could submit a package to CRAN by keeping the same >>> license as the journal in which the code was published and citing the paper >>> and the authors. >>> Can I associate myself as [cre, trl] in the description file? >>> >>> Thanks, >>> Raphael >>> >>> __ >>> R-package-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Building fails with 'mypackage/DESCRIPTION' does not exist
Is it really called "mypackage"? Otherwise I'd first check that it is spelled the same way in all cases... Another possibility is that the embedded spaces in the pathname is doing you in. -pd > On 30 Sep 2019, at 16:31 , Steve Gutreuter wrote: > > I have a package which will no longer build after minor changes. The > problem occurs under both Windows 10 and Linux Mint. For example, from a > Windows terminal I do: > > C:\Users\xyz\OneDrive - ORG\Computing\Devel> R CMD build screenr > > and I get: > > * checking for file 'mypackage/DESCRIPTION' ... OK > * preparing 'mypackage': > * checking DESCRIPTION meta-information ... OK > * installing the package to process help pages > * saving partial Rd database > Error in .read_description(ldpath) : > file 'mypackage/DESCRIPTION' does not exist > Execution halted > > So the first and third lines of output contradict the error message, and of > course mypackage/DESCRIPTION does exist. I suspect the problem has nothing > to do with the DESCRIPTION file, but have not found way to identify the > actual problem in searches on StackOverflow and elsewhere. My .R files in > mypackage/R contain Roxygen comments, and curiously devtools::document() > adds nothing to mypackage/man. > > Any suggestions about how to debug or solve this problem? > > Thanks! > Steve > > [[alternative HTML version deleted]] > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Fix non-ASCII characters in R packages
Dunno if it helps, but the NOTE is about "checking data", which, as far as I can decipher the code, means that it is looking at datasets in the data/ directory. So I suspect that looking at *.R files is not going to be the right thing to do. -pd > On 2 Dec 2019, at 14:57 , Rafael Pereira wrote: > > Hi all, > > I am trying to update my R package on CRAN but I am being requested to fix > this NOTE: > > checking data for non-ASCII characters ... NOTE Note: found 58 marked > Latin-1 strings > > I have used to code below to identify my scripts that have strings using > non-ASCII characters. The problem is that in most cases these non-ASCII > characters are used in the documentation of functions, so I cannot simply > convert their encoding using iconv() for example > > # Find scripts using non-ASCII characters > f <- list.files(pattern = "*.R", recursive = T) > r <- lapply(f, tools::showNonASCIIfile) > > I've tried (1) reopening and (2) resaving those scripts with UTF-8 > encoding, (3) setting UTF-8 as the default encoding of the project, but > nothing seems to fix this issue. Any suggestions? > > obs. I've posted this question on SO > https://stackoverflow.com/questions/59139923/fix-non-ascii-characters-in-r-packages > > best, > > Rafael Pereira > > [[alternative HTML version deleted]] > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN submission with "possibly unsafe calls" or alternative approach?
I think you may want to rethink the mechanism.
Locked bindings are generally there to allow the compiler to make assumptions
about the type, etc., of objects (or rather: not make assumptions because it
will know what the type is). Unlocking invalidates this and may trigger
recompilation or introduce errors. (There are people who know the details much
better than I do).
I seem to recall that people have come up with ways to set up an environment
which can contain mutable objects of this sort.
-pd
> On 6 Dec 2019, at 10:05 , Rainer M Krug wrote:
>
> Hi
>
> In my package `dmdScheme` I define three variables. Depending on a state in
> the package (a selected metadata schemes) these are set as followed from
> within the package:
>
> ```
> unlockBinding("dmdScheme_example", as.environment("package:dmdScheme"))
> assign("dmdScheme_example", scheme_example, "package:dmdScheme")
> lockBinding("dmdScheme_example", as.environment("package:dmdScheme"))
>
>
> scheme_raw <- as_dmdScheme_raw(scheme_example)
> unlockBinding("dmdScheme_raw", as.environment("package:dmdScheme"))
> assign("dmdScheme_raw", scheme_raw, "package:dmdScheme")
> lockBinding("dmdScheme_raw", as.environment("package:dmdScheme"))
>
>
> scheme <- as_dmdScheme(scheme_raw, keepData = FALSE, checkVersion = FALSE)
> unlockBinding("dmdScheme", as.environment("package:dmdScheme"))
> assign("dmdScheme", scheme, "package:dmdScheme")
> lockBinding("dmdScheme", as.environment("package:dmdScheme”))
> ```
>
> ( See
> https://github.com/Exp-Micro-Ecol-Hub/dmdScheme/blob/b97e7b5ef116476e065aeec1da1050eecbd6adf7/R/scheme_use.R#L37-L49
> )
>
> My reasoning is that I want to lock these variables, as they are essential to
> the functioning of the package.
>
> But I get, probably not surprising, the following NOTE:
>
>
> ```
> * checking R code for possible problems ... NOTE
> Found the following possibly unsafe calls:
> File ‘dmdScheme/R/scheme_use.R’:
> unlockBinding("dmdScheme_example", as.environment("package:dmdScheme"))
> unlockBinding("dmdScheme_raw", as.environment("package:dmdScheme"))
> unlockBinding("dmdScheme", as.environment("package:dmdScheme"))
> ```
>
> For the submission to CRAN, Can I disregard this note and explain it during
> the submission?
>
> My second question concerns the values itself. I set the variables to NULL in
> the /data folder in the package, but even after they are set as above, the
> valuee in `dmdScheme::dmdScheme` is still NULL:
>
> ```
>> names(dmdScheme)
> [1] "Experiment" "Genus""Treatments" "Measurement"
> [5] "DataExtraction" "DataFileMetaData"
>> names(dmdScheme::dmdScheme)
> NULL
>>
> ```
>
> Is there a way, that I can change the value of dmdScheme::… variables during
> runtime?
>
> Thanks,
>
> Rainer
>
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
> UCT), Dipl. Phys. (Germany)
>
> Orcid ID: 0000-0002-7490-0066
>
> Department of Evolutionary Biology and Environmental Studies
> University of Zürich
> Office Y34-J-74
> Winterthurerstrasse 190
> 8075 Zürich
> Switzerland
>
> Office: +41 (0)44 635 47 64
> Cell: +41 (0)78 630 66 57
> email: rainer.k...@uzh.ch
> rai...@krugs.de
> Skype: RMkrug
>
> PGP: 0x0F52F982
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Need help to resolve NOTEs in auto check
(a) Spelling issues: False positive are checked manually by CRAN, so just tell them on submission. For software items, Uwe at some point recommended "Single quotes around software names such as 'pkg', functions should be written with parentheses as in foo()." (b) The procedure for submitting is to run 'R CMD build' on the (unpackaged) source directory, then submit the resulting .tar.gz file. If you don't do that, the build time stamp will be absent. Similarly 'R CMD check' should be run on the output from 'R CMD build'. Like this (oups, that dir is out of sync on this computer): Peters-iMac:ISWR-2nd-ed pd$ R CMD build ISwR * checking for file ‘ISwR/DESCRIPTION’ ... OK * preparing ‘ISwR’: * checking DESCRIPTION meta-information ... OK * checking for LF line-endings in source and make files and shell scripts * checking for empty or unneeded directories * looking to see if a ‘data/datalist’ file should be added * re-saving .R files as .rda NB: *.R converted to .rda: other files may need to be removed * re-saving tabular files * creating default NAMESPACE file * building ‘ISwR_2.0-5.tar.gz’ Peters-iMac:ISWR-2nd-ed pd$ R CMD check --as-cran ISwR_2.0-5.tar.gz * using log directory ‘/Users/pd/BIOSTAT/books/ISWR-2nd-ed/ISwR.Rcheck’ * using R version 3.6.0 (2019-04-26) * using platform: x86_64-apple-darwin15.6.0 (64-bit) * using session charset: UTF-8 * using option ‘--as-cran’ * checking for file ‘ISwR/DESCRIPTION’ ... OK * this is package ‘ISwR’ version ‘2.0-5’ * checking CRAN incoming feasibility ... WARNING Maintainer: ‘Peter Dalgaard ’ Insufficient package version (submitted: 2.0.5, existing: 2.0.8) Days since last update: 2 The Date field is over a month old. * checking package namespace information ... OK *.. (c) Examples _will_ be run as part of the check procedure. If that produces stray files in the check directory, you will tget the message that you see. In interactive usage, example(...) will similarly create files in the current directory, which is verboten, so write to a temporary directory instead. (See help(tempfile) for specifics). > On 22 Jan 2020, at 11:29 , Ian Walker wrote: > > Hello, > > I'm trying to repackage an R function so I can update the licence. I'm stuck > with the automatic checks. The problem appears to be the following three > NOTEs in the checking output: > > * checking CRAN incoming feasibility ... NOTE > Maintainer: ‘Ian Walker < > i.wal...@bath.ac.uk >> ’ > > Possibly mis-spelled words in DESCRIPTION: > DEMs (7:503) > STL (7:47) > stereolithography (7:52) > stl (7:24) > > The build time stamp is missing. > > It's not clear what is wrong here - is it the spellings (which are fine) or > the time stamp? If the latter, how do I resolve this? > > * checking DESCRIPTION meta-information ... NOTE > Checking should be performed on sources prepared by ‘R CMD build’. > > I can't make any sense of this issue! > > * checking for non-standard things in the check directory ... NOTE > Found the following files/directories: > ‘lovelyfunction.stl’ ‘volcano.stl’ > > These two .stl files are simply mentioned in the documentation's example code > - they're files that would be created if somebody ran the example code; > they're not in the R package I've created. > > Thanks for any help, > > Ian > -- > Dr Ian Walker FHEA | Department of Psychology, University of Bath > i.wal...@bath.ac.uk (academic) | m...@drianwalker.com (other matters) > > Website: drianwalker.com | Twitter: twitter.com/ianwalker > > My books: > Research Methods and Statistics - a new, clear introduction > http://tinyurl.com/res-stats > Research with People - the essential research textbook: http://amzn.to/sRbYxy > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [FORGED] Re: Help on Windows CRAN Check
Well, it originates in C, where & and | are bitwise operators.
-pd
> On 5 Mar 2020, at 15:44 , Jeff Jetton wrote:
>
> This is something that, by the way, I've always thought R got backwards. If
> you want an operation to handle "one thing" against "one other thing"
> (scalars), a single & or | seems like the obvious symbol for it. Whereas an
> operation on "multiple things" (vectors) would be well-represented by a
> multiple-character symbol like && or ||.
>
> But as long as I remember that it's backwards, I can keep them sorted out.
> :-)
>
> - Jeff
>
> On Thu, Mar 5, 2020 at 6:14 AM Uwe Ligges
> wrote:
>
>>
>>
>> On 05.03.2020 09:45, Rolf Turner wrote:
>>>
>>> On 5/03/20 9:04 pm, Tomas Kalibera wrote:
>>>
>>>> On 3/5/20 4:26 AM, John Lawson wrote:
>>>>> I see this error on the CRAN Check report
>>>
>>>
>>>
>>>>> Fatal error: the condition has length > 1
>>>>
>>>> The problem is that the condition t1 == "I" & t2 == "(" of the if
>>>> statement in the code is not a scalar. Even though this has been allowed
>>>> in R historically, the first element has been used, it is almost always
>>>> a sign of coding error, so it is going to become a runtime error.
>>>>
>>>> So what one should do is fix the code to only use scalar conditions -
>>>> ensure t1, t2 are scalar, replace & by &&.
>>>
>>> Perhaps I'm being even thicker than usual (imagine that!)
>>
>> Oh dear, but this time it is true...:
>>
>>
>>> but I don't
>>> grok that last recommendation: "replace & by &&". It's usually
>>> harmless but indicates a lack of understanding. The "&&" operator
>>> evaluates the second condition only if the first condition is TRUE. It
>>
>> Right, and as the conditions are scalar, we never have to evaluate the
>> 2nd if the first is FALSE unless you do it for side effects.
>>
>> So for logical operators on scalar logical vectors, one should prefer &&
>> and || for efficeincy reasons.
>>
>> Best,
>> Uwe
>>
>>
>>
>>
>>> is useful (only) in setting where the second condition is meaningful
>>> only when the first condition is TRUE.
>>>
>>> Things like:
>>>
>>>if(!is.null(x) && x > 0)
>>>
>>> If "x" were null then the second condition would cause an error to be
>>> thrown if you used "&" rather than "&&".
>>>
>>> In all (???) situations where "&&" works, then "&" works as well.
>>> However it's a Good Idea to use the language as intended.
>>>
>>> It I'm missing some point here, please enlighten me.
>>>
>>>
>>>
>>> cheers,
>>>
>>> Rolf
>>>
>>
>> __
>> 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
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] note about mispelled words
However, notice that if it is the guy from the Kruskal-Wallis test (William K., 1919--2005), the "Kruskall" is in fact misspelt. It might be someone else, of course... -pd > On 17 Mar 2020, at 18:24 , Duncan Murdoch wrote: > > I believe it is also acceptable to explain in your submission message that > the misspelled words are all proper names. As far as I know, misspellings > are not enough of a problem to cause an automatic rejection, so a human being > will be making a judgment about the note. > > Duncan Murdoch > > On 17/03/2020 11:41 a.m., Henrik Bengtsson wrote: >> You can single quote them to avoid them being spell checked, e.g. ... >> using methods of 'Kruskall' and 'Brainerd'. This is a common and >> accepted practice. >> This is hinted at in "Writing R Extensions" (e.g. help.start()); >> The mandatory ‘Description’ field should give a comprehensive >> description of what the package does. One can use several (complete) >> sentences, but only one paragraph. It should be intelligible to all >> the intended readership (e.g. for a CRAN package to all CRAN users). >> It is good practice not to start with the package name, ‘This package’ >> or similar. As with the ‘Title’ field, double quotes should be used >> for quotations (including titles of books and articles), and single >> quotes for non-English usage, including names of other packages and >> external software. This field should also be used for explaining the >> package name if necessary. URLs should be enclosed in angle brackets, >> e.g. ‘<https://www.r-project.org>’: see also Specifying URLs. >> /Henrik >> On Tue, Mar 17, 2020 at 8:30 AM Gianmarco Alberti >> wrote: >>> >>> Hello, >>> I am checking a package of mine, and I got only 1 note regarding possibly >>> misspelled words in the DESCRIPTION. >>> >>> The issue I am facing is that those 6 words are not actually misspelled, >>> being either first or last names of individuals (actually, statistician; >>> e.g., Kruskall, Brainerd). >>> >>> Shall I have to do something (removing those; which does not make sense), >>> or upon submitting my new version of the package there is a way to make >>> clear that that note can be ignored? >>> >>> By the way, those names were already there in earlier versions of the >>> package and no note cropped out in those occasions. >>> >>> Thank you >>> Best >>> GmA >>> >>> >>> Dr Gianmarco Alberti (PhD Udine) >>> Lecturer in Spatial Forensics >>> Coordinator of the BA course in Criminology >>> Department of Criminology >>> Faculty for Social Wellbeing >>> Room 332, Humanities B (FEMA) >>> University of Malta, Msida, Malta (Europe) - MSD 2080 >>> tel +356 2340 3718 >>> >>> Academic profiles >>> https://www.researchgate.net/profile/Gianmarco_Alberti4 >>> https://malta.academia.edu/GianmarcoAlberti >>> >>> Google Scholar profile >>> https://scholar.google.com/citations?user=tFrJKQ0J&hl=en >>> >>> Correspondence Analysis website >>> http://cainarchaeology.weebly.com/ >>> >>> R packages on CRAN: >>> CAinterprTools >>> https://cran.r-project.org/web/packages/CAinterprTools/index.html >>> >>> GmAMisc >>> https://cran.r-project.org/package=GmAMisc >>> >>> movecost >>> https://cran.r-project.org/web/packages/movecost/index.html >>> >>> >>> [[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 >> > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [R] a question of etiquette
hi Azzalini >>>> Subject: [R] a question of etiquette >>>> Date: June 1, 2020 at 11:34:00 AM CDT >>>> To: r-h...@r-project.org >>>> >>>> The new version of a package which I maintain will include a new function >>>> which I have ported to R from Matlab. >>>> The documentation of this R function indicates the authors of the original >>>> Matlab code, reference to their paper, URL of the source code. >>>> >>>> Question: is this adequate, or should I include them as co-authors of the >>>> package, or as contributors, or what else? >>>> Is there a general policy about this matter? >>>> >>>> Adelchi Azzalini >>>> http://azzalini.stat.unipd.it/ >>>> >>>> __ >>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see >>>> https://stat.ethz.ch/mailman/listinfo/r-help >>>> PLEASE do read the posting guide >>>> http://www.R-project.org/posting-guide.html >>>> and provide commented, minimal, self-contained, reproducible code. >>> [[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 > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
