Re: [Rd] on.exit() & sys.on.exit(): Calling them via eval() does not work as hoped

eval() tends to be able to convince normal functions of where they are executing, but primitive functions use different methods to get their evaluation context and aren't as easily fooled. It turns out do.call() works better on primitive functions, and it will work for "on.exit". However I wasn't a

[Rd] How to make an R package that uses Boost.Thread, qualified to be published on CRAN or shared by the most

Hi, Recently, I made an R package that used the C++ library Boost.Thread (http://www.boost.org/doc/libs/1_54_0/doc/html/thread.html) for multithreading. Previously, I have posted a question at stackoverflow (http://stackoverflow.com/questions/19651954/is-it-possible-to-build-an-r-package-which

Re: [Rd] How to make an R package that uses Boost.Thread, qualified to be published on CRAN or shared by the most

On 3 November 2013 at 11:35, Simon wrote: | Hi, | | Recently, I made an R package that used the C++ library Boost.Thread (http://www.boost.org/doc/libs/1_54_0/doc/html/thread.html) for multithreading. Previously, I have posted a question at stackoverflow (http://stackoverflow.com/questions/19

[Rd] Byte code compile not helpful in R3.0.2

I had a bunch of examples of byte code compiles in something I was writing. Changed to 3.0.2 and the advantage of compiler disappears. I've looked in the NEWS file but do not see anything that suggests that the compile is now built-in. Possibly I've just happened on a bunch of examples where it doe

Re: [Rd] Byte code compile not helpful in R3.0.2

On 13-11-03 2:15 PM, Prof J C Nash (U30A) wrote: I had a bunch of examples of byte code compiles in something I was writing. Changed to 3.0.2 and the advantage of compiler disappears. I've looked in the NEWS file but do not see anything that suggests that the compile is now built-in. Possibly I'v

Re: [Rd] Byte code compile not helpful in R3.0.2

My bad to not give details. I'm comparing (though not quite directly) to results in the posting http://rwiki.sciviews.org/doku.php?id=tips:rqcasestudy. What prompted the query was a write up of "for" versus "while" loops, where there was a speedup using compiler for one of these. I had the example

Re: [Rd] Byte code compile not helpful in R3.0.2

tfor <- cmpfun(tfor) twhile <- cmpfun(twhile) /Henrik On Sun, Nov 3, 2013 at 11:55 AM, Prof J C Nash (U30A) wrote: > My bad to not give details. I'm comparing (though not quite directly) to > results in the posting > http://rwiki.sciviews.org/doku.php?id=tips:rqcasestudy. > > What prompted the

Re: [Rd] on.exit() & sys.on.exit(): Calling them via eval() does not work as hoped

On Sun, Nov 3, 2013 at 2:16 AM, Peter Meilstrup wrote: > eval() tends to be able to convince normal functions of where they are > executing, but primitive functions use different methods to get their > evaluation context and aren't as easily fooled. Brilliant wording :) > It turns out do.call()

Re: [Rd] Byte code compile (not) helpful in R3.0.2 -- Fixed.

Thanks. I should not try adjusting code after some hours of proofreading. Making that change gave a suitable time difference. Best, JN On 13-11-03 03:46 PM, Henrik Bengtsson wrote: > tfor <- cmpfun(tfor) > twhile <- cmpfun(twhile) > > /Henrik > > > On Sun, Nov 3, 2013 at 11:55 AM, Prof J C

[Rd] WISHLIST: on.exit(..., add=TRUE, where="first") to address common use cases

Before trying to submit a patch(*) to on.exit(), I'd like to check whether there is an interest in enhancing on.exit(..., add=TRUE) such that it is possible to specify whether the added expression should be added before or after already recorded expression. The default is now to add it after, but

[Rd] Failed to install kernlab package

Hi everyone, I am trying to install kernlab package, but failed many times by now on CentOS 6 operating system. FYI, I have no problem with this package installation on windows platform. Here is the error message: trying URL 'http://cran.wustl.edu/src/contrib/kernlab_0.9-18.tar.gz' Content ty

Re: [Rd] R 3.1.0 and C++11

I'd like to echo Whit's sentiment and hopefully warm up this thread. C++11's new features and functionality give R users low-level tools (like threads, mutexes, futures, date-time, and atomic types) that work across platforms and wouldn't require other external libraries like boost. Romain, will y

Re: [Rd] WISHLIST: on.exit(..., add=TRUE, where="first") to address common use cases

I used to worry about the order of evaluation of on.exit expressions and thought that maybe we needed named on.exit expression so you could remove particular on.exit expressions. However, now I think I can almost always avoid such considerations and make code clearer by making a new function cal

Re: [Rd] How to make an R package that uses Boost.Thread, qualified to be published on CRAN or shared by the most

Hi Dirk, Thank you very much, your answers are always helpful and point me to the right direction. And I also hope the C++11 proposal ( https://stat.ethz.ch/pipermail/r-devel/2013-October/067677.html) will be approved soon. :-) Simon On 11/03/2013 09:54 PM, Dirk Eddelbuettel wrote: > On 3 Nove

Re: [Rd] Failed to install kernlab package

Hi, I can't reproduce the error with a fully updated CentOS 6 with R-core and R-devel installed from http://www.nic.funet.fi/pub/mirrors/fedora.redhat.com/pub/epel/6/x86_64/. Here is the sessionInfo from my CentOS 6 system where installation of kernlab was successful: sessionInfo() R version 3.0.

[Rd] Suggestion for help page for ?plotmath

May I suggest a minor addition to the existing help page for ?plotmath, ... immediately following: "Note that bold, italic and bolditalic do not apply to symbols, and hence not to the Greek symbols such as mu which are displayed in the symbol font. They also do not apply to numeric constants."