Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet

[frederik]

Thanks Paul for answering the additional question.

I admit that I've only had experience with R's X11 code through work
on a couple of bugs, but for some reason I thought it might be
nontrivial to move it all into a self-contained module due to
interactions with various event loops. The two modules you listed
appear to be used for producing output in image and document formats,
so they don't really cast light on whether this is a problem.

I am not very serious about contributing my time to an effort like
this, but maybe it is good to have some discussion here anyway. I had
thought that maybe authors of alternative plotting interfaces would
have something to say about whether the current graphics design
provides sufficient modularity. Obviously it is modular enough for
RStudio to exist.

Other improvements aside, I think it would just be better to comment
out the old "#if BUG" line, and wait for someone to complain if it
breaks something. A lot has been changed since that line was added, as
I explained in the bug report. I would expect that the bug it was
attempting to fix no longer exists.

Otherwise, what is the next milestone on this bug?

Frederick

On Wed, Apr 24, 2019 at 12:30:44PM +1200, Paul Murrell wrote:

Hi

Sorry, I can't offer an explanation for the commented-out line.
However, regarding your final question of avoiding the R-core 
bottleneck, you do have the option of creating a third-party graphics 
device package.  See, for example, the 'tikzDevice' and 'svglite' 
packages on CRAN.  Does that provide you with a way forward ?


Paul

On 20/04/2019 5:27 p.m., frede...@ofb.net wrote:

Dear R Devel,

I know that someone put this line in src/modules/X11/devX11.c:2824 for
a reason, because commenting it out causes R to miss an important
ConfigureNotify event in my window manager. The result is that plots
are initially drawn off the window borders, unreadable.

   R_ProcessX11Events((void*) NULL);

Unfortunately for me, this line is commented in the standard release
of R, it has "#if BUG ... #endif" around it.

I guess it is also unfortunate for anyone who uses the same window
manager as I do, namely i3, which I think is pretty popular among Unix
power users these days; not to mention other full-screen window
managers which probably exhibit the same bug in R.

Maybe everyone on the Core team uses twm as their window manager? Or
RStudio on Windows? Which would be sad because then we're not
representing an important user demographic, namely those who prefer
software which is modern and powerful, yet simple to understand and
modify; fully configurable and interoperable and so on.

I first reported this bug 3 years ago. In doing research for my bug
report, I found that the line was commented out by Peter Dalgaard in
2001 with the explanation "X11 segfault fix - I hope".

I don't know what the way forward is. Obviously the Core Team has
reason to say, "look, this isn't very important, it's been broken
since 2001, maybe fixing it will cause the undocumented segfault bug
to reappear, clearly no one here uses your window manager". Do I have
to submit a correctness proof for the proposed change? What do I do?

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702

As mentioned in my bug report, I checked using gdb that
ConfigureNotify is indeed being received by the call to
R_ProcessX11Events() when it is uncommented. I haven't experienced any
segfaults.

It's good that Peter left evidence that "R_ProcessX11Events" was being
called 18 years ago from X11DeviceDriver(). If he had deleted the
line, rather than commenting it, then discovering the reason for the
window rendering bug would have been much harder for me.

However, the downside is that now it is not just a matter of inserting
the line where it belongs; I also feel a bit like I have to explain
why it was initially removed. But although I've given it some thought,
I still have no idea.

Somewhat tangentially, I am wondering if there is some way that we
could make the development of R's graphics code proceed at a faster
rate, for example by pulling it out into a separate module, so that
people could offer alternative implementations via CRAN etc., rather
than having R Core be the bottleneck. Would this make sense? Has it
already been done?

Thank you,

Frederick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Linux Errors on RHub

[Steven Scott]

The examples are dual purpose.  They work like unit tests, and they show
humans how the code works.  If you have a separate unit testing section you
can mock out the parts that take a long time (e.g. "get data from...").
Then just put the slow bits in your .Rd files into \dontrun blocks.

On Tue, Apr 23, 2019 at 5:54 PM Roy Mendelssohn - NOAA Federal <
roy.mendelss...@noaa.gov> wrote:

> No C++ in my package,  but I think sf or rgdal may have c++.  I have
> graphics examples overlaying grids on maps using ggplot2.  trying to get
> those under 5 sec and still have a meaningful example is nigh impossible.
> I mean I can make up an example that will be under 5 sec,  but it will
> neither be illuminating nor testing of anything.  I have even included the
> test data in the package so that it is faster, (this package maps data from
> a package that downloads data from a web service)  but I am still not
> there.  Also the times I get at home are about half of what CRAN or RHub
> get.
>
> I have a similar problem with a package that downloads data from a web
> service.  Even the most minimal example takes more than 5 seconds.  I fully
> understand CRAN's position.  When you have 1000s of package to test on
> different OS,  if everything takes too long it would be a disaster.  At the
> same time,  basically the last three days I have been trying to figure out
> how to get the times down.
>
> -Roy
>
> On Apr 23, 2019, at 5:33 PM, Steven Scott 
> wrote:
>
> Roy, I don't have an answer for you, but I have a similar issue.
> Does your code happen to have a C++ component that takes a long time to
> compile?
>
> On Tue, Apr 23, 2019 at 5:11 PM Roy Mendelssohn - NOAA Federal via
> R-package-devel  wrote:
>
>
>
> -- Forwarded message --
> From: Roy Mendelssohn - NOAA Federal 
> To: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> Cc:
> Bcc:
> Date: Tue, 23 Apr 2019 17:11:14 -0700
> Subject: Linux Errors on RHub
> Hi All:
>
> I am checking a package I am hoping to submit to CRAN on RHub.  The
> Windows and Fedora runs worked but the Ubuntu test ended because of the
> following:
>
> #> Warning messages:
> 3203#> 1: In i.p(...) : installation of package ‘rgdal’ had non-zero exit
> status
> 3204#> 2: In i.p(...) : installation of package ‘sf’ had non-zero exit
> status
> 3205#> 3: In i.p(...) :
>
>
> I have a few details to work out on Mac and Windows tests (capitalization,
> a note to CRAN that a spelling is correct, reduce times of examples),  but
> given that rgdal and sf are packages on CRAN if I can clean up the other
> items is it appropriate to go ahead and submit?
>
> Thanks,
>
> -Roy
>
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
>
>
>
> -- Forwarded message --
> From: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> To: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> Cc:
> Bcc:
> Date: Tue, 23 Apr 2019 17:11:14 -0700
> Subject: [R-pkg-devel] Linux Errors on RHub
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet

[Paul Murrell]

Hi

Sorry, I can't offer an explanation for the commented-out line.
However, regarding your final question of avoiding the R-core 
bottleneck, you do have the option of creating a third-party graphics 
device package.  See, for example, the 'tikzDevice' and 'svglite' 
packages on CRAN.  Does that provide you with a way forward ?


Paul

On 20/04/2019 5:27 p.m., frede...@ofb.net wrote:

Dear R Devel,

I know that someone put this line in src/modules/X11/devX11.c:2824 for
a reason, because commenting it out causes R to miss an important
ConfigureNotify event in my window manager. The result is that plots
are initially drawn off the window borders, unreadable.

R_ProcessX11Events((void*) NULL);

Unfortunately for me, this line is commented in the standard release
of R, it has "#if BUG ... #endif" around it.

I guess it is also unfortunate for anyone who uses the same window
manager as I do, namely i3, which I think is pretty popular among Unix
power users these days; not to mention other full-screen window
managers which probably exhibit the same bug in R.

Maybe everyone on the Core team uses twm as their window manager? Or
RStudio on Windows? Which would be sad because then we're not
representing an important user demographic, namely those who prefer
software which is modern and powerful, yet simple to understand and
modify; fully configurable and interoperable and so on.

I first reported this bug 3 years ago. In doing research for my bug
report, I found that the line was commented out by Peter Dalgaard in
2001 with the explanation "X11 segfault fix - I hope".

I don't know what the way forward is. Obviously the Core Team has
reason to say, "look, this isn't very important, it's been broken
since 2001, maybe fixing it will cause the undocumented segfault bug
to reappear, clearly no one here uses your window manager". Do I have
to submit a correctness proof for the proposed change? What do I do?

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702

As mentioned in my bug report, I checked using gdb that
ConfigureNotify is indeed being received by the call to
R_ProcessX11Events() when it is uncommented. I haven't experienced any
segfaults.

It's good that Peter left evidence that "R_ProcessX11Events" was being
called 18 years ago from X11DeviceDriver(). If he had deleted the
line, rather than commenting it, then discovering the reason for the
window rendering bug would have been much harder for me.

However, the downside is that now it is not just a matter of inserting
the line where it belongs; I also feel a bit like I have to explain
why it was initially removed. But although I've given it some thought,
I still have no idea.

Somewhat tangentially, I am wondering if there is some way that we
could make the development of R's graphics code proceed at a faster
rate, for example by pulling it out into a separate module, so that
people could offer alternative implementations via CRAN etc., rather
than having R Core be the bottleneck. Would this make sense? Has it
already been done?

Thank you,

Frederick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Linux Errors on RHub

[Steven Scott]

Roy, I don't have an answer for you, but I have a similar issue.
Does your code happen to have a C++ component that takes a long time to
compile?

On Tue, Apr 23, 2019 at 5:11 PM Roy Mendelssohn - NOAA Federal via
R-package-devel  wrote:

>
>
>
> -- Forwarded message --
> From: Roy Mendelssohn - NOAA Federal 
> To: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> Cc:
> Bcc:
> Date: Tue, 23 Apr 2019 17:11:14 -0700
> Subject: Linux Errors on RHub
> Hi All:
>
> I am checking a package I am hoping to submit to CRAN on RHub.  The
> Windows and Fedora runs worked but the Ubuntu test ended because of the
> following:
>
> > #> Warning messages:
> > 3203#> 1: In i.p(...) : installation of package ‘rgdal’ had non-zero
> exit status
> > 3204#> 2: In i.p(...) : installation of package ‘sf’ had non-zero exit
> status
> > 3205#> 3: In i.p(...) :
>
> I have a few details to work out on Mac and Windows tests (capitalization,
> a note to CRAN that a spelling is correct, reduce times of examples),  but
> given that rgdal and sf are packages on CRAN if I can clean up the other
> items is it appropriate to go ahead and submit?
>
> Thanks,
>
> -Roy
>
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
>
>
>
> -- Forwarded message --
> From: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> To: Roy Mendelssohn - NOAA Federal via R-package-devel <
> r-package-devel@r-project.org>
> Cc:
> Bcc:
> Date: Tue, 23 Apr 2019 17:11:14 -0700
> Subject: [R-pkg-devel] Linux Errors on RHub
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Linux Errors on RHub

[Roy Mendelssohn - NOAA Federal via R-package-devel]

--- Begin Message ---
Hi All:

I am checking a package I am hoping to submit to CRAN on RHub.  The Windows and 
Fedora runs worked but the Ubuntu test ended because of the following:

> #> Warning messages:
> 3203#> 1: In i.p(...) : installation of package ‘rgdal’ had non-zero exit 
> status
> 3204#> 2: In i.p(...) : installation of package ‘sf’ had non-zero exit status
> 3205#> 3: In i.p(...) :

I have a few details to work out on Mac and Windows tests (capitalization, a 
note to CRAN that a spelling is correct, reduce times of examples),  but given 
that rgdal and sf are packages on CRAN if I can clean up the other items is it 
appropriate to go ahead and submit?

Thanks,

-Roy


**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

--- End Message ---
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] R-devel (rev 76409) fails 'make check': non-generic function 'isSymmetric' given to findMethods()

[Benjamin Tyner]

Looks fixed as of revision 76417; thanks Brian!

On 4/21/19 9:02 PM, Benjamin Tyner wrote:

Duncan that does indeed look to be the case. Many thanks!

In particular, tests/reg-tests-1d.R optionally loads the Matrix 
namespace which allows the test to succeed. Compare:


   ~/R-rc_2019-04-21_r76409/bin/Rscript -e "options(warn=2);
   library(Matrix); res <- findMethods('isSymmetric'); print('success')"
   [1] "success"

versus

   ~/R-rc_2019-04-21_r76409/bin/Rscript -e "options(warn=2); res <-
   findMethods('isSymmetric'); print('success')"
   Error in findMethods("isSymmetric") :
      (converted from warning) non-generic function 'isSymmetric' given
   to findMethods()
   Execution halted


On 4/21/19 7:47 PM, Duncan Murdoch wrote:


Likely the problem is that you don't have the recommended packages 
loaded.  When I was running tests regularly, they were required. 
Later, I think they became optional.  Perhaps a new test has been 
added that once again assumes the required packages are installed.


Duncan Murdoch



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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: [R-pkg-devel] [EXTERNAL] Re: CRAN Debian File Handling Differences?

[David Blodgett via R-package-devel]

--- Begin Message ---
I see. Thank you for the clarification. I did not realize this applied to 
testing as well as package functionality.

> On Apr 23, 2019, at 10:28 AM, Iñaki Ucar  wrote:
> 
> On Tue, 23 Apr 2019 at 17:24, David Blodgett  wrote:
>> 
>> OK. Thank you. I'm always nervous about closing and re-opening a tempfile() 
>> but I suppose it is safe.
>> 
>> Should I interpret your response as saying that creating and mutating files 
>> in "tests/testthat/data" is not possible on CRAN?
> 
> From CRAN Repository Policy:
> 
> - Packages should not write in the user’s home filespace (including
> clipboards), nor anywhere else on the file system apart from the R
> session’s temporary directory (or during installation in the location
> pointed to by TMPDIR: and such usage should be cleaned up).
> 
> -- 
> Iñaki Úcar

--- End Message ---
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [EXTERNAL] Re: CRAN Debian File Handling Differences?

[Iñaki Ucar]

On Tue, 23 Apr 2019 at 17:24, David Blodgett  wrote:
>
> OK. Thank you. I'm always nervous about closing and re-opening a tempfile() 
> but I suppose it is safe.
>
> Should I interpret your response as saying that creating and mutating files 
> in "tests/testthat/data" is not possible on CRAN?

>From CRAN Repository Policy:

- Packages should not write in the user’s home filespace (including
clipboards), nor anywhere else on the file system apart from the R
session’s temporary directory (or during installation in the location
pointed to by TMPDIR: and such usage should be cleaned up).

-- 
Iñaki Úcar

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [EXTERNAL] Re: CRAN Debian File Handling Differences?

[David Blodgett via R-package-devel]

--- Begin Message ---
OK. Thank you. I'm always nervous about closing and re-opening a tempfile() but 
I suppose it is safe.

Should I interpret your response as saying that creating and mutating files in 
"tests/testthat/data" is not possible on CRAN?

Thank you,

- Dave

> On Apr 23, 2019, at 10:16 AM, Iñaki Ucar  wrote:
> 
> On Tue, 23 Apr 2019 at 15:57, David Blodgett via R-package-devel
>  wrote:
>> 
>> I'm working on some CRAN Debian test failures 
>> (https://win-builder.r-project.org/incoming_pretest/ncdfgeom_1.0.0_20190423_031452/).
>>  The tests all pass on rhub Debian, CRAN windows, local OSX, and Travis 
>> Ubuntu. The tests that are failing on CRAN Debian are ones where I check 
>> that changes got made to an existing file that is modified in place by my 
>> package code.
>> 
>> Are there nuances of the CRAN environment that prevent a `tempfile()` file 
>> being created then modified at run time? What is a suggested best practice 
>> for such a test?
> 
> According to the current master branch, the test that fails is not
> using tempfile(), but "nc_file<-'data/test_output.nc'". Just change
> that line with a call to tempfile and the test should pass.
> 
> -- 
> Iñaki Úcar

--- End Message ---
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN Debian File Handling Differences?

[Iñaki Ucar]

On Tue, 23 Apr 2019 at 15:57, David Blodgett via R-package-devel
 wrote:
>
> I'm working on some CRAN Debian test failures 
> (https://win-builder.r-project.org/incoming_pretest/ncdfgeom_1.0.0_20190423_031452/).
>  The tests all pass on rhub Debian, CRAN windows, local OSX, and Travis 
> Ubuntu. The tests that are failing on CRAN Debian are ones where I check that 
> changes got made to an existing file that is modified in place by my package 
> code.
>
> Are there nuances of the CRAN environment that prevent a `tempfile()` file 
> being created then modified at run time? What is a suggested best practice 
> for such a test?

According to the current master branch, the test that fails is not
using tempfile(), but "nc_file<-'data/test_output.nc'". Just change
that line with a call to tempfile and the test should pass.

-- 
Iñaki Úcar

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-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

[R-pkg-devel] CRAN Debian File Handling Differences?

[David Blodgett via R-package-devel]

--- Begin Message ---
Dear R Package Development Community,

I'm working on some CRAN Debian test failures 
(https://win-builder.r-project.org/incoming_pretest/ncdfgeom_1.0.0_20190423_031452/).
 The tests all pass on rhub Debian, CRAN windows, local OSX, and Travis Ubuntu. 
The tests that are failing on CRAN Debian are ones where I check that changes 
got made to an existing file that is modified in place by my package code. 

Are there nuances of the CRAN environment that prevent a `tempfile()` file 
being created then modified at run time? What is a suggested best practice for 
such a test? 

I may just disable this set of tests on CRAN for the time being since it passes 
on so many environments, but want to do my due diligence and decrease fragility 
as much as possible.

Thanks for any guidance you can offer. 

Regards,

- Dave 
--- End Message ---
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-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,