This is why I only put localization variables in .Rprofile and am always
putting such options into my project-specific scripts.
This may sound like I am a masochist, but I hate sharing my scripts with
someone else contaminated with compatibility bombs like that.
On July 6, 2019 8:19:27 PM PDT,
Just thought it might be of interest were I to give a progress report
( :-) ) on this problem.
I managed to track down and fix what was going wrong. It turns out that
the issue was "stringsAsFactors". I *hate* stringsAsFactors being TRUE
so I have a call to options() setting it to FALSE in
On 2/07/19 11:13 PM, Ivan Krylov wrote:
Could R CMD check be using valgrind to run the examples? Valgrind has
to interpret CPU instructions manually to be able to warn about
results of code execution depending on memory values it considers
undefined, so it is much slower than execution on a re
On 02/07/2019 5:31 a.m., Rolf Turner wrote:
Many thanks to Henrik Bengtsson and Martin Maechler for pointing out
that I can monitor progress by looking at the file
"mypkg.Rcheck/mypkg-Ex.Rout"
e.g. by using "tail -f". This strategy indeed revealed where the hangup
was happening. I wrap
Could R CMD check be using valgrind to run the examples? Valgrind has
to interpret CPU instructions manually to be able to warn about
results of code execution depending on memory values it considers
undefined, so it is much slower than execution on a real CPU.
One way to verify that on a GNU/Linu
On 2/07/19 9:45 PM, Iñaki Ucar wrote:
Which line of code is it?
Dunno that it's very enlightening, without having access to the package,
but the two lines involved are:
fit <- ldFit(inLogs,predictor="logDose",link="logit")
x3 <- cvCompare(fit,nrep=5)
The first line runs instantaneousl
It's a pain in the neck, but even more basic than inserting browser()
calls all over the place (but possibly useful in this situation) would
be inserting appropriate cat() statements all over the place ... (and
maybe using cat() with proc.time() to report on elapsed time as you go?)
(As for
Which line of code is it?
Iñaki
On Tue, 2 Jul 2019 at 11:32, Rolf Turner wrote:
>
>
> Many thanks to Henrik Bengtsson and Martin Maechler for pointing out
> that I can monitor progress by looking at the file
>
> "mypkg.Rcheck/mypkg-Ex.Rout"
>
> e.g. by using "tail -f". This strategy indeed
Many thanks to Henrik Bengtsson and Martin Maechler for pointing out
that I can monitor progress by looking at the file
"mypkg.Rcheck/mypkg-Ex.Rout"
e.g. by using "tail -f". This strategy indeed revealed where the hangup
was happening. I wrapped a line of the examples in \dontrun{} an
> Henrik Bengtsson
> on Mon, 1 Jul 2019 20:36:26 -0700 writes:
> FWIW, when running R CMD check mypkg_1.0.tar.gz
> the example output is captured to the file
> 'mypkg.Rcheck/mypkg-Ex.Rout', so you could monitor that
> one for what's going on.
> /Henrik
Yes, inde
FWIW, when running
R CMD check mypkg_1.0.tar.gz
the example output is captured to the file
'mypkg.Rcheck/mypkg-Ex.Rout', so you could monitor that one for what's
going on.
/Henrik
On Mon, Jul 1, 2019 at 7:00 PM Rolf Turner wrote:
>
>
> I am currently working on a package such that when "R CMD
I am currently working on a package such that when "R CMD check" is run
the procedure seems to disappear into a black hole when it gets to
the "* checking examples ..." stage.
Strangely, when I run the examples individually, although they take a
rather long time, they do not take an "endless
12 matches
Mail list logo
