Re: [R-pkg-devel] RFC: C backtraces for R CMD check via just-in-time debugging

[Vladimir Dergachev]

On Tue, 12 Mar 2024, Ivan Krylov wrote:


Vladimir,

Thank you for the example and for sharing the ideas regarding
symbol-relative offsets!

On Thu, 7 Mar 2024 09:38:18 -0500 (EST)
Vladimir Dergachev  wrote:


 unw_get_reg(, UNW_REG_IP, );


Is it ever possible for unw_get_reg() to fail (return non-zero) for
UNW_REG_IP? The documentation isn't being obvious about this. Then
again, if the process is so damaged it cannot even read the instruction
pointer from its own stack frame, any attempts at self-debugging must
be doomed.


Not sure. I think it just returns what is in it, you will get a false 
reading if the stack is corrupted. The way that I see it - some printout 
is better than none, and having signs that stack is badly corrupted is a 
useful debugging clue.





   * this should work as a package, but I am not sure whether the
offsets between package symbols and R symbols would be static or not.


Since package shared objects are mmap()ed into the address space and
(at least on Linux with ASLR enabled) mmap()s are supposed to be made
unpredictable, this offset ends up not being static. On Linux, R seems
to be normally built as a position-independent executable, so no matter
whether there is a libR.so, both the R base address and the package
shared object base address are randomised:

$ cat ex.c
#include 
#include 
void addr_diff(void) {
ptrdiff_t diff = (char*)_diff - (char*)
Rprintf("self - Rprintf = %td\n", diff);
}
$ R CMD SHLIB ex.c
$ R-dynamic -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = -9900928
$ R-dynamic -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = -15561600
$ R-static -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = 45537907472976
$ R-static -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = 46527711447632


   * R ought to know where packages are loaded, we might want to be
clever and print out information on which package contains which
function, or there might be identical R_init_RMVL() printouts.


That's true. Informaion on all registered symbols is available from
getLoadedDLLs().


Ok, so this is reasonably straighforward.

best

Vladimir Dergachev



--
Best regards,
Ivan



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

Re: [R-pkg-devel] RFC: C backtraces for R CMD check via just-in-time debugging

[Ivan Krylov via R-package-devel]

Vladimir,

Thank you for the example and for sharing the ideas regarding
symbol-relative offsets!

On Thu, 7 Mar 2024 09:38:18 -0500 (EST)
Vladimir Dergachev  wrote:

>  unw_get_reg(, UNW_REG_IP, );

Is it ever possible for unw_get_reg() to fail (return non-zero) for
UNW_REG_IP? The documentation isn't being obvious about this. Then
again, if the process is so damaged it cannot even read the instruction
pointer from its own stack frame, any attempts at self-debugging must
be doomed.

>* this should work as a package, but I am not sure whether the
> offsets between package symbols and R symbols would be static or not.

Since package shared objects are mmap()ed into the address space and
(at least on Linux with ASLR enabled) mmap()s are supposed to be made
unpredictable, this offset ends up not being static. On Linux, R seems
to be normally built as a position-independent executable, so no matter
whether there is a libR.so, both the R base address and the package
shared object base address are randomised:

$ cat ex.c
#include 
#include 
void addr_diff(void) {
 ptrdiff_t diff = (char*)_diff - (char*)
 Rprintf("self - Rprintf = %td\n", diff);
}
$ R CMD SHLIB ex.c
$ R-dynamic -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = -9900928
$ R-dynamic -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = -15561600
$ R-static -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = 45537907472976
$ R-static -q -s -e 'dyn.load("ex.so"); .C("addr_diff");'
self - Rprintf = 46527711447632

>* R ought to know where packages are loaded, we might want to be
> clever and print out information on which package contains which
> function, or there might be identical R_init_RMVL() printouts.

That's true. Informaion on all registered symbols is available from
getLoadedDLLs().

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] M1mac check logs

[Maciej Nasinski]

Thanks a lot for your response.
Yes, I see the check print is different and clear now.

KR
Maciej Nasinski

> On 11 Mar 2024, at 20:49, Uwe Ligges  wrote:
> 
> Unfortunately, due to a temporary bug in R-devel, the check result changed 
> before you looked at it.
> Now foxed and back to the older state where the check.log was sufficient to 
> see the issue.
> 
> Best,
> Uwe Ligges
> 
> 
> 
>> On 11.03.2024 17:09, Maciej Nasinski wrote:
>> Hey All,
>> I want to help fix the M1mac-related issue. The URL to issue is
>> https://www.stats.ox.ac.uk/pub/bdr/M1mac/teal.reporter.out
>> I am one of the coauthors of the teal reporter package.
>> The question is how I can access
>> ‘/Users/ripley/R/packages/tests-devel/teal.reporter.Rcheck/00install.out’
>> and ‘/Users/ripley/R/packages/tests-devel/teal.reporter.Rcheck/00check.log’
>> log files.
>> I appreciate your help.
>> KR
>> Maciej Nasinski
>>[[alternative HTML version deleted]]
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] M1mac check logs

[Uwe Ligges]

Unfortunately, due to a temporary bug in R-devel, the check result 
changed before you looked at it.
Now foxed and back to the older state where the check.log was sufficient 
to see the issue.


Best,
Uwe Ligges



On 11.03.2024 17:09, Maciej Nasinski wrote:

Hey All,

I want to help fix the M1mac-related issue. The URL to issue is
https://www.stats.ox.ac.uk/pub/bdr/M1mac/teal.reporter.out
I am one of the coauthors of the teal reporter package.
The question is how I can access
‘/Users/ripley/R/packages/tests-devel/teal.reporter.Rcheck/00install.out’
and ‘/Users/ripley/R/packages/tests-devel/teal.reporter.Rcheck/00check.log’
log files.

I appreciate your help.

KR
Maciej Nasinski

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CHECK warning about new S3 generic/method consistency

[Uwe Ligges]

On 11.03.2024 19:34, CRAN.r wrote:

No, your assumption is backwards. The methods do need to include all
arguments of the generic. As Writing R Extensions says near the start
of section 7, "A method must have all the arguments of the generic,
including … if the generic does."


That's embarrassing. I was worried it was something simple I missed. Thanks for 
pointing that out!

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



Even more embarassing given you seem to be Mr CRAN given your mail 
message's "From" field ...


Uwe Ligges

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

Re: [R-pkg-devel] R CHECK warning about new S3 generic/method consistency

[CRAN.r]

> No, your assumption is backwards. The methods do need to include all
> arguments of the generic. As Writing R Extensions says near the start
> of section 7, "A method must have all the arguments of the generic,
> including … if the generic does."

That's embarrassing. I was worried it was something simple I missed. Thanks for 
pointing that out!

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

Re: [R-pkg-devel] R CHECK warning about new S3 generic/method consistency

[Duncan Murdoch]

On 11/03/2024 2:13 p.m., CRAN.r wrote:

On Monday, March 11th, 2024 at 12:43 PM, Diego Hernangómez Herrero 
 wrote:


Shouldn’t you include the y argument also inmyscale.default ? Your generic is 
defining that argument as well.


I assume (hopefully correctly) that methods don't need to include all the arguments of 
the generic. I get the same warning if I use "..." instead of y, too.


No, your assumption is backwards.  The methods do need to include all 
arguments of the generic.  As Writing R Extensions says near the start 
of section 7, "A method must have all the arguments of the generic, 
including … if the generic does."


Think about your user.  They'll ask about help for `inmyscale`, and see 
that it has two arguments, x and y.  If x is a type that goes to 
`inmyscale.default`, the user would receive an error when they followed 
the docs and included the y value.


The usual way to handle this is to include both x and y in all methods, 
but document some of them to say that y is ignored.


Duncan Murdoch

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

Re: [R-pkg-devel] R CHECK warning about new S3 generic/method consistency

[Diego Hernangómez Herrero]

Usually when I write a generic I use … in the definition to allow using
additional arguments in specific methods, see

as_bibentry <- function(x, ...) { UseMethod("as_bibentry")
 }

as_bibentry.cff <- function(x, ..., what = c("preferred", "references",
"all")) {


}

but in any case the method must include at least the arguments defined in
the same order. Using … in the generic allows me to include `what` arg with
no WARNINGs.




Have a nice day!


El El lun, 11 mar 2024 a las 19:13, CRAN.r  escribió:

> On Monday, March 11th, 2024 at 12:43 PM, Diego Hernangómez Herrero <
> diego.hernangomezherr...@gmail.com> wrote:
>
> > Shouldn’t you include the y argument also inmyscale.default ? Your
> generic is defining that argument as well.
>
> I assume (hopefully correctly) that methods don't need to include all the
> arguments of the generic. I get the same warning if I use "..." instead of
> y, too.
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CHECK warning about new S3 generic/method consistency

[CRAN.r]

On Monday, March 11th, 2024 at 12:43 PM, Diego Hernangómez Herrero 
 wrote:

> Shouldn’t you include the y argument also inmyscale.default ? Your generic is 
> defining that argument as well.

I assume (hopefully correctly) that methods don't need to include all the 
arguments of the generic. I get the same warning if I use "..." instead of y, 
too.

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

Re: [R-pkg-devel] R CHECK warning about new S3 generic/method consistency

[Diego Hernangómez Herrero]

Shouldn’t you include the y argument also in
myscale.default ? Your generic is defining that argument as well.



Have a nice day!


El El lun, 11 mar 2024 a las 18:25, CRAN.r  escribió:

> I'm trying to define a new generic, and keep getting an S3 generic/method
> consistency when running R CHECK. All of the code seems to be working, and
> I'm not getting any note, errors, or other warnings.
>
> This minimal example shows the warning I'm getting. The functions are
>
>   myscale <- function(x, y) UseMethod("myscale")
>   myscale.default <- function(x) x
>
> The usage section of the man file is
>
>   \usage{
> myscale(x, y)
> \method{myscale}{default}(x)
>   }
>
> and the NAMESPACE file is
>
>   export("myscale", "myscale.default")
>   S3method(myscale, default)
>
> When I build the package and run CHECK, I get
>
>   * checking S3 generic/method consistency ... WARNING
>   myscale:
> function(x, y)
>   myscale.default:
> function(x)
>   See section 'Generic functions and methods' in the 'Writing R
>   Extensions' manual.
>
> As I understand it, there shouldn't be a problem as long as the generic
> function contains all possible arguments of any method, and the methods
> have their arguments in the same order as the generic. It seems that having
> one method with only "x" shouldn't be a problem. I've read the section
> mentioned in the warning, but I can't figure out what's going on. Is any of
> this wrong?
>
> Jay
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] R CHECK warning about new S3 generic/method consistency

[CRAN.r]

I'm trying to define a new generic, and keep getting an S3 generic/method 
consistency when running R CHECK. All of the code seems to be working, and I'm 
not getting any note, errors, or other warnings.

This minimal example shows the warning I'm getting. The functions are

  myscale <- function(x, y) UseMethod("myscale")
  myscale.default <- function(x) x

The usage section of the man file is

  \usage{
myscale(x, y)
\method{myscale}{default}(x)
  }

and the NAMESPACE file is

  export("myscale", "myscale.default")
  S3method(myscale, default)

When I build the package and run CHECK, I get

  * checking S3 generic/method consistency ... WARNING
  myscale:
function(x, y)
  myscale.default:
function(x)
  See section 'Generic functions and methods' in the 'Writing R
  Extensions' manual.

As I understand it, there shouldn't be a problem as long as the generic 
function contains all possible arguments of any method, and the methods have 
their arguments in the same order as the generic. It seems that having one 
method with only "x" shouldn't be a problem. I've read the section mentioned in 
the warning, but I can't figure out what's going on. Is any of this wrong?

Jay

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

[R-pkg-devel] M1mac check logs

[Maciej Nasinski]

Hey All,

I want to help fix the M1mac-related issue. The URL to issue is
https://www.stats.ox.ac.uk/pub/bdr/M1mac/teal.reporter.out
I am one of the coauthors of the teal reporter package.
The question is how I can access
‘/Users/ripley/R/packages/tests-devel/teal.reporter.Rcheck/00install.out’
and ‘/Users/ripley/R/packages/tests-devel/teal.reporter.Rcheck/00check.log’
log files.

I appreciate your help.

KR
Maciej Nasinski

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] [EXTERN] Re: [EXTERN] Re: [EXTERN] Re: @doctype is deprecated. need help for r package documentation

[Ruff, Sergej]

yes.


I apologize it took so long to reply.

I uploaded the old version of the package to my repo: 
https://github.com/SergejRuff/boot




Von: Ivan Krylov 
Gesendet: Freitag, 8. März 2024 08:36:43
An: Ruff, Sergej
Cc: r-package-devel@r-project.org
Betreff: [EXTERN] Re: [R-pkg-devel] [EXTERN] Re: [EXTERN] Re: @doctype is 
deprecated. need help for r package documentation

В Thu, 7 Mar 2024 20:27:29 +
"Ruff, Sergej"  пишет:

> I am refering to Rstudio. I checked the settings and type is set to
> "htlm", not text. And I was wondering why the package documentation
> opened in a browser when I used @doctype.

Do you still have the source package .tar.gz file for which ?bootGSEA
would start a browser from inside RStudio?

--
Best regards,
Ivan

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] confusion over spellchecking

[Diego Hernangómez Herrero]

As per 'The DESCRIPTION file'[1]:


As with the ‘Title’ field, double quotes should be used for quotations
(including titles of books and articles), and single quotes for non-English
usage, including names of other packages and external software.


Enclose that words in single quote, it should work.

[1] Writing R Extensions
https://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file

Have a nice day!


El El dom, 10 mar 2024 a las 18:56, Ben Bolker  escribió:

>
>I am working on a package and can't seem to get rid of a NOTE about
>
> Possibly misspelled words in DESCRIPTION:
>glmmTMB (10:88)
>lme (10:82)
>
> on win-builder.
>
> I have set export _R_CHECK_CRAN_INCOMING_USE_ASPELL_=TRUE locally, and
> have tried to set up the .aspell defaults as specified by Dirk
> Eddelbuettel in  his 2017 blog post
> 
>
>I get no spelling NOTEs locally or on GH actions.
>
>   The aspell machinery is here:
>
> https://github.com/bbolker/reformulas/tree/main/.aspell
>
> Following Dirk's blog post, here's what's in those files:
>
> $ cat defaults.R
> Rd_files <- vignettes <- R_files <- description <-
>  list(encoding = "UTF-8",
>   language = "en",
>   dictionaries = c("en_stats", "reformulas"))
>
> $ r -p -e 'readRDS("reformulas.rds")'
> [1] "glmmTMB" "lme"
>
>
>In the end I think I'm going to suck it up and put those words in
> quotation marks in the definition, but it feels like I *should* be able
> to have them ignored?
>
>I have three questions:
>
>   (1) am I missing something in how this should be set up?
>   (2) is any of this machinery documented anywhere official? (I couldn't
> find the string "spell" anywhere in _Writing R Extensions_ or the CRAN
> repository policy
>   (3) If the answer to #2 is 'no', could/should it be?
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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