Re: [Rd] withAutoprint({ .... }) ?
> 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()
>> anywhere? > Building withAutoprint() on top of source()
>> definitely makes sense, > unless, as Bill says, source()
>> itself could provide the same feature.
>>
>> I was really mainly asking for advice about the function
>> name .. and got none.
> I missed that part. I think the name is good. A shorter
> alternative would be withEcho(), but could be a little bit
> misleading since it doesn't reflect 'print=TRUE' to
> source().
>>
>> I'm now committing my version (including (somewhat incomplete)
>> documentation, so you (all) can look at it and try / test it further.
>>
>> > To differentiate between withAutoprint({ x <- 1 }) and
>> > withAutoprint(expr) where is an expression / language object, one
>> > could have an optional argument `substitute=TRUE`, e.g.
>>
>> > withAutoprint <- function(expr, substitute = TRUE, ...) {
>> >if (substitute) expr <- substitute(expr)
>> >[...]
>> > }
>>
>> I think my approach is nicer insofar it does not seem to need
>> such an argument I'm sure you'll try to disprove that ;-)
> Nah, I like that you've extended source() with the 'exprs' argument.
> May I suggest to add:
> svn diff src/library/base/R/
> Index: src/library/base/R/source.R
> ===
> --- src/library/base/R/source.R (revision 71357)
> +++ src/library/base/R/source.R (working copy)
> @@ -198,7 +198,7 @@
> if (!tail) {
> # Deparse. Must drop "expression(...)"
> dep <- substr(paste(deparse(ei, width.cutoff = width.cutoff,
> -control =
"showAttributes"),
> + control = c("keepInteger", "showAttributes")),
> collapse = "\n"), 12L, 1e+06L)
> dep <- paste0(prompt.echo,
> gsub("\n", paste0("\n", continue.echo), dep))
> such that you get:
>> withAutoprint(x <- c(1L, NA_integer_, NA))
>> x <- c(1L, NA_integer_, NA)
> because without it, you get:
>> withAutoprint(x <- c(1L, NA_integer_, NA))
>> x <- c(1, NA, NA)
That's a very good consideration.
However, your change would change the semantics of source(),
not just those of withAutoprint(), and I would not want to do
that ... at least not at the moment.
What I've done instead, is to make this yet another new
argument of both source() and withAutoprint(),
called 'deparseCtrl' and with different defaults (currently)
for the 2 functions.
Thank you for the feedback!
Martin
> Thanks,
> Henrik
>>
>> Martin
>>
>> > Just some thoughts
>> > /Henrik
>>
>>
>> > On Sat, Sep 24, 2016 at 6:37 AM, Martin Maechler
>> > wrote:
>> >>> William Dunlap
>> >>> on Fri, 2 Sep 2016 08:33:47 -0700 writes:
>> >>
>> >> > Re withAutoprint(), Splus's source() function could take a
expression
>> >> > (literal or not) in place of a file name or text so it could support
>> >> > withAutoprint-like functionality in its GUI. E.g.,
>> >>
>> >> >> source(auto.print=TRUE, exprs.literal= { x <- 3:7 ; sum(x) ; y <-
log(x)
>> >> > ; x - 100}, prompt="--> ")
--> x <- 3:7
--> sum(x)
>> >> > [1] 25
--> y <- log(x)
--> x - 100
>> >> > [1] -97 -96 -95 -94 -93
>> >>
>> >> > or
>> >>
>> >> >> expr <- quote({ x <- 3:7 ; sum(x) ; y <- log(x) ; x - 100})
>> >> >> source(auto.print=TRUE, exprs = expr, prompt="--> ")
--> x <- 3:7
--> sum(x)
>> >> > [1] 25
--> y <- log(x)
--> x - 100
>> >> > [1] -97 -96 -95 -94 -93
>> >>
>> >> > It was easy to implement, since exprs's default value is
parse(file) or
>> >> > parse(text=text), which source is calculating anyway.
>> >>
>> >>
>> >> > Bill Dunlap
>> >> > TIBCO Software
>> >> > wdunlap tibco.com
>> >>
>> >> Thank you, Bill (and the other correspondents); that's indeed a
>> >> very good suggestion :
>> >>
>> >> I've come to the conclusion that Duncan and Bill are right: One
>> >> should do this in R (not C) and as Bill hinted, one should use
>> >> source(). I first tried to do it separately, just "like source()",
>> >> but a considerable part of the source of source() {:-)} is
>> >> about using src attributes instead of deparse() when the former
>> >> are present, and it does make sense to generalize
>> >> withAutoprint() to have the same feature, so after all, have it
>> >> call source().
>> >>
>> >> I've spent a few hours now trying things and variants, also
>> >> found I needed to enhance
[Rd] src/Makevars ignored ?
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 package level by the content of src/Makevars Problem I have is that src/Makevars is ignored see following example: R is compiled and use the following CC and CFLAGS definition bigmess:epactsR/src > R CMD config CC gcc -std=gnu99 bigmess:epactsR/src > R CMD config CFLAGS -Wall -g so building C sources lead to the following bigmess:epactsR/src > R CMD SHLIB index.c gcc -std=gnu99 -I/local/gensoft2/adm/lib64/R/include -DNDEBUG -I/usr/local/include-fpic -Wall -g -c index.c -o index.o normal, it uses defintion from RHOME/etc/Makeconf when I set upp a ~/.R/Makevars that overwrite CC and CFLAGS definition. bigmess:epactsR/src > cat ~/.R/Makevars CC=gcc CFLAGS=-O3 bigmess:epactsR/src > R CMD SHLIB index.c gcc -I/local/gensoft2/adm/lib64/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -c index.c -o index.o gcc -std=gnu99 -shared -L/usr/local/lib64 -o index.so index.o OK CC and CFLAGS are honored and set accordingly to ~/.R/Makevars but when I try to use src/Makevars, it is ignored bigmess:epactsR/src > cat ~/.R/Makevars cat: /home/edeveaud/.R/Makevars: No such file or directory bigmess:epactsR/src > cat ./Makevars CC = gcc CFLAGS=-O3 bigmess:epactsR/src > R CMD SHLIB index.c gcc -std=gnu99 -I/local/gensoft2/adm/lib64/R/include -DNDEBUG -I/usr/local/include-fpic -Wall -g -c index.c -o index.o is there something I have missed, misunderstood or is there something wrong ? PS I tested the ssame behaviour with various version of R from R/2.15 to R/3.3 best regards Eric __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] library() asks user to accept license of some built-in packages
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 free and open source.
The unnecessary license question is asked for the built-in packages
"compiler", "grid" and "parallel".
The source file where the checks happen is
"src/library/base/R/library.R". I think one solution could be to add
something like
if(identical(pkgInfo$DESCRIPTION[["Priority"]], "base")) return()
to the beginning of checkLicense(), or add more packages to the
hard-coded exemption list checked before calling checkLicense().
Also, in find.package(), the shortcut list of standard packages is
missing "compiler".
--
Mikko Korpela
Department of Geosciences and Geography
University of Helsinki
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] withAutoprint({ .... }) ?
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 `source()` as it is now) so that examples are always rendered in auto-print mode? That may add some extra output to examples (which can be removed easily), but solve the original problem in a painless way. -Kirill __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] src/Makevars ignored ?
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/etc/Makeconf | 2) at user level by the content of ~/.R/Makevars | 3) at package level by the content of src/Makevars | | Problem I have is that src/Makevars is ignored | | | see following example: | | R is compiled and use the following CC and CFLAGS definition | | bigmess:epactsR/src > R CMD config CC | gcc -std=gnu99 | bigmess:epactsR/src > R CMD config CFLAGS | -Wall -g | | so building C sources lead to the following | | bigmess:epactsR/src > R CMD SHLIB index.c | gcc -std=gnu99 -I/local/gensoft2/adm/lib64/R/include -DNDEBUG | -I/usr/local/include-fpic -Wall -g -c index.c -o index.o | | normal, it uses defintion from RHOME/etc/Makeconf | | | when I set upp a ~/.R/Makevars that overwrite CC and CFLAGS definition. | | bigmess:epactsR/src > cat ~/.R/Makevars | CC=gcc | CFLAGS=-O3 | bigmess:epactsR/src > R CMD SHLIB index.c | gcc -I/local/gensoft2/adm/lib64/R/include -DNDEBUG -I/usr/local/include | -fpic -O3 -c index.c -o index.o | gcc -std=gnu99 -shared -L/usr/local/lib64 -o index.so index.o | | | OK CC and CFLAGS are honored and set accordingly to ~/.R/Makevars | | | but when I try to use src/Makevars, it is ignored | | bigmess:epactsR/src > cat ~/.R/Makevars | cat: /home/edeveaud/.R/Makevars: No such file or directory | bigmess:epactsR/src > cat ./Makevars | CC = gcc | CFLAGS=-O3 | bigmess:epactsR/src > R CMD SHLIB index.c | gcc -std=gnu99 -I/local/gensoft2/adm/lib64/R/include -DNDEBUG | -I/usr/local/include-fpic -Wall -g -c index.c -o index.o | | | is there something I have missed, misunderstood or is there something | wrong ? You have not demonstrated that src/Makevars is ignored -- as it clearly isn't, given how thousands of CRAN packages use it. What you have done is demonstrate that you _cannot change CC and CXX_ in src/Makevars. And I think that was known, though maybe not as widely. Dirk | PS I tested the ssame behaviour with various version of R from R/2.15 to | R/3.3 | | best regards | | Eric | | __ | R-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] src/Makevars ignored ?
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
|
| 1) at system level by the ocntentos RHOME/etc/Makeconf
| 2) at user level by the content of ~/.R/Makevars
| 3) at package level by the content of src/Makevars
|
| Problem I have is that src/Makevars is ignored
|
|
| see following example:
|
| R is compiled and use the following CC and CFLAGS definition
|
| bigmess:epactsR/src > R CMD config CC
| gcc -std=gnu99
| bigmess:epactsR/src > R CMD config CFLAGS
| -Wall -g
|
| so building C sources lead to the following
|
| bigmess:epactsR/src > R CMD SHLIB index.c
| gcc -std=gnu99 -I/local/gensoft2/adm/lib64/R/include -DNDEBUG
| -I/usr/local/include-fpic -Wall -g -c index.c -o index.o
|
| normal, it uses defintion from RHOME/etc/Makeconf
|
|
| when I set upp a ~/.R/Makevars that overwrite CC and CFLAGS definition.
|
| bigmess:epactsR/src > cat ~/.R/Makevars
| CC=gcc
| CFLAGS=-O3
| bigmess:epactsR/src > R CMD SHLIB index.c
| gcc -I/local/gensoft2/adm/lib64/R/include -DNDEBUG -I/usr/local/include
| -fpic -O3 -c index.c -o index.o
| gcc -std=gnu99 -shared -L/usr/local/lib64 -o index.so index.o
|
|
| OK CC and CFLAGS are honored and set accordingly to ~/.R/Makevars
|
|
| but when I try to use src/Makevars, it is ignored
|
| bigmess:epactsR/src > cat ~/.R/Makevars
| cat: /home/edeveaud/.R/Makevars: No such file or directory
| bigmess:epactsR/src > cat ./Makevars
| CC = gcc
| CFLAGS=-O3
| bigmess:epactsR/src > R CMD SHLIB index.c
| gcc -std=gnu99 -I/local/gensoft2/adm/lib64/R/include -DNDEBUG
| -I/usr/local/include-fpic -Wall -g -c index.c -o index.o
|
|
| is there something I have missed, misunderstood or is there something
| wrong ?
You have not demonstrated that src/Makevars is ignored -- as it clearly
isn't, given how thousands of CRAN packages use it.
What you have done is demonstrate that you _cannot change CC and CXX_ in
src/Makevars. And I think that was known, though maybe not as widely.
Hello Dirk,
so why ~/R/Makevars allows to change CC and not src/Makevars ?
this is pretty confusing.
in unix world mechanism of overwriting system default in user and
package order is something standadr and consistent given the level
priority is package specific stuff overwrite user configuration that
overwrite system default
mechanism of Makevars is NOT consistent
furthermore diggng in $RHOME/bin/config one can see the following
if test "${site}" = "yes"; then
: ${R_MAKEVARS_SITE="${R_HOME}/etc${R_ARCH}/Makevars.site"}
if test -f "${R_MAKEVARS_SITE}"; then
makefiles="${makefiles} -f ${R_MAKEVARS_SITE}"
fi
fi
if test "${personal}" = "yes"; then
if test "${R_OSTYPE}" = "windows"; then
if test -f "${R_MAKEVARS_USER}"; then
makefiles="${makefiles} -f ${R_MAKEVARS_USER}"
elif test ${R_ARCH} = "/x64" -a -f "${HOME}/.R/Makevars.win64"; then
makefiles="${makefiles} -f ${HOME}/.R/Makevars.win64"
elif test -f "${HOME}/.R/Makevars.win"; then
makefiles="${makefiles} -f ${HOME}/.R/Makevars.win"
elif test -f "${HOME}/.R/Makevars"; then
makefiles="${makefiles} -f ${HOME}/.R/Makevars"
fi
else
. ${R_HOME}/etc${R_ARCH}/Renviron
if test -f "${R_MAKEVARS_USER}"; then
makefiles="${makefiles} -f ${R_MAKEVARS_USER}"
elif test -f "${HOME}/.R/Makevars-${R_PLATFORM}"; then
makefiles="${makefiles} -f ${HOME}/.R/Makevars-${R_PLATFORM}"
elif test -f "${HOME}/.R/Makevars"; then
makefiles="${makefiles} -f ${HOME}/.R/Makevars"
fi
fi
fi
it checks and honours R_MAKEVARS_USER, ~/.R/Makevars, but not src/Makevars
I'm not really familiar with the R policy about code comilation, but I
consider this a bug but maybee I'm wrong
as a side note I solved the problem of overwritting CC for this
particular package using MAKEFLAGS="CC=gcc" R CMD INSTALL package
best regards
Eric
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] src/Makevars ignored ?
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 optimization. (For this reason I also don't think users should
modify their ~/.R/Makevars, unless for testing purposes). The exception is
(in my opinion) if you need to decrease the level of optimization because
you know or suspect the compiler to generate wrong code.
What you should do, is use
PKG_CFLAGS
as documented in R-exts, 1.2.1 under "Using Makevars".
Best,
Kasper
On Tue, Sep 27, 2016 at 9:23 AM, Eric Deveaud wrote:
> 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
>> |
>> | 1) at system level by the ocntentos RHOME/etc/Makeconf
>> | 2) at user level by the content of ~/.R/Makevars
>> | 3) at package level by the content of src/Makevars
>> |
>> | Problem I have is that src/Makevars is ignored
>> |
>> |
>> | see following example:
>> |
>> | R is compiled and use the following CC and CFLAGS definition
>> |
>> | bigmess:epactsR/src > R CMD config CC
>> | gcc -std=gnu99
>> | bigmess:epactsR/src > R CMD config CFLAGS
>> | -Wall -g
>> |
>> | so building C sources lead to the following
>> |
>> | bigmess:epactsR/src > R CMD SHLIB index.c
>> | gcc -std=gnu99 -I/local/gensoft2/adm/lib64/R/include -DNDEBUG
>> | -I/usr/local/include-fpic -Wall -g -c index.c -o index.o
>> |
>> | normal, it uses defintion from RHOME/etc/Makeconf
>> |
>> |
>> | when I set upp a ~/.R/Makevars that overwrite CC and CFLAGS definition.
>> |
>> | bigmess:epactsR/src > cat ~/.R/Makevars
>> | CC=gcc
>> | CFLAGS=-O3
>> | bigmess:epactsR/src > R CMD SHLIB index.c
>> | gcc -I/local/gensoft2/adm/lib64/R/include -DNDEBUG
>> -I/usr/local/include
>> | -fpic -O3 -c index.c -o index.o
>> | gcc -std=gnu99 -shared -L/usr/local/lib64 -o index.so index.o
>> |
>> |
>> | OK CC and CFLAGS are honored and set accordingly to ~/.R/Makevars
>> |
>> |
>> | but when I try to use src/Makevars, it is ignored
>> |
>> | bigmess:epactsR/src > cat ~/.R/Makevars
>> | cat: /home/edeveaud/.R/Makevars: No such file or directory
>> | bigmess:epactsR/src > cat ./Makevars
>> | CC = gcc
>> | CFLAGS=-O3
>> | bigmess:epactsR/src > R CMD SHLIB index.c
>> | gcc -std=gnu99 -I/local/gensoft2/adm/lib64/R/include -DNDEBUG
>> | -I/usr/local/include-fpic -Wall -g -c index.c -o index.o
>> |
>> |
>> | is there something I have missed, misunderstood or is there something
>> | wrong ?
>>
>> You have not demonstrated that src/Makevars is ignored -- as it clearly
>> isn't, given how thousands of CRAN packages use it.
>>
>> What you have done is demonstrate that you _cannot change CC and CXX_ in
>> src/Makevars. And I think that was known, though maybe not as widely.
>>
>
>
> Hello Dirk,
>
>
> so why ~/R/Makevars allows to change CC and not src/Makevars ?
>
> this is pretty confusing.
>
> in unix world mechanism of overwriting system default in user and package
> order is something standadr and consistent given the level
>
> priority is package specific stuff overwrite user configuration that
> overwrite system default
>
> mechanism of Makevars is NOT consistent
>
>
> furthermore diggng in $RHOME/bin/config one can see the following
>
>
> if test "${site}" = "yes"; then
> : ${R_MAKEVARS_SITE="${R_HOME}/etc${R_ARCH}/Makevars.site"}
> if test -f "${R_MAKEVARS_SITE}"; then
> makefiles="${makefiles} -f ${R_MAKEVARS_SITE}"
> fi
> fi
> if test "${personal}" = "yes"; then
> if test "${R_OSTYPE}" = "windows"; then
> if test -f "${R_MAKEVARS_USER}"; then
> makefiles="${makefiles} -f ${R_MAKEVARS_USER}"
> elif test ${R_ARCH} = "/x64" -a -f "${HOME}/.R/Makevars.win64"; then
> makefiles="${makefiles} -f ${HOME}/.R/Makevars.win64"
> elif test -f "${HOME}/.R/Makevars.win"; then
> makefiles="${makefiles} -f ${HOME}/.R/Makevars.win"
> elif test -f "${HOME}/.R/Makevars"; then
> makefiles="${makefiles} -f ${HOME}/.R/Makevars"
> fi
> else
> . ${R_HOME}/etc${R_ARCH}/Renviron
> if test -f "${R_MAKEVARS_USER}"; then
> makefiles="${makefiles} -f ${R_MAKEVARS_USER}"
> elif test -f "${HOME}/.R/Makevars-${R_PLATFORM}"; then
> makefiles="${makefiles} -f ${HOME}/.R/Makevars-${R_PLATFORM}"
> elif test -f "${HOME}/.R/Makevars"; then
> makefiles="${makefiles} -f ${HOME}/.R/Makevars"
> fi
> fi
> fi
>
> it checks and honours R_MAKEVARS_USER, ~/.R/Makevars, but not src/Makevars
> I'm not really familiar with the R policy about code comilation, but I
> consider this a bug but maybee I'm wrong
>
>
> as a side note I solved the problem of
Re: [Rd] src/Makevars ignored ?
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 "system" parameters like compiler brand or version as there may only be one compiler, the one R was built with it does allow however to set compilation flags, language standards, include directories etc as needed to build the package -- (user- or system-level) Makeconf allow compiler changes, but that is orthogonal to the per-package config and stays local to the machine | in unix world mechanism of overwriting system default in user and | package order is something standadr and consistent given the level | | priority is package specific stuff overwrite user configuration that | overwrite system default | | mechanism of Makevars is NOT consistent Yes we sometimes wish we could override system Makeconf settings in a package, but we can't. | as a side note I solved the problem of overwritting CC for this | particular package using MAKEFLAGS="CC=gcc" R CMD INSTALL package That works and is documented, but is not "portable" to other machines. Hope this helps, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] src/Makevars ignored ?
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 is inside a package and cannot / should not alter "system" parameters like compiler brand or version as there may only be one compiler, the one R was built with it does allow however to set compilation flags, language standards, include directories etc as needed to build the package -- (user- or system-level) Makeconf allow compiler changes, but that is orthogonal to the per-package config and stays local to the machine yep I fully aggree with this. | in unix world mechanism of overwriting system default in user and | package order is something standadr and consistent given the level | | priority is package specific stuff overwrite user configuration that | overwrite system default | | mechanism of Makevars is NOT consistent Yes we sometimes wish we could override system Makeconf settings in a package, but we can't. | as a side note I solved the problem of overwritting CC for this | particular package using MAKEFLAGS="CC=gcc" R CMD INSTALL package That works and is documented, but is not "portable" to other machines. I realize based on Kasper's answer and your's that I was not clear on the context I was working. Eric __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] src/Makevars ignored ?
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 cluster I have a reasonable knowledge of the systems I work on. I don't want to distribute any of the piece of code I was asked to made available on the cluster. I just need (and succeded plus functional test succeded) to build the Rpackage requested by a specific software. I mean, you don't even know if the compiler is gcc.If a user wants (say) heavy optimization they will compile R with optimization. (For this reason I also don't think users should modify their ~/.R/Makevars, unless for testing purposes). my question was not in a R package developer context, but in the R user that grabs some piece of code and is not abble to compile it because of 1) a developper that mixed C and C++ code which is legit. 2) a silly interaction beetween C and C++ symbol generation because of the use, in our case, of CC = gcc -std=gnu99 3) a dev that answwer: "I have no clue, in debian it works" ;-( anyway I still convinced that if R provides a mechanisn hierachical way of variable overwrite pkg / user/ system it _SHOULD_ be consistent at all levels my question was raised because of our install mechanism that (hopefully) does not allow modification of files like ~/.R/Makevars. I can only "play" with the sources of the software it is working on and//or environment variables. so I wanted to have a temporary way of setting CC to be plain gcc without ISO C99 language standard support just for this specific R library. The exception is (in my opinion) if you need to decrease the level of optimization because you know or suspect the compiler to generate wrong code. What you should do, is use PKG_CFLAGS as documented in R-exts, 1.2.1 under "Using Makevars". in the documentation you pointed (and trust me I read it), keyword is _set additional_ preprocessor options and//or compiler flags only way to _remove_ is to overwrite back to logic. either Makevars, whatever level, allow to overwrite CC definition either Makevars, whatever level, disable CC redefinition but not a mix Eric __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] src/Makevars ignored ?
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 variable overwrite pkg / user/ system it _SHOULD_ be
consistent at all levels".
The mechanism for achieving what you want - overriding CC on a local
machine - is using a ~/.R/Makevars file. I am not sure that this can be
done in a package specific manner (I don;t do this very often), but you
could create this file ('this file" being ~/.R/Makevars), install the
package and then remove it. Remember, this is an install-time setting, so
you don't need the users of your system to be involved in this. That way
you could test your proposed fix. If the fix works, it seems to me like it
should be included in the package source by the package maintainer, perhaps
using a configure script, but that is ultimately something which is up to
the package maintainer.
Best,
Kasper
On Tue, Sep 27, 2016 at 10:52 AM, Eric Deveaud wrote:
> 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 cluster I
> have a reasonable knowledge of the systems I work on.
>
> I don't want to distribute any of the piece of code I was asked to made
> available on the cluster.
> I just need (and succeded plus functional test succeded) to build the
> Rpackage requested by a specific software.
>
>
> I mean, you don't even know if the
>> compiler is gcc.If a user wants (say) heavy optimization they will
>> compile R with optimization. (For this reason I also don't think users
>> should modify their ~/.R/Makevars, unless for testing purposes).
>>
>
> my question was not in a R package developer context, but in the R user
> that grabs some piece of code and is not abble to compile it because of
> 1) a developper that mixed C and C++ code which is legit.
> 2) a silly interaction beetween C and C++ symbol generation because of the
> use, in our case, of CC = gcc -std=gnu99
> 3) a dev that answwer: "I have no clue, in debian it works" ;-(
>
> anyway I still convinced that if R provides a mechanisn hierachical way of
> variable overwrite pkg / user/ system it _SHOULD_ be consistent at all
> levels
>
> my question was raised because of our install mechanism that (hopefully)
> does not allow
> modification of files like ~/.R/Makevars.
> I can only "play" with the sources of the software it is working on
> and//or environment variables. so I wanted to have a temporary way of
> setting CC to be plain gcc without ISO C99 language standard support just
> for this specific R library.
>
>
> The exception is (in my opinion) if you need to decrease the level of
>> optimization because you know or suspect the compiler to generate wrong
>> code.
>>
>> What you should do, is use
>> PKG_CFLAGS
>> as documented in R-exts, 1.2.1 under "Using Makevars".
>>
>
> in the documentation you pointed (and trust me I read it), keyword is _set
> additional_ preprocessor options and//or compiler flags
>
> only way to _remove_ is to overwrite
>
> back to logic.
>
> either Makevars, whatever level, allow to overwrite CC definition
> either Makevars, whatever level, disable CC redefinition
>
> but not a mix
>
>
> Eric
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] src/Makevars ignored ?
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 Debian linux ;-)
I wouldn't want CRAN to honor said compiler switching inside src/Makevars
but the way you're describing the perceived contract, you're implying they
should.
I totally understand your posit, but there's a larger universe to consider
than internal package builds. In a sense you really want an R version of
Rule of Acquisition #17 "A contract is a contract is a contract... but only
on my internal systems." and that doesn't seem like a good idea to me when
the larger universe of CRAN and the need for baseline standard package
builds are considered.
On Tue, Sep 27, 2016 at 11:19 AM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:
> 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 variable overwrite pkg / user/ system it _SHOULD_ be
> consistent at all levels".
>
> The mechanism for achieving what you want - overriding CC on a local
> machine - is using a ~/.R/Makevars file. I am not sure that this can be
> done in a package specific manner (I don;t do this very often), but you
> could create this file ('this file" being ~/.R/Makevars), install the
> package and then remove it. Remember, this is an install-time setting, so
> you don't need the users of your system to be involved in this. That way
> you could test your proposed fix. If the fix works, it seems to me like it
> should be included in the package source by the package maintainer, perhaps
> using a configure script, but that is ultimately something which is up to
> the package maintainer.
>
> Best,
> Kasper
>
> On Tue, Sep 27, 2016 at 10:52 AM, Eric Deveaud
> wrote:
>
> > 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 cluster I
> > have a reasonable knowledge of the systems I work on.
> >
> > I don't want to distribute any of the piece of code I was asked to made
> > available on the cluster.
> > I just need (and succeded plus functional test succeded) to build the
> > Rpackage requested by a specific software.
> >
> >
> > I mean, you don't even know if the
> >> compiler is gcc.If a user wants (say) heavy optimization they will
> >> compile R with optimization. (For this reason I also don't think users
> >> should modify their ~/.R/Makevars, unless for testing purposes).
> >>
> >
> > my question was not in a R package developer context, but in the R user
> > that grabs some piece of code and is not abble to compile it because of
> > 1) a developper that mixed C and C++ code which is legit.
> > 2) a silly interaction beetween C and C++ symbol generation because of
> the
> > use, in our case, of CC = gcc -std=gnu99
> > 3) a dev that answwer: "I have no clue, in debian it works" ;-(
> >
> > anyway I still convinced that if R provides a mechanisn hierachical way
> of
> > variable overwrite pkg / user/ system it _SHOULD_ be consistent at all
> > levels
> >
> > my question was raised because of our install mechanism that (hopefully)
> > does not allow
> > modification of files like ~/.R/Makevars.
> > I can only "play" with the sources of the software it is working on
> > and//or environment variables. so I wanted to have a temporary way of
> > setting CC to be plain gcc without ISO C99 language standard support just
> > for this specific R library.
> >
> >
> > The exception is (in my opinion) if you need to decrease the level of
> >> optimization because you know or suspect the compiler to generate wrong
> >> code.
> >>
> >> What you should do, is use
> >> PKG_CFLAGS
> >> as documented in R-exts, 1.2.1 under "Using Makevars".
> >>
> >
> > in the documentation you pointed (and trust me I read it), keyword is
> _set
> > additional_ preprocessor options and//or compiler flags
> >
> > only way to _remove_ is to overwrite
> >
> > back to logic.
> >
> > either Makevars, whatever level, allow to overwrite CC definition
> > either Makevars, whatever level, disable CC redefinition
> >
> > but not a mix
> >
> >
> > Eric
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
>
Re: [Rd] Recursive dir.create() on Windows shares
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 separator. e.g.
splitdrive("//host/computer/dir") returns ("//host/computer", "/dir")" (see
https://docs.python.org/3/library/os.path.html#os.path.splitdrive )
The now-deprecated (as of Python 3.1) os.path.splitunc() treated UNC paths
in a similar way.
So this to say I believe the correct behaviour is to skip the first two
parts of a path beginning with \\ before attempting to create a directory
in a call to dir.create() with recursive = TRUE.
On Mon, Sep 26, 2016 at 3:46 PM, Duncan Murdoch
wrote:
> On 26/09/2016 5:27 PM, Evan Cortens wrote:
>
>> Hi folks,
>>
>> I've noticed that there's an issue with the recursive creation of
>> directories that reside on network shares. For example:
>>
>>
>>> dir.create('SERVERNAME\\Empl\\Home1\\active\\e\\ecortens
>> \\thisisatest',
>> recursive = TRUE)
>> Warning message:
>> In
>> dir.create("SERVERNAME\\Empl\\Home1\\active\\e\\ecortens
>> \\thisisatest",
>> :
>> cannot create dir '\\SERVERNAME\Empl', reason 'Permission denied'
>>
>> The issue is that dir.create() is skipping the server name, but it's not
>> skipping the share name. So, in the above example, it's trying to create
>> "Empl", which fails, setting errno to the code for "Permission denied",
>> instead of EEXIST, the code for "file already exists", because it's not
>> actually a file, and therefore can't exist as one. (Incidentally, the same
>> challenge arises with the system call _wstat(), which also will return a
>> -1, telling you that the share name doesn't exist.)
>>
>> The solution to this issue, then, is to skip not only the server name, but
>> the share name as well, which is easily done with one more line of code:
>>
>> C:\Users\ecortens\Software\R-devel\src>svn diff
>> Index: main/platform.c
>> ===
>> --- main/platform.c (revision 71366)
>> +++ main/platform.c (working copy)
>> @@ -2159,10 +2159,11 @@
>> while (*p == L'\\' && wcslen(dir) > 1 && *(p-1) != L':') *p-- =
>> L'\0';
>> if (recursive) {
>> p = dir;
>> - /* skip leading \\share */
>> + /* skip leading \\server\share */
>> if (*p == L'\\' && *(p+1) == L'\\') {
>> p += 2;
>> p = wcschr(p, L'\\');
>> + p = wcschr(p+1, L'\\');
>> }
>> while ((p = wcschr(p+1, L'\\'))) {
>> *p = L'\0';
>>
>> This fixes the issue for me, and I can create directories no problem.
>> However, I'm a little worried, as the code in platform.c has been this way
>> since 2008--surely this can't have been a bug since then. Yet I can't find
>> any indication that the UNC naming convention has changed, and I can't
>> find
>> any way that will let you test the pathname to see if it's
>> "\\server\share"
>> or "\\share".
>>
>> I've also filed this on bugzilla, and have updated it there. See
>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=1715
>>
>> Thanks for an amazing piece of software!
>>
>> Best,
>>
>> Evan
>>
>> P. S. I'm new to the mailing list, so I apologize in advance if I'm
>> violating any conventions I'm unaware of.
>>
>>
> Presumably someone from Microsoft will respond to this.
>
> Duncan Murdoch
>
>
--
Evan Cortens, PhD
Institutional Analyst - Office of Institutional Analysis
Mount Royal University
403-440-6529
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem in levels<- and other inconsistencies
# 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 element in a vector or list
x <- c("a","b",NA)
# then using split() it gets lost
split(x, x)
# as it is (somewhat) when converting to a default factor
table(as.factor(x))
# for table the workaround is
table(as.factor(x), exclude=NULL)
# but for split we need
f <- factor(x, exclude=NULL)
split(x, f)
# conclusion: we MUST use an NA level
# so far so good
g <- f
levels(g)
# but re-assigning the levels changes them
levels(g) <- levels(g)
levels(g)
# which I consider a severe problem.
# Yes, I read the help page of levels<-
# about removing levels by assigning NAs to them
# but that implies: we MUST NOT use an NA level
# If a language suggests
# that we MUST and we MUST NOT use an NA level
# the language has limited usefulness
# (and a user who depends on the language
# is put into a DOUBLE BIND)
# SUGGESTION: assure the above assignment does not change levels
# trying to apply the levels of f to new data also fails
g <- factor(x, levels=levels(f))
g
# and giving both arguments even stops
h <- factor(x, levels=levels(f), labels=levels(f))
# I do understand that exclude= meaningfully has effect
# if levels= are to be determined automatically, but
# SUGGESTION: with explicit levels= exclude= should be ignored.
# SUGGESTION: give split(x, y, exclude=NA) an exclude= argument,
# which when set to NULL will prevent dropping NA levels
# when coercing y to factor
# (it still remains open what should have priority
# if y is a factor with an NA-level and exclude=NA)
table(f, exclude=NA)
# here existing levels win over exclude=
# which is consistent with my suggestion for factor(, levels=, exclude=)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem in levels<- and other inconsistencies
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[[2]]
x
# [[1]]
# [1] 3 2 1 0 -1
Now of course, not just because there is a precedent means the factor
API shouldn't be improved.
Cheers,
H.
On 09/27/2016 12:33 PM, Dr. Jens Oehlschlägel wrote:
# 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 element in a vector or list
x <- c("a","b",NA)
# then using split() it gets lost
split(x, x)
# as it is (somewhat) when converting to a default factor
table(as.factor(x))
# for table the workaround is
table(as.factor(x), exclude=NULL)
# but for split we need
f <- factor(x, exclude=NULL)
split(x, f)
# conclusion: we MUST use an NA level
# so far so good
g <- f
levels(g)
# but re-assigning the levels changes them
levels(g) <- levels(g)
levels(g)
# which I consider a severe problem.
# Yes, I read the help page of levels<-
# about removing levels by assigning NAs to them
# but that implies: we MUST NOT use an NA level
# If a language suggests
# that we MUST and we MUST NOT use an NA level
# the language has limited usefulness
# (and a user who depends on the language
# is put into a DOUBLE BIND)
# SUGGESTION: assure the above assignment does not change levels
# trying to apply the levels of f to new data also fails
g <- factor(x, levels=levels(f))
g
# and giving both arguments even stops
h <- factor(x, levels=levels(f), labels=levels(f))
# I do understand that exclude= meaningfully has effect
# if levels= are to be determined automatically, but
# SUGGESTION: with explicit levels= exclude= should be ignored.
# SUGGESTION: give split(x, y, exclude=NA) an exclude= argument,
# which when set to NULL will prevent dropping NA levels
# when coercing y to factor
# (it still remains open what should have priority
# if y is a factor with an NA-level and exclude=NA)
table(f, exclude=NA)
# here existing levels win over exclude=
# which is consistent with my suggestion for factor(, levels=, exclude=)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
