[Rd] r cmd build
On Windows Vista hhc.exe is not available. One can do this on an install: rcmd install --docs=normal myPackage to avoid the message about hhc.exe; however, "rcmd build" does not appear to support --docs=normal so one cannot do a build without getting a message about hhc.exe (although the build still proceeds). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build failure
I have a local library 'dart' that imports "httr". It has routines that access central patient data such as birth date, so it is heavily used locally but of no interest to anyone else. The httr library (and 300 others) are in a shared directory, referenced by everyone in the biostatistics group via adding this location to the .libPaths in their default .Rprofile. (Actually, their .Rprofile starts by running material from a central one, the libPaths is there). When I run R (3.2.0) all is fine, but R CMD build fails with the text below * creating vignettes ... ERROR Error: processing vignette 'dart.Rnw' failed with diagnostics: chunk 2 (label = auth1) Error : package ‘httr’ required by ‘dart’ could not be found Execution halted If I add the requiste directory to my R_LIBS_USER environment variable then all is fine. However, that's a nuisance since the location changes over time (e.g. R releases). The system admins have a whole process that keeps .bashrc, .Rprofle and etc dot references up to date. Plugging into this is why we use .Rprofile. They are quite willing to make select changes in the central file, but with >1000 users any suggested changes in the overall process do not get a warm welcome. Any ideas? There is no mention in the Writing R Extentions manual that it ignores the Rprofile file. If "suck it up and use R_LIBS_USER" is the answer, well, there are only a few who build packages. PS, I can't use RHOME:/etc/Rprofile.site since the biostat group is not the only set of R users. Some other groups, for instance, cannot even see our central area. Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build question
On Solaris when my package is built, I get the following result: creating vignettes ...Segmentation Fault - core dumped OK My question isn't why I get a segfault, but why does build return an OK after such an inauspicious event? Is build only supposed to error out if something more central to the package is off? R CMD check does issue a warning that the vignette is missing, so maybe that is the intended result. Best, Jim -- James W. MacDonald, M.S. Biostatistician Affymetrix and cDNA Microarray Core University of Michigan Cancer Center 1500 E. Medical Center Drive 7410 CCGC Ann Arbor MI 48109 734-647-5623 ** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r cmd build
On 15/09/2007 10:27 PM, Gabor Grothendieck wrote: > On Windows Vista hhc.exe is not available. One can do this on an > install: > > rcmd install --docs=normal myPackage > > to avoid the message about hhc.exe; however, > "rcmd build" does not appear to support --docs=normal so one cannot > do a build without getting a message about hhc.exe (although the build > still proceeds). Are you talking about "build --binary"? I recommend using "install --build" instead. AFAIK a non-binary build doesn't make any use of hhc. Another way to do an install or build without getting that message is to indicate in src/gnuwin32/MkRules that you don't want to build CHM help. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r cmd build
The Writing Extensions manual says to do an R CMD build for releases to CRAN. That's what I have been doing and that does produce a .tar.gz file even though I get a message about hhc.exe. Is that what I should continue to do and ignore the message or should I be using one of the alternatives you mention to create a .tar.gz release file on Vista? On 9/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 15/09/2007 10:27 PM, Gabor Grothendieck wrote: > > On Windows Vista hhc.exe is not available. One can do this on an > > install: > > > > rcmd install --docs=normal myPackage > > > > to avoid the message about hhc.exe; however, > > "rcmd build" does not appear to support --docs=normal so one cannot > > do a build without getting a message about hhc.exe (although the build > > still proceeds). > > Are you talking about "build --binary"? I recommend using "install > --build" instead. AFAIK a non-binary build doesn't make any use of hhc. > > Another way to do an install or build without getting that message is to > indicate in src/gnuwin32/MkRules that you don't want to build CHM help. > > Duncan Murdoch > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r cmd build
Something should be added to the Writing Extensions manual since one gets this message during the R CMD build on Vista: hhc: not found CHM compile failed: HTML Help Workshop not installed? and one is not really sure if the result is ok or not -- it does say it FAILED. Even better would be to get rid of the message or improve the message. Again, this all refers to doing a build on Vista. On 9/16/07, Uwe Ligges <[EMAIL PROTECTED]> wrote: > > > Gabor Grothendieck wrote: > > The Writing Extensions manual says to do an R CMD build for releases > > to CRAN. That's what I have been doing and that does produce a .tar.gz > > file even though I get a message about hhc.exe. Is that what I should > > continue > > to do and ignore the message or should I be using one of the alternatives > > you mention to create a .tar.gz release file on Vista? > > Well, to produce a tar.gz, it is not required to have hhc.exe. It might > happen that vignettes are created and therefore the package is installed > for this purpose (and hhc is used to produce some help pages - > temporarily). When hhc is not found at that place, just ignore it, the > resulting .tar.gz should really be fine. > > Uwe Ligges > > > On 9/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >> On 15/09/2007 10:27 PM, Gabor Grothendieck wrote: > >>> On Windows Vista hhc.exe is not available. One can do this on an > >>> install: > >>> > >>> rcmd install --docs=normal myPackage > >>> > >>> to avoid the message about hhc.exe; however, > >>> "rcmd build" does not appear to support --docs=normal so one cannot > >>> do a build without getting a message about hhc.exe (although the build > >>> still proceeds). > >> Are you talking about "build --binary"? I recommend using "install > >> --build" instead. AFAIK a non-binary build doesn't make any use of hhc. > >> > >> Another way to do an install or build without getting that message is to > >> indicate in src/gnuwin32/MkRules that you don't want to build CHM help. > >> > >> Duncan Murdoch > >> > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r cmd build
Gabor Grothendieck wrote: > The Writing Extensions manual says to do an R CMD build for releases > to CRAN. That's what I have been doing and that does produce a .tar.gz > file even though I get a message about hhc.exe. Is that what I should > continue > to do and ignore the message or should I be using one of the alternatives > you mention to create a .tar.gz release file on Vista? Well, to produce a tar.gz, it is not required to have hhc.exe. It might happen that vignettes are created and therefore the package is installed for this purpose (and hhc is used to produce some help pages - temporarily). When hhc is not found at that place, just ignore it, the resulting .tar.gz should really be fine. Uwe Ligges > On 9/16/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> On 15/09/2007 10:27 PM, Gabor Grothendieck wrote: >>> On Windows Vista hhc.exe is not available. One can do this on an >>> install: >>> >>> rcmd install --docs=normal myPackage >>> >>> to avoid the message about hhc.exe; however, >>> "rcmd build" does not appear to support --docs=normal so one cannot >>> do a build without getting a message about hhc.exe (although the build >>> still proceeds). >> Are you talking about "build --binary"? I recommend using "install >> --build" instead. AFAIK a non-binary build doesn't make any use of hhc. >> >> Another way to do an install or build without getting that message is to >> indicate in src/gnuwin32/MkRules that you don't want to build CHM help. >> >> Duncan Murdoch >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build --resave-data
Hi,
More about the new --resave-data option
As mentioned previously here
https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
'R CMD build' and 'R CMD INSTALL' handle this new option
inconsistently. The former does --resave-data="gzip" by default.
The latter doesn't seem to support the --resave-data= syntax:
the --resave-data flag must either be present or not. And by
default 'R CMD INSTALL' won't resave the data.
Also, because now 'R CMD build' is resaving the data, shouldn't it
reinstall the package in order to be able to do this correctly?
Here is why. There is this new warning in 'R CMD check' that complains
about files not of a type allowed in a 'data' directory:
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
The Icens package also has .R files under data/ with things like:
bet <- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
i.e. the R code needs to access some of the text files located
in the data/ folder. So in order to get rid of this warning I
tried to move those text files to inst/extdata/ and I modified
the code in the .R file so it does:
CMVdata_filepath <- system.file("extdata", "CMVdata", package="Icens")
bet <- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE)
But now 'R CMD build' fails to resave the data because the package
was not installed first and the CMVdata file could not be found.
Unfortunately, for a lot of people that means that the safe way to
build a source tarball now is with
R CMD build --keep-empty-dirs --no-resave-data
I hope the list of options/flags that we need to use to "fix" 'R CMD
build' (and make it consistent with R CMD INSTALL) is not going to
grow too much ;-)
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build failure
What field is httr in the DESCRIPTION? Hadley On Thu, Jul 9, 2015 at 10:26 AM, Therneau, Terry M., Ph.D. wrote: > I have a local library 'dart' that imports "httr". It has routines that > access central patient data such as birth date, so it is heavily used > locally but of no interest to anyone else. > > The httr library (and 300 others) are in a shared directory, referenced by > everyone in the biostatistics group via adding this location to the > .libPaths in their default .Rprofile. (Actually, their .Rprofile starts by > running material from a central one, the libPaths is there). > > When I run R (3.2.0) all is fine, but R CMD build fails with the text below > > * creating vignettes ... ERROR > Error: processing vignette 'dart.Rnw' failed with diagnostics: > chunk 2 (label = auth1) > Error : package ‘httr’ required by ‘dart’ could not be found > Execution halted > > > If I add the requiste directory to my R_LIBS_USER environment variable then > all is fine. However, that's a nuisance since the location changes over > time (e.g. R releases). The system admins have a whole process that keeps > .bashrc, .Rprofle and etc dot references up to date. Plugging into this is > why we use .Rprofile. They are quite willing to make select changes in the > central file, but with >1000 users any suggested changes in the overall > process do not get a warm welcome. > > Any ideas? There is no mention in the Writing R Extentions manual that it > ignores the Rprofile file. If "suck it up and use R_LIBS_USER" is the > answer, well, there are only a few who build packages. > > PS, I can't use RHOME:/etc/Rprofile.site since the biostat group is not the > only set of R users. Some other groups, for instance, cannot even see our > central area. > > Terry T. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build failure
"Depends: httr (>= 0.6), XML" in the DESCRIPTION file "import(httr, XML)" in NAMESPACE Per your question I just tried changing "Depends" to "Imports", it didn't make a change. Terry T. On 07/09/2015 12:33 PM, Hadley Wickham wrote: What field is httr in the DESCRIPTION? Hadley On Thu, Jul 9, 2015 at 10:26 AM, Therneau, Terry M., Ph.D. wrote: I have a local library 'dart' that imports "httr". It has routines that access central patient data such as birth date, so it is heavily used locally but of no interest to anyone else. The httr library (and 300 others) are in a shared directory, referenced by everyone in the biostatistics group via adding this location to the .libPaths in their default .Rprofile. (Actually, their .Rprofile starts by running material from a central one, the libPaths is there). When I run R (3.2.0) all is fine, but R CMD build fails with the text below * creating vignettes ... ERROR Error: processing vignette 'dart.Rnw' failed with diagnostics: chunk 2 (label = auth1) Error : package ‘httr’ required by ‘dart’ could not be found Execution halted If I add the requiste directory to my R_LIBS_USER environment variable then all is fine. However, that's a nuisance since the location changes over time (e.g. R releases). The system admins have a whole process that keeps .bashrc, .Rprofle and etc dot references up to date. Plugging into this is why we use .Rprofile. They are quite willing to make select changes in the central file, but with >1000 users any suggested changes in the overall process do not get a warm welcome. Any ideas? There is no mention in the Writing R Extentions manual that it ignores the Rprofile file. If "suck it up and use R_LIBS_USER" is the answer, well, there are only a few who build packages. PS, I can't use RHOME:/etc/Rprofile.site since the biostat group is not the only set of R users. Some other groups, for instance, cannot even see our central area. Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build failure
On Thu, 9 Jul 2015, Therneau, Terry M., Ph.D. wrote: I have a local library 'dart' that imports "httr". [snip `R CMD build' can't find dart] Any ideas? There is no mention in the Writing R Extentions manual that it ignores the Rprofile file. Terry, From WRE: 1.3 Checking and building packages ... Note: R CMD check and R CMD build run R processes with --vanilla in which none of the user’s startup files are read. If you need R_LIBS set (to find packages in a non-standard library) you can set it in the environment: also you can use the check and build environment files (as specified by the environment variables R_CHECK_ENVIRON and R_BUILD_ENVIRON; if unset, files33 ~/.R/check.Renviron and ~/.R/build.Renviron are used) to set environment variables when using these utilities. And from ?Startup The command-line option --vanilla implies --no-site-file, --no-init-file, --no-environ and (except for R CMD) --no-restore HTH, Chuck __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build failure
On Thu, Jul 9, 2015 at 12:26 PM, Therneau, Terry M., Ph.D. wrote: > I have a local library 'dart' that imports "httr". It has routines that > access central patient data such as birth date, so it is heavily used > locally but of no interest to anyone else. > > The httr library (and 300 others) are in a shared directory, referenced by > everyone in the biostatistics group via adding this location to the > .libPaths in their default .Rprofile. (Actually, their .Rprofile starts by > running material from a central one, the libPaths is there). > > When I run R (3.2.0) all is fine, but R CMD build fails with the text below > > * creating vignettes ... ERROR > Error: processing vignette 'dart.Rnw' failed with diagnostics: > chunk 2 (label = auth1) > Error : package ‘httr’ required by ‘dart’ could not be found > Execution halted > > > If I add the requiste directory to my R_LIBS_USER environment variable then > all is fine. However, that's a nuisance since the location changes over > time (e.g. R releases). The system admins have a whole process that keeps > .bashrc, .Rprofle and etc dot references up to date. Plugging into this is > why we use .Rprofile. They are quite willing to make select changes in the > central file, but with >1000 users any suggested changes in the overall > process do not get a warm welcome. > > Any ideas? There is no mention in the Writing R Extentions manual that it > ignores the Rprofile file. If "suck it up and use R_LIBS_USER" is the > answer, well, there are only a few who build packages. > It is mentioned in ?Startup: "'R CMD check' and 'R CMD build' do not always read the standard startup files, but they do always read specific 'Renviron' files. The location of these can be controlled by the environment variables 'R_CHECK_ENVIRON' and 'R_BUILD_ENVIRON'. If these are set their value is used as the path for the 'Renviron' file; otherwise, files '~/.R/check.Renviron' or '~/.R/build.Renviron' or sub-architecture-specific versions are employed." Maybe one of those options could work for you? > PS, I can't use RHOME:/etc/Rprofile.site since the biostat group is not the > only set of R users. Some other groups, for instance, cannot even see our > central area. > > Terry T. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build question
> "JimMcD" == James W MacDonald <[EMAIL PROTECTED]> > on Fri, 22 Sep 2006 11:28:48 -0400 writes: JimMcD> On Solaris when my package is built, I get the following result: I don't think this is bound to Solaris at all. JimMcD> creating vignettes ...Segmentation Fault - core dumped JimMcD> OK JimMcD> My question isn't why I get a segfault, but why does JimMcD> build return an OK after such an inauspicious event? JimMcD> Is build only supposed to error out if something JimMcD> more central to the package is off? JimMcD> R CMD check does issue a warning that the vignette JimMcD> is missing, so maybe that is the intended result. I have been puzzled recently by similar behavior, and I think that current behavior is not satisfactory. IIRC, I even got -- creating vignettes ... OK -- But from the 3 vignettes, the 2nd one gave an error (in R code), and consequently only the pdf of the 1st vignette had been built --- all completely silently until you "R CMD check" the built tar file get the warning about missing pdf. I only did not "complain" because people could have pointed out to me that I could fix the problem myself .. :-\ Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build on Vista
Hello, I have R 2.7.2 and RTools 2.8 on a vista pro computer. On my computer R CMD build changes the file names : all capital letters are transformed into lowercase letters (for instance the DESCRIPTION file is changed in 'description'). What can I do to correct this problem? Tank you, Ollivier TARAMASCO [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build wiped my computer
Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove "junk files" it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, and even more importantly if I can I restore what was lost. Panickingly, Jarrod [jar...@localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file 'MCMCglmm_2.05/DESCRIPTION' ... OK * preparing 'MCMCglmm_2.05': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * Installing *source* package ?MCMCglmm? ... ** libs g++ -m64 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c MCMCglmm.cc -o MCMCglmm.o MCMCglmm.cc: In function ?void MCMCglmm(double*, double*, double*, int*, int*, int*, int*, int*, int*, double*, int*, int*, double*, int*, int*, double*, double*, int*, int*, int*, int*, int*, int*, int*, int*, int*, int*, double*, double*, double*, int*, int*, int*, int*, double*, double*, double*, int*, double*, bool*, double*, double*, int*, int*, int*, int*, int*, double*, int*, int*, int*, double*, double*, double*, int*, int*, double*, int*, int*, int*, int*, double*, double*, double*, double*)?: MCMCglmm.cc:228: warning: ?pvLS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?pvLL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Lrv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pmuL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?LambdaX? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?A? may be used uninitialized in this function MCMCglmm.cc:86: warning: ?dimG? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?AlphainvS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?AlphainvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphazstar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphapred? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?muAlpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Alphainv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tXalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Xalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?linky_orig? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?tYKrinvYS? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?LambdaS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?tYKrinvYL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?LambdaLU? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinvY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?ILY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Y? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?I? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?alphaS? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaMME? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaM? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?XtmKRinv? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?alphaL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?L? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?dev? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?astar_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Worig? may be used uninitialized in this function gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c cs_add.c -o cs_add.o gcc -m64 -std=gnu99 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexcep
Re: [Rd] R CMD build --resave-data
On 11.04.2011 02:47, Hervé Pagès wrote:
Hi,
More about the new --resave-data option
As mentioned previously here
https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
'R CMD build' and 'R CMD INSTALL' handle this new option
inconsistently. The former does --resave-data="gzip" by default.
The latter doesn't seem to support the --resave-data= syntax:
the --resave-data flag must either be present or not. And by
default 'R CMD INSTALL' won't resave the data.
Also, because now 'R CMD build' is resaving the data, shouldn't it
reinstall the package in order to be able to do this correctly?
Here is why. There is this new warning in 'R CMD check' that complains
about files not of a type allowed in a 'data' directory:
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
The Icens package also has .R files under data/ with things like:
bet <- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
i.e. the R code needs to access some of the text files located
in the data/ folder. So in order to get rid of this warning I
tried to move those text files to inst/extdata/ and I modified
the code in the .R file so it does:
CMVdata_filepath <- system.file("extdata", "CMVdata", package="Icens")
bet <- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE)
But now 'R CMD build' fails to resave the data because the package
was not installed first and the CMVdata file could not be found.
Unfortunately, for a lot of people that means that the safe way to
build a source tarball now is with
R CMD build --keep-empty-dirs --no-resave-data
Hervé,
actually is makes some sense to have these defaults from a CRAN
maintainer's point of view:
--keep-empty-dirs:
we found many packages containing empty dirs unnecessarily and the idea
is to exclude them at the build state rather than at the later
installation stage. Note that the package maintainer is supposed to run
build (and knows if the empty dirs are to be included, the user who runs
INSTALL does not).
--no-resave-data:
We found many packages with unsufficiently compressed data. This should
be fixed when building the package, not later when installing it, since
the reduces size is useful in the source tarball already.
So it does make some sense to have different defaults in build as
opposed to INSTALL from my point of view (although I could live with
different, tough).
If you need further arguments for the discussion: I also tend to use
--no-vignettes nowadays if my code does not change considerably. ;-)
Best wishes,
Uwe
I hope the list of options/flags that we need to use to "fix" 'R CMD
build' (and make it consistent with R CMD INSTALL) is not going to
grow too much ;-)
Thanks,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build --resave-data
Hi Uwe,
On 11-04-11 08:13 AM, Uwe Ligges wrote:
On 11.04.2011 02:47, Hervé Pagès wrote:
Hi,
More about the new --resave-data option
As mentioned previously here
https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
'R CMD build' and 'R CMD INSTALL' handle this new option
inconsistently. The former does --resave-data="gzip" by default.
The latter doesn't seem to support the --resave-data= syntax:
the --resave-data flag must either be present or not. And by
default 'R CMD INSTALL' won't resave the data.
Also, because now 'R CMD build' is resaving the data, shouldn't it
reinstall the package in order to be able to do this correctly?
Here is why. There is this new warning in 'R CMD check' that complains
about files not of a type allowed in a 'data' directory:
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
The Icens package also has .R files under data/ with things like:
bet <- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
i.e. the R code needs to access some of the text files located
in the data/ folder. So in order to get rid of this warning I
tried to move those text files to inst/extdata/ and I modified
the code in the .R file so it does:
CMVdata_filepath <- system.file("extdata", "CMVdata", package="Icens")
bet <- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE)
But now 'R CMD build' fails to resave the data because the package
was not installed first and the CMVdata file could not be found.
Unfortunately, for a lot of people that means that the safe way to
build a source tarball now is with
R CMD build --keep-empty-dirs --no-resave-data
Hervé,
actually is makes some sense to have these defaults from a CRAN
maintainer's point of view:
--keep-empty-dirs:
we found many packages containing empty dirs unnecessarily and the idea
is to exclude them at the build state rather than at the later
installation stage. Note that the package maintainer is supposed to run
build (and knows if the empty dirs are to be included, the user who runs
INSTALL does not).
--no-resave-data:
We found many packages with unsufficiently compressed data. This should
be fixed when building the package, not later when installing it, since
the reduces size is useful in the source tarball already.
So it does make some sense to have different defaults in build as
opposed to INSTALL from my point of view (although I could live with
different, tough).
If you deliberately ignore the fact that 'R CMD INSTALL' is also used
by developers to install from the *package source tree* (by opposition
to end users who use it to install from a *source tarball*, even though
they don't use it directly), then you have a point. So maybe I should
have been more explicit about the problem that it can be for the
*developer* to have 'R CMD build' and 'R CMD INSTALL' behave
differently by default.
Of course I'm not suggesting that 'R CMD INSTALL' should behave
differently (by default) depending on whether it's used on a source
tarball (mode 1) or a package source tree (mode 2).
I'm suggesting that, by default, the 3 commands (R CMD build +
R CMD INSTALL in mode 1 and 2) behave consistently.
With the latest changes, and by default, 'R CMD INSTALL' is still doing
the right thing, but not 'R CMD build' anymore.
I perfectly understand the intention behind those new flags, which is
to try to "optimize" the resulting source tarball but what would you
think if 'gcc' had some optimization flags that can generate broken
executables (under some circumstances) and if these flags were enabled
by default?
Note that I would have no problem with 'R CMD build' trying to resave
the data by default if the current implementation of that feature
was working properly, but unfortunately it's broken (see my previous
email for the details).
Thanks,
H.
If you need further arguments for the discussion: I also tend to use
--no-vignettes nowadays if my code does not change considerably. ;-)
Best wishes,
Uwe
I hope the list of options/flags that we need to use to "fix" 'R CMD
build' (and make it consistent with R CMD INSTALL) is not going to
grow too much ;-)
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build --resave-data
On Apr 12, 2011, at 8:53 PM, Hervé Pagès wrote:
> Hi Uwe,
>
> On 11-04-11 08:13 AM, Uwe Ligges wrote:
>>
>>
>> On 11.04.2011 02:47, Hervé Pagès wrote:
>>> Hi,
>>>
>>> More about the new --resave-data option
>>>
>>> As mentioned previously here
>>>
>>> https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
>>>
>>> 'R CMD build' and 'R CMD INSTALL' handle this new option
>>> inconsistently. The former does --resave-data="gzip" by default.
>>> The latter doesn't seem to support the --resave-data= syntax:
>>> the --resave-data flag must either be present or not. And by
>>> default 'R CMD INSTALL' won't resave the data.
>>>
>>> Also, because now 'R CMD build' is resaving the data, shouldn't it
>>> reinstall the package in order to be able to do this correctly?
>>>
>>> Here is why. There is this new warning in 'R CMD check' that complains
>>> about files not of a type allowed in a 'data' directory:
>>>
>>>
>>> http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
>>>
>>>
>>>
>>> The Icens package also has .R files under data/ with things like:
>>>
>>> bet <- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
>>>
>>> i.e. the R code needs to access some of the text files located
>>> in the data/ folder. So in order to get rid of this warning I
>>> tried to move those text files to inst/extdata/ and I modified
>>> the code in the .R file so it does:
>>>
>>> CMVdata_filepath <- system.file("extdata", "CMVdata", package="Icens")
>>> bet <- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE)
>>>
>>> But now 'R CMD build' fails to resave the data because the package
>>> was not installed first and the CMVdata file could not be found.
>>>
>>> Unfortunately, for a lot of people that means that the safe way to
>>> build a source tarball now is with
>>>
>>> R CMD build --keep-empty-dirs --no-resave-data
>>
>>
>> Hervé,
>>
>> actually is makes some sense to have these defaults from a CRAN
>> maintainer's point of view:
>>
>> --keep-empty-dirs:
>> we found many packages containing empty dirs unnecessarily and the idea
>> is to exclude them at the build state rather than at the later
>> installation stage. Note that the package maintainer is supposed to run
>> build (and knows if the empty dirs are to be included, the user who runs
>> INSTALL does not).
>>
>> --no-resave-data:
>> We found many packages with unsufficiently compressed data. This should
>> be fixed when building the package, not later when installing it, since
>> the reduces size is useful in the source tarball already.
>>
>> So it does make some sense to have different defaults in build as
>> opposed to INSTALL from my point of view (although I could live with
>> different, tough).
>
> If you deliberately ignore the fact that 'R CMD INSTALL' is also used
> by developers to install from the *package source tree* (by opposition
> to end users who use it to install from a *source tarball*,
.. for a good reason, IMHO no serious developer would do that for obvious
reasons - you'd be working on a dirty copy creating many unnecessary problems
and polluting your sources. The first time you'll spend an hour chasing a
non-existent problem due to stale binary objects in your tree you'll learn that
lesson ;). The fraction of a second spent in R CMD build is well worth the
hours saved. IMHO the only valid reason to run INSTALL on a (freshly unpacked
tar ball) directory is to capture config.log.
Cheers,
Simon
> even though
> they don't use it directly), then you have a point. So maybe I should
> have been more explicit about the problem that it can be for the
> *developer* to have 'R CMD build' and 'R CMD INSTALL' behave
> differently by default.
>
> Of course I'm not suggesting that 'R CMD INSTALL' should behave
> differently (by default) depending on whether it's used on a source
> tarball (mode 1) or a package source tree (mode 2).
>
> I'm suggesting that, by default, the 3 commands (R CMD build +
> R CMD INSTALL in mode 1 and 2) behave consistently.
>
> With the latest changes, and by default, 'R CMD INSTALL' is still doing
> the right thing, but not 'R CMD build' anymore.
>
> I perfectly understand the intention behind those new flags, which is
> to try to "optimize" the resulting source tarball but what would you
> think if 'gcc' had some optimization flags that can generate broken
> executables (under some circumstances) and if these flags were enabled
> by default?
>
> Note that I would have no problem with 'R CMD build' trying to resave
> the data by default if the current implementation of that feature
> was working properly, but unfortunately it's broken (see my previous
> email for the details).
>
> Thanks,
> H.
>
>>
>> If you need further arguments for the discussion: I also tend to use
>> --no-vignettes nowadays if my code does not change considerably. ;-)
>>
>> Best wishes,
>> Uwe
>>
>>
>>
>>> I hope the list of options/flags that we need to use to "fix" 'R CMD
>>> build'
Re: [Rd] R CMD build --resave-data
>> If you deliberately ignore the fact that 'R CMD INSTALL' is also used >> by developers to install from the *package source tree* (by opposition >> to end users who use it to install from a *source tarball*, > > .. for a good reason, IMHO no serious developer would do that for obvious > reasons - you'd be working on a dirty copy creating many unnecessary problems > and polluting your sources. The first time you'll spend an hour chasing a > non-existent problem due to stale binary objects in your tree you'll learn > that lesson ;). The fraction of a second spent in R CMD build is well worth > the hours saved. IMHO the only valid reason to run INSTALL on a (freshly > unpacked tar ball) directory is to capture config.log. This is news to me! I know that you're supposed to run R CMD check on the built package, but you're supposed to run install on it too? (And if it's so important, why doesn't R do it for you automatically?) Do you have any convenient shortcuts to overcome the fact that the binary package contains the package name? i.e. how can I build and install/check in a single line without having to specify the full file name? How can I go from: R CMD build plyr && R CMD install plyr_1.5.tar.gz to R CMD build-and-install plyr ? Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build --resave-data
On Apr 12, 2011, at 10:26 PM, Hadley Wickham wrote: >>> If you deliberately ignore the fact that 'R CMD INSTALL' is also used >>> by developers to install from the *package source tree* (by opposition >>> to end users who use it to install from a *source tarball*, >> >> .. for a good reason, IMHO no serious developer would do that for obvious >> reasons - you'd be working on a dirty copy creating many unnecessary >> problems and polluting your sources. The first time you'll spend an hour >> chasing a non-existent problem due to stale binary objects in your tree >> you'll learn that lesson ;). The fraction of a second spent in R CMD build >> is well worth the hours saved. IMHO the only valid reason to run INSTALL on >> a (freshly unpacked tar ball) directory is to capture config.log. > > This is news to me! I know that you're supposed to run R CMD check on > the built package, but you're supposed to run install on it too? (And > if it's so important, why doesn't R do it for you automatically?) > I'm not saying "supposed to" I'm saying wise to. And the "IMHO"s above were what I really meant. By all means, you're free to do anything as long as you don't ask on the mailing list that something doesn't work because you ran it on a stale directory ;). > Do you have any convenient shortcuts to overcome the fact that the > binary package contains the package name? i.e. how can I build and > install/check in a single line without having to specify the full file > name? > > How can I go from: > > R CMD build plyr && R CMD install plyr_1.5.tar.gz > Some will argue that's an invalid command to start with ;). But other than that I see nothing wrong with it ... it's what I do to be honest ... (except where I don't, but that has to do with my custom build script legacy which has a defined way to get versions on the shell, long story...). > to > > R CMD build-and-install plyr ? > R CMD build plyr && R CMD INSTALL plyr_* ... if you don't keep too many version in the same directory ;) - but it's not something I would use. For the paranoid R CMD build plyr && R CMD INSTALL plyr_`sed -n 's/Version: *//p' plyr/DESCRIPTION`.tar.gz But, seriously, that is the least problem I see - you'd have to advance your version numbers very quickly to get the version command out of your shell history... Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build --resave-data
On 11-04-12 07:06 PM, Simon Urbanek wrote:
On Apr 12, 2011, at 8:53 PM, Hervé Pagès wrote:
Hi Uwe,
On 11-04-11 08:13 AM, Uwe Ligges wrote:
On 11.04.2011 02:47, Hervé Pagès wrote:
Hi,
More about the new --resave-data option
As mentioned previously here
https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
'R CMD build' and 'R CMD INSTALL' handle this new option
inconsistently. The former does --resave-data="gzip" by default.
The latter doesn't seem to support the --resave-data= syntax:
the --resave-data flag must either be present or not. And by
default 'R CMD INSTALL' won't resave the data.
Also, because now 'R CMD build' is resaving the data, shouldn't it
reinstall the package in order to be able to do this correctly?
Here is why. There is this new warning in 'R CMD check' that complains
about files not of a type allowed in a 'data' directory:
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
The Icens package also has .R files under data/ with things like:
bet<- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
i.e. the R code needs to access some of the text files located
in the data/ folder. So in order to get rid of this warning I
tried to move those text files to inst/extdata/ and I modified
the code in the .R file so it does:
CMVdata_filepath<- system.file("extdata", "CMVdata", package="Icens")
bet<- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE)
But now 'R CMD build' fails to resave the data because the package
was not installed first and the CMVdata file could not be found.
Unfortunately, for a lot of people that means that the safe way to
build a source tarball now is with
R CMD build --keep-empty-dirs --no-resave-data
Hervé,
actually is makes some sense to have these defaults from a CRAN
maintainer's point of view:
--keep-empty-dirs:
we found many packages containing empty dirs unnecessarily and the idea
is to exclude them at the build state rather than at the later
installation stage. Note that the package maintainer is supposed to run
build (and knows if the empty dirs are to be included, the user who runs
INSTALL does not).
--no-resave-data:
We found many packages with unsufficiently compressed data. This should
be fixed when building the package, not later when installing it, since
the reduces size is useful in the source tarball already.
So it does make some sense to have different defaults in build as
opposed to INSTALL from my point of view (although I could live with
different, tough).
If you deliberately ignore the fact that 'R CMD INSTALL' is also used
by developers to install from the *package source tree* (by opposition
to end users who use it to install from a *source tarball*,
.. for a good reason, IMHO no serious developer would do that for obvious
reasons -
This sounds like saying that no serious developer working on a big
project involving a lot of files to compile should use 'make'.
I mean, serious developers like you *always* do 'make clean' before
they do 'make' on the R tree when they need to test a change, even
a small one? And this only takes a "fraction of second" for them?
Hey, I'd love to be able to do that too! ;-)
H.
you'd be working on a dirty copy creating many unnecessary problems and
polluting your sources. The first time you'll spend an hour chasing a
non-existent problem due to stale binary objects in your tree you'll learn that
lesson ;). The fraction of a second spent in R CMD build is well worth the
hours saved. IMHO the only valid reason to run INSTALL on a (freshly unpacked
tar ball) directory is to capture config.log.
Cheers,
Simon
even though
they don't use it directly), then you have a point. So maybe I should
have been more explicit about the problem that it can be for the
*developer* to have 'R CMD build' and 'R CMD INSTALL' behave
differently by default.
Of course I'm not suggesting that 'R CMD INSTALL' should behave
differently (by default) depending on whether it's used on a source
tarball (mode 1) or a package source tree (mode 2).
I'm suggesting that, by default, the 3 commands (R CMD build +
R CMD INSTALL in mode 1 and 2) behave consistently.
With the latest changes, and by default, 'R CMD INSTALL' is still doing
the right thing, but not 'R CMD build' anymore.
I perfectly understand the intention behind those new flags, which is
to try to "optimize" the resulting source tarball but what would you
think if 'gcc' had some optimization flags that can generate broken
executables (under some circumstances) and if these flags were enabled
by default?
Note that I would have no problem with 'R CMD build' trying to resave
the data by default if the current implementation of that feature
was working properly, but unfortunately it's broken (see my previous
email for the details).
Thanks,
H.
If you need further arguments for the discussion: I also tend to use
--no-vignettes nowadays if my code does not change considerably. ;-)
Best wishes,
Uwe
I
Re: [Rd] R CMD build --resave-data
> Hervé Pagès
> on Tue, 12 Apr 2011 22:21:58 -0700 writes:
> On 11-04-12 07:06 PM, Simon Urbanek wrote:
>>
>> On Apr 12, 2011, at 8:53 PM, Hervé Pagès wrote:
>>
>>> Hi Uwe,
>>>
>>> On 11-04-11 08:13 AM, Uwe Ligges wrote:
On 11.04.2011 02:47, Hervé Pagès wrote:
> Hi,
>
> More about the new --resave-data option
>
> As mentioned previously here
>
> https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
>
> 'R CMD build' and 'R CMD INSTALL' handle this new option
> inconsistently. The former does --resave-data="gzip" by
> default. The latter doesn't seem to support the
> --resave-data= syntax: the --resave-data flag must either be
> present or not. And by default 'R CMD INSTALL' won't resave
> the data.
>
> Also, because now 'R CMD build' is resaving the data,
> shouldn't it reinstall the package in order to be able to do
> this correctly?
>
> Here is why. There is this new warning in 'R CMD check' that
> complains about files not of a type allowed in a 'data'
> directory:
>
>
>
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
>
>
>
> The Icens package also has .R files under data/ with things
> like:
>
> bet<- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
>
> i.e. the R code needs to access some of the text files
> located in the data/ folder. So in order to get rid of this
> warning I tried to move those text files to inst/extdata/
> and I modified the code in the .R file so it does:
>
> CMVdata_filepath<- system.file("extdata", "CMVdata",
> package="Icens") bet<- matrix(scan(CMVdata_filepath,
> quiet=TRUE),nc=5,byr=TRUE)
>
> But now 'R CMD build' fails to resave the data because the
> package was not installed first and the CMVdata file could
> not be found.
>
> Unfortunately, for a lot of people that means that the safe
> way to build a source tarball now is with
>
> R CMD build --keep-empty-dirs --no-resave-data
Hervé,
actually is makes some sense to have these defaults from a
CRAN maintainer's point of view:
--keep-empty-dirs: we found many packages containing empty
dirs unnecessarily and the idea is to exclude them at the
build state rather than at the later installation stage. Note
that the package maintainer is supposed to run build (and
knows if the empty dirs are to be included, the user who runs
INSTALL does not).
--no-resave-data: We found many packages with unsufficiently
compressed data. This should be fixed when building the
package, not later when installing it, since the reduces size
is useful in the source tarball already.
So it does make some sense to have different defaults in
build as opposed to INSTALL from my point of view (although I
could live with different, tough).
>>>
>>> If you deliberately ignore the fact that 'R CMD INSTALL' is
>>> also used by developers to install from the *package source
>>> tree* (by opposition to end users who use it to install from a
>>> *source tarball*,
>>
>> .. for a good reason, IMHO no serious developer would do that
>> for obvious reasons -
> This sounds like saying that no serious developer working on a
> big project involving a lot of files to compile should use
> 'make'. I mean, serious developers like you *always* do 'make
> clean' before they do 'make' on the R tree when they need to
> test a change, even a small one? And this only takes a "fraction
> of second" for them? Hey, I'd love to be able to do that too!
> ;-)
> H.
>> you'd be working on a dirty copy creating many unnecessary
>> problems and polluting your sources. The first time you'll
>> spend an hour chasing a non-existent problem due to stale
>> binary objects in your tree you'll learn that lesson ;). The
>> fraction of a second spent in R CMD build is well worth the
>> hours saved. IMHO the only valid reason to run INSTALL on a
>> (freshly unpacked tar ball) directory is to capture config.log.
>>
>> Cheers, Simon
>>
>>
>>
>>> even though they don't use it directly), then you have a
>>> point. So maybe I should have been more explicit about the
>>> problem that it can be for the *developer* to have 'R CMD
>>> build' and 'R CMD INSTALL' behave differently by default.
>>>
>>> Of course I'm not suggesting that 'R CMD
Re: [Rd] R CMD build --resave-data
On 13.04.2011 02:53, Hervé Pagès wrote:
Hi Uwe,
On 11-04-11 08:13 AM, Uwe Ligges wrote:
On 11.04.2011 02:47, Hervé Pagès wrote:
Hi,
More about the new --resave-data option
As mentioned previously here
https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
'R CMD build' and 'R CMD INSTALL' handle this new option
inconsistently. The former does --resave-data="gzip" by default.
The latter doesn't seem to support the --resave-data= syntax:
the --resave-data flag must either be present or not. And by
default 'R CMD INSTALL' won't resave the data.
Also, because now 'R CMD build' is resaving the data, shouldn't it
reinstall the package in order to be able to do this correctly?
Here is why. There is this new warning in 'R CMD check' that complains
about files not of a type allowed in a 'data' directory:
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
The Icens package also has .R files under data/ with things like:
bet <- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
i.e. the R code needs to access some of the text files located
in the data/ folder. So in order to get rid of this warning I
tried to move those text files to inst/extdata/ and I modified
the code in the .R file so it does:
CMVdata_filepath <- system.file("extdata", "CMVdata", package="Icens")
bet <- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE)
But now 'R CMD build' fails to resave the data because the package
was not installed first and the CMVdata file could not be found.
Unfortunately, for a lot of people that means that the safe way to
build a source tarball now is with
R CMD build --keep-empty-dirs --no-resave-data
Hervé,
actually is makes some sense to have these defaults from a CRAN
maintainer's point of view:
--keep-empty-dirs:
we found many packages containing empty dirs unnecessarily and the idea
is to exclude them at the build state rather than at the later
installation stage. Note that the package maintainer is supposed to run
build (and knows if the empty dirs are to be included, the user who runs
INSTALL does not).
--no-resave-data:
We found many packages with unsufficiently compressed data. This should
be fixed when building the package, not later when installing it, since
the reduces size is useful in the source tarball already.
So it does make some sense to have different defaults in build as
opposed to INSTALL from my point of view (although I could live with
different, tough).
If you deliberately ignore the fact that 'R CMD INSTALL' is also used
by developers to install from the *package source tree* (by opposition
to end users who use it to install from a *source tarball*, even though
they don't use it directly), then you have a point. So maybe I should
have been more explicit about the problem that it can be for the
*developer* to have 'R CMD build' and 'R CMD INSTALL' behave
differently by default.
Of course I'm not suggesting that 'R CMD INSTALL' should behave
differently (by default) depending on whether it's used on a source
tarball (mode 1) or a package source tree (mode 2).
I'm suggesting that, by default, the 3 commands (R CMD build +
R CMD INSTALL in mode 1 and 2) behave consistently.
With the latest changes, and by default, 'R CMD INSTALL' is still doing
the right thing, but not 'R CMD build' anymore.
I perfectly understand the intention behind those new flags, which is
to try to "optimize" the resulting source tarball but what would you
think if 'gcc' had some optimization flags that can generate broken
executables (under some circumstances) and if these flags were enabled
by default?
Note that I would have no problem with 'R CMD build' trying to resave
the data by default if the current implementation of that feature
was working properly, but unfortunately it's broken (see my previous
email for the details).
It is one thing to talk about sensible defaults and another thing to
talk about bugs. I just talked about sensible defaults. And I have not
had the time to look iunto details. I just arrived in Dortmund 15
minutes ago and I the first thing I have to do is repairing some
winbuilder stuff and get 2.13.0 ready on it. I may look into other
details later this week or at the beginning of next week.
Uwe
Thanks,
H.
If you need further arguments for the discussion: I also tend to use
--no-vignettes nowadays if my code does not change considerably. ;-)
Best wishes,
Uwe
I hope the list of options/flags that we need to use to "fix" 'R CMD
build' (and make it consistent with R CMD INSTALL) is not going to
grow too much ;-)
Thanks,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build --resave-data
Hi Uwe,
On 11-04-13 10:50 AM, Uwe Ligges wrote:
On 13.04.2011 02:53, Hervé Pagès wrote:
Hi Uwe,
On 11-04-11 08:13 AM, Uwe Ligges wrote:
On 11.04.2011 02:47, Hervé Pagès wrote:
Hi,
More about the new --resave-data option
As mentioned previously here
https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html
'R CMD build' and 'R CMD INSTALL' handle this new option
inconsistently. The former does --resave-data="gzip" by default.
The latter doesn't seem to support the --resave-data= syntax:
the --resave-data flag must either be present or not. And by
default 'R CMD INSTALL' won't resave the data.
Also, because now 'R CMD build' is resaving the data, shouldn't it
reinstall the package in order to be able to do this correctly?
Here is why. There is this new warning in 'R CMD check' that complains
about files not of a type allowed in a 'data' directory:
http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html
The Icens package also has .R files under data/ with things like:
bet <- matrix(scan("CMVdata", quiet=TRUE),nc=5,byr=TRUE)
i.e. the R code needs to access some of the text files located
in the data/ folder. So in order to get rid of this warning I
tried to move those text files to inst/extdata/ and I modified
the code in the .R file so it does:
CMVdata_filepath <- system.file("extdata", "CMVdata", package="Icens")
bet <- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE)
But now 'R CMD build' fails to resave the data because the package
was not installed first and the CMVdata file could not be found.
Unfortunately, for a lot of people that means that the safe way to
build a source tarball now is with
R CMD build --keep-empty-dirs --no-resave-data
Hervé,
actually is makes some sense to have these defaults from a CRAN
maintainer's point of view:
--keep-empty-dirs:
we found many packages containing empty dirs unnecessarily and the idea
is to exclude them at the build state rather than at the later
installation stage. Note that the package maintainer is supposed to run
build (and knows if the empty dirs are to be included, the user who runs
INSTALL does not).
--no-resave-data:
We found many packages with unsufficiently compressed data. This should
be fixed when building the package, not later when installing it, since
the reduces size is useful in the source tarball already.
So it does make some sense to have different defaults in build as
opposed to INSTALL from my point of view (although I could live with
different, tough).
If you deliberately ignore the fact that 'R CMD INSTALL' is also used
by developers to install from the *package source tree* (by opposition
to end users who use it to install from a *source tarball*, even though
they don't use it directly), then you have a point. So maybe I should
have been more explicit about the problem that it can be for the
*developer* to have 'R CMD build' and 'R CMD INSTALL' behave
differently by default.
Of course I'm not suggesting that 'R CMD INSTALL' should behave
differently (by default) depending on whether it's used on a source
tarball (mode 1) or a package source tree (mode 2).
I'm suggesting that, by default, the 3 commands (R CMD build +
R CMD INSTALL in mode 1 and 2) behave consistently.
With the latest changes, and by default, 'R CMD INSTALL' is still doing
the right thing, but not 'R CMD build' anymore.
I perfectly understand the intention behind those new flags, which is
to try to "optimize" the resulting source tarball but what would you
think if 'gcc' had some optimization flags that can generate broken
executables (under some circumstances) and if these flags were enabled
by default?
Note that I would have no problem with 'R CMD build' trying to resave
the data by default if the current implementation of that feature
was working properly, but unfortunately it's broken (see my previous
email for the details).
It is one thing to talk about sensible defaults and another thing to
talk about bugs. I just talked about sensible defaults. And I have not
had the time to look iunto details. I just arrived in Dortmund 15
minutes ago and I the first thing I have to do is repairing some
winbuilder stuff and get 2.13.0 ready on it. I may look into other
details later this week or at the beginning of next week.
No problem. I understand perfectly. Release times are very busy time
on the Bioconductor side too. Thanks for looking into this!
H.
Uwe
Thanks,
H.
If you need further arguments for the discussion: I also tend to use
--no-vignettes nowadays if my code does not change considerably. ;-)
Best wishes,
Uwe
I hope the list of options/flags that we need to use to "fix" 'R CMD
build' (and make it consistent with R CMD INSTALL) is not going to
grow too much ;-)
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mai
[Rd] 'R CMD build' and file permissions
Hi, When building a source package on Linux with 'R CMD build', the files in the resulting tarball don't have the original permissions. The problem is that the packages I want to build include an SQLite data base (an .sqlite file) and, before I run 'R CMD build', I've made this file read-only (chmod 444) because I want this DB to be read-only. Then if I install by running 'R CMD INSTALL' directly on the source directory, everything works as expected (the permissions of the installed .sqlite file are conserved). But if I run 'R CMD build' in order to produce the tarballs (I need to distribute those packages), then, when the user will install them, the SQLite DBs will not be read-only anymore. Is there a way to prevent 'R CMD build' from changing the permissions of the source files? Thanks in advance! Cheers, H __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build on Vista
On Sun, 19 Oct 2008, Ollivier TARAMASCO wrote: Hello, I have R 2.7.2 and RTools 2.8 on a vista pro computer. On my computer R CMD build changes the file names : all capital letters are transformed into lowercase letters (for instance the DESCRIPTION file is changed in 'description'). What can I do to correct this problem? Use a less unreliable OS? The copying is done in Perl, and so is out of our control. This may depend on the file system, and I've not seen this (nor have others reported it), except on Samba-mounted file systems, about which the FAQ says Your file system must allow case-honouring long file names (as is likely except perhaps for some network-mounted systems). So sorry, unless that is the explanation this is beyond our control. Tank you, Ollivier TARAMASCO [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build on Vista
Check what drives you have available on your system and what file system each uses. Click on Start button and type in System Information and then choose Components / Storage / Drives in the left side panel. That will report all your drives and their file system and other information. Try running the build on a drive with a different file system and see if that helps. If you are able to remove the drive that seems to be the problem you might want to do that to ensure that its not being used for temporary files during the build. On Sun, Oct 19, 2008 at 12:56 PM, Ollivier TARAMASCO <[EMAIL PROTECTED]> wrote: > Hello, > > > > I have R 2.7.2 and RTools 2.8 on a vista pro computer. On my computer R CMD > build changes the file names : all capital letters are transformed into > lowercase letters (for instance the DESCRIPTION file is changed in > 'description'). What can I do to correct this problem? > > > > Tank you, > > > > Ollivier TARAMASCO > > >[[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build wiped my computer
> Jarrod Hadfield > on Tue, 27 Jul 2010 21:37:09 +0100 writes: > Hi, I ran R (version 2.9.0) CMD build under root in > Fedora (9). When it tried to remove "junk files" it > removed EVERYTHING in my local account! (See below). > Can anyone tell me what happened, the culprit may lay here: >> * removing junk files >> unlink MCMCglmm_2.05/R/ residuals.MCMCglmm.R >> ~ where it seems that someone (you?) have added a newline in the filname, so instead of 'residuals.MCMCglmm.R~' you got 'residuals.MCMCglmm.R ~' and the unlink / rm command interpreted '~' as your home directory. But I can hardly believe it. This seems explanation seems a bit doubtful to me.. ... > and even more importantly if I can I restore what was lost. well, you just get it from the backup. You do daily backups, do you? Regards, Martin Maechler, ETH Zurich > Panickingly, > Jarrod > [jar...@localhost AManal]$ R CMD build MCMCglmm_2.05 > * checking for file 'MCMCglmm_2.05/DESCRIPTION' ... OK > * preparing 'MCMCglmm_2.05': > * checking DESCRIPTION meta-information ... OK > * cleaning src > * installing the package to re-build vignettes > * Installing *source* package ?MCMCglmm? ... > ** libs > g++ -m64 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe > -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -c MCMCglmm.cc -o > MCMCglmm.o > MCMCglmm.cc: In function ?void MCMCglmm(double*, double*, double*, > int*, int*, int*, int*, int*, int*, double*, int*, int*, double*, > int*, int*, double*, double*, int*, int*, int*, int*, int*, int*, > int*, int*, int*, int*, double*, double*, double*, int*, int*, int*, > int*, double*, double*, double*, int*, double*, bool*, double*, > double*, int*, int*, int*, int*, int*, double*, int*, int*, int*, > double*, double*, double*, int*, int*, double*, int*, int*, int*, > int*, double*, double*, double*, double*)?: > MCMCglmm.cc:228: warning: ?pvLS? may be used uninitialized in this function > MCMCglmm.cc:227: warning: ?pvLL? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?Lrv? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?pmuL? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?pvL? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?LambdaX? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?bv_tmp? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?bv? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?A? may be used uninitialized in this function > MCMCglmm.cc:86: warning: ?dimG? may be used uninitialized in this function > MCMCglmm.cc:228: warning: ?AlphainvS? may be used uninitialized in > this function > MCMCglmm.cc:227: warning: ?AlphainvL? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?alphalocation_tmp? may be used > uninitialized in this function > MCMCglmm.cc:225: warning: ?alphalocation? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?alphazstar? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?alphapred? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?alphaastar? may be used uninitialized in > this function > MCMCglmm.cc:225: warning: ?muAlpha? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?Alphainv? may be used uninitialized in this > function > MCMCglmm.cc:225: warning: ?tXalpha? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?Xalpha? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?linky_orig? may be used uninitialized in > this function > MCMCglmm.cc:228: warning: ?tYKrinvYS? may be used uninitialized in > this function > MCMCglmm.cc:228: warning: ?LambdaS? may be used uninitialized in this function > MCMCglmm.cc:227: warning: ?tYKrinvYL? may be used uninitialized in > this function > MCMCglmm.cc:227: warning: ?LambdaLU? may be used uninitialized in this > function > MCMCglmm.cc:225: warning: ?tYKrinvY? may be used uninitialized in this > function > MCMCglmm.cc:225: warning: ?tYKrinv? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?ILY? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?tY? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?Y? may be used uninitialized in this function > MCMCglmm.cc:225: warning: ?I? may be used uninitialized in this function > MCMCglmm.cc:228: warning: ?alphaS? may be used uninitialized in this function > MCMCglmm.cc
Re: [Rd] R CMD build wiped my computer
Hi Martin, I think this is the most likely reason given that the name in the DESCRIPTION file does NOT have a version number. Even so, it is very easy to misname a file and then delete it/change its name (as I've done here) and I hope current versions of R would not cause this problem. Perhaps Fedora should not use ~ as its back up file suffixes? Cheers, Jarrod On 28 Jul 2010, at 11:41, Martin Maechler wrote: Jarrod Hadfield on Tue, 27 Jul 2010 21:37:09 +0100 writes: Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove "junk files" it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, the culprit may lay here: * removing junk files unlink MCMCglmm_2.05/R/ residuals.MCMCglmm.R ~ where it seems that someone (you?) have added a newline in the filname, so instead of 'residuals.MCMCglmm.R~' you got 'residuals.MCMCglmm.R ~' and the unlink / rm command interpreted '~' as your home directory. But I can hardly believe it. This seems explanation seems a bit doubtful to me.. ... and even more importantly if I can I restore what was lost. well, you just get it from the backup. You do daily backups, do you? Regards, Martin Maechler, ETH Zurich Panickingly, Jarrod [jar...@localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file 'MCMCglmm_2.05/DESCRIPTION' ... OK * preparing 'MCMCglmm_2.05': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * Installing *source* package ?MCMCglmm? ... ** libs g++ -m64 -I/usr/include/R -I/usr/local/include-fpic -O2 -g - pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c MCMCglmm.cc -o MCMCglmm.o MCMCglmm.cc: In function ?void MCMCglmm(double*, double*, double*, int*, int*, int*, int*, int*, int*, double*, int*, int*, double*, int*, int*, double*, double*, int*, int*, int*, int*, int*, int*, int*, int*, int*, int*, double*, double*, double*, int*, int*, int*, int*, double*, double*, double*, int*, double*, bool*, double*, double*, int*, int*, int*, int*, int*, double*, int*, int*, int*, double*, double*, double*, int*, int*, double*, int*, int*, int*, int*, double*, double*, double*, double*)?: MCMCglmm.cc:228: warning: ?pvLS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?pvLL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Lrv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pmuL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?LambdaX? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?A? may be used uninitialized in this function MCMCglmm.cc:86: warning: ?dimG? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?AlphainvS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?AlphainvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphazstar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphapred? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?muAlpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Alphainv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tXalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Xalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?linky_orig? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?tYKrinvYS? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?LambdaS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?tYKrinvYL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?LambdaLU? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinvY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?ILY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Y? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?I? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?alphaS? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaMME? may be
[Rd] R CMD build error (RProtoBuf on windows)
Hello all,
I am trying to port the package RProtoBuf to windows. The developers of
RProtoBuf have given me some helpful pointers so far, but now I am stuck.
After having made what I think are the necessary changes to the package to
compile on windows, "R CMD build RProtoBuf" outputs a somewhat cryptic error
("This application has requested the Runtime to terminate it in an unusual
way") after which it deletes the temporary directory in which it was working.
How do I debug/investigate this? The relevant lines of the build output are
pasted below.
Thanks! Koert
g++ -shared -s -static-libgcc -o RProtoBuf.dll tmp.def ConnectionCopyingInputStr
eam.o ConnectionCopyingOutputStream.o ConnectionInputStream.o ConnectionOutputSt
ream.o DescriptorPoolLookup.o RSourceTree.o RWarningErrorCollector.o Rconnection
CopyingInputStream.o ZeroCopyInputStreamWrapper.o ZeroCopyOutputStreamWrapper.o
exceptions.o extractors.o lookup.o mutators.o rprotobuf.o streams.o wrapper_Arra
yInputStream.o wrapper_ArrayOutputStream.o wrapper_Descriptor.o wrapper_EnumDesc
riptor.o wrapper_EnumValueDescriptor.o wrapper_FieldDescriptor.o wrapper_FileDes
criptor.o wrapper_Message.o wrapper_MethodDescriptor.o wrapper_ServiceDescriptor
.o wrapper_ZeroCopyInputStream.o C:/Devel/R-2.12/library/Rcpp/lib/i386/libRcpp.a
-Lc:/Devel/mingw/msys/1.0/local/lib -lprotobuf -LC:/Devel/R-2.12/bin/i386 -lR
Info: resolving google::protobuf::FieldDescriptor::kTypeToCppTypeMap by lin
king to __imp___ZN6google8protobuf15FieldDescriptor17kTypeToCppTypeMapE (auto-im
portc:/devel/rtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/l
d.exe: warning: auto-importing has been activated without --enable-auto-import s
pecified on the command line.
This should work unless it involves constant data structures referencing symbols
from auto-imported DLLs.)
installing to C:/DOCUME~1/kkuipers/LOCALS~1/Temp/RtmpRbU0Q2/Rinst25a17ae0/RProto
Buf/libs/i386
** R
** demo
** inst
** preparing package for lazy loading
Loading required package: bitops
Warning: package 'Rcpp' was built under R version 2.12.1
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
* DONE (RProtoBuf)
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
---
ERROR: Installation failed
Removing installation dir
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build now removes empty dirs
Hi, It's unfortunate that with recent revisions of R 2.13 (this appeared in revision 54640, March 2), 'R CMD build' now removes empty dirs in the package. People might have good reasons for having empty dirs in their packages. For example, in Bioconductor, we have some tools to automatically generate annotation packages and those tools are implemented in software packages that use templates for the annotation packages to be generated. Those package templates are stored under the inst/ folder of the software package. One of those software packages is the AnnotationDbi package: it contains 41 package templates under inst/: [hpages@latitude Rpacks]$ ls AnnotationDbi/inst/AnnDbPkg-templates/ AFFYHUEX.DB CHIMP.DB MALARIA.DBWORM.DB ANOPHELES.DBCOELICOLOR.DB MOUSECHIP.DB XENOPUSCHIP.DB ARABIDOPSISCHIP.DB ECOLICHIP.DB MOUSE.DB XENOPUS.DB ARABIDOPSIS.DB ECOLI.DB ORGANISM.DB YEASTCHIP.DB BASEPKG.DB FLYCHIP.DB PFAM.DB YEAST.DB BOVINECHIP.DB FLY.DB PIGCHIP.DBYEASTNCBI.DB BOVINE.DB GO.DB PIG.DBZEBRAFISHCHIP.DB CANINECHIP.DB HUMANCHIP.DB RATCHIP.DBZEBRAFISH.DB CANINE.DB HUMAN.DB RAT.DB CHICKENCHIP.DB INPARANOID.DB RHESUS.DB CHICKEN.DB KEGG.DBWORMCHIP.DB Those package templates are just the skeletons of the hundreds of annotation packages that we generate. Of course, each of them contains empty subfolders. Having 'R CMD build' remove those empty subfolders breaks all the tools that make use of those package templates. Maybe I've missed it but I didn't see any mention of this "feature" on this list and the fact that it was added only 6 weeks before the next R and Bioconductor releases is only making this worse. I hope this "feature" can be reverted. Why would people or our build system need to start using R CMD build --keep-empty-dirs just to get a source tarball right? Thanks, H. PS: This page http://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html (referenced from http://developer.r-project.org/) has not been updated for months. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build error during vignettes build
Hello, I'm trying to rebuild a package (using R version 3.3.2 (2016-10-31)) that has not seen any changes since it was last built without problems in previous R versions. It fails during vignette building with: ------ $ R CMD build diveMove * checking for file ‘diveMove/DESCRIPTION’ ... OK * preparing ‘diveMove’: * checking DESCRIPTION meta-information ... OK * installing the package to build vignettes * creating vignettes ... ERROR Quitting from lines 432-438 (diveMove.Rnw) Error: processing vignette 'diveMove.Rnw' failed with diagnostics: missing values and NaN's not allowed if 'na.rm' is FALSE Execution halted --- --- There are no problems running the R code resulting from tangling the vignette. Specifically, the code referred to in the error is a single function call, which returns with no warnings or errors, so I have little to hold on to. How can I get more verbose debug from "R CMD build"? -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build/check on Windows 7
Folks: sessionInfo() R version 2.15.0 (2012-03-30) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] datasets splines grid tcltk stats graphics grDevices [8] utils methods base other attached packages: [1] svSocket_0.9-51 lattice_0.19-26 MASS_7.3-17 loaded via a namespace (and not attached): [1] cluster_1.14.2 Hmisc_3.9-3R2HTML_2.2 svMisc_0.9-65 TinnR_1.0-5 [6] tools_2.15.0 According to section 1.3 of the WRITING R EXTENSIONS manual, both R CMD build and R CMD check run R with the '--vanilla' option so no user startup files are read. However, 1. If I have an Rprofile.site in my etc startup directory, if I am in the ...\top directory and try to check or build the top\mypackage source package, I can only do so by giving (in the Windows shell, of course) the full path name to R CMD build/check, e.g. R CMD build pathtoTop\top\mypackage . R CMD build mypackage yields the error: ERROR cannot change to directory 'test' 2. However, if I remove (e.g. change the name) of Rprofile.site, then R CMD build/check mypackage works fine. Note that my Rprofile.site file DOES contain a setwd() statement to some other directory; if I comment out this statement, then I also do not need to use the full path name even with the Rprofile.site file there. So my question is: Is the documentation wrong? -- Is there an environmental variable or option I need to set/change? -- Is this a Windows "feature" subtlety? Many thanks. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'R CMD build --binary BUNDLE' and Windows
'R CMD build --binary BUNDLE' and Windows. When using R version 2.9.0 beta for 'R CMD build --binary CoCo' on Windows only the first package of the 'Contains' field of the bundle DESCRIPTION file ends up in the zip file. (Same result for the bundle 'VR' by R version 2.9.0 beta.) The check of the CoCo bundle version 0.1.7.5 by R version 2.9.0 beta is OK (on my machine), see attached 00check.log. The zip-file is OK by versions 2.6.0, 2.6.2, 2.7.2, and 2.8.0 of R. Regards, Jens Henrik Badsberg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build error (RProtoBuf on windows)
On Fri, 25 Feb 2011, Koert Kuipers wrote:
Hello all,
I am trying to port the package RProtoBuf to windows. The developers of
RProtoBuf have given me some helpful pointers so far, but now I am stuck.
After having made what I think are the necessary changes to the
package to compile on windows, "R CMD build RProtoBuf" outputs a
somewhat cryptic error ("This application has requested the Runtime
to terminate it in an unusual way") after which it deletes the
Well, that's a standard Windows error message: it is normally
accompanied by a popup window with more information.
temporary directory in which it was working. How do I
debug/investigate this? The relevant lines of the build output are
pasted below.
Why are you trying to rebuild the package vignettes? Use Rcmd build
--no-vignettes to get a tarball, Rcmd INSTALL to get an installed
package: then you can run the installed package under a debugger (see
the rw-FAQ) in the usual way to track down bugs in compiled code.
Thanks! Koert
g++ -shared -s -static-libgcc -o RProtoBuf.dll tmp.def ConnectionCopyingInputStr
eam.o ConnectionCopyingOutputStream.o ConnectionInputStream.o ConnectionOutputSt
ream.o DescriptorPoolLookup.o RSourceTree.o RWarningErrorCollector.o Rconnection
CopyingInputStream.o ZeroCopyInputStreamWrapper.o ZeroCopyOutputStreamWrapper.o
exceptions.o extractors.o lookup.o mutators.o rprotobuf.o streams.o wrapper_Arra
yInputStream.o wrapper_ArrayOutputStream.o wrapper_Descriptor.o wrapper_EnumDesc
riptor.o wrapper_EnumValueDescriptor.o wrapper_FieldDescriptor.o wrapper_FileDes
criptor.o wrapper_Message.o wrapper_MethodDescriptor.o wrapper_ServiceDescriptor
.o wrapper_ZeroCopyInputStream.o C:/Devel/R-2.12/library/Rcpp/lib/i386/libRcpp.a
-Lc:/Devel/mingw/msys/1.0/local/lib -lprotobuf -LC:/Devel/R-2.12/bin/i386 -lR
Info: resolving google::protobuf::FieldDescriptor::kTypeToCppTypeMap by lin
king to __imp___ZN6google8protobuf15FieldDescriptor17kTypeToCppTypeMapE (auto-im
portc:/devel/rtools/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/l
d.exe: warning: auto-importing has been activated without --enable-auto-import s
pecified on the command line.
This should work unless it involves constant data structures referencing symbols
from auto-imported DLLs.)
installing to C:/DOCUME~1/kkuipers/LOCALS~1/Temp/RtmpRbU0Q2/Rinst25a17ae0/RProto
Buf/libs/i386
** R
** demo
** inst
** preparing package for lazy loading
Loading required package: bitops
Warning: package 'Rcpp' was built under R version 2.12.1
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
* DONE (RProtoBuf)
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
---
ERROR: Installation failed
Removing installation dir
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build now removes empty dirs
I am also in favor for keeping the ability of installing directory structures that are partly empty. I've used it before to setup templates that can conveniently be copied recursively to a local path. I did noticed that R CMD INSTALL gave a warning about empty directories before (or was it a NOTE by R CMD check?). /Henrik On Tue, Mar 29, 2011 at 11:56 PM, Pages, Herve wrote: > Hi, > > It's unfortunate that with recent revisions of R 2.13 (this > appeared in revision 54640, March 2), 'R CMD build' now removes > empty dirs in the package. People might have good reasons for > having empty dirs in their packages. For example, in Bioconductor, > we have some tools to automatically generate annotation packages > and those tools are implemented in software packages that use > templates for the annotation packages to be generated. Those > package templates are stored under the inst/ folder of the > software package. One of those software packages is the > AnnotationDbi package: it contains 41 package templates under > inst/: > > [hpages@latitude Rpacks]$ ls AnnotationDbi/inst/AnnDbPkg-templates/ > AFFYHUEX.DB CHIMP.DB MALARIA.DB WORM.DB > ANOPHELES.DB COELICOLOR.DB MOUSECHIP.DB XENOPUSCHIP.DB > ARABIDOPSISCHIP.DB ECOLICHIP.DB MOUSE.DB XENOPUS.DB > ARABIDOPSIS.DB ECOLI.DB ORGANISM.DB YEASTCHIP.DB > BASEPKG.DB FLYCHIP.DB PFAM.DB YEAST.DB > BOVINECHIP.DB FLY.DB PIGCHIP.DB YEASTNCBI.DB > BOVINE.DB GO.DB PIG.DB ZEBRAFISHCHIP.DB > CANINECHIP.DB HUMANCHIP.DB RATCHIP.DB ZEBRAFISH.DB > CANINE.DB HUMAN.DB RAT.DB > CHICKENCHIP.DB INPARANOID.DB RHESUS.DB > CHICKEN.DB KEGG.DB WORMCHIP.DB > > Those package templates are just the skeletons of the hundreds of > annotation packages that we generate. Of course, each of them contains > empty subfolders. > > Having 'R CMD build' remove those empty subfolders breaks all the > tools that make use of those package templates. > > Maybe I've missed it but I didn't see any mention of this "feature" > on this list and the fact that it was added only 6 weeks before the > next R and Bioconductor releases is only making this worse. > > I hope this "feature" can be reverted. Why would people or our build > system need to start using R CMD build --keep-empty-dirs just to get > a source tarball right? > > Thanks, > H. > > PS: This page > > http://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html > > (referenced from http://developer.r-project.org/) has not been > updated for months. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build now removes empty dirs
Hi Henrik, Just to clarify, you still have the ability of installing directory structures that are partly empty. Actually 'R CMD INSTALL pkgpath/' does this. And if srctarball.tar.gz contains empty dirs, 'R CMD INSTALL srctarball.tar.gz' will also keep them. The problem is that *by default* 'R CMD build' removes those empty dirs, unless you specify --keep-empty-dirs The fact that 'R CMD build' and 'R CMD INSTALL' now have different default behaviors is really a bad thing since when I'm working on a package I typically do not use 'R CMD build' before I install it. I use 'R CMD INSTALL' directly on the package source tree. So everything looks ok to me because then empty dirs are installed. It's only later when I build the source tarball that it will be broken. It's not just --keep-empty-dirs, it's also --resave-data. These new options don't do the right thing by default and they are not even consistent between 'R CMD build' and 'R CMD INSTALL'. Cheers, H. On 11-03-30 08:04 PM, Henrik Bengtsson wrote: I am also in favor for keeping the ability of installing directory structures that are partly empty. I've used it before to setup templates that can conveniently be copied recursively to a local path. I did noticed that R CMD INSTALL gave a warning about empty directories before (or was it a NOTE by R CMD check?). /Henrik On Tue, Mar 29, 2011 at 11:56 PM, Pages, Herve wrote: Hi, It's unfortunate that with recent revisions of R 2.13 (this appeared in revision 54640, March 2), 'R CMD build' now removes empty dirs in the package. People might have good reasons for having empty dirs in their packages. For example, in Bioconductor, we have some tools to automatically generate annotation packages and those tools are implemented in software packages that use templates for the annotation packages to be generated. Those package templates are stored under the inst/ folder of the software package. One of those software packages is the AnnotationDbi package: it contains 41 package templates under inst/: [hpages@latitude Rpacks]$ ls AnnotationDbi/inst/AnnDbPkg-templates/ AFFYHUEX.DB CHIMP.DB MALARIA.DBWORM.DB ANOPHELES.DBCOELICOLOR.DB MOUSECHIP.DB XENOPUSCHIP.DB ARABIDOPSISCHIP.DB ECOLICHIP.DB MOUSE.DB XENOPUS.DB ARABIDOPSIS.DB ECOLI.DB ORGANISM.DB YEASTCHIP.DB BASEPKG.DB FLYCHIP.DB PFAM.DB YEAST.DB BOVINECHIP.DB FLY.DB PIGCHIP.DBYEASTNCBI.DB BOVINE.DB GO.DB PIG.DBZEBRAFISHCHIP.DB CANINECHIP.DB HUMANCHIP.DB RATCHIP.DBZEBRAFISH.DB CANINE.DB HUMAN.DB RAT.DB CHICKENCHIP.DB INPARANOID.DB RHESUS.DB CHICKEN.DB KEGG.DBWORMCHIP.DB Those package templates are just the skeletons of the hundreds of annotation packages that we generate. Of course, each of them contains empty subfolders. Having 'R CMD build' remove those empty subfolders breaks all the tools that make use of those package templates. Maybe I've missed it but I didn't see any mention of this "feature" on this list and the fact that it was added only 6 weeks before the next R and Bioconductor releases is only making this worse. I hope this "feature" can be reverted. Why would people or our build system need to start using R CMD build --keep-empty-dirs just to get a source tarball right? Thanks, H. PS: This page http://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html (referenced from http://developer.r-project.org/) has not been updated for months. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build now removes empty dirs
> Pages, Herve > on Tue, 29 Mar 2011 23:56:47 -0700 (PDT) writes: > Hi, It's unfortunate that with recent revisions of R 2.13 > (this appeared in revision 54640, March 2), 'R CMD build' > now removes empty dirs in the package. People might have > good reasons for having empty dirs in their packages. For > example, in Bioconductor, we have some tools to > automatically generate annotation packages and those tools > are implemented in software packages that use templates > for the annotation packages to be generated. Those package > templates are stored under the inst/ folder of the > software package. One of those software packages is the > AnnotationDbi package: it contains 41 package templates > under inst/: > [hpages@latitude Rpacks]$ ls > AnnotationDbi/inst/AnnDbPkg-templates/ AFFYHUEX.DB > CHIMP.DB MALARIA.DB WORM.DB ANOPHELES.DB COELICOLOR.DB > MOUSECHIP.DB XENOPUSCHIP.DB ARABIDOPSISCHIP.DB > ECOLICHIP.DB MOUSE.DB XENOPUS.DB ARABIDOPSIS.DB ECOLI.DB > ORGANISM.DB YEASTCHIP.DB BASEPKG.DB FLYCHIP.DB PFAM.DB > YEAST.DB BOVINECHIP.DB FLY.DB PIGCHIP.DB YEASTNCBI.DB > BOVINE.DB GO.DB PIG.DB ZEBRAFISHCHIP.DB CANINECHIP.DB > HUMANCHIP.DB RATCHIP.DB ZEBRAFISH.DB CANINE.DB HUMAN.DB > RAT.DB CHICKENCHIP.DB INPARANOID.DB RHESUS.DB CHICKEN.DB > KEGG.DB WORMCHIP.DB > Those package templates are just the skeletons of the > hundreds of annotation packages that we generate. Of > course, each of them contains empty subfolders. > Having 'R CMD build' remove those empty subfolders breaks > all the tools that make use of those package templates. > Maybe I've missed it but I didn't see any mention of this > "feature" on this list and the fact that it was added only > 6 weeks before the next R and Bioconductor releases is > only making this worse. > I hope this "feature" can be reverted. Why would people or > our build system need to start using R CMD build > --keep-empty-dirs just to get a source tarball right? > Thanks, H. > PS: This page > http://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html > (referenced from http://developer.r-project.org/) has not > been updated for months. Thank you, Herve. I've only now read your e-mail. (and I now also agree that --keep-empty-dirs should *not* be needed to keep an empty inst/ !) Thanks for the heads up about NEWS.html. It's finally current again, and hopefully remains so: It got outdated accidentally, as it was removed from the default 'make' target, and now needs an extra make call. Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build error during vignettes build
On 21/02/17 19:06, Sebastian P. Luque wrote: Hello, I'm trying to rebuild a package (using R version 3.3.2 (2016-10-31)) that has not seen any changes since it was last built without problems in previous R versions. It fails during vignette building with: ------ $ R CMD build diveMove * checking for file ‘diveMove/DESCRIPTION’ ... OK * preparing ‘diveMove’: * checking DESCRIPTION meta-information ... OK * installing the package to build vignettes * creating vignettes ... ERROR Quitting from lines 432-438 (diveMove.Rnw) Error: processing vignette 'diveMove.Rnw' failed with diagnostics: missing values and NaN's not allowed if 'na.rm' is FALSE Execution halted --- --- There are no problems running the R code resulting from tangling the vignette. Specifically, the code referred to in the error is a single function call, which returns with no warnings or errors, so I have little to hold on to. How can I get more verbose debug from "R CMD build"? Are you sure that the complete R code of the vignette runs without errors? I can't help you with getting more verbose output from 'R CMD build', but the error can be reproduced with other means, as outlined below. When trying to build the vignette from the git version of your package (as part of R CMD build), I see the same error message. Investigating further, the "tangled" file diveMove.R from 'tools::buildVignette("diveMove.Rnw")' has 68 lines and stops short of the code chunk "zoc" where the error occurs. Running that code obviously works fine. However, 'tools::buildVignette("diveMove.Rnw", weave = FALSE)' outputs a longer (154 lines) diveMove.R (presumably containing the complete code of the vignette) which includes the chunk "zoc". Executing the code with source() produces the expected error. This also identifies the call where the error occurs: Error in quantile.default(Ad1.maybe.nat, probs = (1 - ascent.crit.q)) : missing values and NaN's not allowed if 'na.rm' is FALSE The error can be investigated with the usual tools, e.g. traceback() and debug(). -- Mikko Korpela Department of Geosciences and Geography University of Helsinki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build error during vignettes build
On Wed, 22 Feb 2017 12:22:45 +0200,
Mikko Korpela wrote:
[...]
> When trying to build the vignette from the git version of your package
> (as part of R CMD build), I see the same error message. Investigating
> further, the "tangled" file diveMove.R from
> 'tools::buildVignette("diveMove.Rnw")' has 68 lines and stops short of
> the code chunk "zoc" where the error occurs. Running that code
> obviously works fine.
This is exactly what I failed to do -> check the tangled output to see
it is complete... It didn't occur to me to do that assuming all the code
would be there. Even more so considering there's nothing in the CRAN
checks showing problems.
Thank you Mikko!
--
Seb
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build/check on Windows 7
If of any value/FYI, this seems to be related to my R-devel post 'R devel [and R 2.14.1 patched]: R CMD build now sources ~/.Rprofile': https://stat.ethz.ch/pipermail/r-devel/2012-February/063365.html /Henrik On Tue, Jul 17, 2012 at 7:48 PM, Bert Gunter wrote: > Folks: > > sessionInfo() > R version 2.15.0 (2012-03-30) > Platform: i386-pc-mingw32/i386 (32-bit) > > locale: > [1] LC_COLLATE=English_United States.1252 > [2] LC_CTYPE=English_United States.1252 > [3] LC_MONETARY=English_United States.1252 > [4] LC_NUMERIC=C > > [5] LC_TIME=English_United States.1252 > > attached base packages: > [1] datasets splines grid tcltk stats graphics grDevices > [8] utils methods base > > other attached packages: > [1] svSocket_0.9-51 lattice_0.19-26 MASS_7.3-17 > > loaded via a namespace (and not attached): > [1] cluster_1.14.2 Hmisc_3.9-3R2HTML_2.2 svMisc_0.9-65 > TinnR_1.0-5 > [6] tools_2.15.0 > > > According to section 1.3 of the WRITING R EXTENSIONS manual, both R CMD > build and R CMD check run R with the '--vanilla' option so no user startup > files are read. > > However, > > 1. If I have an Rprofile.site in my etc startup directory, if I am in the > ...\top directory and try to check or build the top\mypackage source > package, I can only do so by giving (in the Windows shell, of course) the > full path name to R CMD build/check, e.g. > R CMD build pathtoTop\top\mypackage . > > R CMD build mypackage > > yields the error: ERROR cannot change to directory 'test' > > > 2. However, if I remove (e.g. change the name) of Rprofile.site, then > > R CMD build/check mypackage > > works fine. Note that my Rprofile.site file DOES contain a setwd() > statement to some other directory; if I comment out this statement, then I > also do not need to use the full path name even with the Rprofile.site file > there. > > So my question is: Is the documentation wrong? -- Is there an environmental > variable or option I need to set/change? -- Is this a Windows "feature" > subtlety? > > Many thanks. > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'R CMD build --binary BUNDLE' and Windows
c...@badsberg.eu wrote: 'R CMD build --binary BUNDLE' and Windows. When using R version 2.9.0 beta for 'R CMD build --binary CoCo' on Windows only the first package of the 'Contains' field of the bundle DESCRIPTION file ends up in the zip file. (Same result for the bundle 'VR' by R version 2.9.0 beta.) The check of the CoCo bundle version 0.1.7.5 by R version 2.9.0 beta is OK (on my machine), see attached 00check.log. The zip-file is OK by versions 2.6.0, 2.6.2, 2.7.2, and 2.8.0 of R. Brian fixed this, please check the current version (r48312). -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'R CMD build --binary BUNDLE' and Windows
It has only been fixed partly: 'Contains' fields with more than about 72 characters are 'corrupted' when the DESCRIPTION file is 'reformated' in the process from 'incomming' to 'http://cran.at.r-project.org/web/packages/' - or R (2.9.0) cannot handle 'contains' fields with more than one line. The bundle 'CoCo version 0.1.7.5' I submitted april 3th now checks OK by R version 2.9.0 RC: http://win-builder.r-project.org/JDzIuXv33Z9B/ But a check on file 'CoCo_0.1.7.5.tar.gz' from http://cran.at.r-project.org/web/packages/CoCo/index.html is not OK: http://win-builder.r-project.org/9Nh7tz03uCV8/ The difference is that the DESCRIPTION file of the bundle is 'reformated' by CRAN, dividing the 'Contains' filed onto two lines. Regards, Jens Henrik 'diff' of DESCRIPTION files: < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ diff -b CoCo/DESCRIPTION ../../2009.04.03/mnt/CoCo/DESCRIPTION 2,3c2 < Contains: CoCoObjects CoCoCore CoCoRaw CoCoOldData CoCoGraph CoCo < CoCoCg --- > Contains: CoCoObjects CoCoCore CoCoRaw CoCoOldData CoCoGraph CoCo CoCoCg 9,15c8,13 < BundleDescription: Interface to CoCo from R - Graphical modelling by < CoCo. The package CoCo handles discrete data by log-linear < models and contingency tables. CoCoCg is for both discrete and < continuous data by CG-regressions. CoCoCore and CoCoRaw contain < respectively the one entry point interface function to CoCo end < the interface functions for the commands of CoCo. CoCoObjects < and CoCoGraph are base and extension with objects and graphs. --- > BundleDescription: Interface to CoCo from R - Graphical modelling by CoCo. > The package CoCo handles discrete data by log-linear models and contingency tables. > CoCoCg is for both discrete and continuous data by CG-regressions. > CoCoCore and CoCoRaw contain respectively the one entry point interface function > to CoCo end the interface functions for the commands of CoCo. > CoCoObjects and CoCoGraph are base and extension with objects and graphs. 17,18c15,16 < Copyright: Copyright (C) by Jens Henrik Badsberg, 1991-2009, non-profit < use and redistribution permitted (Artistic License 2.0) --- > Copyright: Copyright (C) by Jens Henrik Badsberg, 1991-2009, > non-profit use and redistribution permitted (Artistic License 2.0) 22,23d19 < Repository: CRAN < Date/Publication: 2009-04-04 20:41:49 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Submitted DESCRIPTION file of the CoCo-bundle: < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bundle: CoCo Contains: CoCoObjects CoCoCore CoCoRaw CoCoOldData CoCoGraph CoCo CoCoCg Version: 0.1.7.5 Date: 03.04.2009 Author: Jens Henrik Badsberg Maintainer: Jens Henrik Badsberg Depends: R (>= 2.0.0), dynamicGraph (>= 0.2.0), MASS, methods BundleDescription: Interface to CoCo from R - Graphical modelling by CoCo. The package CoCo handles discrete data by log-linear models and contingency tables. CoCoCg is for both discrete and continuous data by CG-regressions. CoCoCore and CoCoRaw contain respectively the one entry point interface function to CoCo end the interface functions for the commands of CoCo. CoCoObjects and CoCoGraph are base and extension with objects and graphs. License: file LICENSE Copyright: Copyright (C) by Jens Henrik Badsberg, 1991-2009, non-profit use and redistribution permitted (Artistic License 2.0) Address: Andreas Bjorns Gade 21, 2. tv, 1428 Kobenhavn K, Denmark URL: http://www.badsberg.eu Packaged: Fri Apr 3 23:41:15 2009; CoCo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > DESCRIPTION file of the CoCo-bundle on CRAN: < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bundle: CoCo Contains: CoCoObjects CoCoCore CoCoRaw CoCoOldData CoCoGraph CoCo CoCoCg Version: 0.1.7.5 Date: 03.04.2009 Author: Jens Henrik Badsberg Maintainer: Jens Henrik Badsberg Depends: R (>= 2.0.0), dynamicGraph (>= 0.2.0), MASS, methods BundleDescription: Interface to CoCo from R - Graphical modelling by CoCo. The package CoCo handles discrete data by log-linear models and contingency tables. CoCoCg is for both discrete and continuous data by CG-regressions. CoCoCore and CoCoRaw contain respectively the one entry point interface function to CoCo end the interface functions for the commands of CoCo. CoCoObjects and CoCoGraph are base and extension with objects and graphs. License: file LICENSE Copyright: Copyright (C) by Jens Henrik Badsberg, 1991-2009, non-profit use and redistribution permitted (Artistic License 2.0) Address: Andreas Bjorns Gade 21, 2. tv, 1428 Kobenhavn K, Denmark URL: http://www.badsberg.eu Packaged: Fri Apr 3 23:41:15 2009; CoCo Repository: CRAN Date/Publication: 2009-04-04 20:41:49 - - - - - - - - - - - - - - - - - - - - - -
[Rd] R CMD build says, 'Can't call method "print"'
Hi, While running R CMD build on one of the Bioc packages, I'm getting the following error message * creating vignettes ... OK * cleaning src * removing junk files * checking for LF line-endings in source files Can't call method "print" on an undefined value at /home/sfalcon/arch/x86_64/R-2.3/bin/build line 646. The pacakge has CRLF line endings in source files. > R.version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status RC major 2 minor 3.0 year 2006 month 04 day22 svn rev37906 language R version.string Version 2.3.0 RC (2006-04-22 r37906) + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build fails with try(stop()) in vignette
A vignette in /inst/doc with
\documentclass[]{article}
\begin{document}
<>=
try(stop('err'))
@
\end{document}
produces an error with R CMD build :
...
** building package indices ...
* DONE (testPkg)
* creating vignettes ... ERROR
Error in try(stop("err")) : err
This is not seen with Sweave alone.
> sessionInfo()
R version 2.5.0 beta (2007-04-11 r41127)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
attached base packages:
[1] "stats" "graphics" "grDevices" "utils" "datasets" "methods"
[7] "base"
--
Martin Morgan
Bioconductor / Computational Biology
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build with mingw and msys (PR#9766)
Full_Name: Steffen
Version: 2-5-0
OS: Windows
Submission from: (NULL) (192.124.243.162)
Hi,
the R CMD build script is using
if($WINDOWS) {
## workaround for paths in Cygwin tar
$filepath =~ s+^([A-Za-z]):+/cygdrive/\1+;
}
which does not work if the build environment is a MINGW.
I have added the patch below,
Yours,
Steffen
$ diff -u build build.orig
--- build Fri Jun 29 13:50:16 2007
+++ build.orig Fri Jun 29 08:51:48 2007
@@ -47,7 +47,6 @@
R::Vars::error("R_HOME", "R_EXE");
my $WINDOWS = ($R::Vars::OSTYPE eq "windows");
-my $MSYS = ( $ENV{OSTYPE} eq "msys" );
my @exclude_patterns = R::Utils::get_exclude_patterns();
@@ -222,14 +221,10 @@
my $filepath = &file_path($startdir, $filename);
## under Windows, need separate Cygwin and Windows versions of path.
my $origfilepath = $filepath;
-if ($MSYS) {
- ## different workwaround for MSYS
- $filepath =~ s+^([A-Za-z]):+/\1/+;
-} elsif ($WINDOWS) {
- ## workaround for paths in Cygwin tar
- $filepath =~ s+^([A-Za-z]):+/cygdrive/\1+;
+if($WINDOWS) {
+ ## workaround for paths in Cygwin tar
+ $filepath =~ s+^([A-Za-z]):+/cygdrive/\1+;
}
-
R_system(join(" ",
("$tar chf",
&shell_quote_file_path($filepath),
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build: "Subdirectory 'R' contains invalid file names"
Hi, I get
* excluding invalid files from 'R.oo'
Subdirectory 'R' contains invalid file names:
attachLocally.Object.Rex Exception.Rex extend.default.Rex
InternalErrorException.reportBug.Rex Package.Rex Person.Rex Rdoc.Rex
setMethodS3.Rex StaticFields.Rex
when running R CMD build in R v2.3.0 devel. I do understand what is
going on. In my *.R files I keep so called Rdoc comments which in
their simplest form are Rd code wrapped up in plain comments. These
are compiled into Rd files written to ../man/ (I do this prior to
building packages). Rdoc also supports inclusion of other files, e.g.
@include "Person.Rex" to include example code.
With this structure I can, when I develop/maintain a package, have
/R/ as the working directory, modify my *.R files and re-source
them from within R. Since I keep all my Rd example code in separate
*.Rex files, I can easily rerun/test these by sourcing them too. I
find this very convenient.
In previous versions, the *.Rex files was included when building a
source distribution of a package. In R v2.3.0 they are excluded.
However, I would like to distribute the *.Rex files with my
source-code package too (so I do not have to keep another type of
source distribution). Note that these files are only needed for
further development of the package, but *not* to install the package
from source (since their contents is already incorporated in the Rd
files). They are also not of interest to the end-user.
My question is how to incorporate the *.Rex files? Here are some
ideas, that I would like to have some feedback on:
1) Put them in /R/Rex/*.Rex. However, Section 1.1.4 in Writing R
Extensions suggest that subdirectories of R/ may only(?) be named
'windows' or 'unix'.
2) Rename them to /R/*.in, cf. Section 1.1.4. Is this the
purpose of *.in files? Will it have side effects?
3) Put the in /inst//*.Rex. This will work, but then they
will also be install and available in system.file("",
package=""). Not a big problem, but not what I want.
4) To avoid (3), put the in //*.Rex, i.e. at the top level
directory. Is this allowed? Section 1.1.4 says "Note that [...]
information files at the top level of the package will not be
installed". Does this mean that they will be included in the source
distribution and what about top level directories?
5) Put the in /src/*.Rex. Can src/ be used this way too?
6) Ask R-core to revert back to pre-R v2.3.0 and allow other files in
the R/ directory too. Are more people than I interested in this?
I realize I can test the above by trial and error, but I will still
not be sure what is the right approach here. Comments/feedback is
appreciated.
Thanks
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build says, 'Can't call method "print"'
This is a Perl scope problem on $log. For a quick fix, remove 'my' where it is defined (the real fix is to pass $log down, and I'll do that in the sources). On Sun, 23 Apr 2006, Seth Falcon wrote: > Hi, > > While running R CMD build on one of the Bioc packages, I'm getting the > following error message > > * creating vignettes ... OK > * cleaning src > * removing junk files > * checking for LF line-endings in source files > Can't call method "print" on an undefined value at > /home/sfalcon/arch/x86_64/R-2.3/bin/build line 646. > > The pacakge has CRLF line endings in source files. > > >> R.version > _ > platform x86_64-unknown-linux-gnu > arch x86_64 > os linux-gnu > system x86_64, linux-gnu > status RC > major 2 > minor 3.0 > year 2006 > month 04 > day22 > svn rev37906 > language R > version.string Version 2.3.0 RC (2006-04-22 r37906) > > > + seth > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build wiped my computer (from R-help)
NOTE: Now submitted to R-devel, as this seems more appropriate.
I may have spoken too soon about this having been fixed. (see below).
If I create another "unusual but not 'invalid'" filename in the R subdirectory,
the
behaviour is different from that reported below, and is similar to the original
poster's
output (the third "unlink" command, where "xyz" was "~"):
circa> ls -al RColorBrewer/R
total 140
-rwxr-xr-x 1 ray ecs 43988 Apr 17 2005ColorBrewer.R~*
-rw-r--r-- 1 ray ecs 0 Jul 29 09:57residuals.MCMCglmm.R?xyz
drwxr-xr-x 2 ray ecs 4096 Jul 29 12:02 ./
drwxr-xr-x 5 ray ecs 4096 Jul 29 11:49 ../
-rwxr-xr-x 1 ray ecs 43988 Jul 29 09:57 ColorBrewer.R*
-rwxr-xr-x 1 ray ecs 43988 Apr 17 2005 ColorBrewer.R~*
-rw-r--r-- 1 ray ecs 0 Jul 29 09:58 residuals.MCMCglmm.R
circa>
circa>
circa> R CMD build RColorBrewer
* checking for file 'RColorBrewer/DESCRIPTION' ... OK
* preparing 'RColorBrewer':
* checking DESCRIPTION meta-information ... OK
* checking whether 'INDEX' is up-to-date ... NO
* use '--force' to overwrite the existing 'INDEX'
* removing junk files
unlink RColorBrewer/R/ ColorBrewer.R~
unlink RColorBrewer/R/ColorBrewer.R
unlink RColorBrewer/R/ residuals.MCMCglmm.R
xyz
unlink RColorBrewer/R/residuals.MCMCglmm.R
unlink RColorBrewer/R/ColorBrewer.R~
rmdir RColorBrewer/R
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'RColorBrewer_1.0-3.tar.gz'
circa>
Ray Brownrigg
On Thu, 29 Jul 2010, Ray Brownrigg wrote:
> On Thu, 29 Jul 2010, Duncan Murdoch wrote:
> > On 28/07/2010 10:01 AM, Jarrod Hadfield wrote:
> > > Hi Marc,
> > >
> > > Thanks for the info on recovery - most of it can pieced together from
> > > backups but a quick, cheap and easy method of recovery would have been
> > > nicer.
> > >
> > > My main concern is that this could happen again and that the "bug" is
> > > not limited to R 2.9. I would think that an accidental carriage return
> > > at the end of a file name (even a temporary one) would be a reasonably
> > > common phenomenon (I'm surprised I hadn't done it before).
> >
> > If you can put together a recipe to reproduce the problem (or a less
> > extreme version of R deleting files it shouldn't), we'll certainly fix
> > it. But so far all we've got are guesses about what might have gone
> > wrong, and I don't think anyone has been able to reproduce the problem
> > on current R.
>
> Duncan:
>
> It looks to me like it has already been fixed, if indeed that was the
> problem. In R-2.10.1, I tried to reproduce the problem (using
> RColorBrewer, since that was the smallest package I have a local copy of),
> and the build produced this:
>
> * removing junk files
> * excluding invalid files from 'RColorBrewer'
> Subdirectory 'R' contains invalid file names:
> residuals.MCMCglmm.R xyz
>
> where the space shown between the "R" and the "xyz" was a newline
> character. [I didn't dare try using a "~" :-)]
>
> Ray Brownrigg
>
> > Duncan Murdoch
> >
> > > Cheers,
> > >
> > > Jarrod
> > >
> > > On 28 Jul 2010, at 14:04, Marc Schwartz wrote:
> > > > Jarrod,
> > > >
> > > > Noting your exchange with Martin, Martin brings up a point that
> > > > certainly I missed, which is that somehow the tilde ('~') character
> > > > got into the chain of events. As Martin noted, on Linuxen/Unixen
> > > > (including OSX), the tilde, when used in the context of file name
> > > > globbing, refers to your home directory. Thus, a command such as:
> > > >
> > > > ls ~
> > > >
> > > > will list the files in your home directory. Similarly:
> > > >
> > > > rm ~
> > > >
> > > > will remove the files there as well. If the -rf argument is added,
> > > > then the deletion becomes recursive through that directory tree,
> > > > which appears to be the case here.
> > > >
> > > > I am unclear, as Martin appears to be, as to the steps that caused
> > > > this to happen. That may yet be related in some fashion to Duncan's
> > > > hypothesis.
> > > >
> > > > That being said, the use of the tilde character as a suffix to
> > > > denote that a file is a backup version, is not limited to Fedora or
> > > > Linux, for that matter. It is quite common for many text editors
> > > > (eg. Emacs) to use this. As a result, it is also common for many
> > > > applications to ignore files that have a tilde suffix.
> > > >
> > > > Based upon your follow up posts to the original thread, it would
> > > > seem that you do not have any backups. The default ext3 file system
> > > > that is used on modern Linuxen, by design, makes it a bit more
> > > > difficult to recover deleted files. This is due to the unlinking of
> > > > file metadata at the file system data structure level, as opposed to
> > > > simply marking the file as deleted in the directory structures, as
> > > > happens on Windows.
> > > >
> > > > There is a utility called ext3undel
> > > > (http://projects.izzysoft.de/trac/ext3undel ), which is a wrapper of
> > > > sorts to other
Re: [Rd] R CMD build wiped my computer (from R-help)
On 28/07/2010 8:10 PM, Ray Brownrigg wrote:
NOTE: Now submitted to R-devel, as this seems more appropriate.
I may have spoken too soon about this having been fixed. (see below).
If I create another "unusual but not 'invalid'" filename in the R subdirectory, the
behaviour is different from that reported below, and is similar to the original poster's
output (the third "unlink" command, where "xyz" was "~"):
circa> ls -al RColorBrewer/R
total 140
-rwxr-xr-x 1 ray ecs 43988 Apr 17 2005ColorBrewer.R~*
-rw-r--r-- 1 ray ecs 0 Jul 29 09:57residuals.MCMCglmm.R?xyz
Ray clarified to me that this filename was "residuals.MCMCglmm.R"
preceded by 3 spaces and followed by a carriage return and "xyz".
drwxr-xr-x 2 ray ecs 4096 Jul 29 12:02 ./
drwxr-xr-x 5 ray ecs 4096 Jul 29 11:49 ../
-rwxr-xr-x 1 ray ecs 43988 Jul 29 09:57 ColorBrewer.R*
-rwxr-xr-x 1 ray ecs 43988 Apr 17 2005 ColorBrewer.R~*
-rw-r--r-- 1 ray ecs 0 Jul 29 09:58 residuals.MCMCglmm.R
circa>
circa>
circa> R CMD build RColorBrewer
* checking for file 'RColorBrewer/DESCRIPTION' ... OK
* preparing 'RColorBrewer':
* checking DESCRIPTION meta-information ... OK
* checking whether 'INDEX' is up-to-date ... NO
* use '--force' to overwrite the existing 'INDEX'
* removing junk files
unlink RColorBrewer/R/ ColorBrewer.R~
unlink RColorBrewer/R/ColorBrewer.R
unlink RColorBrewer/R/ residuals.MCMCglmm.R
xyz
That certainly looks bad. I can't reproduce it on Windows; it doesn't
allow that filename. So I'll have to leave this for a Unix-alike user.
Duncan Murdoch
unlink RColorBrewer/R/residuals.MCMCglmm.R
unlink RColorBrewer/R/ColorBrewer.R~
rmdir RColorBrewer/R
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building 'RColorBrewer_1.0-3.tar.gz'
circa>
Ray Brownrigg
On Thu, 29 Jul 2010, Ray Brownrigg wrote:
On Thu, 29 Jul 2010, Duncan Murdoch wrote:
On 28/07/2010 10:01 AM, Jarrod Hadfield wrote:
Hi Marc,
Thanks for the info on recovery - most of it can pieced together from
backups but a quick, cheap and easy method of recovery would have been
nicer.
My main concern is that this could happen again and that the "bug" is
not limited to R 2.9. I would think that an accidental carriage return
at the end of a file name (even a temporary one) would be a reasonably
common phenomenon (I'm surprised I hadn't done it before).
If you can put together a recipe to reproduce the problem (or a less
extreme version of R deleting files it shouldn't), we'll certainly fix
it. But so far all we've got are guesses about what might have gone
wrong, and I don't think anyone has been able to reproduce the problem
on current R.
Duncan:
It looks to me like it has already been fixed, if indeed that was the
problem. In R-2.10.1, I tried to reproduce the problem (using
RColorBrewer, since that was the smallest package I have a local copy of),
and the build produced this:
* removing junk files
* excluding invalid files from 'RColorBrewer'
Subdirectory 'R' contains invalid file names:
residuals.MCMCglmm.R xyz
where the space shown between the "R" and the "xyz" was a newline
character. [I didn't dare try using a "~" :-)]
Ray Brownrigg
Duncan Murdoch
Cheers,
Jarrod
On 28 Jul 2010, at 14:04, Marc Schwartz wrote:
Jarrod,
Noting your exchange with Martin, Martin brings up a point that
certainly I missed, which is that somehow the tilde ('~') character
got into the chain of events. As Martin noted, on Linuxen/Unixen
(including OSX), the tilde, when used in the context of file name
globbing, refers to your home directory. Thus, a command such as:
ls ~
will list the files in your home directory. Similarly:
rm ~
will remove the files there as well. If the -rf argument is added,
then the deletion becomes recursive through that directory tree,
which appears to be the case here.
I am unclear, as Martin appears to be, as to the steps that caused
this to happen. That may yet be related in some fashion to Duncan's
hypothesis.
That being said, the use of the tilde character as a suffix to
denote that a file is a backup version, is not limited to Fedora or
Linux, for that matter. It is quite common for many text editors
(eg. Emacs) to use this. As a result, it is also common for many
applications to ignore files that have a tilde suffix.
Based upon your follow up posts to the original thread, it would
seem that you do not have any backups. The default ext3 file system
that is used on modern Linuxen, by design, makes it a bit more
difficult to recover deleted files. This is due to the unlinking of
file metadata at the file system data structure level, as opposed to
simply marking the file as deleted in the directory structures, as
happens on Windows.
There is a utility called ext3undel
(http://projects.izzysoft.de/trac/ext3undel ), which is a wrapper of
sorts to other undelete utilities such as PhotoRec and foremost. I
have not used it/them, so cannot speak from pers
Re: [Rd] R CMD build wiped my computer (from R-help)
Duncan Murdoch wrote:
> On 28/07/2010 8:10 PM, Ray Brownrigg wrote:
>> NOTE: Now submitted to R-devel, as this seems more appropriate.
>>
>> I may have spoken too soon about this having been fixed. (see below).
>>
>> If I create another "unusual but not 'invalid'" filename in the R
>> subdirectory, the
>> behaviour is different from that reported below, and is similar to the
>> original poster's
>> output (the third "unlink" command, where "xyz" was "~"):
>>
>> circa> ls -al RColorBrewer/R
>> total 140
>> -rwxr-xr-x 1 ray ecs 43988 Apr 17 2005ColorBrewer.R~*
>> -rw-r--r-- 1 ray ecs 0 Jul 29 09:57residuals.MCMCglmm.R?xyz
>
> Ray clarified to me that this filename was "residuals.MCMCglmm.R"
> preceded by 3 spaces and followed by a carriage return and "xyz".
>
>> drwxr-xr-x 2 ray ecs 4096 Jul 29 12:02 ./
>> drwxr-xr-x 5 ray ecs 4096 Jul 29 11:49 ../
>> -rwxr-xr-x 1 ray ecs 43988 Jul 29 09:57 ColorBrewer.R*
>> -rwxr-xr-x 1 ray ecs 43988 Apr 17 2005 ColorBrewer.R~*
>> -rw-r--r-- 1 ray ecs 0 Jul 29 09:58 residuals.MCMCglmm.R
>> circa>
>> circa>
>> circa> R CMD build RColorBrewer
>> * checking for file 'RColorBrewer/DESCRIPTION' ... OK
>> * preparing 'RColorBrewer':
>> * checking DESCRIPTION meta-information ... OK
>> * checking whether 'INDEX' is up-to-date ... NO
>> * use '--force' to overwrite the existing 'INDEX'
>> * removing junk files
>> unlink RColorBrewer/R/ ColorBrewer.R~
>> unlink RColorBrewer/R/ColorBrewer.R
>> unlink RColorBrewer/R/ residuals.MCMCglmm.R
>> xyz
>
> That certainly looks bad. I can't reproduce it on Windows; it doesn't
> allow that filename. So I'll have to leave this for a Unix-alike user.
I have been following this from the sideline, because I suck really bad
when it comes to Perl programming. However
I'm seeing this stuff in the build script:
## Remove exclude files.
open(EXCLUDE, "< $exclude");
while() {
rmtree(glob($_));
}
close(EXCLUDE);
Now this comes after
find(\&find_exclude_files, "$pkgname");
which AFAICT prints a number of file names into EXCLUDE. Now if one of
those file names contain a wildcard, I conjecture that the glob() can
make weird things happen. I don't think we want to glob there, do we?
Another issue is that EXCLUDE seems unprotected against file names with
embedded newlines. Something like find's -print0 would be handy...
> Duncan Murdoch
>
>> unlink RColorBrewer/R/residuals.MCMCglmm.R
>> unlink RColorBrewer/R/ColorBrewer.R~
>> rmdir RColorBrewer/R
>> * checking for LF line-endings in source and make files
>> * checking for empty or unneeded directories
>> * building 'RColorBrewer_1.0-3.tar.gz'
>>
>> circa>
>>
>> Ray Brownrigg
>>
>> On Thu, 29 Jul 2010, Ray Brownrigg wrote:
>>> On Thu, 29 Jul 2010, Duncan Murdoch wrote:
On 28/07/2010 10:01 AM, Jarrod Hadfield wrote:
> Hi Marc,
>
> Thanks for the info on recovery - most of it can pieced together from
> backups but a quick, cheap and easy method of recovery would have been
> nicer.
>
> My main concern is that this could happen again and that the "bug" is
> not limited to R 2.9. I would think that an accidental carriage return
> at the end of a file name (even a temporary one) would be a reasonably
> common phenomenon (I'm surprised I hadn't done it before).
If you can put together a recipe to reproduce the problem (or a less
extreme version of R deleting files it shouldn't), we'll certainly fix
it. But so far all we've got are guesses about what might have gone
wrong, and I don't think anyone has been able to reproduce the problem
on current R.
>>> Duncan:
>>>
>>> It looks to me like it has already been fixed, if indeed that was the
>>> problem. In R-2.10.1, I tried to reproduce the problem (using
>>> RColorBrewer, since that was the smallest package I have a local copy of),
>>> and the build produced this:
>>>
>>> * removing junk files
>>> * excluding invalid files from 'RColorBrewer'
>>> Subdirectory 'R' contains invalid file names:
>>> residuals.MCMCglmm.R xyz
>>>
>>> where the space shown between the "R" and the "xyz" was a newline
>>> character. [I didn't dare try using a "~" :-)]
>>>
>>> Ray Brownrigg
>>>
Duncan Murdoch
> Cheers,
>
> Jarrod
>
> On 28 Jul 2010, at 14:04, Marc Schwartz wrote:
>> Jarrod,
>>
>> Noting your exchange with Martin, Martin brings up a point that
>> certainly I missed, which is that somehow the tilde ('~') character
>> got into the chain of events. As Martin noted, on Linuxen/Unixen
>> (including OSX), the tilde, when used in the context of file name
>> globbing, refers to your home directory. Thus, a command such as:
>>
>> ls ~
>>
>> will list the files in your home directory. Similarly:
>>
>> rm ~
>>
>> will remove the files there as well. If the -rf argument is added,
>> then the deletion becomes recursive throu
[Rd] 'R CMD build' not cleaning the src/ folder on Windows
Hi, 'R CMD build' (with R 2.12.0 RC) fails to clean the src/ folder on Windows: D:\biocbld\bbs-2.7-bioc>ls meat/BUS/src BUS.cpp BUS.h D:\biocbld\bbs-2.7-bioc>R\bin\R CMD build meat\BUS * checking for file 'meat\BUS/DESCRIPTION' ... OK * preparing 'BUS': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * creating vignettes ... OK * cleaning src * checking for LF line-endings in source and make files * checking for empty or unneeded directories * building 'BUS_1.5.0.tar.gz' D:\biocbld\bbs-2.7-bioc>tar ztvf BUS_1.5.0.tar.gz --wildcards '*.o' -rwxr--r-- biocbuild2/root 16503 2010-10-10 22:15 BUS/src/BUS.o Packages with a Makefile in src/ don't seem to be affected. This is with R 2.12.0 RC (2010-10-07 r53227). Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build fails with try(stop()) in vignette
It would appear that printing the error message to stderr() is what is
causing the build to fail; replace
try(stop('err'))
with
cat('Error in try(stop("err")) : err\n', file = stderr())
and I get the same failure.
Best,
luke
On Wed, 11 Apr 2007, Martin Morgan wrote:
> A vignette in /inst/doc with
>
> \documentclass[]{article}
> \begin{document}
> <>=
> try(stop('err'))
> @
> \end{document}
>
> produces an error with R CMD build :
>
> ...
> ** building package indices ...
> * DONE (testPkg)
> * creating vignettes ... ERROR
> Error in try(stop("err")) : err
>
> This is not seen with Sweave alone.
>
>> sessionInfo()
> R version 2.5.0 beta (2007-04-11 r41127)
> x86_64-unknown-linux-gnu
>
> locale:
> LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] "stats" "graphics" "grDevices" "utils" "datasets" "methods"
> [7] "base"
>
>
>
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build fails with try(stop()) in vignette
> On Wed, 11 Apr 2007 17:28:31 -0500 (CDT),
> Luke Tierney (LT) wrote:
> It would appear that printing the error message to stderr() is what is
> causing the build to fail; replace
> try(stop('err'))
> with
> cat('Error in try(stop("err")) : err\n', file = stderr())
> and I get the same failure.
Yes, both R CMD check and R CMD build "analyse" the textual output
from running R (on examples, vigenttes, ...) to locate
problems. Reason is a chicken&egg problem: You cannot use the same R
process which runs the code to spot all problems, because it may not
survive until the point where you are able to spot the problem.
Having errors thrown in code chunks is still in many ways an open
problem in Sweave files, because it is hard to distinguish problems
the user wants to show to the reader from ones that are not deliberate
...
Best,
Fritz
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build fails with try(stop()) in vignette
On Thu, 12 Apr 2007, Friedrich Leisch wrote:
>> On Wed, 11 Apr 2007 17:28:31 -0500 (CDT),
>> Luke Tierney (LT) wrote:
>
> > It would appear that printing the error message to stderr() is what is
> > causing the build to fail; replace
>
> >try(stop('err'))
>
> > with
>
> >cat('Error in try(stop("err")) : err\n', file = stderr())
>
> > and I get the same failure.
>
> Yes, both R CMD check and R CMD build "analyse" the textual output
> from running R (on examples, vigenttes, ...) to locate
> problems. Reason is a chicken&egg problem: You cannot use the same R
> process which runs the code to spot all problems, because it may not
> survive until the point where you are able to spot the problem.
>
> Having errors thrown in code chunks is still in many ways an open
> problem in Sweave files, because it is hard to distinguish problems
> the user wants to show to the reader from ones that are not deliberate
> ...
Just to clarify: this means for now the recommendation would be for
authors of vignettes using try() to arrange to suppress the error
message either by adding silent=TRUE to the call or setting the
show.error.messages option to FALSE?
Best,
luke
>
>
> Best,
> Fritz
>
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build fails with try(stop()) in vignette
> On Thu, 12 Apr 2007 07:35:28 -0500 (CDT),
> Luke Tierney (LT) wrote:
> On Thu, 12 Apr 2007, Friedrich Leisch wrote:
>>> On Wed, 11 Apr 2007 17:28:31 -0500 (CDT),
>>> Luke Tierney (LT) wrote:
>>
>> > It would appear that printing the error message to stderr() is what is
>> > causing the build to fail; replace
>>
>> > try(stop('err'))
>>
>> > with
>>
>> > cat('Error in try(stop("err")) : err\n', file = stderr())
>>
>> > and I get the same failure.
>>
>> Yes, both R CMD check and R CMD build "analyse" the textual output
>> from running R (on examples, vigenttes, ...) to locate
>> problems. Reason is a chicken&egg problem: You cannot use the same R
>> process which runs the code to spot all problems, because it may not
>> survive untilthe point where you are able to spot the problem.
>>
>> Having errors thrown in code chunks is still in many ways an open
>> problem in Sweave files, because it is hard to distinguish problems
>> the user wants to show to the reader from ones that are not deliberate
>> ...
> Just to clarify: this means for now the recommendation would be for
> authors of vignettes using try() to arrange to suppress the error
> message either by adding silent=TRUE to the call or setting the
> show.error.messages option to FALSE?
Yes. We should try to get a better system, but I'm not sure what that
should be (and definetely not for 2.5).
Most of the stuff is by Kurt, so we should wait for his opinion. If
you look at the R CMD check code you will see a lot of grep's for
"^Error", so merely inserting a blank before the error message may do
the trick, but we have no means to automate that yet.
.f
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build with mingw and msys (PR#9766)
On 29/06/2007 7:53 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Steffen
> Version: 2-5-0
> OS: Windows
> Submission from: (NULL) (192.124.243.162)
>
>
> Hi,
>
> the R CMD build script is using
>
> if($WINDOWS) {
> ## workaround for paths in Cygwin tar
> $filepath =~ s+^([A-Za-z]):+/cygdrive/\1+;
> }
>
> which does not work if the build environment is a MINGW.
> I have added the patch below,
It sounds as though you're not using the tar.exe that comes with the R
toolset, you're using the MSYS one. Or am I misunderstanding what
you're doing? What does "which tar" give you? (I'm assuming MSYS
provides "which", it's not part of the R toolset.).
I'd like the R toolset to work if someone is running in an MSYS shell,
but I don't want to support arbitrary toolsets, it's just too much work
to try to keep up with changes to them all.
Duncan Murdoch
>
> Yours,
> Steffen
>
> $ diff -u build build.orig
> --- build Fri Jun 29 13:50:16 2007
> +++ build.orig Fri Jun 29 08:51:48 2007
> @@ -47,7 +47,6 @@
> R::Vars::error("R_HOME", "R_EXE");
>
> my $WINDOWS = ($R::Vars::OSTYPE eq "windows");
> -my $MSYS = ( $ENV{OSTYPE} eq "msys" );
>
> my @exclude_patterns = R::Utils::get_exclude_patterns();
>
> @@ -222,14 +221,10 @@
> my $filepath = &file_path($startdir, $filename);
> ## under Windows, need separate Cygwin and Windows versions of path.
> my $origfilepath = $filepath;
> -if ($MSYS) {
> - ## different workwaround for MSYS
> - $filepath =~ s+^([A-Za-z]):+/\1/+;
> -} elsif ($WINDOWS) {
> - ## workaround for paths in Cygwin tar
> - $filepath =~ s+^([A-Za-z]):+/cygdrive/\1+;
> +if($WINDOWS) {
> + ## workaround for paths in Cygwin tar
> + $filepath =~ s+^([A-Za-z]):+/cygdrive/\1+;
> }
> -
> R_system(join(" ",
> ("$tar chf",
>&shell_quote_file_path($filepath),
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build: "Subdirectory 'R' contains invalid file names"
> Henrik Bengtsson writes:
> Hi, I get
> * excluding invalid files from 'R.oo'
> Subdirectory 'R' contains invalid file names:
> attachLocally.Object.Rex Exception.Rex extend.default.Rex
> InternalErrorException.reportBug.Rex Package.Rex Person.Rex Rdoc.Rex
> setMethodS3.Rex StaticFields.Rex
> when running R CMD build in R v2.3.0 devel. I do understand what is
> going on. In my *.R files I keep so called Rdoc comments which in
> their simplest form are Rd code wrapped up in plain comments. These
> are compiled into Rd files written to ../man/ (I do this prior to
> building packages). Rdoc also supports inclusion of other files, e.g.
> @include "Person.Rex" to include example code.
> With this structure I can, when I develop/maintain a package, have
> /R/ as the working directory, modify my *.R files and re-source
> them from within R. Since I keep all my Rd example code in separate
> *.Rex files, I can easily rerun/test these by sourcing them too. I
> find this very convenient.
> In previous versions, the *.Rex files was included when building a
> source distribution of a package. In R v2.3.0 they are excluded.
> However, I would like to distribute the *.Rex files with my
> source-code package too (so I do not have to keep another type of
> source distribution). Note that these files are only needed for
> further development of the package, but *not* to install the package
> from source (since their contents is already incorporated in the Rd
> files). They are also not of interest to the end-user.
Henrik,
I am not sure I fully understand the issue.
The
Note that these files are only needed for further development of the
package
suggests that these files are only needed for your local master sources,
but not in the source package created by R CMD build. If this is the
case, then you really don't have to do anything, because R CMD build
will happily exclude these files, and R CMD check on the .tar.gz will no
longer find them.
Best
-k
> My question is how to incorporate the *.Rex files? Here are some
> ideas, that I would like to have some feedback on:
> 1) Put them in /R/Rex/*.Rex. However, Section 1.1.4 in Writing R
> Extensions suggest that subdirectories of R/ may only(?) be named
> 'windows' or 'unix'.
> 2) Rename them to /R/*.in, cf. Section 1.1.4. Is this the
> purpose of *.in files? Will it have side effects?
> 3) Put the in /inst//*.Rex. This will work, but then they
> will also be install and available in system.file("",
> package=""). Not a big problem, but not what I want.
> 4) To avoid (3), put the in //*.Rex, i.e. at the top level
> directory. Is this allowed? Section 1.1.4 says "Note that [...]
> information files at the top level of the package will not be
> installed". Does this mean that they will be included in the source
> distribution and what about top level directories?
> 5) Put the in /src/*.Rex. Can src/ be used this way too?
> 6) Ask R-core to revert back to pre-R v2.3.0 and allow other files in
> the R/ directory too. Are more people than I interested in this?
> I realize I can test the above by trial and error, but I will still
> not be sure what is the right approach here. Comments/feedback is
> appreciated.
> Thanks
> Henrik
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build: "Subdirectory 'R' contains invalid file names"
Hi,
On 2/10/06, Kurt Hornik <[EMAIL PROTECTED]> wrote:
> > Henrik Bengtsson writes:
>
> > Hi, I get
> > * excluding invalid files from 'R.oo'
> > Subdirectory 'R' contains invalid file names:
> > attachLocally.Object.Rex Exception.Rex extend.default.Rex
> > InternalErrorException.reportBug.Rex Package.Rex Person.Rex Rdoc.Rex
> > setMethodS3.Rex StaticFields.Rex
>
> > when running R CMD build in R v2.3.0 devel. I do understand what is
> > going on. In my *.R files I keep so called Rdoc comments which in
> > their simplest form are Rd code wrapped up in plain comments. These
> > are compiled into Rd files written to ../man/ (I do this prior to
> > building packages). Rdoc also supports inclusion of other files, e.g.
> > @include "Person.Rex" to include example code.
>
> > With this structure I can, when I develop/maintain a package, have
> > /R/ as the working directory, modify my *.R files and re-source
> > them from within R. Since I keep all my Rd example code in separate
> > *.Rex files, I can easily rerun/test these by sourcing them too. I
> > find this very convenient.
>
> > In previous versions, the *.Rex files was included when building a
> > source distribution of a package. In R v2.3.0 they are excluded.
> > However, I would like to distribute the *.Rex files with my
> > source-code package too (so I do not have to keep another type of
> > source distribution). Note that these files are only needed for
> > further development of the package, but *not* to install the package
> > from source (since their contents is already incorporated in the Rd
> > files). They are also not of interest to the end-user.
>
> Henrik,
>
> I am not sure I fully understand the issue.
>
> The
>
>Note that these files are only needed for further development of the
>package
>
> suggests that these files are only needed for your local master sources,
> but not in the source package created by R CMD build. If this is the
> case, then you really don't have to do anything, because R CMD build
> will happily exclude these files, and R CMD check on the .tar.gz will no
> longer find them.
Yes. However, I would like to avoid to keep a version of "local
master sources". Until now, all necessary code in my packages are
available in the *.tar.gz files build by R CMD build. This is
convenient if someone else wants to contribute/add to my package, the
*.tar.gz is all that is needed and it is available on the web. I can
also update my package on request, say, when I travel, without having
access to my "local master sources". Kind of a poor man's
subversion/cvs.
Thanks
Henrik
> Best
> -k
>
> > My question is how to incorporate the *.Rex files? Here are some
> > ideas, that I would like to have some feedback on:
>
> > 1) Put them in /R/Rex/*.Rex. However, Section 1.1.4 in Writing R
> > Extensions suggest that subdirectories of R/ may only(?) be named
> > 'windows' or 'unix'.
>
> > 2) Rename them to /R/*.in, cf. Section 1.1.4. Is this the
> > purpose of *.in files? Will it have side effects?
>
> > 3) Put the in /inst//*.Rex. This will work, but then they
> > will also be install and available in system.file("",
> > package=""). Not a big problem, but not what I want.
>
> > 4) To avoid (3), put the in //*.Rex, i.e. at the top level
> > directory. Is this allowed? Section 1.1.4 says "Note that [...]
> > information files at the top level of the package will not be
> > installed". Does this mean that they will be included in the source
> > distribution and what about top level directories?
>
> > 5) Put the in /src/*.Rex. Can src/ be used this way too?
>
> > 6) Ask R-core to revert back to pre-R v2.3.0 and allow other files in
> > the R/ directory too. Are more people than I interested in this?
>
> > I realize I can test the above by trial and error, but I will still
> > not be sure what is the right approach here. Comments/feedback is
> > appreciated.
>
> > Thanks
>
> > Henrik
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Henrik Bengtsson
Mobile: +46 708 909208 (+1h UTC)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build: "Subdirectory 'R' contains invalid file names"
On Fri, 10 Feb 2006, Henrik Bengtsson wrote:
> Hi,
>
> On 2/10/06, Kurt Hornik <[EMAIL PROTECTED]> wrote:
>>> Henrik Bengtsson writes:
>>
>>> Hi, I get
>>> * excluding invalid files from 'R.oo'
>>> Subdirectory 'R' contains invalid file names:
>>> attachLocally.Object.Rex Exception.Rex extend.default.Rex
>>> InternalErrorException.reportBug.Rex Package.Rex Person.Rex Rdoc.Rex
>>> setMethodS3.Rex StaticFields.Rex
>>
>>> when running R CMD build in R v2.3.0 devel. I do understand what is
>>> going on. In my *.R files I keep so called Rdoc comments which in
>>> their simplest form are Rd code wrapped up in plain comments. These
>>> are compiled into Rd files written to ../man/ (I do this prior to
>>> building packages). Rdoc also supports inclusion of other files, e.g.
>>> @include "Person.Rex" to include example code.
>>
>>> With this structure I can, when I develop/maintain a package, have
>>> /R/ as the working directory, modify my *.R files and re-source
>>> them from within R. Since I keep all my Rd example code in separate
>>> *.Rex files, I can easily rerun/test these by sourcing them too. I
>>> find this very convenient.
>>
>>> In previous versions, the *.Rex files was included when building a
>>> source distribution of a package. In R v2.3.0 they are excluded.
>>> However, I would like to distribute the *.Rex files with my
>>> source-code package too (so I do not have to keep another type of
>>> source distribution). Note that these files are only needed for
>>> further development of the package, but *not* to install the package
>>> from source (since their contents is already incorporated in the Rd
>>> files). They are also not of interest to the end-user.
>>
>> Henrik,
>>
>> I am not sure I fully understand the issue.
>>
>> The
>>
>>Note that these files are only needed for further development of the
>>package
>>
>> suggests that these files are only needed for your local master sources,
>> but not in the source package created by R CMD build. If this is the
>> case, then you really don't have to do anything, because R CMD build
>> will happily exclude these files, and R CMD check on the .tar.gz will no
>> longer find them.
>
> Yes. However, I would like to avoid to keep a version of "local
> master sources". Until now, all necessary code in my packages are
> available in the *.tar.gz files build by R CMD build. This is
> convenient if someone else wants to contribute/add to my package, the
> *.tar.gz is all that is needed and it is available on the web. I can
> also update my package on request, say, when I travel, without having
> access to my "local master sources". Kind of a poor man's
> subversion/cvs.
And inconvenient to everyone who has to pay to download your development
files that they do not need.
Can you not put your master sources on your own web site.
>
> Thanks
>
> Henrik
>
>> Best
>> -k
>>
>>> My question is how to incorporate the *.Rex files? Here are some
>>> ideas, that I would like to have some feedback on:
>>
>>> 1) Put them in /R/Rex/*.Rex. However, Section 1.1.4 in Writing R
>>> Extensions suggest that subdirectories of R/ may only(?) be named
>>> 'windows' or 'unix'.
>>
>>> 2) Rename them to /R/*.in, cf. Section 1.1.4. Is this the
>>> purpose of *.in files? Will it have side effects?
>>
>>> 3) Put the in /inst//*.Rex. This will work, but then they
>>> will also be install and available in system.file("",
>>> package=""). Not a big problem, but not what I want.
>>
>>> 4) To avoid (3), put the in //*.Rex, i.e. at the top level
>>> directory. Is this allowed? Section 1.1.4 says "Note that [...]
>>> information files at the top level of the package will not be
>>> installed". Does this mean that they will be included in the source
>>> distribution and what about top level directories?
>>
>>> 5) Put the in /src/*.Rex. Can src/ be used this way too?
>>
>>> 6) Ask R-core to revert back to pre-R v2.3.0 and allow other files in
>>> the R/ directory too. Are more people than I interested in this?
>>
>>> I realize I can test the above by trial and error, but I will still
>>> not be sure what is the right approach here. Comments/feedback is
>>> appreciated.
>>
>>> Thanks
>>
>>> Henrik
>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
> --
> Henrik Bengtsson
> Mobile: +46 708 909208 (+1h UTC)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailma
[Rd] 'R CMD build' ignoring segfaults occuring during the vignettes creation
Sorry for erroneous subject of my previous post. Here it goes again. Hi, Something else I'd like to report. If a segmentation fault occurs during the "creating vignettes" step, then 'R CMD build' ignores the problem and end up building the source package anyway: /loc/biocbuild/1.9d/R/bin/R CMD build RMAGEML * checking for file 'RMAGEML/DESCRIPTION' ... OK * preparing 'RMAGEML': ... * DONE (RMAGEML) * creating vignettes ...sh: line 1: 8070 Segmentation fault '/loc/biocbuild/1.9d/R/bin/R' --vanilla --no-save --quiet /tmp/Rout656233925 2>&1 OK * cleaning src * removing junk files * checking for LF line-endings in source files * checking for empty or unneeded directories * building 'RMAGEML_2.7.0.tar.gz' 'R CMD check' behaves the same way during the "checking package vignettes" step. I have observed this problem with R 2.3.0 and R 2.4.0 devel (r37925). Best, H. -- Hervé Pagès E-mail: [EMAIL PROTECTED] Phone: (206) 667-5791 Fax: (206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build installing the package to process help pages
Dear All,
If a package has dynamic manual pages (i.e. `\Sexpr{} macros), then R
CMD build installs the package, and (by default) creates the PDF
manual.
I understand that this is needed for build-time Sexprs. Could anyone
explain me why `R CMD build` needs to install the package if all the
Sexprs are install-time and/or render-time? I must be missing
something here.
Thanks much,
Gabor
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build should fail early for old package versions?
Hi all, Today I had an R CMD build that failed while building a vignette because the vignette needs tidyr (>= 1.0, declared in DESCRIPTION Suggests) but my system had a previous version installed. It did not take me too long to figure out the issue (solved by upgrading tidyr) but it would have been even faster / easier if R CMD build failed early, with an error message that says something like "Can not build package XXX because it Suggests: tidyr (>= 1.0) but tidyr 0.8.3 is installed" Is that possible? Toby [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build/check Documentation in Writing R Extensions 1.3
Hi, In WRE section 1.3, there is a note that says "R CMD check and R CMD build run R processes with --vanilla in which none of the user’s startup files are read." While this is true, is it somewhat confusing? When reading quickly, it is possible to read that statement as "running R CMD check is the same thing as running R --vanilla CMD check". It is easy to read WRE and think that your .Rprofile file is being ignored by the parent R process in a call to R CMD check when this is not the case. Bob [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'R CMD build' not cleaning the src/ folder on Windows
This problems seems to be solved in current R 2.12 RC. Thanks! H. On 10/10/2010 10:47 PM, Hervé Pagès wrote: Hi, 'R CMD build' (with R 2.12.0 RC) fails to clean the src/ folder on Windows: D:\biocbld\bbs-2.7-bioc>ls meat/BUS/src BUS.cpp BUS.h D:\biocbld\bbs-2.7-bioc>R\bin\R CMD build meat\BUS * checking for file 'meat\BUS/DESCRIPTION' ... OK * preparing 'BUS': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * creating vignettes ... OK * cleaning src * checking for LF line-endings in source and make files * checking for empty or unneeded directories * building 'BUS_1.5.0.tar.gz' D:\biocbld\bbs-2.7-bioc>tar ztvf BUS_1.5.0.tar.gz --wildcards '*.o' -rwxr--r-- biocbuild2/root 16503 2010-10-10 22:15 BUS/src/BUS.o Packages with a Makefile in src/ don't seem to be affected. This is with R 2.12.0 RC (2010-10-07 r53227). Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build and et_EE.UTF-8 locale -> invalid files (PR#10351)
Full_Name: Ott Toomet Version: 2.6.0, 2.5.x OS: debian etch, lenny Submission from: (NULL) (80.235.63.243) When building a package with 'R CMD build name_of_directory" using "et_EE.UTF-8" locale, I get the following: [EMAIL PROTECTED]:~/tyyq/econ/micEcon$ R CMD build trunk * checking for file 'trunk/DESCRIPTION' ... OK * preparing 'trunk': * checking DESCRIPTION meta-information ... OK * checking whether 'INDEX' is up-to-date ... NO * use '--force' to overwrite the existing 'INDEX' * removing junk files * excluding invalid files from 'micEcon' Subdirectory 'R' contains invalid file names: testConsist.R tobit2fit.R tobit2.R tobit5fit.R translogCalc.R translogDeriv.R translogEst.R translogHessian.R translogMonoRestr.R utils.R vcov-methods.R vcov.selection.R writeFront41in.R Subdirectory 'man' contains invalid file names: testConsist.Rd tobit2fit.Rd translogCalc.Rd translogDeriv.Rd translogEst.Rd translogHessian.Rd triang.Rd vcov-methods.Rd vcov.selection.Rd vecli2m.Rd veclipos.Rd vecli.Rd writeFront41in.Rd * checking for LF line-endings in source and make files * checking for empty or unneeded directories * building 'micEcon_0.3-8.tar.gz' Of course, the package does not work because of removal of these files. It is hard for me to see anything illegal in the listed file names. Even more, everything works perfectly, if I run the command from "C" locale: [EMAIL PROTECTED]:~/tyyq/econ/micEcon$ LC_ALL="C" R CMD build trunk * checking for file 'trunk/DESCRIPTION' ... OK * preparing 'trunk': * checking DESCRIPTION meta-information ... OK * checking whether 'INDEX' is up-to-date ... NO * use '--force' to overwrite the existing 'INDEX' * removing junk files * checking for LF line-endings in source and make files * checking for empty or unneeded directories * building 'micEcon_0.3-8.tar.gz' I can still can directly install from the subdirectory: 'R CMD INSTALL trunk' works well regardless of locale. The micEcon package is available at CRAN. Best, Ott __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build should fail early for old package versions?
On 30/09/2019 5:25 p.m., Toby Hocking wrote: Hi all, Today I had an R CMD build that failed while building a vignette because the vignette needs tidyr (>= 1.0, declared in DESCRIPTION Suggests) but my system had a previous version installed. It did not take me too long to figure out the issue (solved by upgrading tidyr) but it would have been even faster / easier if R CMD build failed early, with an error message that says something like "Can not build package XXX because it Suggests: tidyr (>= 1.0) but tidyr 0.8.3 is installed" Is that possible? If you list a package in Suggests, your package should work (perhaps with some limitations) without the suggested one. Unfortunately for you, the limitation "can't rebuild the vignettes" is incompatible with building the package, but I don't think there's anything you can put in the DESCRIPTION file to indicate this. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignette
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
I noticed that the location of Sweave.sty shipped with
R has changed recently (moved from ${R_HOME}/share/texmf
to ${R_HOME}/share/texmf/tex/latex/). Could that be related
to the problem?
I don't see that problem on platforms other than Windows or
with R < 2.12
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build looking for texi2dvi in the wrong place (R-devel)
R CMD build fails with recent R-devel because it is looking for texi2dvi in /usr/local/bin, but on this system, MacTex has installed it in /usr/bin. $ R CMD build IRanges * checking for file 'IRanges/DESCRIPTION' ... OK * preparing 'IRanges': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to build vignettes * creating vignettes ... ERROR [...] Warning in sub(object$syntax$docexpr, val, chunk[pos[1L]]) : argument 'replacement' has length > 1 and only the first element will be used Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, : Running 'texi2dvi' on 'IRangesOverview.tex' failed. Messages: sh: /usr/local/bin/texi2dvi: No such file or directory Calls: -> texi2pdf -> texi2dvi Execution halted That's with: R Under development (unstable) (2015-01-11 r67421) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.9.5 (Mavericks) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base The same command works without error on: R Under development (unstable) (2014-11-11 r66970) Platform: x86_64-apple-darwin13.4.0 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base Setting options(texi2dvi='/usr/bin/texi2dvi') in my ~/.Rprofile did not help, I suspect because R CMD build runs buildVignettes() in a subprocess started with --vanilla. Creating a symlink from /usr/bin/texi2dvi to /usr/local/bin/texi2dvi gave me a "too many levels of symbolic links" error. Making it a hard link works, but seems like a real hack (what if the executable was not relocatable?). Thanks in advance, Dan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build and et_EE.UTF-8 locale -> invalid files (PR#10351)
[EMAIL PROTECTED] wrote: > Full_Name: Ott Toomet > Version: 2.6.0, 2.5.x > OS: debian etch, lenny > Submission from: (NULL) (80.235.63.243) > > > When building a package with 'R CMD build name_of_directory" using > "et_EE.UTF-8" > locale, I get the following: > > [EMAIL PROTECTED]:~/tyyq/econ/micEcon$ R CMD build trunk > * checking for file 'trunk/DESCRIPTION' ... OK > * preparing 'trunk': > * checking DESCRIPTION meta-information ... OK > * checking whether 'INDEX' is up-to-date ... NO > * use '--force' to overwrite the existing 'INDEX' > * removing junk files > * excluding invalid files from 'micEcon' > Subdirectory 'R' contains invalid file names: > testConsist.R tobit2fit.R tobit2.R tobit5fit.R translogCalc.R > translogDeriv.R translogEst.R translogHessian.R translogMonoRestr.R > utils.R vcov-methods.R vcov.selection.R writeFront41in.R > Subdirectory 'man' contains invalid file names: > testConsist.Rd tobit2fit.Rd translogCalc.Rd translogDeriv.Rd > translogEst.Rd translogHessian.Rd triang.Rd vcov-methods.Rd > vcov.selection.Rd vecli2m.Rd veclipos.Rd vecli.Rd writeFront41in.Rd > * checking for LF line-endings in source and make files > * checking for empty or unneeded directories > * building 'micEcon_0.3-8.tar.gz' > > Of course, the package does not work because of removal of these files. It is > hard for me to see anything illegal in the listed file names. Even more, > everything works perfectly, if I run the command from "C" locale: > > [EMAIL PROTECTED]:~/tyyq/econ/micEcon$ LC_ALL="C" R CMD build trunk > * checking for file 'trunk/DESCRIPTION' ... OK > * preparing 'trunk': > * checking DESCRIPTION meta-information ... OK > * checking whether 'INDEX' is up-to-date ... NO > * use '--force' to overwrite the existing 'INDEX' > * removing junk files > * checking for LF line-endings in source and make files > * checking for empty or unneeded directories > * building 'micEcon_0.3-8.tar.gz' > > I can still can directly install from the subdirectory: 'R CMD INSTALL trunk' > works well regardless of locale. > > The micEcon package is available at CRAN. > > I'm not sure what to do about it, but I'm 99% sure that what is biting you is that Estonian sorts z before t, and something somewhere is using a regexp containing a-zA-Z. Presumably, R CMD build should just standardize the locale to "C" internally (it is a right pain to change all instances of a-zA-Z to [[:alpha:]], most likely not even possible to do it portably, and at any rate, packages should not come out different depending on the locale in which it was built.) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
On 11/09/2010 12:52 AM, Hervé Pagès wrote:
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignette
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.
The reorg is described in this NEWS item:
* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).
Duncan Murdoch
I noticed that the location of Sweave.sty shipped with
R has changed recently (moved from ${R_HOME}/share/texmf
to ${R_HOME}/share/texmf/tex/latex/). Could that be related
to the problem?
I don't see that problem on platforms other than Windows or
with R < 2.12
Thanks,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Hi Duncan,
On 09/11/2010 03:56 AM, Duncan Murdoch wrote:
On 11/09/2010 12:52 AM, Hervé Pagès wrote:
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignett
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.
The reorg is described in this NEWS item:
* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).
Before this reorg, the package maintainer didn't have to care about
where to find things in R_HOME/share/texmf. 'R CMD build' would just
find them by setting the TEXINPUTS envir variable appropriately (and
then commands in the inst/doc/Makefile file would find them too).
This reorg was checked in svn as rev 52256. I see the following
adjustments to TEXINPUTS:
** On Unix (src/scripts/Rcmd.in file):
-## Append 'share/texmf' to TeX's input search path.
-if test -z "$TEXINPUTS}"; then
- TEXINPUTS=".:${R_SHARE_DIR}/texmf:"
+## Append 'share/texmf/...' to TeX's input search path.
+if test -z "${TEXINPUTS}"; then
+ TEXINPUTS=".:${R_SHARE_DIR}/texmf/tex/latex:"
else
- TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf:"
+ TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf/tex/latex:"
fi
export TEXINPUTS
** On Windows (src/gnuwin32/fixed/etc/Rcmd_environ file):
-TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf;
+TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf/tex/latex;
The path seems to have been adjusted correctly. So my question is:
why isn't this working on Windows for packages that use a Makefile?
Thanks,
H.
Duncan Murdoch
I noticed that the location of Sweave.sty shipped with
R has changed recently (moved from ${R_HOME}/share/texmf
to ${R_HOME}/share/texmf/tex/latex/). Could that be related
to the problem?
I don't see that problem on platforms other than Windows or
with R < 2.12
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
On 12/09/2010 12:49 AM, Hervé Pagès wrote:
Hi Duncan,
On 09/11/2010 03:56 AM, Duncan Murdoch wrote:
On 11/09/2010 12:52 AM, Hervé Pagès wrote:
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignett
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.
The reorg is described in this NEWS item:
* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).
Before this reorg, the package maintainer didn't have to care about
where to find things in R_HOME/share/texmf. 'R CMD build' would just
find them by setting the TEXINPUTS envir variable appropriately (and
then commands in the inst/doc/Makefile file would find them too).
This reorg was checked in svn as rev 52256. I see the following
adjustments to TEXINPUTS:
** On Unix (src/scripts/Rcmd.in file):
-## Append 'share/texmf' to TeX's input search path.
-if test -z "$TEXINPUTS}"; then
- TEXINPUTS=".:${R_SHARE_DIR}/texmf:"
+## Append 'share/texmf/...' to TeX's input search path.
+if test -z "${TEXINPUTS}"; then
+ TEXINPUTS=".:${R_SHARE_DIR}/texmf/tex/latex:"
else
- TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf:"
+ TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf/tex/latex:"
fi
export TEXINPUTS
** On Windows (src/gnuwin32/fixed/etc/Rcmd_environ file):
-TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf;
+TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf/tex/latex;
The path seems to have been adjusted correctly. So my question is:
why isn't this working on Windows for packages that use a Makefile?
I don't know. My first assumption would that something in the Makefile
is wrong, but since you don't give any examples, I can't check.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Hi Duncan
wouldn't it be possible that by default the Sweave.sty in share/texmf is
found by 'R CMD build' for use by package vignettes without manual
intervention?
AfaIcs this is also how it worked in the past.
Best wishes
Wolfgang
On Sep/11/10 12:56 PM, Duncan Murdoch wrote:
On 11/09/2010 12:52 AM, Hervé Pagès wrote:
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignette
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.
The reorg is described in this NEWS item:
* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).
Duncan Murdoch
I noticed that the location of Sweave.sty shipped with
R has changed recently (moved from ${R_HOME}/share/texmf
to ${R_HOME}/share/texmf/tex/latex/). Could that be related
to the problem?
I don't see that problem on platforms other than Windows or
with R < 2.12
Thanks,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Wolfgang Huber
EMBL
http://www.embl.de/research/units/genome_biology/huber
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
On 12/09/2010 12:04 PM, Wolfgang Huber wrote:
Hi Duncan
wouldn't it be possible that by default the Sweave.sty in share/texmf is
found by 'R CMD build' for use by package vignettes without manual
intervention?
Yes, it does work that way. What Hervé is talking about are cases where
people use Makefiles to bypass the normal process.
Duncan Murdoch
AfaIcs this is also how it worked in the past.
Best wishes
Wolfgang
On Sep/11/10 12:56 PM, Duncan Murdoch wrote:
On 11/09/2010 12:52 AM, Hervé Pagès wrote:
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignette
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.
The reorg is described in this NEWS item:
* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).
Duncan Murdoch
I noticed that the location of Sweave.sty shipped with
R has changed recently (moved from ${R_HOME}/share/texmf
to ${R_HOME}/share/texmf/tex/latex/). Could that be related
to the problem?
I don't see that problem on platforms other than Windows or
with R < 2.12
Thanks,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Hi Duncan,
On 09/12/2010 05:07 AM, Duncan Murdoch wrote:
On 12/09/2010 12:49 AM, Hervé Pagès wrote:
Hi Duncan,
On 09/11/2010 03:56 AM, Duncan Murdoch wrote:
On 11/09/2010 12:52 AM, Hervé Pagès wrote:
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignett
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.
The reorg is described in this NEWS item:
* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).
Before this reorg, the package maintainer didn't have to care about
where to find things in R_HOME/share/texmf. 'R CMD build' would just
find them by setting the TEXINPUTS envir variable appropriately (and
then commands in the inst/doc/Makefile file would find them too).
This reorg was checked in svn as rev 52256. I see the following
adjustments to TEXINPUTS:
** On Unix (src/scripts/Rcmd.in file):
-## Append 'share/texmf' to TeX's input search path.
-if test -z "$TEXINPUTS}"; then
- TEXINPUTS=".:${R_SHARE_DIR}/texmf:"
+## Append 'share/texmf/...' to TeX's input search path.
+if test -z "${TEXINPUTS}"; then
+ TEXINPUTS=".:${R_SHARE_DIR}/texmf/tex/latex:"
else
- TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf:"
+ TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf/tex/latex:"
fi
export TEXINPUTS
** On Windows (src/gnuwin32/fixed/etc/Rcmd_environ file):
-TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf;
+TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf/tex/latex;
The path seems to have been adjusted correctly. So my question is:
why isn't this working on Windows for packages that use a Makefile?
I don't know. My first assumption would that something in the Makefile
is wrong, but since you don't give any examples, I can't check.
There are 8 Bioconductor packages failing to build on Windows
because of this problem. They have a Makefile in inst/doc/ that
calls 'pdflatex' or 'texi2dvi --pdf' on to convert
.tex into .pdf. They don't
have Sweave.sty in inst/doc/ (other packages use the same kind of
Makefile and are building ok because they have a copy of Sweave.sty
in inst/doc/).
For example, here is the content of adSplit/inst/doc/Makefile:
all:pdf clean
pdf:tr_2005_02.tex
epstopdf splitSet.eps
pdflatex tr_2005_02
pdflatex tr_2005_02
pdflatex tr_2005_02
clean:
rm -f *.aux *.eps *.log *.out *.tex *.toc
rm -f Rplots.ps splitSet.pdf tr_2005_02-*
The 7 other packages use similar Makefile. As I said before, they
all used to build ok before the R_HOME/share/texmf reorg. They still
build ok on non-Windows machines. Thanks!
H.
Duncan Murdoch
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Hervé Pagès wrote:
Hi Duncan,
On 09/12/2010 05:07 AM, Duncan Murdoch wrote:
On 12/09/2010 12:49 AM, Hervé Pagès wrote:
Hi Duncan,
On 09/11/2010 03:56 AM, Duncan Murdoch wrote:
On 11/09/2010 12:52 AM, Hervé Pagès wrote:
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignett
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.
The reorg is described in this NEWS item:
* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).
Before this reorg, the package maintainer didn't have to care about
where to find things in R_HOME/share/texmf. 'R CMD build' would just
find them by setting the TEXINPUTS envir variable appropriately (and
then commands in the inst/doc/Makefile file would find them too).
This reorg was checked in svn as rev 52256. I see the following
adjustments to TEXINPUTS:
** On Unix (src/scripts/Rcmd.in file):
-## Append 'share/texmf' to TeX's input search path.
-if test -z "$TEXINPUTS}"; then
- TEXINPUTS=".:${R_SHARE_DIR}/texmf:"
+## Append 'share/texmf/...' to TeX's input search path.
+if test -z "${TEXINPUTS}"; then
+ TEXINPUTS=".:${R_SHARE_DIR}/texmf/tex/latex:"
else
- TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf:"
+ TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf/tex/latex:"
fi
export TEXINPUTS
** On Windows (src/gnuwin32/fixed/etc/Rcmd_environ file):
-TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf;
+TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf/tex/latex;
The path seems to have been adjusted correctly. So my question is:
why isn't this working on Windows for packages that use a Makefile?
I don't know. My first assumption would that something in the Makefile
is wrong, but since you don't give any examples, I can't check.
There are 8 Bioconductor packages failing to build on Windows
because of this problem. They have a Makefile in inst/doc/ that
calls 'pdflatex' or 'texi2dvi --pdf' on to convert
.tex into .pdf. They don't
have Sweave.sty in inst/doc/ (other packages use the same kind of
Makefile and are building ok because they have a copy of Sweave.sty
in inst/doc/).
For example, here is the content of adSplit/inst/doc/Makefile:
all:pdf clean
pdf:tr_2005_02.tex
epstopdf splitSet.eps
pdflatex tr_2005_02
pdflatex tr_2005_02
pdflatex tr_2005_02
clean:
rm -f *.aux *.eps *.log *.out *.tex *.toc
rm -f Rplots.ps splitSet.pdf tr_2005_02-*
The 7 other packages use similar Makefile. As I said before, they
all used to build ok before the R_HOME/share/texmf reorg. They still
build ok on non-Windows machines. Thanks!
H.
On Windows using MikTeX, we put a -I option on the command line to point
to the input directory. If you don't want to do that, you can use "R
CMD texify --pdf" instead of "pdflatex"; it will try to determine the
appropriate command line based on the platform.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
On 13/09/2010 2:38 PM, Hervé Pagès wrote:
On 09/13/2010 03:34 AM, Duncan Murdoch wrote:
> Hervé Pagès wrote:
>> Hi Duncan,
>>
>> On 09/12/2010 05:07 AM, Duncan Murdoch wrote:
>>> On 12/09/2010 12:49 AM, Hervé Pagès wrote:
Hi Duncan,
On 09/11/2010 03:56 AM, Duncan Murdoch wrote:
> On 11/09/2010 12:52 AM, Hervé Pagès wrote:
>> Hi,
>>
>> I found the following problem with recent R-devel
>> (2010-08-26 r52817) on Windows (32-bit and 64-bit):
>> 'R CMD build' gets stalled during vignett
>> creation for packages that have a Makefile in/inst/doc.
>>
>> It seems that the problem is that the commands used in the
>> Makefile for converting .tex to .pdf are not able to locate
>> the Sweave.sty file anymore (if I drop this file to
>> /inst/doc, then the problem goes away).
> This sounds like a problem that only the package maintainer could
> address. Presumably it will be temporary: once they adjust to the new
> organization of the share/texmf directory, things will be fine again.
>
> The reorg is described in this NEWS item:
>
> * Directory R_HOME/share/texmf now follows the TDS conventions, so
> can be set as a texmf tree ('root directory' in MiKTeX parlance).
Before this reorg, the package maintainer didn't have to care about
where to find things in R_HOME/share/texmf. 'R CMD build' would just
find them by setting the TEXINPUTS envir variable appropriately (and
then commands in the inst/doc/Makefile file would find them too).
This reorg was checked in svn as rev 52256. I see the following
adjustments to TEXINPUTS:
** On Unix (src/scripts/Rcmd.in file):
-## Append 'share/texmf' to TeX's input search path.
-if test -z "$TEXINPUTS}"; then
- TEXINPUTS=".:${R_SHARE_DIR}/texmf:"
+## Append 'share/texmf/...' to TeX's input search path.
+if test -z "${TEXINPUTS}"; then
+ TEXINPUTS=".:${R_SHARE_DIR}/texmf/tex/latex:"
else
- TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf:"
+ TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf/tex/latex:"
fi
export TEXINPUTS
** On Windows (src/gnuwin32/fixed/etc/Rcmd_environ file):
-TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf;
+TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf/tex/latex;
The path seems to have been adjusted correctly. So my question is:
why isn't this working on Windows for packages that use a Makefile?
>>> I don't know. My first assumption would that something in the Makefile
>>> is wrong, but since you don't give any examples, I can't check.
>>
>> There are 8 Bioconductor packages failing to build on Windows
>> because of this problem. They have a Makefile in inst/doc/ that
>> calls 'pdflatex' or 'texi2dvi --pdf' on to convert
>> .tex into.pdf. They don't
>> have Sweave.sty in inst/doc/ (other packages use the same kind of
>> Makefile and are building ok because they have a copy of Sweave.sty
>> in inst/doc/).
>>
>> For example, here is the content of adSplit/inst/doc/Makefile:
>>
>> all: pdf clean
>>
>> pdf: tr_2005_02.tex
>> epstopdf splitSet.eps
>> pdflatex tr_2005_02
>> pdflatex tr_2005_02
>> pdflatex tr_2005_02
>>
>> clean:
>> rm -f *.aux *.eps *.log *.out *.tex *.toc
>> rm -f Rplots.ps splitSet.pdf tr_2005_02-*
>>
>> The 7 other packages use similar Makefile. As I said before, they
>> all used to build ok before the R_HOME/share/texmf reorg. They still
>> build ok on non-Windows machines. Thanks!
>>
>> H.
>
> On Windows using MikTeX, we put a -I option on the command line to point
> to the input directory. If you don't want to do that, you can use "R CMD
> texify --pdf" instead of "pdflatex"; it will try to determine the
> appropriate command line based on the platform.
Yes I can use 'R CMD some_command' instead of just 'some_command' in the
Makefile so 'some_command' sees the TEXINPUTS variable and that solves
the problem. But when I call 'R CMD build', shouldn't 'make' and its
child processes ('pdflatex', 'texify', etc...) already see TEXINPUTS?
Why do I need to call the commands in the Makefile thru R CMD again
in order to see TEXINPUTS?
Thanks for suggesting workarounds but don't you think there is a real
problem?
As I said, we don't use TEXINPUTS on Windows, we use the command line
version. I didn't write the code, so I don't know why there's the
difference, but I assume there's a reason for it, and presumably the
reason is that relying on TEXINPUTS doesn't work.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
On 09/13/2010 03:34 AM, Duncan Murdoch wrote:
Hervé Pagès wrote:
Hi Duncan,
On 09/12/2010 05:07 AM, Duncan Murdoch wrote:
On 12/09/2010 12:49 AM, Hervé Pagès wrote:
Hi Duncan,
On 09/11/2010 03:56 AM, Duncan Murdoch wrote:
On 11/09/2010 12:52 AM, Hervé Pagès wrote:
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignett
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
This sounds like a problem that only the package maintainer could
address. Presumably it will be temporary: once they adjust to the new
organization of the share/texmf directory, things will be fine again.
The reorg is described in this NEWS item:
* Directory R_HOME/share/texmf now follows the TDS conventions, so
can be set as a texmf tree ('root directory' in MiKTeX parlance).
Before this reorg, the package maintainer didn't have to care about
where to find things in R_HOME/share/texmf. 'R CMD build' would just
find them by setting the TEXINPUTS envir variable appropriately (and
then commands in the inst/doc/Makefile file would find them too).
This reorg was checked in svn as rev 52256. I see the following
adjustments to TEXINPUTS:
** On Unix (src/scripts/Rcmd.in file):
-## Append 'share/texmf' to TeX's input search path.
-if test -z "$TEXINPUTS}"; then
- TEXINPUTS=".:${R_SHARE_DIR}/texmf:"
+## Append 'share/texmf/...' to TeX's input search path.
+if test -z "${TEXINPUTS}"; then
+ TEXINPUTS=".:${R_SHARE_DIR}/texmf/tex/latex:"
else
- TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf:"
+ TEXINPUTS=".:${TEXINPUTS}:${R_SHARE_DIR}/texmf/tex/latex:"
fi
export TEXINPUTS
** On Windows (src/gnuwin32/fixed/etc/Rcmd_environ file):
-TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf;
+TEXINPUTS=.;${TEXINPUTS};${R_SHARE_DIR}/texmf/tex/latex;
The path seems to have been adjusted correctly. So my question is:
why isn't this working on Windows for packages that use a Makefile?
I don't know. My first assumption would that something in the Makefile
is wrong, but since you don't give any examples, I can't check.
There are 8 Bioconductor packages failing to build on Windows
because of this problem. They have a Makefile in inst/doc/ that
calls 'pdflatex' or 'texi2dvi --pdf' on to convert
.tex into .pdf. They don't
have Sweave.sty in inst/doc/ (other packages use the same kind of
Makefile and are building ok because they have a copy of Sweave.sty
in inst/doc/).
For example, here is the content of adSplit/inst/doc/Makefile:
all: pdf clean
pdf: tr_2005_02.tex
epstopdf splitSet.eps
pdflatex tr_2005_02
pdflatex tr_2005_02
pdflatex tr_2005_02
clean:
rm -f *.aux *.eps *.log *.out *.tex *.toc
rm -f Rplots.ps splitSet.pdf tr_2005_02-*
The 7 other packages use similar Makefile. As I said before, they
all used to build ok before the R_HOME/share/texmf reorg. They still
build ok on non-Windows machines. Thanks!
H.
On Windows using MikTeX, we put a -I option on the command line to point
to the input directory. If you don't want to do that, you can use "R CMD
texify --pdf" instead of "pdflatex"; it will try to determine the
appropriate command line based on the platform.
Yes I can use 'R CMD some_command' instead of just 'some_command' in the
Makefile so 'some_command' sees the TEXINPUTS variable and that solves
the problem. But when I call 'R CMD build', shouldn't 'make' and its
child processes ('pdflatex', 'texify', etc...) already see TEXINPUTS?
Why do I need to call the commands in the Makefile thru R CMD again
in order to see TEXINPUTS?
Thanks for suggesting workarounds but don't you think there is a real
problem?
H.
Duncan Murdoch
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Duncan, On 09/13/2010 11:47 AM, Duncan Murdoch wrote: On 13/09/2010 2:38 PM, Hervé Pagès wrote: [...] Thanks for suggesting workarounds but don't you think there is a real problem? As I said, we don't use TEXINPUTS on Windows, we use the command line version. I didn't write the code, so I don't know why there's the difference, but I assume there's a reason for it, and presumably the reason is that relying on TEXINPUTS doesn't work. This is fixed in current R-devel. Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
On 14/09/2010 2:46 PM, Hervé Pagès wrote: Duncan, On 09/13/2010 11:47 AM, Duncan Murdoch wrote: > On 13/09/2010 2:38 PM, Hervé Pagès wrote: [...] >> Thanks for suggesting workarounds but don't you think there is a real >> problem? >> > > As I said, we don't use TEXINPUTS on Windows, we use the command line > version. I didn't write the code, so I don't know why there's the > difference, but I assume there's a reason for it, and presumably the > reason is that relying on TEXINPUTS doesn't work. This is fixed in current R-devel. That explains my confusion. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Oops, sorry for the noise but after looking at today's BioC build/check results, I realize the problem is still here. At least for some of the 8 packages that had an 'R CMD build' timeout because of the Sweave.sty file not being found. I just happened to run 'R CMD build' by hands yesterday on a package for which the problem is gone so I went ahead and started to sing victory... not so fast! I'm gonna post with a new subject and give more details. H. On 09/14/2010 11:48 AM, Duncan Murdoch wrote: On 14/09/2010 2:46 PM, Hervé Pagès wrote: Duncan, On 09/13/2010 11:47 AM, Duncan Murdoch wrote: > On 13/09/2010 2:38 PM, Hervé Pagès wrote: [...] >> Thanks for suggesting workarounds but don't you think there is a real >> problem? >> > > As I said, we don't use TEXINPUTS on Windows, we use the command line > version. I didn't write the code, so I don't know why there's the > difference, but I assume there's a reason for it, and presumably the > reason is that relying on TEXINPUTS doesn't work. This is fixed in current R-devel. That explains my confusion. Duncan Murdoch -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build processes inst/doc/Makefile only if there are vignette files?
Hi, in Section 'Writing package vignettes' of 'Writing R Extensions' it says: "Whenever a Makefile is found, then R CMD build will try to run make after the Sweave runs, so PDF manuals can be created from arbitrary source formats (plain LaTeX files, ...). [...] Note that the make step is executed even if there are no files in Sweave format, [...]". In my package, inst/doc/ file contains two files: Makefile, and report.tex. However, when running 'Rcmd build' on Windows with R v2.13.0 alpha (2011-03-27 r55091) I can only get 'make' to run (process inst/doc/Makefile) if I add a inst/doc/dummy.Rnw file, otherwise nothing happens. My Makefile contains: all: pdf pdf: report.tex texi2dvi --pdf report.tex clean: rm dummy.Rnw dummy.tex rm *.aux *.log *.toc Is it really necessary to add dummy.Rnw? Am I missing something? /Henrik > sessionInfo() R version 2.13.0 alpha (2011-03-27 r55091) Platform: x86_64-pc-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.13.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build - will reset the timestamps of all files in a package
Dear developers, I wonder why (R version 2.13.0 and after) the command "R CMD build" sets the timestamp of all files in the package to the current date/time. This seems not to be mentioned in the list of changes. Is there an option to avoid this? Best regards, Valentin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build then check fails on R-devel due to serialization version
Hi, Since yesterday I'm seeing `R CMD check --as-cran` failures on the R-devel daily build (specifically, R Under development (unstable) (2018-01-09 r74100)) for multiple packages: * checking serialized R objects in the sources ... WARNING Found file(s) with version 3 serialization: ‘build/vignette.rds’ Such files are only readable in R >= 3.5.0. Recreate them with R < 3.5.0 or save(version = 2) or saveRDS(version = 2) as appropriate As far as I can tell, revision 74099 (https://github.com/wch/r-source/commit/d9530001046a582ff6a43ca834d6c3586abd0a97), which changes the default serialization format to 3, clashes with revision 73973 (https://github.com/wch/r-source/commit/885764eb74f2211a547b13727f2ecc5470c3dd00), which checks that serialized R objects are _not_ version 3. It seems that with the current development version of R, if you `R CMD build` and then run `R CMD check --as-cran` on the built package, it will fail. Neal __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build looking for texi2dvi in the wrong place (R-devel)
Dan, On Jan 12, 2015, at 7:50 PM, Dan Tenenbaum wrote: > R CMD build fails with recent R-devel because it is looking for texi2dvi in > /usr/local/bin, but on this system, MacTex has installed it in /usr/bin. > No, you're looking at the wrong package - texi2dvi comes from texinfo which is now mandatory in version 5.2+ located in /usr/local since OS X comes with an old version. You should install it from http://r.research.att.com/libs/texinfo-5.2-darwin10.tar.gz Cheers, Simon > $ R CMD build IRanges > * checking for file 'IRanges/DESCRIPTION' ... OK > * preparing 'IRanges': > * checking DESCRIPTION meta-information ... OK > * cleaning src > * installing the package to build vignettes > * creating vignettes ... ERROR > [...] > Warning in sub(object$syntax$docexpr, val, chunk[pos[1L]]) : > argument 'replacement' has length > 1 and only the first element will be used > Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, : > Running 'texi2dvi' on 'IRangesOverview.tex' failed. > Messages: > sh: /usr/local/bin/texi2dvi: No such file or directory > Calls: -> texi2pdf -> texi2dvi > Execution halted > > That's with: > > R Under development (unstable) (2015-01-11 r67421) > Platform: x86_64-apple-darwin13.4.0 (64-bit) > Running under: OS X 10.9.5 (Mavericks) > > locale: > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > The same command works without error on: > > R Under development (unstable) (2014-11-11 r66970) > Platform: x86_64-apple-darwin13.4.0 (64-bit) > > locale: > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > Setting > options(texi2dvi='/usr/bin/texi2dvi') > > in my ~/.Rprofile did not help, I suspect because R CMD build runs > buildVignettes() in a subprocess started with --vanilla. Creating a symlink > from /usr/bin/texi2dvi to /usr/local/bin/texi2dvi gave me a "too many levels > of symbolic links" error. Making it a hard link works, but seems like a real > hack (what if the executable was not relocatable?). > > Thanks in advance, > Dan > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build looking for texi2dvi in the wrong place (R-devel)
- Original Message - > From: "Simon Urbanek" > To: "Dan Tenenbaum" > Cc: "R-devel" > Sent: Monday, January 12, 2015 5:50:35 PM > Subject: Re: [Rd] R CMD build looking for texi2dvi in the wrong place > (R-devel) > > Dan, > > On Jan 12, 2015, at 7:50 PM, Dan Tenenbaum > wrote: > > > R CMD build fails with recent R-devel because it is looking for > > texi2dvi in /usr/local/bin, but on this system, MacTex has > > installed it in /usr/bin. > > > > No, you're looking at the wrong package - texi2dvi comes from texinfo > which is now mandatory in version 5.2+ located in /usr/local since > OS X comes with an old version. You should install it from > > http://r.research.att.com/libs/texinfo-5.2-darwin10.tar.gz > Thanks, was there an announcement that I missed about this and if so, where was it? Dan > Cheers, > Simon > > > > > $ R CMD build IRanges > > * checking for file 'IRanges/DESCRIPTION' ... OK > > * preparing 'IRanges': > > * checking DESCRIPTION meta-information ... OK > > * cleaning src > > * installing the package to build vignettes > > * creating vignettes ... ERROR > > [...] > > Warning in sub(object$syntax$docexpr, val, chunk[pos[1L]]) : > > argument 'replacement' has length > 1 and only the first element > > will be used > > Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = > > quiet, : > > Running 'texi2dvi' on 'IRangesOverview.tex' failed. > > Messages: > > sh: /usr/local/bin/texi2dvi: No such file or directory > > Calls: -> texi2pdf -> texi2dvi > > Execution halted > > > > That's with: > > > > R Under development (unstable) (2015-01-11 r67421) > > Platform: x86_64-apple-darwin13.4.0 (64-bit) > > Running under: OS X 10.9.5 (Mavericks) > > > > locale: > > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 > > > > attached base packages: > > [1] stats graphics grDevices utils datasets methods > > base > > > > The same command works without error on: > > > > R Under development (unstable) (2014-11-11 r66970) > > Platform: x86_64-apple-darwin13.4.0 (64-bit) > > > > locale: > > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 > > > > attached base packages: > > [1] stats graphics grDevices utils datasets methods > > base > > > > Setting > > options(texi2dvi='/usr/bin/texi2dvi') > > > > in my ~/.Rprofile did not help, I suspect because R CMD build runs > > buildVignettes() in a subprocess started with --vanilla. Creating > > a symlink from /usr/bin/texi2dvi to /usr/local/bin/texi2dvi gave > > me a "too many levels of symbolic links" error. Making it a hard > > link works, but seems like a real hack (what if the executable was > > not relocatable?). > > > > Thanks in advance, > > Dan > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build looking for texi2dvi in the wrong place (R-devel)
On 12/01/2015 6:26 PM, Dan Tenenbaum wrote: > > > - Original Message - >> From: "Simon Urbanek" >> To: "Dan Tenenbaum" >> Cc: "R-devel" >> Sent: Monday, January 12, 2015 5:50:35 PM >> Subject: Re: [Rd] R CMD build looking for texi2dvi in the wrong place >> (R-devel) >> >> Dan, >> >> On Jan 12, 2015, at 7:50 PM, Dan Tenenbaum >> wrote: >> >>> R CMD build fails with recent R-devel because it is looking for >>> texi2dvi in /usr/local/bin, but on this system, MacTex has >>> installed it in /usr/bin. >>> >> >> No, you're looking at the wrong package - texi2dvi comes from texinfo >> which is now mandatory in version 5.2+ located in /usr/local since >> OS X comes with an old version. You should install it from >> >> http://r.research.att.com/libs/texinfo-5.2-darwin10.tar.gz >> > > Thanks, was there an announcement that I missed about this and if so, where > was it? It has been in the NEWS file since Jan 6. You can see it there, and would have seen it announced here: http://developer.r-project.org/blosxom.cgi/R-devel/2015/01/06#n2015-01-06 Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build looking for texi2dvi in the wrong place (R-devel)
- Original Message - > From: "Duncan Murdoch" > To: "Dan Tenenbaum" , "Simon Urbanek" > > Cc: "R-devel" > Sent: Monday, January 12, 2015 8:40:07 PM > Subject: Re: [Rd] R CMD build looking for texi2dvi in the wrong place > (R-devel) > > On 12/01/2015 6:26 PM, Dan Tenenbaum wrote: > > > > > > - Original Message - > >> From: "Simon Urbanek" > >> To: "Dan Tenenbaum" > >> Cc: "R-devel" > >> Sent: Monday, January 12, 2015 5:50:35 PM > >> Subject: Re: [Rd] R CMD build looking for texi2dvi in the wrong > >> place (R-devel) > >> > >> Dan, > >> > >> On Jan 12, 2015, at 7:50 PM, Dan Tenenbaum > >> > >> wrote: > >> > >>> R CMD build fails with recent R-devel because it is looking for > >>> texi2dvi in /usr/local/bin, but on this system, MacTex has > >>> installed it in /usr/bin. > >>> > >> > >> No, you're looking at the wrong package - texi2dvi comes from > >> texinfo > >> which is now mandatory in version 5.2+ located in /usr/local since > >> OS X comes with an old version. You should install it from > >> > >> http://r.research.att.com/libs/texinfo-5.2-darwin10.tar.gz > >> > > > > Thanks, was there an announcement that I missed about this and if > > so, where was it? > > It has been in the NEWS file since Jan 6. You can see it there, and > would have seen it announced here: > > http://developer.r-project.org/blosxom.cgi/R-devel/2015/01/06#n2015-01-06 > Thanks, I'll subscribe to these feeds. Dan > Duncan Murdoch > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build when the package name is different from the directory name
Hi,
I was really happy when I saw that in R version 2.3.0 "R CMD check" works for
packages whose package name is different from the directory name in which it
is located (see http://cran.r-project.org/src/base/NEWS).
Now, I can have branches of my packages in directories like
"[...]/branches//", while I had to use
"[...]/branches//" before.
"R CMD check " runs as expected but when I build the package
with "R CMD build ", the file name of the source package is
"_-.tar.gz" (and not "_-.tar.gz"). Furthermore the base directory
inside the .tar.gz archive is "" (and not "").
Is there a possibility to tell "R CMD build" to use the correct package name
("R CMD check" uses the correct package name.) Can you change the (default)
behaviour of "R CMD build" in future releases?
Do I have to change the file name and/or the name of the base directory before
uploading the package to CRAN?
I use R version 2.3.1 (2006-06-01) on i686-pc-linux-gnu.
The same happens with R version 2.4.0 RC.
Thanks,
Arne
--
Arne Henningsen
Department of Agricultural Economics
University of Kiel
Olshausenstr. 40
D-24098 Kiel (Germany)
Tel: +49-431-880 4445
Fax: +49-431-880 1397
[EMAIL PROTECTED]
http://www.uni-kiel.de/agrarpol/ahenningsen/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build processes inst/doc/Makefile only if there are vignette files?
What R CMD build (and check) does is to call tools::buildVignettes. That has been true for a while, and buildVignettes() returns if no vignettes are found. The docs are out-of-date. My view is that you are misusing inst/doc: it is intended *only* for files which are going to be installed and hence report.tex should not really be there. So you should be doing this in another source directory and copying report.pdf to inst/doc. Use configure to arrange this. Shortly vignettes to be built will be moved out of inst/doc. On Tue, 29 Mar 2011, Henrik Bengtsson wrote: Hi, in Section 'Writing package vignettes' of 'Writing R Extensions' it says: "Whenever a Makefile is found, then R CMD build will try to run make after the Sweave runs, so PDF manuals can be created from arbitrary source formats (plain LaTeX files, ...). [...] Note that the make step is executed even if there are no files in Sweave format, [...]". In my package, inst/doc/ file contains two files: Makefile, and report.tex. However, when running 'Rcmd build' on Windows with R v2.13.0 alpha (2011-03-27 r55091) I can only get 'make' to run (process inst/doc/Makefile) if I add a inst/doc/dummy.Rnw file, otherwise nothing happens. My Makefile contains: all: pdf pdf: report.tex texi2dvi --pdf report.tex clean: rm dummy.Rnw dummy.tex rm *.aux *.log *.toc Is it really necessary to add dummy.Rnw? Am I missing something? /Henrik sessionInfo() R version 2.13.0 alpha (2011-03-27 r55091) Platform: x86_64-pc-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.13.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build processes inst/doc/Makefile only if there are vignette files?
On 11-03-30 01:55 AM, Prof Brian Ripley wrote: What R CMD build (and check) does is to call tools::buildVignettes. That has been true for a while, and buildVignettes() returns if no vignettes are found. The docs are out-of-date. My view is that you are misusing inst/doc: it is intended *only* for files which are going to be installed and hence report.tex should not really be there. So you should be doing this in another source directory and copying report.pdf to inst/doc. Use configure to arrange this. Shortly vignettes to be built will be moved out of inst/doc. Could you please elaborate on this? I just found this in the NEWS for R 2.14.0: o The preferred location for vignette sources is now the directory ‘vignettes’ and not ‘inst/doc’: R CMD build will now re-build vignettes in ‘vignettes’ and copy the ‘.Rnw’ (etc) files and the corresponding PDFs to ‘inst/doc’. Sounds like an important move. What are the long term plans: keep both inst/doc/ and vignettes/ as places for vignettes to be built? Or drop inst/doc/ at some point? Thanks! H. On Tue, 29 Mar 2011, Henrik Bengtsson wrote: Hi, in Section 'Writing package vignettes' of 'Writing R Extensions' it says: "Whenever a Makefile is found, then R CMD build will try to run make after the Sweave runs, so PDF manuals can be created from arbitrary source formats (plain LaTeX files, ...). [...] Note that the make step is executed even if there are no files in Sweave format, [...]". In my package, inst/doc/ file contains two files: Makefile, and report.tex. However, when running 'Rcmd build' on Windows with R v2.13.0 alpha (2011-03-27 r55091) I can only get 'make' to run (process inst/doc/Makefile) if I add a inst/doc/dummy.Rnw file, otherwise nothing happens. My Makefile contains: all: pdf pdf: report.tex texi2dvi --pdf report.tex clean: rm dummy.Rnw dummy.tex rm *.aux *.log *.toc Is it really necessary to add dummy.Rnw? Am I missing something? /Henrik sessionInfo() R version 2.13.0 alpha (2011-03-27 r55091) Platform: x86_64-pc-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.13.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build processes inst/doc/Makefile only if there are vignette files?
On Fri, 29 Apr 2011, Hervé Pagès wrote: On 11-03-30 01:55 AM, Prof Brian Ripley wrote: What R CMD build (and check) does is to call tools::buildVignettes. That has been true for a while, and buildVignettes() returns if no vignettes are found. The docs are out-of-date. My view is that you are misusing inst/doc: it is intended *only* for files which are going to be installed and hence report.tex should not really be there. So you should be doing this in another source directory and copying report.pdf to inst/doc. Use configure to arrange this. Shortly vignettes to be built will be moved out of inst/doc. Could you please elaborate on this? I just found this in the NEWS for R 2.14.0: o The preferred location for vignette sources is now the directory ‘vignettes’ and not ‘inst/doc’: R CMD build will now re-build vignettes in ‘vignettes’ and copy the ‘.Rnw’ (etc) files and the corresponding PDFs to ‘inst/doc’. Sounds like an important move. What are the long term plans: keep both inst/doc/ and vignettes/ as places for vignettes to be built? Or drop inst/doc/ at some point? Drop inst/doc at some point. It doesn't make much difference to the codebase: all the work is done in pkgVignettes(). Thanks! H. On Tue, 29 Mar 2011, Henrik Bengtsson wrote: Hi, in Section 'Writing package vignettes' of 'Writing R Extensions' it says: "Whenever a Makefile is found, then R CMD build will try to run make after the Sweave runs, so PDF manuals can be created from arbitrary source formats (plain LaTeX files, ...). [...] Note that the make step is executed even if there are no files in Sweave format, [...]". In my package, inst/doc/ file contains two files: Makefile, and report.tex. However, when running 'Rcmd build' on Windows with R v2.13.0 alpha (2011-03-27 r55091) I can only get 'make' to run (process inst/doc/Makefile) if I add a inst/doc/dummy.Rnw file, otherwise nothing happens. My Makefile contains: all: pdf pdf: report.tex texi2dvi --pdf report.tex clean: rm dummy.Rnw dummy.tex rm *.aux *.log *.toc Is it really necessary to add dummy.Rnw? Am I missing something? /Henrik sessionInfo() R version 2.13.0 alpha (2011-03-27 r55091) Platform: x86_64-pc-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.13.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build processes inst/doc/Makefile only if there are vignette files?
On 11-04-29 10:36 PM, Prof Brian Ripley wrote: On Fri, 29 Apr 2011, Hervé Pagès wrote: On 11-03-30 01:55 AM, Prof Brian Ripley wrote: What R CMD build (and check) does is to call tools::buildVignettes. That has been true for a while, and buildVignettes() returns if no vignettes are found. The docs are out-of-date. My view is that you are misusing inst/doc: it is intended *only* for files which are going to be installed and hence report.tex should not really be there. So you should be doing this in another source directory and copying report.pdf to inst/doc. Use configure to arrange this. Shortly vignettes to be built will be moved out of inst/doc. Could you please elaborate on this? I just found this in the NEWS for R 2.14.0: o The preferred location for vignette sources is now the directory ‘vignettes’ and not ‘inst/doc’: R CMD build will now re-build vignettes in ‘vignettes’ and copy the ‘.Rnw’ (etc) files and the corresponding PDFs to ‘inst/doc’. Sounds like an important move. What are the long term plans: keep both inst/doc/ and vignettes/ as places for vignettes to be built? Or drop inst/doc/ at some point? Drop inst/doc at some point. May I ask when? It doesn't make much difference to the codebase: all the work is done in pkgVignettes(). Maybe but it will make a big difference from our side: about 450 BioC packages will need to be modified. Thanks, H. Thanks! H. On Tue, 29 Mar 2011, Henrik Bengtsson wrote: Hi, in Section 'Writing package vignettes' of 'Writing R Extensions' it says: "Whenever a Makefile is found, then R CMD build will try to run make after the Sweave runs, so PDF manuals can be created from arbitrary source formats (plain LaTeX files, ...). [...] Note that the make step is executed even if there are no files in Sweave format, [...]". In my package, inst/doc/ file contains two files: Makefile, and report.tex. However, when running 'Rcmd build' on Windows with R v2.13.0 alpha (2011-03-27 r55091) I can only get 'make' to run (process inst/doc/Makefile) if I add a inst/doc/dummy.Rnw file, otherwise nothing happens. My Makefile contains: all: pdf pdf: report.tex texi2dvi --pdf report.tex clean: rm dummy.Rnw dummy.tex rm *.aux *.log *.toc Is it really necessary to add dummy.Rnw? Am I missing something? /Henrik sessionInfo() R version 2.13.0 alpha (2011-03-27 r55091) Platform: x86_64-pc-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.13.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319 -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build - will reset the timestamps of all files in a package
After half a year of silence on this issue I would dare ask again: is this intended, why and how can I avoid it? Best regards, Valentin ... I wonder why (R version 2.13.0 and after) the command "R CMD build" sets the timestamp of all files in the package to the current date/time. This seems not to be mentioned in the list of changes. Is there an option to avoid this? ... __ R-devel@ mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- View this message in context: http://r.789695.n4.nabble.com/R-CMD-build-will-reset-the-timestamps-of-all-files-in-a-package-tp3492257p3938360.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build - will reset the timestamps of all files in a package
> Valentin Todorov > on Tue, 25 Oct 2011 14:34:21 -0700 writes: > After half a year of silence on this issue I would dare > ask again: is this intended, why and how can I avoid it? > Best regards, Valentin > ... I wonder why (R version 2.13.0 and after) the command > "R CMD build" sets the timestamp of all files in the > package to the current date/time. This seems not to be > mentioned in the list of changes. Is there an option to > avoid this? ... Yes, upgrade to R 2.14.0 (now in "RC" = Release Candidate state) or newer (and don't use Windows). The 'NEWS' entry is • R CMD build on a Unix-alike (only) now tries to preserve dates on files it copies from its input directory. (This was the undocumented behaviour prior to R 2.13.0.) Best regards, and thanks for persevering ( and *NO thanks* for using Nabble :-( ) Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build then check fails on R-devel due to serialization version
On 10/01/2018 1:26 PM, Neal Richardson wrote: Hi, Since yesterday I'm seeing `R CMD check --as-cran` failures on the R-devel daily build (specifically, R Under development (unstable) (2018-01-09 r74100)) for multiple packages: * checking serialized R objects in the sources ... WARNING Found file(s) with version 3 serialization: ‘build/vignette.rds’ Such files are only readable in R >= 3.5.0. Recreate them with R < 3.5.0 or save(version = 2) or saveRDS(version = 2) as appropriate As far as I can tell, revision 74099 (https://github.com/wch/r-source/commit/d9530001046a582ff6a43ca834d6c3586abd0a97), which changes the default serialization format to 3, clashes with revision 73973 (https://github.com/wch/r-source/commit/885764eb74f2211a547b13727f2ecc5470c3dd00), which checks that serialized R objects are _not_ version 3. It seems that with the current development version of R, if you `R CMD build` and then run `R CMD check --as-cran` on the built package, it will fail. I think the message basically says: don't do that. You should build with R-release for now. You always need to check with R-devel, so life is complicated. If you build with R-devel without forcing the old format, nobody using R-release will be able to use your tarball. Eventually I guess the new format will be accepted by CRAN, but it will likely be a while: nobody expects everyone to instantly upgrade to a new R release, let alone to an unreleased development version. Presumably that particular file (build/vignette.rds) could be automatically built in the old format for now, but the new format needs testing, so it makes sense to me to leave it as a default, even if it makes it more complicated to submit a package to CRAN. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build then check fails on R-devel due to serialization version
This change poses difficulties for automated build systems such as travis-ci, which is widely used in the R community. In particular because this is a WARNING and not a NOTE this causes all R-devel builds with vignettes to fail, as the default settings fail the build if R CMD check issues a WARNING. The simplest change would be for R-core to change this message to be a NOTE rather than a WARNING, the serialization could still be tested and there would be a check against vignettes built with R-devel, but it would not cause these builds to fail. On Wed, Jan 10, 2018 at 3:52 PM, Duncan Murdoch wrote: > On 10/01/2018 1:26 PM, Neal Richardson wrote: >> >> Hi, >> Since yesterday I'm seeing `R CMD check --as-cran` failures on the >> R-devel daily build (specifically, R Under development (unstable) >> (2018-01-09 r74100)) for multiple packages: >> >> * checking serialized R objects in the sources ... WARNING >> Found file(s) with version 3 serialization: >> ‘build/vignette.rds’ >> Such files are only readable in R >= 3.5.0. >> Recreate them with R < 3.5.0 or save(version = 2) or saveRDS(version = >> 2) as appropriate >> >> As far as I can tell, revision 74099 >> >> (https://github.com/wch/r-source/commit/d9530001046a582ff6a43ca834d6c3586abd0a97), >> which changes the default serialization format to 3, clashes with >> revision 73973 >> (https://github.com/wch/r-source/commit/885764eb74f2211a547b13727f2ecc5470c3dd00), >> which checks that serialized R objects are _not_ version 3. It seems >> that with the current development version of R, if you `R CMD build` >> and then run `R CMD check --as-cran` on the built package, it will >> fail. >> > > I think the message basically says: don't do that. You should build with > R-release for now. You always need to check with R-devel, so life is > complicated. > > If you build with R-devel without forcing the old format, nobody using > R-release will be able to use your tarball. > > Eventually I guess the new format will be accepted by CRAN, but it will > likely be a while: nobody expects everyone to instantly upgrade to a new R > release, let alone to an unreleased development version. > > Presumably that particular file (build/vignette.rds) could be automatically > built in the old format for now, but the new format needs testing, so it > makes sense to me to leave it as a default, even if it makes it more > complicated to submit a package to CRAN. > > Duncan Murdoch > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build then check fails on R-devel due to serialization version
As things stand now, package tarballs with vignettes that are built with R-devel will not install in R 3.4.x, so CRAN can't accept them and someone running R CMD check --as-cran should be told that. A WARNING is appropriate. Most likely what will change soon is that build/version.rds will be saved with serialization version = 2 and this warning will not be triggered just by having a vignette. It will still be triggered by data files serialized with R-devel's default version = 3. Please do remember that the 'devel' in R-devel means exactly that: things will at times be unstable. There are currently a lot of balls flying around with changes in R-devel and also Biocontuctor, and the CRAN maintainers are working hard to keep things all up in the air. Please be patient. Best, luke On Thu, 11 Jan 2018, Jim Hester wrote: This change poses difficulties for automated build systems such as travis-ci, which is widely used in the R community. In particular because this is a WARNING and not a NOTE this causes all R-devel builds with vignettes to fail, as the default settings fail the build if R CMD check issues a WARNING. The simplest change would be for R-core to change this message to be a NOTE rather than a WARNING, the serialization could still be tested and there would be a check against vignettes built with R-devel, but it would not cause these builds to fail. On Wed, Jan 10, 2018 at 3:52 PM, Duncan Murdoch wrote: On 10/01/2018 1:26 PM, Neal Richardson wrote: Hi, Since yesterday I'm seeing `R CMD check --as-cran` failures on the R-devel daily build (specifically, R Under development (unstable) (2018-01-09 r74100)) for multiple packages: * checking serialized R objects in the sources ... WARNING Found file(s) with version 3 serialization: ‘build/vignette.rds’ Such files are only readable in R >= 3.5.0. Recreate them with R < 3.5.0 or save(version = 2) or saveRDS(version = 2) as appropriate As far as I can tell, revision 74099 (https://github.com/wch/r-source/commit/d9530001046a582ff6a43ca834d6c3586abd0a97), which changes the default serialization format to 3, clashes with revision 73973 (https://github.com/wch/r-source/commit/885764eb74f2211a547b13727f2ecc5470c3dd00), which checks that serialized R objects are _not_ version 3. It seems that with the current development version of R, if you `R CMD build` and then run `R CMD check --as-cran` on the built package, it will fail. I think the message basically says: don't do that. You should build with R-release for now. You always need to check with R-devel, so life is complicated. If you build with R-devel without forcing the old format, nobody using R-release will be able to use your tarball. Eventually I guess the new format will be accepted by CRAN, but it will likely be a while: nobody expects everyone to instantly upgrade to a new R release, let alone to an unreleased development version. Presumably that particular file (build/vignette.rds) could be automatically built in the old format for now, but the new format needs testing, so it makes sense to me to leave it as a default, even if it makes it more complicated to submit a package to CRAN. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build then check fails on R-devel due to serialization version
To reduce difficulties for people relying on automated tests set up to build&"check --as-cran" using R-devel (e.g. travis-ci), the default serialization version has been temporarily switched back to 2. Thank you for your patience - according to svn history, the last change of the serialization format happened 16 years ago, and unsurprisingly some practices that developed since did not anticipate such change and have to be adapted. CRAN is now protected against packages containing serialized files in format 3 (which not only is not readable by 3.4.x and older, but could still change - the 'devel' in 'R-devel'). These new checks have to stay but we are looking at improving package-maintainer-friendliness. It turned out more difficult than just 1-2 days, hence the temporary switch back to version 2. Best Tomas On 01/11/2018 02:47 PM, luke-tier...@uiowa.edu wrote: As things stand now, package tarballs with vignettes that are built with R-devel will not install in R 3.4.x, so CRAN can't accept them and someone running R CMD check --as-cran should be told that. A WARNING is appropriate. Most likely what will change soon is that build/version.rds will be saved with serialization version = 2 and this warning will not be triggered just by having a vignette. It will still be triggered by data files serialized with R-devel's default version = 3. Please do remember that the 'devel' in R-devel means exactly that: things will at times be unstable. There are currently a lot of balls flying around with changes in R-devel and also Biocontuctor, and the CRAN maintainers are working hard to keep things all up in the air. Please be patient. Best, luke On Thu, 11 Jan 2018, Jim Hester wrote: This change poses difficulties for automated build systems such as travis-ci, which is widely used in the R community. In particular because this is a WARNING and not a NOTE this causes all R-devel builds with vignettes to fail, as the default settings fail the build if R CMD check issues a WARNING. The simplest change would be for R-core to change this message to be a NOTE rather than a WARNING, the serialization could still be tested and there would be a check against vignettes built with R-devel, but it would not cause these builds to fail. On Wed, Jan 10, 2018 at 3:52 PM, Duncan Murdoch wrote: On 10/01/2018 1:26 PM, Neal Richardson wrote: Hi, Since yesterday I'm seeing `R CMD check --as-cran` failures on the R-devel daily build (specifically, R Under development (unstable) (2018-01-09 r74100)) for multiple packages: * checking serialized R objects in the sources ... WARNING Found file(s) with version 3 serialization: ‘build/vignette.rds’ Such files are only readable in R >= 3.5.0. Recreate them with R < 3.5.0 or save(version = 2) or saveRDS(version = 2) as appropriate As far as I can tell, revision 74099 (https://github.com/wch/r-source/commit/d9530001046a582ff6a43ca834d6c3586abd0a97), which changes the default serialization format to 3, clashes with revision 73973 (https://github.com/wch/r-source/commit/885764eb74f2211a547b13727f2ecc5470c3dd00), which checks that serialized R objects are _not_ version 3. It seems that with the current development version of R, if you `R CMD build` and then run `R CMD check --as-cran` on the built package, it will fail. I think the message basically says: don't do that. You should build with R-release for now. You always need to check with R-devel, so life is complicated. If you build with R-devel without forcing the old format, nobody using R-release will be able to use your tarball. Eventually I guess the new format will be accepted by CRAN, but it will likely be a while: nobody expects everyone to instantly upgrade to a new R release, let alone to an unreleased development version. Presumably that particular file (build/vignette.rds) could be automatically built in the old format for now, but the new format needs testing, so it makes sense to me to leave it as a default, even if it makes it more complicated to submit a package to CRAN. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
