> Henrik Bengtsson
> on Sun, 25 Sep 2016 12:38:27 -0700 writes:
> On Sun, Sep 25, 2016 at 9:29 AM, Martin Maechler
> wrote:
>>> Henrik Bengtsson on
>>> Sat, 24 Sep 2016 11:31:49 -0700 writes:
>>
>> > Martin, did you post your code for withAutoprint()
Hello,
I'm tring to install a Rpackage that holds some C//C++ code
as far as I understood the R library generic compilation mechanism,
compilation of C//C++ sources is controled
1) at system level by the ocntentos RHOME/etc/Makeconf
2) at user level by the content of ~/.R/Makevars
3) at p
When 'getOption("checkPackageLicense")' is 'TRUE' and the user calls
'library(grid)' for the first time, R asks the user to either accept or
decline the package license. This should not be necessary as the package
license is "Part of R ..." with "..." denoting the R version number, and
R is fre
On 25.09.2016 18:29, Martin Maechler wrote:
I'm now committing my version (including (somewhat incomplete)
documentation, so you (all) can look at it and try / test it further.
Thanks, that's awesome. Is `withAutoprint()` recursive? How about
calling the new function in `example()` (instead of `
On 27 September 2016 at 09:37, Eric Deveaud wrote:
| Hello,
|
| I'm tring to install a Rpackage that holds some C//C++ code
|
| as far as I understood the R library generic compilation mechanism,
| compilation of C//C++ sources is controled
|
| 1) at system level by the ocntentos RHOME/et
Le 27/09/16 à 13:31, Dirk Eddelbuettel a écrit :
On 27 September 2016 at 09:37, Eric Deveaud wrote:
| Hello,
|
| I'm tring to install a Rpackage that holds some C//C++ code
|
| as far as I understood the R library generic compilation mechanism,
| compilation of C//C++ sources is controled
|
As a package author, it is in my opinion irresponsible to override these
system settings (which is why it is also impossible). You have no idea
what system it is being deployed on, I mean, you don't even know if the
compiler is gcc. If a user wants (say) heavy optimization they will compile
R with
On 27 September 2016 at 15:23, Eric Deveaud wrote:
| so why ~/R/Makevars allows to change CC and not src/Makevars ?
|
| this is pretty confusing.
It seems weird at first, but makes some sense when you think about it like
this:
-- src/Makevars is inside a package and cannot / should not alter
Le 27/09/16 à 16:30, Dirk Eddelbuettel a écrit :
On 27 September 2016 at 15:23, Eric Deveaud wrote:
| so why ~/R/Makevars allows to change CC and not src/Makevars ?
|
| this is pretty confusing.
It seems weird at first, but makes some sense when you think about it like
this:
-- src/Makevars
Le 27/09/16 à 16:17, Kasper Daniel Hansen a écrit :
As a package author, it is in my opinion irresponsible to override these
system settings (which is why it is also impossible). You have no idea
what system it is being deployed on,
as the it guy dedicated to install and maintain softs on our
So now we have some important context for your original question.
I understand why you want "symmetry" but because of the reasons Dirk
outlines, I personally think it is a bad idea, ie. I disagree with your
statement "anyway I still convinced that if R provides a mechanisn
hierachical way of varia
You're then asking CRAN to violate your "ideal contract" w/r/t compiler
switching inside src/Makevars since CRAN needs to setup and produce
standard, predictable, repeatable builds, including binary generation for
two platforms (much to Dirk's chagrin, there _are_ other operating systems
besides De
One more comment on this. In Python, there is a function,
os.path.splitdrive(), that performs path splitting in the same way my patch
does. Here's a quote from the Python docs:
"If the path contains a UNC path, drive will contain the host name and
share, up to but not including the fourth separato
# A couple of years ago
# I helped making R's character NA handling more consistent
# Today I report an issue with R's factor NA handling
# The core problem is that
# levels(g) <- levels(g)
# can change the levels of g
# more details below
# Kind regards
# Jens Oehlschlägel
# Say I have an NA ele
Hi,
I totally agree that having foo(x) <- foo(x) behave like a no-op
is a must. This is something I try to be careful about when I design
my own objects and their getters and setters.
Just wanted to mention though that there is notorious violation of
this:
x <- list(3:-1, NULL)
x[[2]] <- x[
15 matches
Mail list logo
