[Bioc-devel] Iterating over BSgenomeViews returns DNAString instead of BSgenomeViews

[Pariksheet Nanda]

Hi bioconductor devs,

The BSgenomeViews class has been very useful in efficiently propagating
metadata for running Biostring operations.  I noticed something unexpected
when iterating over views - it seems to return the Biostrings object
instead of a single length Views object, and thus loses the associated view
metadata.  Is this intentional?  Below is some example code, the output and
sessionInfo().  Yes, I also confirmed this happens in the development
version of R / bioconductor 3.5.

On a side note, for unit testing it's been difficult to mock a BSgenome
object due to the link to physical files, and as a workaround I use a
small, arbitrary BSgenome package.  Can one construct a BSgenome from its
package bundled extdata?  The man page examples use packaged genomes.

Code to reproduce the issue:

--
library(BSgenome)
genome <- getBSgenome("BSgenome.Hsapiens.UCSC.hg19")
gr <- GRanges(c("chr1:25001-28000", "chr2:30001-31000"))
views <- Views(genome, gr)
views
lapply(views, class)
--

Result:

--
> views
BSgenomeViews object with 2 views and 0 metadata columns:
  seqnames ranges strand   dna
 
  [1] chr1 [25001, 28000]  * [GCTTCAGCCT...TTATTTATTG]
  [2] chr2 [30001, 31000]  * [GACCCTCCTG...AGCAGGTGGT]
  ---
  seqinfo: 93 sequences (1 circular) from hg19 genome
> lapply(views, class)
[[1]]
[1] "DNAString"
attr(,"package")
[1] "Biostrings"

[[2]]
[1] "DNAString"
attr(,"package")
[1] "Biostrings"

>
--

Tested against these configurations:
1) R 3.3.2 + BSgenome 1.42.0 (stable bioconductor 3.4)
2) R 2017-04-05 installed via llnl/spack + BSgenome 1.43.7 (devel
bioconductor 3.5)

sessionInfo for configuration #2 above:
--
> sessionInfo()
R Under development (unstable) (2017-04-05 r72488)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.2 LTS

Matrix products: default
BLAS:
/share/apps/spack/opt/spack/linux-ubuntu16-x86_64/gcc-5.4.0/r-2017-04-05-4tkzhsu6sdpwmlvnv275jf6x766gwnpy/rlib/R/lib/libRblas.so
LAPACK:
/share/apps/spack/opt/spack/linux-ubuntu16-x86_64/gcc-5.4.0/r-2017-04-05-4tkzhsu6sdpwmlvnv275jf6x766gwnpy/rlib/R/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] BSgenome.Hsapiens.UCSC.hg19_1.4.0 BSgenome_1.43.7
 [3] rtracklayer_1.35.10   Biostrings_2.43.7
 [5] XVector_0.15.2GenomicRanges_1.27.23
 [7] GenomeInfoDb_1.11.10  IRanges_2.9.19
 [9] S4Vectors_0.13.15 BiocGenerics_0.21.3

loaded via a namespace (and not attached):
 [1] zlibbioc_1.21.0GenomicAlignments_1.11.12
 [3] BiocParallel_1.9.5 lattice_0.20-35
 [5] tools_3.5.0SummarizedExperiment_1.5.7
 [7] grid_3.5.0 Biobase_2.35.1
 [9] matrixStats_0.52.1 Matrix_1.2-9
[11] GenomeInfoDbData_0.99.0bitops_1.0-6
[13] RCurl_1.95-4.8 DelayedArray_0.1.7
[15] compiler_3.5.0 Rsamtools_1.27.15
[17] XML_3.98-1.6
> BiocInstaller::biocValid()
[1] TRUE
>

---
Pariksheet Nanda
PhD Candidate in Genetics and Genomics
System Administrator, Storrs HPC Cluster
University of Connecticut

[[alternative HTML version deleted]]

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

[Bioc-devel] Bioconductor 3.5 release: db0, OrgDb and TxDb packages

[Obenchain, Valerie]

Hi,

The new db0, OrgDb and TxDb packages are now available in the devel branch.

# db0:

Updated all 19:

anopheles.db0_3.4.2.tar.gz
chicken.db0_3.4.2.tar.gz
fly.db0_3.4.2.tar.gz
pig.db0_3.4.2.tar.gz
xenopus.db0_3.4.2.tar.gz
arabidopsis.db0_3.4.2.tar.gz
chimp.db0_3.4.2.tar.gz
human.db0_3.4.2.tar.gz
rat.db0_3.4.2.tar.gz
yeast.db0_3.4.2.tar.gz
bovine.db0_3.4.2.tar.gz
ecoliK12.db0_3.4.2.tar.gz
malaria.db0_3.4.2.tar.gz
rhesus.db0_3.4.2.tar.gz
zebrafish.db0_3.4.2.tar.gz
canine.db0_3.4.2.tar.gz
ecoliSakai.db0_3.4.2.tar.gz
mouse.db0_3.4.2.tar.gz
worm.db0_3.4.2.tar.gz


# OrgDb:

Updated all 19:

org.Ce.eg.db_3.4.1.tar.gz
org.EcK12.eg.db_3.4.1.tar.gz
org.Mm.eg.db_3.4.1.tar.gz
org.Rn.eg.db_3.4.1.tar.gz
org.Ag.eg.db_3.4.1.tar.gz
org.Cf.eg.db_3.4.1.tar.gz
org.EcSakai.eg.db_3.4.1.tar.gz
org.Mmu.eg.db_3.4.1.tar.gz
org.Sc.sgd.db_3.4.1.tar.gz
org.At.tair.db_3.4.1.tar.gz
org.Dm.eg.db_3.4.1.tar.gz
org.Gg.eg.db_3.4.1.tar.gz
org.Pf.plasmo.db_3.4.1.tar.gz
org.Ss.eg.db_3.4.1.tar.gz
org.Bt.eg.db_3.4.1.tar.gz
org.Dr.eg.db_3.4.1.tar.gz
org.Hs.eg.db_3.4.1.tar.gz
org.Pt.eg.db_3.4.1.tar.gz
org.Xl.eg.db_3.4.1.tar.gz


# TxDb:

Added 1 new package:

TxDb.Ggallus.UCSC.galGal5.refGene_3.4.0.tar.gz

Updated 4 active tracks:

TxDb.Celegans.UCSC.ce11.refGene_3.4.1.tar.gz
TxDb.Rnorvegicus.UCSC.rn5.refGene_3.4.1.tar.gz
TxDb.Dmelanogaster.UCSC.dm6.ensGene_3.4.1.tar.gz 
TxDb.Rnorvegicus.UCSC.rn6.refGene_3.4.1.tar.gz


# Updated PFAM and GO:

PFAM.db_3.4.1.tar.gz
GO.db_3.4.1.tar.gz


I found what appear to be 2 abandoned OrgDb packages,
org.Tgondii.eg.db_1.0.tar.gz and org.Sco.eg.db_2.4.2.tar.gz. It looks
like these were last updated in October 2015. I've emailed the authors
but one bounced the other hasn't responded. Given that the OrgDb data
are a snapshot in time vs tied to a genome build it's important to
regenerate these every 6 months. If I don't hear back from the authors
I'll remove these from the repo.

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: [Rd] Very hard to reproduce bug (?) in R-devel

[Winston Chang]

>
> Also my suspicion, can you try without having JIT enabled?
>

The results for different JIT levels. I ran compiler::enableJIT() before
sourcing the test file:
3: error
2: error
1: OK
0: OK

-Winston

[[alternative HTML version deleted]]

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

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

[Winston Chang]

>
> Apologies in advance if this is just stating the obvious, but let me try
> and put some general ideas  on the table.


These are great ideas, thanks.



> - is anything non-deterministic involved? (Doesn't sound so, but...)
>

There was an environment where items were added, and the names of the items
had timestamps. However, I just modified that code to use deterministic
names and the error still happened.


- could it be something with the bytecompiler?
>

I've tried two things. The first was to install the pool package with
--no-byte-compile. In this case the error still happens.

The second was to compile R with `./configure
--enable-byte-compiled-packages=no`.
When I do this, the error does NOT happen. I've tried varying the pool code
in a few different ways to try to provoke the error, but I have not been
able to get it to happen. So it is possible that the compiled base R
packages play some part here.



> - can you get something (_anything_) to trigger the bug (in any variant)
> when running R under gdb? I'm thinking gctorture() etc.
>

Some variations of the code will error without gdb, but will not error with
gdb. I twiddled with the code a bit and now the current version of the code
(f97cfdf) will error under gdb.

I've also run it with gctorture(T) and have not seen this error with that
enabled, but I haven't tested it extensively in this mode. (In a previous
email I mentioned that with gctorture on, I got three different errors in
the tests. I later found that these errors were due to tests having
incorrect assumptions. For example, one test called gc() and expected a
warning, but it incorrectly assumed that a GC event would not have occurred
slightly earlier.)



> - it is odd that you cannot immediately get the same behaviour with R -d
> gdb or valgrind. Are you sure you are actually running the same script in
> the same way?
>

Some versions of the code, but not all, will give the same error under gdb
and valgrind. See above.



> - if you can get a hold of something inside gdb, then there should be some
> potential for backtracking using hardware watchpoints and such. As in: This
> memory location doesn't contain the value I expected; what changed it?
>

I probably don't know enough about R internals or gdb to be useful here.
But if someone wants to try it out, reproducing it as simple as copying and
pasting the first two blocks of code from the README here (assuming you
have Docker installed):
  https://gist.github.com/wch/2596a1c9f1bcdee91bb210c782141c88
It will build a Docker image with the appropriate software installed, and
then run the tests. The README also shows how to run it with gdb.

-Winston

[[alternative HTML version deleted]]

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

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

[Uwe Ligges]

On 05.04.2017 23:54, peter dalgaard wrote:



On 05 Apr 2017, at 20:40 , Winston Chang  wrote:

I think there's a good chance that this is due to a bug in R. I have
been trying to track down the cause of the problem but haven't been
able find it.

-Winston


Apologies in advance if this is just stating the obvious, but let me try and 
put some general ideas  on the table.

- is anything non-deterministic involved? (Doesn't sound so, but...)
- could it be something with the bytecompiler?


Also my suspicion, can you try without having JIT enabled?

Best,
Uwe Ligges




- can you get something (_anything_) to trigger the bug (in any variant) when 
running R under gdb? I'm thinking gctorture() etc.
- it is odd that you cannot immediately get the same behaviour with R -d gdb or 
valgrind. Are you sure you are actually running the same script in the same way?
- if you can get a hold of something inside gdb, then there should be some 
potential for backtracking using hardware watchpoints and such. As in: This 
memory location doesn't contain the value I expected; what changed it?

-pd




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

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

[peter dalgaard]

> On 05 Apr 2017, at 20:40 , Winston Chang  wrote:
> 
> I think there's a good chance that this is due to a bug in R. I have
> been trying to track down the cause of the problem but haven't been
> able find it.
> 
> -Winston

Apologies in advance if this is just stating the obvious, but let me try and 
put some general ideas  on the table.

- is anything non-deterministic involved? (Doesn't sound so, but...)
- could it be something with the bytecompiler?
- can you get something (_anything_) to trigger the bug (in any variant) when 
running R under gdb? I'm thinking gctorture() etc.
- it is odd that you cannot immediately get the same behaviour with R -d gdb or 
valgrind. Are you sure you are actually running the same script in the same way?
- if you can get a hold of something inside gdb, then there should be some 
potential for backtracking using hardware watchpoints and such. As in: This 
memory location doesn't contain the value I expected; what changed it?

-pd


-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

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

[Winston Chang]

Hi Dirk, I sent another message just before yours, so you may not have seen
it:

===

I just tried recompiling R with no -O flag, and I still get the same error.
Here are the CFLAGS (the RD program runs R-devel instead of R 3.3.3):

# RD CMD config CFLAGS
-g -fdebug-prefix-map=/build/r-base-3.3.3=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g

===

Additionally, I tried again with the rocker/r-devel-san image, and got the
same error. There was no other output from the sanitizers. In this
container:

# RD CMD config CFLAGS
-pipe -Wall -pedantic -O2 -mtune=native -fsanitize=address

The output looks like this (it should be in order --1--, --2--, --3--,
repeat):
20170405-213410.095858-18 20170405-213420.085451-17
20170405-213550.084947-16 --1--
20170405-213410.095858-18 20170405-213420.085451-17
20170405-213550.084947-16 --1--
20170405-213410.095858-18 20170405-213420.085451-17
20170405-213550.084947-16 --2--
20170405-213410.095858-18 --3--
20170405-213420.085451-17 20170405-213550.084947-16 --1--
20170405-213420.085451-17 20170405-213550.084947-16 --2--
20170405-213420.085451-17 --3--
20170405-213550.084947-16 --1--
20170405-213550.084947-16 --2--
20170405-213550.084947-16 --3--
 --2--
20170405-213410.095858-18 --3--
1. Error: pool scheduler: schedules things in the right order
(@test-scheduling.R#13)
could not find function "task"
1: naiveScheduler$protect({
   scheduleTask(1e+05, function() {
   results <<- c(results, 3L)
   })
   scheduleTask(1, 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()

-Winston


On Wed, Apr 5, 2017 at 4:32 PM, Dirk Eddelbuettel <e...@debian.org> wrote:

>
> On 5 April 2017 at 15:46, Winston Chang wrote:
> | On Wed, Apr 5, 2017 at 2:24 PM, Robert McGehee <
> rmcge...@walleyetrading.net>
> | wrote:
> |
> | > Winston,
> | > I had a similar experience to you tracking down an insanely difficult
> bug
> | > in my R code that "disappeared" whenever slight changes were made to
> the
> | > script (e.g. like adding cat() statements). In my case, it coincided
> with
> | > my over-eager compilation of R and its library stack, as I was also
> | > experimenting with a cutting edge version of the gcc compiler as well
> as
> | > what I thought were innocuous performance enhancing CFLAGS like
> -O3/-Ofast
> | > -march=native. After downgrading gcc and recompiling everything (R and
> | > BLAS) without the extra flags, the problem went away. Not saying this
> is
> | > your problem, just sharing my similar experience.
> | >
> | >
> | Thanks Robert. I'm glad that I'm not the only one who's encountered an
> | issue like this. "Insanely difficult" is an apt description. :)
> |
> | I've been using the rocker/r-devel for testing. It compiles R with the
> | following CFLAGS:
> |   -g -O2 -fdebug-prefix-map=/build/r-base-3.3.3=.
> -fstack-protector-strong
> | -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g
> | It looks like it gets those settings from running R CMD config CFLAGS
> with
> | the already-installed version of R (3.3.3) which comes from a .deb
> package.
> |   https://github.com/rocker-org/rocker/blob/master/r-devel/
> Dockerfile#L76
>
> That's a Debian default a Policy-conforming offical package must use.
>
> For Docker you get these from the (prebuild) .deb package, you get it when
> you do r-devel by hand as they come back in via R CMD CONFIG:
>
>   https://github.com/rocker-org/rocker/blob/master/r-devel/
> Dockerfile#L76-L77
>
> You could undo those two lines / set CFLAGS and CXXFLAGS by hand.
>
> | I've also compiled R (again, in Docker) and tested with that, and gotten
> | the same results. It basically uses just `./configure
> | --without-recommended-packages`
> | and then `make`.
>
> Then these options should not come in.  But are you saying that the
> Heisenbug
> behaviour happens irrespective of the compilation flags?
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

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

[Dirk Eddelbuettel]

On 5 April 2017 at 15:46, Winston Chang wrote:
| On Wed, Apr 5, 2017 at 2:24 PM, Robert McGehee 
| wrote:
| 
| > Winston,
| > I had a similar experience to you tracking down an insanely difficult bug
| > in my R code that "disappeared" whenever slight changes were made to the
| > script (e.g. like adding cat() statements). In my case, it coincided with
| > my over-eager compilation of R and its library stack, as I was also
| > experimenting with a cutting edge version of the gcc compiler as well as
| > what I thought were innocuous performance enhancing CFLAGS like -O3/-Ofast
| > -march=native. After downgrading gcc and recompiling everything (R and
| > BLAS) without the extra flags, the problem went away. Not saying this is
| > your problem, just sharing my similar experience.
| >
| >
| Thanks Robert. I'm glad that I'm not the only one who's encountered an
| issue like this. "Insanely difficult" is an apt description. :)
| 
| I've been using the rocker/r-devel for testing. It compiles R with the
| following CFLAGS:
|   -g -O2 -fdebug-prefix-map=/build/r-base-3.3.3=. -fstack-protector-strong
| -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g
| It looks like it gets those settings from running R CMD config CFLAGS with
| the already-installed version of R (3.3.3) which comes from a .deb package.
|   https://github.com/rocker-org/rocker/blob/master/r-devel/Dockerfile#L76

That's a Debian default a Policy-conforming offical package must use.

For Docker you get these from the (prebuild) .deb package, you get it when
you do r-devel by hand as they come back in via R CMD CONFIG:

  https://github.com/rocker-org/rocker/blob/master/r-devel/Dockerfile#L76-L77

You could undo those two lines / set CFLAGS and CXXFLAGS by hand.
 
| I've also compiled R (again, in Docker) and tested with that, and gotten
| the same results. It basically uses just `./configure
| --without-recommended-packages`
| and then `make`.

Then these options should not come in.  But are you saying that the Heisenbug
behaviour happens irrespective of the compilation flags?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

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

[Winston Chang]

, magrittr, crayon), only testthat contains compiled
> code, and it is pretty minimal. The only compiled code in testthat
> that should be executed is a function that finds a label -- but that
> happens only after an error occurs.
>
> This is the sessionInfo():
> R Under development (unstable) (2017-03-23 r72389)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Debian GNU/Linux 9 (stretch)
>
> Matrix products: default
> BLAS: /usr/local/lib/R/lib/libRblas.so
> LAPACK: /usr/local/lib/R/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] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] pool_0.1.0 DBI_0.6-1  testthat_1.0.2
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.0 magrittr_1.5   R6_2.2.0   crayon_1.3.2
>
>
> I have spent days trying to make a minimal example, and that is the
> best that I have been able to do so far. I would not involve all this
> complexity if I could avoid it. The problem is that the behavior is
> extremely sensitive to any changes. Seemingly-innocuous things like
> removing other tests, or adding a cat() statement can make the error
> disappear, or in some cases it makes ls() return values from a
> different (previous) iteration of the loop.
>
>
> In my testing, I have also seen a case where calls to `cat( ... ,
> file=stderr())` result in output that has the wrong order. I don't
> know if that's due to the cat() calls being executed in the wrong
> order, or if it's simply being printed or buffered in the wrong order.
>
> This is the code in question that cat()s to stderr:
> https://github.com/rstudio/pool/blob/0724ad9/R/scheduler.R#L74-L90
>   while (TRUE) {
> tasks <- sort(ls(private$scheduledTasks))
> if (length(tasks) == 0) break
> t <- tasks[[1]]
>
> s <- stderr()
> cat(tasks, "--1--\n", file = s)
> cat(ls(private$scheduledTasks), "--2--\n", file = s)
> cat(t, "--3--\n", file = s)
>
> task <- private$scheduledTasks[[t]]
> rm(list = t, envir = private$scheduledTasks)
>
> task()
>   }
>
> Without going into too much detail, it should print lines of text that
> end with --1--, --2--, --3--, and repeat. Here's what it prints
> instead when running the tests:
>
> 20170405-182549.466875-18 20170405-182559.456628-17
> 20170405-182729.456318-16 --1--
> 20170405-182549.466875-18 20170405-182559.456628-17
> 20170405-182729.456318-16 --1--
> 20170405-182549.466875-18 20170405-182559.456628-17
> 20170405-182729.456318-16 --2--
> 20170405-182549.466875-18 --3--
> 20170405-182559.456628-17 20170405-182729.456318-16 --1--
> 20170405-182559.456628-17 20170405-182729.456318-16 --2--
> 20170405-182559.456628-17 --3--
> 20170405-182729.456318-16 --1--
> 20170405-182729.456318-16 --2--
> 20170405-182729.456318-16 --3--
>  --2--
> 20170405-182549.466875-18 --3--
> 1. Error: pool scheduler: schedules things in the right order
> (@test-scheduling.R#13)
> could not find function "task"
> 1: naiveScheduler$protect({
>scheduleTask(1e+05, function() {
>results <<- c(results, 3L)
>})
>scheduleTask(1, 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()
>
> It's almost as though, in the middle of the first iteration of the
> while loop, R jumps to the next iteration of the loop, runs the loop a
> couple of times to completion, and then returns to the first iteration
> of the loop at the place that it left.
>
> This can be reproduced by following the instructions in this gist:
>   https://gist.github.com/wch/2596a1c9f1bcdee91bb210c782141c88
>
> Almost any change to the code will make the error disappear, or change
> to a different one.
>
>
> With regard to reproducing it in "base" R: I made a simple example
> using just R (no other packages) that does something similar to what
> happens in the tests, but even when I run it for 100,000 iterations,
> the error doesn't occur.
>
> I think there's a good chance that this is due to a bug in R. I have
> been trying to track down the cause of the problem but haven't been
> able find it.
>
> -Winston
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

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

[Winston Chang]

On Wed, Apr 5, 2017 at 2:24 PM, Robert McGehee 
wrote:

> Winston,
> I had a similar experience to you tracking down an insanely difficult bug
> in my R code that "disappeared" whenever slight changes were made to the
> script (e.g. like adding cat() statements). In my case, it coincided with
> my over-eager compilation of R and its library stack, as I was also
> experimenting with a cutting edge version of the gcc compiler as well as
> what I thought were innocuous performance enhancing CFLAGS like -O3/-Ofast
> -march=native. After downgrading gcc and recompiling everything (R and
> BLAS) without the extra flags, the problem went away. Not saying this is
> your problem, just sharing my similar experience.
>
>
Thanks Robert. I'm glad that I'm not the only one who's encountered an
issue like this. "Insanely difficult" is an apt description. :)

I've been using the rocker/r-devel for testing. It compiles R with the
following CFLAGS:
  -g -O2 -fdebug-prefix-map=/build/r-base-3.3.3=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g
It looks like it gets those settings from running R CMD config CFLAGS with
the already-installed version of R (3.3.3) which comes from a .deb package.
  https://github.com/rocker-org/rocker/blob/master/r-devel/Dockerfile#L76


I've also compiled R (again, in Docker) and tested with that, and gotten
the same results. It basically uses just `./configure
--without-recommended-packages`
and then `make`.

[[alternative HTML version deleted]]

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

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

[Robert McGehee]

 graphics  grDevices utils datasets  methods   base

other attached packages:
[1] pool_0.1.0 DBI_0.6-1  testthat_1.0.2

loaded via a namespace (and not attached):
[1] compiler_3.5.0 magrittr_1.5   R6_2.2.0   crayon_1.3.2


I have spent days trying to make a minimal example, and that is the
best that I have been able to do so far. I would not involve all this
complexity if I could avoid it. The problem is that the behavior is
extremely sensitive to any changes. Seemingly-innocuous things like
removing other tests, or adding a cat() statement can make the error
disappear, or in some cases it makes ls() return values from a
different (previous) iteration of the loop.


In my testing, I have also seen a case where calls to `cat( ... ,
file=stderr())` result in output that has the wrong order. I don't
know if that's due to the cat() calls being executed in the wrong
order, or if it's simply being printed or buffered in the wrong order.

This is the code in question that cat()s to stderr:
https://github.com/rstudio/pool/blob/0724ad9/R/scheduler.R#L74-L90
  while (TRUE) {
tasks <- sort(ls(private$scheduledTasks))
if (length(tasks) == 0) break
t <- tasks[[1]]

s <- stderr()
cat(tasks, "--1--\n", file = s)
cat(ls(private$scheduledTasks), "--2--\n", file = s)
cat(t, "--3--\n", file = s)

    task <- private$scheduledTasks[[t]]
rm(list = t, envir = private$scheduledTasks)

task()
  }

Without going into too much detail, it should print lines of text that
end with --1--, --2--, --3--, and repeat. Here's what it prints
instead when running the tests:

20170405-182549.466875-18 20170405-182559.456628-17
20170405-182729.456318-16 --1--
20170405-182549.466875-18 20170405-182559.456628-17
20170405-182729.456318-16 --1--
20170405-182549.466875-18 20170405-182559.456628-17
20170405-182729.456318-16 --2--
20170405-182549.466875-18 --3--
20170405-182559.456628-17 20170405-182729.456318-16 --1--
20170405-182559.456628-17 20170405-182729.456318-16 --2--
20170405-182559.456628-17 --3--
20170405-182729.456318-16 --1--
20170405-182729.456318-16 --2--
20170405-182729.456318-16 --3--
 --2--
20170405-182549.466875-18 --3--
1. Error: pool scheduler: schedules things in the right order
(@test-scheduling.R#13)
could not find function "task"
1: naiveScheduler$protect({
   scheduleTask(1e+05, function() {
   results <<- c(results, 3L)
   })
   scheduleTask(1, 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()

It's almost as though, in the middle of the first iteration of the
while loop, R jumps to the next iteration of the loop, runs the loop a
couple of times to completion, and then returns to the first iteration
of the loop at the place that it left.

This can be reproduced by following the instructions in this gist:
  https://gist.github.com/wch/2596a1c9f1bcdee91bb210c782141c88

Almost any change to the code will make the error disappear, or change
to a different one.


With regard to reproducing it in "base" R: I made a simple example
using just R (no other packages) that does something similar to what
happens in the tests, but even when I run it for 100,000 iterations,
the error doesn't occur.

I think there's a good chance that this is due to a bug in R. I have
been trying to track down the cause of the problem but haven't been
able find it.

-Winston

__
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

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

[Winston Chang]

)

On Wed, Apr 5, 2017 at 2:59 AM, Martin Maechler
<maech...@stat.math.ethz.ch> wrote:
>
> >>>>> Winston Chang <winstoncha...@gmail.com>
> >>>>> on Tue, 4 Apr 2017 15:29:40 -0500 writes:
>
> > I've done some more investigation into the problem, and it is very
> > difficult to pin down. What it looks like is happening is roughly like 
> this:
> > - `p` is an environment and `p$e` is also an environment.
> > - There is a loop. In each iteration, it looks for one item in `p$e`, 
> saves
> > it in a variable `x`, then removes that item from `p$e`. Then it invokes
> > `x()`. The loop runs again, until there are no more items in `p$e`.
>
> > The problem is that `ls(p$e)` sometimes returns the wrong values -- it
> > returns the values that it had in previous iterations of the loop. The
> > behavior is very touchy. Almost any change to the code will slightly 
> change
> > the behavior; sometimes the `ls()` returns values from a different
> > iteration of the loop, and sometimes the problem doesn't happen at all.
>
> > I've put a  Dockerfile and instructions for reproducing the problem 
> here:
> > https://gist.github.com/wch/2596a1c9f1bcdee91bb210c782141c88
>
> > I think that I've gotten about as far with this as I can, though I'd be
> > happy to provide more information if anyone wants to take look at the
> > problem.
>
> Dear Winston,
>
> While I agree this may very well be a bug in R(-devel), and hence
> also R in 3.4.0 alpha and hence quite important to be dealt with,
>
> your code still involves 3 non-trivial  packages (DBI, R6,
> testthat) some of which have their own C code and notably load
> a couple of other package's namespaces.
> We've always made a point
>   https://www.r-project.org/bugs.html
> that bugs in R should be reproducible without extra
> packages... and I think it would definitely help to pinpoint the
> issue to be seen outside of your extra packages' world.
>
> Or have you been aware of that and are just asking for help
> finding a bug in one of the extra packages involved, a bug that might only be 
> triggered by recent changes in R ?
>
> OTOH, what you describe above  (p ; p$e ; p$e$x ...)
> should be reproducible in pure "base" R code, right?
>
> I'm sorry not to be of more help
> Martin


Of the four packages that are loaded when running the tests (pool,
DBI, R6, testthat, magrittr, crayon), only testthat contains compiled
code, and it is pretty minimal. The only compiled code in testthat
that should be executed is a function that finds a label -- but that
happens only after an error occurs.

This is the sessionInfo():
R Under development (unstable) (2017-03-23 r72389)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

Matrix products: default
BLAS: /usr/local/lib/R/lib/libRblas.so
LAPACK: /usr/local/lib/R/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] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] pool_0.1.0 DBI_0.6-1  testthat_1.0.2

loaded via a namespace (and not attached):
[1] compiler_3.5.0 magrittr_1.5   R6_2.2.0   crayon_1.3.2


I have spent days trying to make a minimal example, and that is the
best that I have been able to do so far. I would not involve all this
complexity if I could avoid it. The problem is that the behavior is
extremely sensitive to any changes. Seemingly-innocuous things like
removing other tests, or adding a cat() statement can make the error
disappear, or in some cases it makes ls() return values from a
different (previous) iteration of the loop.


In my testing, I have also seen a case where calls to `cat( ... ,
file=stderr())` result in output that has the wrong order. I don't
know if that's due to the cat() calls being executed in the wrong
order, or if it's simply being printed or buffered in the wrong order.

This is the code in question that cat()s to stderr:
https://github.com/rstudio/pool/blob/0724ad9/R/scheduler.R#L74-L90
  while (TRUE) {
tasks <- sort(ls(private$scheduledTasks))
if (length(tasks) == 0) break
t <- tasks[[1]]

s <- stderr()
cat(tasks, "--1--\n", file = s)
cat(ls(private$scheduledTasks), "--2--\n", file = s)
cat(t, "--3--\n", file = s)

    task <- private$scheduledTasks[[t]]
    rm(list = t, envir = pri

[Bioc-devel] Using R Markdown for creating reproducible manuscripts – new blog post from eLife Labs

[Emily Packer]

[With apologies for cross-posting]

Hi all,

We have today published a blog post on eLife Labs about how scientists can
use the dynamic document language, R Markdown, for creating reproducible
manuscripts.

At eLife, we aim to make the communication of results more beneficial for
the scientific community as a whole, by operating a platform for presenting
research that encourages and recognises the most responsible behaviours in
science. These ‘responsible behaviours’ include the reproducibility of
research results, which is a cornerstone of science. For example, the
development of new drugs and medical treatments relies on the ability to
replicate the results of preclinical research.

Chris Hartgerink, a metascience researcher at Tilburg University, the
Netherlands, describes how R Markdown provides a simple solution for
creating reproducible manuscripts here: https://elifesciences.org/
elife-news/composing-reproducible-manuscripts-using-r-markdown?utm_source=
Labs_campaign=Bioconductor

If you’d like more information, please don’t hesitate to contact me.

Kind regards,

Emily

-- 

*eLife's early-career researcher travel grants 2017 are now open for
applications.
Visit 
https://elifesciences.org/elife-news/inside-elife-2017-travel-grants-early-career-researchers-now-open-applications
.*


Emily Packer
Press Officer

+44 1223 855373 (office)

http://elifesciences.org

eLife Sciences Publications, Ltd is a limited liability non-profit
non-stock corporation incorporated in the State of Delaware, USA, with
company number 5030732, and is registered in the UK with company number
FC030576 and branch number BR015634 at the address First Floor, 24 Hills
Road, Cambridge CB2 1JP.

[[alternative HTML version deleted]]

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

[Bioc-devel] Commiting from git to svn

[Lluís Revilla]

Dear all,

Short problem: I am a trying to sync my new package BioCor git repository
with the Bioconductor svn repository. But I am failing when I do git svn
dcommit.

Long history of the problem
I did some changes on my master branch (where I developed until now) then I
used the update_remotes.sh which created a new branch.
I changed to that branch (git checkout devel), changed its name (git branch
-m devel bioc/devel) and used (git svn rebase) following the instructions.
I brought the changes by merging the branches (git merge master)and wanted
to push it to the svn server with (git svn dcommit --add-author-from) .
As expected I had some merge conflicts (apparently originated because the
initial commit to that repository wasn't with the code I submitted)
I skipped them (git rebase --skip) until it ended the rebase at the moment
I am only with the changes I performed after submitting the package, as
compared with the Bioconductor-mirror (previously the branch was ahead of
'bioc/master' by 173 commits):
git status
Your branch is ahead of 'bioc/master' by 11 commits.

However when I try to sync and commit with svn I can't (BTW it wasn't clear
to me how to add my username for git svn repository otherwise I am prompted
with tue username of my machine, so maybe it is still wrong):

git svn dcommit --add-author-from --username l.revilla

Authentication realm:  The bioconductor
Subversion Repository
Password for 'l.revilla':

ERROR from SVN:
URL access forbidden for unknown reason: POST of '/bioconductor/!svn/me':
403 Forbidden (https://hedgehog.fhcrc.org)
W: 3d12099bda0c61d0a63a787ebb9cbe3b2e06770d and refs/remotes/svn differ,
using rebase:
:04 04 985b6b2986a31a3eff4161563a5585ea10467787
c8d818d0ed3196d391f914996dd26354004df665 MR
:100644 00 8e2bef6bf185b9bbc9da7e500bdb394396ccad99
 Dbio_cor.R
:04 04 ed161436ea9089f70f74f2e1ea79e53a796eed5b
378a5b97d68ecfa7430bebdaba2c5b6540e6051e Mman
:04 04 65b109ed754cd8aa35a2fcaceea8c05fdbe91899
594d15d7838d2096afda7b5697242e48bb7fce42 Mtests
:04 04 474a6a48c23f1bce377071b58e0b87f161b2a5cf
6be3cd535391595a962f610dad103e88b2fc32bd Mvignettes
Current branch bioc/devel is up to date.
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.


How can I push the new commits to the svn repository?

Many thanks!

Lluís

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Check error on malbec2

[Aimin Yan]

Yes, it is.

Aimin

On Wed, Apr 5, 2017 at 7:20 AM, Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> Are these permanent system files or files that are created during
> examples/vignettes?
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Aimin Yan 
> *Sent:* Tuesday, April 4, 2017 3:41:02 PM
> *To:* Shepherd, Lori
> *Cc:* bioc-devel@r-project.org
> *Subject:* Re: [Bioc-devel] Check error on malbec2
>
> Thank you, I changed to use tempdir(), and it works now.
> One more question is how to locate those outputs in temporary directory since
> I want users to use those outputs.
>
> Aimin
>
> On Tue, Apr 4, 2017 at 2:00 PM, Shepherd, Lori <
> lori.sheph...@roswellpark.org> wrote:
>
>> Write and access your output to a temporary directory instead using
>> tempdir().
>>
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Cancer Institute
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>> --
>> *From:* Bioc-devel  on behalf of Aimin
>> Yan 
>> *Sent:* Tuesday, April 4, 2017 1:45:28 PM
>> *To:* bioc-devel@r-project.org
>> *Subject:* [Bioc-devel] Check error on malbec2
>>
>> In the package I am trying ti submit to bioconductor, I got the following
>> error for check.
>>
>> Warning in dir.create(output.file.dir) :
>>   cannot create dir '/home/pkgbuild/OutputEnmap', reason 'Permission
>> denied'
>> Warning in file(file, ifelse(append, "a", "w")) :
>>   cannot open file '/home/pkgbuild/OutputEnmap/enrichmap_GO.xls': No such
>> file or directory
>> Error in file(file, ifelse(append, "a", "w")) :
>>   cannot open the connection
>> Calls: enrichmentmap -> write.table -> file
>>
>> It seems I do not have permission to create a directory.
>> Does anyone know how to fix this check error?
>>
>>
>> Thanks,
>> Aimin
>>
>> [[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.
>
>
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Check error on malbec2

[Shepherd, Lori]

Are these permanent system files or files that are created during 
examples/vignettes?


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Aimin Yan 
Sent: Tuesday, April 4, 2017 3:41:02 PM
To: Shepherd, Lori
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Check error on malbec2

Thank you, I changed to use tempdir(), and it works now.
One more question is how to locate those outputs in temporary directory since I 
want users to use those outputs.

Aimin

On Tue, Apr 4, 2017 at 2:00 PM, Shepherd, Lori 
> wrote:

Write and access your output to a temporary directory instead using tempdir().



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
> on 
behalf of Aimin Yan >
Sent: Tuesday, April 4, 2017 1:45:28 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Check error on malbec2

In the package I am trying ti submit to bioconductor, I got the following
error for check.

Warning in dir.create(output.file.dir) :
  cannot create dir '/home/pkgbuild/OutputEnmap', reason 'Permission denied'
Warning in file(file, ifelse(append, "a", "w")) :
  cannot open file '/home/pkgbuild/OutputEnmap/enrichmap_GO.xls': No such
file or directory
Error in file(file, ifelse(append, "a", "w")) :
  cannot open the connection
Calls: enrichmentmap -> write.table -> file

It seems I do not have permission to create a directory.
Does anyone know how to fix this check error?


Thanks,
Aimin

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



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: [Rd] Bug report: POSIX regular expression doesn't match for somewhat higher values of upper bound

[Martin Maechler]

>   
> on Tue, 4 Apr 2017 08:45:30 + writes:

> Dear Sirs,
> while

>> regexpr('(.{1,2})\\1', 'foo')
> [1] 2
> attr(,"match.length")
> [1] 2
> attr(,"useBytes")
> [1] TRUE

> yields the correct match, an incremented upper bound in

>> regexpr('(.{1,3})\\1', 'foo')
> [1] -1
> attr(,"match.length")
> [1] -1
> attr(,"useBytes")
> [1] TRUE

> incorrectly yields no match.

Hmm, yes, I would also say that this is incorrect
(though I'm always cautious: The  ?regex  help page explicitly
 mentions greedy repetitions, and these can "bite you" ..)

The behavior is also different from the  perl=TRUE one which is
correct (according to the above understanding).

Using  grep() instead of regexpr() makes the behavior easier to parse.
The following code 
--

tx <- c("ab","abc", paste0("foo", c("", "b", "o", "bar", "oofy")))
setNames(nchar(tx), tx)
## ab abc foofoobfooo  foobar ffy
##  2   3   3   4   4   6   7

grep1r <- function(n, txt, ...) {
pattern <- paste0('(.{1,',n,'})\\1', collapse="") ## can have empty n
ans <- grep(pattern, txt, value=TRUE, ...)
cat(sprintf("pattern '%s' : ", pattern)); print(ans, quote=FALSE)
invisible(ans)
}

grep1r({}, tx)# '.{1,}' : because of _greedy_ matching there is __no__ 
repetiion!
grep1r(100,tx)# i.e., these both give an empty match :  character(0)

## matching at most once:
grep1r(1, tx)# matches all 5 starting with "foo"
grep1r(2, tx)# ditto: all have more than 2 chars
grep1r(3, tx)# not "foo": those with more than 3 chars
grep1r(4, tx)# .. those with more than 4 characters
grep1r(5, tx)# .. those with more than 5 characters
grep1r(6, tx)# .. those with more than 6 characters
grep1r(7, tx)# NONE (= those with more than 7 characters)

for(p in c(FALSE,TRUE)) {
cat("\ngrep(*, perl =", p, ") :\n")
for(n in c(list(NULL), 1:7))
grep1r(n, tx, perl = p)
}

--

ends with

> for(p in c(FALSE,TRUE)) {
+ cat("\ngrep(*, perl =", p, ") :\n")
+ for(n in c(list(NULL), 1:7))
+ grep1r(n, tx, perl = p)
+ }

grep(*, perl = FALSE ) :
pattern '(.{1,})\1' : character(0)
pattern '(.{1,1})\1' : [1] foo foobfooofoobar  ffy
pattern '(.{1,2})\1' : [1] foo foobfooofoobar  ffy
pattern '(.{1,3})\1' : [1] foobfooofoobar  ffy
pattern '(.{1,4})\1' : [1] foobar  ffy
pattern '(.{1,5})\1' : [1] foobar  ffy
pattern '(.{1,6})\1' : [1] ffy
pattern '(.{1,7})\1' : character(0)

grep(*, perl = TRUE ) :
pattern '(.{1,})\1' : [1] foo foobfooofoobar  ffy
pattern '(.{1,1})\1' : [1] foo foobfooofoobar  ffy
pattern '(.{1,2})\1' : [1] foo foobfooofoobar  ffy
pattern '(.{1,3})\1' : [1] foo foobfooofoobar  ffy
pattern '(.{1,4})\1' : [1] foo foobfooofoobar  ffy
pattern '(.{1,5})\1' : [1] foo foobfooofoobar  ffy
pattern '(.{1,6})\1' : [1] foo foobfooofoobar  ffy
pattern '(.{1,7})\1' : [1] foo foobfooofoobar  ffy
>

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

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

[Martin Maechler]

> Winston Chang 
> on Tue, 4 Apr 2017 15:29:40 -0500 writes:

> I've done some more investigation into the problem, and it is very
> difficult to pin down. What it looks like is happening is roughly like 
this:
> - `p` is an environment and `p$e` is also an environment.
> - There is a loop. In each iteration, it looks for one item in `p$e`, 
saves
> it in a variable `x`, then removes that item from `p$e`. Then it invokes
> `x()`. The loop runs again, until there are no more items in `p$e`.

> The problem is that `ls(p$e)` sometimes returns the wrong values -- it
> returns the values that it had in previous iterations of the loop. The
> behavior is very touchy. Almost any change to the code will slightly 
change
> the behavior; sometimes the `ls()` returns values from a different
> iteration of the loop, and sometimes the problem doesn't happen at all.

> I've put a  Dockerfile and instructions for reproducing the problem here:
> https://gist.github.com/wch/2596a1c9f1bcdee91bb210c782141c88

> I think that I've gotten about as far with this as I can, though I'd be
> happy to provide more information if anyone wants to take look at the
> problem.

Dear Winston,

While I agree this may very well be a bug in R(-devel), and hence
also R in 3.4.0 alpha and hence quite important to be dealt with,

your code still involves 3 non-trivial  packages (DBI, R6,
testthat) some of which have their own C code and notably load
a couple of other package's namespaces.
We've always made a point
  https://www.r-project.org/bugs.html
that bugs in R should be reproducible without extra
packages... and I think it would definitely help to pinpoint the
issue to be seen outside of your extra packages' world. 

Or have you been aware of that and are just asking for help
finding a bug in one of the extra packages involved, a bug that might only be 
triggered by recent changes in R ?

OTOH, what you describe above  (p ; p$e ; p$e$x ...)
should be reproducible in pure "base" R code, right?

I'm sorry not to be of more help
Martin

> -Winston

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