Re: [Rd] typo in R Installation and Administration
YC == Yohan Chalabi chal...@phys.ethz.ch on Thu, 18 Dec 2008 18:16:33 +0100 writes: YC Hi all, There seems to be a typo in R Installation and YC Administration in B.7 Compile and load flags YC special flags for compiling Fortran 95 code to be YC turned into a shared library should be FCPICFLAGS and YC not FPICFLAGS Yes. I've fixed, unfortunately a bit too late for today's release of 2.8.1 Merci, Yohan! Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] read.table with fill = TRUE
There seems to be a problem with read.table when fill = TRUE in this case. In the example below, note that: - there should be 4 columns, not 3 - some rows like row 6 are cut off at the end - others like row 7 seem completely wrong Lines - x 1 b + x 1 a + x 2 b + x 2 a + x 2 + y 1 a 1 + y 10 a 2 + y 10 a 10 + y 10 a 1 + y 2 + var 10 a 2 + var 2 + y 10 read.table(textConnection(Lines), fill = TRUE) V1 V2 V3 1x 1 b 2x 1 a 3x 2 b 4x 2 a 5x 2 6y 1 a 71 NA 8y 10 a 92 NA 10 y 10 a 11 10 NA 12 y 10 a 13 1 NA 14 y 2 15 var 10 a 16 2 NA 17 var 2 18 y 10 R.version.string [1] R version 2.8.1 RC (2008-12-17 r47235) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ... (dotMethods) and cbind/rbind: how to give the signature?
Dear List,
I'm struggling with the signature writing cbind/rbind functions for a S4
class.
First of all, I'm very happy that it is now possible to dispatch on ...
I follow the example for paste in ?dotMethods, which works as far as this:
### start example
setClass (cbtest,
representation = representation (data = data.frame),
prototype = prototype (data = data.frame (spc = I (matrix (rnorm
(15) , 3, 5)))
)
)
a - new (cbtest)
a
setMethod(cbind2, signature (x = cbtest, y = cbtest),
function (x, y){
x...@data$spc - cbind (x...@data$spc, y...@data$spc)
x
}
)
setMethod(cbind2, signature (x = cbtest, y = missing), function (x, y)
x)
cb.cbind - function (..., deparse.level){
dots - list (...)
for (i in seq_along (dots)[-1])
dots[[1]] - cbind2 (dots[[1]], dots[[i]])
dots[[1]]
}
cbind2 (a, a)
cb.cbind (a, a, a)
cbind (a, a, a)
setGeneric (cbind, signature = signature(...))
setMethod (cbind, cbtest,
function (..., deparse.level) cb.cbind (...))
cbind (a, a, a)
cbind (a, a, a, deparse.level = 1)
### end example
However, I get the following message:
with setGeneric
Creating a generic for cbind in package .GlobalEnv
(the supplied definition differs from and overrides the implicit generic in
package base: Signatures differ: (...), (deparse.level))
How do I specify the correct signature?
Furthermore: as I do not want to do anything with deparse.level, I'd rather
specify it as missing in setMethod. But again, I don't get the signature
correct.
I tried
setGeneric (cbind, signature = signature (...=..., deparse.level =
integer))
and
setGeneric (cbind, signature = signature (..., deparse.level = integer))
both give:
Fehler in makeGeneric(name, fdef, fdeflt, group = group, valueClass =
valueClass, :
Nicht-Argumente in der Signatur: integer
What is my mistake?
Thanks a lot for your help!
Claudia
version
_
platform i486-pc-linux-gnu
arch i486
os linux-gnu
system i486, linux-gnu
status
major 2
minor 8.0
year 2008
month 10
day20
svn rev46754
language R
version.string R version 2.8.0 (2008-10-20)
--
Claudia Beleites
Dipartimento dei Materiali e delle Risorse Naturali
Università degli Studi di Trieste
Via Alfonso Valerio 6/a
I-34127 Trieste
phone: +39 (0 40) 5 58-34 47
email: cbelei...@units.it
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] methods vs. functions
Dear List, a second, more general, question concerning S4 classes. I have a bunch of functions/methods for my class. At the moment I have them as methods, because they work on objects of my S4 class and therefore belong to that class. On the other hand, it is comparably unlikely that someone else wants the same kind of method. And package.skeleton () produces the xzy-methods.Rds. But for the documentation I rather need normal function definitions. I know that I can write the Rd files just as if it was a normal function, but this got me to ask myself whether it is a good idea to have methods or whether I should rather use normal functions? If I understood the concept of namespace correctly, a package with a namespace avoids trouble with clashing function names - so I don't need to worry about that using functions (I anyways have some functions, that should not be methods of the class). Any comments? Thanks a lot! Claudia -- Claudia Beleites Dipartimento dei Materiali e delle Risorse Naturali Università degli Studi di Trieste Via Alfonso Valerio 6/a I-34127 Trieste phone: +39 (0 40) 5 58-34 47 email: cbelei...@units.it __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Align legend title
Dear R developers,
I needed to align the title of legend for some of my plots. If there is
interest to include
this into base R, bellow are the examples and the relevent diffs.
Regards, Gregor
x - 1:10
y1 - 1.5 * x
y2 - 2.0 * x
y - cbind(y1, y2)
source(file=url(http://gregor.gorjanc.googlepages.com/legend.R;))
matplot(x, y, type=l, lty=c(1, 2))
## Center
legend(topleft, legend=c(a long text, a long text, y = 2.0 * x), lty=c(1,
2), title=Function)
legend(topright, legend=c(a shor text, ), lty=c(1, 2), title=Function +
some more text)
## Left
legend(left, legend=c(a long text, a long text, a long text, y = 2.0 *
x), lty=c(1, 2), title=Function, title.adj=0)
legend(right, legend=c(a shor text, ), lty=c(1, 2), title=Function +
some more long text, title.adj=0)
## Right
legend(bottomleft, legend=c(a long text, a long text, a long text, y = 2.0
* x), lty=c(1, 2), title=Function, title.adj=1)
legend(bottomright, legend=c(a shor text, ), lty=c(1, 2), title=Function
+ some more long text, title.adj=1)
http://gregor.gorjanc.googlepages.com/legend.R
http://gregor.gorjanc.googlepages.com/legend.Rd
http://gregor.gorjanc.googlepages.com/legend.R.diff
http://gregor.gorjanc.googlepages.com/legend.Rd.diff
Index: legend.R
===
--- legend.R(revision 47286)
+++ legend.R(working copy)
@@ -23,7 +23,7 @@
text.width = NULL, text.col = par(col),
merge = do.lines has.pch, trace = FALSE,
plot = TRUE, ncol = 1, horiz = FALSE, title = NULL,
-inset = 0, xpd, title.col = text.col)
+inset = 0, xpd, title.col = text.col, title.adj = 0.5)
{
## the 2nd arg may really be `legend'
if(missing(legend) !missing(y)
@@ -259,11 +259,11 @@
xt - xt + x.intersp * xchar
if(plot) {
- if (!is.null(title))
-text2(left + w/2, top - ymax, labels = title,
- adj = c(0.5, 0), cex = cex, col = title.col)
+if(!is.null(title))
+text2(left + w/2 + ((w - tw) * (title.adj - 0.5)), top - ymax,
+ labels = title, adj = c(0.5, 0), cex = cex, col = title.col)
- text2(xt, yt, labels = legend, adj = adj, cex = cex, col = text.col)
+text2(xt, yt, labels = legend, adj = adj, cex = cex, col = text.col)
}
invisible(list(rect = list(w = w, h = h, left = left, top = top),
text = list(x = xt, y = yt)))
Index: legend.Rd
===
--- legend.Rd (revision 47286)
+++ legend.Rd (working copy)
@@ -16,7 +16,7 @@
adj = c(0, 0.5), text.width = NULL, text.col = par(col),
merge = do.lines has.pch, trace = FALSE,
plot = TRUE, ncol = 1, horiz = FALSE, title = NULL,
- inset = 0, xpd, title.col = text.col)
+ inset = 0, xpd, title.col = text.col, title.adj = 0.5)
}
\description{
This function can be used to add legends to plots. Note that a call
@@ -89,6 +89,8 @@
\item{xpd}{if supplied, a value of the graphical parameter \code{xpd}
to be used while the legend is being drawn.}
\item{title.col}{color for \code{title}.}
+ \item{title.adj}{justify the title, a value of 0 means left justified,
+0.5 means centered and 1 means right justified.}
}
\details{
Arguments \code{x, y, legend} are interpreted in a non-standard way to
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods vs. functions
On 12/22/2008 9:40 AM, Claudia Beleites wrote: Dear List, a second, more general, question concerning S4 classes. I have a bunch of functions/methods for my class. At the moment I have them as methods, because they work on objects of my S4 class and therefore belong to that class. On the other hand, it is comparably unlikely that someone else wants the same kind of method. And package.skeleton () produces the xzy-methods.Rds. But for the documentation I rather need normal function definitions. I know that I can write the Rd files just as if it was a normal function, but this got me to ask myself whether it is a good idea to have methods or whether I should rather use normal functions? If I understood the concept of namespace correctly, a package with a namespace avoids trouble with clashing function names - so I don't need to worry about that using functions (I anyways have some functions, that should not be methods of the class). Any comments? In the S4 scheme, methods belong to the generic, not to the class. If you only have one method for each generic and don't plan for more, it probably makes more sense to make it a regular function: it will run a little bit faster, and be noticeably easier to debug. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in list indexing (PR#13411)
I was wondering if copies were made when a component of a complex nested list structure was extracted but not modified. I was happy that the answer was no, but was surprised that copies weren't made even if the extracted bit was modified: x - list(a=list(b=numeric(100))) y - x[[c(1,1)]] y[1] - 3.14159 x[[c(1,1)]][1] [1] 3.14159 Unfortunately, this exists in today's release of 2.8.1. I should have done this test last week! Duncan Murdoch sessionInfo() R version 2.8.1 (2008-12-22) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.8.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in list indexing (PR#13411)
On 12/22/2008 1:55 PM, murd...@stats.uwo.ca wrote: I was wondering if copies were made when a component of a complex nested list structure was extracted but not modified. I was happy that the answer was no, but was surprised that copies weren't made even if the extracted bit was modified: x - list(a=list(b=numeric(100))) y - x[[c(1,1)]] y[1] - 3.14159 x[[c(1,1)]][1] [1] 3.14159 Unfortunately, this exists in today's release of 2.8.1. I should have done this test last week! The fix looks easy: The problem is that the NAMED status of the component being extracted was miscalculated when using a vector index. I'll commit a change after testing... Duncan Murdoch Duncan Murdoch sessionInfo() R version 2.8.1 (2008-12-22) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.8.1 __ 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] How to add a slot to S4 class of an existing package?
Dear all, Since my package is based on S4 classes, I would like to know how to add a slot to an existing S4 class without breaking the code of users of my package. Assume the following S4 class: setClass(MyClass, representation(name = character, type = character, data = data.frame ), prototype(name = , type = Default, data = data.frame(matrix(nr=0,nc=0)) ) )#MyClass Assume that a user has created an object: myclass - new(MyClass, name=MyName, type=MyType, data=tmp) str(myclass) Now I would like to add another slot info to MyClass: setClass(MyClass, representation(name = character, type = character, data = data.frame, info = data.frame ), prototype(name = , type = Default, data = data.frame(matrix(nr=0,nc=0)), info = data.frame(matrix(nr=0,nc=0)) ) )#MyClass Now when the user loads my package with S4 class MyClass containing a new slot and calls: str(myclass) Error in FUN(c(name, type, data, info)[[4L]], ...) : no slot of name info for this object of class MyClass My question is: Is there any possibility or special trick, which would avoid this error message? Are there other possibilities to access an additional data.frame from an existing class? Is there something like an evolution of S4 classes, which distinguishes the different implementations of an S4 class, and allows the user to keep the object of an old class? Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rscproxy version conflict
We found out about this problem only a few days ago.
The reason is that the official binary packages were compiled with
2.8.1, but the distributed Windows binary of R was still 2.8.0.
rscproxy needs to be compiled for the correct version of R.
Now with R 2.8.1 being release officially the problem should disappear,
but we (which is mostly Thomas Baier, the mastermind behind rcom and
R(D)COM server) will try to find a way to avoid this problem with the
next R update.
Before R 2.8.0, rproxy.dll distributed with R itself was
supplying the underlying mechanism for the rcom package and R(D)COM
server. rproxy.dll was removed from R itself, and rscproxy is the
current substitute. rproxy.dll, being part of R itself, always matched
the R version to the very last digit. With rscproxy, it is more
difficult to stay in sync.
meerman wrote:
After installing the package 'rscproxy' downloaded from the CRAN server, I
get the following error message from R 2.8.0 about a version conflict :
package 'rscproxy' successfully unpacked and MD5 sums checked
The downloaded packages are in
C:\Documents and Settings\John Meerman\Local
Settings\Temp\RtmpbK9mxN\downloaded_packages
updating HTML package descriptions
local({pkg - select.list(sort(.packages(all.available = TRUE)))
+ if(nchar(pkg)) library(pkg, character.only=TRUE)})
*Warning message:
package 'rscproxy' was built under R version 2.8.1 *
This prevents me e.g. to use the R (D)COM 3.0 server.
John Meerman
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.19/1854 - Release Date: 12/17/2008
7:21 PM
--
Erich Neuwirth, University of Vienna
Faculty of Computer Science
Computer Supported Didactics Working Group
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rscproxy version conflict
On Dec 22, 2008, at 15:30 , Erich Neuwirth wrote:
We found out about this problem only a few days ago.
The reason is that the official binary packages were compiled with
2.8.1, but the distributed Windows binary of R was still 2.8.0.
rscproxy needs to be compiled for the correct version of R.
Now with R 2.8.1 being release officially the problem should
disappear,
but we (which is mostly Thomas Baier, the mastermind behind rcom and
R(D)COM server) will try to find a way to avoid this problem with the
next R update.
Before R 2.8.0, rproxy.dll distributed with R itself was
supplying the underlying mechanism for the rcom package and R(D)COM
server. rproxy.dll was removed from R itself, and rscproxy is the
current substitute. rproxy.dll, being part of R itself, always matched
the R version to the very last digit. With rscproxy, it is more
difficult to stay in sync.
FWIW: technically, you don't have to match the patch level version.
Although default DLL checks usually require perfect match, it should
be safe to require that R version lies in [x.y.z, x.y+1.0) where
x.y.z is the R version that the interfacing DLL was compiled against.
(And hence it is safe to use R x.y.0 as the base for compilation until
R x.y+1.0 is released).
Cheers,
Simon
meerman wrote:
After installing the package 'rscproxy' downloaded from the CRAN
server, I
get the following error message from R 2.8.0 about a version
conflict :
package 'rscproxy' successfully unpacked and MD5 sums checked
The downloaded packages are in
C:\Documents and Settings\John Meerman\Local
Settings\Temp\RtmpbK9mxN\downloaded_packages
updating HTML package descriptions
local({pkg - select.list(sort(.packages(all.available = TRUE)))
+ if(nchar(pkg)) library(pkg, character.only=TRUE)})
*Warning message:
package 'rscproxy' was built under R version 2.8.1 *
This prevents me e.g. to use the R (D)COM 3.0 server.
John Meerman
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.19/1854 - Release Date:
12/17/2008 7:21 PM
--
Erich Neuwirth, University of Vienna
Faculty of Computer Science
Computer Supported Didactics Working Group
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
__
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
