> > Is glibc is actually compatible (and/or is gnu libiconv essentially the
> > only path)?
>
> R is built daily on Fedora 21 Linux which uses glibc 2.20 and has been for at
> least
> a decade with that and earlier versions of glibc. No problems with installing
> using glibc have been reported i
On Fri, May 15, 2015 at 8:01 AM, Simon Urbanek
wrote:
> On May 13, 2015, at 2:28 PM, Henrik Bengtsson
> wrote:
>
>> While at it: 'Makevars' is an R invention (i.e. documentation of it
>> is only available through the R docs), correct? /Henrik
>>
>
> Well, it's just a Makefile fragment that get
Changing from c(x)[...] to x[...] without a pre-test does not seem to
cause any issues on CRAN or BIOC so that is done now in R-devel and
R-patched.
Best,
luke
On Wed, 13 May 2015, Henrik Bengtsson wrote:
As kindly pointed out to me (oh my decaying gray matter), is.object()
is better suited f
On 16 May 2015 at 12:11, Hin-Tak Leung wrote:
| The quickest fix is to add cmprsk to the recommended list , and that's is an
R-devel issue.
Given that the set of recommended packages seems to change about once a
decade (give or take a few years as measurement error on my side) I am not
sure I ag
> On May 16, 2015, at 6:11 AM, Hin-Tak Leung
> wrote:
>
>
>
> --
> On Sat, May 16, 2015 8:04 AM BST Uwe Ligges wrote:
>
>> Not sure why this goes to R-devel. You just could have asked the
>> maintainer. Terry Therneau is aware of it and promised he will fix it.
>
--
On Sat, May 16, 2015 8:04 AM BST Uwe Ligges wrote:
>Not sure why this goes to R-devel. You just could have asked the
>maintainer. Terry Therneau is aware of it and promised he will fix it.
>
The quickest fix is to add cmprsk to the recommended list , and that's i
Not sure why this goes to R-devel. You just could have asked the
maintainer. Terry Therneau is aware of it and promised he will fix it.
Best,
Uwe Ligges
On 16.05.2015 07:22, Hin-Tak Leung wrote:
'make check-all' for current R has been showing this error in the middle
for a few months now - any
Dear Martin,
thank you for the food for thought. My package does not depend on MSigDB
(it implements something better than MSigDB), but being able to work with
MSigDB (for comparative purposes) is important. Also, Bioconductor makes
sense only if you really want to take advantage of the Bioconduct
