I fully agree with Kevin. Front-ends can always use pthread_atfork() to close
descriptors and suspend threads in children.
Anyone who thinks you can use PSOCK clusters has obviously not used mclappy()
in real applications - trying to save the workspace and restore it in 20 new
processes is not
I think it's worth saying that mclapply() works as documented: it
relies on forking, and so doesn't work well in environments where it's
unsafe to fork. This is spelled out explicitly in the documentation of
?mclapply:
It is strongly discouraged to use these functions in GUI or embedded
Hi Inaki,
> "Performant"... in terms of what. If the cost of copying the data
> predominates over the computation time, maybe you didn't need
> parallelization in the first place.
Performant in terms of speed. There's no copying in that example
using `mclapply` and so it is significantly faster
Yes we are aware. We are looking into the issue and are trying to have it
resolve shortly.
Lori Shepherd
Bioconductor Core Team
Roswell Park Cancer Institute
Department of Biostatistics & Bioinformatics
Elm & Carlton Streets
Buffalo, New York 14263
From:
On Fri, 12 Apr 2019 at 21:32, Travers Ching wrote:
>
> Just throwing my two cents in:
>
> I think removing/deprecating fork would be a bad idea for two reasons:
>
> 1) There are no performant alternatives
"Performant"... in terms of what. If the cost of copying the data
predominates over the
Hi,
I assume you are already aware of it, but there's a problem with the builder
for the new packages. It works fine in Windows but Mac and Linux cannot access
CRAN
checking package dependencies ...Warning: unable to access index for repository
https://CRAN.R-project.org/src/contrib:
cannot
Just throwing my two cents in:
I think removing/deprecating fork would be a bad idea for two reasons:
1) There are no performant alternatives
2) Removing fork would break existing workflows
Even if replaced with something using the same interface (e.g., a
function that automatically detects
Okay, thank you very much!
On Fri, 12 Apr 2019 at 12:25, Shepherd, Lori
wrote:
> That is not correct. The webhook was only for the package submission
> process.
>
> See the link provided on linking to Bioconductor.
>
> Other helpful github links can be found here:
>
That is not correct. The webhook was only for the package submission process.
See the link provided on linking to Bioconductor.
Other helpful github links can be found here:
http://bioconductor.org/developers/how-to/git/
Lori Shepherd
Bioconductor Core Team
Roswell Park Cancer Institute
Thank you for the instructions!
Can I just clarify -- I was pushing changes to my Github repository that
has a webhook set up (as per instructions from when I first submitted the
package to Bioconductor). I thought that pushes to master branch with
version bump should trigger package builds. Am I
We are not seeing the changes pushed to the git.bioconductor server. I am
assuming you are referring to the RELEASE_3_8 branch since you are referencing
1.6.1.
Have set up the remote upstream to point to Bioconductor,
http://bioconductor.org/developers/how-to/git/sync-existing-repositories/
Hi,
Sorry, I think I must have done something wrong as the build report is not
showing the updates to my package from 2 days ago. Could you please help me
with this? I thought I updated the version of BUMHMM correctly (from 1.6.1
to 1.6.2 and 1.6.3) but it is not been picked up?
Thanks,
Alina
On Thu, 11 Apr 2019 at 22:07, Henrik Bengtsson
wrote:
>
> ISSUE:
> Using *forks* for parallel processing in R is not always safe.
> [...]
> Comments?
Using fork() is never safe. The reference provided by Kevin [1] is
pretty compelling (I kindly encourage anyone who ever forked a process
to read
Your configure outsmarts the check system, so your options are to omit the
flags or to live with the warning. Either solution is fine with Bioconductor.
Martin
On 4/12/19, 4:17 AM, "Bioc-devel on behalf of Jochen Knaus"
wrote:
Hi everybody,
for our new R package "Netboost" we
I have just added this package. The mirror had some hiccups a couple
of weeks ago when we had to switch to synchronize from a cran mirror
instead of the main CRAN site.
Turns out mirrors often have slightly inconsistent data/metadata, not
very surprisingly, and this threw off the mirroring script.
Hi everybody,
for our new R package "Netboost" we have a problem about non portable
compiler flags. Basically we support AVX in our own C++ code (using
compiler intrinsics to use the AVX units). Of course we have a non-AVX
code path.
For building we use autotools and configure to determine at
Hi Martin and Herve,
thanks for the quick responses and the clarification.
It's not an issue now that I know this happens, and can just load DelayedArray
outside of the function.
Best,
Steffi
> On April 12, 2019 at 1:10 AM Martin Morgan wrote:
>
>
> That easy strategy wouldn't work, for
17 matches
Mail list logo
