Re: [Rd] Small enhancement for CMD check
Unfortunately it would need a major rewrite, and either piping output through a pager (surely the standard Unix way to handle this) or redirecting to a file is the simplest way to do this. R CMD check calls a process to run .runPackageTestsR, which calls further processes to run each test and diff the results. We could simply capture stdout/stderr of .runPackageTestsR, but then one would have to wait until all the tests had run before seeing any output, which may mean waiting hours -- that was decided to be too undesirable. On Fri, 25 Feb 2011, Terry Therneau wrote: It would be nice if the 00check.log file also included this part of the output: Running ‘bladder.R’ Comparing ‘bladder.Rout’ to ‘bladder.Rout.save’ ... OK Running ‘book1.R’ Comparing ‘book1.Rout’ to ‘book1.Rout.save’ ... OK Running ‘book2.R’ Comparing ‘book2.Rout’ to ‘book2.Rout.save’ ... OK etc. The survival package has enough test scripts that it exceeds my terminal's scroll bar; I have to either watch closely or run R CMD check survival >& mylog The most prolix are survival portfoliomatlab kappalab spatstat 6836323028 BBHSAUR2fields pcalg aster 2622222221 The remedy seems to be to group the tests into larger units. Terry Therneau -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Small enhancement for CMD check
On Mon, 2011-02-28 at 16:57 +, Prof Brian Ripley wrote: > Unfortunately it would need a major rewrite, and either piping output > through a pager (surely the standard Unix way to handle this) or > redirecting to a file is the simplest way to do this. > > R CMD check calls a process to run .runPackageTestsR, which calls > further processes to run each test and diff the results. We could > simply capture stdout/stderr of .runPackageTestsR, but then one would > have to wait until all the tests had run before seeing any output, > which may mean waiting hours -- that was decided to be too > undesirable. Fair enough. My request was of the "if it's easy to do" class. Thanks for looking. (On Unix you could avoid the wait by using tee, BTW) > The most prolix are > survival portfoliomatlab kappalab spatstat > 6836323028 > BBHSAUR2fields pcalg aster > 2622222221 > > The remedy seems to be to group the tests into larger units. It appears that I'm an outlier. I certainly didn't start thinking that there would be so many tests. But whenever I track down a new bug in response to a user I'll have created some code to isolate and define the error first, and then more lines to verify the fix; I usually find the extra 15-20 minutes to 'formalize' this and add it to the test suite to be a good investment. Hopefully the 68 is taken as a measure of longivity of the package and not of bad programming skills! Terry T __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] broken link on CRAN
The link to http://cran.r-project.org/bin/macosx/R-2.12.1.pkg on the CRAN page http://cran.r-project.org/bin/macosx/ is broken. Also, the email address for the webmaster is null (which is why I'm emailing here). Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] broken link on CRAN
On Feb 28, 2011, at 21:22 , Max Kuhn wrote: > The link to > > http://cran.r-project.org/bin/macosx/R-2.12.1.pkg > > on the CRAN page > > http://cran.r-project.org/bin/macosx/ > > is broken. Also, the email address for the webmaster is null (which is > why I'm emailing here). There's no such link and 2.12.2 is current. I suspect you have a page cache issue, or managed to hit the link at exactly the wrong time during update. If you really need the older version, look in old/. > > Thanks, > > Max > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 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] broken link on CRAN
On Feb 28, 2011, at 3:22 PM, Max Kuhn wrote: > The link to > > http://cran.r-project.org/bin/macosx/R-2.12.1.pkg > > on the CRAN page > > http://cran.r-project.org/bin/macosx/ > > is broken. There is no such link on the page - it's R-2.12.2.pkg now - I suspect you have a cached page in your browser - try reloading it. Cheers, Simon > Also, the email address for the webmaster is null (which is > why I'm emailing here). > > Thanks, > > Max > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] function call overhead
Snipping down to bare minimum history before comment:
On Wed, Feb 16, 2011 at 4:28 PM, Olaf Mersmann
wrote:
> Dear Hadly, dear list,
>
> On Wed, Feb 16, 2011 at 9:53 PM, Hadley Wickham wrote:
>
>>> system.time(replicate(1e4, base::print))
>> user system elapsed
>> 0.539 0.001 0.541
>>> system.time(replicate(1e4, print))
>> user system elapsed
>> 0.013 0.000 0.012
>> library("microbenchmark")
>> res <- microbenchmark(print, base::print, times=1)
>> res
>> print(res, unit="eps")
> Unit: evaluations per second
> min lq median uq max
> print 17543859.65 15384615.38 14705882.35 14492753.62 20665.8538
> base::print 23944.64 23064.33 22584.32 20659.88 210.5329
>
I think it is important to say that this slowdown is not unique to R
and is unrelated to the fact that is R interpreted. The same happens
in compiled object-oriented languages like C++ or Objective-C. There
is an inherent cost in the runtime system to find a function or method
that is suitable to an object.
In agent-based modeling simulations, we call it the cost of "method
lookup" because the runtime system has to check for the existence of a
method each time it is called for a given object. There is a
time-saving approach where one can cache the result of the lookup and
then call that result directly each time through the loop.
Implementing this is pretty complicated, however, and it is
discouraged unless you really need it. It is especially dangerous
because this optimization throws-away the runtime benefit of matching
the correct method to the class of the object. (See
http://www.mulle-kybernetik.com/artikel/Optimization/opti-3.html,
where it shows how one can even cache C library functions to avoid
lookup overhead. I'm told that the Obj-C 2.0 runtime will try to
optimize this automatically, I've not tested.)
The R solution is achieving that exact same kind of speed-up by saving
the function lookup in a local variable. The R approach, however, is
implemented much more easily than the Objective-C solution. There is
an obvious danger: if the saved method is not appropriate to an object
to which it applies, something unpredictable will happen.
The same is true in C++. I was fiddling around with the C++ code that
is included with the R package Siena (awesome package, incidentally)
last year and noticed a similar slowdown with method lookup. In C++,
I was surprised to find a slowdown inside a class using an instance
variable prefixed with "this.". For an IVAR, "this.x" and "x" are
the same thing, but to the runtime system, well, there's slowdown in
finding "this" class and getting x, compared to just using x. To the
programmer who is trying to be clear and careful, putting "this." on
the front of IVAR is tidy, but it also slows down the runtime a lot.
Hope this is not more confusing than when I started :)
pj
--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] function call overhead
On Mon, Feb 28, 2011 at 6:37 PM, Paul Johnson wrote:
> Snipping down to bare minimum history before comment:
>
> On Wed, Feb 16, 2011 at 4:28 PM, Olaf Mersmann
> wrote:
>> Dear Hadly, dear list,
>>
>> On Wed, Feb 16, 2011 at 9:53 PM, Hadley Wickham wrote:
>>
system.time(replicate(1e4, base::print))
>>> user system elapsed
>>> 0.539 0.001 0.541
system.time(replicate(1e4, print))
>>> user system elapsed
>>> 0.013 0.000 0.012
>
>>> library("microbenchmark")
>>> res <- microbenchmark(print, base::print, times=1)
>>> res
>>> print(res, unit="eps")
>> Unit: evaluations per second
>> min lq median uq max
>> print 17543859.65 15384615.38 14705882.35 14492753.62 20665.8538
>> base::print 23944.64 23064.33 22584.32 20659.88 210.5329
>>
>
> I think it is important to say that this slowdown is not unique to R
> and is unrelated to the fact that is R interpreted. The same happens
> in compiled object-oriented languages like C++ or Objective-C. There
> is an inherent cost in the runtime system to find a function or method
> that is suitable to an object.
>
> In agent-based modeling simulations, we call it the cost of "method
> lookup" because the runtime system has to check for the existence of a
> method each time it is called for a given object. There is a
> time-saving approach where one can cache the result of the lookup and
> then call that result directly each time through the loop.
> Implementing this is pretty complicated, however, and it is
> discouraged unless you really need it. It is especially dangerous
> because this optimization throws-away the runtime benefit of matching
> the correct method to the class of the object. (See
> http://www.mulle-kybernetik.com/artikel/Optimization/opti-3.html,
> where it shows how one can even cache C library functions to avoid
> lookup overhead. I'm told that the Obj-C 2.0 runtime will try to
> optimize this automatically, I've not tested.)
>
> The R solution is achieving that exact same kind of speed-up by saving
> the function lookup in a local variable. The R approach, however, is
> implemented much more easily than the Objective-C solution. There is
> an obvious danger: if the saved method is not appropriate to an object
> to which it applies, something unpredictable will happen.
>
> The same is true in C++. I was fiddling around with the C++ code that
> is included with the R package Siena (awesome package, incidentally)
> last year and noticed a similar slowdown with method lookup. In C++,
> I was surprised to find a slowdown inside a class using an instance
> variable prefixed with "this.". For an IVAR, "this.x" and "x" are
> the same thing, but to the runtime system, well, there's slowdown in
> finding "this" class and getting x, compared to just using x. To the
> programmer who is trying to be clear and careful, putting "this." on
> the front of IVAR is tidy, but it also slows down the runtime a lot.
In the case of namespace qualification (or template
metaprogramming) in C++ the qualification is resolved at
compile time, so there is no performance hit at runtime.
On the cost of this.x vs x, this probably becomes very small (or zero)
when a smart optimizer is used (one that knows that they are the same).
The performance hit results when what appears to be a field access (foo.x)
is really syntactic sugar for message dispatch (a function call), as is often
the case in agent-based modelling (and in languages that follow the Smalltalk
model, or the Actor model).
Dominick
> Hope this is not more confusing than when I started :)
>
> pj
> --
> Paul E. Johnson
> Professor, Political Science
> 1541 Lilac Lane, Room 504
> University of Kansas
>
> __
> 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] broken link on CRAN
Peter and Simon, That was the issue. Thanks, Max On Mon, Feb 28, 2011 at 3:48 PM, Simon Urbanek wrote: > > On Feb 28, 2011, at 3:22 PM, Max Kuhn wrote: > >> The link to >> >> http://cran.r-project.org/bin/macosx/R-2.12.1.pkg >> >> on the CRAN page >> >> http://cran.r-project.org/bin/macosx/ >> >> is broken. > > There is no such link on the page - it's R-2.12.2.pkg now - I suspect you > have a cached page in your browser - try reloading it. > > Cheers, > Simon > > >> Also, the email address for the webmaster is null (which is >> why I'm emailing here). >> >> Thanks, >> >> Max >> >> > > -- Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
