Re: [R-pkg-devel] Saving binary files in a package
You have no guarantee that the user has write access to those folders. So you might want to rethink your strategy. ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance Kliniekstraat 25 1070 Anderlecht Belgium To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey Op 4 jul. 2015 05:00 schreef "Glenn Schultz" : > Hi All, > > I am researching the criteria for submitting packages on the R website and > using Hadley's packages book as a general guide. The CRAN policy is that a > package cannot write files. My question is as follows: > > Does this apply when the package is installed only? I ask because my > package does not write any files on install. However, I have functions > that allow the user to create cusip level information to create a MBS > security (dated date, first payment date, etc.). The function then saves > the file as a binary to the appropiate data folder in the package file > directories. I use the same strategy to save mortgage prepayment model > tuning parameters. > > If the result of the function, after a package is installed, is to save a > data file in the package's subdirectories does this violate CRAN policy > against writing files? I read the policy but I am not 100% sure in this > case. > > -Glenn > __ > 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
Re: [R-pkg-devel] Saving binary files in a package
On 4 July 2015 at 09:12, Thierry Onkelinx wrote: | You have no guarantee that the user has write access to those folders. So | you might want to rethink your strategy. Seconded. And I am not aware of a good cross-platform solution so your best bet may be to require the user to specify a filename. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Saving binary files in a package
On Sat, Jul 4, 2015 at 10:00 AM, Dirk Eddelbuettel wrote: > > On 4 July 2015 at 09:12, Thierry Onkelinx wrote: > | You have no guarantee that the user has write access to those folders. So > | you might want to rethink your strategy. > > Seconded. And I am not aware of a good cross-platform solution so your best > bet may be to require the user to specify a filename. One attempt to correctly locate the right place to save files (i.e. the user data dir) is http://cran.r-project.org/web/packages/rappdirs/index.html, a fork of the python appdirs (https://github.com/ActiveState/appdirs). There's no guarantee that these places will be writeable, but they're probably a reasonably good place to start. Hadley -- http://had.co.nz/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check crash for Ubuntu 14.04 R-3.2.1 only
Charles, I took a look based on your tar ball. When I use the normal 'loud' setting I default to for g++ (ie -pedantic -Wall) or clang++ I get more than a page full of errors. I just tried it using the UBSAN-via-clang instrumented R I provide via a docker container (and for which I showed usage during the 'rocker: Docker on R' tutorial preceding useR! -- slides now on my presentation page). It also does not segfault, but it shows a test difference: Running ‘bar.R’ Comparing ‘bar.Rout’ to ‘bar.Rout.save’ ...8d7 < 51,54c50,53 < [1,]010100 < [2,]011000 < [3,]010010 < [4,]010001 --- > [1,]010001 > [2,]010010 > [3,]010100 > [4,]011000 Running ‘bug2.R’ Comparing ‘bug2.Rout’ to ‘bug2.Rout.save’ ...8d7 < (You also seem to consistently differ in one newline which is just a nuisance and not an error,) So no free lunch yet. I fear you may have to minimize the package somewhat to hopefully arrive at minimally reproducible example. So far you seem to have a Heisenbug (https://en.wikipedia.org/wiki/Heisenbug) Sorry I cannot offer more help. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check crash for Ubuntu 14.04 R-3.2.1 only
The diff for bar.Rout is OK. The solution is the same (the two matrices have the same rows and so determine the same convex polyhedron). Why it picks different orders of rows on different machines, I have no idea. I also saw the pages of warnings from gcc -W -Wall -Wextra but they are all about unused variables and unused arguments of functions. AFAIK these are not real problems. I should say that I did not write most of the code. This package is an R interface to the computational geometry provided by cddlib, which is not something linux distributions package. So in order to avoid hassle, I just included the cddlib code (which is GPL) in the src directory and added its author Komei Fukuda to the authors of the package. AFAIK this code is very high quality from a numerical analysis standpoint, however much it may fall below the coding standards of most C coders. Anyway it is the only free software computational geometry code I know about, so it is the only game in town unless statisticians want to just say "we cannot deal with problems like that". This code may actually segfault somewhere, but we haven't seen it in practice unless this is its fault (rather than the 32 bit R-3.2.1 build for Ubuntu 14.04). We still don't have a way to tell which to blame. I am trying to follow the debugging rules (http://debuggingrules.com/) the most important here being "divide and conquer". Until we know where the crash occurs, we are just clueless. On Sat, Jul 4, 2015 at 3:35 AM, Dirk Eddelbuettel wrote: > > Charles, > > I took a look based on your tar ball. When I use the normal 'loud' > setting I > default to for g++ (ie -pedantic -Wall) or clang++ I get more than a page > full of errors. I just tried it using the UBSAN-via-clang instrumented R I > provide via a docker container (and for which I showed usage during the > 'rocker: Docker on R' tutorial preceding useR! -- slides now on my > presentation page). It also does not segfault, but it shows a test > difference: > > Running ‘bar.R’ > Comparing ‘bar.Rout’ to ‘bar.Rout.save’ ...8d7 > < > 51,54c50,53 > < [1,]010100 > < [2,]011000 > < [3,]010010 > < [4,]010001 > --- > > [1,]010001 > > [2,]010010 > > [3,]010100 > > [4,]011000 > Running ‘bug2.R’ > Comparing ‘bug2.Rout’ to ‘bug2.Rout.save’ ...8d7 > < > > (You also seem to consistently differ in one newline which is just a > nuisance > and not an error,) > > So no free lunch yet. I fear you may have to minimize the package somewhat > to hopefully arrive at minimally reproducible example. So far you seem to > have a Heisenbug (https://en.wikipedia.org/wiki/Heisenbug) > > Sorry I cannot offer more help. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > -- Charles Geyer Professor, School of Statistics University of Minnesota char...@stat.umn.edu [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check crash for Ubuntu 14.04 R-3.2.1 only
I should add a more direct question. When a crash occurs ONLY when running R CMD check, how does one debug that? Usually one would say that R CMD check --use-valgrind is the answer. But it only segfaults when --use-vagrind is not used. So somehow we have to debug R CMD check itself. How? On Sat, Jul 4, 2015 at 10:15 AM, Charles Geyer wrote: > The diff for bar.Rout is OK. The solution is the same (the two matrices > have the same rows and so determine the same convex polyhedron). Why it > picks different orders of rows on different machines, I have no idea. > > I also saw the pages of warnings from gcc -W -Wall -Wextra but they are > all about unused variables and unused arguments of functions. AFAIK these > are not real problems. > > I should say that I did not write most of the code. This package is an R > interface to the computational geometry provided by cddlib, which is not > something linux distributions package. So in order to avoid hassle, I just > included the cddlib code (which is GPL) in the src directory and added its > author Komei Fukuda to the authors of the package. > > AFAIK this code is very high quality from a numerical analysis standpoint, > however much it may fall below the coding standards of most C coders. > Anyway it is the only free software computational geometry code I know > about, so it is the only game in town unless statisticians want to just say > "we cannot deal with problems like that". > > This code may actually segfault somewhere, but we haven't seen it in > practice unless this is its fault (rather than the 32 bit R-3.2.1 build for > Ubuntu 14.04). We still don't have a way to tell which to blame. > > I am trying to follow the debugging rules (http://debuggingrules.com/) > the most important here being "divide and conquer". Until we know where > the crash occurs, we are just clueless. > > On Sat, Jul 4, 2015 at 3:35 AM, Dirk Eddelbuettel wrote: > >> >> Charles, >> >> I took a look based on your tar ball. When I use the normal 'loud' >> setting I >> default to for g++ (ie -pedantic -Wall) or clang++ I get more than a page >> full of errors. I just tried it using the UBSAN-via-clang instrumented R >> I >> provide via a docker container (and for which I showed usage during the >> 'rocker: Docker on R' tutorial preceding useR! -- slides now on my >> presentation page). It also does not segfault, but it shows a test >> difference: >> >> Running ‘bar.R’ >> Comparing ‘bar.Rout’ to ‘bar.Rout.save’ ...8d7 >> < >> 51,54c50,53 >> < [1,]010100 >> < [2,]011000 >> < [3,]010010 >> < [4,]010001 >> --- >> > [1,]010001 >> > [2,]010010 >> > [3,]010100 >> > [4,]011000 >> Running ‘bug2.R’ >> Comparing ‘bug2.Rout’ to ‘bug2.Rout.save’ ...8d7 >> < >> >> (You also seem to consistently differ in one newline which is just a >> nuisance >> and not an error,) >> >> So no free lunch yet. I fear you may have to minimize the package >> somewhat >> to hopefully arrive at minimally reproducible example. So far you seem to >> have a Heisenbug (https://en.wikipedia.org/wiki/Heisenbug) >> >> Sorry I cannot offer more help. >> >> Dirk >> >> -- >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> > > > > -- > Charles Geyer > Professor, School of Statistics > University of Minnesota > char...@stat.umn.edu > -- Charles Geyer Professor, School of Statistics University of Minnesota char...@stat.umn.edu [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check crash for Ubuntu 14.04 R-3.2.1 only
Agreed on divide-and-conquer. There is no other way. Valgridn et al may move some code to registers for subtle changes. On 4 July 2015 at 10:20, Charles Geyer wrote: | I should add a more direct question. When a crash occurs ONLY when running R | CMD check, how does one debug that? Usually one would say that R CMD check | --use-valgrind | is the answer. But it only segfaults when --use-vagrind is not used. So | somehow we have to debug R CMD check itself. How? By "mocking" the exact same (compile and run-time) options used by R CMD check. You can trace that down. Things depend a little on whether you do or do not use user-library-paths for .libPaths() or not, whether you use per-user compile flags etc pp. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD check crash for Ubuntu 14.04 R-3.2.1 only
Your "mocking" phrase in unknown to me. I am not sure where to trace that down. Read the bash script for check? Read tools:::.check_packages? Both are clear as mud to me. Also I just tried debugging by print statements. That does not work. It leaves the C called just before the crash. Putting a cat statement in the R function that calls the C function prevents the crash. I know. If there is memory corruption, doing anything can change the crash behavior. So that is not mystifying. Just frustrating. On Sat, Jul 4, 2015 at 10:48 AM, Dirk Eddelbuettel wrote: > > Agreed on divide-and-conquer. There is no other way. Valgridn et al may > move > some code to registers for subtle changes. > > On 4 July 2015 at 10:20, Charles Geyer wrote: > | I should add a more direct question. When a crash occurs ONLY when > running R > | CMD check, how does one debug that? Usually one would say that R CMD > check > | --use-valgrind > | is the answer. But it only segfaults when --use-vagrind is not used. So > | somehow we have to debug R CMD check itself. How? > > By "mocking" the exact same (compile and run-time) options used by R CMD > check. You can trace that down. Things depend a little on whether you do > or > do not use user-library-paths for .libPaths() or not, whether you use > per-user compile flags etc pp. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > -- Charles Geyer Professor, School of Statistics University of Minnesota char...@stat.umn.edu [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
