Re: [Rd] suppress *specific* warnings?
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and found later why the approach is flawed "by design" :
Internationalization / Localization:
- If the warning comes from a "standard R" function,
the warning is almost surely different in a (say) German
locale, and your pattern won't be detected.
- Ditto if from a recommended package.
- If it is a warning that is not translated then it may be that
it is just not *YET* translated.
The really dangerous thing about matching error / warning
messages -- I had done it in the past with the error message I
caught via tryCatch() --
is that
- in your tests the code will work perfectly.
- on CRAN the code will work perfectly, as "they" also use
the English (or C) locale.
So, by doing this you are distributing code that "almost always"
works ... in your environment if you are US, UK or similarly
based.
Indeed, a *really* dangerous practice.
Martin Maechler, ETH Zurich
> Martin Morgan
> on Tue, 23 Oct 2012 05:28:48 -0700 writes:
> On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote:
>> On Sun, 21 Oct 2012, Martin Morgan wrote:
>>
>>> On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings()
forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which
isn't
helping me ... ?)
suppressWarnings2 <- function(expr,regex=NULL) {
opts <- options(warn = -1)
on.exit(options(opts))
>>>
>>> I'm not really sure what the options(warn=-1) is doing there, maybe its
for
>>> efficiency to avoid generating a warning message (as distinct from
signalling
>>
>> The sources in srs/library/base/conditions.R have
>>
>> suppressWarnings <- function(expr) {
>> ops <- options(warn = -1) ## FIXME: temporary hack until R_tryEval
>> on.exit(options(ops)) ## calls are removed from methods code
>> withCallingHandlers(expr,
>> warning=function(w)
>> invokeRestart("muffleWarning"))
>> }
>>
>> I uspect we have still not entirely eliminated R_tryEval in this context
>> but I'm not sure. Will check when I get a chance.
>>
>>> a warning). I think you're after something like
>>>
>>> suppressWarnings2 <-
>>> function(expr, regex=character())
>>> {
>>> withCallingHandlers(expr, warning=function(w) {
>>> if (length(regex) == 1 && length(grep(regex, conditionMessage(w {
>>> invokeRestart("muffleWarning")
>>> }
>>> })
>>> }
>>
>> A problem with using expression matching is of course that this fails
>> with internationalized messages. Ideally warnings should be signaled as
>> warning conditions of a particular class, and that class can be used
>> to discriminate. Unfortunately very few warnings are designed this way.
> Probably specific messages, rather than patterns, would be handled and
then
> suppressWarnings2 <- function(expr, messages = character())
> {
> opts <- options(warn = -1)
> on.exit(options(ops))
> withCallingHandlers(expr, warning=function(w) {
> if (conditionMessage(w) %in% messages)
> invokeRestart("muffleWarning")
> })
> }
> gives one the illusion of speaking many languages
> suppressWarnings2(log(-1), gettext("NaNs introduced", domain="R"))
> Martin
>>
>> Best,
>>
>> luke
>>
>>>
>>> If the restart isn't invoked, then the next handler is called and the
warning
>>> is handled as normal. So with
>>>
>>> f <- function() {
>>> warning("oops")
>>> 2
>>> }
>>>
>>> there is
>>>
suppressWarnings2(f())
>>> [1] 2
>>> Warning message:
>>> In f() : oops
suppressWarnings2(f(), "oops")
>>> [1] 2
>>>
>>> For your own code I think a better strategy is to create a sub-class of
>>> warnings that can be handled differently
>>>
>>> mywarn <-
>>> function(..., call.=TRUE, immediate.=FALSE, domain=NULL)
>>> {
>>> msg <- .makeMessage(..., domain=domain, appendLF=FALSE)
>>> call <- NULL
>>> if (call.)
>>> call <- sy
Re: [Rd] suppress *specific* warnings?
On 12-10-25 5:28 AM, Martin Maechler wrote:
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and found later why the approach is flawed "by design" :
Internationalization / Localization:
- If the warning comes from a "standard R" function,
the warning is almost surely different in a (say) German
locale, and your pattern won't be detected.
- Ditto if from a recommended package.
- If it is a warning that is not translated then it may be that
it is just not *YET* translated.
I think the other Martin's suggestion addressed this: he matched the
translated message, not the English original.
Duncan Murdoch
The really dangerous thing about matching error / warning
messages -- I had done it in the past with the error message I
caught via tryCatch() --
is that
- in your tests the code will work perfectly.
- on CRAN the code will work perfectly, as "they" also use
the English (or C) locale.
So, by doing this you are distributing code that "almost always"
works ... in your environment if you are US, UK or similarly
based.
Indeed, a *really* dangerous practice.
Martin Maechler, ETH Zurich
Martin Morgan
on Tue, 23 Oct 2012 05:28:48 -0700 writes:
> On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote:
>> On Sun, 21 Oct 2012, Martin Morgan wrote:
>>
>>> On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings()
forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which
isn't
helping me ... ?)
suppressWarnings2 <- function(expr,regex=NULL) {
opts <- options(warn = -1)
on.exit(options(opts))
>>>
>>> I'm not really sure what the options(warn=-1) is doing there, maybe
its for
>>> efficiency to avoid generating a warning message (as distinct from
signalling
>>
>> The sources in srs/library/base/conditions.R have
>>
>> suppressWarnings <- function(expr) {
>> ops <- options(warn = -1) ## FIXME: temporary hack until R_tryEval
>> on.exit(options(ops)) ## calls are removed from methods code
>> withCallingHandlers(expr,
>> warning=function(w)
>> invokeRestart("muffleWarning"))
>> }
>>
>> I uspect we have still not entirely eliminated R_tryEval in this context
>> but I'm not sure. Will check when I get a chance.
>>
>>> a warning). I think you're after something like
>>>
>>> suppressWarnings2 <-
>>> function(expr, regex=character())
>>> {
>>> withCallingHandlers(expr, warning=function(w) {
>>> if (length(regex) == 1 && length(grep(regex, conditionMessage(w {
>>> invokeRestart("muffleWarning")
>>> }
>>> })
>>> }
>>
>> A problem with using expression matching is of course that this fails
>> with internationalized messages. Ideally warnings should be signaled as
>> warning conditions of a particular class, and that class can be used
>> to discriminate. Unfortunately very few warnings are designed this way.
> Probably specific messages, rather than patterns, would be handled and
then
> suppressWarnings2 <- function(expr, messages = character())
> {
> opts <- options(warn = -1)
> on.exit(options(ops))
> withCallingHandlers(expr, warning=function(w) {
> if (conditionMessage(w) %in% messages)
> invokeRestart("muffleWarning")
> })
> }
> gives one the illusion of speaking many languages
> suppressWarnings2(log(-1), gettext("NaNs introduced", domain="R"))
> Martin
>>
>> Best,
>>
>> luke
>>
>>>
>>> If the restart isn't invoked, then the next handler is called and the
warning
>>> is handled as normal. So with
>>>
>>> f <- function() {
>>> warning("oops")
>>> 2
>>> }
>>>
>>> there is
>>>
suppressWarnings2(f())
>>> [1] 2
>>> Warning message:
>>> In f() : oops
suppressWarnings2(f(), "oops")
>>> [1] 2
>>>
>>> For your own code I think a better strategy is to create a sub-class of
>>> warnings th
Re: [Rd] concurrent requests (Rook, but I think the question is more general)
On 24/10/12 10:55 PM, Simon Urbanek wrote:
The point is that you need a separate monitoring process or threads. That
process can be R, Rserve or any thing else.
Thanks for the tips. This is what I'm currently contemplating:
1. Main interface starts in user's R session, and opens up the interface
(HTML/Javascript using Rook package)
2. When analysis starts, Rserve is started, with its own web server,
using Rook, for status updates
3. During analysis, main process calls a callback function which uses
RSassign() to send progress updates to the Rserve server
4. HTML/Javascript interface can connect to the webserver on the Rserve
server to get status updates
5. When analysis is done, use RSshutdown() and RSclose() to clean up.
Does this seem reasonable?
One problem I'm having is that when I start Rook on the Rserve server,
the webserver does not respond (although it is started). Does Rserve
only respond to requests on the port assigned for RSclient commands?
Best,
Richard
Here's an example:
###
library(Rserve)
### This works:
stuff = expression({
library(Rook)
s <- Rhttpd$new()
s$add(
app=system.file('exampleApps/helloworld.R',package='Rook'),
name='hello'
)
s$start(quiet=TRUE)
s$browse(1)
print(s$full_url(1))
})
# This will open the browser to the test app, asking for your name
eval(stuff)
### This does not:
Rserve(args="--no-save")
c <- RSconnect()
RSassign(c, stuff)
# This opens the browser to the correct URL, but the webserver doesn't
respond.
RSeval(c, quote(eval(stuff)))
#
# cleanup
RSshutdown(c)
RSclose(c)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] concurrent requests (Rook, but I think the question is more general)
On Thu, Oct 25, 2012 at 8:45 AM, Richard D. Morey wrote:
> On 24/10/12 10:55 PM, Simon Urbanek wrote:
>>
>>
>> The point is that you need a separate monitoring process or threads. That
>> process can be R, Rserve or any thing else.
>>
>>
>>
>
> Thanks for the tips. This is what I'm currently contemplating:
>
> 1. Main interface starts in user's R session, and opens up the interface
> (HTML/Javascript using Rook package)
> 2. When analysis starts, Rserve is started, with its own web server, using
> Rook, for status updates
> 3. During analysis, main process calls a callback function which uses
> RSassign() to send progress updates to the Rserve server
> 4. HTML/Javascript interface can connect to the webserver on the Rserve
> server to get status updates
> 5. When analysis is done, use RSshutdown() and RSclose() to clean up.
>
> Does this seem reasonable?
>
> One problem I'm having is that when I start Rook on the Rserve server, the
> webserver does not respond (although it is started). Does Rserve only
> respond to requests on the port assigned for RSclient commands?
>
> Best,
> Richard
>
> Here's an example:
>
> ###
>
> library(Rserve)
>
> ### This works:
>
> stuff = expression({
>
> library(Rook)
> s <- Rhttpd$new()
> s$add(
> app=system.file('exampleApps/helloworld.R',package='Rook'),
> name='hello'
> )
> s$start(quiet=TRUE)
> s$browse(1)
> print(s$full_url(1))
> })
>
> # This will open the browser to the test app, asking for your name
> eval(stuff)
>
> ### This does not:
>
> Rserve(args="--no-save")
> c <- RSconnect()
> RSassign(c, stuff)
>
> # This opens the browser to the correct URL, but the webserver doesn't
> respond.
> RSeval(c, quote(eval(stuff)))
>
>
> #
> # cleanup
> RSshutdown(c)
> RSclose(c)
>
This "works" for me if I omit the quote(). I get an error, but the
webapp seems to work. Also, I didn't eval(stuff) locally, only on the
server:
> RSeval(c, eval(stuff))
Loading required package: tools
Loading required package: brew
starting httpd help server ... done
[1] "http://127.0.0.1:15583/custom/hello";
Error in parse(text = paste("{", paste(expr, collapse = "\n"), "}")) :
:1:8: unexpected '/'
1: { http:/
^
> traceback()
3: parse(text = paste("{", paste(expr, collapse = "\n"), "}"))
2: serialize(parse(text = paste("{", paste(expr, collapse = "\n"),
"}"))[[1]], NULL)
1: RSeval(c, eval(stuff))
> sessionInfo()
R Under development (unstable) (2012-10-23 r61007)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] tools stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] Rook_1.0-8 brew_1.0-6 Rserve_0.6-8
[4] BiocInstaller_1.9.4
Dan
>
> __
> 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] concurrent requests (Rook, but I think the question is more general)
On 25/10/12 7:14 PM, Dan Tenenbaum wrote:
On Thu, Oct 25, 2012 at 8:45 AM, Richard D. Morey wrote:
On 24/10/12 10:55 PM, Simon Urbanek wrote:
The point is that you need a separate monitoring process or threads. That
process can be R, Rserve or any thing else.
Thanks for the tips. This is what I'm currently contemplating:
1. Main interface starts in user's R session, and opens up the interface
(HTML/Javascript using Rook package)
2. When analysis starts, Rserve is started, with its own web server, using
Rook, for status updates
3. During analysis, main process calls a callback function which uses
RSassign() to send progress updates to the Rserve server
4. HTML/Javascript interface can connect to the webserver on the Rserve
server to get status updates
5. When analysis is done, use RSshutdown() and RSclose() to clean up.
Does this seem reasonable?
One problem I'm having is that when I start Rook on the Rserve server, the
webserver does not respond (although it is started). Does Rserve only
respond to requests on the port assigned for RSclient commands?
Best,
Richard
Here's an example:
###
library(Rserve)
### This works:
stuff = expression({
library(Rook)
s <- Rhttpd$new()
s$add(
app=system.file('exampleApps/helloworld.R',package='Rook'),
name='hello'
)
s$start(quiet=TRUE)
s$browse(1)
print(s$full_url(1))
})
# This will open the browser to the test app, asking for your name
eval(stuff)
### This does not:
Rserve(args="--no-save")
c <- RSconnect()
RSassign(c, stuff)
# This opens the browser to the correct URL, but the webserver doesn't
respond.
RSeval(c, quote(eval(stuff)))
#
# cleanup
RSshutdown(c)
RSclose(c)
This "works" for me if I omit the quote(). I get an error, but the
webapp seems to work. Also, I didn't eval(stuff) locally, only on the
server:
I'll try this in a bit and see what happens.
I forgot my sessionInfo()...
> sessionInfo()
R version 2.15.1 (2012-06-22)
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] tools stats graphics grDevices utils datasets methods
base
other attached packages:
[1] Rook_1.0-8 brew_1.0-6 Rserve_0.6-8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] concurrent requests (Rook, but I think the question is more general)
Richard,
that is not what I had in mind :). Also Rserve 0.x doesn't have built-in HTTP,
only the 1.x series does. Unfortunately I don't have any time today to write
example code, but I would suggest using HTTP for both - just have a hook that
simply accepts serialized R object in the body of the HTTP request and assigns
it to your result. Then you have a second hook that delivers the result back
(in whatever form you want it). It should be really easy to do with Rook in a
separate process. In your computation session you simply fire off a HTTP POST
request with the current status as a serialized R object.
Cheers,
Simon
On Oct 25, 2012, at 11:45 AM, Richard D. Morey wrote:
> On 24/10/12 10:55 PM, Simon Urbanek wrote:
>>
>> The point is that you need a separate monitoring process or threads. That
>> process can be R, Rserve or any thing else.
>>
>>
>>
>
> Thanks for the tips. This is what I'm currently contemplating:
>
> 1. Main interface starts in user's R session, and opens up the interface
> (HTML/Javascript using Rook package)
> 2. When analysis starts, Rserve is started, with its own web server, using
> Rook, for status updates
> 3. During analysis, main process calls a callback function which uses
> RSassign() to send progress updates to the Rserve server
> 4. HTML/Javascript interface can connect to the webserver on the Rserve
> server to get status updates
> 5. When analysis is done, use RSshutdown() and RSclose() to clean up.
>
> Does this seem reasonable?
>
> One problem I'm having is that when I start Rook on the Rserve server, the
> webserver does not respond (although it is started). Does Rserve only respond
> to requests on the port assigned for RSclient commands?
>
> Best,
> Richard
>
> Here's an example:
>
> ###
>
> library(Rserve)
>
> ### This works:
>
> stuff = expression({
> library(Rook)
> s <- Rhttpd$new()
> s$add(
>app=system.file('exampleApps/helloworld.R',package='Rook'),
>name='hello'
> )
> s$start(quiet=TRUE)
> s$browse(1)
> print(s$full_url(1))
> })
>
> # This will open the browser to the test app, asking for your name
> eval(stuff)
>
> ### This does not:
>
> Rserve(args="--no-save")
> c <- RSconnect()
> RSassign(c, stuff)
>
> # This opens the browser to the correct URL, but the webserver doesn't
> respond.
> RSeval(c, quote(eval(stuff)))
>
>
> #
> # cleanup
> RSshutdown(c)
> RSclose(c)
>
>
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial typo in relist.Rd
in src/library/utils/man/relist.Rd, line 50:
objects into a vector representation. \code{relist()}, it's methods and
spurious apostrophe ...
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trivial typo in relist.Rd
On 12-10-25 7:18 PM, Ben Bolker wrote:
in src/library/utils/man/relist.Rd, line 50:
objects into a vector representation. \code{relist()}, it's methods and
spurious apostrophe ...
Thanks, will fix.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] parallel::pvec FUN types differ when v is a list; code simplifications?
In pvec(list(1, 2), FUN, mc.cores=2) FUN sees integer() arguments whereas
pvec(list(1, 2, 3), FUN, mc.cores=2) FUN sees list() arguments; the latter seems
consistent with pvec's description.
This came up in a complicated Bioconductor thread about generics and parallel
evaluation
https://stat.ethz.ch/pipermail/bioc-devel/2012-October/003745.html
One relevant point is that a light-weight re-write of parallel/R/unix/pvec.R
(below) appears to avoid the need for an object v to satisfy
is.vector
as.list
[
and instead only requires
[
This can be important when as.list() forces an inefficient representation of an
object that can nonetheless be subset with [. It also seems like the code below
will be more space efficient, since v is not split into a second object in the
parent but only subset in the children?
Index: pvec.R
===
--- pvec.R (revision 61012)
+++ pvec.R (working copy)
@@ -21,8 +21,6 @@
pvec <- function(v, FUN, ..., mc.set.seed = TRUE, mc.silent = FALSE,
mc.cores = getOption("mc.cores", 2L), mc.cleanup = TRUE)
{
-if (!is.vector(v)) stop("'v' must be a vector")
-
env <- parent.frame()
cores <- as.integer(mc.cores)
if(cores < 1L) stop("'mc.cores' must be >= 1")
@@ -31,16 +29,7 @@
if(mc.set.seed) mc.reset.stream()
n <- length(v)
-l <- if (n <= cores) as.list(v) else {
-## compute the scheduling, making it as fair as possible
-il <- as.integer(n / cores)
-xc <- n - il * cores
-sl <- rep(il, cores)
-if (xc) sl[1:xc] <- il + 1L
-si <- cumsum(c(1L, sl))
-se <- si + c(sl, 0L) - 1L
-lapply(seq_len(cores), function(ix) v[si[ix]:se[ix]])
-}
+si <- splitIndices(n, cores)
jobs <- NULL
cleanup <- function() {
## kill children if cleanup is requested
@@ -59,8 +48,8 @@
on.exit(cleanup())
FUN <- match.fun(FUN)
## may have more cores than tasks
-jobs <- lapply(seq_len(min(n, cores)),
- function(i) mcparallel(FUN(l[[i]], ...), name = i,
+jobs <- lapply(si,
+ function(i) mcparallel(FUN(v[i], ...),
mc.set.seed = mc.set.seed,
silent = mc.silent))
res <- mccollect(jobs)
On 10/24/2012 05:07 PM, Cook, Malcolm wrote:
On 10/24/12 12:44 AM, "Michael Lawrence" wrote:
I agree that it would fruitful to have parLapply in BiocGenerics. It looks
to be a flexible abstraction and its presence in the parallel package
makes
it ubiquitous. If it hasn't been done already, mclapply (and mcmapply)
would be good candidates, as well. The fork-based parallelism is
substantively different in terms of the API from the more general
parallelism of parLapply.
Someone was working on some more robust and convenient wrappers around
mclapply. Did that ever see the light of day?
If you are referring to
http://thread.gmane.org/gmane.science.biology.informatics.conductor/43660
in which I had offered some small changes to parallel::pvec
https://gist.github.com/3757873/
and after which Martin had provided me with a route I have not (yet?)
followed toward submitting a patch to R for consideration by R-devel /
Simon Urbanek in
http://grokbase.com/t/r/bioc-devel/129rbmxp5b/applying-over-granges-and-oth
er-vectors-of-ranges#201209248dcn0tpwt7k7g9zsjr4dha6f1c
On Tue, Oct 23, 2012 at 12:13 PM, Steve Lianoglou <
mailinglist.honey...@gmail.com**> wrote:
In response to a question from yesterday, I pointed someone to the
ShortRead `srapply` function and I wondered to myself why it had to
necessarily by "burried" in the ShortRead package (aside from it
having a `sr` prefix).
I don't know that srapply necessarily 'got it right'...
One thing I like about srapply is its support for a reduce argument.
I had thought it might be a good idea to move that (or something like
that) to BiocGenerics (unless implementations aren't allowed there)
but also realized that it would add more dependencies where someone
might not necessarily need them.
But, almost surely, a large majority of the people will be happy to do
some form of ||-ization, so in my mind it's not such an onerous thing
to add -- on the other hand, this large majority is probably enriched
for people who are doing NGS analysis, in which case, keeping it in
ShortRead can make some sense.
I remain confused about the need for putting any of this into BiocGenerics
at all. It seems to me that properly construed parallization primitives
ought to 'just work' with any object which supports indexing and length.
I would appreciate hearing arguments to the contrary.
Florian, in a similar vein, could we not seek to change
parallel::makeCluster to be extensible to, say, support SGE cluster? THis
seems like the 'right thing to do'. ???
Regardless, I think we have raised
