[Rd] S3 generic/method consistency issue with R CMD check

[Drew Schmidt]

Hi,

I'm having some trouble setting methods for the qr family of functions.  I
believe I have distilled my misunderstanding in the code snippet below:


foo <- function(x, ...) UseMethod("foo")

foo.default <- function(x) { }

# foo

setGeneric(name = "foo", useAsDefault = foo)

setMethod("foo", signature(x="bar"),
  function(x, ...) { }
)

setGeneric(name="foo.Q",
  function(y, ...)
standardGeneric("foo.Q")
)

setMethod("foo.Q", signature(y="bar"),
  function(y, ...) { }
)

# QR

setGeneric(name = "qr", useAsDefault = qr)

setMethod("qr", signature(x="bar"),
  function(x, ...) { }
)

setGeneric(name="qr.Q",
  function(y, ...)
standardGeneric("qr.Q")
)

setMethod("qr.Q", signature(y="bar"),
  function(y, ...) { }
)


If you send this to R CMD check, then it gives exactly one WARNING about
S3 consistency:


* checking S3 generic/method consistency ... WARNING
qr:
  function(x, ...)
qr.Q:
  function(y, ...)


This seems to be complaining about the fact that qr.Q dispatches on 'y'
instead of 'x'.  But there is no complaint about foo/foo.Q even though, I
believe, the only difference is a mechanical substitution of
generic/method names.

Ultimately I would like to be able to set methods for the qr family in a
way that maximally mimics R in both syntax and return.  I'm clearly doing
something wrong, but I'm not really sure how else to proceed.  Any help in
clearing up my misunderstanding here would be greatly appreciated.

Thanks.

-- 
Drew Schmidt
National Institute for Computational Sciences
University of Tennessee

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] paths and Rook problems only in OSX CRAN binary package?

[Richard D. Morey]

Hi everyone,

I'm trying to diagnose a problem in my R package, but it is a little 
tricky since it seems to occur only with the Mac OSX CRAN binary build.

My package starts a Rook server and opens a browser. On my own system 
(details below), when I build the package, I have no trouble. The Rook 
server starts and the page loads in the browser.

However, if I've installed it from CRAN, I get the following error when 
trying to open my Rook interface:

##
Warning message:
In normalizePath(file.path(root, path_info)) :

path[1]="/Volumes/XT3/Rdev-web/QA/Simon/packages/leopard-universal/Rlib/2.15/BayesFactor/.//www/warning.html":
No such file or directory
##

I assume "Simon" refers to Simon Urbanek.

www/warning.html is the file Rook is attempting to open. This looks like 
a path from the CRAN build machine. How did this make it into my 
package? I'm sort of baffled, and I don't know how to diagnose it.

To replicate:
#
install.packages('BayesFactor')
library(BayesFactor)
data(puzzles)
aovGUI(y = puzzles$RT, dataFixed = puzzles[,3:4], dataRandom = puzzles$ID)
#

When I set
options(warning.expression = quote(recover()))

I see where the problem lies. In the frame "15: file_server$call(env)", 
the variable "root" is defined as:

Browse[1]> root
[1] 
"/Volumes/XT3/Rdev-web/QA/Simon/packages/leopard-universal/Rlib/2.15/BayesFactor/."

But "find" returns nothing for "root":
Browse[1]> find("root")
character(0)

In the Rook source here 
(https://github.com/jeffreyhorner/Rook/blob/master/Rook/R/File.R) is the 
reference to "root", but I'm not sure where the specific path value 
comes from.

Further information:
 > sessionInfo()
R version 2.15.2 (2012-10-26)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods base

loaded via a namespace (and not attached):
[1] tools_2.15.2


My Rook version is 1.0-8 and I'm running Mountain Lion (10.8.2). Any 
hints would be appreciated.

Best,
Richard



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] why does do_stop call R_GetTraceback ?

[Andrew Piskorski]

I'm using:
  R 2.15.1 (beta), 2012-06-11, svn.rev 59557, x86_64-unknown-linux-gnu
And I normally use:
  options("error"=recover)

I recently ran into a problem where when my code called stop(),
recover() was incredibly slow (hours) because it was trying to deparse
an extremely large call.  I worked around that by instead using my own
recover function which avoids deparsing anything large.  (Perhaps it
would be better to instead make the deparsing much faster, but I don't
know how to do that.)

However, now I find that when I'm DONE debugging and exit my recover
function, R still sits there using 100% cpu for another 41 seconds
before finishing and returning me to the top-level interactive prompt.
I wondered why...  Rprof() seems to say that all the time is being
taken in stop().

AFAICT, in this case stop() is basically just doing this:

  .Internal(stop(as.logical(TRUE), .makeMessage(..., domain=NULL)))

where the "..." is just the single string I passed to stop(), e.g.,
stop("This code is broken.").

So next, after exiting (my hacked version of) recover(), and while
stop() was still trying to finish up, I attached gdb to my R process.
I've appended the relevant part of the (long) backtrace below.

As you can see, R seems to have been busy calling R_GetTraceback() and
a bunch of subsidiary deparse functions.  But, at that point I'm done
with recover(), and when stop() finally finishes NOTHING else has been
printed out - no additional traceback, nothing.  So why are we calling
jump_to_top_ex() with traceback=TRUE, what good does the call to
R_GetTraceback() do?

That jump_to_top_ex() code only calls R_GetTraceback() when
R_Interactive or haveHandler are true.  I am certainly running
interactively here, and I did define a handler with options("error"=).
But AFAICT, my handler makes no use whatsoever of any of the work done
by R_GetTraceback().  In fact, I don't see any way it could even if I
wanted it to.  And if I remove my handler with options("error"=NULL),
I STILL get no additional "trace back" output at all.

So it looks to me as if calling jump_to_top_ex() with traceback=TRUE
and spending the extra 41 seconds in R_GetTraceback() NEVER does
anything useful!  Is this actually true, or does R_GetTraceback() have
some important side effect that I'm unaware of?

Thanks for your help!


(gdb) bt
#0  vector2buff (s=0xba73ed0, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:1298
#1  deparse2buff (s=0xba73ed0, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:1123
#2  0x7ff28807034f in vec2buff (v=, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:1402
#3  0x7ff28806ea20 in deparse2buff (s=0xba734d0, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:753
#4  0x7ff28807034f in vec2buff (v=, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:1402
#5  0x7ff28806ea20 in deparse2buff (s=0xed9e350, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:753
#6  0x7ff28807034f in vec2buff (v=, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:1402
#7  0x7ff28806ea20 in deparse2buff (s=0xed9c818, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:753
#8  0x7ff28806e40c in args2buff (arglist=0xd90b930, 
lineb=, formals=0, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:1438
#9  0x7ff28806e822 in deparse2buff (s=0xd90b8c0, d=0x7fffa18d4a00)
at ../../../src/main/deparse.c:1108
#10 0x7ff2880706f9 in deparse2 (call=, abbrev=FALSE, 
cutoff=, backtick=, opts=65, 
nlines=-1) at ../../../src/main/deparse.c:484
#11 deparse1WithCutoff (call=, abbrev=FALSE, 
cutoff=, backtick=, opts=65, 
nlines=-1) at ../../../src/main/deparse.c:221
#12 0x7ff2880a07b5 in R_GetTraceback (skip=0)
at ../../../src/main/errors.c:1312
#13 0x7ff2880a347a in jump_to_top_ex (traceback=TRUE, 
tryUserHandler=, processWarnings=FALSE, 
resetConsole=TRUE, ignoreRestartContexts=13368712)
at ../../../src/main/errors.c:837
#14 0x7ff2880a1ba9 in verrorcall_dflt (call=0x28ea1c0, 
format=, ap=)
at ../../../src/main/errors.c:663
#15 0x7ff2880a239e in Rf_errorcall (call=, 
format=) at ../../../src/main/errors.c:698
#16 0x7ff2880a25c2 in do_stop (call=, 
op=, args=0x10ecae78, rho=)
at ../../../src/main/errors.c:1095
[...]
#79 0x00400819 in _start ()

-- 
Andrew Piskorski 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel