Brilliant,
Thanks for the thread Martin. Exactly what I needed.
According to Duncan Murdoch, its an RStudio bug
(https://stat.ethz.ch/pipermail/r-help/2016-March/437415.html).
This fix worked from the same thread fixed the issue
https://stat.ethz.ch/pipermail/r-help/2016-March/437397.html
On 05/18/2016 06:40 PM, Aedin Culhane wrote:
Hi
The R logo, in Bioc help files is very large when viewed in RStudio help
window. I don't see the same, when I view R help files. See enclosed
images.
I see only big logos; there is this thread
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
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
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
> 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
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
> 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
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
Dear R-devel,
The latest version of R-devel (05-17) is throwing an error for me when building
on OS X (v 10.11.4):
making Rembedded.d from Rembedded.c
making dynload.d from dynload.c
making system.d from system.c
making sys-unix.d from sys-unix.c
making sys-std.d from sys-std.c
making X11.d
On 18/05/16 13:50, Martin Maechler wrote:
Mikko Korpela
on Wed, 18 May 2016 13:05:24 +0300 writes:
> I get an error when running "make check" after building
> R-devel r70629 on Ubuntu 14.04.
> Here are the relevant
> lines in the file
G'day Martin,
On Wed, 18 May 2016 12:50:21 +0200
Martin Maechler wrote:
> > Mikko Korpela
> > on Wed, 18 May 2016 13:05:24 +0300 writes:
>
> > I get an error when running "make check" after building
> > R-devel r70629
> Mikko Korpela
> on Wed, 18 May 2016 13:05:24 +0300 writes:
> I get an error when running "make check" after building
> R-devel r70629 on Ubuntu 14.04.
> Here are the relevant
> lines in the file "reg-tests-1c.Rout.fail":
>> ##
Hi,
I have noticed that the run times for MCMCglmm models (mainly written in
C/C++) have suddenly jumped up on Linux machines (Ubuntu/Linaro 4.6.4
and Scientific Linux 6.6) yet they have remained stable on Windows
where they run much faster than on Linux. I wondered whether something
had
I get an error when running "make check" after building R-devel r70629
on Ubuntu 14.04. Here are the relevant lines in the file
"reg-tests-1c.Rout.fail":
> ## m1z uses match(x, *) with length(x) == 1 and failed in R 3.3.0
> ## PR#16909 - a consequence of the match() bug; check here too:
15 matches
Mail list logo