search for: dispatchgroup

...')) [1] "foo" > setMethod('Complex', 'foo', function(z) callGeneric(z@z)) [1] "Complex" > Arg(new('foo', z=1+0i)) Error in Arg(new("foo", z = 1 + (0+0i))) : non-numeric argument to function > The fix is to add if (DispatchGroup("Complex", call, op, args, env, &x)) return x; near the beginning of do_cmathfuns in complex.c. --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 1 minor = 8.0 yea...

B <- A <- factor(c("a", "b")) outer(A, B, "!=") Warning: "FUN" not meaningful for factors [,1] [,2] [1,] NA NA [2,] NA NA Now, this used to work in 0.63.2, but someone `improved' outer. There it did an implicit as.numeric. The problem is that get in match.fun does not understand group generics, and gets Browse[1]> FUN

Hi all, I've noticed a couple of small bugs/documentation errors related to S3 internal and group generics: * In ?S3groupGeneric, log2 and log10 are not listed as group generics, even though they are in the equivalent S4 groups, and are the source code for do_log1arg contains DispatchGroup("Math", ...) * As well as log2 and log10, tools:::.get_internal_S3_generics() fails to include cbind and rbind, even though they are listed in ?"internal generics" Based on my reading of the documentation and the source code, I believe this function lists all S3 internal gener...

...q(from=Sys.Date(), by=1, length=4)) > ##[1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" > ll <- list(d=ds) > lapply(list(d=ds), round) > ## -> Error in lapply(list(d = ds), round) : dispatch error And that's a separate issue, in DispatchGroup which states that arguments have been evaluated (true) but the 'call' from lapply gives the unevaluated arguments and so there is a mismatch. I'm testing fixes for both. > ## or -- related to bug report by Robert McGehee on R-devel, on 2008-07-29: > sapply(list(d=ds), is.numer...