Re: [Rd] Deprecating partial matching in $.data.frame
On Mar 22, 2013, at 05:57 , Hervé Pagès wrote: > Hi, > > Maybe a compromise would be to just issue a warning without > deprecating? That way people who want to do anova(fit1)$P can > still do it. When working interactively, it's certainly convenient > (serious code however should probably stay away from partial matching). That's what it does. Issuing a warning when users do X is pretty much equivalent to deprecating X. > > And so you keep the semantic consistent with lists because yes, > consistency is important. data.frame inherits from list so any > operation that works on a list is expected to work on a data.frame, > preferably the same way (otherwise it will always be a BIG surprise > to the user/programmer). For example if I have to maintain someone > else code and see something like: > >bar <- x$bar > > and I know that 'x' is a list that contains atomic vectors of the > same length, I could have some good reasons to want to use a > data.frame instead of a list. And I would assume it's safe to > modify the code by adding the following line earlier in it: > > x <- as.data.frame(x) > > But with the proposed change to $.data.frame, I cannot make this > kind of assumption anymore... No, but it's only a real problem if the component is not actually called "bar". You could make the same point for environments, but they never allowed partial matching: > e <- as.environment(list(barbaric=666)) > e$bar NULL > e$barbaric [1] 666 -- Peter Dalgaard, Professor 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] ess completion
The thread is strange to me as well, since completion is logically impossible for my Sweave files. - an emacs buffer is open working on an .Rnw file - there is no copy of R running anywhere on the machine - the code chunk in the .Rnw file refers to a R data object saved somewhere else Of course it cannot do "name completion" on a bit of code I'm writing, lacking omniscient powers. Emacs is good but not that good :-) The ESS manual section 12.1 states that for .R files it has "completion of object names and file names". I'm puzzled by exactly what this means, since it is logically impossible (without a running R session) to do this in general. Linking an .Rnw file to an inferior R process doesn't make sense to me. However, I think it's time to move this sub-thread off of R-devel. Respond to me privately about the answer or the proper list for this discussion. Terry T On 03/22/2013 06:00 AM, r-devel-requ...@r-project.org wrote: This thread is strange for me to read as I've been getting completion of object names, function arguments names, and whatnot in ESS buffers for as long as I can have been using it. And I'm only on ESS 12.09. Perhaps you need to set `ess-use-R-completion` to non-nil. Or check the value of `completion-at-point-functions`. Mine is '(ess-roxy-tag-completion ess-filename-completion ess-object-completion t) Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ess completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/03/13 13:30, Terry Therneau wrote: > The thread is strange to me as well, since completion is logically impossible > for my Sweave > files. - an emacs buffer is open working on an .Rnw file - there is no copy > of R running > anywhere on the machine - the code chunk in the .Rnw file refers to a R data > object saved > somewhere else Of course it cannot do "name completion" on a bit of code I'm > writing, lacking > omniscient powers. Emacs is good but not that good :-) > > The ESS manual section 12.1 states that for .R files it has "completion of > object names and > file names". I'm puzzled by exactly what this means, since it is logically > impossible (without > a running R session) to do this in general. Linking an .Rnw file to an > inferior R process > doesn't make sense to me. > > However, I think it's time to move this sub-thread off of R-devel. Respond > to me privately > about the answer or the proper list for this discussion. If anybody wants to continue this ESS discussion: The proper list is the ESS mailing list: https://stat.ethz.ch/mailman/listinfo/ess-help See you there, Rainer > > Terry T > > On 03/22/2013 06:00 AM, r-devel-requ...@r-project.org wrote: >> This thread is strange for me to read as I've been getting completion of >> object names, >> function arguments names, and whatnot in ESS buffers for as long as I can >> have been using it. >> And I'm only on ESS 12.09. >> >> Perhaps you need to set `ess-use-R-completion` to non-nil. Or check the >> value of >> `completion-at-point-functions`. Mine is '(ess-roxy-tag-completion >> ess-filename-completion >> ess-object-completion t) >> >> Peter > > __ R-devel@r-project.org mailing > list > https://stat.ethz.ch/mailman/listinfo/r-devel - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRTF8CAAoJENvXNx4PUvmCrSQH/inP6c5JT+YEJYDEGOkLQOiA 8GLGzgCdO+iekF1EMrKVvcPjim14gRu+y2HcryxMO44w1gIutcY2wpq6m7OYvCXI BV40TjKut6nLzopx0IWVr0vX+mA5IybKiziup+lSS86gb5E8QNRVlBFIw3Xp2TXP rMlS6kkNiQR6y94lwdnUJTy/FerqsV9sQNnNUNipTPt9coL4qISyl1TDoDImrtgM kCG/kSoUnazzldH39qHgfEJb4rhgCLISNFKbPmtCuCbKh+iF0bHJF4rlEXrSkiRu GsmfV1Ln3hWmYijtOygHUlmeSiiVTZVVtfXA5oXrW/GXVvDCYEkSTDuu3JbIj7o= =DJwz -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Deprecating partial matching in $.data.frame
Hi, On 03/22/2013 01:31 AM, peter dalgaard wrote: On Mar 22, 2013, at 05:57 , Hervé Pagès wrote: Hi, Maybe a compromise would be to just issue a warning without deprecating? That way people who want to do anova(fit1)$P can still do it. When working interactively, it's certainly convenient (serious code however should probably stay away from partial matching). That's what it does. Issuing a warning when users do X is pretty much equivalent to deprecating X. For now yes. But you won't keep it deprecated forever right? And so you keep the semantic consistent with lists because yes, consistency is important. data.frame inherits from list so any operation that works on a list is expected to work on a data.frame, preferably the same way (otherwise it will always be a BIG surprise to the user/programmer). For example if I have to maintain someone else code and see something like: bar <- x$bar and I know that 'x' is a list that contains atomic vectors of the same length, I could have some good reasons to want to use a data.frame instead of a list. And I would assume it's safe to modify the code by adding the following line earlier in it: x <- as.data.frame(x) But with the proposed change to $.data.frame, I cannot make this kind of assumption anymore... No, but it's only a real problem if the component is not actually called "bar". You could make the same point for environments, but they never allowed partial matching: A data.fame is a list, not an environment. It would be silly for me as a programmer to assume that replacing environment 'x' by data.frame 'x' won't break the code. H. e <- as.environment(list(barbaric=666)) e$bar NULL e$barbaric [1] 666 -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Description depends line for windows only
I am developing a package that is only applicable on windows, is there a line I can put in the depends field of the DESCRIPTION file to tell that this should only be build for windows? Are there any other protocols that I should follow? Thanks, -- Andrew May the Open Source be with you. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Description depends line for windows only
On Fri, Mar 22, 2013 at 9:44 AM, Andrew Redd wrote:
> I am developing a package that is only applicable on windows, is there a
> line I can put in the depends field of the DESCRIPTION file to tell that
> this should only be build for windows?
>
OS_type: windows
See
RShowDoc("R-exts")
Section 1.1.1 The DESCRIPTION file, search for OS_type.
Dan
> Are there any other protocols that I should follow?
>
> Thanks,
>
> --
> Andrew
> May the Open Source be with you.
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Description depends line for windows only
On 22 March 2013 at 10:44, Andrew Redd wrote: | I am developing a package that is only applicable on windows, is there a | line I can put in the depends field of the DESCRIPTION file to tell that | this should only be build for windows? There is a different field for this. From Section 1.1.1 of you-know-what: The `OS_type' field specifies the OS(es) for which the package is intended. If present, it should be one of `unix' or `windows', and indicates that the package can only be installed on a platform with `.Platform$OS.type' having that value. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] read.pnm question in R-beta
In R-beta (Masked Marvel), when I do the example from the read.pnm help file,
this is what happens:
x <- read.pnm(system.file("pictures/logo.pgm",package="pixmap")[1])
Warning message:
In rep(cellres, length=2): x is NULL so the result will be NULL
In R-2.15.3, it's all right.
Thanks,
Erin
Erin M. Hodgess, Ph.D.
Associate Professor
Department of Computer and Mathematical Sciences
University of Houston - Downtown
mailto: hodge...@uhd.edu
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.pnm question in R-beta
On Mar 22, 2013, at 18:53 , Hodgess, Erin wrote:
> In R-beta (Masked Marvel), when I do the example from the read.pnm help file,
> this is what happens:
>
> x <- read.pnm(system.file("pictures/logo.pgm",package="pixmap")[1])
> Warning message:
>
> In rep(cellres, length=2): x is NULL so the result will be NULL
> In R-2.15.3, it's all right.
It's just a warning. The change is in NEWS. It's up to the pixmap package
maintainer to get rid of the warning.
-pd
>
> Thanks,
> Erin
>
> Erin M. Hodgess, Ph.D.
> Associate Professor
> Department of Computer and Mathematical Sciences
> University of Houston - Downtown
> mailto: hodge...@uhd.edu
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
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] read.pnm question in R-beta
On 22/03/2013 17:53, Hodgess, Erin wrote:
In R-beta (Masked Marvel), when I do the example from the read.pnm help file,
this is what happens:
x <- read.pnm(system.file("pictures/logo.pgm",package="pixmap")[1])
Warning message:
In rep(cellres, length=2): x is NULL so the result will be NULL
In R-2.15.3, it's all right.
That is an error in a package (and no, it was not all right: how can
NULL ever be replicated to length 2?). I presume package pixmap, but
you did not tell us.
After all these years you should have read the posting guide and know to
send such comments to the package maintainer.
Thanks,
Erin
Erin M. Hodgess, Ph.D.
Associate Professor
Department of Computer and Mathematical Sciences
University of Houston - Downtown
mailto: hodge...@uhd.edu
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Why does typeof() modify an object's "named" field?
Hello, Doing typeof() on an object appears to reset the "named" field in its sxpinfo header to 2, which can change the way that subsequent subassignment operations are carried out: X <- 1:5e7 .Internal(inspect(X)) # @4eeb0008 13 INTSXP g0c7 [NAM(1)] (len=5000, tl=0) 1,2,3,4,5,... system.time(X[1] <- 9L) #user system elapsed # 0 0 0 typeof(X) .Internal(inspect(X)) # @4eeb0008 13 INTSXP g1c7 [MARK,NAM(2)] (len=5000, tl=0) 9,2,3,4,5,... system.time(X[2] <- 9L) #user system elapsed #0.160.080.23 Some other functions that query the nature of an object (e.g. class(), length(), attributes()) do not modify the object's "named" field. Is there a reason that typeof() should? (Possibly of interest is this somewhat related thread on Stack Overflow: http://stackoverflow.com/questions/15559387/operator-in-rstudio-and-r/15559956#15559956 ). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check in R-3.0.0 gives warnings
I am running R CMD check on my package nleqslv with R-3.0.0 beta (2013-03-33 r62364) on Mac OS X 10.6.8 In contrast with R-2.15.3 R CMD check now issues a note for - Mercurial version control files .hgignore, .hgtags and directory .hg. These are however included in .hidden_file_exclusions. - typical Mac Finder files .DS_Store All of these are ignored when executing R CMD check --as-cran. I can't remove the .hg* files and directories. I could remove the .DS_Store files to avoid the note. The note is harmless but annoying and strikes me as slightly overzealous. Berend __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check in R-3.0.0 gives warnings
On 22 March 2013 at 21:03, Berend Hasselman wrote: | I am running R CMD check on my package nleqslv with R-3.0.0 beta (2013-03-33 r62364) on Mac OS X 10.6.8 | | In contrast with R-2.15.3 R CMD check now issues a note for | | - Mercurial version control files .hgignore, .hgtags and directory .hg. These are however included in .hidden_file_exclusions. | - typical Mac Finder files .DS_Store | | All of these are ignored when executing R CMD check --as-cran. | | I can't remove the .hg* files and directories. I could remove the .DS_Store files to avoid the note. A few years ago the "Right Way To Do Things" changed. You are really supposed to do 'R CMD check' off the tar.gz, and you *do* have a toggle to exclude what goes into the tar.gz: .Rbuildignore | The note is harmless but annoying and strikes me as slightly overzealous. So are are many other warnings. But in the long run I am happy they are there so that eg my system does not get polluted with your .hg and .DS_Store files which are of zero use to me. Warnings are your friends. Be nice to them. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check in R-3.0.0 gives warnings
On 22-03-2013, at 21:26, Dirk Eddelbuettel wrote: > > On 22 March 2013 at 21:03, Berend Hasselman wrote: > | I am running R CMD check on my package nleqslv with R-3.0.0 beta > (2013-03-33 r62364) on Mac OS X 10.6.8 > | > | In contrast with R-2.15.3 R CMD check now issues a note for > | > | - Mercurial version control files .hgignore, .hgtags and directory .hg. > These are however included in .hidden_file_exclusions. > | - typical Mac Finder files .DS_Store > | > | All of these are ignored when executing R CMD check --as-cran. > | > | I can't remove the .hg* files and directories. I could remove the .DS_Store > files to avoid the note. > > A few years ago the "Right Way To Do Things" changed. You are really > supposed to do 'R CMD check' off the tar.gz, and you *do* have a toggle to > exclude what goes into the tar.gz: .Rbuildignore > which I have. And making a .tar.gz will ignore the version control files. So why not ignore them when doing a check on a (allowed) package directory? >From R CMD check --help Usage: R CMD check [options] pkgs Check R packages from package sources, which can be directories or package 'tar' archives with extension '.tar.gz', '.tar.bz2', '.tar.xz' or '.tgz'. So a directory is allowed. > | The note is harmless but annoying and strikes me as slightly overzealous. > > So are are many other warnings. > It's a note and not a warning. > But in the long run I am happy they are there so that eg my system does not > get polluted with your .hg and .DS_Store files which are of zero use to me. > My .hg and .DS_Store files will not pollute your system. Berend > Warnings are your friends. Be nice to them. > > Dirk > > > -- > Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check in R-3.0.0 gives warnings
On 13-03-22 4:40 PM, Berend Hasselman wrote: On 22-03-2013, at 21:26, Dirk Eddelbuettel wrote: On 22 March 2013 at 21:03, Berend Hasselman wrote: | I am running R CMD check on my package nleqslv with R-3.0.0 beta (2013-03-33 r62364) on Mac OS X 10.6.8 | | In contrast with R-2.15.3 R CMD check now issues a note for | | - Mercurial version control files .hgignore, .hgtags and directory .hg. These are however included in .hidden_file_exclusions. | - typical Mac Finder files .DS_Store | | All of these are ignored when executing R CMD check --as-cran. | | I can't remove the .hg* files and directories. I could remove the .DS_Store files to avoid the note. A few years ago the "Right Way To Do Things" changed. You are really supposed to do 'R CMD check' off the tar.gz, and you *do* have a toggle to exclude what goes into the tar.gz: .Rbuildignore which I have. And making a .tar.gz will ignore the version control files. So why not ignore them when doing a check on a (allowed) package directory? Because that makes the code messier. A directory is treated as if it was just extracted from the tarball. If the code had to distinguish two different ways of getting to that state it would be harder to maintain. Duncan Murdoch From R CMD check --help Usage: R CMD check [options] pkgs Check R packages from package sources, which can be directories or package 'tar' archives with extension '.tar.gz', '.tar.bz2', '.tar.xz' or '.tgz'. So a directory is allowed. | The note is harmless but annoying and strikes me as slightly overzealous. So are are many other warnings. It's a note and not a warning. But in the long run I am happy they are there so that eg my system does not get polluted with your .hg and .DS_Store files which are of zero use to me. My .hg and .DS_Store files will not pollute your system. Berend Warnings are your friends. Be nice to them. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ 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
