Re: [Bioc-devel] [Untrusted Server] Rprintf in a multi-threaded environment

2019-01-28 Thread Yang Liao
Thanks, Shian! Yes, I think the only way to make it work is to send the messages to the main thread. Cheers, Yang -Original Message- From: Shian Su Sent: Tuesday, 29 January 2019 3:22 PM To: Yang Liao Cc: bioc-devel@r-project.org Subject: Re: [Untrusted Server][Bioc-devel] Rprintf in

Re: [Bioc-devel] Pushing towards a better home for matrix generics

2019-01-28 Thread Michael Lawrence via Bioc-devel
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 might comment on the rationale for the full signature, since he defined those generics. On Mon, Jan

Re: [Bioc-devel] [Untrusted Server] Rprintf in a multi-threaded environment

2019-01-28 Thread Shian Su
Hi Yang, That was my SO thread you found, and as you can see, the issue was never clearly explained to me besides the warning in the docs. I don’t believe anything’s changed to allow the R API to be called from different threads, so extra effort is still required. What I ended up doing in my

Re: [Bioc-devel] Question: error in makeTxDbFromUCSC

2019-01-28 Thread Pages, Herve
Hi there, I answered this yesterday on the support site:   https://support.bioconductor.org/p/117265/#117346 Cheers, H. On 1/26/19 05:13, Vincent Carey wrote: > If I am not mistaken the same problem is on the support site and I provided > some > commentary at >

[Bioc-devel] Rprintf in a multi-threaded environment

2019-01-28 Thread Yang Liao
Hi, I'm not sure if some C developers have gone through this problem: it seems that Rprintf cannot work safely in a multi-threaded environment. In particular, if I call Rprintf() from a then-created thread while the stack size checking is enabled (ie the "R_CStackLimit" pointer isn't set to

Re: [Bioc-devel] Pushing towards a better home for matrix generics

2019-01-28 Thread Pages, Herve
Actually there is a 4th solution which is to modify the definition of the implicit generics in the methods package (file makeBasicFunsList.R) to make them dispatch on their 1st arg only. Should be easy. Then no package will need to use a setGeneric statement anymore. Everybody will

Re: [Bioc-devel] Pushing towards a better home for matrix generics

2019-01-28 Thread Michael Lawrence via Bioc-devel
I agree (2) is a good compromise. CC'ing Martin for his perspective. Michael On Mon, Jan 28, 2019 at 6:58 PM Pages, Herve wrote: > > Hi Aaron, > > The 4 matrix summarization generics currently defined in BiocGenerics > are defined as followed: > >setGeneric("rowSums", signature="x") >

Re: [Bioc-devel] Pushing towards a better home for matrix generics

2019-01-28 Thread Pages, Herve
Hi Aaron, The 4 matrix summarization generics currently defined in BiocGenerics are defined as followed:   setGeneric("rowSums", signature="x")   setGeneric("colSums", signature="x")   setGeneric("rowMeans", signature="x")   setGeneric("colMeans", signature="x") The only reason for having

[Bioc-devel] Single Package Builder for New Submissions

2019-01-28 Thread Ludwig Geistlinger
Dear Lori, Is the update of the MAC SPB still ongoing? Today, I managed to produce three different build reports - from "all-ok" to "timeout" and "errors" just by documentation enhancements and version number bumps, ie no changes on the actual R stuff (code, vignette chunks, examples, etc):

[Bioc-devel] missing devel experiment data builds

2019-01-28 Thread Charlotte Soneson
Hi, I just wanted to ask whether there might be a problem with the devel builds for the experimental data packages. Judging from http://bioconductor.org/checkResults/3.9/data-experiment-LATEST/# it seems that the latest