Re: [Rd] How to add a slot to S4 class of an existing package?
On Tue, 7 Sep 2010 20:41:14 -0400, Kasper Daniel Hansen wrote: > Seb That thread and the resources in Biobase assumes that you have a > class that extends "Versioned". Doing so will help you in the long > run by providing you with updateObject (at the cost of some > complexity). However, it does not really help you if the existing > class does not extend Versioned. Thanks Kasper, indeed the class I'm working with doesn't have anything to do with Biobase, and having it extend "Versioned" along with the package dependencies only for this purpose seems overkill in my case. But perhaps one can implement a similar approach internally in the package without having to add a new dependency. > In general, adding a new slot should not break any existing code, but > you may find users who have old objects lying around that they cannot > use with the new functionality (I assume you are adding slots to > provide new functionality). Yes, the new slot adds new functionality and I also thought that adding a slot should not affect existing code. However, an error message during 'R CMD check' came up to the effect that an object did not have the new slot. Unfortunately, I didn't save more details nor investigated this error any further, but it got me doubting whether adding the slot would break existing code and access to objects of the older class. The object is under data/, although now I'm considering removing it and creating it in an example, which might be cleaner. -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] value returned by by()
Hi, I noticed that by() returns an object of class 'by', regardless of what its argument 'simplify' is. ?by says that it always returns a list if simplify=FALSE, yet by.data.frame shows: ---<cut here---start--->--- function (data, INDICES, FUN, ..., simplify = TRUE) { if (!is.list(INDICES)) { IND <- vector("list", 1L) IND[[1L]] <- INDICES names(IND) <- deparse(substitute(INDICES))[1L] } else IND <- INDICES FUNx <- function(x) FUN(data[x, , drop = FALSE], ...) nd <- nrow(data) ans <- eval(substitute(tapply(1L:nd, IND, FUNx, simplify = simplify)), data) attr(ans, "call") <- match.call() class(ans) <- "by" ans } ---<cut here---end->--- One could force a list by wrapping it around an lapply(by.object, "["), but this is not possible if the object contains S4 objects. How does one force a list in those cases? Cheers, -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] value returned by by()
On Tue, 14 Sep 2010 12:02:04 +0200, Uwe Ligges wrote: > It returns a list with athe class attribut set to "by", just use: x <- > by(.) unclass(x) Thanks Uwe, however, that still returns an array when using the data.frame method for by(): R> class(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, summary [1] "array" It seems as if the only way to really ensure a list: R> class(lapply(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, summary))), function(x) x)) [1] "list" but it seems like a waste to call another function just to do this. -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] value returned by by()
On Wed, 15 Sep 2010 11:29:23 +0200, peter dalgaard wrote: > On Sep 15, 2010, at 10:55 , Uwe Ligges wrote: > > > > > > On 14.09.2010 20:50, Seb wrote: > >> On Tue, 14 Sep 2010 12:02:04 +0200, > >> Uwe Ligges wrote: > >> > >>> It returns a list with athe class attribut set to "by", just use: x<- > >>> by(.) unclass(x) > >> > >> Thanks Uwe, however, that still returns an array when using the > >> data.frame method for by(): > >> > >> R> class(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, > >> summary > >> [1] "array" > >> > >> It seems as if the only way to really ensure a list: > >> > >> R> class(lapply(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, > >> summary))), function(x) x)) > >> [1] "list" > >> > >> but it seems like a waste to call another function just to do this. > >> > >> > > > > Then you could still do > > > > x <- by(.) > > attributes(x) <- NULL > > > Or just use c() instead of unclass(). (The root cause is that even with > simplify=FALSE, tapply() will always create an array, in this case a 1d array > with dim=3. The _contents_ of the array will be a list, though.) > Notice that in the relevant cases, what you get really _is_ a list, and both > walks and quacks like one. E.g. > > L <- with(warpbreaks, by(warpbreaks[, 1], tension, mean, simplify=FALSE)) > > is.list(L) > [1] TRUE > > L$M > [1] 26.38889 But if one tries to include this list dressed in 'by' clothes into an S4 class slot declared as a list, then we have problems. In that case, I propose this simple patch to by.Rd, which simply removes the statement about the result being *always* a list. Index: by.Rd === --- by.Rd (revision 52375) +++ by.Rd (working copy) @@ -36,8 +36,6 @@ } \value{ An object of class \code{"by"}, giving the results for each subset. - This is always a list if \code{simplify} is false, otherwise a list or - array (see \code{\link{tapply}}). } \seealso{\code{\link{tapply}}} Thanks! -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] value returned by by()
On Wed, 15 Sep 2010 15:15:27 +0200, Uwe Ligges wrote: > Why? It is still accessible as a list, even with S4 object, at least > for the cases I tried. R> wL <- with(warpbreaks, by(warpbreaks[, 1:2], tension, summary)) R> setClass("Whatever", + representation=representation(A="list")) [1] "Whatever" R> new("Whatever", A=wL) Error in validObject(.Object) : invalid class "Whatever" object: invalid object for slot "A" in class "Whatever": got class "by", should be or extend class "list" -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 plot generic documentation
Hi, Say we want to supply a generic plot() in a package with a simple class, like this: ---<cut here---start--->--- setClass("track", representation=representation(x="numeric", y="numeric")) if (!isGeneric("plot")) { setGeneric("plot", function(x, y, ...) standardGeneric("plot")) } setMethod("plot", signature(x="track", y="missing"), function(x, y, ...) { plot(x...@x, x...@y, ...) }) ---<cut here---end->--- To document the new method, I thought argument 'y' shouldn't need to be documented in the package because it's declared 'missing', and the following in plot-methods.Rd would be ok: ---<cut here---start--->--- \name{plot-methods} \docType{methods} \alias{plot-methods} \alias{plot} \alias{plot,track,missing-method} \title{Methods} \description{A plotting method} \usage{\S4method{plot}{track,missing}(x, \ldots)} \arguments{ \item{x}{track.} \item{\ldots}{Arguments passed to \code{\link{plot}}.} } \section{Methods}{ \describe{ \item{plot}{\code{signature(x="track", y="missing")}: some plot.} } } \keyword{methods} ---<cut here---end->--- yet 'R CMD check' issues a warning: ---<cut here---start--->--- Codoc mismatches from documentation object 'plot-methods': \S4method{plot}{track,missing} Code: function(x, y, ...) Docs: function(x, ...) Argument names in code not in docs: y Mismatches in argument names: Position: 2 Code: y Docs: ... ---<----cut here---end->--- So it seems as if I'm asked to document the generic, not the particular method. What am I misunderstanding? Thanks. Cheers, -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R freezes under Windows while loading package
On Wed, 03 May 2006 10:22:39 -0400 Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 5/3/2006 10:14 AM, Sebastian Manz wrote: > > Hi, > > > > we build this R package using C++ code and under linux it works > > fine. After installing: > > - R version 2.2.1 > > - minGW gcc version 3.4.2 > > - perl version 5.8.8 > > it finally compiled under Windows as well. But, if we try to load > > the library, R freezes without stressing the CPU. > > > > Maybe someone had a similar problem and now has a simple solution > > for it. > > Presumably the problem is in the DLL. Can you use dyn.load() to load > it manually? If so, you can set a debug breakpoint on each entry > point, and see where things are going wrong. Instructions for doing > C-level debugging under Windows are on my web page, > > http://www.stats.uwo.ca/faculty/murdoch/software/debuggingR/ > > and more general-purpose instructions are in the Writing R Extensions > manual in 2.3.0. > > Duncan Murdoch Thank you very much for your fast reply. The problem is found. It had something to do with a library we're using. Sorry we bothered you, Sebastian Manz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel