Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5

[Ramon Diaz-Uriarte]

Dear Martin,


Thanks a lot for looking into this. I'll wait then.


Best,


R.

On Mon, 03-04-2017, at 18:34, Martin Morgan  
wrote:
> On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:
>>
>> Dear All,
>>
>> A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
>> segfault that seems to happen when plotting (in a call to plotting that
>> happens inside a mclapply)
>>
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/veracruz2-buildsrc.html
>>
>>
>> these are some of the lines of the traceback:
>>
>> Traceback:
>>  1: dev.hold()
>>  2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 
>> 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 
>> 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 
>> 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 
>> 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 
>> 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226, 
>> 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), 
>> c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 
>> 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, 
>> -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, 
>> -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, 
>> -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = 
>> quote("Chromosomal location"), col = c("orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>  "orange", "orange", "orange", "orange", "orange"), cex = 1, axes = 
>> FALSE, main = quote("Chr4@L.1"), pch = 20)
>>  3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5, 
>> 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734, 
>> 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5, 
>> 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180, 
>> 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724, 
>> 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5, 
>> 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 
>> 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 0.172, 
>> -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 
>> 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, 
>> -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, 
>> -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal 
>> location"), col = c("orange", "orange", "orange", "orange", "orange",
>>  "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
>> "orange", "orange", "orange"), cex = 1, axes = FALSE, main = 
>> quote("Chr4@L.1"), pch = 20)
>>  4: do.call(funname, c(list(mf[[i]], y, ylab = yl, xlab = xl), dots))
>>
>>
>>
>> It seems that what triggers the problem is an innocuous plot.default
>> followed by dev.hold? (none of which I call explicitly in my code)
>
> I was able to reproduce this with
>
> $ cat segfault-test.R
> xx <- parallel::mclapply(1:2, function(i) {
>  Cairo::CairoPNG(filename = paste("plt", i, ".png", sep=''))
>  dev.hold()
> })
>
> $ R -f segfault-test.R
>
> The El-Capitain builds are still in a great deal of flux, and in 
> particular the Cairo package requires a binary installation that is not 
> yet available (the Cairo package is used is actually from Mavericks). 
> The best strategy is probably to wait until binaries become available.
>
> Martin
>
>>
>>
>> At least another package, arrayQualityMetrics seems to experience a
>> somewhat similar problem:
>>
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/arrayQualityMetrics/veracruz2-buildsrc.html
>>
>> where, again, an apparently innocuous plot.default followed by dev.hold
>> triggers a segfault (and there is no mclapply here)
>>
>> Traceback:
>>  1: dev.hold()
>>  2: plot.default(-2, -1, pch = "", xlim = range(-1, (dim(mns)[2])), ylim 
>> = range(min(as.vector(mns)) - 1, max(as.vector(mns)) + 1), xlab = 
>> "5' <-> 3'\n Probe Number ", ylab = ylab, axes = FALSE, main = "RNA 
>> degradation plot", ...)
>>  3: 

Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5

[Martin Morgan]

On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:


Dear All,

A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
segfault that seems to happen when plotting (in a call to plotting that
happens inside a mclapply)

http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/veracruz2-buildsrc.html


these are some of the lines of the traceback:

Traceback:
 1: dev.hold()
 2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 0.002, -0.179, -0.1385, -0.095, 
-0.611, -0.165, -0.54, -0.358, 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal location"), col = c("orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1, axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
 3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, 
-0.165, -0.54, -0.358, 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal location"), col = c("orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", 
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1, axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
 4: do.call(funname, c(list(mf[[i]], y, ylab = yl, xlab = xl), dots))



It seems that what triggers the problem is an innocuous plot.default
followed by dev.hold? (none of which I call explicitly in my code)


I was able to reproduce this with

$ cat segfault-test.R
xx <- parallel::mclapply(1:2, function(i) {
Cairo::CairoPNG(filename = paste("plt", i, ".png", sep=''))
dev.hold()
})

$ R -f segfault-test.R

The El-Capitain builds are still in a great deal of flux, and in 
particular the Cairo package requires a binary installation that is not 
yet available (the Cairo package is used is actually from Mavericks). 
The best strategy is probably to wait until binaries become available.


Martin




At least another package, arrayQualityMetrics seems to experience a
somewhat similar problem:

http://bioconductor.org/checkResults/devel/bioc-LATEST/arrayQualityMetrics/veracruz2-buildsrc.html

where, again, an apparently innocuous plot.default followed by dev.hold
triggers a segfault (and there is no mclapply here)

Traceback:
 1: dev.hold()
 2: plot.default(-2, -1, pch = "", xlim = range(-1, (dim(mns)[2])), ylim = range(min(as.vector(mns)) 
- 1, max(as.vector(mns)) + 1), xlab = "5' <-> 3'\n Probe Number ", ylab = ylab, 
axes = FALSE, main = "RNA degradation plot", ...)
 3: plot(-2, -1, pch = "", xlim = range(-1, (dim(mns)[2])), ylim = range(min(as.vector(mns)) - 1, 
max(as.vector(mns)) + 1), xlab = "5' <-> 3'\n Probe Number ", ylab = ylab, axes = FALSE, 
main = "RNA degradation plot", ...)
 4: plotAffyRNAdeg(AffyRNAdeg(expressionset, log.it = TRUE), lwd = 1, cols 
= x$arrayColors)




I am not sure how to proceed here. Any suggestions?


Thanks,


R.

--
Ramon Diaz-Uriarte
Department of 

Re: [Bioc-devel] cbind SummarizedExperiments containing a DNAStringSet not working

[Hervé Pagès]

Hi Maarten,

identical() is not reliable on DNAStringSet objects or other objects
that contain external pointers as it can return false negatives as well
as false positives. We'll fix the "cbind" and "rbind" methods for
SummarizedExperiment to work around this problem.

Thanks for the report.

H.

On 04/03/2017 12:58 AM, Maarten van Iterson wrote:

Dear list,

Combining SummarizedExperiment object, containing a DNAStringSet in the
rowData seems not to work properly. If I cbind two SummarizedExperiment
objects, which I know are identical, an error is reported:

Error in FUN(X[[i]], ...) (from #2) :
  column(s) 'sourceSeq' in ‘mcols’ are duplicated and the data do not match

I think I traced the problem existing in `SummarizedExperiment:::.compare`
in that `identical` is used to compare DNAStringSets which is not behaving
as expected. Whereas it should return all identical it returns it is not!

Here is a counter example (which was easier to construct) showing that
`identical` returns FALSE where it should return TRUE.


library(Biostrings)
seq1 <- paste(DNA_BASES[sample(1:4,5,replace=T)], collapse="")
seq2 <- paste(DNA_BASES[sample(1:4,5,replace=T)], collapse="")

seq1

[1] "GACTC"

seq2

[1] "GAATG"


s1 <- DNAStringSet(seq1)
s2 <- DNAStringSet(seq2)

str(s1)

Formal class 'DNAStringSet' [package "Biostrings"] with 5 slots
  ..@ pool   :Formal class 'SharedRaw_Pool' [package "XVector"]
with 2 slots
  .. .. ..@ xp_list:List of 1
  .. .. .. ..$ :
  .. .. ..@ .link_to_cached_object_list:List of 1
  .. .. .. ..$ :
  ..@ ranges :Formal class 'GroupedIRanges' [package "XVector"]
with 7 slots
  .. .. ..@ group  : int 1
  .. .. ..@ start  : int 1
  .. .. ..@ width  : int 5
  .. .. ..@ NAMES  : NULL
  .. .. ..@ elementType: chr "integer"
  .. .. ..@ elementMetadata: NULL
  .. .. ..@ metadata   : list()
  ..@ elementType: chr "DNAString"
  ..@ elementMetadata: NULL
  ..@ metadata   : list()

str(s2)

Formal class 'DNAStringSet' [package "Biostrings"] with 5 slots
  ..@ pool   :Formal class 'SharedRaw_Pool' [package "XVector"]
with 2 slots
  .. .. ..@ xp_list:List of 1
  .. .. .. ..$ :
  .. .. ..@ .link_to_cached_object_list:List of 1
  .. .. .. ..$ :

  ..@ ranges :Formal class 'GroupedIRanges' [package "XVector"]
with 7 slots
  .. .. ..@ group  : int 1
  .. .. ..@ start  : int 1
  .. .. ..@ width  : int 5
  .. .. ..@ NAMES  : NULL
  .. .. ..@ elementType: chr "integer"
  .. .. ..@ elementMetadata: NULL
  .. .. ..@ metadata   : list()
  ..@ elementType: chr "DNAString"
  ..@ elementMetadata: NULL
  ..@ metadata   : list()


identical(seq1, seq2)

[1] FALSE

identical(s1, s2)

[1] TRUE

seq1 == seq2

[1] FALSE

s1 == s2

[1] FALSE


sessionInfo()

R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.2 LTS

locale:
 [1] LC_CTYPE=en_US.utf8   LC_NUMERIC=C
 [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8
 [5] LC_MONETARY=en_US.utf8LC_MESSAGES=en_US.utf8
 [7] LC_PAPER=en_US.utf8   LC_NAME=C
 [9] LC_ADDRESS=C  LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C

attached base packages:
[1] parallel  stats4stats graphics  grDevices utils datasets
[8] methods   base

other attached packages:
 [1] Biostrings_2.42.1  XVector_0.14.1
 [3] BBMRIomics_1.0.3   SummarizedExperiment_1.4.0
 [5] Biobase_2.34.0 GenomicRanges_1.26.4
 [7] GenomeInfoDb_1.10.3IRanges_2.8.2
 [9] S4Vectors_0.12.2   BiocGenerics_0.20.0

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.10 AnnotationDbi_1.36.2
hms_0.3
 [4] GenomicAlignments_1.10.1 zlibbioc_1.20.0
BiocParallel_1.8.1
 [7] BSgenome_1.42.0  lattice_0.20-35
R6_2.2.0
[10] httr_1.2.1   tools_3.3.2
grid_3.3.2
[13] DBI_0.6  assertthat_0.1
digest_0.6.12
[16] tibble_1.2   Matrix_1.2-8
readr_1.1.0
[19] rtracklayer_1.34.2   bitops_1.0-6
biomaRt_2.30.0
[22] RCurl_1.95-4.8   memoise_1.0.0
RSQLite_1.1-2
[25] compiler_3.3.2   GenomicFeatures_1.26.3
Rsamtools_1.26.1
[28] XML_3.98-1.5 jsonlite_1.3
VariantAnnotation_1.20.3




I don't completely understand understand why `identical` is not working
properly is it comparing the environment address in the above example they
are the same although the sequences are not? In my case the two
SummarizedExperiments contained the same DNAStringSets but had a different
environment address?

Regards,
Maarten

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list

Re: [Rd] Very hard to reproduce bug (?) in R-devel

[Winston Chang]

Small correction to my previous email: the error can also be
replicated by installing the package and then sourcing the tests. This
is slightly faster than running R CMD check. It is also how we ran the
tests with gdb. This will run the tests in a Docker container and
raise the same error. (To run outside of a Docker container, simply
leave out the first line).

  docker run --rm -ti pooltest /bin/bash
  RD CMD INSTALL pool_0.1.0.tar.gz  --install-tests
  cd /usr/local/lib/R/site-library/pool/tests
  RD -e 'source("testthat.R")'


At the suggestion of Tomas Kalibera, I ran the tests with
gctorture(TRUE). When I do this, I get three errors instead of just
one:

==
# RD -e 'gctorture(TRUE); source("testthat.R")'

R Under development (unstable) (2017-03-23 r72389) -- "Unsuffered Consequences"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> gctorture(TRUE); source("testthat.R")
1. Failure: pool: checks for leaks (named) (@test-leak-detection.R#21) -
gc() showed 0 warnings


2. Failure: pool scheduler: schedules things in the right order
(@test-scheduling.R#24)
`results` not identical to 1:3.
2/3 mismatches (average diff: 1)
[1] 2 - 1 ==  1
[2] 1 - 2 == -1


3. Failure: pool scheduler: works with pool (@test-scheduling.R#31) 
pool$counters$free not identical to 1.
1/1 mismatches
[1] 0 - 1 == -1


testthat results

OK: 199 SKIPPED: 0 FAILED: 3
1. Failure: pool: checks for leaks (named) (@test-leak-detection.R#21)
2. Failure: pool scheduler: schedules things in the right order
(@test-scheduling.R#24)
3. Failure: pool scheduler: works with pool (@test-scheduling.R#31)

Error: testthat unit tests failed
Execution halted

==




On Mon, Apr 3, 2017 at 10:34 AM, Winston Chang  wrote:
> When running R CMD check on a package, we are encountering an error on
> R-devel (as of 72457) on Linux. Unfortunately, it is very hard to
> reproduce, and almost any change to the code makes the error go away.
> I believe that this is due to a bug in R-devel, which has been present
> since at least commit 72128 (on 2017-02-06).
>
> The test error occurs when R CMD check is run on Travis CI (on Ubuntu
> 12.04.05), and locally on R-devel (on Debian testing). If we make any
> of the following changes, the error does not occur, and the test
> passes:
> - Run the test scripts from an interactive R session
> - Run on a Mac instead of Linux
> - Use R 3.3.3 or 3.2.5
> - Add code right before the tests. For example, just running gc() or
> format(1) right before the test causes it to not fail. However, adding
> very simple code like 1+1 does not affect the test (it still fails).
> - Run R CMD check with -d gdb or -d valgrind
>
> Because the test is so sensitive to any changes, we've been unable to
> track down the source of the problem. We can't be sure, but the error
> message suggests that a promise is getting evaluated with the wrong
> environment.
>
> Here's the relevant output from the tests:
> 1. Error: pool scheduler: schedules things in the right order
> (@test-scheduling.R#13)
> could not find function "task"
> 1: naiveScheduler$protect({
>scheduleTask(1000, function() {
>results <<- c(results, 3L)
>})
>scheduleTask(100, function() {
>results <<- c(results, 2L)
>})
>scheduleTask(10, function() {
>results <<- c(results, 1L)
>})
>}) at testthat/test-scheduling.R:13
> 2: private$refCount$release() at testthat/test-scheduling.R:13
> 3: private$callback()
> 4: self$protect({
>task()
>})
> 5: private$refCount$release()
> 6: private$callback()
> 7: self$protect({
>task()
>})
> 8: force(expr)
>
> You can see complete logs on Travis here:
>   https://travis-ci.org/rstudio/pool/jobs/217301804#L747-L771
>
> In the test, a re-entrant function is called (self$protect, at levels
> 4 and 7 on the call stack), and in the inner call (7), a variable,
> `task`, does not have the correct value. It should be a function, but
> it isn't; it's either NULL or some other non-function value.
>
> That code is here:
>   https://github.com/rstudio/pool/blob/f7e52a3/R/scheduler.R#L79-L81
> Note that there's a `force(task)` a couple lines above, which is
> commented out. If that is uncommented, the test passes, even though
> 

[Rd] Very hard to reproduce bug (?) in R-devel

[Winston Chang]

When running R CMD check on a package, we are encountering an error on
R-devel (as of 72457) on Linux. Unfortunately, it is very hard to
reproduce, and almost any change to the code makes the error go away.
I believe that this is due to a bug in R-devel, which has been present
since at least commit 72128 (on 2017-02-06).

The test error occurs when R CMD check is run on Travis CI (on Ubuntu
12.04.05), and locally on R-devel (on Debian testing). If we make any
of the following changes, the error does not occur, and the test
passes:
- Run the test scripts from an interactive R session
- Run on a Mac instead of Linux
- Use R 3.3.3 or 3.2.5
- Add code right before the tests. For example, just running gc() or
format(1) right before the test causes it to not fail. However, adding
very simple code like 1+1 does not affect the test (it still fails).
- Run R CMD check with -d gdb or -d valgrind

Because the test is so sensitive to any changes, we've been unable to
track down the source of the problem. We can't be sure, but the error
message suggests that a promise is getting evaluated with the wrong
environment.

Here's the relevant output from the tests:
1. Error: pool scheduler: schedules things in the right order
(@test-scheduling.R#13)
could not find function "task"
1: naiveScheduler$protect({
   scheduleTask(1000, function() {
   results <<- c(results, 3L)
   })
   scheduleTask(100, function() {
   results <<- c(results, 2L)
   })
   scheduleTask(10, function() {
   results <<- c(results, 1L)
   })
   }) at testthat/test-scheduling.R:13
2: private$refCount$release() at testthat/test-scheduling.R:13
3: private$callback()
4: self$protect({
   task()
   })
5: private$refCount$release()
6: private$callback()
7: self$protect({
   task()
   })
8: force(expr)

You can see complete logs on Travis here:
  https://travis-ci.org/rstudio/pool/jobs/217301804#L747-L771

In the test, a re-entrant function is called (self$protect, at levels
4 and 7 on the call stack), and in the inner call (7), a variable,
`task`, does not have the correct value. It should be a function, but
it isn't; it's either NULL or some other non-function value.

That code is here:
  https://github.com/rstudio/pool/blob/f7e52a3/R/scheduler.R#L79-L81
Note that there's a `force(task)` a couple lines above, which is
commented out. If that is uncommented, the test passes, even though
calling force() there shouldn't make a difference. Also, calling
`format(1)` at that location also causes the test to pass.


I've written instructions to reproduce the problem in a Docker container here:
  https://gist.github.com/wch/4cd0c56757886c63522049a32b3c294f

If you want to try reproducing the error without using Docker, I
believe if you download pool_0.1.0.tar.gz file from the
gist.github.com URL above, and run R CMD check on it, that will do it.
Some upstream dependencies will likely need to be installed; they are
listed in the code in the gist.


We also used git bisect to try to find the first commit in R where the
test would fail. The instructions for doing this are also in the gist
linked to above. It found that the first commit where the test failed
was 72128:
  
https://github.com/wch/r-source/commit/7c950ac11202cabc25b276c2f4da82226644953d

Taking a look at the changes in that commit, however, it seems very
unlikely that it caused the error. Instead, it probably just made a
change which allowed an already-existing bug to manifest.


We'd appreciate any help finding the cause of this bug!
-Winston

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

[Bioc-devel] Bioconductor 3.5 Release: db0 packages

[Obenchain, Valerie]

The new db0 packages (all version 3.4.2) are now available in the devel
repo. Let me know if you notice any problems.

Thanks.

Valerie



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] Using LaTeX packages in vignettes

[Andrzej Oleś]

Dear Roel,

to override the default \bibliographystyle{unsrt} use
`BiocStyle::latex(use.unsrturl=FALSE)` as documented in ?BiocStyle::latex

Best, Andrzej

On Mon, Apr 3, 2017 at 2:29 PM, Janssen-10, R.R.E. <
r.r.e.janssen...@umcutrecht.nl> wrote:

> Obenchain, Valerie writes:
> > Hi,
> >
> > On 03/30/2017 03:20 AM, Janssen-10, R.R.E. wrote:
> >> Hello all,
> >>
> >> We wrote our vignette in Sweave/LaTeX, and I am running into a problem
> with citing to other papers.
> >> I would like to use the APA style of citing which looks like:
> "Determine the optimal factorization rank using the
> >> NMF package (Gaujoux and Seoighe, 2010). ..."
> >>
> >> Now, to achieve that, I could use the package "apacite", but I wonder
> whether it's available on the build nodes of
> >> Bioconductor, and whether it's desired to choose our own citation
> style.  Can we choose our own citation style in
> >> vignettes? And if so, is "apacite" available on the build
> infrastructure of Bioconductor?
> >
> > apacite is included in TeXLive which is on the build machines.
> >
> > Valerie
>
> Thanks!  There's one problem left now.  I think the Bioconductor theme
> sets the \bibliographystyle to "unsrt".  I would like to add the following
> to my vignette:
> > \usepackage[natbibapa]{apacite}
> > \bibliographystyle{apacite}
>
> The problem is that there can only be a single \bibliographystyle
> definition in the TeX file:
> > Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet =
> quiet,  :
> >   Running 'texi2dvi' on 'Introduction_to_MutationalPatterns.tex' failed.
> > BibTeX errors:
> > The top-level auxiliary file: Introduction_to_MutationalPatterns.aux
> > The style file: apacite.bst
> > Illegal, another \bibstyle command---line 20 of file Introduction_to_
> MutationalPatterns.aux
> >  : \bibstyle
> >  :  {/gnu/store/87z400wdxx9ii0h2nfi8864wl0c3vs
> aq-r-biocstyle-2.2.1/site-library/BiocStyle/resources/tex/unsrturl}
>
> Do you know how I can get around this?
>
> Thanks for your time.
>
> Kind regards,
> Roel Janssen
>
> 
> --
>
> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
> uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
> ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender
> direct
> te informeren door het bericht te retourneren. Het Universitair Medisch
> Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de
> W.H.W.
> (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd
> bij
> de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
>
> Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
>
> 
> --
>
> This message may contain confidential information and ...{{dropped:10}}

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

Re: [Bioc-devel] Using LaTeX packages in vignettes

[Janssen-10, R.R.E.]

Obenchain, Valerie writes:
> Hi,
> 
> On 03/30/2017 03:20 AM, Janssen-10, R.R.E. wrote:
>> Hello all,
>>
>> We wrote our vignette in Sweave/LaTeX, and I am running into a problem with 
>> citing to other papers.
>> I would like to use the APA style of citing which looks like: "Determine the 
>> optimal factorization rank using the
>> NMF package (Gaujoux and Seoighe, 2010). ..."
>>
>> Now, to achieve that, I could use the package "apacite", but I wonder 
>> whether it's available on the build nodes of
>> Bioconductor, and whether it's desired to choose our own citation style.  
>> Can we choose our own citation style in
>> vignettes? And if so, is "apacite" available on the build infrastructure of 
>> Bioconductor?
>
> apacite is included in TeXLive which is on the build machines.
>
> Valerie

Thanks!  There's one problem left now.  I think the Bioconductor theme sets the 
\bibliographystyle to "unsrt".  I would like to add the following to my 
vignette:
> \usepackage[natbibapa]{apacite}
> \bibliographystyle{apacite}

The problem is that there can only be a single \bibliographystyle definition in 
the TeX file:
> Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  : 
>   Running 'texi2dvi' on 'Introduction_to_MutationalPatterns.tex' failed.
> BibTeX errors:
> The top-level auxiliary file: Introduction_to_MutationalPatterns.aux
> The style file: apacite.bst
> Illegal, another \bibstyle command---line 20 of file 
> Introduction_to_MutationalPatterns.aux
>  : \bibstyle
>  :  
> {/gnu/store/87z400wdxx9ii0h2nfi8864wl0c3vsaq-r-biocstyle-2.2.1/site-library/BiocStyle/resources/tex/unsrturl}

Do you know how I can get around this?

Thanks for your time.

Kind regards,
Roel Janssen

--

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.

Denk s.v.p aan het milieu voor u deze e-mail afdrukt.

--

This message may contain confidential information and is...{{dropped:11}}

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

Re: [Rd] complex NA's match(), etc: not back-compatible change proposal

[Martin Maechler]

> Suharto Anggono Suharto Anggono via R-devel 
> on Sat, 1 Apr 2017 14:10:06 + writes:

> I am raising this again.

> With
> z <- complex(real = c(0,NaN,NaN), imaginary = c(NA,NA,0)) ,
> results of
> sapply(z, match, table = z)
> and
> match(z, z)
> are different in R 3.4.0 alpha. I think they should be the same.

> I suggest changing 'cequal' in unique.c such that a
> complex number that has both NA and NaN matches NA and
> doesn't match NaN, as such complex number is printed as NA.

Thank you very much, Suharto, for the reminder.

I have committed a change to R-devel yesterday, though
your suggestion above had not been 100% clear to me.

What I think we want and I decided to commit
  r72473 | maechler | 2017-04-02 22:23:56 +0200 (Sun, 02 Apr 2017)

was to entirely mimic how R format()s and prints() complex numbers:

1) If a complex number has a real or imaginary which is NA then
   it is formatted / printed as "NA"
   ==>  All such complex numbers should match()
   i.e. match(), unique(), duplicated() treat such complex
   numbers as "the same".

2) The picture is very different with (non-NA)  NaN:
   There, R formats and prints  NaN+1i  or NaN+99i  or 0+1i*NaN
   differently, and [in R-devel only, planned in R 3.4.0 alpha
   in a day or two!]
   match(), unique(), duplicated() now treat them as different.

The change is more consistent notably does give the same result

for   match(z,z)
and   sapply(z, match, table = z)  

for a variety of z (permutations).

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

[Bioc-devel] Installing EBImage with custom packages dir?

[Guillaume MULLER]

Hi,

I've been installing EBImage several time these past months on multiple 
machines, using instructions at: 
http://bioconductor.org/packages/release/bioc/html/EBImage.html.

I've noticed a few strange things with the installer:

- When the installer installs the dependencies and one of them fails (e.g. 
"tiff" or "png", because the headers are not installed on the system), and I 
run again biocLite("EBImage"), then even the dependencies that previously 
installed successfully (I saw the "DONE (xxx)" line in the logs) are 
re-downloaded and re-installed...

- The script asks if I want to upgrade my packages. If I says yes, then the 
system-wide installation fails because I'm not root, thus the biocLite() asks 
if I want to install the packages in my "personal library". If I answer "yes", 
it installs the packages in the default personal library location 
("~/R/x86_64-pc-linux-gnu-library/3.2"), whereas I've hardcoded my personal 
library location by using (.libPaths("~/.R/x86_64-pc-linux-gnu-library/3.1.2" 
in my .Rprofile)... Also, I'm not sure the script does not takes into account 
the packages already installed installed in my personal library, thus 
redundantly (re)-installs some packages in the default location.

Is there any work-around so that I don't have to move all the (redundantly) 
installed packages into my actual personal library?

Cheers


GM
-- 
Guillaume MULLER, PhD
PRESANS - Remix Coworking - L'Appart
57 rue de Turbigo
75003 Paris
France
http://www.presans.com
http://feeds.feedburner.com/OYI/fr

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

Re: [Rd] Potential bug in utils::citation()

[Martin Maechler]

> Zhian Kamvar 
> on Sun, 2 Apr 2017 16:26:37 -0500 writes:

> Hi, I believe the function utils::citation() will fail if
> the package specified has two or more citation entries in
> the current R-devel. The following error is issued:

> 'missing' can only be used for arguments

> I have created a working example on github [0] that is
> build using R-devel on travis-ci [1]. Jim Hester has
> potentially identified [2] the source of the problem as
> being from a commit on the 27th [3, 4]. I do not have
> R-devel built on my machine, but I believe this error can
> be reproduced on the current R-devel with:

> if (require("boot") & require("utils"))
>utils::citation("boot")

Correct: it does reproduce the new bug 
and that is due to a change by me, and I had started investigation
on Friday (but not with your package and not having seen a
straighforward example yet).

This will be fixed ASAP, i.e., within hours.
Martin Maechler

> Background:

> My package poppr suddenly started failing check on R-devel
> during a weekly travis-ci job [5] due to the error
> above. Another package of mine, ezec, passed [6]. Both
> contain calls to utils::citation() within the vignettes,
> but poppr has two citations and ezec only has one (called
> from another package).

> Thanks, Zhian

> [0]: https://github.com/zkamvar/citest [1]:
> https://travis-ci.org/zkamvar/citest/jobs/217874351 [2]:
> 
https://github.com/wch/r-source/commit/7890e9e87d44f85ab76c0e786036a191eacd71d1
> [3]: https://svn.r-project.org/R/trunk@72419 [4]:
> 
https://github.com/wch/r-source/commit/7890e9e87d44f85ab76c0e786036a191eacd71d1
> [5]:
> https://travis-ci.org/grunwaldlab/poppr/jobs/216452458
> [6]: https://travis-ci.org/grunwaldlab/ezec/jobs/216452916

> -
> Zhian N. Kamvar, Ph. D.  Postdoctoral Researcher (Everhart
> Lab) Department of Plant Pathology University of
> Nebraska-Lincoln

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

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

[Bioc-devel] cbind SummarizedExperiments containing a DNAStringSet not working

[Maarten van Iterson]

Dear list,

Combining SummarizedExperiment object, containing a DNAStringSet in the
rowData seems not to work properly. If I cbind two SummarizedExperiment
objects, which I know are identical, an error is reported:

Error in FUN(X[[i]], ...) (from #2) :
  column(s) 'sourceSeq' in ‘mcols’ are duplicated and the data do not match

I think I traced the problem existing in `SummarizedExperiment:::.compare`
in that `identical` is used to compare DNAStringSets which is not behaving
as expected. Whereas it should return all identical it returns it is not!

Here is a counter example (which was easier to construct) showing that
`identical` returns FALSE where it should return TRUE.

> library(Biostrings)
> seq1 <- paste(DNA_BASES[sample(1:4,5,replace=T)], collapse="")
> seq2 <- paste(DNA_BASES[sample(1:4,5,replace=T)], collapse="")
>
> seq1
[1] "GACTC"
> seq2
[1] "GAATG"
>
> s1 <- DNAStringSet(seq1)
> s2 <- DNAStringSet(seq2)
>
> str(s1)
Formal class 'DNAStringSet' [package "Biostrings"] with 5 slots
  ..@ pool   :Formal class 'SharedRaw_Pool' [package "XVector"]
with 2 slots
  .. .. ..@ xp_list:List of 1
  .. .. .. ..$ :
  .. .. ..@ .link_to_cached_object_list:List of 1
  .. .. .. ..$ :
  ..@ ranges :Formal class 'GroupedIRanges' [package "XVector"]
with 7 slots
  .. .. ..@ group  : int 1
  .. .. ..@ start  : int 1
  .. .. ..@ width  : int 5
  .. .. ..@ NAMES  : NULL
  .. .. ..@ elementType: chr "integer"
  .. .. ..@ elementMetadata: NULL
  .. .. ..@ metadata   : list()
  ..@ elementType: chr "DNAString"
  ..@ elementMetadata: NULL
  ..@ metadata   : list()
> str(s2)
Formal class 'DNAStringSet' [package "Biostrings"] with 5 slots
  ..@ pool   :Formal class 'SharedRaw_Pool' [package "XVector"]
with 2 slots
  .. .. ..@ xp_list:List of 1
  .. .. .. ..$ :
  .. .. ..@ .link_to_cached_object_list:List of 1
  .. .. .. ..$ :

  ..@ ranges :Formal class 'GroupedIRanges' [package "XVector"]
with 7 slots
  .. .. ..@ group  : int 1
  .. .. ..@ start  : int 1
  .. .. ..@ width  : int 5
  .. .. ..@ NAMES  : NULL
  .. .. ..@ elementType: chr "integer"
  .. .. ..@ elementMetadata: NULL
  .. .. ..@ metadata   : list()
  ..@ elementType: chr "DNAString"
  ..@ elementMetadata: NULL
  ..@ metadata   : list()
>
> identical(seq1, seq2)
[1] FALSE
> identical(s1, s2)
[1] TRUE
> seq1 == seq2
[1] FALSE
> s1 == s2
[1] FALSE
>
> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.2 LTS

locale:
 [1] LC_CTYPE=en_US.utf8   LC_NUMERIC=C
 [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8
 [5] LC_MONETARY=en_US.utf8LC_MESSAGES=en_US.utf8
 [7] LC_PAPER=en_US.utf8   LC_NAME=C
 [9] LC_ADDRESS=C  LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C

attached base packages:
[1] parallel  stats4stats graphics  grDevices utils datasets
[8] methods   base

other attached packages:
 [1] Biostrings_2.42.1  XVector_0.14.1
 [3] BBMRIomics_1.0.3   SummarizedExperiment_1.4.0
 [5] Biobase_2.34.0 GenomicRanges_1.26.4
 [7] GenomeInfoDb_1.10.3IRanges_2.8.2
 [9] S4Vectors_0.12.2   BiocGenerics_0.20.0

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.10 AnnotationDbi_1.36.2
hms_0.3
 [4] GenomicAlignments_1.10.1 zlibbioc_1.20.0
BiocParallel_1.8.1
 [7] BSgenome_1.42.0  lattice_0.20-35
R6_2.2.0
[10] httr_1.2.1   tools_3.3.2
grid_3.3.2
[13] DBI_0.6  assertthat_0.1
digest_0.6.12
[16] tibble_1.2   Matrix_1.2-8
readr_1.1.0
[19] rtracklayer_1.34.2   bitops_1.0-6
biomaRt_2.30.0
[22] RCurl_1.95-4.8   memoise_1.0.0
RSQLite_1.1-2
[25] compiler_3.3.2   GenomicFeatures_1.26.3
Rsamtools_1.26.1
[28] XML_3.98-1.5 jsonlite_1.3
VariantAnnotation_1.20.3
>

I don't completely understand understand why `identical` is not working
properly is it comparing the environment address in the above example they
are the same although the sequences are not? In my case the two
SummarizedExperiments contained the same DNAStringSets but had a different
environment address?

Regards,
Maarten

[[alternative HTML version deleted]]

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

[Bioc-devel] Filter classes moved from ensembldb to AnnotationFilter

[Rainer Johannes]

Dear all,

I've just committed a change in ensembldb (version 1.99.13) that removes all 
filter classes from it and imports them from the AnnotationFilter package. This 
change will break biovizBase and ggbio (and all packages downstream of them, 
e.g. Gviz). I've already sent Michael Lawrence patches to fix both packages, 
but  there might still be some problems in the upcoming build reports I guess.

I've also contacted the developers of the TVTB and chimeraviz packages and made 
them aware of the change. Could be that there are other packages out there 
possibly affected by the change. If so, let me know and I'll assist fixing the 
problems (if needed).

cheers, jo

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