Thanks Luke for clarifying that you should not call R API from outside the main
thread ever. There’s some false advice in
https://stackoverflow.com/questions/49723216/print-to-terminal-in-a-multithreaded-environment-for-cran-r-package
that suggests it’d be ok if you set up the right mutex.
I be
Thanks Martin and Luke, I think the only way to go is to only use the main
thread to handle the screen output.
-Original Message-
From: Tierney, Luke
Sent: Wednesday, 30 January 2019 1:16 AM
To: Yang Liao
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Rprintf in a multi-threaded
Hi friendly Bioc gang! I'm struggling with what seems like a silly problem. I'm
trying to write a simple wrapper S4 generic that accesses the data slot of
various S4 objects (seurat and SingleCellExperiment objects). So the generic is:
setGeneric("getGE",function(x) standardGeneric("getGE"))
A
Hi Marta,
There are a few issues with your repository. Let’s take a look at your commit
history.
t/hipathia (RELEASE_3_8)❯❯❯ git log —oneline
d93efc9 (HEAD -> RELEASE_3_8, origin/RELEASE_3_8) Fixing bug in Wilcoxon test
bd245a5 fixing version number
Thanks Charlotte for bringing this to our attention. Yes it looks like
there are some serious issues with the data experiment builds. Sorry for
that. We're working on it and will try to have them back on their feet
for the next build iteration (experiment data builds are scheduled to
run on Sun
Along like the lines of Martin Morgan's comment, simpler signatures
mean simpler software. We can typically limit to single dispatch, and
it indicates how the generic is _meant_ to be used, separating the
data arguments from the modulating accessory parameters. I'm not sure
how valuable dispatching
Multiple dispatch also makes it difficult to reason about method selection, at
least for me.
> setGeneric(f, function(a, b, c) standardGeneric("f"))
[1] "f"
> setMethod(f, c(b="missing"), function(a, b, c) {})
> setMethod(f, c(c="missing"), function(a, b, c) {})
> f()
Note: method with signature
Yes the help system could enforce the full signature for the aliases but
that means the end user then will have to always do
?`colSums,SomeClass,ANY,ANY-method`, which feels unnecessary complicated
and confusing in the case of a generic where dispatching on the 2nd and
3rd arguments hardly make
> Pages, Herve
> on Tue, 29 Jan 2019 16:44:47 + writes:
> Hi Martin. Speed is not the concern: I just did some
> quick benchmarking and didn't observe any significant
> difference in method dispatch performance after doing
> setGeneric("toto", function(x, a=0, b=0
Hi Martin.
Speed is not the concern: I just did some quick benchmarking and didn't
observe any significant difference in method dispatch performance after
doing setGeneric("toto", function(x, a=0, b=0, c=0)
standardGeneric("toto")) vs doing setGeneric("toto", signature="x",
function(x, a=0, b=
No functions in the R API are safe to call from any thread other than
the R main thread.
-- Many may need to allocate from the R heap (more as ALTREP evaolves)
and that is not thread safe;
-- Many (and with some compilation options nearly all) can signal an
error, and the subsequent jump
We are experience some intermittent drops in connectivity and are investigating
this matter. Thanks for pointing these out. We hope to have to issue resolved
shortly.
Lori Shepherd
Bioconductor Core Team
Roswell Park Cancer Institute
Department of Biostatistics & Bioinformatics
Elm & Carl
Printing from multiple workers to stdout is problematic anyway, because the
output from different workers is not intrinsically synchronized -- they will
appear interleaved with each other.
Generally for forked processes connections (to stdout, files, databases, urls,
...) need to be opened on t
> Michael Lawrence
> on Mon, 28 Jan 2019 20:47:58 -0800 writes:
> That will have some consequences; for example,
> documentation aliases will need to change. Not sure how
> many packages will need to be fixed outside of Matrix, but
> it's not an isolated change. Martin
> Michael Lawrence
> on Mon, 28 Jan 2019 19:00:59 -0800 writes:
> I agree (2) is a good compromise. CC'ing Martin for his
> perspective. Michael
Hmm there's quite a bit more it, really:
I'd not be unwilling to do so myself, but in the long history of
Matrix development
15 matches
Mail list logo
