Re: [Bioc-devel] helper function arguments: best practice

[Manders-2, F.M.]

Hi Severin,

I understand that the helper_function is not defined in the main function.
The anonymous function inside the lapply call however is, which means it can 
use the (list of) variables in the main function.
You still need to pass the list of arguments to the helper_function, but not 
also to the anonymous function.

Best,
Freek

On 19/04/2021, 12:24, "Severin Bang"  
wrote:

Hi Freek,

the helper_function() is not defined in the main function, but only 
called there. I decided to pass a named list of parameters, from which 
each helper function grabs those it needs. I also thought about defining 
the function in the main function, but decided that this neither helps 
the readability nor is particularly useful (I could just do what the 
helper function does in the main function directly...).

It would rather have the ability to define for the lapply (or the helper 
function itself) that the locale environment of the main function should 
be used, but this is at least a workable solution.

But many thanks for your suggestion nonetheless :)

Best
Severin

On 19.04.21 11:14, Manders-2, F.M. wrote:
> Hi Severin,
>
> I'm not sure what the best practice is, but since your anonymous function 
is defined inside your main function, you don't need to supply it with all 
those arguments.
> This should also work, because R has lexical scoping:
>
> main_function <- function(alot, of, paramters) {
>var01 <- foo
>...
>varXX <- bar
>data_list <- list(data01, data02, data03, ... , dataYY)
>
>lapply(
>  seq_along(data_list),
>  function(i) {
>stuff
>helper_function(var01, ... , varXX)
>  }
> }
>
> This is already a bit shorter.
>
> I hope this helps,
> Freek
>
> On 16/04/2021, 13:45, "Bioc-devel on behalf of Severin Bang" 
 wrote:
>
>  Dear community,
>
>  I am writing my first package with the aim to publish it on
>  Bioconductor. To structure the code and make it  (human) readable I 
have
>  defined some helper functions, that will not be exported.
>
>  The main function (which will be user available) makes some data
>  structuring, defines some variables and will then call a helper 
function
>  in a lapply-call on a list of data.frames.
>
>  Now I find myself passing >>10 arguments (basically everything that 
was
>  defined in the main function before the lapply call) to the helper
>  function when executed by lapply. All arguments (except the index of 
the
>  current data.frame from the list which is lapplyd over) are static 
for
>  all the runs.
>
>  My question is now: What is considered best practice in this case?
>  should I put all parameters in a list? Is there a way to pass the 
whole
>  "parent" environment (the locale of the main function) to lapply, or
>  should I keep all the single parameters?
>
>  Maybe a "pseudo code" example is useful; this is how my problem is
>  structured:
>
>  main_function <- function(alot, of, paramters) {
> var01 <- foo
> ...
> varXX <- bar
> data_list <- list(data01, data02, data03, ... , dataYY)
>
> lapply(
>   seq_along(data_list),
>   function(
> i,
> var01,
> ...
> varXX
>   ) {
> stuff
> helper_function(var01, ... , varXX)
>   },
>   var01 = var01,
>   ...
>   varXX = varXX
> )
>  }
>
>
>  Thank you very much!
>
>  Best,
>  Severin
>
>  ___
>  Bioc-devel@r-project.org mailing list
>  https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] helper function arguments: best practice

[Manders-2, F.M.]

Hi Severin,

I'm not sure what the best practice is, but since your anonymous function is 
defined inside your main function, you don't need to supply it with all those 
arguments.
This should also work, because R has lexical scoping:

main_function <- function(alot, of, paramters) {
  var01 <- foo
  ...
  varXX <- bar
  data_list <- list(data01, data02, data03, ... , dataYY)

  lapply(
seq_along(data_list),
function(i) {
  stuff
  helper_function(var01, ... , varXX)
}
}

This is already a bit shorter.

I hope this helps,
Freek

On 16/04/2021, 13:45, "Bioc-devel on behalf of Severin Bang" 
 wrote:

Dear community,

I am writing my first package with the aim to publish it on 
Bioconductor. To structure the code and make it  (human) readable I have 
defined some helper functions, that will not be exported.

The main function (which will be user available) makes some data 
structuring, defines some variables and will then call a helper function 
in a lapply-call on a list of data.frames.

Now I find myself passing >>10 arguments (basically everything that was 
defined in the main function before the lapply call) to the helper 
function when executed by lapply. All arguments (except the index of the 
current data.frame from the list which is lapplyd over) are static for 
all the runs.

My question is now: What is considered best practice in this case? 
should I put all parameters in a list? Is there a way to pass the whole 
"parent" environment (the locale of the main function) to lapply, or 
should I keep all the single parameters?

Maybe a "pseudo code" example is useful; this is how my problem is 
structured:

main_function <- function(alot, of, paramters) {
   var01 <- foo
   ...
   varXX <- bar
   data_list <- list(data01, data02, data03, ... , dataYY)

   lapply(
 seq_along(data_list),
 function(
   i,
   var01,
   ...
   varXX
 ) {
   stuff
   helper_function(var01, ... , varXX)
 },
 var01 = var01,
 ...
 varXX = varXX
   )
}


Thank you very much!

Best,
Severin

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Orchid ID invalid according to BiocCheck

[Manders-2, F.M.]

Yes, I’ll create a PR.

From: Vincent Carey 
Date: Monday, 19 October 2020 at 12:36
To: "Manders-2, F.M." , bioc-devel 

Subject: Fwd: [Bioc-devel] Orchid ID invalid according to BiocCheck

forwarding to bioc-devel
-- Forwarded message -
From: Vincent Carey 
mailto:st...@channing.harvard.edu>>
Date: Mon, Oct 19, 2020 at 6:33 AM
Subject: Re: [Bioc-devel] Orchid ID invalid according to BiocCheck
To: Manders-2, F.M. 
mailto:f.m.mand...@prinsesmaximacentrum.nl>>
Cc: Alessandro Lussana via Bioc-devel 
mailto:Bioc-devel@r-project.org>>

looks like BiocCheck/checks.R:validID <- 
grepl("[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}", orcid)

has to change -- do you have time to determine the correct regex for this and 
file a PR?



On Mon, Oct 19, 2020 at 6:31 AM Manders-2, F.M. 
mailto:f.m.mand...@prinsesmaximacentrum.nl>>
 wrote:
Yes, the X is correct (https://orcid.org/-0001-6197-347X). I don’t know why 
I have an X there and not a number.

From: Vincent Carey 
mailto:st...@channing.harvard.edu>>
Date: Monday, 19 October 2020 at 12:20
To: "Manders-2, F.M." 
mailto:f.m.mand...@prinsesmaximacentrum.nl>>
Cc: Alessandro Lussana via Bioc-devel 
mailto:Bioc-devel@r-project.org>>
Subject: Re: [Bioc-devel] Orchid ID invalid according to BiocCheck

 person("Freek", "Manders", email = 
"f.m.mand...@prinsesmaximacentrum.nl<mailto:f.m.mand...@prinsesmaximacentrum.nl>",
 role = c("aut"),
comment = c(ORCID = "-0001-6197-347X")),

is what I see in a current checkout.  is "X" at the end correct?  maybe there 
is an encoding issue?

On Mon, Oct 19, 2020 at 6:14 AM Manders-2, F.M. 
mailto:f.m.mand...@prinsesmaximacentrum.nl>>
 wrote:
Hi all,

BiocCheck is giving me a note that my ORCID ID is invalid ("Invalid ORCID ID 
for Freek Manders").
However, I see nothing wrong with the ID. It also seems to work well on the dev 
page of my package (MutationalPatterns)
Clicking on the green ID circle, sends me to my page just fine.
Is there a mistake in BiocCheck? Should I just ignore this?

With kind regards,
Freek Manders

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Orchid ID invalid according to BiocCheck

[Manders-2, F.M.]

It seems to be a valid ID: 
https://support.orcid.org/hc/en-us/articles/360053289173-Why-does-my-ORCID-iD-have-an-X-
Maybe BiocCheck doesn’t realize the ID can end with an X?

From: Vincent Carey 
Date: Monday, 19 October 2020 at 12:20
To: "Manders-2, F.M." 
Cc: Alessandro Lussana via Bioc-devel 
Subject: Re: [Bioc-devel] Orchid ID invalid according to BiocCheck

 person("Freek", "Manders", email = 
"f.m.mand...@prinsesmaximacentrum.nl<mailto:f.m.mand...@prinsesmaximacentrum.nl>",
 role = c("aut"),
comment = c(ORCID = "-0001-6197-347X")),

is what I see in a current checkout.  is "X" at the end correct?  maybe there 
is an encoding issue?

On Mon, Oct 19, 2020 at 6:14 AM Manders-2, F.M. 
mailto:f.m.mand...@prinsesmaximacentrum.nl>>
 wrote:
Hi all,

BiocCheck is giving me a note that my ORCID ID is invalid ("Invalid ORCID ID 
for Freek Manders").
However, I see nothing wrong with the ID. It also seems to work well on the dev 
page of my package (MutationalPatterns)
Clicking on the green ID circle, sends me to my page just fine.
Is there a mistake in BiocCheck? Should I just ignore this?

With kind regards,
Freek Manders

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Orchid ID invalid according to BiocCheck

[Manders-2, F.M.]

Yes, the X is correct (https://orcid.org/-0001-6197-347X). I don’t know why 
I have an X there and not a number.

From: Vincent Carey 
Date: Monday, 19 October 2020 at 12:20
To: "Manders-2, F.M." 
Cc: Alessandro Lussana via Bioc-devel 
Subject: Re: [Bioc-devel] Orchid ID invalid according to BiocCheck

 person("Freek", "Manders", email = 
"f.m.mand...@prinsesmaximacentrum.nl<mailto:f.m.mand...@prinsesmaximacentrum.nl>",
 role = c("aut"),
comment = c(ORCID = "-0001-6197-347X")),

is what I see in a current checkout.  is "X" at the end correct?  maybe there 
is an encoding issue?

On Mon, Oct 19, 2020 at 6:14 AM Manders-2, F.M. 
mailto:f.m.mand...@prinsesmaximacentrum.nl>>
 wrote:
Hi all,

BiocCheck is giving me a note that my ORCID ID is invalid ("Invalid ORCID ID 
for Freek Manders").
However, I see nothing wrong with the ID. It also seems to work well on the dev 
page of my package (MutationalPatterns)
Clicking on the green ID circle, sends me to my page just fine.
Is there a mistake in BiocCheck? Should I just ignore this?

With kind regards,
Freek Manders

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Orchid ID invalid according to BiocCheck

[Manders-2, F.M.]

Hi all,

BiocCheck is giving me a note that my ORCID ID is invalid ("Invalid ORCID ID 
for Freek Manders").
However, I see nothing wrong with the ID. It also seems to work well on the dev 
page of my package (MutationalPatterns)
Clicking on the green ID circle, sends me to my page just fine.
Is there a mistake in BiocCheck? Should I just ignore this?

With kind regards,
Freek Manders

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Vignette examples

[Manders-2, F.M.]

Hi Emilie,

There are two possible problems I could think of.
Did you remember to load your package in the vignette?
Are your functions exported in the NAMESPACE of your package?

With kind regards,
Freek Manders

On 10/09/2020, 16:38, "Bioc-devel on behalf of Emilie Secherre" 
 wrote:

Hello,



I'm currently making a bioconductor package. When i'm running R CMD check,
all the examples i used in function vignettes have one issue : could not
find function "mypckgfunction". Is there a way to fix this issue ? The
examples work perfectly when i'm using them in a R script, and are used in
unit tests without any warning, it's just about examples in vignettes...



Thank you in advance for your answer,

Emilie Secherre

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Bioconductor Package Submission - Removing git pack objects

[Manders-2, F.M.]

Hi Joseph,

When you run 'R CMD build' you should get a release tarball, which shouldn't 
contain this .git folder. If you perform the 'R CMD check' on the tarball, you 
shouldn't get this warning. If you still get the warning, or have other files 
that generate this warning, then you could try to add them to a '.Rbuildignore' 
file.

I hope this helps,
Freek Manders

On 14/08/2020, 13:26, "Bioc-devel on behalf of Joseph Lee Jing Xian" 
 wrote:

To whom it may concern:

I am Joseph, writing on behalf of the developers of 
proActiv, a package used to infer 
promoter activity from RNA-seq data.
We are in the process of preparing the package for Biconductor submission. 
So far, the package has cleared R CMD check with no errors or warnings, and 
cleared R CMD BiocCheck with no errors. However, we're still getting one 
warning from R CMD BiocCheck regarding individual file size. In particular, we 
have a couple of offending files (.bed, .rda), one of them being a git pack 
object (.pack).
We have followed the suggested pipeline to remove large files with BFG 
Repo-cleaner:

> git clone --mirror https://github.com/GoekeLab/proActiv.git


> java -jar bfg-1.13.0.jar --strip-blobs-bigger-than 5M 
--no-blob-protection proActiv.git

> cd proActiv.git

> git reflog expire --expire=now --all && git gc --prune=now --aggressive

This removes the individual files (e.g. .bed, .rda) in commit history that 
were bigger than the stipulated 5M limit, as expected.
However, cloning the package locally from the bare repository and running R 
CMD BiocCheck on it still throws the same warning, but with the git pack object 
as the only offending file.
How should one go about dealing with hidden git pack objects so that the 
Bioconductor checks can be passed successfully?

Thanks,
Joseph

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Author/maintainer field no longer accepted.

[Manders-2, F.M.]

Hi All,

R BiocCheck no longer seems to accept a Author/Maintainer field. 
(https://github.com/Bioconductor/BiocCheck/commit/e0176f6591c771774f6cb05d4ff8bc1b145ad10e)

* Checking for valid maintainer...
* ERROR: Remove Maintainer field. Use Authors@R [cre] designation.

However, the package guidelines 
(https://www.bioconductor.org/developers/package-guidelines/) still say that a 
Author/Maintainer field is allowed:
Authors@R or Author/Maintainer:” fields: Use either Authors@R field or Author: 
and Maintainer: fields, not both.

I think the guidelines need to be updated.

With kind regards,
Freek Manders


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] VariantAnnotation::readVcf() sets the wrong seqlevelsStyle in devel

[Manders-2, F.M.]

Hi Herve,

The performance of seqlevelStyle when the genome of a GRanges object has been 
set, still seems strange to me.
Here is some example code I ran in the Bioconductor:devel docker:
gr <- GRanges(rep(c("chr2", "chr3", "chrM"), 2), IRanges(1:6, 10))
genome(gr) <- "hg19"
seqlevelsStyle(gr) <- "NCBI"

This results in R freezing for more than a minute, after which the following 
cryptic error is given: 
Error in function (type, msg, asError = TRUE)  :
  Failed to connect to ftp.ncbi.nlm.nih.gov port 21: Connection refused

Maybe seqlevelsStyle should check if the genome of a GRanges object has been 
set and throw an informative error?

With kind regards,
Freek Manders

On 06/08/2020, 19:18, "Bioc-devel on behalf of Hervé Pagès" 
 wrote:

Hi Robert,

Yes seqlevelsStyle's new behavior is slightly different and less 
forgiving. The thing is that it will generally reveal dormant issues 
which is not such a bad thing after all.

Note that it doesn't seem completely straightforward to retrieve the 
reference genome/assembly directly from the VCF header. AFAICT this 
information is either missing or weirdly formatted. For example the 
headers of the 1000genomes VCF files located at 

ftp://ftp-trace.ncbi.nih.gov/1000genomes/ftp/release/20101123/interim_phase1_release/
 
contain

   ##reference=1000Genomes-NCBI37

or in the ex2.vcf file included in VariantAnnotation it's:

   ##reference=file:///seq/references/1000GenomesPilot-NCBI36.fasta

so not clear that importing this in the genome field of the returned VCF 
object would be that helpful.

Thanks for pointing me to the VariantAnnotation vignette. I'll fix the 
calls to readVcf() to use GRCh37 instead of hg19. Seems like one call 
(on ex2.vcf) is using the wrong genome: ex2.vcf is based on hg18/NCBI36, 
not on hg19/GRCh37. Will fix that too.

Sure readVcf() could probably be improved to perform some sanity checks 
by making sure that the user-supplied genome is compatible with the 
chromosome names. However that still won't prevent the user from 
specifying the wrong genome (e.g. GRCh37 instead of NCBI36) like in the 
ex2.vcf case. Anyway this is a feature request for readVcf().

In the end I'm not sure what's the purpose of specifying the genome 
anyway. What does it give us? Maybe the vignette and examples in 
VariantAnnotation should stop doing that? Better to not specify the 
genome than specifying the wrong one.

Best,
H.

On 8/6/20 07:42, Robert Castelo wrote:
> hi Hervé,
> 
> thank you very much for your clarifications, but this behavior is 
> different in release and has been different until now, this is BioC 3.11:
> 
> library(VariantAnnotation)
> 
> fl <- system.file("extdata", "chr22.vcf.gz", package="VariantAnnotation")
> vcf <- readVcf(fl, "hg19")
> seqlevels(vcf)
> [1] "22"
> seqlevelsStyle(vcf)
> [1] "NCBI""Ensembl"
> 
> i appreciate that the behavior now in devel is more consistent, i 
> actually never understood the need to specify the 'genome="hg19"' 
> argument since this in principle can be figured out from the VCF header 
> information. However, the documentation has become right now confusing, 
> if you go to subsection 2.1 and 2.1.2 from the introductory vignette, it 
> shows using readVcf() with "hg19" but then the sequence names are 
> literally what they are in the VCF file (NCBI style)
> 
> because of the large user base of VariantAnnotation (top-49 download) 
> and the many possible reverse dependencies downstream, i'd suggest that 
> either readVcf() issues an error or, maybe even better, overrides the 
> sequence level style in the VCF file maybe with a warning, when the 
> 'genome' argument does not match the sequence style of the VCF file.
> 
> cheers,
> 
> robert.
> 
> 
> On 04/08/2020 18:29, Hervé Pagès wrote:
>> Hi Robert,
>>
>> The VCF file uses "22" for the chromosome name which is the name used 
>> by NCBI. So explicitly specifying "hg19" in the readVcf() call is like 
>> saying that this chromosome name is a UCSC name which is why 
>> seqlevelsStyle() gets confused later.
>>
>> If you specify the name of the NCBI assembly, things work as expected:
>>
>>   fl <- system.file("extdata", "chr22.vcf.gz", 
>> package="VariantAnnotation")
>>   vcf <- readVcf(fl, "GRCh37")
>>   seqlevels(vcf)
>>   # [1] "22"
>>   seqlevelsStyle(vcf)
>>   # [1] "NCBI"
>>   seqlevelsStyle(vcf) <- "UCSC"
>>   seqlevels(vcf)
>>   # [1] "chr22"
>>
>> Or, if you don't know what reference genome the file is based on, 
>> don't specify it:
>>
>>   fl <- system.file("extdata", "chr22.vcf.gz", 
>> package="VariantAnnotation")
>>   vcf <- readVcf(fl)
>>   seqlevels(vcf)
>>   # [1] "22"

[Bioc-devel] ccfindR install fails

[Manders-2, F.M.]

Hi all,

I’m trying to install the devel version of the ccfindR package to test my 
package (MutationalPatterns).
It passed the nightly build tests, so I thought it should work.
I used the development docker container to try and install the package, but it 
fails because its dependency “Rmpi” fails to install. I pasted the errors  I 
got below.
I found some information on how to install this dependency, but can’t get it to 
work. (http://fisher.stats.uwo.ca/faculty/yu/Rmpi/install.htm)
I tried to install open-mpi, but this is apparently already installed in the 
docker. However, I couldn’t find its path. I found several files starting with 
mpi in /usr/bin/ , but I have no idea if these are the correct ones.

Does anybody know what you need to do to install the ccfindR package?

The issue can be reproduced by running (requires docker):
docker pull bioconductor/bioconductor_docker:devel
docker run -it --user rstudio bioconductor/bioconductor_docker:devel R
BiocManager::install("ccfindR")

With kind regards,
Freek Manders


Errors:
** testing if installed package can be loaded from temporary location
Bioconductor version 3.12 (BiocManager 1.30.10), ?BiocManager::install for help
--
The value of the MCA parameter "plm_rsh_agent" was set to a path
that could not be found:

  plm_rsh_agent: ssh : rsh

Please either unset the parameter, or check that the path is correct
--
[abf30c1267ab:00745] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a 
daemon on the local node in file ess_singleton_module.c at line 582
[abf30c1267ab:00745] [[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a 
daemon on the local node in file ess_singleton_module.c at line 166
--
It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  orte_ess_init failed
  --> Returned value Unable to start a daemon on the local node (-127) instead 
of ORTE_SUCCESS
--
--
It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems.  This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):

  ompi_mpi_init: ompi_rte_init failed
  --> Returned "Unable to start a daemon on the local node" (-127) instead of 
"Success" (0)
--
*** An error occurred in MPI_Init
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***and potentially your MPI job)
[abf30c1267ab:745] Local abort before MPI_INIT completed completed 
successfully, but am not able to aggregate error messages, and not able to 
guarantee that all other processes were killed!
ERROR: loading failed
* removing ‘/usr/local/lib/R/site-library/Rmpi’
Warning in install.packages :
  installation of package ‘Rmpi’ had non-zero exit status


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel