Re: [Rd] Source for bash_completion.d/R?
On Tue, May 3, 2011 at 4:40 AM, Dirk Eddelbuettel e...@debian.org wrote: On 2 May 2011 at 11:32, Sharpie wrote: | Hello, I was just tweaking the R build for the Homebrew package manager and I | thought it would be nice to enable bash completion. I noticed that | Debian-based systems install `/etc/bash_completion.d/R` but could not find a | source for this file in the `etc` folder of the R source. Right. This started off via a suggestion by Deepayan and a quick install via a local-to-Debian-package-sources file, and has never moved away from that. I am CCing Deepayan now; it may indeed be useful to commit this in the R svn and to add it to the tarball as the feature is very, very useful if you deplay bash completion. I vaguely remember a discussion on r-core where the consensus was that this was too shell-specific to belong in the R sources. It has been publicly available (for a long time) at http://code.google.com/p/rcompletion/source/browse/trunk/bash_completion/R (could use a little work now). -Deepayan Dirk -- Gauss once played himself in a zero-sum game and won $50. -- #11 at http://www.gaussfacts.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check and Suggests Packages
Hervé Pagès hpa...@fhcrc.org
on Mon, 02 May 2011 11:55:08 -0700 writes:
Hi, On 11-04-28 07:00 PM, Dario Strbenac wrote:
Hello,
In my description file, I have an example data package in
Suggests: that I've deleted from my library to test what
the user who doesn't have it will experience.
However, R CMD check won't even pass my package :
* checking package dependencies ... ERROR
Package required but not available: RepitoolsExamples
confusing!
Wouldn't a message like
Package required for full checking but not available:
RepitoolsExamples
be more appropriate and avoid a confusion that we've seen
for a very long time now?
Sure. But such messages are already produced in current
versions of R, .. at least they are there in the package checking
source, see
format.check_package_depends() in
src/library/tools/R/QC.R
which has e.g.,
if(length(bad - x$suggests_but_not_installed) 1L) {
c(gettext(Packages suggested but not available for checking:),
and similar for 'Enhances' in lieu of 'Suggests'.
If Dario really uses R 2.13.0 (or newer),
and he gets the above error message for a package that is not
required but only suggested,
I think we'd need a clear, ideally simple,
reproducible example, here.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Location of Internal Code
Hello, This seems like a fairly elementary question, but I couldn't seem to find the answer anywhere online. Where can I find code which is called with .Internal? Specifically, the R function colSums() calls an internal function with the same name (I presume a C function), and I'd like to see how it works. I've searched through the header files in R-2.x.x/include/ (Windows version), but to no avail. Thanks, Robin -- Robin Evans Statistics Department University of Washington www.stat.washington.edu/~rje42 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug report: R 2.14.0dev Sweave option width does not work
Thank you! It works.
On 01.05.2011 19:17, Duncan Murdoch wrote:
On 11-05-01 7:35 AM, Duncan Murdoch wrote:
On 30/04/11 7:25 PM, Alexander Favorov wrote:
Hi!
In R 2.14.0dev (R version 2.14.0 Under development (unstable)
(2011-04-29 r55692), Windows release
(http://cran.r-project.org/bin/windows/base/rdevel.html), the line :
options(width=55)
in code chunk of an Rnw file has no effect on sweave's output text file.
The same thing in 2.13.0 worked.
What effect do you expect? That would only have an effect if
- the option value was different before that line, and
- you printed something that would differ in the two widths.
Please put together an example to illustrate what problem you're seeing.
Duncan Murdoch
Turned out (from a private email) that this has nothing to do with line
breaking. It is just that the default in 2.14.0 is keep.source=TRUE,
whereas it was keep.source=FALSE in previous versions. If you want the
old behaviour, put
\SweaveOpts{keep.source=FALSE}
early in your .Rnw file.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [R] Sweave stops when opening X11 device fails
Hi all, I am posting this again because I got no reply on r-help. Maybe the devel-list is the right place for this kind of question. I've run into the following problem with Sweave: I frequently run Sweave from a xterm console within an X session owned by a different user, i.e. my colleague is logged in on this computer and I do su with my username and start R and Sweave afterwards. Now, when Sweave comes to a figure chunk, it sees that there is an X server running and tries to show whatever I plot in that chunk on the screen, additionally to writing a pdf file. The problem is that I am not logged into the X session myself, and the script fails with a message saying someting like could not open device X11 (I have German messages, so I do not know what the exact phrase would be in English). When I log in with putty, where there is no X11 at all, everything works fine. Is there a way to prevent Sweave from failing in the former case? Would this even account as a bug? I think it would be nice if the script just kept on running without plotting on the screen if opening X11 fails, just like it does when no X11 is available at all. Best regards, Andreas p.s.: I would be willing to dig in the code and look for a fix myself, but it would be great if anyone could give a hint where to look. I suspect RweaveDriverRuncode is the right place, but in what namespace is it? -- Andreas Borg Medizinische Informatik UNIVERSITÄTSMEDIZIN der Johannes Gutenberg-Universität Institut für Medizinische Biometrie, Epidemiologie und Informatik Obere Zahlbacher Straße 69, 55131 Mainz www.imbei.uni-mainz.de Telefon +49 (0) 6131 175062 E-Mail: b...@imbei.uni-mainz.de Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail und der darin enthaltenen Informationen ist nicht gestattet. __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to create vignette.pdf for R-2.13.0?
On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. --no-clean-vignettes. FYI, I did not claim ..create the vignettes *in pkginst/doc*, instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory inst/doc with the vignettes while xps.Rcheck from R-2.13.0 does not contain inst. But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates xps_1.13.1.tar.gz which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply because it doesn't. For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has been, an approximation. Actually, it does. What earlier versions never did (despite 'cstrato's repeated delusional claims earlier) was to create the vignettes *in pkginst/doc*. All of them re-created (by default) vignettes in a working directory. The difference is that 2.13.0 deletes that working directory if the test was successful, whereas earlier versions left the results somewhere in pkg.Rcheck (the 'somewhere' has varied). However, earier versions of R CMD check sometimes failed when R CMD build succeeded Using Animal (a small CRAN package with one vignette). R 2.12.2 gave * checking package vignettes in ‘inst/doc’ ... WARNING Package vignettes without corresponding PDF: /tmp/Animal/inst/doc/Animal.Rnw and the vignette was re-created in Animal.Rcheck/inst/doc. R 2.13.0 gives * checking package vignettes in ‘inst/doc’ ... WARNING Package vignette(s) without corresponding PDF: Animal.Rnw Non-ASCII package vignette(s) without specified encoding: Animal.Rnw * checking running R code from vignettes ... OK * checking re-building of vignettes ... OK and the working directory was Animal.Rcheck/vign_test . The main reason for cleaning up is that to mimic R CMD build the test has to make a complete copy of the package sources, and that adds up: checking CRAN already takes 17GB for each flavour. Duncan Murdoch Best regards Christian On 4/27/11 10:16 AM, Uwe Ligges wrote: On 26.04.2011 21:58, cstrato wrote: Dear Duncan, dear Uwe, Just now I have re-run everything, and today xps.Rnw can be converted to a vignette w/o any problems using: a, buildVignettes(xps, dir=/Volumes/CoreData/CRAN/xps, quiet=F) b, R CMD Sweave xps.Rnw In both cases the vignette xps.pdf is created (maybe my Mac did not like to work during eastern holidays). However, one issue remains: R64 CMD check xps_1.13.1.tar.gz no longer creates any pdf files for the vignettes. Dioes it give an error or warning? It should check the code. R CMD build creates the pdf files. Uwe Ligges Best regards Christian On 4/25/11 9:31 PM, Duncan Murdoch wrote: On 25/04/2011 3:16 PM, cstrato wrote: Thank you. My problem seems to be that at the moment the problem can be seen only on my Mac, since e.g. the Bioconductor servers have no problems creating the vignettes. Then you are definitely the one in the best position to diagnose the problem. Use the usual approach: simplify it by cutting out everything that looks unrelated. Verify that the problem still exists, then cut some more. Eventually you'll have isolated the error to a particular small snippet of code, and then you can add print() statements, or use trace(), or do whatever is necessary to see what's so special about your system. I suspect it will turn out to be an assumption in the code that is not true on your system. If the assumption is being made by code you
Re: [Rd] Location of Internal Code
On 03.05.2011 01:59, Robin Evans wrote: Hello, This seems like a fairly elementary question, but I couldn't seem to find the answer anywhere online. Where can I find code which is called with .Internal? Specifically, the R function colSums() calls an internal function with the same name (I presume a C function), and I'd like to see how it works. I've searched through the header files in R-2.x.x/include/ (Windows version), but to no avail. They are only used for external function to be able to link against R. For .Internal() (for example), see ./src/main/names.c and the names they refer to (also in other files in ./src/main) Uwe Ligges Thanks, Robin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Sweave stops when opening X11 device fails
On May 3, 2011, at 12:35 , Andreas Borg wrote: Hi all, I am posting this again because I got no reply on r-help. Maybe the devel-list is the right place for this kind of question. Actually, not an R problem at all, but try one of these... 1) get rid of the DISPLAY environment variable before starting R 2) replace the su command with ssh -Y localhost to get the X server tunneled properly. 3) xhost +localhost (may be a security liability) -pd I've run into the following problem with Sweave: I frequently run Sweave from a xterm console within an X session owned by a different user, i.e. my colleague is logged in on this computer and I do su with my username and start R and Sweave afterwards. Now, when Sweave comes to a figure chunk, it sees that there is an X server running and tries to show whatever I plot in that chunk on the screen, additionally to writing a pdf file. The problem is that I am not logged into the X session myself, and the script fails with a message saying someting like could not open device X11 (I have German messages, so I do not know what the exact phrase would be in English). When I log in with putty, where there is no X11 at all, everything works fine. Is there a way to prevent Sweave from failing in the former case? Would this even account as a bug? I think it would be nice if the script just kept on running without plotting on the screen if opening X11 fails, just like it does when no X11 is available at all. Best regards, Andreas p.s.: I would be willing to dig in the code and look for a fix myself, but it would be great if anyone could give a hint where to look. I suspect RweaveDriverRuncode is the right place, but in what namespace is it? -- Andreas Borg Medizinische Informatik UNIVERSITÄTSMEDIZIN der Johannes Gutenberg-Universität Institut für Medizinische Biometrie, Epidemiologie und Informatik Obere Zahlbacher Straße 69, 55131 Mainz www.imbei.uni-mainz.de Telefon +49 (0) 6131 175062 E-Mail: b...@imbei.uni-mainz.de Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail und der darin enthaltenen Informationen ist nicht gestattet. __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ 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
Re: [Rd] [R] Sweave stops when opening X11 device fails
On 3 May 2011 at 13:19, peter dalgaard wrote: | | On May 3, 2011, at 12:35 , Andreas Borg wrote: | | Hi all, | | I am posting this again because I got no reply on r-help. Maybe the devel-list is the right place for this kind of question. | | Actually, not an R problem at all, but try one of these... | | 1) get rid of the DISPLAY environment variable before starting R | | 2) replace the su command with ssh -Y localhost to get the X server tunneled properly. | | 3) xhost +localhost (may be a security liability) 4) If available, use the 'xvfb-run' frontend to simulate X11 in a virtual framebuffer. That is how the Debian packages build when a given package requires X11 at init or load time (here's looking at you, tcltk). This can be as simple as xvfb-run R CMD Sweave someFile.Rnw Debian / Ubuntu have xvfb-run available in a package 'xvfb', I suspect other distros do to. Dirk | -pd | | | I've run into the following problem with Sweave: I frequently run Sweave | from a xterm console within an X session owned by a different user, i.e. | my colleague is logged in on this computer and I do su with my | username and start R and Sweave afterwards. Now, when Sweave comes to a | figure chunk, it sees that there is an X server running and tries to | show whatever I plot in that chunk on the screen, additionally to | writing a pdf file. The problem is that I am not logged into the X | session myself, and the script fails with a message saying someting like | could not open device X11 (I have German messages, so I do not know | what the exact phrase would be in English). When I log in with putty, | where there is no X11 at all, everything works fine. Is there a way to | prevent Sweave from failing in the former case? Would this even account | as a bug? I think it would be nice if the script just kept on running | without plotting on the screen if opening X11 fails, just like it does | when no X11 is available at all. | | Best regards, | | Andreas | | p.s.: I would be willing to dig in the code and look for a fix myself, but it would be great if anyone could give a hint where to look. I suspect RweaveDriverRuncode is the right place, but in what namespace is it? | | -- | Andreas Borg | Medizinische Informatik | | UNIVERSITÄTSMEDIZIN | der Johannes Gutenberg-Universität | Institut für Medizinische Biometrie, Epidemiologie und Informatik | Obere Zahlbacher Straße 69, 55131 Mainz | www.imbei.uni-mainz.de | | Telefon +49 (0) 6131 175062 | E-Mail: b...@imbei.uni-mainz.de | | Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der | richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den | Absender und löschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe | dieser Mail und der darin enthaltenen Informationen ist nicht gestattet. | | __ | r-h...@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-help | PLEASE do read the posting guide http://www.R-project.org/posting-guide.html | and provide commented, minimal, self-contained, reproducible code. | | __ | R-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel | | -- | Peter Dalgaard | Center for Statistics, Copenhagen Business School | Solbjerg Plads 3, 2000 Frederiksberg, Denmark | Phone: (+45)38153501 | Email: pd@cbs.dk Priv: pda...@gmail.com | | __ | R-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel -- Gauss once played himself in a zero-sum game and won $50. -- #11 at http://www.gaussfacts.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reference Classes: Accessing methods via [[...]], bug?
On Sun, 1 May 2011, Martin Morgan wrote: On 05/01/2011 03:09 PM, John Chambers wrote: It would be interesting to get some experience and opinions on whether this is a good idea or not. It breaks encapsulation, in that the behavior of the class can no longer be inferred from the class definition alone. On the other hand, it is convenient and relates to operator overloading in some other languages. I have written 'show' methods for reference classes (is there another way to pretty-print them?) and S4 methods that dispatch to reference methods (in particular, yield(x) on connection-like classes dispatching to x$yield()). Most of my S4 method usage with reference classes has been the 'show' methods for the same reason that Martin states - I was unable to find another mechanism of pretty printing, and wanted something along those lines for situations such as a list of objects and how that gets rendered on the screen. I've also made use of S4 methods for reference classes to help maintain backwards compatibility for cases where I've changed the underlying implementation from S4 to using reference classes - in those cases the ability to use S4 methods was handy but not strictly necessary. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. Best regards Christian On 5/3/11 1:07 PM, Uwe Ligges wrote: On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. --no-clean-vignettes. FYI, I did not claim ..create the vignettes *in pkginst/doc*, instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory inst/doc with the vignettes while xps.Rcheck from R-2.13.0 does not contain inst. But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates xps_1.13.1.tar.gz which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply because it doesn't. For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has been, an approximation. Actually, it does. What earlier versions never did (despite 'cstrato's repeated delusional claims earlier) was to create the vignettes *in pkginst/doc*. All of them re-created (by default) vignettes in a working directory. The difference is that 2.13.0 deletes that working directory if the test was successful, whereas earlier versions left the results somewhere in pkg.Rcheck (the 'somewhere' has varied). However, earier versions of R CMD check sometimes failed when R CMD build succeeded Using Animal (a small CRAN package with one vignette). R 2.12.2 gave * checking package vignettes in ‘inst/doc’ ... WARNING Package vignettes without corresponding PDF: /tmp/Animal/inst/doc/Animal.Rnw and the vignette was re-created in Animal.Rcheck/inst/doc. R 2.13.0 gives * checking package vignettes in ‘inst/doc’ ... WARNING Package vignette(s) without corresponding PDF: Animal.Rnw Non-ASCII package vignette(s) without specified encoding: Animal.Rnw * checking running R code from vignettes ... OK * checking re-building of vignettes ... OK and the working directory was Animal.Rcheck/vign_test . The main reason for cleaning up is that to mimic R CMD build the test has to make a complete copy of the package sources, and that adds up: checking CRAN already takes 17GB for each flavour. Duncan Murdoch Best regards Christian On 4/27/11 10:16 AM, Uwe Ligges wrote: On 26.04.2011 21:58, cstrato wrote: Dear Duncan, dear Uwe, Just now I have re-run everything, and today xps.Rnw can be converted to a vignette w/o any problems using: a, buildVignettes(xps, dir=/Volumes/CoreData/CRAN/xps, quiet=F) b, R CMD Sweave xps.Rnw In both cases the vignette xps.pdf is created (maybe my Mac did not like to work during eastern holidays). However, one issue remains: R64 CMD check xps_1.13.1.tar.gz no longer creates any pdf files for the vignettes. Dioes it give an error or warning? It should check the code. R CMD build creates the pdf files. Uwe Ligges Best regards Christian On 4/25/11 9:31 PM, Duncan Murdoch wrote: On 25/04/2011 3:16 PM, cstrato wrote: Thank you. My problem seems to be that at the moment the problem can be seen only on my
Re: [Rd] How to create vignette.pdf for R-2.13.0?
On 03.05.2011 21:14, cstrato wrote: Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. Then this is the main problem here. The *recommended* development cycle from the manuals is to run 1. R CMD build in order to get a valid source tarball and clean the sources 2. R CMD INSTALL to check if your package can be installed 3. R CMD check in order to finally check your package Running R CMD INSTALL on your source directory may pollute it, hence this is not recommended at all. Best, UWe Best regards Christian On 5/3/11 1:07 PM, Uwe Ligges wrote: On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. --no-clean-vignettes. FYI, I did not claim ..create the vignettes *in pkginst/doc*, instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory inst/doc with the vignettes while xps.Rcheck from R-2.13.0 does not contain inst. But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates xps_1.13.1.tar.gz which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply because it doesn't. For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has been, an approximation. Actually, it does. What earlier versions never did (despite 'cstrato's repeated delusional claims earlier) was to create the vignettes *in pkginst/doc*. All of them re-created (by default) vignettes in a working directory. The difference is that 2.13.0 deletes that working directory if the test was successful, whereas earlier versions left the results somewhere in pkg.Rcheck (the 'somewhere' has varied). However, earier versions of R CMD check sometimes failed when R CMD build succeeded Using Animal (a small CRAN package with one vignette). R 2.12.2 gave * checking package vignettes in ‘inst/doc’ ... WARNING Package vignettes without corresponding PDF: /tmp/Animal/inst/doc/Animal.Rnw and the vignette was re-created in Animal.Rcheck/inst/doc. R 2.13.0 gives * checking package vignettes in ‘inst/doc’ ... WARNING Package vignette(s) without corresponding PDF: Animal.Rnw Non-ASCII package vignette(s) without specified encoding: Animal.Rnw * checking running R code from vignettes ... OK * checking re-building of vignettes ... OK and the working directory was Animal.Rcheck/vign_test . The main reason for cleaning up is that to mimic R CMD build the test has to make a complete copy of the package sources, and that adds up: checking CRAN already takes 17GB for each flavour. Duncan Murdoch Best regards Christian On 4/27/11 10:16 AM, Uwe Ligges wrote: On 26.04.2011 21:58, cstrato wrote: Dear Duncan, dear Uwe, Just now I have re-run everything, and today xps.Rnw can be converted to a vignette w/o any problems using: a, buildVignettes(xps, dir=/Volumes/CoreData/CRAN/xps, quiet=F) b, R CMD Sweave xps.Rnw In both cases the vignette xps.pdf is created (maybe my Mac did not like to work
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Uwe, Thank you, however since I use R CMD INSTALL xps.tar.gz my source code is not polluted. Furthermore, I forgot to mention that finally I upload the source code only to the BioC svn repository. The rest is done by the BioC servers, including building the pdf-files for the vignettes. Best regards Christian On 5/3/11 10:13 PM, Uwe Ligges wrote: On 03.05.2011 21:14, cstrato wrote: Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. Then this is the main problem here. The *recommended* development cycle from the manuals is to run 1. R CMD build in order to get a valid source tarball and clean the sources 2. R CMD INSTALL to check if your package can be installed 3. R CMD check in order to finally check your package Running R CMD INSTALL on your source directory may pollute it, hence this is not recommended at all. Best, UWe Best regards Christian On 5/3/11 1:07 PM, Uwe Ligges wrote: On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. --no-clean-vignettes. FYI, I did not claim ..create the vignettes *in pkginst/doc*, instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory inst/doc with the vignettes while xps.Rcheck from R-2.13.0 does not contain inst. But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates xps_1.13.1.tar.gz which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply because it doesn't. For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has been, an approximation. Actually, it does. What earlier versions never did (despite 'cstrato's repeated delusional claims earlier) was to create the vignettes *in pkginst/doc*. All of them re-created (by default) vignettes in a working directory. The difference is that 2.13.0 deletes that working directory if the test was successful, whereas earlier versions left the results somewhere in pkg.Rcheck (the 'somewhere' has varied). However, earier versions of R CMD check sometimes failed when R CMD build succeeded Using Animal (a small CRAN package with one vignette). R 2.12.2 gave * checking package vignettes in ‘inst/doc’ ... WARNING Package vignettes without corresponding PDF: /tmp/Animal/inst/doc/Animal.Rnw and the vignette was re-created in Animal.Rcheck/inst/doc. R 2.13.0 gives * checking package vignettes in ‘inst/doc’ ... WARNING Package vignette(s) without corresponding PDF: Animal.Rnw Non-ASCII package vignette(s) without specified encoding: Animal.Rnw * checking running R code from vignettes ... OK * checking re-building of vignettes ... OK and the working directory was Animal.Rcheck/vign_test . The main reason for cleaning up is that to mimic R CMD build the test has to make a complete copy of the package sources, and that adds up: checking CRAN already takes 17GB for each flavour. Duncan Murdoch Best regards Christian On 4/27/11 10:16 AM, Uwe
Re: [Rd] How to create vignette.pdf for R-2.13.0?
On May 3, 2011, at 4:48 PM, cstrato cstr...@aon.at wrote: Dear Uwe, Thank you, however since I use R CMD INSTALL xps.tar.gz my source code is not polluted. But then you already used build to create the tar ball so the vignette has been built. So what is your point? Cheers, S Furthermore, I forgot to mention that finally I upload the source code only to the BioC svn repository. The rest is done by the BioC servers, including building the pdf-files for the vignettes. Best regards Christian On 5/3/11 10:13 PM, Uwe Ligges wrote: On 03.05.2011 21:14, cstrato wrote: Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. Then this is the main problem here. The *recommended* development cycle from the manuals is to run 1. R CMD build in order to get a valid source tarball and clean the sources 2. R CMD INSTALL to check if your package can be installed 3. R CMD check in order to finally check your package Running R CMD INSTALL on your source directory may pollute it, hence this is not recommended at all. Best, UWe Best regards Christian On 5/3/11 1:07 PM, Uwe Ligges wrote: On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. --no-clean-vignettes. FYI, I did not claim ..create the vignettes *in pkginst/doc*, instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory inst/doc with the vignettes while xps.Rcheck from R-2.13.0 does not contain inst. But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates xps_1.13.1.tar.gz which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply because it doesn't. For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has been, an approximation. Actually, it does. What earlier versions never did (despite 'cstrato's repeated delusional claims earlier) was to create the vignettes *in pkginst/doc*. All of them re-created (by default) vignettes in a working directory. The difference is that 2.13.0 deletes that working directory if the test was successful, whereas earlier versions left the results somewhere in pkg.Rcheck (the 'somewhere' has varied). However, earier versions of R CMD check sometimes failed when R CMD build succeeded Using Animal (a small CRAN package with one vignette). R 2.12.2 gave * checking package vignettes in ‘inst/doc’ ... WARNING Package vignettes without corresponding PDF: /tmp/Animal/inst/doc/Animal.Rnw and the vignette was re-created in Animal.Rcheck/inst/doc. R 2.13.0 gives * checking package vignettes in ‘inst/doc’ ... WARNING Package vignette(s) without corresponding PDF: Animal.Rnw Non-ASCII package vignette(s) without specified encoding: Animal.Rnw * checking running R code from vignettes ... OK * checking re-building of vignettes ... OK
Re: [Rd] How to create vignette.pdf for R-2.13.0?
No, I simply do tar czf xps_1.13.1.tar.gz xps. Best regards Christian On 5/3/11 11:11 PM, Simon Urbanek wrote: On May 3, 2011, at 4:48 PM, cstratocstr...@aon.at wrote: Dear Uwe, Thank you, however since I use R CMD INSTALL xps.tar.gz my source code is not polluted. But then you already used build to create the tar ball so the vignette has been built. So what is your point? Cheers, S Furthermore, I forgot to mention that finally I upload the source code only to the BioC svn repository. The rest is done by the BioC servers, including building the pdf-files for the vignettes. Best regards Christian On 5/3/11 10:13 PM, Uwe Ligges wrote: On 03.05.2011 21:14, cstrato wrote: Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. Then this is the main problem here. The *recommended* development cycle from the manuals is to run 1. R CMD build in order to get a valid source tarball and clean the sources 2. R CMD INSTALL to check if your package can be installed 3. R CMD check in order to finally check your package Running R CMD INSTALL on your source directory may pollute it, hence this is not recommended at all. Best, UWe Best regards Christian On 5/3/11 1:07 PM, Uwe Ligges wrote: On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. --no-clean-vignettes. FYI, I did not claim ..create the vignettes *inpkginst/doc*, instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory inst/doc with the vignettes while xps.Rcheck from R-2.13.0 does not contain inst. But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates xps_1.13.1.tar.gz which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply because it doesn't. For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has been, an approximation. Actually, it does. What earlier versions never did (despite 'cstrato's repeated delusional claims earlier) was to create the vignettes *in pkginst/doc*. All of them re-created (by default) vignettes in a working directory. The difference is that 2.13.0 deletes that working directory if the test was successful, whereas earlier versions left the results somewhere inpkg.Rcheck (the 'somewhere' has varied). However, earier versions of R CMD check sometimes failed when R CMD build succeeded Using Animal (a small CRAN package with one vignette). R 2.12.2 gave * checking package vignettes in ‘inst/doc’ ... WARNING Package vignettes without corresponding PDF: /tmp/Animal/inst/doc/Animal.Rnw and the vignette was re-created in Animal.Rcheck/inst/doc. R 2.13.0 gives * checking package vignettes in ‘inst/doc’ ... WARNING Package vignette(s) without corresponding PDF: Animal.Rnw Non-ASCII package vignette(s) without specified encoding: Animal.Rnw * checking running R
Re: [Rd] Reference Classes: Accessing methods via [[...]], bug?
Part of the motivation for the reference classes was to bring a general OOP view to R. One can start from some essential concepts of objects and their properties, inheritance and class definition, as have evolved over a very long time. Next, there is a fundamental choice of paradigm between encapsulated OOP as the rest of the world knows it, and functional OOP as practiced by S and R, and a few other languages. While the two paradigms are quite different, there is no need to view them as opposed. They provide different advantages and tend to suit different goals--very roughly, functional object creation and reproducible results versus persistent objects whose properties one would like to have evolve over time using their encapsulated methods. My biggest worry with the introduction of reference classes is that many people will just stick to the style of OOP that they're familiar with, and not bother to learn the strengths of the generic function approach. As these remarks may suggest, I'm trying to write up this perspective in some detail. To be continued Are you familiar with Concepts, Techniques, and Models of Computer Programming by van Roy and Haridi? That's what really helped me to understand the strengths and weaknesses of the various styles of programming. 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] How to create vignette.pdf for R-2.13.0?
On May 3, 2011, at 5:15 PM, cstrato wrote: No, I simply do tar czf xps_1.13.1.tar.gz xps. Well, that's your problem then, not R's. Source packages are created using R CMD build, not by manual tarring (you can do the latter if you know what you're doing, but then you can't complain about the R doing something wrong). Cheers, S On 5/3/11 11:11 PM, Simon Urbanek wrote: On May 3, 2011, at 4:48 PM, cstratocstr...@aon.at wrote: Dear Uwe, Thank you, however since I use R CMD INSTALL xps.tar.gz my source code is not polluted. But then you already used build to create the tar ball so the vignette has been built. So what is your point? Cheers, S Furthermore, I forgot to mention that finally I upload the source code only to the BioC svn repository. The rest is done by the BioC servers, including building the pdf-files for the vignettes. Best regards Christian On 5/3/11 10:13 PM, Uwe Ligges wrote: On 03.05.2011 21:14, cstrato wrote: Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. Then this is the main problem here. The *recommended* development cycle from the manuals is to run 1. R CMD build in order to get a valid source tarball and clean the sources 2. R CMD INSTALL to check if your package can be installed 3. R CMD check in order to finally check your package Running R CMD INSTALL on your source directory may pollute it, hence this is not recommended at all. Best, UWe Best regards Christian On 5/3/11 1:07 PM, Uwe Ligges wrote: On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. --no-clean-vignettes. FYI, I did not claim ..create the vignettes *inpkginst/doc*, instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory inst/doc with the vignettes while xps.Rcheck from R-2.13.0 does not contain inst. But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates xps_1.13.1.tar.gz which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply because it doesn't. For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has been, an approximation. Actually, it does. What earlier versions never did (despite 'cstrato's repeated delusional claims earlier) was to create the vignettes *in pkginst/doc*. All of them re-created (by default) vignettes in a working directory. The difference is that 2.13.0 deletes that working directory if the test was successful, whereas earlier versions left the results somewhere inpkg.Rcheck (the 'somewhere' has varied). However, earier versions of R CMD check sometimes failed when R CMD build succeeded Using Animal (a small CRAN package with one vignette). R 2.12.2 gave * checking package vignettes in ‘inst/doc’ ... WARNING Package vignettes without corresponding PDF:
[Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. Thanks! Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check and Suggests Packages
Hello, If Dario really uses R 2.13.0 (or newer), and he gets the above error message for a package that is not required but only suggested, I think we'd need a clear, ideally simple, reproducible example, here. I was able to reproduce it. I made a new package with package.skeleton(), then added Suggests: RepitoolsExamples to the DESCRIPTION file, and the result of check was : * using log directory /home/darstr/testPackage.Rcheck * using R version 2.13.0 (2011-04-13) * using platform: x86_64-unknown-linux-gnu (64-bit) * using session charset: UTF-8 * checking for file testPackage/DESCRIPTION ... OK * checking extension type ... Package * this is package testPackage version 1.0 * checking package dependencies ... ERROR Package required but not available: RepitoolsExamples testPackage.tar.gz Description: GNU Zip compressed data __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Tue, May 3, 2011 at 7:44 PM, Yihui Xie x...@yihui.name wrote: Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. The above seems very awkward. If you want to do it temporarily each time you use R its going to be MUCH slower than using batch files since you will have to start up R and then run an R program. To do it permanently implies mucking with your system settings and leaving it in a changed state and that seems worse than the batch file approach which requires no such permanent change. Your (2) is unnecessary using the batch files since they automatically find R regardless of what you name the directory. In other situations if you want to set the path using R you already need to know the path to R in order to run R in the first place and if you know the path to R in order to run it why do you need to set the path? -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On 03/05/2011 7:44 PM, Yihui Xie wrote: Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; Few Windows users use those commands. The ones who do are generally exactly the ones who know how to edit the PATH variable themselves. For most users (the ones who start R from the shortcut), there's no need to mess with the PATH variable. Personally, I hate programs that do that. And with R, it's now complicated, because there are 2 different directories holding executables: bin/i386 and bin/x64. (The bin directory also holds some, but that's just for back compatibility.) How could the installer know which of those to put in the PATH? At installation time, a user isn't going to know which one he/she needs. 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); Multiple installs give you the possibility of reproducing things that don't work in the latest R version. I think it's a good practice to keep multiple installs on your system if you have the space, and since disk space is cheap these days, that's not so uncommon. Duncan Murdoch I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. Thanks! Regards, Yihui -- Yihui Xiexieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA __ 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] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
1. Few Windows users use these commands does not imply they are not useful, and I have no idea how many Windows users really use them. How do you run R CMD build when you build R packages under Windows? You don't write C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build, do you? I think the reason we have to mess with the PATH variable for each single software package is that Windows is Not Unix, so you may hate Windows instead of a package that modifies your PATH variable. For the choice of i386 and x64, you can let the user decide which bin path to use. I believe the number of users who frequently switch back and forth is fairly small. 2. Under most circumstances I just keep the latest version of R. To maintain R code with old R versions will be more and more difficult with new features and changes coming in. Disk space is cheap, but time is not. I'm talking about the default installation directory here and I'm only wishing that the version string could be removed by default. Anyway, I think I will go to the batch files approach if these suggestions are going to be turned down. I just don't want to tell other people to run Rscript.bat under Windows and Rscript under *nix. I hope they can be consistent. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Tue, May 3, 2011 at 8:14 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 03/05/2011 7:44 PM, Yihui Xie wrote: Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; Few Windows users use those commands. The ones who do are generally exactly the ones who know how to edit the PATH variable themselves. For most users (the ones who start R from the shortcut), there's no need to mess with the PATH variable. Personally, I hate programs that do that. And with R, it's now complicated, because there are 2 different directories holding executables: bin/i386 and bin/x64. (The bin directory also holds some, but that's just for back compatibility.) How could the installer know which of those to put in the PATH? At installation time, a user isn't going to know which one he/she needs. 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); Multiple installs give you the possibility of reproducing things that don't work in the latest R version. I think it's a good practice to keep multiple installs on your system if you have the space, and since disk space is cheap these days, that's not so uncommon. Duncan Murdoch I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. Thanks! Regards, Yihui -- Yihui Xiexieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA __ 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] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On May 3, 2011, at 11:25 PM, Yihui Xie wrote: 1. Few Windows users use these commands does not imply they are not useful, and I have no idea how many Windows users really use them. How do you run R CMD build when you build R packages under Windows? You don't write C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build, do you? Yes, of course. It's the safest way and really easy if you use a decent manager (I hope you're not typing your packages tar ball names by hand, either). Adding things to PATH on Windows (unlike unix) has the unwanted consequence that all hell breaks loose due to PATH overriding DLL locations so you really don't want to mess with it. I think the reason we have to mess with the PATH variable for each single software package is that Windows is Not Unix, so you may hate Windows instead of a package that modifies your PATH variable. For the choice of i386 and x64, you can let the user decide which bin path to use. I believe the number of users who frequently switch back and forth is fairly small. 2. Under most circumstances I just keep the latest version of R. To maintain R code with old R versions will be more and more difficult with new features and changes coming in. Disk space is cheap, but time is not. I'm talking about the default installation directory here and I'm only wishing that the version string could be removed by default. It can be already now, so I really have no idea what you're complaining about. If that's what you want, drop the the version and keep the one unversioned directory in your PATH and Bob's your uncle. Cheers, Simon Anyway, I think I will go to the batch files approach if these suggestions are going to be turned down. I just don't want to tell other people to run Rscript.bat under Windows and Rscript under *nix. I hope they can be consistent. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Tue, May 3, 2011 at 8:14 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 03/05/2011 7:44 PM, Yihui Xie wrote: Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; Few Windows users use those commands. The ones who do are generally exactly the ones who know how to edit the PATH variable themselves. For most users (the ones who start R from the shortcut), there's no need to mess with the PATH variable. Personally, I hate programs that do that. And with R, it's now complicated, because there are 2 different directories holding executables: bin/i386 and bin/x64. (The bin directory also holds some, but that's just for back compatibility.) How could the installer know which of those to put in the PATH? At installation time, a user isn't going to know which one he/she needs. 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); Multiple installs give you the possibility of reproducing things that don't work in the latest R version. I think it's a good practice to keep multiple installs on your system if you have the space, and since disk space is cheap these days, that's not so uncommon. Duncan Murdoch I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. Thanks! Regards, Yihui -- Yihui Xiexieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA __ 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
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Tue, May 3, 2011 at 7:44 PM, Yihui Xie x...@yihui.name wrote: Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. Although I have some misgivings about this just to be sure we have all based covered I have placed an R package called cmd in the batchfiles download area (go to http://batchfiles.googlecode.com and click on download tab). Install the package and then every time you wish to use R.exe, Rscript.exe, etc. start up R and run library(cmd) cmd32() # or cmd64() and it will spawn a Windows console session with the appropriate path variable set. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
Thanks! But I'm sorry this is not what I wanted. I just hope we can
call R as a command like we do under *nix -- this will make it easier
for *other* software packages to find R.
BTW, for the cmd package: if we were evil enough, we can directly
execute this in R to permanently set the PATH variable:
system(paste('setx PATH ', normalizePath(R.home('bin')), ';',
Sys.getenv('PATH'), '', sep = ''))
Nobody will feel comfortable with it, though.
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Tue, May 3, 2011 at 11:41 PM, Gabor Grothendieck
ggrothendi...@gmail.com wrote:
Although I have some misgivings about this just to be sure we have all
based covered I have placed an R package called cmd in the batchfiles
download area (go to http://batchfiles.googlecode.com and click on
download tab).
Install the package and then every time you wish to use R.exe,
Rscript.exe, etc. start up R and run
library(cmd)
cmd32() # or cmd64()
and it will spawn a Windows console session with the appropriate path
variable set.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Wed, May 4, 2011 at 3:25 PM, Yihui Xie x...@yihui.name wrote: 1. Few Windows users use these commands does not imply they are not useful, and I have no idea how many Windows users really use them. How do you run R CMD build when you build R packages under Windows? You don't write C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build, do you? I think the reason we have to mess with the PATH variable for each single software package is that Windows is Not Unix, so you may hate Windows instead of a package that modifies your PATH variable. For the choice of i386 and x64, you can let the user decide which bin path to use. I believe the number of users who frequently switch back and forth is fairly small. 2. Under most circumstances I just keep the latest version of R. To maintain R code with old R versions will be more and more difficult with new features and changes coming in. Disk space is cheap, but time is not. I keep old versions for basically the same reasons you don't -- that is, I have analyses that ran under the old versions, and I can be sure they will give the same answer a year later if I keep the old versions. This isn't so much because of changes in R as because of changes in packages. -thomas -- Thomas Lumley Professor of Biostatistics University of Auckland __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Wed, May 4, 2011 at 1:04 AM, Yihui Xie x...@yihui.name wrote: Thanks! But I'm sorry this is not what I wanted. I just hope we can call R as a command like we do under *nix -- this will make it easier for *other* software packages to find R. You asked for an R program that gives the ability to run R.exe, Rscript.exe, etc. from the command line and that indeed is what it enables in the spawned session. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
I also prefer to keep the old versions. Sometimes, I have spent time to set up the system with older version and don't want to update to the latest (e.g. the new RGtk2 needs updated GTk2 as well) because the older still works and I don't need the new features. Regards Ronggui On 4 May 2011 13:26, Thomas Lumley tlum...@uw.edu wrote: On Wed, May 4, 2011 at 3:25 PM, Yihui Xie x...@yihui.name wrote: 1. Few Windows users use these commands does not imply they are not useful, and I have no idea how many Windows users really use them. How do you run R CMD build when you build R packages under Windows? You don't write C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build, do you? I think the reason we have to mess with the PATH variable for each single software package is that Windows is Not Unix, so you may hate Windows instead of a package that modifies your PATH variable. For the choice of i386 and x64, you can let the user decide which bin path to use. I believe the number of users who frequently switch back and forth is fairly small. 2. Under most circumstances I just keep the latest version of R. To maintain R code with old R versions will be more and more difficult with new features and changes coming in. Disk space is cheap, but time is not. I keep old versions for basically the same reasons you don't -- that is, I have analyses that ran under the old versions, and I can be sure they will give the same answer a year later if I keep the old versions. This isn't so much because of changes in R as because of changes in packages. -thomas -- Thomas Lumley Professor of Biostatistics University of Auckland __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Wincent Ronggui HUANG Sociology Department of Fudan University PhD of City University of Hong Kong http://asrr.r-forge.r-project.org/rghuang.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
