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-sv
> 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 direct
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 acc
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://
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,
> 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
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
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
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 sho
> Martin Maechler
> on Thu, 19 May 2016 10:26:44 +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 m
>
> 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_R
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.
The isearch C-c bug has existed forever, according to Chet Ramey. Yes,
I had to retrain myself to use C-g to exit isearch but it's confus
Spoke too soon, both systems now build, but neither has the original bugs
fixed
(Incidentally, I realized why the ctl-R...ctl-C bug never bit me: The emacs
habit is to exit isearch with ctl-G and that works flawlessly.)
-pd
> On 18 May 2016, at 22:40 , peter dalgaard wrote:
>
> Ah, got
Ah, got it. For some ancient reason config.site on that machine had
LDFLAGS=-L/usr/X11R6/lib
in config.site, and that prevented configure from inserting -L /usr/local/lib,
so linked /usr/lib/libreadline.dylib, which is the Apple-supplied one, which
possibly is really libedit...
-p
> On 18 M
> On 18 May 2016, at 18:54 , Martin Maechler wrote:
>
>
>> Yes, the nightly build is broken in a similar, but different way. See below.
>> Both seem to be readline related, so Frederick Eaton's patches, which Martin
>> committed yesterday are the likely culprit. I had actually tested them and
Thanks for the fix, Martin.
The build runs smoothly now, with just a warning remaining:
sys-std.c:1002:7: warning: implicit declaration of function
'rl_resize_terminal' is invalid in C99
[-Wimplicit-function-declaration]
rl_resize_terminal();
^
1 war
> Yes, the nightly build is broken in a similar, but different way. See below.
> Both seem to be readline related, so Frederick Eaton's patches, which Martin
> committed yesterday are the likely culprit. I had actually tested them and
> things seemed to work, but it was on a different machine a
Yes, the nightly build is broken in a similar, but different way. See below.
Both seem to be readline related, so Frederick Eaton's patches, which Martin
committed yesterday are the likely culprit. I had actually tested them and
things seemed to work, but it was on a different machine and not a
18 matches
Mail list logo
