[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 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] question about assignment warnings for replacement methods
Hi Simon,
On 11-04-08 01:05 PM, Simon Urbanek wrote:
On Apr 8, 2011, at 2:55 PM, Hervé Pagès wrote:
Hi Duncan, Marc,
On 11-04-05 11:15 AM, Duncan Murdoch wrote:
On 05/04/2011 1:51 PM, Marc Carlson wrote:
Hi,
I have seen several packages that with the most recent version of R are
giving a warning like this:
Assignments in \usage in documentation object 'marginalData-methods':
marginalData(object) = value
I assume that this is to prevent people from making assignments in their
usage statements (which seems completely understandable). But what
about the case above? This is a person who just wants to show the
proper usage for a replacement method. IOW they just want to write
something that looks like what you actually do when you use a
replacement method. They just want to show users how to do something
like this:
replacementMethod(object)<- newValue
So is that really something that should not be allowed in a usage
statement?
If replacementMethod was a replacement function, then
replacementMethod(object)<- newValue
is supposed to be fine.
Yes, 'replacementMethod(object)<- newValue' vorks indeed, but
not 'replacementMethod(object) = newValue'.
But if it is an S3 method, it should be
\method{replacementMethod}{class}(object)<- newValue
and if it is an S4 method I think it should be
\S4method{replacementMethod}{signature_list}(object)<- newValue
In the case reported by Marc, replacementMethod was both: a
replacement (generic) function and a replacement method. And the
man page had an alias for both. Marc replaced
replacementMethod(object) = newValue
with
\S4method{replacementMethod}{signature_list}(object)<- newValue
and that solved the problem. But replacing '=' with '<-' solves it too.
Shouldn't 'R CMD check' treat the 2 assignment operators the same way
since they are equivalent?
They are not equivalent (you can't use = in many places where you can use<-).
I tried to lower the chance of getting a comment like this by saying
"the 2 *assignment* operators are equivalent" but apparently I
failed :-/
Seems to me that the places where I can't replace <- by = are exactly
the places where I would be replacing an assignment operator by
something that is not an assignment operator anymore.
Also my understanding is that it is considered bad practice by some to use = as
assignment outside of the command prompt (interactive use) -- but opinions vary
and I don't want to start a flame war here ;).
I agree with you. I like to be able to directly copy/paste
a <- foo()
into
system.time(... paste it here ...)
and press and have it work. But as you said, opinions may
vary...
Anyway, if 'R CMD check' wants to encourage good practice, fine with
me, but then the warning for 'replacementMethod(object) = newValue'
should be something else and also maybe for consistency the code in
the examples and in the vignette should be checked to detect when =
is used instead of <-
Otherwise, 'R CMD check' should just treat
replacementMethod(object) = newValue
the same way it treats
replacementMethod(object) <- newValue
Thanks,
H.
Cheers,
Simon
Thanks!
H.
(though the manual suggests using the S3 style, I'm not sure how
literally to take it).
Duncan Murdoch
__
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
--
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] deparse operators in expressions
On 10/04/2011 2:08 PM, Yihui Xie wrote: Thanks for pointing out the direction. Since this is unlikely to change in base R, is it possible to change from an add-on package? Of course. Just write your own deparse function. You can start with the code from the standard one, and make any changes you like. Alternatively, just type your code the way you like it, and use keep.source to have it displayed as you entered it. I think it is reasonable to eliminate spaces around ^ and :, but I don't understand why /, %% and %/% should be different with other arithmetic operators like +, - and *. I looked it up, and it has been like that since revision 2 when this code was first committed to our repository in 1997. I imagine whoever wrote it was following the pattern of some other language (maybe S), or maybe just their own personal taste. Duncan Murdoch Regards, Yihui -- Yihui Xie Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sun, Apr 10, 2011 at 8:20 AM, Duncan Murdoch wrote: On 11-04-09 9:43 PM, Yihui Xie wrote: Hi, I observed a slight problem in deparse(): it will add spaces around most operators except /. I wonder if this is easy to fix. I know this is quite trivial, but I will appreciate if / is not treated as an exception. Examples: It's easy to change: take a look at src/main/deparse.c. The operators that are labelled as PP_BINARY2 get no spaces. Looking in src/main/names.c, we see those are /, ^, %%, %/% and :. But clearly this is by design, and I think it's unlikely to change. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish there were a "strict mode" for R interpreter. What about You?
On Apr 10, 2011, at 19:54 , wrote: > On Sun, 10 Apr 2011, Hadley Wickham wrote: > Okay, I understand what you are trying to do. Yes, you have fooled codetools in this instance. >>> >>> ...but notice that the codetools warning is just that: It _is_ acknowledged >>> that these things occasionally happen by design. There are a couple of >>> cases in base R too: >>> >>> * checking R code for possible problems ... NOTE >>> glm.fit: no visible binding for global variable ‘n’ >> >> Are you sure that's not a bug? There's: >> >> aic.model <- aic(y, n, mu, weights, dev) + 2 * rank >> >> and n.ok is defined, but n isn't defined anywhere. > > It is (or should be) defined by the call to > >eval(family$initialize) > ...iff actually used by family$aic. And, it is a different n from n.ok (a vector, the per-element size parameter of the binomial) >> >>> quantile.ecdf: no visible binding for global variable ‘y’ >> >> I wonder why it warns on y, but not nobs. > > It does when run on stats:::quantile.ecdf directly: > >> codetools::checkUsage(stats:::quantile.ecdf) > : no visible binding for global variable ‘nobs’ > : no visible binding for global variable ‘y’ > > Maybe in the context where you saw this nobs is defined in an > enclosing environment. > It came from make check-devel, so I suspect that it picks up stats:::nobs() (which would be horribly wrong, but, well...) > luke > >> >> Hadley -- 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
Re: [Rd] deparse operators in expressions
Thanks for pointing out the direction. Since this is unlikely to change in base R, is it possible to change from an add-on package? I think it is reasonable to eliminate spaces around ^ and :, but I don't understand why /, %% and %/% should be different with other arithmetic operators like +, - and *. Regards, Yihui -- Yihui Xie Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sun, Apr 10, 2011 at 8:20 AM, Duncan Murdoch wrote: > On 11-04-09 9:43 PM, Yihui Xie wrote: >> >> Hi, >> >> I observed a slight problem in deparse(): it will add spaces around >> most operators except /. I wonder if this is easy to fix. I know this >> is quite trivial, but I will appreciate if / is not treated as an >> exception. Examples: > > It's easy to change: take a look at src/main/deparse.c. The operators that > are labelled as PP_BINARY2 get no spaces. Looking in src/main/names.c, we > see those are /, ^, %%, %/% and :. > > But clearly this is by design, and I think it's unlikely to change. > > Duncan Murdoch > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish there were a "strict mode" for R interpreter. What about You?
On Sun, 10 Apr 2011, Hadley Wickham wrote: Okay, I understand what you are trying to do. Yes, you have fooled codetools in this instance. ...but notice that the codetools warning is just that: It _is_ acknowledged that these things occasionally happen by design. There are a couple of cases in base R too: * checking R code for possible problems ... NOTE glm.fit: no visible binding for global variable ‘n’ Are you sure that's not a bug? There's: aic.model <- aic(y, n, mu, weights, dev) + 2 * rank and n.ok is defined, but n isn't defined anywhere. It is (or should be) defined by the call to eval(family$initialize) quantile.ecdf: no visible binding for global variable ‘y’ I wonder why it warns on y, but not nobs. It does when run on stats:::quantile.ecdf directly: codetools::checkUsage(stats:::quantile.ecdf) : no visible binding for global variable ‘nobs’ : no visible binding for global variable ‘y’ Maybe in the context where you saw this nobs is defined in an enclosing environment. luke Hadley -- Luke Tierney 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: l...@stat.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] Wish there were a "strict mode" for R interpreter. What about You?
>> Okay, I understand what you are trying to do. Yes, you have fooled >> codetools in this instance. > > ...but notice that the codetools warning is just that: It _is_ acknowledged > that these things occasionally happen by design. There are a couple of cases > in base R too: > > * checking R code for possible problems ... NOTE > glm.fit: no visible binding for global variable ‘n’ Are you sure that's not a bug? There's: aic.model <- aic(y, n, mu, weights, dev) + 2 * rank and n.ok is defined, but n isn't defined anywhere. > quantile.ecdf: no visible binding for global variable ‘y’ I wonder why it warns on y, but not nobs. 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] Wish there were a "strict mode" for R interpreter. What about You?
On Apr 10, 2011, at 15:10 , Duncan Murdoch wrote:
> On 11-04-09 9:22 PM, Spencer Graves wrote:
>> On 4/9/2011 6:12 PM, Duncan Murdoch wrote:
>>> On 11-04-09 7:02 PM, Spencer Graves wrote:
"R CMD check" will give this message sometimes when I don't feel
it's appropriate. For example, I define a data object ETB in a package,
then give that as the default in a function call like
f(data.=ETB){if(missing(data.))data(ETB); data.}. When I run "R CMD
check", I get "no visible binding for global variable 'ETB'", even
though the function is tested and works during R CMD check.
>>>
>>> What is ETB? Your code is looking for a global variable by that name,
>>> and that's what codetools is telling you.
>>
>> Duncan: Thanks for the question.
>>
>>
>> ETB is a data object in my package. codetools can't find it because
>> data(ETB) is needed before ETB becomes available. codetools is not
>> smart enough to check to see if ETB is a data object in the package.
>
> Okay, I understand what you are trying to do. Yes, you have fooled codetools
> in this instance.
...but notice that the codetools warning is just that: It _is_ acknowledged
that these things occasionally happen by design. There are a couple of cases in
base R too:
* checking R code for possible problems ... NOTE
glm.fit: no visible binding for global variable ‘n’
quantile.ecdf: no visible binding for global variable ‘y’
I can't seem to spot the 'n' just now, though...
--
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
Re: [Rd] Wish there were a "strict mode" for R interpreter. What about You?
On 4/10/2011 6:10 AM, Duncan Murdoch wrote:
On 11-04-09 9:22 PM, Spencer Graves wrote:
On 4/9/2011 6:12 PM, Duncan Murdoch wrote:
On 11-04-09 7:02 PM, Spencer Graves wrote:
On 4/9/2011 2:31 PM, Hadley Wickham wrote:
On Sat, Apr 9, 2011 at 2:51 PM, Paul Johnson
wrote:
Years ago, I did lots of Perl programming. Perl will let you be lazy
and write functions that refer to undefined variables (like R does),
but there is also a strict mode so the interpreter will block
anything
when a variable is mentioned that has not been defined. I wish there
were a strict mode for checking R functions.
Here's why. We have a lot of students writing R functions around
here
and they run into trouble because they use the same name for things
inside and outside of functions. When they call functions that have
mistaken or undefined references to names that they use elsewhere,
then variables that are in the environment are accidentally used.
Know
what I mean?
dat<- whatever
someNewFunction<- function(z, w){
#do something with z and w and create a new "dat"
# but forget to name it "dat"
lm (y, x, data=dat)
# lm just used wrong data
}
I wish R had a strict mode to return an error in that case. Users
don't realize they are getting nonsense because R finds things to
fill
in for their mistakes.
Is this possible? Does anybody agree it would be good?
library(codetools)
checkUsage(someNewFunction)
: no visible binding for global variable ‘y’
: no visible binding for global variable ‘x’
: no visible binding for global variable ‘dat’
Which also picks up another bug in your function ;)
Is this run by "R CMD check"? I've seen this message.
"R CMD check" will give this message sometimes when I
don't feel
it's appropriate. For example, I define a data object ETB in a
package,
then give that as the default in a function call like
f(data.=ETB){if(missing(data.))data(ETB); data.}. When I run "R CMD
check", I get "no visible binding for global variable 'ETB'", even
though the function is tested and works during R CMD check.
What is ETB? Your code is looking for a global variable by that name,
and that's what codetools is telling you.
Duncan: Thanks for the question.
ETB is a data object in my package. codetools can't find it because
data(ETB) is needed before ETB becomes available. codetools is not
smart enough to check to see if ETB is a data object in the package.
Okay, I understand what you are trying to do. Yes, you have fooled
codetools in this instance.
I'm sorry: I did not intend to fool codetools. ;-)
I just wanted to provide sensible defaults in a way that seemed
obvious to me.
Thanks again for all your work on Rtools and the R project more
generally. Spencer
Duncan Murdoch
--
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph: 408-655-4567
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools questions
On Sat, Apr 9, 2011 at 4:40 PM, Duncan Murdoch wrote: > On 11-04-06 2:45 PM, Henrik Bengtsson wrote: >> >> On Wed, Apr 6, 2011 at 4:54 AM, Duncan Murdoch >> wrote: >>> >>> On 11-04-05 7:51 PM, Henrik Bengtsson wrote: On Tue, Apr 5, 2011 at 3:44 PM, Duncan Murdoch wrote: > > On 11-04-05 6:22 PM, Spencer Graves wrote: >> >> Hello: >> >> >> 1. How can I tell when the development version of Rtools has >> changed? > > I don't make announcements of the changes, you just need to check the > web > site. There are online tools that can do this for you automatically, > but > I > don't know which one to recommend. Google suggests lots of them. I also asked myself this before and I must admit it took me a while to interpret the contents of the webpage. There are multiple sections, e.g. 'Changes since R 2.12.2', 'Changes since R 2.11.1', 'Changes since R 2.11.0', and so on. Then within each section there are some dates mentioned. Given my current R version (say R 2.13.0 beta) and Rtools (Rtools213.exe), it not fully clear to me which section to look at, e.g. 'Changes since R 2.12.2'? >>> >>> Well, that depends on when you downloaded it. I use the R version >>> releases >>> as bookmarks. If you last downloaded Rtools after the release of R >>> 2.12.2, >>> then you only need to look at the last section. >>> >>> The problem with collecting changes into those that apply to each Rtools >>> version is just that the change lists would be longer: Rtools212 will >>> get >>> changes through several R releases. When there are compiler changes, >>> RtoolsXYZ generally comes out during the previous R version, because the >>> compiler may only work with the R-devel version. For instance, Rtools212 >>> was introduced between R 2.11.0 and 2.11.1 and was updated a number of >>> times >>> up to quite recently. (It is now frozen, so if you download it now and >>> are >>> working with the R versions it supports you never need to worry about >>> updates to it.) >> >> I understand, and I suspected this was the reason too. >> >>> >>> However, if you want to reformat the page, go ahead, and send me the new >>> version. It's a hand edited HTML page so I'd be happy to incorporate >>> changes that make it more readable, as long as it's still easy to edit by >>> hand. >>> >>> Gabor asked how to know which version was downloaded. If you have the >>> installer file you can tell: right click on it, choose Properties, look >>> at >>> the Version tab. If you didn't keep the installer, I don't know a way to >>> find out, but it might be recorded in the unins000.dat file that the >>> uninstaller uses. Of course, without downloading the new one you can't >>> find >>> out its version: so back to my original suggestion to monitor changes to >>> the web page. I'll see if there's a way to automatically include the >>> revision number in the filename. >> >> This is useful - I didn't know about this version number of InnoSetup. >> I've browsed the online InnoSetup help, but I couldn't locate what >> the version parameter is called. With it, would it be possible to use >> a [Code] block having InnoSetup write the version number to a VERSION >> file in the Rtools installation directory? That would make it >> possible to compare what's online and what's installed. >> >> Another alternative for figuring out if Rtools have changed would be >> to compare the timestamp of the installed Rtools directory (because >> you typically install immediately after download) and the >> Rtools213.exe timestamp on the web server. This could be achieved by >> moving the files to, say, >> http://www.murdoch-sutherland.com/Rtools/download/ and enable indexing >> of files in that directory. >> >> Either way, know about the version number is certainly good enough for >> me. After installing Rtools, I can simply put the installer file in >> the Rtools directory to allow me to compare to it later. (I kind of >> did this before by comparing file sizes.) > > I've just uploaded a small change: now Rtools.txt records the version > number (and if I remember to update it, you can download only that file to > see if you are up to date). There's also a VERSION.txt file that contains > the version number, which is likely to maintain its format more > consistently, so if you want an automatic check, you should look at that > file. It's also on the web site. > Thanks. I have added a batch file to the batchfiles distribution (http://batchfiles.googlecode.com) which locates Rtools and then displays VERSION.txt . If placed on the Windows PATH then issuing this command from the Windows console with no arguments will display the VERSION.txt file: RtoolsVersion A direct link is to the file is here: http://batchfiles.googlecode.com/svn/trunk/RtoolsVersion.bat It finds Rtools from the registry or if not found there looks in C:\Rtools . -- Stati
Re: [Rd] deparse operators in expressions
On 11-04-09 9:43 PM, Yihui Xie wrote: Hi, I observed a slight problem in deparse(): it will add spaces around most operators except /. I wonder if this is easy to fix. I know this is quite trivial, but I will appreciate if / is not treated as an exception. Examples: It's easy to change: take a look at src/main/deparse.c. The operators that are labelled as PP_BINARY2 get no spaces. Looking in src/main/names.c, we see those are /, ^, %%, %/% and :. But clearly this is by design, and I think it's unlikely to change. Duncan Murdoch deparse(expression(1/1)) [1] "expression(1/1)" deparse(expression(1+1)) [1] "expression(1 + 1)" deparse(expression(1%in%1)) [1] "expression(1 %in% 1)" sessionInfo() R version 2.12.2 (2011-02-25) Platform: x86_64-pc-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8 [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8 [7] LC_PAPER=en_US.utf8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base Regards, Yihui -- Yihui Xie 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] Wish there were a "strict mode" for R interpreter. What about You?
On 11-04-09 9:22 PM, Spencer Graves wrote:
On 4/9/2011 6:12 PM, Duncan Murdoch wrote:
On 11-04-09 7:02 PM, Spencer Graves wrote:
On 4/9/2011 2:31 PM, Hadley Wickham wrote:
On Sat, Apr 9, 2011 at 2:51 PM, Paul Johnson
wrote:
Years ago, I did lots of Perl programming. Perl will let you be lazy
and write functions that refer to undefined variables (like R does),
but there is also a strict mode so the interpreter will block anything
when a variable is mentioned that has not been defined. I wish there
were a strict mode for checking R functions.
Here's why. We have a lot of students writing R functions around here
and they run into trouble because they use the same name for things
inside and outside of functions. When they call functions that have
mistaken or undefined references to names that they use elsewhere,
then variables that are in the environment are accidentally used. Know
what I mean?
dat<- whatever
someNewFunction<- function(z, w){
#do something with z and w and create a new "dat"
# but forget to name it "dat"
lm (y, x, data=dat)
# lm just used wrong data
}
I wish R had a strict mode to return an error in that case. Users
don't realize they are getting nonsense because R finds things to fill
in for their mistakes.
Is this possible? Does anybody agree it would be good?
library(codetools)
checkUsage(someNewFunction)
: no visible binding for global variable ‘y’
: no visible binding for global variable ‘x’
: no visible binding for global variable ‘dat’
Which also picks up another bug in your function ;)
Is this run by "R CMD check"? I've seen this message.
"R CMD check" will give this message sometimes when I don't feel
it's appropriate. For example, I define a data object ETB in a package,
then give that as the default in a function call like
f(data.=ETB){if(missing(data.))data(ETB); data.}. When I run "R CMD
check", I get "no visible binding for global variable 'ETB'", even
though the function is tested and works during R CMD check.
What is ETB? Your code is looking for a global variable by that name,
and that's what codetools is telling you.
Duncan: Thanks for the question.
ETB is a data object in my package. codetools can't find it because
data(ETB) is needed before ETB becomes available. codetools is not
smart enough to check to see if ETB is a data object in the package.
Okay, I understand what you are trying to do. Yes, you have fooled
codetools in this instance.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use keep.source for function in package with lazy loading
R-devel now has a KeepSource DESCRIPTION field to accomplish what I think you are seeking. On Tue, 5 Apr 2011, Greg Snow wrote: Prof. Ripley, Thanks for the explanation. I had set both keep.source and keep.source.packages to TRUE for my experiments, but had not realized that a new R process would be involved, so did not try the environmental variable approach. From what you say below, I don't think I am going to accomplish what I wanted, since I want the source to show for users other than myself and there does not seem to be a reasonable way to change the users environment before installing my package (that is getting a bit too big brother to even think about). I was hoping that there might be some switch somewhere that I had missed that would say keep the source for this function even though the default is not to. But, it does not look like there is anything like that, and it is not worth implementing just for my one little use. Hmm, maybe I can set the source manually using .onAttach, I'll have to experiment some more. Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Monday, April 04, 2011 3:41 PM To: Greg Snow Cc: R-devel@r-project.org Subject: Re: [Rd] Use keep.source for function in package with lazy loading On Mon, 4 Apr 2011, Greg Snow wrote: I have a function in one of my packages that I would like to print using the original source rather than the deparse of the function. The package uses lazy loading and the help page for library (under keep.source) says that keep.source does not apply to packages that use lazy loading and that whether those functions keep the source depends on when they are installed. Not quite: it is says it is 'determined when it is installed'. For a package that does not use lazy loading, what is installed is a file of R code. When library() loads such a package, it sources() the R code, and at that point has the option to keep the source or not (for that R session). For a package which uses lazy loading, the source()ing happens when the package is installed: the objects created are then dumped into a database. Whether the source attribute is retained at that point depends on the setting of the option "keep.source.pkgs". So if you can arrange to install the package with that option set to true, in principle (and in my experiments) the source attributes are retained. The easiest way to do this would seem to be to set the environment variable R_KEEP_PKG_SOURCE to "yes" whilst installing the package. This package is on R-forge and is being built there (and will eventually be used to submit the next version of the package to CRAN). I am not sure what the help means by 'installed', I have set the options to keep the source to TRUE before calling install.package, but that does not seem to work. I presume you mean keep.source.pkgs, not keep.source? That needs to be set in the process which is installing the package: install.packages() calls R CMD INSTALL in a separate process. Is there a way to "strongly encourage" the source to be kept for this function (or the entire package)? Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 -- 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 -- 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
