Re: [Rd] Latest R-devel build failing on OS X
Thank you, Martin. I linked to your message in a comment here so maybe other people will know about that useful technique: http://singmann.org/installing-r-devel-on-linux/#comment-161 However, when I try it, I get an error: $ make make[1]: Entering directory '/home/frederik/pkg-tmp/R-svn-build/m4' make[1]: Nothing to be done for 'R'. make[1]: Leaving directory '/home/frederik/pkg-tmp/R-svn-build/m4' make[1]: Entering directory '/home/frederik/pkg-tmp/R-svn-build/tools' make[1]: Nothing to be done for 'R'. make[1]: Leaving directory '/home/frederik/pkg-tmp/R-svn-build/tools' make[1]: Entering directory '/home/frederik/pkg-tmp/R-svn-build/doc' /usr/bin/install: cannot stat '../../R-svn/doc/NEWS': No such file or directory /usr/bin/install: cannot stat '../../R-svn/doc/NEWS.pdf': No such file or directory Makefile:164: recipe for target 'svnonly' failed make[1]: *** [svnonly] Error 1 make[1]: Leaving directory '/home/frederik/pkg-tmp/R-svn-build/doc' Makefile:60: recipe for target 'R' failed make: *** [R] Error 1 I configured like this: $ cd ../R-svn-build/ $ ../R-svn/configure --without-recommended-packages --prefix=$HOME/r-svn-test STRIP=true I guess I can try to debug it myself but thought I should report back to you. It works when I 'configure' and 'make' in the source directory. Cheers, Frederick On Tue, May 24, 2016 at 07:20:18PM +0200, Martin Maechler wrote: > > Keith O'Hara > > on Tue, 24 May 2016 12:47:43 -0400 writes: > > > svn checkout https://svn.r-project.org/R/trunk/ > > yes, indeed. thank you, Keith. > > and from then on only > > cd > svn up > > (which is short for 'svn update'). > > Another hint: Then do *not* build in the source directory but in > what we called a "build directory"; i.e., something like > (from scratch; including the only-once needed "checkout") : > > svn checkout https://svn.r-project.org/R/trunk/ R > cd R > tools/rsync-recommended > mkdir ../build-R > cd ../build-R > ../R/configure > make > make check > > and I then never run 'make install', but rather use symbolic > link from > /build-R/bin/R to something like ~/bin/R-devel > i.e., > cd ~/bin > ln -s /build-R/bin/R R-devel > > Martin > > >> On May 24, 2016, at 12:45 PM, frede...@ofb.net wrote: > >> > >> I agree with Martin's summary of the situation, and with the updated > >> NEWS entry. > >> > >> I'm not familiar with Subversion, can you tell me the command to use? > >> > >> (I tried "svn co https://svn.r-project.org/R/"; but it seems to be > >> downloading all branches) > >> > >> Frederick > >> > >> On Tue, May 24, 2016 at 04:30:11PM +0200, Martin Maechler wrote: > peter dalgaard > on Tue, 24 May 2016 13:47:27 +0200 writes: > >>> > I had a regression in config.site so the nightly build didn't. > Retrying > Looks like it will build, but the ctl-R, ctl-C bug is still present > on OSX (w/Simon's libs). This _was_ fixed for a while, was it not? > >>> > >>> I thought it was never fixed, for readline versions 5.x (or all > >>> of readline_version < 6.3 ?) because the patch assumed features > >>> not available, e.g., for Frederik (who got compilation errors > >>> which I think you confirmed on pre-6 readline). > >>> > >>> I remember you having two different readlines installed on OSX > >>> but the standard Mac binary (from CRAN, i.e. Simon) would use > >>> the old readline version ? > >>> > >>> so that whole resetReadline() solution is now conditionalized inside > >>> > >>> #if defined(RL_READLINE_VERSION) && RL_READLINE_VERSION >= 0x0603 > >>> ... > >>> ... > >>> #endif > >>> > >>> and hence the previous code (which is buggy) is used for > >>> readline versions < 6.3. > >>> As a consequence the bug is only fixed for readline >= 6.3, > >>> because the current patch did not compile and hence seemed not > >>> appropriate for readline < 6.3 (and hence the above > conditionalization). > >>> > >>> > (The NEWS entry is also wrong: The issue existed before readline 6.3) > >>> > >>> Aah.. you are right. The API change with 6.3 was for the other, the > >>> "SIGWINCH" bug. > >>> > >>> Here's a an update proposal for that NEWS entry : > >>> > >>> • The API for readline libraries >= 6.3 had changed such > >>> terminal window resizes where no longer properly signalled > >>> (PR#16604). Also, ‘Ctrl C’ in incremental search behaved > >>> confusingly in R (unix) consoles (PR#16603) also for older > >>> readline versions. These have been fixed (for readline >= > >>> 6.3 only), thanks to patches by Frederick Eaton. > >>> > >>> >
Re: [Rd] Suggestion: mkString(NULL) should be NA
On Tue, May 24, 2016 at 9:30 AM, Jeroen Ooms
wrote:
> On Tue, May 24, 2016 at 5:59 PM, Gabriel Becker
> wrote:
> > Shouldn't Rf_mkString(NULL) return (the c-level equivalent of)
> character()
> > rather than the NA_character_?
>
> No. It should still be safe to assume that mkString() always returns a
> character vector of exactly length one. Anything else could lead to
> type errors.
>
Well the thing is you're passing an invalid pointer, that doesn't point to
a C string, to a constructor expecting a valid const char *. I'm fine with
the contract being that mkString always returns a character vector of
length one, but that doesn't necessarily mean that the function needs to
accept NULL pointers. The contract as I understand it is that if you give
it a C string, it will create a CHARSXP for that string. In this light,
Bill's suggestion that it throw an error seems the most principled
response. I would think you would need to at the very least emit a warning.
>
> > An empty string and NULL aren't the same.
>
> Exactly! So if you pass in an empty C string, you get an empty R
> string, and if you pass in a null pointer you get NA.
>
> Rf_mkString(NULL) <--> NA
> Rf_mkString("") <--> ""
>
> There is no ambiguity, and much better than segfaulting.
>
Well, better than segfaulting is not really relevant here. No one is
arguing that it should segfault. The question is what behavior it should
have when it doesn't segfault.
It's true that a C empty string is not the same as NULL, but NULL isn't the
same as NA either. Semantically, for your use-case (which I gather arose
from interactions we had :) ) the NULL means there is no version, while NA
indicates there is a version but we don't know what it is. Imagine an
object class that represents a persons name (first, middle, last). Now take
two people, One has no middle name (and we know that when creating the
object) and another for whom we don't have any information about the middle
name, only first and last were reported. I would expect the first one to
have middle name either NULL or (in a data.frame context) "", while the
second would have NA_character_. In this light, mkString should arguably
generate "". i don't think the fact that there is another way to get "" is
a particularly large problem.
On the other hand, and in support of your position it came up as Michael
Lawrence and I were talking about this that asChar from utils.c will give
you NA_STRING when you give it R_NilValue. That is a coercion though,
whereas arguably mkString is not. That said, consistency would probably be
good.
~G
--
Gabriel Becker, PhD
Associate Scientist (Bioinformatics)
Genentech Research
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Latest R-devel build failing on OS X
> Keith O'Hara > on Tue, 24 May 2016 12:47:43 -0400 writes: > svn checkout https://svn.r-project.org/R/trunk/ yes, indeed. thank you, Keith. and from then on only cd svn up (which is short for 'svn update'). Another hint: Then do *not* build in the source directory but in what we called a "build directory"; i.e., something like (from scratch; including the only-once needed "checkout") : svn checkout https://svn.r-project.org/R/trunk/ R cd R tools/rsync-recommended mkdir ../build-R cd ../build-R ../R/configure make make check and I then never run 'make install', but rather use symbolic link from /build-R/bin/R to something like ~/bin/R-devel i.e., cd ~/bin ln -s /build-R/bin/R R-devel Martin >> On May 24, 2016, at 12:45 PM, frede...@ofb.net wrote: >> >> I agree with Martin's summary of the situation, and with the updated >> NEWS entry. >> >> I'm not familiar with Subversion, can you tell me the command to use? >> >> (I tried "svn co https://svn.r-project.org/R/"; but it seems to be >> downloading all branches) >> >> Frederick >> >> On Tue, May 24, 2016 at 04:30:11PM +0200, Martin Maechler wrote: peter dalgaard on Tue, 24 May 2016 13:47:27 +0200 writes: >>> I had a regression in config.site so the nightly build didn't. Retrying Looks like it will build, but the ctl-R, ctl-C bug is still present on OSX (w/Simon's libs). This _was_ fixed for a while, was it not? >>> >>> I thought it was never fixed, for readline versions 5.x (or all >>> of readline_version < 6.3 ?) because the patch assumed features >>> not available, e.g., for Frederik (who got compilation errors >>> which I think you confirmed on pre-6 readline). >>> >>> I remember you having two different readlines installed on OSX >>> but the standard Mac binary (from CRAN, i.e. Simon) would use >>> the old readline version ? >>> >>> so that whole resetReadline() solution is now conditionalized inside >>> >>> #if defined(RL_READLINE_VERSION) && RL_READLINE_VERSION >= 0x0603 >>> ... >>> ... >>> #endif >>> >>> and hence the previous code (which is buggy) is used for >>> readline versions < 6.3. >>> As a consequence the bug is only fixed for readline >= 6.3, >>> because the current patch did not compile and hence seemed not >>> appropriate for readline < 6.3 (and hence the above conditionalization). >>> >>> (The NEWS entry is also wrong: The issue existed before readline 6.3) >>> >>> Aah.. you are right. The API change with 6.3 was for the other, the >>> "SIGWINCH" bug. >>> >>> Here's a an update proposal for that NEWS entry : >>> >>> • The API for readline libraries >= 6.3 had changed such >>> terminal window resizes where no longer properly signalled >>> (PR#16604). Also, ‘Ctrl C’ in incremental search behaved >>> confusingly in R (unix) consoles (PR#16603) also for older >>> readline versions. These have been fixed (for readline >= >>> 6.3 only), thanks to patches by Frederick Eaton. >>> >>> >>> Martin >>> -pd >>> On 24 May 2016, at 12:55 , Martin Maechler wrote: >>> > > Can you (Frederick, Peter, Keith, but ideally others, too) > confirm that you don't see any problems anymore, when building a > version of R-devel from sources that are newer > than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see below)? > > I'm asking because the question is open if these should be > "back ported" to R 3.3.0 patched or not. > > Best regards, > Martin > >> Martin Maechler >> on Thu, 19 May 2016 11:02:48 +0200 writes: > >> >> on Wed, 18 May 2016 15:03:31 -0700 writes: > Readline <= 6.2 shouldn't require the SIGWINCH patch, so if older versions have trouble finding rl_resize_terminal then you could wrap a macro around that part. > >>> I find python related patches that use > >>> #ifdef HAVE_RL_RESIZE_TERMINAL > >>> so they must have configured for that. We could and >>> probably should do the same, but as a Linux_only guy >>> currently (even basically only one flavor of Linux), I'd >>> appreciate others to produce code for that. > > Actually that was easy (in hindsight.. I took too long!) > enough, so I've now committed > > > r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 line > Changed paths: > M configure > M config
Re: [Rd] Latest R-devel build failing on OS X
Thanks. OK, I get $ ./configure --prefix=$HOME/r-svn-test --cache-file=config.cache STRIP=true && make -j8 ... checking for Fortran flag to compile .f95 files... none checking for gfortran option to support OpenMP... -fopenmp checking for recommended packages... ls: cannot access './src/library/Recommended/MASS_*.tar.gz': No such file or directory no configure: error: Some of the recommended packages are missing Use --without-recommended-packages if this was intentional However, when I configure --without-recommended-packages and make install, the build works and both Readline issues are fixed in the result. Thank you! On Tue, May 24, 2016 at 12:47:43PM -0400, Keith O'Hara wrote: > svn checkout https://svn.r-project.org/R/trunk/ > > > On May 24, 2016, at 12:45 PM, frede...@ofb.net wrote: > > > > I agree with Martin's summary of the situation, and with the updated > > NEWS entry. > > > > I'm not familiar with Subversion, can you tell me the command to use? > > > > (I tried "svn co https://svn.r-project.org/R/"; but it seems to be > > downloading all branches) > > > > Frederick > > > > On Tue, May 24, 2016 at 04:30:11PM +0200, Martin Maechler wrote: > >>> peter dalgaard > >>>on Tue, 24 May 2016 13:47:27 +0200 writes: > >> > >>> I had a regression in config.site so the nightly build didn't. > >>> Retrying > >>> Looks like it will build, but the ctl-R, ctl-C bug is still present on > >>> OSX (w/Simon's libs). This _was_ fixed for a while, was it not? > >> > >> I thought it was never fixed, for readline versions 5.x (or all > >> of readline_version < 6.3 ?) because the patch assumed features > >> not available, e.g., for Frederik (who got compilation errors > >> which I think you confirmed on pre-6 readline). > >> > >> I remember you having two different readlines installed on OSX > >> but the standard Mac binary (from CRAN, i.e. Simon) would use > >> the old readline version ? > >> > >> so that whole resetReadline() solution is now conditionalized inside > >> > >> #if defined(RL_READLINE_VERSION) && RL_READLINE_VERSION >= 0x0603 > >> ... > >> ... > >> #endif > >> > >> and hence the previous code (which is buggy) is used for > >> readline versions < 6.3. > >> As a consequence the bug is only fixed for readline >= 6.3, > >> because the current patch did not compile and hence seemed not > >> appropriate for readline < 6.3 (and hence the above conditionalization). > >> > >> > >>> (The NEWS entry is also wrong: The issue existed before readline 6.3) > >> > >> Aah.. you are right. The API change with 6.3 was for the other, the > >> "SIGWINCH" bug. > >> > >> Here's a an update proposal for that NEWS entry : > >> > >> • The API for readline libraries >= 6.3 had changed such > >> terminal window resizes where no longer properly signalled > >> (PR#16604). Also, ‘Ctrl C’ in incremental search behaved > >> confusingly in R (unix) consoles (PR#16603) also for older > >> readline versions. These have been fixed (for readline >= > >> 6.3 only), thanks to patches by Frederick Eaton. > >> > >> > >> Martin > >> > >>> -pd > >> > >>> On 24 May 2016, at 12:55 , Martin Maechler > >>> wrote: > >> > > Can you (Frederick, Peter, Keith, but ideally others, too) > confirm that you don't see any problems anymore, when building a > version of R-devel from sources that are newer > than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see below)? > > I'm asking because the question is open if these should be > "back ported" to R 3.3.0 patched or not. > > Best regards, > Martin > > > Martin Maechler > > on Thu, 19 May 2016 11:02:48 +0200 writes: > > > > > on Wed, 18 May 2016 15:03:31 -0700 writes: > > >>> Readline <= 6.2 shouldn't require the SIGWINCH patch, so > >>> if older versions have trouble finding rl_resize_terminal > >>> then you could wrap a macro around that part. > > >> I find python related patches that use > > >> #ifdef HAVE_RL_RESIZE_TERMINAL > > >> so they must have configured for that. We could and > >> probably should do the same, but as a Linux_only guy > >> currently (even basically only one flavor of Linux), I'd > >> appreciate others to produce code for that. > > > Actually that was easy (in hindsight.. I took too long!) > > enough, so I've now committed > > > > > r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 > > line > > Changed paths: > > M configure > > M configure.ac > > M src/include/config.h.in > > M src/unix/sys-std.c > > > check for rl_resize_terminal() now > > > >
Re: [Rd] Latest R-devel build failing on OS X
svn checkout https://svn.r-project.org/R/trunk/ > On May 24, 2016, at 12:45 PM, frede...@ofb.net wrote: > > I agree with Martin's summary of the situation, and with the updated > NEWS entry. > > I'm not familiar with Subversion, can you tell me the command to use? > > (I tried "svn co https://svn.r-project.org/R/"; but it seems to be > downloading all branches) > > Frederick > > On Tue, May 24, 2016 at 04:30:11PM +0200, Martin Maechler wrote: >>> peter dalgaard >>>on Tue, 24 May 2016 13:47:27 +0200 writes: >> >>> I had a regression in config.site so the nightly build didn't. Retrying >>> Looks like it will build, but the ctl-R, ctl-C bug is still present on OSX >>> (w/Simon's libs). This _was_ fixed for a while, was it not? >> >> I thought it was never fixed, for readline versions 5.x (or all >> of readline_version < 6.3 ?) because the patch assumed features >> not available, e.g., for Frederik (who got compilation errors >> which I think you confirmed on pre-6 readline). >> >> I remember you having two different readlines installed on OSX >> but the standard Mac binary (from CRAN, i.e. Simon) would use >> the old readline version ? >> >> so that whole resetReadline() solution is now conditionalized inside >> >> #if defined(RL_READLINE_VERSION) && RL_READLINE_VERSION >= 0x0603 >> ... >> ... >> #endif >> >> and hence the previous code (which is buggy) is used for >> readline versions < 6.3. >> As a consequence the bug is only fixed for readline >= 6.3, >> because the current patch did not compile and hence seemed not >> appropriate for readline < 6.3 (and hence the above conditionalization). >> >> >>> (The NEWS entry is also wrong: The issue existed before readline 6.3) >> >> Aah.. you are right. The API change with 6.3 was for the other, the >> "SIGWINCH" bug. >> >> Here's a an update proposal for that NEWS entry : >> >> • The API for readline libraries >= 6.3 had changed such >> terminal window resizes where no longer properly signalled >> (PR#16604). Also, ‘Ctrl C’ in incremental search behaved >> confusingly in R (unix) consoles (PR#16603) also for older >> readline versions. These have been fixed (for readline >= >> 6.3 only), thanks to patches by Frederick Eaton. >> >> >> Martin >> >>> -pd >> >>> On 24 May 2016, at 12:55 , Martin Maechler >>> wrote: >> Can you (Frederick, Peter, Keith, but ideally others, too) confirm that you don't see any problems anymore, when building a version of R-devel from sources that are newer than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see below)? I'm asking because the question is open if these should be "back ported" to R 3.3.0 patched or not. Best regards, Martin > Martin Maechler > on Thu, 19 May 2016 11:02:48 +0200 writes: > > on Wed, 18 May 2016 15:03:31 -0700 writes: >>> Readline <= 6.2 shouldn't require the SIGWINCH patch, so >>> if older versions have trouble finding rl_resize_terminal >>> then you could wrap a macro around that part. >> I find python related patches that use >> #ifdef HAVE_RL_RESIZE_TERMINAL >> so they must have configured for that. We could and >> probably should do the same, but as a Linux_only guy >> currently (even basically only one flavor of Linux), I'd >> appreciate others to produce code for that. > Actually that was easy (in hindsight.. I took too long!) > enough, so I've now committed > > r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 line > Changed paths: > M configure > M configure.ac > M src/include/config.h.in > M src/unix/sys-std.c > check for rl_resize_terminal() now > > ... and Keith should even not see the warning anymore > (nor Peter the error, when compiling using readline 5.x instead of > 6.[23]). [...] >> >>> -- >>> Peter Dalgaard, Professor, >>> Center for Statistics, Copenhagen Business School >>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark >>> Phone: (+45)38153501 >>> Office: A 4.23 >>> 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] Latest R-devel build failing on OS X
I agree with Martin's summary of the situation, and with the updated NEWS entry. I'm not familiar with Subversion, can you tell me the command to use? (I tried "svn co https://svn.r-project.org/R/"; but it seems to be downloading all branches) Frederick On Tue, May 24, 2016 at 04:30:11PM +0200, Martin Maechler wrote: > > peter dalgaard > > on Tue, 24 May 2016 13:47:27 +0200 writes: > > > I had a regression in config.site so the nightly build didn't. > Retrying > > Looks like it will build, but the ctl-R, ctl-C bug is still present on > OSX (w/Simon's libs). This _was_ fixed for a while, was it not? > > I thought it was never fixed, for readline versions 5.x (or all > of readline_version < 6.3 ?) because the patch assumed features > not available, e.g., for Frederik (who got compilation errors > which I think you confirmed on pre-6 readline). > > I remember you having two different readlines installed on OSX > but the standard Mac binary (from CRAN, i.e. Simon) would use > the old readline version ? > > so that whole resetReadline() solution is now conditionalized inside > > #if defined(RL_READLINE_VERSION) && RL_READLINE_VERSION >= 0x0603 >... >... > #endif > > and hence the previous code (which is buggy) is used for > readline versions < 6.3. > As a consequence the bug is only fixed for readline >= 6.3, > because the current patch did not compile and hence seemed not > appropriate for readline < 6.3 (and hence the above conditionalization). > > > > (The NEWS entry is also wrong: The issue existed before readline 6.3) > > Aah.. you are right. The API change with 6.3 was for the other, the > "SIGWINCH" bug. > > Here's a an update proposal for that NEWS entry : > > • The API for readline libraries >= 6.3 had changed such >terminal window resizes where no longer properly signalled >(PR#16604). Also, ‘Ctrl C’ in incremental search behaved >confusingly in R (unix) consoles (PR#16603) also for older >readline versions. These have been fixed (for readline >= >6.3 only), thanks to patches by Frederick Eaton. > > > Martin > > > -pd > > > On 24 May 2016, at 12:55 , Martin Maechler > wrote: > > >> > >> Can you (Frederick, Peter, Keith, but ideally others, too) > >> confirm that you don't see any problems anymore, when building a > >> version of R-devel from sources that are newer > >> than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see > below)? > >> > >> I'm asking because the question is open if these should be > >> "back ported" to R 3.3.0 patched or not. > >> > >> Best regards, > >> Martin > >> > >>> Martin Maechler > >>> on Thu, 19 May 2016 11:02:48 +0200 writes: > >> > >>> > >>> on Wed, 18 May 2016 15:03:31 -0700 writes: > >> > > Readline <= 6.2 shouldn't require the SIGWINCH patch, so > > if older versions have trouble finding rl_resize_terminal > > then you could wrap a macro around that part. > >> > I find python related patches that use > >> > #ifdef HAVE_RL_RESIZE_TERMINAL > >> > so they must have configured for that. We could and > probably should do the same, but as a Linux_only guy > currently (even basically only one flavor of Linux), I'd > appreciate others to produce code for that. > >> > >>> Actually that was easy (in hindsight.. I took too long!) > >>> enough, so I've now committed > >> > >>> > > >>> r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 > line > >>> Changed paths: > >>> M configure > >>> M configure.ac > >>> M src/include/config.h.in > >>> M src/unix/sys-std.c > >> > >>> check for rl_resize_terminal() now > >>> > > >> > >>> ... and Keith should even not see the warning anymore > >>> (nor Peter the error, when compiling using readline 5.x instead of > 6.[23]). > >> > >> > >> [...] > > > -- > > Peter Dalgaard, Professor, > > Center for Statistics, Copenhagen Business School > > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > > Phone: (+45)38153501 > > Office: A 4.23 > > 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] Suggestion: mkString(NULL) should be NA
On Tue, May 24, 2016 at 5:59 PM, Gabriel Becker wrote:
> Shouldn't Rf_mkString(NULL) return (the c-level equivalent of) character()
> rather than the NA_character_?
No. It should still be safe to assume that mkString() always returns a
character vector of exactly length one. Anything else could lead to
type errors.
> An empty string and NULL aren't the same.
Exactly! So if you pass in an empty C string, you get an empty R
string, and if you pass in a null pointer you get NA.
Rf_mkString(NULL) <--> NA
Rf_mkString("") <--> ""
There is no ambiguity, and much better than segfaulting.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: mkString(NULL) should be NA
Why should Rf_mkString(NULL) produce NA_STRING instead of "" (R_BlankString)? I prefer that passing in a nil pointer would cause an error instead, as the nil may arise by accident, perhaps a pointer to freed memory, and I would like to be notified that my code is bad instead of getting a random NA_STRING. Bill Dunlap TIBCO Software wdunlap tibco.com On Tue, May 24, 2016 at 8:42 AM, Jeroen Ooms wrote: > On Thu, May 12, 2016 at 1:20 PM, Jeroen Ooms > wrote: > > I would like to propose that Rf_mkString(NULL) and Rf_mkChar(NULL) > > return NA rather than segfault. > > An example implementation: https://git.io/vroxm > > With this patch, mkChar(NULL), mkCharCE(NULL, ce) would return > NA_STRING rather than segfault at strlen(NULL). This automatically > fixes mkString(NULL) as well which wraps mkChar (See Rinlinedfuns.h). > > __ > 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] Suggestion: mkString(NULL) should be NA
Shouldn't Rf_mkString(NULL) return (the c-level equivalent of) character() rather than the NA_character_? An empty string and NULL aren't the same. It seems reasonable for Rf_mkChar to give NA_character_ though. ~G On Tue, May 24, 2016 at 8:42 AM, Jeroen Ooms wrote: > On Thu, May 12, 2016 at 1:20 PM, Jeroen Ooms > wrote: > > I would like to propose that Rf_mkString(NULL) and Rf_mkChar(NULL) > > return NA rather than segfault. > > An example implementation: https://git.io/vroxm > > With this patch, mkChar(NULL), mkCharCE(NULL, ce) would return > NA_STRING rather than segfault at strlen(NULL). This automatically > fixes mkString(NULL) as well which wraps mkChar (See Rinlinedfuns.h). > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabriel Becker, PhD Associate Scientist (Bioinformatics) Genentech Research [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: mkString(NULL) should be NA
On Thu, May 12, 2016 at 1:20 PM, Jeroen Ooms wrote: > I would like to propose that Rf_mkString(NULL) and Rf_mkChar(NULL) > return NA rather than segfault. An example implementation: https://git.io/vroxm With this patch, mkChar(NULL), mkCharCE(NULL, ce) would return NA_STRING rather than segfault at strlen(NULL). This automatically fixes mkString(NULL) as well which wraps mkChar (See Rinlinedfuns.h). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R without graphics
On 5/23/16 10:46 PM, Prof Brian Ripley wrote: On 24/05/2016 00:54, Simon Urbanek wrote: Um... any reason why you don't simply disable aqua? That file is only compiled if you enable aqua - it has really nothing to do with grDevices ... Also, you can specify a compiler for Objective-C separately and the manual advises you to do so (to specify Apple's clang). Tried that, but I have to use an old version of clang that can't handle the code. But --with-aqua=no was the solution. On May 23, 2016, at 7:44 PM, Mick Jordan wrote: Is it possible to configure and build an R without any graphics support. I..e no grDevices or graphics packages? I tried "--with-x=no --with-cairo=no --with-grDevices=no --with-graphics=no" Inventing flags does not help you: use configure --help to see what is supported (as the manual says). I have learnt that R manuals are frequently inaccurate or out of date. So from the ./configure script: Optional Packages: --with-PACKAGE[=ARG]use PACKAGE [ARG=yes] which is why I tried --with-grDevices=no Reading the manual is faster than posting (and posting Mac-specific Qs to R-sig-mac is more likely to get an informed response). I don't need this kind of grief. I hereby sign off from posting to this list. Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Latest R-devel build failing on OS X
> peter dalgaard > on Tue, 24 May 2016 13:47:27 +0200 writes: > I had a regression in config.site so the nightly build didn't. Retrying > Looks like it will build, but the ctl-R, ctl-C bug is still present on OSX (w/Simon's libs). This _was_ fixed for a while, was it not? I thought it was never fixed, for readline versions 5.x (or all of readline_version < 6.3 ?) because the patch assumed features not available, e.g., for Frederik (who got compilation errors which I think you confirmed on pre-6 readline). I remember you having two different readlines installed on OSX but the standard Mac binary (from CRAN, i.e. Simon) would use the old readline version ? so that whole resetReadline() solution is now conditionalized inside #if defined(RL_READLINE_VERSION) && RL_READLINE_VERSION >= 0x0603 ... ... #endif and hence the previous code (which is buggy) is used for readline versions < 6.3. As a consequence the bug is only fixed for readline >= 6.3, because the current patch did not compile and hence seemed not appropriate for readline < 6.3 (and hence the above conditionalization). > (The NEWS entry is also wrong: The issue existed before readline 6.3) Aah.. you are right. The API change with 6.3 was for the other, the "SIGWINCH" bug. Here's a an update proposal for that NEWS entry : • The API for readline libraries >= 6.3 had changed such terminal window resizes where no longer properly signalled (PR#16604). Also, ‘Ctrl C’ in incremental search behaved confusingly in R (unix) consoles (PR#16603) also for older readline versions. These have been fixed (for readline >= 6.3 only), thanks to patches by Frederick Eaton. Martin > -pd > On 24 May 2016, at 12:55 , Martin Maechler wrote: >> >> Can you (Frederick, Peter, Keith, but ideally others, too) >> confirm that you don't see any problems anymore, when building a >> version of R-devel from sources that are newer >> than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see below)? >> >> I'm asking because the question is open if these should be >> "back ported" to R 3.3.0 patched or not. >> >> Best regards, >> Martin >> >>> Martin Maechler >>> on Thu, 19 May 2016 11:02:48 +0200 writes: >> >>> >>> on Wed, 18 May 2016 15:03:31 -0700 writes: >> > Readline <= 6.2 shouldn't require the SIGWINCH patch, so > if older versions have trouble finding rl_resize_terminal > then you could wrap a macro around that part. >> I find python related patches that use >> #ifdef HAVE_RL_RESIZE_TERMINAL >> so they must have configured for that. We could and probably should do the same, but as a Linux_only guy currently (even basically only one flavor of Linux), I'd appreciate others to produce code for that. >> >>> Actually that was easy (in hindsight.. I took too long!) >>> enough, so I've now committed >> >>> >>> r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 line >>> Changed paths: >>> M configure >>> M configure.ac >>> M src/include/config.h.in >>> M src/unix/sys-std.c >> >>> check for rl_resize_terminal() now >>> >> >>> ... and Keith should even not see the warning anymore >>> (nor Peter the error, when compiling using readline 5.x instead of 6.[23]). >> >> >> [...] > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > 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] Latest R-devel build failing on OS X
On my machine (iMac w/ El Capitan (10.11.4)), svn rev. 70662 builds without any errors (and the warning I mentioned before is now gone too). K > On May 24, 2016, at 6:55 AM, Martin Maechler > wrote: > > > Can you (Frederick, Peter, Keith, but ideally others, too) > confirm that you don't see any problems anymore, when building a > version of R-devel from sources that are newer > than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see below)? > > I'm asking because the question is open if these should be > "back ported" to R 3.3.0 patched or not. > > Best regards, > Martin > >> Martin Maechler >>on Thu, 19 May 2016 11:02:48 +0200 writes: > >> >>on Wed, 18 May 2016 15:03:31 -0700 writes: > Readline <= 6.2 shouldn't require the SIGWINCH patch, so if older versions have trouble finding rl_resize_terminal then you could wrap a macro around that part. > >>> I find python related patches that use > >>> #ifdef HAVE_RL_RESIZE_TERMINAL > >>> so they must have configured for that. We could and >>> probably should do the same, but as a Linux_only guy >>> currently (even basically only one flavor of Linux), I'd >>> appreciate others to produce code for that. > >> Actually that was easy (in hindsight.. I took too long!) >> enough, so I've now committed > >> >> r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 line >> Changed paths: >> M configure >> M configure.ac >> M src/include/config.h.in >> M src/unix/sys-std.c > >> check for rl_resize_terminal() now >> > >> ... and Keith should even not see the warning anymore >> (nor Peter the error, when compiling using readline 5.x instead of 6.[23]). > > >[...] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Latest R-devel build failing on OS X
I had a regression in config.site so the nightly build didn't. Retrying Looks like it will build, but the ctl-R, ctl-C bug is still present on OSX (w/Simon's libs). This _was_ fixed for a while, was it not? (The NEWS entry is also wrong: The issue existed before readline 6.3) -pd On 24 May 2016, at 12:55 , Martin Maechler wrote: > > Can you (Frederick, Peter, Keith, but ideally others, too) > confirm that you don't see any problems anymore, when building a > version of R-devel from sources that are newer > than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see below)? > > I'm asking because the question is open if these should be > "back ported" to R 3.3.0 patched or not. > > Best regards, > Martin > >> Martin Maechler >>on Thu, 19 May 2016 11:02:48 +0200 writes: > >> >>on Wed, 18 May 2016 15:03:31 -0700 writes: > Readline <= 6.2 shouldn't require the SIGWINCH patch, so if older versions have trouble finding rl_resize_terminal then you could wrap a macro around that part. > >>> I find python related patches that use > >>> #ifdef HAVE_RL_RESIZE_TERMINAL > >>> so they must have configured for that. We could and >>> probably should do the same, but as a Linux_only guy >>> currently (even basically only one flavor of Linux), I'd >>> appreciate others to produce code for that. > >> Actually that was easy (in hindsight.. I took too long!) >> enough, so I've now committed > >> >> r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 line >> Changed paths: >> M configure >> M configure.ac >> M src/include/config.h.in >> M src/unix/sys-std.c > >> check for rl_resize_terminal() now >> > >> ... and Keith should even not see the warning anymore >> (nor Peter the error, when compiling using readline 5.x instead of 6.[23]). > > >[...] -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 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] Latest R-devel build failing on OS X
Can you (Frederick, Peter, Keith, but ideally others, too) confirm that you don't see any problems anymore, when building a version of R-devel from sources that are newer than (or equal to) svn revision 70632 (2016-05-19 10:59:51, see below)? I'm asking because the question is open if these should be "back ported" to R 3.3.0 patched or not. Best regards, Martin > Martin Maechler > on Thu, 19 May 2016 11:02:48 +0200 writes: > > on Wed, 18 May 2016 15:03:31 -0700 writes: >>> Readline <= 6.2 shouldn't require the SIGWINCH patch, so >>> if older versions have trouble finding rl_resize_terminal >>> then you could wrap a macro around that part. >> I find python related patches that use >> #ifdef HAVE_RL_RESIZE_TERMINAL >> so they must have configured for that. We could and >> probably should do the same, but as a Linux_only guy >> currently (even basically only one flavor of Linux), I'd >> appreciate others to produce code for that. > Actually that was easy (in hindsight.. I took too long!) > enough, so I've now committed > > r70632 | maechler | 2016-05-19 10:59:51 +0200 (Thu, 19 May 2016) | 1 line > Changed paths: > M configure > M configure.ac > M src/include/config.h.in > M src/unix/sys-std.c > check for rl_resize_terminal() now > > ... and Keith should even not see the warning anymore > (nor Peter the error, when compiling using readline 5.x instead of 6.[23]). [...] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
