Re: [R-pkg-devel] bayespca package - CRAN test

[Facundo Muñoz]

If you have access to a linux box (or cygwin), there is this tool [1]
that lets you do something like

find . -name inst/include/*.h | xargs dos2unix

to fix all the line breaks in one shot.

There are also binaries for Windows so you should be able to do this
from your computer.

Best,

    ƒacu.-


[1] https://waterlan.home.xs4all.nl/dos2unix.html

On 6/5/19 1:13 PM, D. Vidotto wrote:
> Dear members,
>
> Yesterday I submitted a package called 'bayespca' (version 
> 0.0.2) to CRAN. Today, I received an e-mail saying that the package did not 
> pass some test.
> Thus, today I have been working on fixing these problems (original three 
> notes). While I could fix almost all of them, there is still one problem left 
> which I cannot fix. It is the following one:
>
> * checking line endings in C/C++/Fortran sources/headers ... NOTE
> Found the following sources/headers with CR or CRLF line endings:
>   inst/include/aux_functions.h
>   inst/include/elbo_functions.h
>   inst/include/expectedvalues.h
>   inst/include/updateElbo.h
>   inst/include/updateExpected.h
>   inst/include/vbalgorithm.h
> Some Unix compilers require LF line endings.
>
>
> How can I fix these? Why are my cpp files in the source folder correct, while 
> these headers are not? Furthermore, when I run the R CMD check -as-cran on my 
> machine (Windows), the test about line endings pass with no problems. May you 
> help me telling me how I can modify the line endings of the above files?
>
> Thank you in advance for your help.
>
>
> With kind regards,
>
> Davide Vidotto
> Tilburg University
>
>
>   [[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] mvrnorm, eigen, tests, and R CMD check

[Facundo Muñoz]

In my opinion, the underlying problem is that you are checking whether
the test reproduces exactly your pre-computed solution, while there
actually exist other valid answers.

I believe you want to check whether the sub-spaces are the same, not
whether the bases are identical (which can depend on platform, linear
algebra library, etc.)

ƒacu.-



On 05/17/2018 09:30 PM, Kevin Coombes wrote:
> Yes; I'm pretty sure that it is exactly the repeated eigenvalues that are
> the issue. The matrices I am using are all nonsingular, and the various
> algorithms have no problem computing the eigenvalues correctly (up to
> numerical errors that I can bound and thus account for on tests by rounding
> appropriately). But an eigenvalue of multiplicity M has an M-dimensional
> eigenspace with no preferred basis. So, any M-dimensional  (unitary) change
> of basis is permitted. That's what give rise to the lack of reproducibility
> across architectures. The choice of basis appears to use different
> heuristics on 32-bit windows than on 64-bit Windows or Linux machines. As a
> result, I can't include the tests I'd like as part of a CRAN submission.
>
> On Thu, May 17, 2018, 2:29 PM William Dunlap  wrote:
>
>> Your explanation needs to be a bit more general in the case of identical
>> eigenvalues - each distinct eigenvalue has an associated subspace, whose
>> dimension is the number repeats of that eigenvalue and the eigenvectors for
>> that eigenvalue are an orthonormal basis for that subspace.  (With no
>> repeated eigenvalues this gives your 'unique up to sign'.)
>>
>> E.g., for the following 5x5 matrix with two eigenvalues of 1 and two of 0
>>
>>   > x <- tcrossprod( cbind(c(1,0,0,0,1),c(0,1,0,0,1),c(0,0,1,0,1)) )
>>   > x
>>[,1] [,2] [,3] [,4] [,5]
>>   [1,]10001
>>   [2,]01001
>>   [3,]00101
>>   [4,]00000
>>   [5,]11103
>> the following give valid but different (by more than sign) eigen vectors
>>
>> e1 <- structure(list(values = c(4, 1, 0.999, 0,
>> -2.22044607159862e-16
>> ), vectors = structure(c(-0.288675134594813, -0.288675134594813,
>> -0.288675134594813, 0, -0.866025403784439, 0, 0.707106781186547,
>> -0.707106781186547, 0, 0, 0.816496580927726, -0.408248290463863,
>> -0.408248290463863, 0, -6.10622663543836e-16, 0, 0, 0, -1, 0,
>> -0.5, -0.5, -0.5, 0, 0.5), .Dim = c(5L, 5L))), .Names = c("values",
>> "vectors"), class = "eigen")
>> e2 <- structure(list(values = c(4, 1, 1, 0, -2.29037708937563e-16),
>> vectors = structure(c(0.288675134594813, 0.288675134594813,
>> 0.288675134594813, 0, 0.866025403784438, -0.784437556312061,
>> 0.588415847923579, 0.196021708388481, 0, 4.46410900710223e-17,
>> 0.22654886208902, 0.566068420404321, -0.79261728249334, 0,
>> -1.11244069540181e-16, 0, 0, 0, -1, 0, -0.5, -0.5, -0.5,
>> 0, 0.5), .Dim = c(5L, 5L))), .Names = c("values", "vectors"
>> ), class = "eigen")
>>
>> I.e.,
>>> all.equal(crossprod(e1$vectors), diag(5), tol=0)
>> [1] "Mean relative difference: 1.407255e-15"
>>> all.equal(crossprod(e2$vectors), diag(5), tol=0)
>> [1] "Mean relative difference: 3.856478e-15"
>>> all.equal(e1$vectors %*% diag(e1$values) %*% t(e1$vectors), x, tol=0)
>> [1] "Mean relative difference: 1.110223e-15"
>>> all.equal(e2$vectors %*% diag(e2$values) %*% t(e2$vectors), x, tol=0)
>> [1] "Mean relative difference: 9.069735e-16"
>>
>>> e1$vectors
>>[,1]   [,2]  [,3] [,4] [,5]
>> [1,] -0.2886751  0.000  8.164966e-010 -0.5
>> [2,] -0.2886751  0.7071068 -4.082483e-010 -0.5
>> [3,] -0.2886751 -0.7071068 -4.082483e-010 -0.5
>> [4,]  0.000  0.000  0.00e+00   -1  0.0
>> [5,] -0.8660254  0.000 -6.106227e-160  0.5
>>> e2$vectors
>>   [,1]  [,2]  [,3] [,4] [,5]
>> [1,] 0.2886751 -7.844376e-01  2.265489e-010 -0.5
>> [2,] 0.2886751  5.884158e-01  5.660684e-010 -0.5
>> [3,] 0.2886751  1.960217e-01 -7.926173e-010 -0.5
>> [4,] 0.000  0.00e+00  0.00e+00   -1  0.0
>> [5,] 0.8660254  4.464109e-17 -1.112441e-160  0.5
>>
>>
>>
>>
>>
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com
>>
>> On Thu, May 17, 2018 at 10:14 AM, Martin Maechler <
>> maech...@stat.math.ethz.ch> wrote:
>>
 Duncan Murdoch 
 on Thu, 17 May 2018 12:13:01 -0400 writes:
>>> > On 17/05/2018 11:53 AM, Martin Maechler wrote:
>>> >>> Kevin Coombes ... on Thu, 17
>>> >>> May 2018 11:21:23 -0400 writes:
>>>
>>> >>[..]
>>>
>>> >> > [3] Should the documentation (man page) for "eigen" or
>>> >> > "mvrnorm" include a warning that the results can change
>>> >> > from machine to machine (or between things like 32-bit and
>>> >> > 64-bit R on the same machine) because of difference in
>>> >> > linear algebra modules? (Possibly including the statement
>>> >> > that "set.seed" won't save you.)
>>>
>>> >> The problem 

Re: [R-pkg-devel] R force download of specific package versions in DESCRIPTION file

[Facundo Muñoz]

I think Packrat [1] might help:

- Isolated: ... each project its own private package library.
- Reproducible: ... exact versions are the ones that get installed ...

ƒacu.-

[1] https://rstudio.github.io/packrat/


On 05/18/2017 04:34 PM, Martin Watts wrote:
> I have created a package (which I host on a local server) that I have set
> up to depend on exact versions of other packages, i.e my DESCRIPTION file
> looks like this:
>
> Package: myPackage
> Depends:
> R (>= 3.2.5)
> Imports:
> dplyr (== 0.5.0),
> lazyeval (== 0.2.0),
> lubridate (== 1.6.0),
> magrittr (== 1.5),
> reshape2 (== 1.4.2)
>
>
> My expectation is that when I run install.packages('myPackage') that each
> of these specific dependency versions will be installed, but this is not
> the case. It looks like if a dependent package is not present at all then
> it is installed to the correct version, but when it is present at a LATER
> version it is not rolled-back to the desired version.
>
> Is there a way that we can force all requested versions of these packages
> to be installed? We would like this behaviour as we'd like a way to
> guarantee that all R environments are exactly the same when running this
> code.
>
> Note that I've been testing using devtools::install, but I assume that this
> mirrors the behaviour of install.packages.
> Also posted on SO: http://stackoverflow.com/questions/44028355/r-force-
> download-of-specific-package-versions-in-description-file
>
> Thanks,
> Martin
>
>   [[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

[R-pkg-devel] coercion in R CMD check

[Facundo Muñoz]

I have been struggling all day with this issue, which was terribly
difficult to identify.

In the end, if I have a test in my package such as:

test_that("coercions works... depending the check", {
  s = "/A/string/starting/with/a/slash"
  expect_true(s > 0)
})


then if I test() it, it goes fine.
But if I R CMD check the packaged source, it fails.

I don't understand the difference between the testing performed by R CMD
check, and the testing performed by myself. It is not related with
--as-cran.


Cheers
ƒacu.-

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Fwd: src/install.libs.R

[Facundo Muñoz]

I relaunch this question for which I had no answers.
Just in case someone who can give some insight missed it before.

Thanks in advance
ƒacu.-



 Mensaje reenviado 
Asunto: src/install.libs.R
Fecha:  Tue, 6 Oct 2015 11:41:23 +0200
De: Facundo Muñoz 
Para:   r-package-devel@r-project.org



Dear all,

I need to make use of the |src/install.libs.R| file, in order to perform
certain tasks at installation time.
I followed the R-exts doc
<http://cran.univ-paris1.fr/doc/manuals/r-release/R-exts.html#Package-subdirectories>.
However, R CMD INSTALL seems to never run the script.

Here is a minimal reproducible example.
It makes use of |devtools| to simplify the example, but I have tried the
installation manually as well.

|## Create a minimal buildable package library(devtools)
create('testpkg') ## Write src/install.libs.R dir.create('testpkg/src')
test.file <- path.expand('~/testfile.txt') diag.lines <- c(
deparse(quote(stop('This should break the installation'))),
deparse(quote(file.create(test.file))) ) writeLines(diag.lines,
'testpkg/src/install.libs.R') ## Install package ## also tried manually
with R CMD INSTALL install('testpkg') ## The installation did not break
## nor the file has been created file.exists('~/testfile.txt') # FALSE
## Cleanup remove.packages('testpkg') unlink('testpkg', recursive = TRUE) |

Am I missing something?

thanks in advance
ƒacu.-

PS: by the way…

|> sessionInfo() R version 3.2.2 (2015-08-14) Platform:
x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 14.04.2 LTS locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=fr_FR.UTF-8
LC_MESSAGES=en_US.UTF-8 LC_PAPER=fr_FR.UTF-8 LC_NAME=C [9] LC_ADDRESS=C
LC_TELEPHONE=C LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C attached
base packages: [1] stats graphics grDevices utils datasets methods base
other attached packages: [1] devtools_1.8.0.9000 loaded via a namespace
(and not attached): [1] tools_3.2.2 memoise_0.2.1 digest_0.6.8 |

​



[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] src/install.libs.R

[Facundo Muñoz]

Dear all,

I need to make use of the |src/install.libs.R| file, in order to perform
certain tasks at installation time.
I followed the R-exts doc
.
However, R CMD INSTALL seems to never run the script.

Here is a minimal reproducible example.
It makes use of |devtools| to simplify the example, but I have tried the
installation manually as well.

|## Create a minimal buildable package library(devtools)
create('testpkg') ## Write src/install.libs.R dir.create('testpkg/src')
test.file <- path.expand('~/testfile.txt') diag.lines <- c(
deparse(quote(stop('This should break the installation'))),
deparse(quote(file.create(test.file))) ) writeLines(diag.lines,
'testpkg/src/install.libs.R') ## Install package ## also tried manually
with R CMD INSTALL install('testpkg') ## The installation did not break
## nor the file has been created file.exists('~/testfile.txt') # FALSE
## Cleanup remove.packages('testpkg') unlink('testpkg', recursive = TRUE) |

Am I missing something?

thanks in advance
ƒacu.-

PS: by the way…

|> sessionInfo() R version 3.2.2 (2015-08-14) Platform:
x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 14.04.2 LTS locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=fr_FR.UTF-8
LC_MESSAGES=en_US.UTF-8 LC_PAPER=fr_FR.UTF-8 LC_NAME=C [9] LC_ADDRESS=C
LC_TELEPHONE=C LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C attached
base packages: [1] stats graphics grDevices utils datasets methods base
other attached packages: [1] devtools_1.8.0.9000 loaded via a namespace
(and not attached): [1] tools_3.2.2 memoise_0.2.1 digest_0.6.8 |

​

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] extending a few functions from another package

[Facundo Muñoz]

Dear list,

I have built a package geoRcb (https://github.com/famuvie/geoRcb) which
is an extension of package geoR.
It provides some very specific additional functionality, in the form of
new arguments for only 3 functions from geoR.
It also has some original complementary functions, but otherwise keeps
most of geoR untouched.

To avoid forking the whole geoR package (and duplicating the vast
majority of the code), I only packaged the modified (or original)
functions. However, since these functions make use of some other
internal functions, I used the dirty trick of *implanting* the modified
functions within the geoR namespace
(https://github.com/famuvie/geoRcb/blob/master/R/geoRcb.R)

I understand that modifying another package's namespace is very bad.
But I don't see how to proceed correctly in this case without forking
the whole package.

Thanks for your suggestions.
ƒacu.-

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel