Re: [Bioc-devel] build errors: "Error in .seqlengths_TwoBitFile(x) : UCSC library operation failed"

[Pages, Herve]

Hi Paul,

Is there a possibility that trena's code is having one worker 
downloading/re-installing BSgenome.Hsapiens.UCSC.hg38 while at the same 
time another worker is trying to access it?

The reason I suspect something like this is that it seems that 
BSgenome.Hsapiens.UCSC.hg38 gets reinstalled every night on the builders 
and that this happens at the time the build system is running 'R CMD 
check' on trena.

Package vignettes, examples, and unit tests should avoid re-installing 
packages.

H.

On 4/22/19 15:01, Paul Shannon wrote:
> I cannot reproduce daily build failures found in the trena package by the 
> build system.  The build report shows:
>
> trena RUnit Tests - 86 test functions, 7 errors, 0 failures
>
> ERROR in test_.injectSnp: Error in .seqlengths_TwoBitFile(x) : UCSC library 
> operation failed
> ERROR in test_bugInStartEndOfMinusStrandHits: Error in 
> .seqlengths_TwoBitFile(x) : UCSC library operation failed
> ERROR in test_findMatchesByChromosomalRegion: Error in 
> .seqlengths_TwoBitFile(x) : UCSC library operation failed
> ERROR in test_findMatchesByChromosomalRegion.twoAlternateAlleles: Error in 
> .seqlengths_TwoBitFile(x) : UCSC library operation failed
> ERROR in test_findMatchesByMultipleChromosomalRegions: Error in 
> .seqlengths_TwoBitFile(x) : UCSC library operation failed
> ERROR in test_getSequence: Error in .seqlengths_TwoBitFile(x) : UCSC library 
> operation failed
> ERROR in test_noMatch: Error in .seqlengths_TwoBitFile(x) : UCSC library 
> operation failed
>
> This seems similar to a bioc support exchange from two years ago, which may 
> suggest that the build system's BSgenome.Hsapiens.UCSC.hg38 is the locus of 
> the problem.   I offer suggestion very tentatively.
>
> support 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_95963_=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=1AJWecG5cm0EI_BZG7zYbHNZa3JkQY8pdsJFahrtpIU=2WHZQbOLmt-jvKlwVBty43jY5JcBt2U_sdqZDqRxEOY=
>
> Any suggestions?
>
>   - Paul
>
> sessionInfo()  # from my clean R CMD check
> R version 3.6.0 beta (2019-04-11 r76379)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 16.04.5 LTS
>
> Matrix products: default
> BLAS:   /local/users/pshannon/src/R-beta/lib/libRblas.so
> LAPACK: /local/users/pshannon/src/R-beta/lib/libRlapack.so
>
> locale:
>   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>   [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>   [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>   [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats4parallel  stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages:
>   [1] RPostgreSQL_0.6-2   DBI_1.0.0   RUnit_0.4.32
>   [4] trena_1.5.14MotifDb_1.22.0  Biostrings_2.48.0
>   [7] XVector_0.20.0  IRanges_2.14.12 S4Vectors_0.18.3
> [10] BiocGenerics_0.26.0 glmnet_2.0-16   foreach_1.4.4
> [13] Matrix_1.2-17
>
> loaded via a namespace (and not attached):
>   [1] SummarizedExperiment_1.10.1   lassopv_0.2.0
>   [3] progress_1.2.0lattice_0.20-38
>   [5] rtracklayer_1.40.6blob_1.1.1
>   [7] XML_3.98-1.19 rlang_0.3.4
>   [9] flare_1.6.0   BiocParallel_1.14.2
> [11] bit64_0.9-7   splitstackshape_1.4.8
> [13] matrixStats_0.54.0GenomeInfoDbData_1.1.0
> [15] stringr_1.4.0 zlibbioc_1.26.0
> [17] codetools_0.2-16  memoise_1.1.0
> [19] Biobase_2.40.0biomaRt_2.36.1
> [21] GenomeInfoDb_1.16.0   curl_3.3
> [23] AnnotationDbi_1.42.1  lars_1.2
> [25] Rcpp_1.0.1BSgenome_1.48.0
> [27] DelayedArray_0.6.6org.Hs.eg.db_3.6.0
> [29] bit_1.1-14Rsamtools_1.32.3
> [31] BSgenome.Hsapiens.UCSC.hg38_1.4.1 RMySQL_0.10.17
> [33] hms_0.4.2 digest_0.6.18
> [35] stringi_1.4.3 GenomicRanges_1.32.7
> [37] grid_3.6.0tools_3.6.0
> [39] bitops_1.0-6  magrittr_1.5
> [41] RCurl_1.95-4.12   RSQLite_2.1.1
> [43] randomForest_4.6-14   crayon_1.3.4
> [45] vbsr_0.0.5pkgconfig_2.0.2
> [47] MASS_7.3-51.4 data.table_1.12.2
> [49] prettyunits_1.0.2 httr_1.4.0
> [51] assertthat_0.2.1  iterators_1.0.10
> [53] R6_2.4.0  GenomicAlignments_1.16.0
> [55] igraph_1.2.4.1compiler_3.6.0
> ___
> Bioc-devel@r-project.org mailing list
> 

Re: [Bioc-devel] Release push DENIED by fallthru (REMP)

[Pages, Herve]

Hi Yinan,

The RELEASE_3_8 branch was frozen 8 days ago. This was announced on this 
list:

https://stat.ethz.ch/pipermail/bioc-devel/2019-April/014931.html

Best,

H.

On 4/23/19 13:53, Yinan Zheng wrote:
> Hi Bioc Devel Team,
>
> I fixed some bugs in my package REMP but failed to push the changes to the 
> release version (works fine to push to devel version and github). Would you 
> please advise how should I fix it? (I have been following the same git code 
> provided on the website previously and this issue happened recently.
>
> $ git push upstream RELEASE_3_8
> Enter passphrase for key '/c/Users/yzk256/.ssh/id_rsa':
> Counting objects: 67, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (66/66), done.
> Writing objects: 100% (67/67), 23.78 KiB | 0 bytes/s, done.
> Total 67 (delta 57), reused 0 (delta 0)
> remote: FATAL: W refs/heads/RELEASE_3_8 packages/REMP y.zheng DENIED by 
> fallthru
> remote: error: hook declined to update refs/heads/RELEASE_3_8
> To git.bioconductor.org:packages/REMP.git
> ! [remote rejected] RELEASE_3_8 -> RELEASE_3_8 (hook declined)
> error: failed to push some refs to 
> 'g...@git.bioconductor.org:packages/REMP.git'
>
> Thank you!
>
> Best,
> Yinan
>
>
>   [[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=6FgTZqHEHfvp03oJeoqLZO9zlSHUJgiQwYbnFSxp4Lg=58sbZABnT5GRk744289YlYQnuMCV9BG7u3SbaJajimo=

-- 
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

[Bioc-devel] Release push DENIED by fallthru (REMP)

[Yinan Zheng]

Hi Bioc Devel Team,

I fixed some bugs in my package REMP but failed to push the changes to the 
release version (works fine to push to devel version and github). Would you 
please advise how should I fix it? (I have been following the same git code 
provided on the website previously and this issue happened recently.

$ git push upstream RELEASE_3_8
Enter passphrase for key '/c/Users/yzk256/.ssh/id_rsa':
Counting objects: 67, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (66/66), done.
Writing objects: 100% (67/67), 23.78 KiB | 0 bytes/s, done.
Total 67 (delta 57), reused 0 (delta 0)
remote: FATAL: W refs/heads/RELEASE_3_8 packages/REMP y.zheng DENIED by fallthru
remote: error: hook declined to update refs/heads/RELEASE_3_8
To git.bioconductor.org:packages/REMP.git
! [remote rejected] RELEASE_3_8 -> RELEASE_3_8 (hook declined)
error: failed to push some refs to 'g...@git.bioconductor.org:packages/REMP.git'

Thank you!

Best,
Yinan


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] memory exhausted on tokay2

[Pages, Herve]

Glad you found the culprit.

Actually, the use of data.table::fwrite() seems to cause a memory leak. More 
precisely, if I repeatedly run the full exportMethylome example in a terminal, 
the memory usage (reported by 'top' in another terminal) grows at a rate of 0.8 
Gb per run. I observed this on the 2 systems where I tried it: one running 
Ubuntu 16.04 LTS and the other one running MacOS El Capitan.

Note that this problem disappears if I modify exportMethylome() to call good 
ol' write.table() instead of data.table::fwrite(). Yes it's slower, but it 
seems safer.

Cheers,

H.


On 4/23/19 12:18, Aaron Taudt wrote:
Dear Hervé,

thank you (and Martin) for the advice. I was able to locate the culprit: it was 
a data.table::fwrite( ) statement, the behaviour of which must have changed 
since the last release. I put this example in a NOT RUN block.

Kind regards,
Aaron




Am Mi., 17. Apr. 2019 um 12:41 Uhr schrieb Martin Morgan 
mailto:mtmorgan.b...@gmail.com>>:
maybe as an aid to debugging this, after running R CMD check on 
_1.5.1.tar.gz one can run just the examples with

  R -f pkg.Rcheck/pkg-Ex.R

or interactively with something like

  R
  > source("pkg.Rcheck/pkg-Ex.R", echo = TRUE, max = Inf)

Martin

On 4/17/19, 5:31 AM, "Bioc-devel on behalf of Pages, Herve" 
mailto:bioc-devel-boun...@r-project.org> on 
behalf of hpa...@fredhutch.org> wrote:

Hi Aaron,

I used 'top' on merida1 (one of our 2 Mac builders, MacOS El Capitan) to 
monitor memory usage of 'R CMD check methimpute_1.5.1.tar.gz' and also observed 
a pick at more than 6Gb there, like on my Linux laptop (Ubuntu 16.04 LTS). Note 
that memory usage stays relatively low (< 1Gb) for most of the time 'R CMD 
check' is running but starts to increase significantly when it reaches the 
"checking examples" step, with the pick happening at the very end of that step 
but for a very short time (about 2 sec.). On Linux I hit the space bar every 
sec in the terminal where I run 'top' to force it to refresh the displayed 
stats with enough frequency, otherwise I would probably miss the pick. On 
merida1 I don't have to do anything because the 'top' command there 
automatically refreshes the displayed stats at very short intervals.

H.

On 4/11/19 11:53, Aaron Taudt wrote:
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 
mailto:hpa...@fredhutch.org>>>:
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 

[Bioc-devel] Windows vignette build error "execution failed with error code 4"

[Taner Arslan]

Dear all,

My package is almost ready to be accepted but now i am getting weird building 
error on Windows. It works without error on Linux and OS X. I have tried many 
many things. But I could not figured out.

The  error is:

Invalid Parameter - /figure-html
Warning in shell(paste(c(cmd, args), collapse = " ")) :
  'convert "SubCellBarCode_files/figure-html/coverageMarkers-1.png" -trim 
"SubCellBarCode_files/figure-html/coverageMarkers-1.png"' execution failed with 
error code 4

You can see more here:
http://bioconductor.org/spb_reports/SubCellBarCode_buildreport_20190423143932.html

 I used to get this error before as well. After getting this error, when i 
resubmitted the package, the problem solved (I literally was not doing 
anything). Today i tried many times, still i get the problems. Did you ever 
encounter with this problem?

I have mac;
R version 3.5.2 (2018-12-20) ## Platform: x86_64-apple-darwin15.6.0 (64-bit) ## 
Running under: macOS Sierra 10.12.6

Thanks in advance.



När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI 
kommer att behandla dina personuppgifter. Här finns information om hur KI 
behandlar personuppgifter.


Sending email to Karolinska Institutet (KI) will result in KI processing your 
personal data. You can read more about KI’s processing of personal data 
here.

[[alternative HTML version deleted]]

___
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 (and Martin) for the advice. I was able to locate the culprit: it
was a data.table::fwrite( ) statement, the behaviour of which must have
changed since the last release. I put this example in a NOT RUN block.

Kind regards,
Aaron




Am Mi., 17. Apr. 2019 um 12:41 Uhr schrieb Martin Morgan <
mtmorgan.b...@gmail.com>:

> maybe as an aid to debugging this, after running R CMD check on
> _1.5.1.tar.gz one can run just the examples with
>
>   R -f pkg.Rcheck/pkg-Ex.R
>
> or interactively with something like
>
>   R
>   > source("pkg.Rcheck/pkg-Ex.R", echo = TRUE, max = Inf)
>
> Martin
>
> On 4/17/19, 5:31 AM, "Bioc-devel on behalf of Pages, Herve" <
> bioc-devel-boun...@r-project.org on behalf of hpa...@fredhutch.org> wrote:
>
> Hi Aaron,
>
> I used 'top' on merida1 (one of our 2 Mac builders, MacOS El Capitan)
> to monitor memory usage of 'R CMD check methimpute_1.5.1.tar.gz' and also
> observed a pick at more than 6Gb there, like on my Linux laptop (Ubuntu
> 16.04 LTS). Note that memory usage stays relatively low (< 1Gb) for most of
> the time 'R CMD check' is running but starts to increase significantly when
> it reaches the "checking examples" step, with the pick happening at the
> very end of that step but for a very short time (about 2 sec.). On Linux I
> hit the space bar every sec in the terminal where I run 'top' to force it
> to refresh the displayed stats with enough frequency, otherwise I would
> probably miss the pick. On merida1 I don't have to do anything because the
> 'top' command there automatically refreshes the displayed stats at very
> short intervals.
>
> H.
>
> On 4/11/19 11:53, Aaron Taudt wrote:
> 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 <
> hpa...@fredhutch.org>:
> 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 

Re: [Bioc-devel] How can I print a message on console with library("myPackage")?

[Martin Morgan]

This is called the 'tragedy of the commons', where everyone seems something 
that looks good (screen real-estate to advertise their package) and so takes 
advantage of it. Once everyone does that, the 'commons' is completely destroyed 
by messages like the one you're trying to suppress.

You can participate in this tragedy by using `packageStartupMessage()` in an 
`.onAttach()` or `.onLoad()` function, typically defined in R/zzz.R

.onAttach <- function(...) {
packageStartupMessage("MY PACKAGE IS MORE IMPORTANT THAN YOUR PACKAGE!!")
}

As a developer you can't suppress messages from other packages (so you should 
make your message really big so that it can't be missed!). You can avoid 
Depend:ing or Import:ing packages that have messages, which might be a 
particularly good idea if the package provides minimal functionality for your 
own package.

The message below comes about because two packages R.oo and R.methodsS3 are 
both loaded directly or indirectly by your package, and they both define 
methods throw.default; this seems pretty strange to me, especially since both 
packages are written by the same person (who sometimes reads this list so might 
respond with a rational explanation)!

As a user you can 

suppressPackageStartupMessages({
library(...)
library(...)
}

Martin

On 4/23/19, 3:04 PM, "Bioc-devel on behalf of Arman Shahrisa" 
 
wrote:

I�m the maintainer of package �cbaf�. I use roxygen2 for documentation.

If I want a message to be printed when the user loads my package with 
library(), what should I do?


I also have another question. When I load my package, a message is printed 
in console:

> Registered S3 method overwritten by 'R.oo':
>  methodfrom
>  throw.default R.methodsS3

How can I prevent this?





Best regards,
Arman


[[alternative HTML version deleted]]


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

Re: [Bioc-devel] How can I print a message on console with library("myPackage")?

[介非王]

Hi Arman,

I only have a suggestion for your first question, have you tried .onLoad
functions? R will call it when loading the package using library(). You can
put your message function in .onLoad.

Best,
Jiefei

Arman Shahrisa  于2019年4月23日周二 下午3:04写道：

> I’m the maintainer of package “cbaf”. I use roxygen2 for documentation.
>
> If I want a message to be printed when the user loads my package with
> library(), what should I do?
>
>
> I also have another question. When I load my package, a message is printed
> in console:
>
> > Registered S3 method overwritten by 'R.oo':
> >  methodfrom
> >  throw.default R.methodsS3
>
> How can I prevent this?
>
>
>
>
>
> Best regards,
> Arman
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Jiefei Wang
Room 2-501,Tangxuan,QilinGarden,NanshanDistrict,Shenzhen
Guangdong,China
Phone (+86)18312589584
szw...@gmail.com

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Adding maintainer to mzID

[Thomas Lin Pedersen]

Great - the description file should already reflect this.

Thanks
Thomas

> On 23 Apr 2019, at 20.51, Turaga, Nitesh  
> wrote:
> 
> Hi Thomas,
> 
> You found the right place. Please issue the change on the package as well (in 
> the devel version), change the maintainer to Laurent Gatto. 
> 
> Laurent should now have access to this package.
> 
> Best regards,
> 
> Nitesh 
> 
>> On Apr 23, 2019, at 2:46 PM, Thomas Lin Pedersen  wrote:
>> 
>> Hi
>> 
>> I wish to add Laurent Gatto as maintainer of the mzID package and give him 
>> full read/write rights to the repository. Is this the formal route for doing 
>> that?
>> 
>> best
>> Thomas
>> ___
>> 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.

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

Re: [Bioc-devel] Adding maintainer to mzID

[Turaga, Nitesh]

Hi Thomas,

You found the right place. Please issue the change on the package as well (in 
the devel version), change the maintainer to Laurent Gatto. 

Laurent should now have access to this package.

Best regards,

Nitesh 

> On Apr 23, 2019, at 2:46 PM, Thomas Lin Pedersen  wrote:
> 
> Hi
> 
> I wish to add Laurent Gatto as maintainer of the mzID package and give him 
> full read/write rights to the repository. Is this the formal route for doing 
> that?
> 
> best
> Thomas
> ___
> 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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Adding maintainer to mzID

[Thomas Lin Pedersen]

Hi

I wish to add Laurent Gatto as maintainer of the mzID package and give him full 
read/write rights to the repository. Is this the formal route for doing that?

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

Re: [Bioc-devel] build errors: "Error in .seqlengths_TwoBitFile(x) : UCSC library operation failed"

[Paul Shannon]

Hi Herve,

Thanks for your reply!

> Is there a possibility that trena's code is having one worker 
> downloading/re-installing BSgenome.Hsapiens.UCSC.hg38 while at the same 
> time another worker is trying to access it?

I don’t think any download or reinstalling happens.  Several genome packages 
(hg38, hg19, mm10) are imported by trena as specified in the DESCRIPTION file, 
and so I assume they must be present after trena is built and installed.  Thus 
- and here’s where I may be confused - there should be nothing to trigger 
download or re-install as the tests, examples and vignettes are run.

In the constructor of the MotifMatcher class, this assignment is made

if(genomeName == "hg38"){
   reference.genome <- 
BSgenome.Hsapiens.UCSC.hg38::BSgenome.Hsapiens.UCSC.hg38
   }

And used later like this:

seqs <- as.character(BSgenome::getSeq(obj@reference.genome, gr.regions))

Hence my suggestion that no download or install takes place at run time.


In the current design of the unit tests for MotifMatcher, I call the 
constructor in each test:

   jaspar.human.pfms <- as.list(query (query(MotifDb, "sapiens"), "jaspar2016"))
   motifMatcher <- MotifMatcher(genomeName="hg38", pfms=jaspar.human.pfms, 
quiet=TRUE)

For what it’s worth, this code is unchanged in the last year, has run fine on 
the build system until recently, and passes R CMD check under R3.6.0beta on 
ubuntu for me.  There is no parallelization in this class - but maybe the build 
system introduces some at a higher level?

I can condition these failing tests on hostname in order to pass the build 
tests if that is not too much of a dodge.

 - Paul


> On Apr 23, 2019, at 12:19 AM, Pages, Herve  wrote:
> 
> Hi Paul,
> 
> Is there a possibility that trena's code is having one worker 
> downloading/re-installing BSgenome.Hsapiens.UCSC.hg38 while at the same 
> time another worker is trying to access it?
> 
> The reason I suspect something like this is that it seems that 
> BSgenome.Hsapiens.UCSC.hg38 gets reinstalled every night on the builders 
> and that this happens at the time the build system is running 'R CMD 
> check' on trena.
> 
> Package vignettes, examples, and unit tests should avoid re-installing 
> packages.
> 
> H.
> 
> On 4/22/19 15:01, Paul Shannon wrote:
>> I cannot reproduce daily build failures found in the trena package by the 
>> build system.  The build report shows:
>> 
>> trena RUnit Tests - 86 test functions, 7 errors, 0 failures
>> 
>> ERROR in test_.injectSnp: Error in .seqlengths_TwoBitFile(x) : UCSC library 
>> operation failed
>> ERROR in test_bugInStartEndOfMinusStrandHits: Error in 
>> .seqlengths_TwoBitFile(x) : UCSC library operation failed
>> ERROR in test_findMatchesByChromosomalRegion: Error in 
>> .seqlengths_TwoBitFile(x) : UCSC library operation failed
>> ERROR in test_findMatchesByChromosomalRegion.twoAlternateAlleles: Error in 
>> .seqlengths_TwoBitFile(x) : UCSC library operation failed
>> ERROR in test_findMatchesByMultipleChromosomalRegions: Error in 
>> .seqlengths_TwoBitFile(x) : UCSC library operation failed
>> ERROR in test_getSequence: Error in .seqlengths_TwoBitFile(x) : UCSC library 
>> operation failed
>> ERROR in test_noMatch: Error in .seqlengths_TwoBitFile(x) : UCSC library 
>> operation failed
>> 
>> This seems similar to a bioc support exchange from two years ago, which may 
>> suggest that the build system's BSgenome.Hsapiens.UCSC.hg38 is the locus of 
>> the problem.   I offer suggestion very tentatively.
>> 
>>support 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_95963_=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=1AJWecG5cm0EI_BZG7zYbHNZa3JkQY8pdsJFahrtpIU=2WHZQbOLmt-jvKlwVBty43jY5JcBt2U_sdqZDqRxEOY=
>> 
>> Any suggestions?
>> 
>>  - Paul
>> 
>> sessionInfo()  # from my clean R CMD check
>> R version 3.6.0 beta (2019-04-11 r76379)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 16.04.5 LTS
>> 
>> Matrix products: default
>> BLAS:   /local/users/pshannon/src/R-beta/lib/libRblas.so
>> LAPACK: /local/users/pshannon/src/R-beta/lib/libRlapack.so
>> 
>> locale:
>>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>> 
>> attached base packages:
>> [1] stats4parallel  stats graphics  grDevices utils datasets
>> [8] methods   base
>> 
>> other attached packages:
>>  [1] RPostgreSQL_0.6-2   DBI_1.0.0   RUnit_0.4.32
>>  [4] trena_1.5.14MotifDb_1.22.0  Biostrings_2.48.0
>>  [7] XVector_0.20.0  IRanges_2.14.12 S4Vectors_0.18.3
>> [10] BiocGenerics_0.26.0 glmnet_2.0-16   foreach_1.4.4
>> [13] Matrix_1.2-17
>> 
>> loaded via a namespace (and not attached):
>>  [1] SummarizedExperiment_1.10.1   

Re: [Bioc-devel] Weird monkey identifiers in org.Hs.eg.db

[Van Twisk, Daniel]

We've made some changes to our annotation generation scripts this release and 
it seems these may have introduced some errors. Thank you for identifying this 
issue and I will try to have some fixes out asap.


From: Bioc-devel  on behalf of James W. 
MacDonald 
Sent: Tuesday, April 23, 2019 11:03:02 AM
To: Aaron Lun
Cc: Bioc-devel
Subject: Re: [Bioc-devel] Weird monkey identifiers in org.Hs.eg.db

Looks like the ensembl table of the human.db0 package got polluted with *Pan
troglodytes* genes:

> con <- dbConnect(SQLite(),
"/R-devel/lib64/R/library/human.db0/extdata/chipsrc_human.sqlite")
> dbGetQuery(con, "select count(*) from ensembl where ensid like
'ENSPTR%';")
  count(*)
116207
> dbGetQuery(con, "select count(*) from ensembl where ensid like 'ENSG%';")
  count(*)
128973

On Mon, Apr 22, 2019 at 11:54 PM Aaron Lun <
infinite.monkeys.with.keyboa...@gmail.com> wrote:

> Playing around with org.Hs.eg.db 3.8.0. What on earth is ENSPTRG...?
>
>  > library(org.Hs.eg.db)
>  > mapIds(org.Hs.eg.db, key="GCG", keytype="SYMBOL", column="ENSEMBL")
> 'select()' returned 1:many mapping between keys and columns
>   GCG
> "ENSPTRG777"
>
> Well, at least it still recovers the right identifier... eventually.
>
>  > select(org.Hs.eg.db, key="GCG", keytype="SYMBOL", columns="ENSEMBL")
> 'select()' returned 1:many mapping between keys and columns
>SYMBOLENSEMBL
> 1GCG ENSPTRG777
> 2GCGENSG0115263
>
> The SYMBOL->Entrez ID relational table seems to be okay:
>
>  > Y <- toTable(org.Hs.egSYMBOL)
>  > Y[which(Y[,2]=="GCG"),]
>   gene_id symbol
> 21522641GCG
>
> So the cause is the Ensembl->Entrez mappings:
>
>  > Z <- toTable(org.Hs.egENSEMBL2EG)
>  > Z[Z[,1]==2641,]
>   gene_id ensembl_id
> 30282641 ENSPTRG777
> 30292641ENSG0115263
>
> Googling suggests that ENSPTRG777 is an identifier for some
> other gene in one of the other monkeys. Hardly "Hs" stuff.
>
> Session info (not technically R 3.6, but I didn't think that would have
> been the cause):
>
> > R Under development (unstable) (2019-04-11 r76379)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Ubuntu 18.04.2 LTS
> >
> > Matrix products: default
> > BLAS:   /home/luna/Software/R/trunk/lib/libRblas.so
> > LAPACK: /home/luna/Software/R/trunk/lib/libRlapack.so
> >
> > locale:
> >  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> >  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> >  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> >  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> >  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] parallel  stats4stats graphics  grDevices utils datasets
> > [8] methods   base
> >
> > other attached packages:
> > [1] org.Hs.eg.db_3.8.0   AnnotationDbi_1.45.1 IRanges_2.17.5
> > [4] S4Vectors_0.21.23Biobase_2.43.1   BiocGenerics_0.29.2
> >
> > loaded via a namespace (and not attached):
> >  [1] Rcpp_1.0.1  digest_0.6.18   DBI_1.0.0   RSQLite_2.1.1
> >  [5] blob_1.1.1  bit64_0.9-7 bit_1.1-14  compiler_3.7.0
> >  [9] pkgconfig_2.0.2 memoise_1.1.0
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[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

Re: [Bioc-devel] Weird monkey identifiers in org.Hs.eg.db

[James W. MacDonald]

Looks like the ensembl table of the human.db0 package got polluted with *Pan
troglodytes* genes:

> con <- dbConnect(SQLite(),
"/R-devel/lib64/R/library/human.db0/extdata/chipsrc_human.sqlite")
> dbGetQuery(con, "select count(*) from ensembl where ensid like
'ENSPTR%';")
  count(*)
116207
> dbGetQuery(con, "select count(*) from ensembl where ensid like 'ENSG%';")
  count(*)
128973

On Mon, Apr 22, 2019 at 11:54 PM Aaron Lun <
infinite.monkeys.with.keyboa...@gmail.com> wrote:

> Playing around with org.Hs.eg.db 3.8.0. What on earth is ENSPTRG...?
>
>  > library(org.Hs.eg.db)
>  > mapIds(org.Hs.eg.db, key="GCG", keytype="SYMBOL", column="ENSEMBL")
> 'select()' returned 1:many mapping between keys and columns
>   GCG
> "ENSPTRG777"
>
> Well, at least it still recovers the right identifier... eventually.
>
>  > select(org.Hs.eg.db, key="GCG", keytype="SYMBOL", columns="ENSEMBL")
> 'select()' returned 1:many mapping between keys and columns
>SYMBOLENSEMBL
> 1GCG ENSPTRG777
> 2GCGENSG0115263
>
> The SYMBOL->Entrez ID relational table seems to be okay:
>
>  > Y <- toTable(org.Hs.egSYMBOL)
>  > Y[which(Y[,2]=="GCG"),]
>   gene_id symbol
> 21522641GCG
>
> So the cause is the Ensembl->Entrez mappings:
>
>  > Z <- toTable(org.Hs.egENSEMBL2EG)
>  > Z[Z[,1]==2641,]
>   gene_id ensembl_id
> 30282641 ENSPTRG777
> 30292641ENSG0115263
>
> Googling suggests that ENSPTRG777 is an identifier for some
> other gene in one of the other monkeys. Hardly "Hs" stuff.
>
> Session info (not technically R 3.6, but I didn't think that would have
> been the cause):
>
> > R Under development (unstable) (2019-04-11 r76379)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Ubuntu 18.04.2 LTS
> >
> > Matrix products: default
> > BLAS:   /home/luna/Software/R/trunk/lib/libRblas.so
> > LAPACK: /home/luna/Software/R/trunk/lib/libRlapack.so
> >
> > locale:
> >  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> >  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> >  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> >  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> >  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] parallel  stats4stats graphics  grDevices utils datasets
> > [8] methods   base
> >
> > other attached packages:
> > [1] org.Hs.eg.db_3.8.0   AnnotationDbi_1.45.1 IRanges_2.17.5
> > [4] S4Vectors_0.21.23Biobase_2.43.1   BiocGenerics_0.29.2
> >
> > loaded via a namespace (and not attached):
> >  [1] Rcpp_1.0.1  digest_0.6.18   DBI_1.0.0   RSQLite_2.1.1
> >  [5] blob_1.1.1  bit64_0.9-7 bit_1.1-14  compiler_3.7.0
> >  [9] pkgconfig_2.0.2 memoise_1.1.0
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Error: invalid graphics state in creating vignettes

[Jianhong Ou, Ph.D.]

Hi Sunyong,

plotMotifLogo does not compatible with par now. Please use grid to plot the 
multiple panels in one canvas. I am working on this but it takes time.

Jianhong.

On 4/23/19, 12:47 AM, "Bioc-devel on behalf of Shin, Sunyoung" 
 
wrote:

Dear all,

I got an error message: invalid graphics state as below from BUILD report 
for atSNP 0.99.23 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__master.bioconductor.org_packages_3.9_bioc_html_atSNP.html=DwIGaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=PXg851DHXyo-Gs3eMIfeo49gUXVh-JSZu_MZDDxGun8=PbqNdXfVMLxlePSjrHOEN8-tkQLva8Pg6UAfB4VOTUw=lESpOegy3zU7jKZUfxiUhG5mSg7qotzhof_KHZmVEB8=).
 This occurs on every platform: malbec2, tokay2, and celaya2. Running  
devtools::check()  on my local computer does not produce the error. I would 
appreciate it if anyone can help debugging.

* creating vignettes ... ERROR

--- re-building ‘atsnp-vignette.rmd’ using rmarkdown
Quitting from lines 292-294 (atsnp-vignette.rmd)
Error: processing vignette 'atsnp-vignette.rmd' failed with diagnostics:
invalid graphics state
--- failed re-building ‘atsnp-vignette.rmd’

SUMMARY: processing the following file failed:
  ‘atsnp-vignette.rmd’

Error: Vignette re-building failed.
Execution halted

The graphing function which makes the error is plotMotifMatch(match.seq,  
motif.lib = motif_library). Below is the part of the code that is needed  to be 
fixed, I think.

{
  par(mfrow=c(4,1), oma=c(1,1,4,1))
  plot.new()
  par(mar=c(1.5, 3, 4, 2))
  plotMotifLogo(pcm2pfm(ref_aug_pwm), "Best match to the reference genome", 
yaxis=FALSE, xaxis=FALSE, xlab="", ylab="PWM", ...)
if(motif.match$ref_strand=='+') {
arrows((min(which(colSums(ref_aug_pwm)!=0))-1)/ncol(ref_aug_pwm), -0.17, 
max(which(colSums(ref_aug_pwm)!=0))/ncol(ref_aug_pwm), -0.17, length = 0.1, 
angle = 15, code = 2, col = "blue", lwd = 1.5, xpd=NA)
  mtext("5'", 1, 
adj=(min(which(colSums(ref_aug_pwm)!=0))-1)/ncol(ref_aug_pwm), padj=1, 
col="blue", cex=1)
  mtext("3'", 1, adj=max(which(colSums(ref_aug_pwm)!=0))/ncol(ref_aug_pwm), 
padj=1, col="blue", cex=1)
} else {
arrows(max(which(colSums(ref_aug_pwm)!=0))/ncol(ref_aug_pwm), -0.17, 
(min(which(colSums(ref_aug_pwm)!=0))-1)/ncol(ref_aug_pwm), -0.17, length = 0.1, 
angle = 15, code = 2, col = "blue", lwd = 1.5, xpd=NA)
  mtext("5'", 1, adj=max(which(colSums(ref_aug_pwm)!=0))/ncol(ref_aug_pwm), 
padj=1, col="blue", cex=1)
  mtext("3'", 1, 
adj=(min(which(colSums(ref_aug_pwm)!=0))-1)/ncol(ref_aug_pwm), padj=1, 
col="blue", cex=1)
}
  par(mar = c(4, 3, 1.5, 2))
plotMotifLogo(pcm2pfm(ref_aug_match_pwm), font="mono,Courier", yaxis=FALSE, 
xlab="", ylab=paste("(", motif.match$ref_strand, ")", sep=""), ...)
segments(snp_loc/motif.match$snp_ref_length, 0, 
snp_loc/motif.match$snp_ref_length, 1, col="blue", lty=3, lwd=2)
segments(snp_loc/motif.match$snp_ref_length, 1, 
(snp_loc+1)/motif.match$snp_ref_length, 1, col="blue", lty=3, lwd=2)
segments((snp_loc+1)/motif.match$snp_ref_length, 0, 
(snp_loc+1)/motif.match$snp_ref_length, 1, col="blue", lty=3, lwd=2)
segments(snp_loc/motif.match$snp_ref_length, 0, 
(snp_loc+1)/motif.match$snp_ref_length, 0, col="blue", lty=3, lwd=2)
  if(motif.match$ref_strand=="+")   {
  mtext("5'", 1,  adj=0, padj=1, col="blue", cex=1)
  mtext("3'", 1,  adj=1, padj=1, col="blue", cex=1)
} else {
  mtext("3'", 1, adj=0, padj=1, col="blue", cex=1)
  mtext("5'", 1, adj=1, padj=1, col="blue", cex=1)
  }
par(mar=c(1.5, 3, 4, 2))
plotMotifLogo(pcm2pfm(snp_aug_match_pwm), "Best match to the SNP genome", 
font="mono,Courier", yaxis=FALSE, xlab="", ylab=paste("(", 
motif.match$snp_strand, ")", sep=""), ...)
segments(snp_loc/motif.match$snp_ref_length, 0, 
snp_loc/motif.match$snp_ref_length, 1, col="blue", lty=3, lwd=2)
segments(snp_loc/motif.match$snp_ref_length, 1, 
(snp_loc+1)/motif.match$snp_ref_length, 1, col="blue", lty=3, lwd=2)
segments((snp_loc+1)/motif.match$snp_ref_length, 0, 
(snp_loc+1)/motif.match$snp_ref_length, 1, col="blue", lty=3, lwd=2)
segments(snp_loc/motif.match$snp_ref_length, 0, 
(snp_loc+1)/motif.match$snp_ref_length, 0, col="blue", lty=3, lwd=2)
  if(motif.match$snp_strand=="+")   {
  mtext("5'", 1,  adj=0, padj=1, col="blue", cex=1)
  mtext("3'", 1,  adj=1, padj=1, col="blue", cex=1)
} else {
  mtext("3'", 1, adj=0, padj=1, col="blue", cex=1)
  mtext("5'", 1, adj=1, padj=1, col="blue", cex=1)
  }
par(mar=c(4, 3, 1.5, 2))
plotMotifLogo(pcm2pfm(snp_aug_pwm), yaxis=FALSE, xaxis=FALSE, xlab="", 
ylab="PWM", ...)
if(motif.match$snp_strand=='+') {
arrows((min(which(colSums(snp_aug_pwm)!=0))-1)/ncol(snp_aug_pwm), -0.17, 
max(which(colSums(snp_aug_pwm)!=0))/ncol(snp_aug_pwm), -0.17, length = 0.1, 
angle = 15, code = 2, col = "blue", lwd = 1.5, xpd=NA)
  mtext("5'", 1,