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

2017-04-05 Thread 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-

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

2017-04-05 Thread 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 th

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

2017-04-05 Thread 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

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

2017-04-05 Thread 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

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

2017-04-05 Thread Winston Chang
-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

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

2017-04-05 Thread 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

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

2017-04-05 Thread Winston Chang
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 <- ta

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

2017-04-05 Thread 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

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

2017-04-05 Thread Robert McGehee
d9/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",

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

2017-04-05 Thread Winston Chang
(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 t

Re: [Rd] Bug report: POSIX regular expression doesn't match for somewhat higher values of upper bound

2017-04-05 Thread 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(

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

2017-04-05 Thread 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.