Re: [R-pkg-devel] Additional issues: Intel segfault

[Ivan Krylov via R-package-devel]

В Sat, 2 Mar 2024 02:07:47 +
Murray Efford  пишет:

> Gabor suggested https://github.com/r-hub/rhub2 and that worked like a
> charm. A check there on the Intel platform found no errors in my
> present version of secrdesign, so I'll resubmit with confidence.

Thank you for letting me know! Having this as a container simplifies a
lot of things.

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Additional issues: Intel segfault

[Murray Efford]

Thanks, Ivan, for looking into this and providing some reassurance. Gabor 
suggested https://github.com/r-hub/rhub2 and that worked like a charm. A check 
there on the Intel platform found no errors in my present version of 
secrdesign, so I'll resubmit with confidence. The original error remains a 
mystery, but not one I need to pursue.
Murray

From: Ivan Krylov 
Sent: Friday, 1 March 2024 21:46
To: Murray Efford 
Cc: R-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] Additional issues: Intel segfault

В Fri, 1 Mar 2024 07:42:01 +
Murray Efford  пишет:

> R CMD check suggests it is most likely in the Examples for
> 'validate', but all code there is wrapped in \dontrun{}.

The crash happens after q('no'), suggesting a corruption in the heap or
in the R memory manager. At least it's a null pointer being
dereferenced and not a 0xRANDOM_LOOKING_NUMBER: this limits the impact
of the problem.

I don't know if anyone created an easily reproducible container with an
Intel build of R (there's https://hub.docker.com/r/intel/oneapi, but
aren't the compilers themselves supposed to be not redistributable?),
so you will most likely have to follow
https://www.stats.ox.ac.uk/pub/bdr/Intel/README.txt and
https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Intel-compilers
manually, compiling R using Intel compilers yourself in order to
reproduce this.

I think it would be great if CRAN checking machines used a just-in-time
debugger to provide C-level backtraces at the place of the crash. For
Windows, such a utility does exist [*], but I recently learned that the
glibc `catchsegv` program (and most other similar programs) used to
perform shared object preloading (before being thrown out of the
codebase altogether), which is more intrusive than it could be. A proof
of concept using GDB on Linux can be shown to work:

R -d gdb \
 --debugger-args='-batch -ex run -ex bt -ex c -ex q' \
 -e '
  Rcpp::sourceCpp(code =
   "//[[Rcpp::export]]\nvoid rip() { *(double*)(42) = 42; }"
  ); rip()
 '

--
Best regards,
Ivan

[*] https://github.com/jrfonseca/drmingw

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] capture "->"

[avi.e.gross]

Adrian,
 
That is indeed a specialized need albeit not necessarily one that cannot be 
done by requiring an alternate way of typing a formula that avoids being 
something the parser sees as needed to do at that level.
 
In this case, my other questions become moot as I assume the global assignment 
operator and somethings like assign(“xyz”, 5) will not be in the way.
 
What I was wondering about is what happens if you temporarily disable the 
meaning of the assignment operator <- and turn it back on after.
 
In the following code, for no reason, I redefine + to mean – and then undo it:
 
 
> temp <- `+`
> `+` <- `-`
> 5 + 3
[1] 2
> `+` <- temp
> 5 + 3
[1] 8
 
I have no idea if a similar technique could save and later restore the meaning 
of <- and replace it with something appropriate so that an expression using it 
is not evaluated the same way and leaves it alone long enough …
 
Of course, even if this works, it could cause side effects if anything else is 
done between changes that invokes it (maybe not likely) or the change back is 
not done perhaps due to an error interruption.
 
 
Avi
 
From: Adrian Dușa  
Sent: Friday, March 1, 2024 11:38 AM
To: avi.e.gr...@gmail.com
Cc: r-devel ; Dmitri Popavenko 

Subject: Re: [Rd] capture "->"
 
I would also be interested in that.
For me, this is interesting for my QCA package, over which Dmitri and I have 
exchanged a couple of messages.
The "<-" operator is used to denote necessity, and the "->" is used for 
sufficiency.
 
Users often make use of Boolean expressions such as A*B + C -> Y
(to calculate if the expression A*B + C is sufficient for the outcome Y)
 
The parser inverses it into Y <- A*B + C, as if the outcome Y is necessary for 
the expression A*B + C, which changes the nature of the expression.
 
Quoting such expressions is already possible and it works as expected. We were 
trying to avoid the quotes, if at all possible, to simplify the command use in 
the manuals.
 
Best wishes,
Adrian
 
On Fri, Mar 1, 2024 at 4:33 PM mailto:avi.e.gr...@gmail.com> > wrote:
I am wondering what the specific need for this is or is it just an exercise?

Where does it matter if a chunk of code assigns using "<-" beforehand or "->" 
after hand, or for that matter assigns indirectly without a symbol?

And whatever you come up with, will it also support the global assignment of 
"->>" as compared to ""<<-" too?

I do wonder if you can re-declare the assignment operators or would that mess 
up the parser.

-Original Message-
From: R-devel mailto:r-devel-boun...@r-project.org> > On Behalf Of Duncan Murdoch
Sent: Friday, March 1, 2024 9:23 AM
To: Dmitri Popavenko mailto:dmitri.popave...@gmail.com> >
Cc: r-devel mailto:r-devel@r-project.org> >
Subject: Re: [Rd] capture "->"

On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote:
> On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch    
>  >> wrote:
> 
> ...
> I was thinking more of you doing something like
> 
>parse(text = "A -> B", keep.source = TRUE)
> 
> I forget what the exact rules are for attaching srcrefs to arguments of
> functions, but I do remember they are a little strange, because not
> every possible argument can accept a srcref attribute.  For example,
> you
> can't attach one to NULL, or to a name.
> 
> Srcrefs are also fairly big and building them is slow, so I think we
> tried to limit them to where they were needed, we didn't try to attach
> them to every subexpression, just one per statement.  Each expression
> within {} is a separate statement, so we get srcrefs attached to the {.
> But in "foo(A -> B)" probably you only get one on the foo call.
> 
> In some circumstances you could get the srcref on that call by looking
> at sys.call().  But then things are complicated again, because R
> doesn't
> attach srcrefs to things typed at the console, only to things that are
> sourced from files or text strings (and parsed with keep.source=TRUE).
> 
> So I think you should probably require input from a string or a
> file, or
> not expect foo(A -> B) to work without some decoration.
> 
> 
> Indeed, the more challenging task is to identify "->" at the console
> (from a script or a string, seems trivial now).
> 
> I would be willing to decorate as much as it takes to make this work, I 
> am just empty on more ideas how to persuade the parser.

By "decorate", I meant putting it in quotes and parsing it using 
parse(text=...), or putting it in braces as you found.  I think parsing 
a string is most likely to be reliable because someone might turn off 
`keep.source` and then the braced approach would fail.  But you have 
control over it when you call parse() yourself.

Duncan Murdoch

__
R-devel@r-project.org   mailing list

[Bioc-devel] BioC2024 Registration and Sticker Contest Now Open!

[Maria . Doyle]

BioC2024 registration is now live! Don�t miss your chance to join the 
conversation and expand your expertise.
Sign up here: https://www.bioc2024.bioconductor.org/

Got a knack for design? Enter the BioC2024 Sticker Design Contest to win your 
spot at the conference.
Enter here: https://forms.gle/2XH7ikQEPvJzgcaU7

Join us to network, learn, and contribute to the Bioconductor community!

Maria Doyle, PhD
Bioconductor Community Manager

School of Medicine,
University of Limerick, Limerick, V94 T9PX
Ireland
Email: maria.do...@ul.ie
Phone (office): +353 61 234 768
[I work flexible hours across several time zones. I don't expect you to read or 
respond to my emails outside of your normal working hours]



[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] capture "->"

[Adrian Dușa]

I would also be interested in that.
For me, this is interesting for my QCA package, over which Dmitri and I
have exchanged a couple of messages.
The "<-" operator is used to denote necessity, and the "->" is used for
sufficiency.

Users often make use of Boolean expressions such as A*B + C -> Y
(to calculate if the expression A*B + C is sufficient for the outcome Y)

The parser inverses it into Y <- A*B + C, as if the outcome Y is necessary
for the expression A*B + C, which changes the nature of the expression.

Quoting such expressions is already possible and it works as expected. We
were trying to avoid the quotes, if at all possible, to simplify the
command use in the manuals.

Best wishes,
Adrian

On Fri, Mar 1, 2024 at 4:33 PM  wrote:

> I am wondering what the specific need for this is or is it just an
> exercise?
>
> Where does it matter if a chunk of code assigns using "<-" beforehand or
> "->" after hand, or for that matter assigns indirectly without a symbol?
>
> And whatever you come up with, will it also support the global assignment
> of "->>" as compared to ""<<-" too?
>
> I do wonder if you can re-declare the assignment operators or would that
> mess up the parser.
>
> -Original Message-
> From: R-devel  On Behalf Of Duncan Murdoch
> Sent: Friday, March 1, 2024 9:23 AM
> To: Dmitri Popavenko 
> Cc: r-devel 
> Subject: Re: [Rd] capture "->"
>
> On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote:
> > On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch  > > wrote:
> >
> > ...
> > I was thinking more of you doing something like
> >
> >parse(text = "A -> B", keep.source = TRUE)
> >
> > I forget what the exact rules are for attaching srcrefs to arguments
> of
> > functions, but I do remember they are a little strange, because not
> > every possible argument can accept a srcref attribute.  For example,
> > you
> > can't attach one to NULL, or to a name.
> >
> > Srcrefs are also fairly big and building them is slow, so I think we
> > tried to limit them to where they were needed, we didn't try to
> attach
> > them to every subexpression, just one per statement.  Each expression
> > within {} is a separate statement, so we get srcrefs attached to the
> {.
> > But in "foo(A -> B)" probably you only get one on the foo call.
> >
> > In some circumstances you could get the srcref on that call by
> looking
> > at sys.call().  But then things are complicated again, because R
> > doesn't
> > attach srcrefs to things typed at the console, only to things that
> are
> > sourced from files or text strings (and parsed with
> keep.source=TRUE).
> >
> > So I think you should probably require input from a string or a
> > file, or
> > not expect foo(A -> B) to work without some decoration.
> >
> >
> > Indeed, the more challenging task is to identify "->" at the console
> > (from a script or a string, seems trivial now).
> >
> > I would be willing to decorate as much as it takes to make this work, I
> > am just empty on more ideas how to persuade the parser.
>
> By "decorate", I meant putting it in quotes and parsing it using
> parse(text=...), or putting it in braces as you found.  I think parsing
> a string is most likely to be reliable because someone might turn off
> `keep.source` and then the braced approach would fail.  But you have
> control over it when you call parse() yourself.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[avi.e.gross]

I am wondering what the specific need for this is or is it just an exercise?

Where does it matter if a chunk of code assigns using "<-" beforehand or "->" 
after hand, or for that matter assigns indirectly without a symbol?

And whatever you come up with, will it also support the global assignment of 
"->>" as compared to ""<<-" too?

I do wonder if you can re-declare the assignment operators or would that mess 
up the parser.

-Original Message-
From: R-devel  On Behalf Of Duncan Murdoch
Sent: Friday, March 1, 2024 9:23 AM
To: Dmitri Popavenko 
Cc: r-devel 
Subject: Re: [Rd] capture "->"

On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote:
> On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch  > wrote:
> 
> ...
> I was thinking more of you doing something like
> 
>parse(text = "A -> B", keep.source = TRUE)
> 
> I forget what the exact rules are for attaching srcrefs to arguments of
> functions, but I do remember they are a little strange, because not
> every possible argument can accept a srcref attribute.  For example,
> you
> can't attach one to NULL, or to a name.
> 
> Srcrefs are also fairly big and building them is slow, so I think we
> tried to limit them to where they were needed, we didn't try to attach
> them to every subexpression, just one per statement.  Each expression
> within {} is a separate statement, so we get srcrefs attached to the {.
> But in "foo(A -> B)" probably you only get one on the foo call.
> 
> In some circumstances you could get the srcref on that call by looking
> at sys.call().  But then things are complicated again, because R
> doesn't
> attach srcrefs to things typed at the console, only to things that are
> sourced from files or text strings (and parsed with keep.source=TRUE).
> 
> So I think you should probably require input from a string or a
> file, or
> not expect foo(A -> B) to work without some decoration.
> 
> 
> Indeed, the more challenging task is to identify "->" at the console
> (from a script or a string, seems trivial now).
> 
> I would be willing to decorate as much as it takes to make this work, I 
> am just empty on more ideas how to persuade the parser.

By "decorate", I meant putting it in quotes and parsing it using 
parse(text=...), or putting it in braces as you found.  I think parsing 
a string is most likely to be reliable because someone might turn off 
`keep.source` and then the braced approach would fail.  But you have 
control over it when you call parse() yourself.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Duncan Murdoch]

On 01/03/2024 8:51 a.m., Dmitri Popavenko wrote:
On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch > wrote:


...
I was thinking more of you doing something like

   parse(text = "A -> B", keep.source = TRUE)

I forget what the exact rules are for attaching srcrefs to arguments of
functions, but I do remember they are a little strange, because not
every possible argument can accept a srcref attribute.  For example,
you
can't attach one to NULL, or to a name.

Srcrefs are also fairly big and building them is slow, so I think we
tried to limit them to where they were needed, we didn't try to attach
them to every subexpression, just one per statement.  Each expression
within {} is a separate statement, so we get srcrefs attached to the {.
But in "foo(A -> B)" probably you only get one on the foo call.

In some circumstances you could get the srcref on that call by looking
at sys.call().  But then things are complicated again, because R
doesn't
attach srcrefs to things typed at the console, only to things that are
sourced from files or text strings (and parsed with keep.source=TRUE).

So I think you should probably require input from a string or a
file, or
not expect foo(A -> B) to work without some decoration.


Indeed, the more challenging task is to identify "->" at the console
(from a script or a string, seems trivial now).

I would be willing to decorate as much as it takes to make this work, I 
am just empty on more ideas how to persuade the parser.


By "decorate", I meant putting it in quotes and parsing it using 
parse(text=...), or putting it in braces as you found.  I think parsing 
a string is most likely to be reliable because someone might turn off 
`keep.source` and then the braced approach would fail.  But you have 
control over it when you call parse() yourself.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Dmitri Popavenko]

On Fri, Mar 1, 2024 at 1:00 PM Duncan Murdoch 
wrote:

> ...
> I was thinking more of you doing something like
>
>   parse(text = "A -> B", keep.source = TRUE)
>
> I forget what the exact rules are for attaching srcrefs to arguments of
> functions, but I do remember they are a little strange, because not
> every possible argument can accept a srcref attribute.  For example, you
> can't attach one to NULL, or to a name.
>
> Srcrefs are also fairly big and building them is slow, so I think we
> tried to limit them to where they were needed, we didn't try to attach
> them to every subexpression, just one per statement.  Each expression
> within {} is a separate statement, so we get srcrefs attached to the {.
> But in "foo(A -> B)" probably you only get one on the foo call.
>
> In some circumstances you could get the srcref on that call by looking
> at sys.call().  But then things are complicated again, because R doesn't
> attach srcrefs to things typed at the console, only to things that are
> sourced from files or text strings (and parsed with keep.source=TRUE).
>
> So I think you should probably require input from a string or a file, or
> not expect foo(A -> B) to work without some decoration.
>

Indeed, the more challenging task is to identify "->" at the console
(from a script or a string, seems trivial now).

I would be willing to decorate as much as it takes to make this work, I am
just empty on more ideas how to persuade the parser.
Dmitri

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Duncan Murdoch]

On 01/03/2024 5:25 a.m., Dmitri Popavenko wrote:

Dear Duncan,

On Fri, Mar 1, 2024 at 11:30 AM Duncan Murdoch > wrote:


...
If you parse it with srcrefs, you could look at the source.  The parser
doesn't record whether it was A -> B or B <- A anywhere else.


Thank you, this gets me closer but it still needs a little push:

 > foo <- function(x) {
   x <- substitute(x)
   return(attr(x, "srcref")[[2]])
}

 > foo(A -> B)
NULL

This seems to work, however:
 > foo({A -> B})
A -> B

Is there a way to treat the formula as if it was enclosed between the 
curly brackets?

Dmitri


I was thinking more of you doing something like

 parse(text = "A -> B", keep.source = TRUE)

I forget what the exact rules are for attaching srcrefs to arguments of 
functions, but I do remember they are a little strange, because not 
every possible argument can accept a srcref attribute.  For example, you 
can't attach one to NULL, or to a name.


Srcrefs are also fairly big and building them is slow, so I think we 
tried to limit them to where they were needed, we didn't try to attach 
them to every subexpression, just one per statement.  Each expression 
within {} is a separate statement, so we get srcrefs attached to the {. 
But in "foo(A -> B)" probably you only get one on the foo call.


In some circumstances you could get the srcref on that call by looking 
at sys.call().  But then things are complicated again, because R doesn't 
attach srcrefs to things typed at the console, only to things that are 
sourced from files or text strings (and parsed with keep.source=TRUE).


So I think you should probably require input from a string or a file, or 
not expect foo(A -> B) to work without some decoration.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Fw: MungeSumstats Bioconductor

[Hervé Pagès]

The longtests builds only run the tests in the longtests/ folder.


Best,

H.


On 2/21/24 09:56, alan murphy wrote:
> Hey Herve,
>
> Thanks for this, I'm going to implement that now. One thing I 
> wondered, is it only the tests in the longtest/ folder that run on 
> these weekly builds or both those and the tests in test/? I'm 
> wondering should I duplicate the tests in both folders that I want to 
> run in both?
>
> Cheers,
> Alan.
> 
> *From:* Hervé Pagès 
> *Sent:* Tuesday 6 February 2024 18:58
> *To:* alan murphy ; Bioc-devel@r-project.org 
> 
> *Subject:* Re: [Bioc-devel] Fw: MungeSumstats Bioconductor
>
> Hi Alan,
>
> The specs of the Linux servers have not changed.
>
> However we've recently observed some of these random kills by the 
> Linux kernel for a couple of other packages, and we started an 
> application to get funding to increase the amount of RAM on these 
> machines.
>
> These random kills are a desperate attempt by the Linux kernel to keep 
> the machine alive when it's under extremely high load and running out 
> of resources. Unfortunately this is not something that anybody will be 
> able to easily reproduce as it only happens under special 
> circumstances e.g. during the daily builds when dozens of packages are 
> being checked simultaneously.
>
> Regardless of whether we'll manage to increase the memory on the Linux 
> servers, it seems to me that the most memory-hungry unit tests in 
> MungeSumstats would be a better fit for the long tests. These tests 
> are run once a week instead of daily, and use less workers (4 instead 
> of 28). This means that each package has access to more resources.
>
> See https://contributions.bioconductor.org/long-tests.html 
>  for how to 
> set up the long tests in your package.
>
> Let me know if you have questions or need help with this.
>
> Best,
>
> H.
>
> On 2/2/24 09:14, alan murphy wrote:
>> Hi,
>>
>> I'm the maintainer of the MungeSumstats package which is currently failing 
>> on the devel nebbiolo1 Linux platform because of RAM requirements of the 
>> unit tests. These tests use large reference datasets (like 
>> BSgenome.Hsapiens.1000genomes.hs37d5::BSgenome.Hsapiens.1000genomes.hs37d5) 
>> which cause the issue, e.g. from the output of the devel linux 
>> test
>>   
>> :
>>
>> ```
>>
>> Validating RSIDs of 92 SNPs using BSgenome::snpsById...
>> Killed
>>
>> ```
>> which is from this 
>> function:https://github.com/neurogenomics/MungeSumstats/blob/cccf77b2249f52be59fe1749f13a386ffaaae528/R/load_ref_genome_data.R#L49
>>   
>> 
>>
>> I would like to keep these units tests as they are very important for me to 
>> know if things have gone wrong. I can't scale down the RAM usage, it is only 
>> using a few rows of data as it, the issue is that the reference sets are 
>> massive rather than the actual set being tested. I currently don't have a 
>> lot of these tests set to run on windows/mac platforms so I rely on the 
>> Linux machines to run this. I am not sure what has changed but a few 
>> releases back, the same tested were not causing this issue and would 
>> complete on linux - has the machine spec changed? Is there any chance RAM 
>> could be increased for these tests or is there a way to specify not to run 
>> the specific unit tests on the Bioconductor server so I can at least keep 
>> these for my github actions workflows? See below for the automated message I 
>> got about these errors.
>>
>> Any other suggestions on ways around this would be greatly appreciated!
>>
>> Thanks,
>> Alan.
>> 
>> From: CoreTeam Bioconductor  
>> 
>> Sent: Friday 2 February 2024 16:43
>> To:alanmurp...@hotmail.com    
>>   
>> Subject: MungeSumstats Bioconductor
>>
>> Hello Package Maintainer,
>>
>> We would like to bring to your attention that your package is failing in 
>> devel on the linux platform. This is very problematic. Please investigate 
>> the issues and fix the package to avoid deprecation.
>>
>> https://bioconductor.org/checkResults/devel/bioc-LATEST/  
>> 
>>   
>> 
>>
>> If you have further questions or concerns please reach out on 
>> thebioc-de...@r-project.org  
>>   
>> 

Re: [Rd] capture "->"

[Dmitri Popavenko]

Dear Duncan,

On Fri, Mar 1, 2024 at 11:30 AM Duncan Murdoch 
wrote:

> ...
> If you parse it with srcrefs, you could look at the source.  The parser
> doesn't record whether it was A -> B or B <- A anywhere else.
>

Thank you, this gets me closer but it still needs a little push:

> foo <- function(x) {
  x <- substitute(x)
  return(attr(x, "srcref")[[2]])
}

> foo(A -> B)
NULL

This seems to work, however:
> foo({A -> B})
A -> B

Is there a way to treat the formula as if it was enclosed between the curly
brackets?
Dmitri

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] capture "->"

[Duncan Murdoch]

On 01/03/2024 4:17 a.m., Dmitri Popavenko wrote:

Hi everyone,

I am aware this is a parser issue, but is there any possibility to capture
the use of the inverse assignment operator into a formula?

Something like:


foo <- function(x) substitute(x)


gives:


foo(A -> B)

B <- A

I wonder if there is any possibility whatsoever to signal the use of ->
instead of <-


If you parse it with srcrefs, you could look at the source.  The parser 
doesn't record whether it was A -> B or B <- A anywhere else.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] capture "->"

[Dmitri Popavenko]

Hi everyone,

I am aware this is a parser issue, but is there any possibility to capture
the use of the inverse assignment operator into a formula?

Something like:

> foo <- function(x) substitute(x)

gives:

> foo(A -> B)
B <- A

I wonder if there is any possibility whatsoever to signal the use of ->
instead of <-

Thank you,
Dmitri

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Additional issues: Intel segfault

[Ivan Krylov via R-package-devel]

В Fri, 1 Mar 2024 07:42:01 +
Murray Efford  пишет:

> R CMD check suggests it is most likely in the Examples for
> 'validate', but all code there is wrapped in \dontrun{}.

The crash happens after q('no'), suggesting a corruption in the heap or
in the R memory manager. At least it's a null pointer being
dereferenced and not a 0xRANDOM_LOOKING_NUMBER: this limits the impact
of the problem.

I don't know if anyone created an easily reproducible container with an
Intel build of R (there's https://hub.docker.com/r/intel/oneapi, but
aren't the compilers themselves supposed to be not redistributable?),
so you will most likely have to follow
https://www.stats.ox.ac.uk/pub/bdr/Intel/README.txt and
https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Intel-compilers
manually, compiling R using Intel compilers yourself in order to
reproduce this.

I think it would be great if CRAN checking machines used a just-in-time
debugger to provide C-level backtraces at the place of the crash. For
Windows, such a utility does exist [*], but I recently learned that the
glibc `catchsegv` program (and most other similar programs) used to
perform shared object preloading (before being thrown out of the
codebase altogether), which is more intrusive than it could be. A proof
of concept using GDB on Linux can be shown to work:

R -d gdb \
 --debugger-args='-batch -ex run -ex bt -ex c -ex q' \
 -e '
  Rcpp::sourceCpp(code =
   "//[[Rcpp::export]]\nvoid rip() { *(double*)(42) = 42; }"
  ); rip()
 '

-- 
Best regards,
Ivan

[*] https://github.com/jrfonseca/drmingw

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel