Re: [Rd] Underscores in package names

[Kevin Wright]

Please, no.  I'd also like to disallow uppercase letters in package names.
For instance, the cuteness of using a capital "R" in package names is
outweighed by the annoyance of trying to remember which packages use an
upper-case letter.

On Thu, Aug 8, 2019 at 9:32 AM Jim Hester  wrote:

> Are there technical reasons that package names cannot be snake case?
> This seems to be enforced by `.standard_regexps()$valid_package_name`
> which currently returns
>
>"[[:alpha:]][[:alnum:].]*[[:alnum:]]"
>
> Is there any technical reason this couldn't be altered to accept `_`
> as well, e.g.
>
>   "[[:alpha:]][[:alnum:]._]*[[:alnum:]]"
>
> I realize that historically `_` has not always been valid in variable
> names, but this has now been acceptable for 15+ years (since R 1.9.0 I
> believe). Might we also allow underscores for package names?
>
> Jim
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Kevin Wright

[[alternative HTML version deleted]]

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

Re: [Rd] Underscores in package names

[Kevin Wright]

hat would
> handle
> > >> the more general package names. I just don't personally see a
> motivation
> > >> that justifies changing something this fundamental (even if it is
> both
> > >> narrow and was initially more or less arbitrarily chosen) about R
> at
> > >> this late date.
> > >>
> > >> I guess at the end of the day, I guess what I'm saying is that
> breaking
> > >> and changing things is sometimes good, but if we're going to rock
> the
> > >> boat personally I'd want to do so going after bigger wins than
> this one.
> > >> Thats just my opinion though.
> >
> > > Sorry, I wasn't clear.  I agree with you.  I was just saying that
> the
> > > particular argument based on ugly tarball names isn't the reason.
> >
> > > Duncan Murdoch
> >
> > Thank you (and Gabe).
> >
> > We have had some R core internal "talk" about Jim Hester's
> > suggestion (of adding underscores to the allow characters in
> > package names).
> > Duncan had already given a good reason why such a change would be
> problematic
> > (the underscore being used as unique separator of package name
> >  and version in source and binary package archives),
> > and with Jim's offer to find and provide patches for all places
> > this is used in the R sources, we've convinced ourselves that
> > there is much more code "out there", notably 'devops' code in
> > scripts, which currently relies on the current package naming
> > rules and which could break, often only rarely and hence
> > possibly unnoticed for too long.
> >
> > Also, we've not seen compelling arguments why the current scheme
> > would be too limited (people mentioned that if you must use a
> > separator, "." was available).
> >
> > Consequence:  We stay with the stability principle and the
> > package naming scheme is _not_ going to be changed for now.
> >
> > Martin Maechler
> > ETH Zurich and R Core Team
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Kevin Wright

[[alternative HTML version deleted]]

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

Re: [Rd] No RTFM?

[Kevin Wright]

Recently I was visiting with people about why commercial support is needed
for some people using R.  One person observed:

With commercial support, you have a person that you can call with questions
and yell at.
With R mailing lists, you can ask questions and have people yell at YOU.

The atmosphere of the R-help and R-devel mailing lists is infamous.  Is this
a good reputation to have?  I'm doubtful that it is.

So, I support Spencer's suggestion for more civility.

Kevin Wright


On Thu, Aug 19, 2010 at 7:08 PM, Spencer Graves <
spencer.gra...@structuremonitoring.com> wrote:

>  What do you think about adding a "No RTFM" policy to the R mailing lists?
> Per, "http://en.wikipedia.org/wiki/RTFM":
>
>
> The Ubuntu Forums and LinuxQuestions.org, for instance, have instituted "no
> RTFM" policies to promote a welcoming atmosphere.[8][9].
>
> RTFM [and] "Go look on google" are two inappropriate responses to a
> question. If you don't know the answer or don't wish to help, please say
> nothing instead of brushing off someone's question. Politely showing someone
> how you searched or obtained the answer to a question is acceptable, even
> encouraged.
> ...
>
> If you wish to remind a user to use search tools or other resources when
> they have asked a question you feel is basic or common, please be very
> polite. Any replies for help that contain language disrespectful towards the
> user asking the question, i.e. "STFU" or "RTFM" are unacceptable and will
> not be tolerated. —Ubuntu Forums
>
>
> Gavin Simpson and I recently provided examples answering a question from
> "r.ookie" that had previously elicited responses, ""You want us to read the
> help page to you?" and "It yet again appears that you are asking us to read
> the help pages for you."
>
>
> I can appreciate the sentiment in fortunes('rtfm'). In this case, however,
> "r.ookie" had RTFM (and said so), but evidently the manual was not
> sufficiently clear.
>
>
> Best Wishes,
> Spencer Graves
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Kevin Wright

[[alternative HTML version deleted]]

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

Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code

[Kevin Wright]

For those of you "familiar with R", here's a little quiz.  What what's the
difference between:


f1 <- function(){
  a=5
}
f1()

f2 <- function(){
  return(a=5)
}
f2()


Kevin Wright




On Tue, Feb 15, 2011 at 3:55 PM, Geoff Jentry wrote:

> On Wed, 16 Feb 2011, David Scott wrote:
>
>> 4. We don't want gratuitous use of "return" at the end of functions.
>>> Why do people still do that?
>>>
>> Well I for one (and Jeff as well it seems) think it is good programming
>> practice. It makes explicit what is being returned eliminating the
>> possibility of mistakes and provides clarity for anyone reading the code.
>>
>
> You're unnecessarily adding the overhead of a function call by explicitly
> calling return().
>
> Sure it seems odd for someone coming from the C/C++/Java/etc world, but
> anyone familiar with R should find code that doesn't have an explicit
> return() call to be fully readable & clear.
>
> -J
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Phrase "package writer" in R-exts

[Kevin Wright]

Considering that the package.skeleton() function really is a "package
writer" of sorts, I agree that "package author" is clearer.

Kevin


On Fri, Apr 1, 2011 at 1:22 PM, Davor Cubranic  wrote:

> In a conversation with a programmer new to writing R packages, he mentioned
> that he was very confused by phrase "package writer" used in the document,
> and said that he "[was] literally imagining some sort of function that
> writes something related to packages".
>
> I can see his point: not only is it confusing, but I think it's also bad
> English (one wouldn't say "the novel's writer"). Can this be changed to
> "package author"?
>
> Davor
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Statistical mode

[Kevin Wright]

Arni,

Here are two examples:

R> statmode(iris)
Sepal.Length  Sepal.Width Petal.Length  Petal.Width  Species
 "5"  "3""1.4""0.2" "setosa"
R> table(iris$Species)

setosa versicolor  virginica
50 50 50

R> library(lattice)
R> statmode(barley)
 yieldvariety   year   site
"20.6" "Svansota" "1932" "Grand Rapids"

My thoughts:
1. The mode is not so interesting for continuous data.  I would much rather
use something like density().
2. Both the iris and barley data sets are balanced (each factor level
appears equally often), and the current output from the statmode function is
misleading by only showing one level.
3. I think the describe() function in the Hmisc package is much more useful
and informative, even for introductory stat classes.  I always use
describe() after importing data into R.

Kevin



On Thu, May 26, 2011 at 3:26 PM, Arni Magnusson  wrote:

> One descriptive statistic that is conspicuously missing from core R is the
> statistical mode - the most frequent value in a discrete distribution.
>
> I would like to propose adding the attached 'statmode' (or a similar
> function) to the 'stats' package.
>
> Currently, it can be quite cumbersome to calculate the mode of a
> distribution in R, both for experts and beginners. The lack of a function to
> do this is felt, both when teaching introductory R courses, and when using
> sapply() or the like.
>
> Looking forward to your feedback,
>
> Arni
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] License question

[Kevin Wright]

With open source software, you can do anything you want on your own
computer.  The difficult questions arise when you want to re-distribute
software.

You have provided very little context for your question, so the standard
answer on this email list is "Talk to your lawyer".

Kevin


On Tue, Aug 16, 2011 at 7:44 AM, Uwe Schmitt  wrote:

>
> Hi,
>
> I'm not sure if this is the right mailing list for my question,
> so please redirect me if this is the wrong place for the
> following question:
>
> Am I allowed to include R.dll and Rblas.dll in other software ?
>
> In my case I'm want to run some R commands from a Python script
> and save the results. I tried RPy2 which has some trouble running
> on Windows.
>
> Regards, Uwe
>
>
>
> --
>
> Dr. rer. nat. Uwe Schmitt
> Forschung & Entwicklung Mathematik
>
> mineway GmbH
> Gebäude 4
> Im Helmerswald 2
> 66121 Saarbrücken
>
> Telefon: +49 (0)681 8390 5334
> Telefax: +49 (0)681 830 4376
>
> uschm...@mineway.de
> www.mineway.de
>
> Geschäftsführung: Dr.-Ing. Mathias Bauer
> Amtsgericht Saarbrücken HRB 12339
>
> __**
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/**listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] New URL redirect checks

[Kevin Wright]

Isn't the whole concept of DOI basically link-shortening/redirecting?

For example, this link
https://doi.org/10.2134/agronj2016.07.0395
redirects to
https://acsess.onlinelibrary.wiley.com/doi/abs/10.2134/agronj2016.07.0395

As a side note, I got so fed up with CRAN check complaints about (perfectly
valid) re-directs that I refuse to use the \url{} tag anymore.

Kevin


On Thu, Sep 17, 2020 at 8:32 AM Yihui Xie  wrote:

> I don't have an opinion on the URL shorteners, but how about the
> original question? Redirection can be extremely useful in general.
> Shortening URLs is only one of its possible applications. FWIW, CRAN
> uses (303) redirect itself, e.g.,
> https://cran.r-project.org/package=MASS is redirected to
> https://cran.r-project.org/web/packages/MASS/index.html Should these
> "canonical" CRAN links be disallowed in packages, too? Just as another
> example, https://cran.r-project.org/bin/windows/base/release.html is
> redirected to the latest Windows installer of R (through the 
> tag).
>
> If the intent of the new URL redirect check is to disallow using URL
> shorteners like bit.ly or nyti.ms, that may be fair, but it it is to
> disallow using any URLs that are redirected, I think this CRAN policy
> may be worth a reconsideration.
>
> Regards,
> Yihui
> --
> https://yihui.org
>
>
> On Thu, Sep 17, 2020 at 3:26 AM Gábor Csárdi 
> wrote:
> >
> > Right, I am sorry, I did not realize the security aspect here. I guess
> > I unconsciously treated CRAN package authors as a trusted source.
> >
> > Thanks for the correction and clarification, and to CRAN for
> > implementing these checks. :)
> >
> > G.
> >
> > On Wed, Sep 16, 2020 at 10:50 PM Duncan Murdoch
> >  wrote:
> > >
> > > On 16/09/2020 4:51 p.m., Simon Urbanek wrote:
> > > > I can't comment for CRAN, but generally, shorteners are considered
> security risk so regardless of the 301 handling I think flagging those is a
> good idea. Also I think it is particularly bad to use them in manuals
> because it hides the target so the user has no idea what hey will get.
> > >
> > > I agree, and we do have \href{}{} in Rd files and similar in other
> > > formats for giving text of a link different than the URL if the URL is
> > > inconveniently long.  There's still a bit of a security issue though:
> > > the built in help browser (at least in MacOS) doesn't show the full URL
> > > when you hover over the link, as most browsers do.  So one could have
> > >
> > > \href{https://disney.org}{https://horrible.web.site}
> > >
> > > Duncan Murdoch
> > >
> > >
> > > >
> > > > Cheers,
> > > > Simon
> > > >
> > > >
> > > >> On Sep 17, 2020, at 5:35 AM, Gábor Csárdi 
> wrote:
> > > >>
> > > >> Dear all,
> > > >>
> > > >> the new CRAN URL checks flag HTTP 301 redirects. While I understand
> > > >> the intent, I think this is unfortunate, because several URL
> shortener
> > > >> services use 301 redirects, and often a shorter URL is actually
> better
> > > >> in a manual page than a longer one that can be several lines long in
> > > >> the console and also potentially truncated in the PDF manual.
> > > >>
> > > >> Some example shorteners that are flagged:
> > > >>
> > > >>> db <- tools:::url_db(c("https://nyti.ms";, "https://t.co/mtXLLfYOYE";),
> "README")
> > > >>> tools:::check_url_db(db)
> > > >> URL: https://nyti.ms (moved to https://www.nytimes.com/)
> > > >> From: README
> > > >> Status: 200
> > > >> Message: OK
> > > >>
> > > >> URL: https://t.co/mtXLLfYOYE (moved to
> > > >> https://www.bbc.co.uk/news/blogs-trending-47975564)
> > > >> From: README
> > > >> Status: 200
> > > >> Message: OK
> > > >>
> > > >> __
> > > >> 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
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Kevin Wright

[[alternative HTML version deleted]]

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

Re: [Rd] Minimum requirements for package submission

[Kevin Wright]

> As long as your package passes R CMD check --as-cran on the
> development version of R, CRAN will be happy.  They do not generally
> read your source code, and CRAN does not certify that your package is
> useful or even correct - so you don't need to worry about what your
> package does.
>
> I, for one, hope that you DO worry about what your package does.  :-)


> > 2. Does the vignette need to be written in latex or can I get away with
> > writing all of the requirements in word? (I believe I've seen a vignette
> > written in word -> pdf)
>

 Before knitr became an accepted engine for vignettes, I had a
knitr-generated vignette that I included in a package.  It could just as
easily have been a Word file saved as a pdf.  There was some trick to doing
this (which I have forgotten).  Something like creating an extremely
minimal .rnw file and then including the vignette with the same name and a
.pdf extension.  Search the R-help mail archives and you can find other
people who have included non-.rnw vignettes.

Kevin

[[alternative HTML version deleted]]

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

Re: [Rd] readRDS and saveRDS

[Kevin Wright]

Not only is it fun to think about a generic load function, I created one and
it is a pleasure to use--avoids the inconsistent function names that
prompted your post.  What's more important, language purity (S3 methods) or
making life simpler for the users (consistency)?
This "import" is not a true S3 generic, but handles: clipboard, csv, rda,
rdata, txt, xls, xlsx.  (You have to load one of the packages that has a
read.xls function--there are several different ones).  A corresponding
"export" function can similarly be defined.  Loosely inspired by importData
from S-Plus.

Kevin

import <- function(file, sheet=1, header=TRUE, ...){

  if(file=="clipboard") {
dat <- read.table(file="clipboard", header=header, sep='\t',
na.strings=c('NA','*'),
as.is=TRUE)
return(dat)
  }

  # Otherwise 'file' is on a disk
  stopifnot(file.exists(file))

getFileExtension <- function(file){
  dotpos <- regexpr("\\.+[[:alnum:]]+$", file)
  substring(file, ifelse(dotpos<1, 1000, dotpos+1))
}

  ext <- casefold(getFileExtension(file))

  if(ext=="csv")
dat <- read.csv(file, header, ...)
  else if (ext=="rdata" | ext=="rda") {
## # Note, 'load' loads the data inside the frame of the 'import'
function
## # and returns the name of the object.  We have to do some trickery
## # to move the data into 'our' object named 'dat'.
dat <- local({objname <- load(file); get(objname)})
  } else if (ext=="txt")
dat <- read.table(file, sep="\t", header, ...) # header=FALSE
  else if (ext=="xls") {
dat <- read.xls(file, sheet, ...)
  } else if (ext=="xlsx") {
require("xlsx")
dat <- read.xlsx(file, sheet, header, ...)
  } else {
stop("Unknown file extension")
  }
  return(dat)
}



On Tue, Oct 18, 2011 at 3:36 PM, Hadley Wickham  wrote:

> >> Ending names in .foo is a bad idea because of the S3 naming conventions,
> so
> >> I think this is unlikely.  But you can always create an alias
> yourself...
> >
> > I always thought that S3 was part of the reason for read.ext write.ext.
> In:
> >
> > "/path/file.ext"
> >
> > the "class" of the file is "ext".  I kind of like the idea of taking
> > this farther, generic functions read/write dispatch to the appropriate
> > method depending on the class of the file.  Generally, only read/write
> > would be used, specifying the specific method as needed.  read.rda and
> > write.rda could replace load/save where: dat <- read.rda() would
> > create an environment, dat rather than simply loading them into the
> > global environment.
> >
> > Though this is more of a hypothetical situation than a suggestion for
> change.
>
> That makes me think of a generic read that would dispatch not on the
> class of the first argument (which would always be a string), but
> would instead dispatch on the file extension.  So read("x.csv") would
> call read.csv, read("cache.rds") would use readRDS etc. Of course it
> doesn't work in complete generality, but it's a fun idea to think
> about.
>
> 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
>

[[alternative HTML version deleted]]

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

Re: [Rd] readRDS and saveRDS

[Kevin Wright]

Hadley,

Any chance of changing fun.aggregate to FUN and value_var to value.var?

aggregate(.., FUN, ...)
acast(..., fun.aggregate, ...)

cast(..., value.var)
acast(..., value_var)

Side note: My fantasy for R 3.0 would be to fix the obvious inconsistencies
in function names/arguments, use Roxygen format for the documentation,
change the egregious [ , , drop=TRUE] to FALSE and paste(..., sep=""),
install packages on the fly, and improve consistency for functions dealing
with colors (hex, 0-1, 0-255, etc).

Kevin


On Tue, Oct 18, 2011 at 8:37 AM, Hadley Wickham  wrote:

> Hi all,
>
> Is there any chance that readRDS and saveRDS might one day become
> read.rds and write.rds?  That would make them more consistent with the
> other reading and writing functions.
>
> 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
>

[[alternative HTML version deleted]]

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

Re: [Rd] Error message library()

[Kevin Wright]

Thierry,

I agree with you and think that computers _should_ help users.

When R tells me a package does not exist, it is almost never because I
typed an incorrect package name.

Almost always it is because:
(1) I am using an old script with a new version of R and have not yet
installed a package.
(2) I am running a current script on a different machine that does not have
a package installed.
(3) I am copying some code from the web and have not yet installed a
package.

MiKTeX does a nice job of auto-installing packages in a silent manner.
I've tried to imitate that with the function below.  I add this to
.Rprofile.  Then use "lib(pkg)" to install and attach packages
automatically.  The function is rough and needs improvement, but works
reasonably well.

Kevin


assign("lib",
   function(p=NULL, ...){
 # Why ... ?
 p <- substitute(p)
 if(!is.null(p) & !is.character(p))
   p <- deparse(substitute(p))
 print(p)
 ip <- rownames(installed.packages())
 # Should be more clever here and only install some of 'p'
 if(!(p %in% ip)) install.packages(p)

 require(p, ..., character.only=TRUE)
   }, env=startup)



On Wed, Oct 26, 2011 at 4:46 AM, ONKELINX, Thierry  wrote:

> Dear all,
>
> When one tries to load a non-installed package you get the error:
>
> Error in library(xyz) : there is no package called 'xyz'
>
> I noticed on several occasions that this puzzles beginners. Therefore I
> suggest to change the error description in:
>
> Error in library(xyz) : there is no package called 'xyz' installed on this
> machine. Check the name of the package or use install.packages("xyz") to
> install it.
>
> Best regards,
>
> Thierry
>
>
> 
> ir. Thierry Onkelinx
> Instituut voor natuur- en bosonderzoek
> team Biometrie & Kwaliteitszorg
> Gaverstraat 4
> 9500 Geraardsbergen
> Belgium
>
> Research Institute for Nature and Forest
> team Biometrics & Quality Assurance
> Gaverstraat 4
> 9500 Geraardsbergen
> Belgium
>
> tel. + 32 54/436 185
> thierry.onkel...@inbo.be
> www.inbo.be
>
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of.
> ~ Sir Ronald Aylmer Fisher
>
> The plural of anecdote is not data.
> ~ Roger Brinner
>
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Help page of colors() : add a new example ?

[Kevin Wright]

Gael,

Your graph has a lot of white space.  Is that intentional?  I've seen
similar code in other places that uses less white space.

Here's another option for choosing ANY color, not just pre-defined colors.

require(tcltk)
tclvalue(tcl("tk_chooseColor"))


Kevin

On Mon, Jan 30, 2012 at 8:46 AM, Millot Gael  wrote:

> Dear all,
>
> May I suggest to add an example in the help page of the colors() function ?
> The following code could be useful to easily choose any color from
> colors() :
>
> ## Millot G. (2011), p.71.
> ## Figure displaying all the 657 built-in color names of colors().
> palette(colors())
> tempo<-NULL
> for(i in 14:1){tempo<-c(tempo, rep(i,50))}
> windows(width=10) # replace by quartz(width=10) for MacOS and by
> X11(width=10) for Linux
> par(ann=FALSE, xaxt="n", yaxt="n", bty="n")
> plot(rep(1:50,14)[1:657], tempo[1:657], pch=22, bg=1:657, cex=1.5, bty="n")
> par(xpd=TRUE)
> axis(side=2, at=14:1, labels=, cex.axis=1.5, srt=90)
> text(rep(-2, 14), 14:1, as.character((0:13)*50+1), srt=0, cex=1)
> text(c(10,20,30,40,50), rep(-0.5,5), c(10,20,30,40,50), srt=0, cex=1)
>
> ## palette(colors()) allow to replace the color names by the numbers
> indicated
> ## in the figure.
> palette(colors())
> plot(1, col=630, pch=16, cex=10) # 630 is "tomato"
>
> This code comes from the page 71 of the book I published in french:
> Millot G. Comprendre et réaliser les tests statistiques à l'aide de R, 2nd
> edition. De Boeck editions, Bruxelles . 2011, 767 pages.
>
> I wrote it since my students usually complain about the difficulty to
> select a color
> from colors() when the names are displayed.
>
> Kind regards,
>
> Gael Millot.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Kevin Wright

[[alternative HTML version deleted]]

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

Re: [Rd] CRAN policies

[Kevin Wright]

t; >
> > The only part that I don't see is the mechanism to add code-walker
> functions to
> > the environment in codetools that has the standard list of them for
> functions with
> > nonstandard evaluation:
> >  > objects(codetools:::collectUsageHandlers, all=TRUE)
> >   [1] "$" "$<-"   ".Internal"
> >   [4] "::"":::"   "@"
> >   [7] "@<-"   "{" "~"
> >  [10] "<-""<<-"   "="
> >  [13] "assign""binomial"  "bquote"
> >  [16] "data"  "detach""expression"
> >  [19] "for"   "function"  "Gamma"
> >  [22] "gaussian"  "if""library"
> >  [25] "local" "poisson"   "quasi"
> >  [28] "quasibinomial" "quasipoisson"  "quote"
> >  [31] "Quote" "require"   "substitute"
> >  [34] "with"
>
> It seems like we really need a standard way to add metadata to functions:
>
> attr(with, "special_args") <- "expr"
> attr(lm, "special_args") <- c("formula", "weights", "subset")
>
> This would be useful because it could automatically contribute to the
> documentation.
>
> Similarly,
>
> attr(my.new.method, "s3method") <- c("my.new", "method")
>
> could be useful.
>
> 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
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Kevin Wright

[[alternative HTML version deleted]]

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

Re: [Rd] setting global options for a package

[Kevin Wright]

Have you considered the lattice package?  The defaults can be
accessed/changed via trellis.par.get(), but also passed as arguments
into the functions.

Kevin


On Thu, May 10, 2012 at 8:59 AM, Michael Friendly  wrote:
> This may be elementary, but I can't find an answer: How can I set up global
> options for
> some specific arguments to functions in a package which can be easily
> changed by the user?
>
> This question relates to the selection of colors used in functions in
> several packages (heplots,
> genridge), where I want to provide reasonable default values for plots, but
> allow users to
> change those defaults globally for all plots produced with my functions.
>
> One solution is to use palette() for the default, as in
>
> foo <- function(x, col=palette(), ...)  {}
> but the standard palette is not appropriate for my use, and I'd rather not
> hijack more typical uses
>
> Another is to use an explicit list of colors for default, as in
>
> bar <- function(x, col=c('red', 'blue', 'brown', 'darkgreen', ...), ...)  {}
> but this must be overridden each time by someone to wants to change the
> defaults.
>
> options() seems like the way to go, but I'm not sure how to implement this.
>  If I use
> a .onLoad function to set some options, will these be created in the global
> environment?
> If not, how to make them so?
>
> .onLoad <- function() {
>  options(heplot.colors =
>  c("red", "blue", "black", "darkgreen", "darkcyan","magenta",
> "brown","darkgray"))
> }
>
> My function could then use
>
> foo <- function(x, getOption("heplot.colors"), ...)  {}
>
>
> --
> Michael Friendly     Email: friendly AT yorku DOT ca
> Professor, Psychology Dept.
> York University      Voice: 416 736-5115 x66249 Fax: 416 736-5814
> 4700 Keele Street    Web:   http://www.datavis.ca
> Toronto, ONT  M3J 1P3 CANADA
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Kevin Wright

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

Re: [Rd] Defining a method in two packages

[Kevin Wright]

Sorry for one more email, but here is a more concise and pertinent "ranef"
example:

# Allow S4 methods to find S3 asreml objects
setOldClass("asreml")

if(!isGeneric("ranef")){
  setGeneric("ranef", function(object, ...) standardGeneric("ranef"))
}

ranef.asreml <- function(obj){
  effects <- obj$coefficients$random
  class(effects) <- c("ranef.asreml",class(effects))
  return(effects)
}

print.ranef.asreml <- function(x, ...){
  print.default(x)
}


Kevin


On Fri, Mar 5, 2010 at 10:47 AM, Terry Therneau  wrote:

> The coxme package has a ranef() method, as does lme4.  I'm having
> trouble getting them to play together, as shown below.  (The particular
> model in the example isn't defensible, but uses a standard data set.)
>
> The problem is that most of the time only one of lme4 or coxme will be
> loaded, so each needs to define the basic ranef function as well as a
> method for it.  But when loaded together the last one wins.  The coxme
> object is an S3 class BTW. (Suggestions to convert it to S4 will not be
> well recieved -- but that's a different and unnecessary thread.)
>
> Odds are that this has a simple solution which I have missed.
> Terry Therneau
>
>
> tmt935% R --vanilla
>
> R version 2.10.0 (2009-10-26)
> Copyright (C) 2009 The R Foundation for Statistical Computing
> ISBN 3-900051-07-0
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
>  Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
> > library(coxme)
> Loading required package: survival
> Loading required package: splines
> Loading required package: bdsmatrix
>
> > fit <- coxme(Surv(time, status) ~ age + (1|ph.ecog), lung)
> > ranef(fit)
> $ph.ecog
> Intercept
> 0.1592346
>
> > library(lme4)
> Loading required package: Matrix
> Loading required package: lattice
>
> Attaching package: 'lme4'
>
>
>The following object(s) are masked from package:coxme :
>
> fixef,
> ranef
>
> > ranef(fit)
> Error in function (classes, fdef, mtable)  :
>  unable to find an inherited method for function "ranef", for signature
> "coxme"
> > q()
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Kevin Wright

[[alternative HTML version deleted]]

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

[Rd] Solved two problems with Cygwin

[Kevin Wright]

While installing software on a new computer, I thought I would try to use
Cygwin to build an R package.  (Note: NOT Ripley/Murdoch's Rtools).

I uncovered and solved two issues, one of which appears to be identical to a
problem previously reported (and unsolved) on this list.  I offer this
information in case it will be helpful.

(1) Cygwin defaults to UNIX mode when installed, but it appears to be
necessary to choose DOS/text mode in order to build R packages.

> Rcmd check mypkg

* checking for working latex ... OK
* using log directory 'x:/Rpkgs/mypkg.Rcheck'
' __ignored__  R version 2.4.1 (2006-12-18)
* checking for file 'mypkg/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'mypkg' version '1.0'
* checking package dependencies ... ERROR
During startup - Warning messages:
' in: library(package, lib.loc = lib.loc, character.only = TRUE, logical =
TRUE,
 in options("defaultPackages") was not found


Manual inspection the mypkg.Rcheck/00install.log file shows:

* using log directory 'x:/Rpkgs/mypkg.Rcheck'

* using ARGUMENT '
' __ignored__  R version 2.4.1 (2006-12-18)


and so forth.  The problem for me was that Cygwin was installed using the
recommended UNIX mode.  I re-ran the cygwin installer and installed a simple
package (Games/fortune is a nice one) and chose DOS/text mode for files,
which solved this problem.


(2) Do not use make-3.81.

> Rcmd build mypkg

Using auto-selected zip options ' mypkg-HELP=ziponly'
c:/R/R241/src/gnuwin32/MakePkg:89: *** multiple target patterns.  Stop.
make[1]: *** [pkg-mypkg] Error 2
*** Installation of mypkg failed ***

Looking in mypkg/00install.out is more helpful:

c:/R/R241/src/gnuwin32/MakePkg:118: *** target pattern contains no `%'.
Stop.
make: *** [pkg-mypkg] Error 2
*** Installation of my failed ***

This appears to be a problem with the current (Jan 2007) version of make
(make 3.81) which appears to drop support for Windows paths that contain a
colon. See: http://www.cygwin.com/ml/cygwin/2006-07/msg00373.html

make 3.80 is available here:
http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites

Once I downgraded make from version 3.81 to version 3.80, I was able to
build R packages.

My setup: Windows XP Pro, R 2.4.1, current Cygwin.


Kevin Wright

[[alternative HTML version deleted]]

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

[Rd] Is formula(data.frame) documented?

[Kevin Wright]

The Examples section of 'unstack' includes:

formula(PlantGrowth) # check the default formula

I wanted to add a formula to my own data.frame (for unstacking), so I
start looking:
?formula  # Nothing here about adding a formula to data
attr(PlantGrowth, "formula") # Nothing here--c.f. groupedData objects
dput(PlantGrowth) # Hmm, no formula here either
?formula.data.frame # Aliased to formula.  Growing more frustrated.

After more experimentation, I guessed that 'formula.data.frame' is
using the first column as the response and other columns as model
terms.  Eventually I had the idea to look in S-Plus:

?formula.data.frame

This is a method for the function formula() for objects inheriting
from class data.frame. If object is a model frame, the formula for the
model frame is returned, otherwise a formula is deduced from the names
of object. The first name is taken to be the response, and all the
remaining names are pasted together additively.

Ah.  Simple, lucid.

Two notes:

1. Would it be possible to add documentation for formula.data.frame?
(I can create a .Rd file--just ask).

2. General comment to the R community: As a user, I sometimes find
that it would be much clearer to have separate help files with links
in the 'See Also' section rather than using 'aliased' help for
multiple functions in a single file.  (I readily admit that separate
help files are more work...)

Thanks,

K Wright

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

Re: [Rd] formula(CO2)

[Kevin Wright]

About a month ago I had a similar issue related to 'formula':
http://tolstoy.newcastle.edu.au/R/e2/devel/07/05/3329.html

In summary:

In S-Plus, the help for formula.data.frame says:
This is a method for the function formula() for objects inheriting
from class data.frame. If object is a model frame, the formula for the
model frame is returned, otherwise a formula is deduced from the names
of object. The first name is taken to be the response, and all the
remaining names are pasted together additively.

In R, the help for formula.data.frame is aliased to the help for
formula, but does not clearly document the usage with data.frames.

Kevin

On 7/16/07, Gabor Grothendieck <[EMAIL PROTECTED]> wrote:
> The formula attribute of the builtin CO2 dataset seems a bit strange:
>
> > formula(CO2)
> Plant ~ Type + Treatment + conc + uptake
>
> What is one supposed to do with that?  Certainly its not suitable for
> input to lm and none of the examples in ?CO2 use the above.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

[Rd] Building package with R 2.6.0 on Windows/Cygwin gives error with tar

[Kevin Wright]

My setup:
Windows XP, R-2.6.0, Cygwin (not the Rtools version)

When I tried to build a package, I was given this message:
tar: c\:/X/Rpkgs/Drydown_1.41.tar: Cannot open: Input/Output error

Even manually typing the following caused the same error:
tar chf 'c:/X/Rpkgs/Drydown_1.41.tar' Drydown

I looked at the 2.5.1 and 2.6.0 build scripts.  After restoring this
section to the 2.6.0 build script:
  ## workaround for paths in Cygwin tar
  $filepath =~ s+^([A-Za-z]):+/cygdrive/\1+;
  }
then $filepath evaluates to
  /cygdrive/c/X/Rpkgs/Drydown_1.41.tar
and I was able to build packages again.

(Posted in case someone else has the same problem and/or finds this useful.)

Kevin Wright

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

Re: [Rd] Building package with R 2.6.0 on Windows/Cygwin gives error with tar

[Kevin Wright]

I tried setenv TAR="tar --force-local" and also tried changing the
build script directly to
R_system(join(" ",
  ("tar --force-local -chf",
   &shell_quote_file_path($filepath),
   "$pkgname")));
but still had this error:
tar: Cannot execute remote shell: No such file or directory
tar: c\:/x/rpkgs/Drydown_1.41.tar: Cannot open: Input/Output error

Replacing R_system with print confirms that $filepath does not have
the backslash.

Curiously, at the bash prompt, this does work:
tar --force-local -chf "c:/X/Rpkgs/Drydown_1.41.tar" Drydown

Maybe a confusion between R_system and bash ???

I'm happy to help test this further, but with the hack reported at the
start of this thread I'm also content to let this drop (or go off
list).

Kevin Wright



On 10/5/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> Try setting TAR to 'tar --force-local'.
>
> This should be the default under Windows, but a typo was introduced in R
> 2.6.0 after it was tested.
>
> On Thu, 4 Oct 2007, Kevin Wright wrote:
>
> > My setup:
> > Windows XP, R-2.6.0, Cygwin (not the Rtools version)
> >
> > When I tried to build a package, I was given this message:
> > tar: c\:/X/Rpkgs/Drydown_1.41.tar: Cannot open: Input/Output error
> >
> > Even manually typing the following caused the same error:
> > tar chf 'c:/X/Rpkgs/Drydown_1.41.tar' Drydown
> >
> > I looked at the 2.5.1 and 2.6.0 build scripts.  After restoring this
> > section to the 2.6.0 build script:
> >  ## workaround for paths in Cygwin tar
> >  $filepath =~ s+^([A-Za-z]):+/cygdrive/\1+;
> >  }
> > then $filepath evaluates to
> >  /cygdrive/c/X/Rpkgs/Drydown_1.41.tar
> > and I was able to build packages again.
> >
> > (Posted in case someone else has the same problem and/or finds this useful.)
>
> It WOULD have been useful if you had tested in the alpha/beta/RC period
> and not immediately after release.  (I believe this has been asked of you
> before.)
>
> --
> Brian D. Ripley,  [EMAIL PROTECTED]
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595
>

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

[Rd] Could heatmap default to scale="none" ?

[Kevin Wright]

(I have searched the email archives for discussions on this topic but
have found nothing.)

The help page for heatmap says:
By default (scale = "row") the rows are scaled to have mean zero and
standard deviation one. There is some empirical evidence from genomic
plotting that this is useful.

I offer two comments on that.

1. Since the heatmap function is general-purpose (that is, not in a
genomics package), wouldn't it be better to just use no scaling?

2. Why assume that the rows should be scaled instead of the columns? 
There appears to be an assumption on the structure of the data.  Is
this assumption really warranted for a general-purpose function?

For the data I'm analyzing, scaling has hidden a great deal of
structure and I've just had to re-do many hours of work because I
didn't thoroughly read the help page and was not expecting the
scaling.  Further, given the structure of my data I did try (manually)
centering (not scaling) the COLUMNS, not the rows.

The heatmap.2 function in the gplots package defaults to scale="none"
and I argue that it would be better for the heatmap function to do the
same.

Kevin Wright

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

[Rd] Wishlist: Creating horizontal PDFs

[Kevin Wright]

It would be nice to easily create horizontal PDF files for standard paper
sizes.  For example:
pdf(file, paper="default", horizontal=TRUE)

Currently (R 2.2.1) there is no 'horizontal' argument for the PDF driver.
It looks like the only way to create a horizontal PDF is to manually specify
width and height.  For example:
pdf(file, width=11, height=8.5)

Does this feature look useful?  If so, I may someday try to make the changes
(I rarely have the ability to build R).

If anyone else wants to make the change, the code for the PDF driver appears
to be in R-devel/src/library/grDevices/src/devPS.c

The changes should not be hard.  FYI...there is a 'horizontal' option for
the postscript driver.

Kevin Wright

[[alternative HTML version deleted]]

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

[Rd] Undocumented features of 'browser' (and possible changes)

[Kevin Wright]

I often use browser() when debugging a function.  After entering
browser, I would find it very useful to be able to cut-and-paste a
chunk of R code to the browser (or use ess-eval-region in Emacs).  An
inconvenience, however, is that both blank lines and comment lines
will exit the browser.

The man page for browser says nothing about exiting the browser via
ENTER or via a line that begins with a comment, only that
"sub-interpreter can be exited by typing c" and "Typing Q quits the
current execution".

A hack that does allow code pasting into the browser is to put "NULL"
at the start of blank lines and comment lines.

Question: How would people react to a request to change the browser so
that blank lines and comment lines do not exit the browser?

Possible answers (check one or write your own)
[ ] - Who are you kidding?
[ ] - Even though it is undocumented and redundant, I use ENTER to exit browser
[ ] - You are forgetting about this scenario...
[ ] - A patch would be welcome
[ ] - Sounds great and I committed the changes already.  :-)


Kevin Wright, Windows 2000, R 2.2.1

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

Re: [Rd] Undocumented features of 'browser' (and possible changes)

[Kevin Wright]

Thanks for the clarification about ENTER and for explaining that
browser and debug use the same parser.  I'll crawl back into my
cubicle and keep using my hack.  Maybe I'll look into  re-writing
ess-eval-region to not send blank lines and comment lines.

Kevin


On 24 Mar 2006 23:11:25 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> "Kevin Wright" <[EMAIL PROTECTED]> writes:
>
> > I often use browser() when debugging a function.  After entering
> > browser, I would find it very useful to be able to cut-and-paste a
> > chunk of R code to the browser (or use ess-eval-region in Emacs).  An
> > inconvenience, however, is that both blank lines and comment lines
> > will exit the browser.
> >
> > The man page for browser says nothing about exiting the browser via
> > ENTER or via a line that begins with a comment, only that
> > "sub-interpreter can be exited by typing c" and "Typing Q quits the
> > current execution".
> >
> > A hack that does allow code pasting into the browser is to put "NULL"
> > at the start of blank lines and comment lines.
> >
> > Question: How would people react to a request to change the browser so
> > that blank lines and comment lines do not exit the browser?
> >
> > Possible answers (check one or write your own)
> > [ ] - Who are you kidding?
> > [ ] - Even though it is undocumented and redundant, I use ENTER to exit 
> > browser
> > [x] - You are forgetting about this scenario...
>
> ENTER does not actually quit the browser, it repeats the last command,
> as in
>
> > f(2)
> Called from: f(2)
> Browse[1]> n
> debug: x <- 2
> Browse[1]>
> debug: y <- x + 1
> Browse[1]>
>
> This is useful, since it drives you nuts to type "n",ENTER if you're
> debugging a lengthy piece of code (possibly more noticeable when
> you're using debug() than with browser(), but the two need to be
> consistent). This is also the way things work in e.g. the gdb
> debugger.
>
> Having "c" as the initial default is still open for discussion, of
> course. The scenario where browser() is in a function that gets called
> repeatedly does require some attention; it might be convenient to be
> able to continue with a single keystroke in that case.
>
>
> > [ ] - A patch would be welcome
> > [ ] - Sounds great and I committed the changes already.  :-)
> >
> >
> > Kevin Wright, Windows 2000, R 2.2.1
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
>O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
>   c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
>  (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
> ~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907
>

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

[Rd] pdf default version

[Kevin Wright]

R has had the ability to generate pdfs with transparent colors for a
couple of years now using pdf(..., version="1.4").

By default, Sweave uses just 'pdf' (without version 1.4), so a hack is
needed when using Sweave to create pdfs with transparent colors.  See
http://tolstoy.newcastle.edu.au/R/help/04/11/6655.html

I would find my work process simpler if R defaulted to generating PDFs
using version="1.4".  The help page for R's pdf command says there is
a risk of some older pdf viewers not being able to view newer PDFs.
Does anyone have a feeling for how big a risk this is?  I tried for a
while to search google for pdf metadata and the distribution of pdf
documents of different versions, but could find nothing useful to
report.

The PDF 1.4 specification appears to have been published in November, 2001.

Is updating pdf() to version="1.4" feasible?

Discussions on this topic will be watched with interest.

Kevin Wright

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

[Rd] Bug in Acrobat Reader 7 (or R?) with translucent text

[Kevin Wright]

My setup:  R 2.4.0, Windows 2000, Acrobat Reader 7.

When I create a .pdf with translucent colors, the translucency works
correctly for points, but not for text.  Below is some R code that
creates a .pdf with this phenomenon.

I was going to report this as a bug in R, but then I tried to view the
pdf with a couple of other viewers and found that at least one of the
viewers correctly displayed the file (with translucent text), so maybe
it is a bug with Acrobat Reader.  It might be worth checking to see if
colors for "text" are handled any differently than colors for "points"
that might cause this problem.

Best,

Kevin Wright


black <- rgb(0,0,0,.75)
blue <- rgb(0, .2, 1, .75)
red <- rgb(1,0,0,.75)
pdf("pdfcols.pdf", version="1.4")
set.seed(50)
plot(.5,.5,type="n",xlim=c(0,1),ylim=c(0,1))
points(runif(200),runif(200), col=black)
points(runif(200),runif(200), col=blue)
points(runif(200),runif(200), col=red)
text(.1, .1, "This is red", col=red)
text(.1, .1, "Also red", col=red)
text(.2, .2, "This is blue", col=blue)
text(.2, .2, "Also blue", col=blue)
text(.3, .3, "This is black", col=black)
text(.3, .3, "Also black", col=black)
points(runif(200),runif(200), col=black)
points(runif(200),runif(200), col=blue)
points(runif(200),runif(200), col=red)
dev.off()

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