I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2):
$> R --vanilla
x <- c(0L, -2e9:2e9)
# > Segmentation fault
Tried to reproduce on Linux but the above worked as expected. Not an
issue merely with the length of the vector; for example, x <-
rep_len(1:10, 1e10) works, though th
> Hugh Parsonage
> on Tue, 8 Sep 2020 18:08:11 +1000 writes:
> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2):
> $> R --vanilla
> x <- c(0L, -2e9:2e9)
> # > Segmentation fault
> Tried to reproduce on Linux but the above worked as expected.
> Martin Maechler
> on Tue, 8 Sep 2020 10:40:24 +0200 writes:
> Hugh Parsonage
> on Tue, 8 Sep 2020 18:08:11 +1000 writes:
>> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2):
>> $> R --vanilla
>> x <- c(0L, -2e9:2e9)
>> # > Segmenta
Thanks, Alex.
That might be good enough for me for this particular concern; in the
absence of a language specification specifying my behaviour and
referring to precedent seems like a reasonable fall back.
Dan
On Tue, 2020-09-08 at 09:33 +0200, Bertram, Alexander wrote:
> Hi Dan,
>
> For what it
The general principle is that R packages are only allowed to use what is
documented in the R help (? command) and in Writing R Extensions. The
former covers what is allowed from R code in extensions, the latter
mostly what is allowed from C code in extensions (with some references
to Fortran
Thanks Martin. On further testing, it seems that the segmentation
fault can only occur when the amount of obtainable memory is
sufficiently high. On my machine (admittedly with other processes
running):
$ R --vanilla --max-mem-size=30G -e "x <- c(0L, -2e9:2e9)"
Segmentation fault
$ R --vanilla -
Dan,
Sounds like a cool project! Response to one of your questions inline
On Mon, Sep 7, 2020 at 4:24 AM Dan Kortschak via R-devel <
r-devel@r-project.org> wrote:
>
> The last question is more a question of interest in design strategy,
> and the answer may have been lost to time. In order to red
Hi Dan,
For what it's worth, Renjin requires LISTSXPs to hold either a LISTSXP or a
NULL, and this appears to be largely the case in practice based on running
tests for thousands of packages (including cross compiled C code). I can
only remember it being briefly an issue with the rlang package, bu
Thanks, Tomas.
This is unfortunate. Calling between Go and C is not cheap; the gc
implementation of the Go compiler (as opposed to gccgo) uses different
calling conventions from C and there are checks to ensure that Go
allocated memory pointers do not leak into C code. For this reason I
wanted t
Thanks, Gabriel.
On Mon, 2020-09-07 at 14:38 -0700, Gabriel Becker wrote:
> I cannot speak to initial intent, perhaps others can. I can say that
> there is at least one place where the difference between R_NilValue
> and NULL is very important as of right now. The current design of the
> ALTREP
On 9/8/20 11:47 AM, Dan Kortschak wrote:
Thanks, Tomas.
This is unfortunate. Calling between Go and C is not cheap; the gc
implementation of the Go compiler (as opposed to gccgo) uses different
calling conventions from C and there are checks to ensure that Go
allocated memory pointers do not l
Thanks, Tomas.
This is unfortunate. Calling between Go and C is not cheap; the gc
implementation of the Go compiler (as opposed to gccgo) uses different
calling conventions from C and there are checks to ensure that Go
allocated memory pointers do not leak into C code. For this reason I
wanted t
On Tue, 2020-09-08 at 12:08 +0200, Tomas Kalibera wrote:
> I am not sure if I understand correctly, but if you were accessing
> directly the memory of SEXPs from Go implementation instead of
> calling
> through exported access functions documented in WRE, that would be a
> really bad idea. Of cours
On 9/8/20 1:13 PM, Dan Kortschak wrote:
On Tue, 2020-09-08 at 12:08 +0200, Tomas Kalibera wrote:
I am not sure if I understand correctly, but if you were accessing
directly the memory of SEXPs from Go implementation instead of
calling
through exported access functions documented in WRE, that wou
On Tue, Sep 8, 2020 at 4:12 AM Tomas Kalibera wrote:
>
>
> The general principle is that R packages are only allowed to use what is
> documented in the R help (? command) and in Writing R Extensions. The
> former covers what is allowed from R code in extensions, the latter
> mostly what is allowed
I was not. I was explaining why my expectations exist. I honestly
surprised that this would be misinterpreted.
Dan
On Tue, 2020-09-08 at 13:47 +0200, Tomas Kalibera wrote:
> Please don't use this list for advertising on other languages, there
> may be other lists for that.
__
On Tue, 8 Sep 2020, Hadley Wickham wrote:
On Tue, Sep 8, 2020 at 4:12 AM Tomas Kalibera wrote:
The general principle is that R packages are only allowed to use what is
documented in the R help (? command) and in Writing R Extensions. The
former covers what is allowed from R code in extension
On Tue, 8 Sep 2020, Hugh Parsonage wrote:
Thanks Martin. On further testing, it seems that the segmentation
fault can only occur when the amount of obtainable memory is
sufficiently high. On my machine (admittedly with other processes
running):
$ R --vanilla --max-mem-size=30G -e "x <- c(0L, -
Unfortunately I only get
[Thread 21752.0x4aa8 exited with code 3221225477]
[Thread 21752.0x4514 exited with code 3221225477]
[Thread 21752.0x3f10 exited with code 3221225477]
[Inferior 1 (process 21752) exited with code 0305]
(I'm guessing I would need to build an instrumented version of
On Tue, 8 Sep 2020, Martin Maechler wrote:
Martin Maechler
on Tue, 8 Sep 2020 10:40:24 +0200 writes:
Hugh Parsonage
on Tue, 8 Sep 2020 18:08:11 +1000 writes:
>> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2):
>> $> R --vanilla
>> x <- c(0L, -2e9:2e9)
On 9/8/20 4:48 PM, Hugh Parsonage wrote:
Unfortunately I only get
[Thread 21752.0x4aa8 exited with code 3221225477]
[Thread 21752.0x4514 exited with code 3221225477]
[Thread 21752.0x3f10 exited with code 3221225477]
[Inferior 1 (process 21752) exited with code 0305]
(I'm guessing I woul
> luke-tierney
> on Tue, 8 Sep 2020 09:42:43 -0500 (CDT) writes:
> On Tue, 8 Sep 2020, Martin Maechler wrote:
>>> Martin Maechler
>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes:
>>
>>> Hugh Parsonage
>>> on Tue, 8 Sep 2020 18:08:11 +1000 writes:
On Tue, 8 Sep 2020, Martin Maechler wrote:
luke-tierney
on Tue, 8 Sep 2020 09:42:43 -0500 (CDT) writes:
> On Tue, 8 Sep 2020, Martin Maechler wrote:
>>> Martin Maechler
>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes:
>>
>>> Hugh Parsonage
>>> on Tue, 8 Sep 2
Hello,
I got a notification regarding a failure to pass incoming checks
automatically after a CRAN submission. The details are given here:
https://win-builder.r-project.org/incoming_pretest/diveMove_1.5.0_20200908_191325/
The only visible issue is a NOTE from the macosx build, with the very
ter
Thank you everyone who has helped a non-R developer attempt to build a
tool to extend the R ecosystem.
>From what I've read, it looks like I should document the sexp internals
package I provide as a here-be-dragons package, keep the hand-holding
level of the rgo tool using Cgo calls to perform dat
On Tue, Sep 8, 2020 at 5:20 PM Tomas Kalibera wrote:
>
> On 9/8/20 4:48 PM, Hugh Parsonage wrote:
> > Unfortunately I only get
> >
> > [Thread 21752.0x4aa8 exited with code 3221225477]
> > [Thread 21752.0x4514 exited with code 3221225477]
> > [Thread 21752.0x3f10 exited with code 3221225477]
> > [
On Tue, Sep 8, 2020 at 11:44 PM Jeroen Ooms wrote:
>
> On Tue, Sep 8, 2020 at 5:20 PM Tomas Kalibera
> wrote:
> >
> > On 9/8/20 4:48 PM, Hugh Parsonage wrote:
> > > Unfortunately I only get
> > >
> > > [Thread 21752.0x4aa8 exited with code 3221225477]
> > > [Thread 21752.0x4514 exited with code
Am I being too optimistic in expecting this (mixing and matching
matrices and Matrices) to work? If x is a matrix and m is a Matrix,
replacing a commensurately sized sub-matrix of x with m throws "number
of items to replace is not a multiple of replacement length" ...
x <- matrix(0,nrow=3,n
Hello,
R 4.0.2 on Ubuntu 20.04, sessionInfo() below.
I can reproduce this, sort of. The error I'm getting is different:
x[rr, cc] <- m
#Error in x[rr, cc] <- m : replacement has length zero
But if I check lengths and dimensions, they are identical().
identical(length(x[rr, cc]), length(m))
#
On 08.09.2020 21:34, Sebastian P. Luque wrote:
Hello,
I got a notification regarding a failure to pass incoming checks
automatically after a CRAN submission. The details are given here:
https://win-builder.r-project.org/incoming_pretest/diveMove_1.5.0_20200908_191325/
The only visible issu
I am unable to set break or use gdb with any success when I use that version.
On linux I would do R -d gdb but this gives "unknown option '-d' "
while gdb R.exe (in the same directory as the debug version) gives the
same output as before.
I'm happy to help but I appreciate this list might not be
31 matches
Mail list logo
