My comment is about the definition of HAVE_UINTPTR_T in Rconfig.h. stdint.h
is coming with (g)libc, therefore unlikely to change/appear/disappear
(unless kernel and a bit of the OS changes), therefore may not be a
realistic concern. On the other hand mixing compilers is frequent, but this
is not do
> On Jan 1, 2017, at 5:12 PM, Laurent Gautier wrote:
>
>
>
> 2017-01-01 8:28 GMT-05:00 Prof Brian Ripley :
> On 29/12/2016 15:55, Simon Urbanek wrote:
> The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback with
> HAVE_UINTPTR_T but that config flag is not exported in Rconf
2017-01-01 8:28 GMT-05:00 Prof Brian Ripley :
> On 29/12/2016 15:55, Simon Urbanek wrote:
>
>> The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback
>> with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h.
>> Should be now fixed in R-devel - please check if that
On 1 January 2017 at 13:28, Prof Brian Ripley wrote:
| On 29/12/2016 15:55, Simon Urbanek wrote:
| > The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback
with HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. Should
be now fixed in R-devel - please check if th
On 29/12/2016 15:55, Simon Urbanek wrote:
The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback with
HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. Should be now
fixed in R-devel - please check if that works for you.
Rconfig.h would be appropriate if Rint
Thanks for looking at it. Having HAVE_UINTPTR_T defined in Rconfig.h
should fix the issue. Will the fix make it to R-3.3.3 (if that point
release is planned, or R-3.3.2-patched), or will it only be with R-3.4 ?
L.
PS: I am forwarding a thank you note to the reporter of the problem on the
rpy2 i
The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback with
HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. Should be now
fixed in R-devel - please check if that works for you.
Thanks,
Simon
> On Dec 26, 2016, at 11:25 PM, Laurent Gautier wrote:
>
> Hi,
>
Hi,
I was recently pointed out that a definition in Rinterface.h can be conflicting
with a definition in stdint.h:
/usr/include/R/Rinterface.h has:
typedef unsigned long uintptr_t;
/usr/include/stdint.h has:
typedef unsigned int uintptr_t;
(when 32bit platform complete definition is:
#if __W
somewhat one the side,
l = list(1)
l[[2]]
# error, index out of bounds
l[2][[1]]
# NULL
that is, we can't extract from l any element at an index exceeding the
list's length (if we could, it would have been NULL or some sort of
_NA_list), but we can extract a sublist at an
On Sun, 15 Mar 2009, Wacek Kusnierczyk wrote:
Stavros Macrakis wrote:
Well, that's one issue. But another is that there should be a
specification addressed to users, who should not have to understand
internals.
this should really be taken seriously.
Well, the lack of such a specificatio
On Sun, 15 Mar 2009, Stavros Macrakis wrote:
The semantics of [ and [[ don't seem to be fully specified in the
Reference manual. In particular, I can't find where the following
cases are covered:
cc <- c(1); ll <- list(1)
cc[3]
[1] NA
OK, RefMan says: If i is positive and exceeds length(x
Just a couple of inline comments down below:
On 15/03/2009 5:30 PM, Stavros Macrakis wrote:
Duncan,
Thanks for the reply.
On Sun, Mar 15, 2009 at 4:43 PM, Duncan Murdoch wrote:
On 15/03/2009 2:31 PM, Stavros Macrakis wrote:
dput(ll[3])
list(NULL)
? i is positive and exceeds length(x); why
Stavros Macrakis wrote:
>
> Well, that's one issue. But another is that there should be a
> specification addressed to users, who should not have to understand
> internals.
>
this should really be taken seriously.
vQ
__
R-devel@r-project.org mailin
Duncan,
Thanks for the reply.
On Sun, Mar 15, 2009 at 4:43 PM, Duncan Murdoch wrote:
> On 15/03/2009 2:31 PM, Stavros Macrakis wrote:
>> dput(ll[3])
>> list(NULL)
>> ? i is positive and exceeds length(x); why isn't this list(NA)?
>
> Because the sentence you read was talking about "simple vecto
On 15/03/2009 2:31 PM, Stavros Macrakis wrote:
The semantics of [ and [[ don't seem to be fully specified in the
Reference manual. In particular, I can't find where the following
cases are covered:
cc <- c(1); ll <- list(1)
cc[3]
[1] NA
OK, RefMan says: If i is positive and exceeds length(
The semantics of [ and [[ don't seem to be fully specified in the
Reference manual. In particular, I can't find where the following
cases are covered:
> cc <- c(1); ll <- list(1)
> cc[3]
[1] NA
OK, RefMan says: If i is positive and exceeds length(x) then the
corresponding selection is NA.
> dpu
16 matches
Mail list logo