On 13/10/2020 5:33 a.m., Iñaki Ucar wrote:
On Tue, 13 Oct 2020 at 01:47, Ben Bolker wrote:
On 10/12/20 7:37 PM, Duncan Murdoch wrote:
On 12/10/2020 6:51 p.m., Ben Bolker wrote:
On 10/12/20 6:36 PM, Duncan Murdoch wrote:
On 12/10/2020 6:14 p.m., Ben Bolker wrote:
I'd say a mismatch
On Tue, 13 Oct 2020 at 01:47, Ben Bolker wrote:
>
>
>
> On 10/12/20 7:37 PM, Duncan Murdoch wrote:
> > On 12/10/2020 6:51 p.m., Ben Bolker wrote:
> >>
> >>
> >> On 10/12/20 6:36 PM, Duncan Murdoch wrote:
> >>> On 12/10/2020 6:14 p.m., Ben Bolker wrote:
>
>
> >
> > I'd say a misma
On 12.10.2020 23:29, Ben Bolker wrote:
Sure. I assume I should aim for <10 minutes since that's the
threshold for a NOTE ... (for what it's worth the tests take a bit less
than 25% as long on my Linux laptop, since an individual test run is
more than twice as fast and we only have to
On 10/12/20 7:37 PM, Duncan Murdoch wrote:
On 12/10/2020 6:51 p.m., Ben Bolker wrote:
On 10/12/20 6:36 PM, Duncan Murdoch wrote:
On 12/10/2020 6:14 p.m., Ben Bolker wrote:
I'd say a mismatch in saved output isn't a small problem, it's
either a
too-sensitive test or something serious
On 12/10/2020 6:51 p.m., Ben Bolker wrote:
On 10/12/20 6:36 PM, Duncan Murdoch wrote:
On 12/10/2020 6:14 p.m., Ben Bolker wrote:
I'd say a mismatch in saved output isn't a small problem, it's either a
too-sensitive test or something serious.
Duncan Murdoch
That's fair enough, but
On 10/12/20 6:36 PM, Duncan Murdoch wrote:
On 12/10/2020 6:14 p.m., Ben Bolker wrote:
I'd say a mismatch in saved output isn't a small problem, it's either a
too-sensitive test or something serious.
Duncan Murdoch
That's fair enough, but it would be nice if (1) this were a NOTE an
On 12/10/2020 6:14 p.m., Ben Bolker wrote:
I'd say a mismatch in saved output isn't a small problem, it's either a
too-sensitive test or something serious.
Duncan Murdoch
That's fair enough, but it would be nice if (1) this were a NOTE and
I don't think so. As I said, I think it sh
I'd say a mismatch in saved output isn't a small problem, it's either a
too-sensitive test or something serious.
Duncan Murdoch
That's fair enough, but it would be nice if (1) this were a NOTE and
(2) it were made explicit in the CRAN policy that, *except by special
exception*, an u
On 12/10/2020 5:17 p.m., Ben Bolker wrote:
On 10/12/20 4:40 PM, Duncan Murdoch wrote:
There's this one in
https://win-builder.r-project.org/incoming_pretest/lme4_1.1-24_20201012_210730/Windows/00check.log:
Comparing 'lmer-1.Rout' to 'lmer-1.Rout.save' ...428d427
< boundary (singular) fit
Sure. I assume I should aim for <10 minutes since that's the
threshold for a NOTE ... (for what it's worth the tests take a bit less
than 25% as long on my Linux laptop, since an individual test run is
more than twice as fast and we only have to check one architecture ...)
Do I interp
Actually more than 23 minutes check time for a single package is really
excessive, can you pls cut that down?
This comes from
** running tests for arch 'i386' ... [509s] OK
** running tests for arch 'x64' ... [501s] OK
so only tests take 1010 seconds already.
I see that lme4 is a really impor
On 10/12/20 4:40 PM, Duncan Murdoch wrote:
There's this one in
https://win-builder.r-project.org/incoming_pretest/lme4_1.1-24_20201012_210730/Windows/00check.log:
Comparing 'lmer-1.Rout' to 'lmer-1.Rout.save' ...428d427
< boundary (singular) fit: see ?isSingular
430d428
< boundary (sing
On Mon, 12 Oct 2020 at 22:40, Ben Bolker wrote:
>
> On 10/12/20 4:34 PM, Iñaki Ucar wrote:
> > You are right. I was too fast and didn't read "last released version".
> > Then the only suspicious thing I see is:
> >
> > Overall checktime 23 min > 10 min
>
>I agree that's unfortunate, but it doe
There's this one in
https://win-builder.r-project.org/incoming_pretest/lme4_1.1-24_20201012_210730/Windows/00check.log:
Comparing 'lmer-1.Rout' to 'lmer-1.Rout.save' ...428d427
< boundary (singular) fit: see ?isSingular
430d428
< boundary (singular) fit: see ?isSingular
Those messages about t
On 10/12/20 4:34 PM, Iñaki Ucar wrote:
You are right. I was too fast and didn't read "last released version".
Then the only suspicious thing I see is:
Overall checktime 23 min > 10 min
I agree that's unfortunate, but it doesn't seem grounds for summary
rejection ... ? (CRAN policy says
You are right. I was too fast and didn't read "last released version".
Then the only suspicious thing I see is:
Overall checktime 23 min > 10 min
On Mon, 12 Oct 2020 at 22:25, Ben Bolker wrote:
>
>Thanks, but I don't think that's the problem because:
>
> (1) Those are reported as being f
Thanks, but I don't think that's the problem because:
(1) Those are reported as being from the last released version, not
this one.
(2) As far as I can tell from my local tests, I'm pretty sure I've
fixed these issues in the current release.
(3) In my experience UBSAN tests don't gen
On Mon, 12 Oct 2020 at 22:04, Ben Bolker wrote:
>
>Before I risk wasting the CRAN maintainers' time with a query, can
> anyone see what I'm missing here? Everything I can see looks OK, with
> the possible exception of the 'NA' result for "CRAN incoming
> feasibility" on r-devel-windows-ix86+x
Before I risk wasting the CRAN maintainers' time with a query, can
anyone see what I'm missing here? Everything I can see looks OK, with
the possible exception of the 'NA' result for "CRAN incoming
feasibility" on r-devel-windows-ix86+x86_64 (which surely isn't my fault???)
Any help appre
19 matches
Mail list logo
