Re: [Bioc-devel] loading database package changes random number

[Martin Morgan]

That easy strategy wouldn't work, for instance two successive calls to 
MulticoreParam() would get the same port assigned, rather than the contract of 
a 'random' port in a specific range; the port can be assigned by the 
manager.port= argument if the user wants to avoid random assignment. I could 
maintain a separate random number stream in BiocParallel for what amounts to a 
pretty trivial and probably dubious strategy [choosing random ports in hopes 
that one is not in use], but that starts to sound like a more substantial 
feature.

Martin

On 4/11/19, 7:06 PM, "Pages, Herve"  wrote:

Hi Steffi,

Any code that gets called between your calls to set.seed() and runif() 
could potentially use the random number generator. So the sequence 
set.seed(123); runif(1) is only guaranteed to be deterministic if no 
other code is called in between, or if the code called in between does 
not use the random number generator (but if that code is not under your 
control it could do anything).

@Martin: I'll look at your suggestion for DelayedArray. An easy 
workaround would be to avoid changing the RNG state in BiocParallel by 
having .snowPort() make a copy of .Random.seed (if it exists) before 
calling runif() and restoring it on exit.

H.

On 4/11/19 15:25, Martin Morgan wrote:
> This is actually from a dependency DelayedArray which, on load, calls 
DelayedArray::setAutoBPPARAM, which calls BiocParallel::MulticoreParam(), which 
uses the random number generator to select a random port for connection.
>
> A different approach would be for DelayedArray to respect the user's 
configuration and use bpparam(), or perhaps look at the class of bpparam() and 
tell the user they should, e.g., BiocParallel::register(SerialParam()) if 
that's appropriate, or use registered("MulticoreParam") or 
registered("SerialParam") if available (they are by default) rather than 
creating an ad-hoc instance.
>
> Martin
>
> On 4/11/19, 10:17 AM, "Bioc-devel on behalf of Steffi Grote" 
 wrote:
>
>  Hi all,
>  I found out that example code for my package GOfuncR yields a 
different result the first time it's executed, despite setting a seed. All the 
following executions are identical.
>  It turned out that loading the database package 'Homo.sapiens' 
changed the random numbers:
>  
>  set.seed(123)
>  runif(1)
>  # [1] 0.2875775
>  
>  set.seed(123)
>  suppressWarnings(suppressMessages(require(Homo.sapiens)))
>  runif(1)
>  # [1] 0.7883051
>  
>  set.seed(123)
>  runif(1)
>  # [1] 0.2875775
>  
>  Is that known or expected behaviour?
>  Should I not load a package inside a function that later uses random 
numbers?
>  
>  Thanks in advance,
>  Steffi
>  
>  ___
>  Bioc-devel@r-project.org mailing list
>  
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=8XXamcpEeef966i7IGk_3aE9GMJodKAzXwWW4fL_hrI=KoHGLM0HbP4whRZLG4ol66_q1qkg9E0LjFHObDqgNuo=
>  

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319


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

Re: [Bioc-devel] loading database package changes random number

[Pages, Herve]

Hi Steffi,

Any code that gets called between your calls to set.seed() and runif() 
could potentially use the random number generator. So the sequence 
set.seed(123); runif(1) is only guaranteed to be deterministic if no 
other code is called in between, or if the code called in between does 
not use the random number generator (but if that code is not under your 
control it could do anything).

@Martin: I'll look at your suggestion for DelayedArray. An easy 
workaround would be to avoid changing the RNG state in BiocParallel by 
having .snowPort() make a copy of .Random.seed (if it exists) before 
calling runif() and restoring it on exit.

H.

On 4/11/19 15:25, Martin Morgan wrote:
> This is actually from a dependency DelayedArray which, on load, calls 
> DelayedArray::setAutoBPPARAM, which calls BiocParallel::MulticoreParam(), 
> which uses the random number generator to select a random port for connection.
>
> A different approach would be for DelayedArray to respect the user's 
> configuration and use bpparam(), or perhaps look at the class of bpparam() 
> and tell the user they should, e.g., BiocParallel::register(SerialParam()) if 
> that's appropriate, or use registered("MulticoreParam") or 
> registered("SerialParam") if available (they are by default) rather than 
> creating an ad-hoc instance.
>
> Martin
>
> On 4/11/19, 10:17 AM, "Bioc-devel on behalf of Steffi Grote" 
>  wrote:
>
>  Hi all,
>  I found out that example code for my package GOfuncR yields a different 
> result the first time it's executed, despite setting a seed. All the 
> following executions are identical.
>  It turned out that loading the database package 'Homo.sapiens' changed 
> the random numbers:
>  
>  set.seed(123)
>  runif(1)
>  # [1] 0.2875775
>  
>  set.seed(123)
>  suppressWarnings(suppressMessages(require(Homo.sapiens)))
>  runif(1)
>  # [1] 0.7883051
>  
>  set.seed(123)
>  runif(1)
>  # [1] 0.2875775
>  
>  Is that known or expected behaviour?
>  Should I not load a package inside a function that later uses random 
> numbers?
>  
>  Thanks in advance,
>  Steffi
>  
>  ___
>  Bioc-devel@r-project.org mailing list
>  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=8XXamcpEeef966i7IGk_3aE9GMJodKAzXwWW4fL_hrI=KoHGLM0HbP4whRZLG4ol66_q1qkg9E0LjFHObDqgNuo=
>  

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

Re: [Bioc-devel] memory exhausted on tokay2

[Aaron Taudt]

Dear Hervé,

thank you for your reply and the explanations. I have checked the R CMD
check on my system (MacOS Mojave) and the whole check does not exceed 1Gb
of RAM. I am also surprised why it would need that much, because all the
examples are pretty slim, so even if all objects are kept, I am wondering
why it needs that much RAM on Windows/Linux.
If you can give me some more hints I'd be glad.

Cheers,
Aaron



Am So., 7. Apr. 2019 um 00:03 Uhr schrieb Pages, Herve :

> Hi Aaron,
>
> Maybe the particular example (plotting) where the "memory exhausted"
> error occurs is not particularly memory-intensive. However keep in mind
> 2 important things:
>
>1) 'R CMD check' runs all the examples from all the man pages in the
> same R session. This means that memory used (and not released) by other
> examples will reduce the memory available for the example being
> currently run. So even though your plotting examples use less than 1 Gb
> of RAM, the 'top' command on my Linux laptop indicates that a full 'R
> CMD check' on the methimpute package uses about 6 Gb of RAM!
>
>2) We use the --force-multiarch option when running 'R CMD check' on
> the Windows build machines. This forces 'R CMD check' to run all the
> examples from all the man pages twice: once in 32-bit mode and once in
> 64-bit mode. Note that 32-bit Windows limits the amount of memory that a
> single process can use to about 3Gb. This would explain why the plotting
> examples fail only when run in 32-bit mode (i386 arch). All the examples
> run ok in 64-bit mode (x64 arch).
>
> The solution is to try to reduce the memory footprint of your examples
> in general, not just the plotting examples. Maybe there is an example
> somewhere that creates a big object. Note that because all the examples
> are run in the same session, this object will persist when other
> examples are run. Removing the object (with 'rm(object)') might help.
>
> The very last resort would be to mark the package as not supported on
> 32-bit Windows but hopefully we won't need to do that.
>
> Hope this helps,
>
> H.
>
> On 4/6/19 04:10, Aaron Taudt wrote:
> > Dear bioconductor-devel,
> >
> > I am trying to fix an "Error: memory exhausted (limit reached?)" error
> that
> > arises during Rcheck on tokay2 (Windows Server 2012 R2 Standard / x64) .
> > The package builds and passes Rcheck just fine on all other hosts. Is
> this
> > something I can fix? The function in question is not particularly
> > memory-intensive.
> >
> > Regards,
> > Aaron Taudt
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=i7VUGpP2oVdclQ-zgbh2Nfj5Q4KDtdvne_1mdlA6Sao=drLmF9Z_F3ETYHXRyi-kZsSZhCwDaphEEcsYMEEqvIY=
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] GWASTools error on tokay related to VariantAnnotation::readVcf

[Shepherd, Lori]

Please ignore this ERROR for now.  It is a known issue in VariantAnnotation and 
we are working on the patch.  You can ignore this for now.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Stephanie 
Gogarten 
Sent: Thursday, April 11, 2019 2:14:52 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] GWASTools error on tokay related to 
VariantAnnotation::readVcf

Hi,

I am puzzled by the current check failure of GWASTools on tokay (but not
any other platform). I have a unit test that writes a VCF file, which is
then read in using VariantAnnotation::readVcf. This is the header of the
VCF file:

##fileformat=VCFv4.1

##fileDate=2019-04-11

##source=GWASTools::vcfWrite()

##INFO=

##FORMAT=


Only on tokay, readVcf generates this error:


Error in validObject(.Object) :

  invalid class "VCFHeader" object: 'geno(VCFHeader)' must be a 3 column
DataFrame with names Number, Type, Description

Calls: readVcf ... VCFHeader -> new -> initialize -> initialize ->
validObject


I cannot reproduce this using R-devel and current versions of all
Bioc-devel packages (notably VariantAnnotation_1.29.25), though I don't
have a Windows machine to test on. I also don't understand why this error
would be platform dependent.


thanks,

Stephanie

[[alternative HTML version deleted]]

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


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

[Bioc-devel] GWASTools error on tokay related to VariantAnnotation::readVcf

[Stephanie Gogarten]

Hi,

I am puzzled by the current check failure of GWASTools on tokay (but not
any other platform). I have a unit test that writes a VCF file, which is
then read in using VariantAnnotation::readVcf. This is the header of the
VCF file:

##fileformat=VCFv4.1

##fileDate=2019-04-11

##source=GWASTools::vcfWrite()

##INFO=

##FORMAT=


Only on tokay, readVcf generates this error:


Error in validObject(.Object) :

  invalid class "VCFHeader" object: 'geno(VCFHeader)' must be a 3 column
DataFrame with names Number, Type, Description

Calls: readVcf ... VCFHeader -> new -> initialize -> initialize ->
validObject


I cannot reproduce this using R-devel and current versions of all
Bioc-devel packages (notably VariantAnnotation_1.29.25), though I don't
have a Windows machine to test on. I also don't understand why this error
would be platform dependent.


thanks,

Stephanie

[[alternative HTML version deleted]]

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

[Bioc-devel] deprecation guidelines

[Samuela Pollack]

Dear Bioconductor,

We are deprecating part of a package. I am following the guidelines in 
the "Function Deprecation Guidelines" page at bioconductor.org and I 
have a few questions:


(i) Deprecating a S4 method which has the same name in another S4 class. 
We have two DelayedArray backends. Functions like dim and dimnames are 
deprecated in one but not in the other. Should those functions be listed 
in the ThePkg-deprecated document? With the name of the backend that's 
being deprecated? With a note about the backend that is *not* being 
deprecated?


(ii) Deprecating a S4 class. Should this look just like a function in 
ThePkg-deprecated?


(iii) subscript, double-subscript, assign-to-property (property<-) 
operators. Should they be included in ThePkg-deprecated.Rd? In favor: 
they are being deprecated for the class they pertain to. Against: we 
certainly aren't deprecating the subscript operator in general.


thanks,

- Sam

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

[Bioc-devel] loading database package changes random number

[Steffi Grote]

Hi all,
I found out that example code for my package GOfuncR yields a different result 
the first time it's executed, despite setting a seed. All the following 
executions are identical.
It turned out that loading the database package 'Homo.sapiens' changed the 
random numbers:

set.seed(123)
runif(1)
# [1] 0.2875775

set.seed(123)
suppressWarnings(suppressMessages(require(Homo.sapiens)))
runif(1)
# [1] 0.7883051

set.seed(123)
runif(1)
# [1] 0.2875775

Is that known or expected behaviour?
Should I not load a package inside a function that later uses random numbers?

Thanks in advance,
Steffi

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

Re: [Bioc-devel] New package submission failing only in devel due to dependent package errors

[Daniel Cameron]

The package adds structural variant functionality on top of
VariantAnnotation. It's been pretty stable for the last 18 months and
getting more users so I thought it was time to bit the bullet and get it
into BioConductor. install_github() isn't the ideal distribution mechanism
for a package with so many BioConductor dependencies.

https://github.com/Bioconductor/Contributions/issues/1079
http://bioconductor.org/spb_reports/StructuralVariantAnnotation_buildreport_20190411011937.html


No errors in the linux/mac builds although I did just add a warning from a
commit addressing review feedback.

On Wed, Apr 10, 2019 at 12:00 AM Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> We are aware of the issue in VariantAnnotation and hopefully will have a
> fix soon.  We have been seeing this ERROR on tokay2 (windows)  but not on
> the other two platforms.  Is this the case for your package?  What is the
> name/package issue number of the submitted package?If so,  we would
> accept your package conditionally since the ERROR is not with your package
> directly as long as it is building on the other two platforms without
> ERROR.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Bioc-devel  on behalf of Daniel
> Cameron 
> *Sent:* Tuesday, April 9, 2019 7:21:54 AM
> *To:* bioc-devel@r-project.org
> *Subject:* [Bioc-devel] New package submission failing only in devel due
> to dependent package errors
>
> Hello,
>
> I am attempting to submit a new package, and everything builds correctly
> against R 3.5 and release bioconductor, but the package build is failing in
> devel due to a dependent package. The build error is:
>
> Quitting from lines 52-56 (vignettes.Rmd)
> Error: processing vignette 'vignettes.Rmd' failed with diagnostics:
> invalid class "VCFHeader" object: 'info(VCFHeader)' must be a 3 column
> DataFrame with names Number, Type, Description
> --- failed re-building 'vignettes.Rmd'
>
> Which I can reproduce locally when building against devel but I'm not sure
> what do you as the offending line is:
> vcf <- VariantAnnotation::readVcf(vcf.file, "hg19")The VCF itself is valid
> (in that it complies with the VCF specifications), and has been parsing
> just fine in my unit tests since May 2016, it's just failing in devel.
>
> Presumably this is a blocker for package acceptance but I'm not sure
> exactly how to proceed given the change is not in my package. Should I be
> raising an issue against VariantAnnotation and hoping it gets resolved fast
> enough for my package to go in this round, or should I also be doing
> something else?
>
> Thanks
> Daniel
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.

[[alternative HTML version deleted]]

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