[Rd] Error in parse(outFile)
Hi all I have made some changes to a package (SimHap) I wrote a couple of years ago, and it has passed R CMD check under windows, but under linux (ubuntu jaunty) I am getting the following error: * installing *source* package 'SimHap' ... ** R Error in parse(outFile) : 2:1: unexpected $end ERROR: unable to collate files for package 'SimHap' Does anyone know what the "outFile" it is referring to here, and why this would be happening in a linux build, but not in windows. In both cases I'm using R 2.10.0. Cheers Pam Dr Pamela McCaskie Assistant Professor Centre for Genetic Epidemiology and Biostatistics M409 University of Western Australia Email: pam.mccas...@uwa.edu.au Ph: 6488 6741 Fax: 6488 6750 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Method dispatch for function
> "SM" == Stavros Macrakis
> on Mon, 23 Nov 2009 11:24:24 -0500 writes:
SM> (I had sent this to r-help and got no responses -- perhaps r-devel is
SM> a better list for this question?)
Definitely better, yes.
SM> How can I determine what S3 method will be called for a particular
SM> first-argument class?
SM> I was imagining something like functionDispatch('str','numeric') =>
SM> utils:::str.default , but I can't find anything like this.
SM> For that matter, I was wondering if anyone had written a version of
SM> `methods` which gave their fully qualified names if they were not
SM> visible, e.g.
SM> methods('str') =>
SM> utils:::str.data.frame utils:::str.default
SM> stats:::str.dendrogram stats:::str.logLik utils:::str.POSIXt
SM> or
SM> methods('str') =>
SM> $utils
SM> "str.data.frame" "str.default" "str.POSIXt"
SM> $stats
SM> "str.dendrogram" "str.logLik"
I'm pretty sure that basically, the current methods() function
"contains" the necessary information internally already
(but beware: methods() is not the simplest of our functions !)
I'd be welcoming back-compatible patches to methods() {*and*
the corresponding *.Rd file !} which would provide such
functionality.
I think I would introduce a third optional argument
(logical or character, specifying the "variants"),
and the result could easily become back-compatible if the extra information
you want is put as a new column in the "info" attribute (a data
frame) of the current methods() result.
SM> Thank you,
You are welcome,
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in parse(outFile)
Pamela McCaskie wrote: Hi all I have made some changes to a package (SimHap) I wrote a couple of years ago, and it has passed R CMD check under windows, but under linux (ubuntu jaunty) I am getting the following error: * installing *source* package 'SimHap' ... ** R Error in parse(outFile) : 2:1: unexpected $end ERROR: unable to collate files for package 'SimHap' Does anyone know what the "outFile" it is referring to here, and why this would be happening in a linux build, but not in windows. In both cases I'm using R 2.10.0. When installing a package, R collects all the source into one big file and parses it all at once. The filename is stored internally in a variable called "outFile". I don't know what would be causing this difference between Windows and Linux. If you can send me a copy of the package offline I'll take a look later today. Duncan Murdoch Cheers Pam Dr Pamela McCaskie Assistant Professor Centre for Genetic Epidemiology and Biostatistics M409 University of Western Australia Email: pam.mccas...@uwa.edu.au Ph: 6488 6741 Fax: 6488 6750 [[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] group generics
Hi Ross --
Ross Boylan writes:
> I have classes A and B, where B contains A. In the implementation of
> the group generic for B I would like to use the corresponding group
> generic for A. Is there a way to do that?
>
> I would also appreciate any comments if what I'm trying to do seems like
> the wrong approach.
>
> Here's a stripped down example:
> setClass("A",
> representation=representation(xa="numeric")
> )
>
> setMethod("Arith", signature(e1="numeric", e2="A"), function(e1, e2) {
> new("A", ax=e1...@xa)
typo, I guess, xa = e1...
> }
> )
>
> setClass("B",
> representation=representation(xb="numeric"),
> contains=c("A")
> )
>
> setMethod("Arith", signature(e1="numeric", e2="B"), function(e1, e2) {
> # the next line does not work right
> v <- selectMethod("callGeneric", signature=c("numeric", "A"))(e1, e2)
v <- callGeneric(e1, as(e2, "A"))
or probably
v <- callNextMethod(e1, e2)
Martin
> print(v)
> new("B", v, xb=e1...@xb)
> }
> )
>
>
> Results:
>> t1 <- new("B", new("A", xa=4), xb=2)
>> t1
> An object of class “B”
> Slot "xb":
> [1] 2
>
> Slot "xa":
> [1] 4
>
>> 3*t1
> Error in getGeneric(f, !optional) :
> no generic function found for "callGeneric"
>
> Thanks.
> Ross Boylan
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in all.equal() or in the plm package
Hi,
sorry for replying so late to this. I somehow missed the original thread
and was just pointed to it by Yves...
I noticed that there is a (minor) bug either the command all.equal()
or in the "plm" package. I demonstrate this using an example taken
from the documentation of plm():
I'm not sure this is a bug, but I'd call it at least a design flaw.
The problem is that the length.Formula method in the Formula package
(which plm depends on) returns a vector of length 2. Now there's
nothing in R that requires length() to return a scalar, but all.equal
assumes it does, and I'd guess there are lots of other places this
assumption is made.
Well, ?length says:
The default method currently returns an 'integer' of length 1.
Since this may change in the future and may differ for other
methods, programmers should not rely on it.
The problem IMO is that the all.equal() method for "formula" gets called
by inheritance without assuring that it works. I think we just need to
supply a suitable all.equal() method for "Formula" objects.
Okay, let's call it "design flaw". Given that the "unusual" behaviour
of length.Formula() causes this problem, I suggest that the
length.Formula() method should be changed. Maybe to something like
R> a <- as.Formula( y ~ x | z | w )
# current behaviour:
R> length(a)
[1] 1 3
# suggested behaviour:
R> length(a)
[1] 2
This wouldn't be correct either because this is not a list of length 2. A
"Formula" is a "formula" (of length 2 or 3) with two attributes ("lhs" and
"rhs"). Thus, currently length() does not reflect the internal structure
but rather the conceptual structure (of a formula consiting of a LHS and
RHS, both with a certain length).
Unless there are good reasons to do otherwise, I would keep the length()
method and just supply a suitable all.equal() method for
"Formula" objects.
hth,
Z
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible bug in "unsplit" (PR#14084)
Dear R-bug-people
I have encountered a problem with "unsplit", which I believe may be
caused by a bug in the function. However, unexpericend with bug-reports
I apologise if this is barely a user problem rather than a problem
within R.
The problem occurs if an object is split by several grouping factors
with levels not occuring in the data, and using drop = TRUE. This may
appear as a special and hardly relevant case, but I had to split a data
frame on several factors, do some analyses on each of the subsets in the
splitted object, and then unsplit it. I had to use drop = TRUE,
otherwise my analyses would not run. Nevertheless, I found a fix to the
unsplit, which I suggest is due to that the drop-argument not is
maintained in the call to unsplit within unsplit. Description and
example below. The problem was found on R version 2.9.0 and 2.10.0 on
windows XP.
> sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32
locale:
[1] LC_COLLATE=Norwegian (Bokmål)_Norway.1252 LC_CTYPE=Norwegian
(Bokmål)_Norway.1252
[3] LC_MONETARY=Norwegian (Bokmål)_Norway.1252 LC_NUMERIC=C
[5] LC_TIME=Norwegian (Bokmål)_Norway.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.10.0
>
## a reproducable example:
dff <- data.frame(gr1=factor(c(1,1,1,1,1,2,2,2,2,2,2),
levels=c(1,2,3,4)), gr2=factor(c(1,2,1,2,1,2,1,2,1,2,3),
levels=c(1,2,3,4)), yy=rnorm(11))
# note that the two groups "gr1" and "gr2" have defined levels which not
occur in the data.
dff2 <- split(dff, list(dff$gr1, dff$gr2), drop=TRUE)
# I dont want empty objects, so I use drop=TRUE
# now I want to unsplit it, and expect the following to work:
dff3 <- unsplit(dff2, list(dff$gr1, dff$gr2), drop=TRUE)
Error in `row.names<-.data.frame`(`*tmp*`, value = c("1", "11", "3",
"11", :
duplicate 'row.names' are not allowed
In addition: Warning message:
non-unique values when setting 'row.names': 1, 11, 3, 5
### end
Looking at the unsplit function, we find:
> unsplit
function (value, f, drop = FALSE)
{
len <- length(if (is.list(f)) f[[1L]] else f)
if (is.data.frame(value[[1L]])) {
x <- value[[1L]][rep(NA, len), , drop = FALSE]
rownames(x) <- unsplit(lapply(value, rownames), f)
}
else x <- value[[1L]][rep(NA, len)]
split(x, f, drop = drop) <- value
x
}
>
Note that if "value" is a data.frame, then rownames for the output x is
made by the call:
rownames(x) <- unsplit(lapply(value, rownames), f)
This call to unsplit ignores the drop-argument, and in the example above
we get from this call:
> unsplit(lapply(dff2, rownames), list(dff$gr1, dff$gr2))
[1] "1" "11" "3" "11" "5" "1" "7" "3" "9" "5" "11"
i.e. not unique row names for the output x.
A simple fix is to add drop = drop to that argument, such that the
updated unsplit (here called unsplit2) is like this:
unsplit2 <- function (value, f, drop = FALSE)
{
len <- length(if (is.list(f)) f[[1L]] else f)
if (is.data.frame(value[[1L]])) {
x <- value[[1L]][rep(NA, len), , drop = FALSE]
rownames(x) <- unsplit(lapply(value, rownames), f, drop=drop) # note new
"drop=drop"
}
else x <- value[[1L]][rep(NA, len)]
split(x, f, drop = drop) <- value
x
}
This works fine in the example above, and the original levels in gr1 and
gr2 (i.e. they both have four levels) are maintained in the output data
frame such that it has similar attributes as the orignial dff:
> dff3 <- unsplit2(dff2, list(dff$gr1, dff$gr2), drop=TRUE)
> dff3
gr1 gr2 yy
1 1 1 2.13749771
2 1 2 -0.02166458
3 1 1 0.45960452
4 1 2 2.72074958
5 1 1 -0.17536995
6 2 2 -0.08909495
7 2 1 0.94260802
8 2 2 -0.09979505
9 2 1 1.22240834
10 2 2 -0.81710781
11 2 3 0.76071130
>
I must admit that I have not the possiblity to check if such a quick-fix
conflicts with other use of unsplit or on other types of data, but I
cannot see that it should be a problem.
Sincerely
Ivar Herfindal
Centre for Conservation Biology
Norwegian University for Science and Technology
N-7491 Trondheim, Norway
email: ivar.herfin...@bio.ntnu.no
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] heatmap.2 gives wrong colorkey with unequally spaced breaks (PR#14085)
Full_Name: Joris FA Meys Version: 2.10.0 OS: Windows XP Submission from: (NULL) (157.193.194.73) I use the enhanced heatmap function in gplots : heatmap.2 For the presentation of the color key, the code is not 100% adequate. More specifically, in case you define unequally spaced breaks : 1) the keyplot ignores the minimum and maximum of these breaks. Code changed in line 323 and 324 to : min.raw <- min(c(x,breaks), na.rm = TRUE) max.raw <- max(c(x,breaks), na.rm = TRUE) 2) the keyplot gives the histogram with the correct breaks, but the colors remain equally spaced. This is due to the lack of a specification for x in the call to the image() function. Code changed in line 327-328 to : image(x=breaks,z = matrix(z, ncol = 1), col = col, breaks = tmpbreaks, xaxt = "n", yaxt = "n") Line numbers obtained by copy-pasting code from console into Tinn-R. The changed code is how I adapted the function in order to get the desired result. Don't know if it's error-proof, but it works for me. Cheers Joris __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Question about image() behavior
If the x vector has a gap, then image() fills in those spots using the z value of the nearest x value. I had expected it to just leave those spaces blank though. For example x=c(1:5,100:105) y=c(1:10) z=matrix(rnorm(100),10,10) image(x,y,z) I expected that to produce a figure with a wide vertical gap between x=5 and x=100. Is this the correct behavior? Could there be an option added to choose between these two behaviors? Either way, it should be stated in the documentation. Justin [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about image() behavior
On 25/11/2009 3:00 PM, Justin McGrath wrote: If the x vector has a gap, then image() fills in those spots using the z value of the nearest x value. I had expected it to just leave those spaces blank though. For example x=c(1:5,100:105) y=c(1:10) z=matrix(rnorm(100),10,10) image(x,y,z) I expected that to produce a figure with a wide vertical gap between x=5 and x=100. Is this the correct behavior? Could there be an option added to choose between these two behaviors? Either way, it should be stated in the documentation. It's doing what is documented. Giving uneven spacing to x values just says that the rectangles being coloured by the z values are not square. If you want to leave blanks, then put in NA values for z. For example, x <- c(1:6, 100:105) y <- 1:10 z <- matrix(rnorm(110), 11, 10) z[6,] <- NA image(x,y,z) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Symbols, install, and eval.
Hello.
I've got two values which are calls (i.e. LANGSXPs). The first one, x,
is generated through the parser of gram.c. The second one, z, is built
manually, by retrieving the symbols of "str" and of "lm" via the install
function.
The structure of x and y are shown at the bottom of this email.
Evaluating x succeeds:
# R.Raw.eval_langsxp x;;
function (formula, data, subset, weights, na.action, method = "qr",
model = TRUE, x = FALSE, y = FALSE, qr = TRUE, singular.ok = TRUE,
contrasts = NULL, offset, ...)
- : R.Raw.sexp =
# ml_eval x;;
function (formula, data, subset, weights, na.action, method = "qr",
model = TRUE, x = FALSE, y = FALSE, qr = TRUE, singular.ok = TRUE,
contrasts = NULL, offset, ...)
- : R.Raw.sexp =
While evaluating z fails. (ml_eval is a an OCaml function mimicking the
eval function of eval.c).
# R.Raw.eval_langsxp z;;
Erreur dans function (object, ...) :
function générique incorrecte dans 'UseMethod'
Exception: Failure "OCaml-R error in r_eval_sxp C stub.".
# ml_eval z;;
Erreur : impossible de trouver la fonction "���"
/bin/sh: line 1: 15884 Erreur de segmentation ocaml
So I was wondering if someone could give some advice on what I am doing
wrong when building z. Here's the structure of x (parser-generated from
R code/string) and of z (manually constructed with 'install').
# show x;;
- : R.Internal.Pretty.t = CALL (ARG "str", [(NULL, ARG "lm")])
# show z;;
- : R.Internal.Pretty.t =
CALL
(PROMISE
{value =
CLOSURE {formals = LIST [(ARG "object", PLACE); (ARG "...", PLACE)]};
expr =
CALL (SYMBOL (Some ("lazyLoadDBfetch", BUILTIN)),
[(NULL, INT [166954; 101]); (NULL, ARG "datafile");
(NULL, ARG "compressed"); (NULL, ARG "envhook")]);
prom_env = NULL},
[(NULL,
PROMISE
{value =
CLOSURE
{formals =
LIST
[(ARG "formula", PLACE); (ARG "data", PLACE); (Unknown, PLACE);
(ARG "weights", PLACE); (ARG "na.action", PLACE);
(ARG "method", STRINGS ["qr"]); (ARG "model", Unknown);
(ARG "x", Unknown); (ARG "y", Unknown); (Unknown, Unknown);
(ARG "singular.ok", Unknown); (ARG "contrasts", NULL);
(ARG "offset", PLACE); (ARG "...", PLACE)]};
expr =
CALL (SYMBOL (Some ("lazyLoadDBfetch", BUILTIN)),
[(NULL, INT [25; 1139]); (NULL, ARG "datafile");
(NULL, ARG "compressed"); (NULL, ARG "envhook")]);
prom_env = NULL})])
# ml_eval x;;
function (formula, data, subset, weights, na.action, method = "qr",
model = TRUE, x = FALSE, y = FALSE, qr = TRUE, singular.ok = TRUE,
contrasts = NULL, offset, ...)
- : R.Raw.sexp =
# ml_eval z;;
Erreur : impossible de trouver la fonction "��J"
/bin/sh: line 1: 26563 Erreur de segmentation ocaml
make: *** [test-ocaml-r] Erreur 139
All the best,
--
Guillaume Yziquel
http://yziquel.homelinux.org/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
