Re: [Rd] Sort output of apropos
Seems sensible, but 2.5.0 is in feature freeze and it is possible that someone has relied on this. I've added this (and a \value section to the help file) for R-devel. On Wed, 11 Apr 2007, Seth Falcon wrote: > A further improvement to apropos() would be to sort the output. > Currently, the output of apropos is in the order found on the search > list and this will rarely be useful to the user. > > All that is needed is a sort(x) at the end of the function. > > + seth > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sort output of apropos
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > Seems sensible, but 2.5.0 is in feature freeze and it is possible that > someone has relied on this. > > I've added this (and a \value section to the help file) for R-devel. Excellent. Thank you. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] save() and interrupts
Hi, are there any (cross-platform) specs on what the saved filed is if save() is interrupted, e.g. by a user interrupt? It could be non-existing, empty, partly written, or completed. Thanks Henrik __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] save() and interrupts
On Sun, 15 Apr 2007, Henrik Bengtsson wrote: > are there any (cross-platform) specs on what the saved filed is if > save() is interrupted, e.g. by a user interrupt? It could be > non-existing, empty, partly written, or completed. My understanding is that you cannot user interrupt compiled code unless it is set up to check interrupts. Version 2 saves are done via the internal saveToConn, and I don't see any calls to R_CheckUserInterrupt there. So you only need to worry about user interrupts in the R code, and that has an on.exit action to close the connection (which should be executed even if you interrupt). Which suggests that the file will be non-existent empty complete and the first two depend on interrupting in the millisecond or less before the compiled code gets called. For other forms of interrupts, e.g. a Unix kill -9, the file state could be anything. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] save() and interrupts
Hi, thanks for this. On 4/15/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Sun, 15 Apr 2007, Henrik Bengtsson wrote: > > > are there any (cross-platform) specs on what the saved filed is if > > save() is interrupted, e.g. by a user interrupt? It could be > > non-existing, empty, partly written, or completed. > > My understanding is that you cannot user interrupt compiled code unless it > is set up to check interrupts. Version 2 saves are done via the internal > saveToConn, and I don't see any calls to R_CheckUserInterrupt there. So > you only need to worry about user interrupts in the R code, and that has > an on.exit action to close the connection (which should be executed even > if you interrupt). Which suggests that the file will be > > non-existent > empty > complete > > and the first two depend on interrupting in the millisecond or less before > the compiled code gets called. I'll put it on my todo list to investigate how to make save() more robust against interrupts before calling the internal code. One option is to use tryCatch(). However, that does not handle too frequent user interrupts, e.g. if an interrupt is sent while in the "interrupt" call, that will interrupt the function. So, tryCatch() alone will only lower the risk for incomplete empty files. For data written to files, one alternative is to check for files of zero size in the on.exit() statement and remove such. /Henrik > > For other forms of interrupts, e.g. a Unix kill -9, the file state could > be anything. > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as() creates invalid entries in methods list?
Hi,
We've observed rather strange behavior related to as(). When as() is
used to make a conversion to a super class, an invalid entry is
inserted into the table of methods.
> setClass("A", contains="list")
> get(".MTable", environment(coerce))[["list#A"]]
NULL
> as(list(), "A")
> get(".MTable", environment(coerce))[["list#A"]]
function (from, to)
{
obj <- new("A")
as(obj, "list") <- from
obj
}
Entries in .MTable should be MethodDefinition objects (or at least
that is what is usually there for methods defined via setAs). It
happens that if you try to load a package that has a NAMESPACE file
with a directive exportMethods(coerce) but no call to setAs then you
get an error:
library("hello")
Error in .mergeMethodsTable(generic, mtable, get(tname, envir = env), :
Invalid object in meta table of methods for "coerce", label
"list#A", had class "function"
So I think there are two problems that might need fixes:
1. methods::as shouldn't create invalid entries. I've included a
patch (see below) that seems to help, but I'm not sure it is the
right fix. For example, there are two helper functions that create
coerce methods and perhaps a better fix is for both of these to be
modified to return MethodDefinition objects.
2. The name space code allows packages to have methods listed in
exportMethods directives even if no corresponding setMethod,
setGeneric, or setAs call appears in the R code. Ideally, a
warning or error would be raised in this case. I'm not sure such a
declaration should do any harm in theory, but in practice it seems
to trigger subtle bugs in the methods package.
+ seth
--- a/src/library/methods/R/as.R
+++ b/src/library/methods/R/as.R
@@ -37,9 +37,6 @@ as <-
test <- [EMAIL PROTECTED]
asMethod <- .makeAsMethod([EMAIL PROTECTED], [EMAIL
PROTECTED], Class, Clas
canCache <- (!is(test, "function")) || identical(body(test),
- if(canCache) { # make into method definition
-asMethod <- .asCoerceMethod(asMethod, sig, FALSE)
- }
}
}
if(is.null(asMethod) && extends(Class, thisClass)) {
@@ -54,6 +51,10 @@ as <-
fdef = coerceFun, mlist =
coerceMethods)
inherited <- TRUE
+} else {
+if(canCache) { # make into method definition
+asMethod <- .asCoerceMethod(asMethod, sig, FALSE)
+}
}
## cache in the coerce function's environment
if(canCache && !is.null(asMethod)) {
--
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
