Re: [Rd] Operations with long altrep vectors cause segfaults on Windows

> 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) >> # >

Re: [Rd] some questions about R internal SEXP types

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

Re: [Rd] some questions about R internal SEXP types

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

[Rd] Operations with long altrep vectors cause segfaults on Windows

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

Re: [Rd] Operations with long altrep vectors cause segfaults on Windows

> 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.

Re: [Rd] some questions about R internal SEXP types

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

Re: [Rd] some questions about R internal SEXP types

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.

Re: [Rd] some questions about R internal SEXP types

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

Re: [Rd] [External] Re: some questions about R internal SEXP types

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

Re: [Rd] some questions about R internal SEXP types

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,

Re: [Rd] some questions about R internal SEXP types

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

Re: [Rd] some questions about R internal SEXP types

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

Re: [Rd] some questions about R internal SEXP types

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

Re: [Rd] some questions about R internal SEXP types

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

Re: [Rd] some questions about R internal SEXP types

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

Re: [Rd] some questions about R internal SEXP types

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

Re: [Rd] [External] Re: Operations with long altrep vectors cause segfaults on Windows

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,

Re: [Rd] [External] Re: Operations with long altrep vectors cause segfaults on Windows

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

Re: [Rd] [External] Re: Operations with long altrep vectors cause segfaults on Windows

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)

Re: [Rd] [External] Re: Operations with long altrep vectors cause segfaults on Windows

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

Re: [Rd] [External] Re: Operations with long altrep vectors cause segfaults on Windows

> 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

Re: [Rd] [External] Re: Operations with long altrep vectors cause segfaults on Windows

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

Re: [Rd] [External] Re: Operations with long altrep vectors cause segfaults on Windows

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

Re: [Rd] [External] Re: Operations with long altrep vectors cause segfaults on Windows

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] > >

[Rd] more Matrix weirdness

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 <-

[Rd] failing automatic incoming check

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

Re: [Rd] some questions about R internal SEXP types

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

[Bioc-devel] Hotfix rejected by git

Hello! We’ve identified a small bug in our Chicago package that we’ve updated on the master branch and now wanted to update retrospectively in releases 3.9, 3.10 and 3.11. I initially updated and pushed just the master branch, and got this: $ git push remote: fatal: this operation must be

Re: [Bioc-devel] Hotfix rejected by git

Yes I can see the updates 1.17.1 on the master branch on git.bioconductor.org. We are looking into the RSS git ERROR. We only allow corrections to the current release (RELEASE_3_11) and devel (master) branches. We do not allow updates to past releases for legacy and reproducibility.

Re: [Bioc-devel] Hotfix rejected by git

Hi Mikhail, The RSS issue should be fixed now. Best regards, Nitesh > On Sep 8, 2020, at 7:45 AM, Shepherd, Lori > wrote: > > Yes I can see the updates 1.17.1 on the master branch on > git.bioconductor.org . We are looking into the > RSS git ERROR. > > We

Re: [Bioc-devel] fetch upstream of an existing package

The RSS error should be fixed. On Sep 8, 2020, at 7:58 AM, Shepherd, Lori mailto:lori.sheph...@roswellpark.org>> wrote: I RSS feed ERROR did not prevent the changes from being pushed to git.bioconductor.org . The changes should be reflected in either today's or

Re: [Bioc-devel] maintainer access to scater

Hi Aaron, Alan should be able to access the package now. Please change the the DESCRIPTION file of the package to reflect the change in maintainer. Nitesh > On Sep 7, 2020, at 1:40 PM, Aaron Lun > wrote: > > For record-keeping purposes: > > We are transitioning maintainership of scater

Re: [Bioc-devel] Hotfix rejected by git

Great, thanks a lot Nitesh. Do I need to push again? Many thanks, Mikhail From: Nitesh Turaga Date: Tuesday, 8 September 2020 at 16:34 To: "Shepherd, Lori" Cc: "Spivakov, Mikhail" , "bioc-devel@r-project.org" Subject: Re: [Bioc-devel] Hotfix rejected by git This email from

Re: [Bioc-devel] Maintenance of MetaNeighbor package

Hi Everyone, Thank you for your prompt response. Stephan should be able to access the package as soon as he adds SSH keys to the server. I will be sending Stephan a private email regarding his credentials to access the Bioconductor git credentials application. Best, Nitesh > On Sep 3,

Re: [Bioc-devel] Pushing to Bioconductor repo gives errors

The RSS feed issue has been taken care of. The bug fix was issued today at 10 AM Eastern standard time. This should not be showing up on your push to the git server anymore. Best, Nitesh > On Sep 7, 2020, at 8:44 AM, Nitesh Turaga wrote: > > Your push went through. This is a different

[Bioc-devel] Bioconductor Release 3.12 Schedule Posted

The Bioconductor Release 3.12 Schedule has been posted and is tentatively scheduled for October 28th. Important deadlines can be found on the website and will be posted here and on the bioc-devel at r-project.org mailing list. As a quick summary: October 2: New package submission deadline

[Bioc-devel] Build issues under macOS

Hi, I've begun the submission of a new package [1], but I'm encountering some errors in the automated build under macOS on merida1 and would greatly appreciate any assistance. I've currently tried to build twice, once upon initial submission and once after updating the DESCRIPTION to remove a