[Rd] capture error messages from loading shared objects

[Adrian Dusa]

Fellow R developers,

I can capture usual error message using the normal way:
> tc <- tryCatch(1 + a, error = function(e) e)
> tc


However I have troubles capturing the error message from this type of error:

> tc <- tryCatch(requireNamespace("foobar"), error = function(e) e)
Loading required namespace: foobar
Failed with error:  ‘there is no package called ‘foobar’’
> tc
[1] FALSE

Is there any way to capture that specific error message?

Thank you in advance,
Adrian

[[alternative HTML version deleted]]

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

Re: [Rd] capture error messages from loading shared objects

[Ivan Krylov]

В Tue, 28 Nov 2023 10:46:45 +0100
Adrian Dusa  пишет:

> tryCatch(requireNamespace("foobar"), error = function(e) e) 

I think you meant loadNamespace() (which throws errors), not
requireNamespace() (which internally uses tryCatch(loadNamespace(...))
and may or may not print the error depending on the `quietly` argument).

-- 
Best regards,
Ivan

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

Re: [Rd] capture error messages from loading shared objects

[Adrian Dusa]

Once again, Ivan, many thanks.
Yes, that does solve it.
Best wishes,
Adrian

On Tue, Nov 28, 2023 at 11:28 AM Ivan Krylov  wrote:

> В Tue, 28 Nov 2023 10:46:45 +0100
> Adrian Dusa  пишет:
>
> > tryCatch(requireNamespace("foobar"), error = function(e) e)
>
> I think you meant loadNamespace() (which throws errors), not
> requireNamespace() (which internally uses tryCatch(loadNamespace(...))
> and may or may not print the error depending on the `quietly` argument).
>
> --
> Best regards,
> Ivan
>

[[alternative HTML version deleted]]

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

Re: [Rd] capture error messages from loading shared objects

[Henrik Bengtsson]

Careful; tryCatch() on non-error conditions will break out of what's
evaluated, e.g.

res <- tryCatch({
  cat("1\n")
  message("2")
  cat("3\n")
  42
}, message = identity)

will output '1' but not '3', because it returns as soon as the first
message() is called.

To "record" messages (same for warnings), use withCallingHandlers()
instead, e.g.

msgs <- list()
res <- withCallingHandlers({
  cat("1\n")
  message("2")
  cat("3\n")
  42
}, message = function(m) {
  msgs <<- c(msgs, list(m))
  invokeRestart("muffleMessage")
})

This will output '1', muffle '2', output '3', and return 42, and 'msgs' holds

> msgs
[[1]]
 wrote:
>
> If you would like to save the error message instead of suppressing it, you
> can use tryCatch(message=function(e)e, ...).
>
> -BIll
>
> On Tue, Nov 28, 2023 at 3:55 AM Adrian Dusa  wrote:
>
> > Once again, Ivan, many thanks.
> > Yes, that does solve it.
> > Best wishes,
> > Adrian
> >
> > On Tue, Nov 28, 2023 at 11:28 AM Ivan Krylov 
> > wrote:
> >
> > > В Tue, 28 Nov 2023 10:46:45 +0100
> > > Adrian Dusa  пишет:
> > >
> > > > tryCatch(requireNamespace("foobar"), error = function(e) e)
> > >
> > > I think you meant loadNamespace() (which throws errors), not
> > > requireNamespace() (which internally uses tryCatch(loadNamespace(...))
> > > and may or may not print the error depending on the `quietly` argument).
> > >
> > > --
> > > Best regards,
> > > Ivan
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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

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

Re: [Rd] capture error messages from loading shared objects

[Bill Dunlap]

If you would like to save the error message instead of suppressing it, you
can use tryCatch(message=function(e)e, ...).

-BIll

On Tue, Nov 28, 2023 at 3:55 AM Adrian Dusa  wrote:

> Once again, Ivan, many thanks.
> Yes, that does solve it.
> Best wishes,
> Adrian
>
> On Tue, Nov 28, 2023 at 11:28 AM Ivan Krylov 
> wrote:
>
> > В Tue, 28 Nov 2023 10:46:45 +0100
> > Adrian Dusa  пишет:
> >
> > > tryCatch(requireNamespace("foobar"), error = function(e) e)
> >
> > I think you meant loadNamespace() (which throws errors), not
> > requireNamespace() (which internally uses tryCatch(loadNamespace(...))
> > and may or may not print the error depending on the `quietly` argument).
> >
> > --
> > Best regards,
> > Ivan
> >
>
> [[alternative HTML version deleted]]
>
> __
> 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 error messages from loading shared objects

[Adrian Dușa]

Thanks Henrik and Bill,

Indeed, but I do have a function called tryCatchWEM() in package admisc
that captures all that.

My use case was to test for different architectures (for instance, arm64 vs
Intel MacOS) embedding R in cross-platform applications.
I needed to test if the package could be loaded, and previously used
requireNamespace() being unaware, as Ivan pointed out, that internally that
function already does tryCatch() with loadNamespace().

That was the reason why my own function tryCatchWEM() could not capture
that specific error message.
I now do:
> admisc::tryCatchWEM(loadNamespace("foobar"))
$error
[1] "there is no package called ‘foobar’"

(and the error message is captured just fine).

All the best,
Adrian

On Tue, Nov 28, 2023 at 7:45 PM Henrik Bengtsson 
wrote:

> Careful; tryCatch() on non-error conditions will break out of what's
> evaluated, e.g.
>
> res <- tryCatch({
>   cat("1\n")
>   message("2")
>   cat("3\n")
>   42
> }, message = identity)
>
> will output '1' but not '3', because it returns as soon as the first
> message() is called.
>
> To "record" messages (same for warnings), use withCallingHandlers()
> instead, e.g.
>
> msgs <- list()
> res <- withCallingHandlers({
>   cat("1\n")
>   message("2")
>   cat("3\n")
>   42
> }, message = function(m) {
>   msgs <<- c(msgs, list(m))
>   invokeRestart("muffleMessage")
> })
>
> This will output '1', muffle '2', output '3', and return 42, and 'msgs'
> holds
>
> > msgs
> [[1]]
> 
> /Henrik
>
> On Tue, Nov 28, 2023 at 10:34 AM Bill Dunlap 
> wrote:
> >
> > If you would like to save the error message instead of suppressing it,
> you
> > can use tryCatch(message=function(e)e, ...).
> >
> > -BIll
> >
> > On Tue, Nov 28, 2023 at 3:55 AM Adrian Dusa 
> wrote:
> >
> > > Once again, Ivan, many thanks.
> > > Yes, that does solve it.
> > > Best wishes,
> > > Adrian
> > >
> > > On Tue, Nov 28, 2023 at 11:28 AM Ivan Krylov 
> > > wrote:
> > >
> > > > В Tue, 28 Nov 2023 10:46:45 +0100
> > > > Adrian Dusa  пишет:
> > > >
> > > > > tryCatch(requireNamespace("foobar"), error = function(e) e)
> > > >
> > > > I think you meant loadNamespace() (which throws errors), not
> > > > requireNamespace() (which internally uses
> tryCatch(loadNamespace(...))
> > > > and may or may not print the error depending on the `quietly`
> argument).
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan
> > > >
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > __
> > > 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
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu

[[alternative HTML version deleted]]

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

Re: [Rd] R test coverage

[Lluís Revilla]

Hi Jim,

Thanks for the info.
I disregarded covr in my search results as I thought it would only apply to
packages outside base and recommended.
The code is pure R code so it might work, but it reads a file so it might
involve some C code.

Thanks!

Lluís

On Mon, 27 Nov 2023 at 20:11, Jim Hester  wrote:

> It should be possible to use covr to do this, see this old issue
> (https://github.com/r-lib/covr/issues/59). However interpreting the
> results can prove challenging as naturally covr uses functions
> from the base internally. Unfortunately the base and many of the
> internal and recommended packages have somewhat bespoke installation,
> so it would likely take some additional work on your end to get
> reporting working. I had thought of doing this at one point, but
> wasn't sure there would be any audience for the results, so did not
> pursue it further.
>
> For measuring coverage of the C code in the R runtime alone you could
> use gcov and run the test suite, which depending on your contribution
> may be the most informative route.
>
> (replying for the list, accidentally replied only to Lluís the first time)
>
> On Mon, Nov 27, 2023 at 10:15 AM Lluís Revilla 
> wrote:
> >
> > Hi all,
> >
> > I recently proposed a change in R that has led to the addition of new
> code
> > to the R source code.
> >
> > The code added, as far as I know, has no tests and it might affect many
> > packages in CRAN.
> > I was wondering if adding a test would be helpful or it is already
> covered
> > by some other test.
> > Which brought me to the question: what is the coverage of R checks
> > (check-devel)?
> >
> > My searches in the mailing list or other places didn't return anything
> > close to it.
> > But I am curious if someone has already done this and how.
> >
> > Many thanks,
> >
> > Lluís
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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: [R-pkg-devel] NOTE or Information?

[Lionel Henry]

I need to do an rlang release for the same format warning!

I'll take this opportunity to look into conditionally exporting `%||%`
from base, which should solve that warning.

Best,
Lionel

On 11/28/23, Göran Broström  wrote:
> A thirty-year-old format error in the C code of my package eha was
> finally detected by the latest R-devel, thanks to CRAN for that!
>
> However, I also get a message never seen before, when I check the package:
>
> ---
> Attaching package: ‘rlang’
>
> The following object is masked from ‘package:base’:
>
>  %||%
> ---
>
> I guess that this is a result of my use of devtools and roxygen for
> writing documentation. Is this a bug in rlang and the mask part of the
> message will go away when it is fixed?
>
> Thanks, Göran
>
> __
> 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] NOTE or Information?

[Ivan Krylov]

В Tue, 28 Nov 2023 13:40:51 +0100
Göran Broström  пишет:

> I guess that this is a result of my use of devtools and roxygen for 
> writing documentation. Is this a bug in rlang and the mask part of
> the message will go away when it is fixed?

Not exactly a bug. It just so happens that rlang exports a function
with the same name as a function already existing in a different
attached package. Same thing happens on a larger scale with other
packages too:

library(dplyr)
# 
# Attaching package: 'dplyr'
# 
# The following objects are masked from 'package:stats':
# 
# filter, lag
# 
# The following objects are masked from 'package:base':
# 
# intersect, setdiff, setequal, union

As long as the authors of the package that masks functions from another
package are careful to preserve compatibility with the original
function (this typically happens when a package masks a function with
an S3 generic) or you remain aware that the function name is ambiguous,
you will avoid problems.

The `%||%` operators in base and rlang aren't implemented exactly the
same, but they should have the same semantics:

base::`%||%`
# function (x, y)
# if (is.null(x)) y else x
# 
# 
rlang::`%||%`
# function (x, y)
# {
# if (is_null(x))
# y
# else x
# }
# 
# 

Since your eha package doesn't directly use rlang, you're welcome to
ignore this message.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] NOTE or Information?

[Enrico Schumann]

On Tue, 28 Nov 2023, Göran Broström writes:

> A thirty-year-old format error in the C code of my
> package eha was finally detected by the latest R-devel,
> thanks to CRAN for that!
>
> However, I also get a message never seen before, when I check the package:
>
> ---
> Attaching package: ‘rlang’
>
> The following object is masked from ‘package:base’:
>
> %||%
> ---
>
> I guess that this is a result of my use of devtools and
> roxygen for writing documentation. Is this a bug in
> rlang and the mask part of the message will go away
> when it is fixed?
>
> Thanks, Göran
>

A `%||%` operator has been added to R-devel, and hence
the warning about masking:


https://github.com/r-devel/r-svn/commit/aa23547f2c5a80752194647c811fa2c1433d43b9



-- 
Enrico Schumann
Lucerne, Switzerland
http://enricoschumann.net

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

[R-pkg-devel] NOTE or Information?

[Göran Broström]

A thirty-year-old format error in the C code of my package eha was 
finally detected by the latest R-devel, thanks to CRAN for that!


However, I also get a message never seen before, when I check the package:

---
Attaching package: ‘rlang’

The following object is masked from ‘package:base’:

%||%
---

I guess that this is a result of my use of devtools and roxygen for 
writing documentation. Is this a bug in rlang and the mask part of the 
message will go away when it is fixed?


Thanks, Göran

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

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Reed A. Cartwright]

If I have read the R's change log correctly, C99 printf format is now
supported on Windows. I think the change was made in the last week.

On Tue, Nov 28, 2023, 13:01 Henrik Bengtsson 
wrote:

> "%td" is not supported on all platforms/compilers.  This is what I got
> when I added it to 'matrixStats';
>
> * using log directory
> 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
> * using R Under development (unstable) (2023-11-26 r85638 ucrt)
> * using platform: x86_64-w64-mingw32
> * R was compiled by
> gcc.exe (GCC) 12.3.0
> GNU Fortran (GCC) 12.3.0
> * running under: Windows Server 2022 x64 (build 20348)
> * using session charset: UTF-8
> * using options '--no-manual --as-cran'
> * checking for file 'matrixStats/DESCRIPTION' ... OK
> * this is package 'matrixStats' version '1.1.0-9003'
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for executable files ... OK
> * checking for hidden files and directories ... OK
> * checking for portable file names ... OK
> * checking serialization versions ... OK
> * checking whether package 'matrixStats' can be installed ... [22s] WARNING
> Found the following significant warnings:
> binCounts.c:25:81: warning: unknown conversion type character 't' in
> format [-Wformat=]
> binCounts.c:25:11: warning: too many arguments for format
> [-Wformat-extra-args]
> binMeans.c:26:60: warning: unknown conversion type character 't' in
> format [-Wformat=]
> binMeans.c:26:67: warning: unknown conversion type character 't' in
> format [-Wformat=]
> ...
> See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
> for details.
> * used C compiler: 'gcc.exe (GCC) 12.2.0'
>
> It worked fine on Linux. Because of this, I resorted to the coercion
> strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
> I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
> int'.
>
> /Henrik
>
> On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov 
> wrote:
> >
> > On Wed, 29 Nov 2023 06:11:23 +1100
> > Hugh Parsonage  wrote:
> >
> > > Rprintf("%lld", (long long) xlength(x));
> >
> > This is fine. long longs are guaranteed to be at least 64 bits in size
> > and are signed, just like lengths in R.
> >
> > > Rprintf("%td, xlength(x));
> >
> > Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
> > to fail on an (increasingly rare) 32-bit system where R_xlen_t is int
> > (which is an implementation detail).
> >
> > In my opinion, ptrdiff_t is just the right type for array lengths if
> > they have to be signed (which is useful for Fortran interoperability),
> > so Rprintf("%td", (ptrdiff_t)xlength(x)) would be my preferred option
> > for now. By definition of ptrdiff_t, you can be sure [*] that there
> > won't be any vectors on your system longer than PTRDIFF_MAX.
> >
> > > using the string macro found in Mr Kalibera's commit of r85641:
> > > R_PRIdXLEN_T
> >
> > I think this will be the best solution once we can afford
> > having our packages depend on R >= 4.4.
> >
> > --
> > Best regards,
> > Ivan
> >
> > [*]
> https://urldefense.com/v3/__https://en.cppreference.com/w/c/types/ptrdiff_t__;!!IKRxdwAv5BmarQ!Zm84sWjl9Vg2_hQ8e5geMYnVFH8eNO-9KZsIkE7Tjk_V_-tj8W2Ept9o43gl-WGDczLbJTORU0oHTnfSA5iTLmO_uTKw$
> posits that there
> > may exist long vectors that fit in SIZE_MAX (unsigned) elements but not
> > PTRDIFF_MAX (signed) elements. If such vector exists, subtracting two
> > pointers to its insides may result in undefined behaviour. This may be
> > already possible in a 32-bit process on Linux running with a 3G
> > user-space / 1G kernel-space split. The only way around the problem is
> > to use unsigned types for lengths, but that would preclude Fortran
> > compatibility.
> >
> > __
> > R-package-devel@r-project.org mailing list
> >
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!Zm84sWjl9Vg2_hQ8e5geMYnVFH8eNO-9KZsIkE7Tjk_V_-tj8W2Ept9o43gl-WGDczLbJTORU0oHTnfSA5iTLmjE7gjq$
>
> __
> R-package-devel@r-project.org mailing list
>
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!Zm84sWjl9Vg2_hQ8e5geMYnVFH8eNO-9KZsIkE7Tjk_V_-tj8W2Ept9o43gl-WGDczLbJTORU0oHTnfSA5iTLmjE7gjq$
>

[[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] Canonical way to Rprintf R_xlen_t

[Daniel Kelley]

I hope it's okay to ask this on the present thread, rather than starting a new 
one...

On this issue of the C format for various integer-type items, I am finding that 
checks made with devtools::check_win_devel() give different results than those 
made with the github R-CMD-check action named ubuntu-latest-devel.  Which (if 
either) might be best for someone trying to fix up code for a CRAN release?

# Details

The code

NumericVector a;
::R_error("size %ld", a.size());

does not lead to warnings with R-CMD-check/ubuntu-latest-devel compilation, but 
it does with devtools::check_win_devel().  And the reverse is true with the code

NumericVector a;
::R_error("size %lld", a.size());

so one of these two methods must not be a good way to know if I'm doing the 
right thing.  I don't want to submit an update to CRAN that will lead to 
problems there, so I am keen to find a way to test this aspect without making a 
new submission (and thereby wasting time for the kind folks who run CRAN).

Thanks.

Dan.

> On Nov 28, 2023, at 4:30 PM, Reed A. Cartwright  
> wrote:
> 
> CAUTION: The Sender of this email is not from within Dalhousie.
> 
> If I have read the R's change log correctly, C99 printf format is now
> supported on Windows. I think the change was made in the last week.
> 
> On Tue, Nov 28, 2023, 13:01 Henrik Bengtsson 
> wrote:
> 
>> "%td" is not supported on all platforms/compilers.  This is what I got
>> when I added it to 'matrixStats';
>> 
>> * using log directory
>> 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
>> * using R Under development (unstable) (2023-11-26 r85638 ucrt)
>> * using platform: x86_64-w64-mingw32
>> * R was compiled by
>> gcc.exe (GCC) 12.3.0
>> GNU Fortran (GCC) 12.3.0
>> * running under: Windows Server 2022 x64 (build 20348)
>> * using session charset: UTF-8
>> * using options '--no-manual --as-cran'
>> * checking for file 'matrixStats/DESCRIPTION' ... OK
>> * this is package 'matrixStats' version '1.1.0-9003'
>> * checking package namespace information ... OK
>> * checking package dependencies ... OK
>> * checking if this is a source package ... OK
>> * checking if there is a namespace ... OK
>> * checking for executable files ... OK
>> * checking for hidden files and directories ... OK
>> * checking for portable file names ... OK
>> * checking serialization versions ... OK
>> * checking whether package 'matrixStats' can be installed ... [22s] WARNING
>> Found the following significant warnings:
>> binCounts.c:25:81: warning: unknown conversion type character 't' in
>> format [-Wformat=]
>> binCounts.c:25:11: warning: too many arguments for format
>> [-Wformat-extra-args]
>> binMeans.c:26:60: warning: unknown conversion type character 't' in
>> format [-Wformat=]
>> binMeans.c:26:67: warning: unknown conversion type character 't' in
>> format [-Wformat=]
>> ...
>> See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
>> for details.
>> * used C compiler: 'gcc.exe (GCC) 12.2.0'
>> 
>> It worked fine on Linux. Because of this, I resorted to the coercion
>> strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
>> I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
>> int'.
>> 
>> /Henrik
>> 
>> On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov 
>> wrote:
>>> 
>>> On Wed, 29 Nov 2023 06:11:23 +1100
>>> Hugh Parsonage  wrote:
>>> 
 Rprintf("%lld", (long long) xlength(x));
>>> 
>>> This is fine. long longs are guaranteed to be at least 64 bits in size
>>> and are signed, just like lengths in R.
>>> 
 Rprintf("%td, xlength(x));
>>> 
>>> Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
>>> to fail on an (increasingly rare) 32-bit system where R_xlen_t is int
>>> (which is an implementation detail).
>>> 
>>> In my opinion, ptrdiff_t is just the right type for array lengths if
>>> they have to be signed (which is useful for Fortran interoperability),
>>> so Rprintf("%td", (ptrdiff_t)xlength(x)) would be my preferred option
>>> for now. By definition of ptrdiff_t, you can be sure [*] that there
>>> won't be any vectors on your system longer than PTRDIFF_MAX.
>>> 
 using the string macro found in Mr Kalibera's commit of r85641:
 R_PRIdXLEN_T
>>> 
>>> I think this will be the best solution once we can afford
>>> having our packages depend on R >= 4.4.
>>> 
>>> --
>>> Best regards,
>>> Ivan
>>> 
>>> [*]
>> https://urldefense.com/v3/__https://en.cppreference.com/w/c/types/ptrdiff_t__;!!IKRxdwAv5BmarQ!Zm84sWjl9Vg2_hQ8e5geMYnVFH8eNO-9KZsIkE7Tjk_V_-tj8W2Ept9o43gl-WGDczLbJTORU0oHTnfSA5iTLmO_uTKw$
>> posits that there
>>> may exist long vectors that fit in SIZE_MAX (unsigned) elements but not
>>> PTRDIFF_MAX (signed) elements. If such vector exists, subtracting two
>>> pointers to its insides may result in undefined behaviour. This may be
>>> already possible in a 32-bit process on Linux running with a 3G
>>> user-space / 1G kernel-space split. The only way around the problem is
>>> to use unsigned 

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Tomas Kalibera]

On 11/28/23 22:21, Tomas Kalibera wrote:


On 11/28/23 21:50, Henrik Bengtsson wrote:

Daniel, I get those compiler warnings for '%td" MS Windows. It works
fine on Linux.


Please let me clarify. %td works in R on Windows in R 4.3 and R-devel, 
when using the recommended toolchain, which is Rtools43. It also 
worked with R 4.2 and Rtools42. It works since R has switched to UCRT 
on Windows. I assume you are not using a recommended toolchain and 
this is why you are getting the warning - please let me know if this 
is not the case and I will try to help.


I forgot to say that one needs R-devel 85640 or newer. You could get the 
warning for %td etc also with R-devel between 85639 and R-devel 85619, 
even with the recommended toolchain, because these versions used 
"printf" format in the header, but on Windows it needs to use 
"gnu_printf" (which is the C99/UCRT format). I've fixed that in 85640.


Best
Tomas



There is a bug in GCC, still present in gcc 12 and gcc 10, due to 
which gcc displays warnings about the format even when it is 
supported. The details are complicated, but in short, it accidentally 
applies both Microsoft format and C99/GNU format checks to printf 
functions with UCRT - so you get a warning whenever the two formats 
disagree, which includes printing a 64 bit integer.  Also for %td 
which is not supported by Microsoft format. Or say %zu (size_t) or %Lf 
(long double). I've been patching GCC in Rtools42 and Rtools43 to 
avoid this problem, so you don't get the warning there. My patch has 
been picked up also by Msys2, I didn't check whether it is still there 
or not. Finally a new implementation of the patch was accepted to GCC 
trunk, so eventually this will no longer be needed. But regardless 
which version of GCC Rtools44 will use, I will make sure it will 
accept C99 printf formats without warnings. An unpatched GCC 10 or 12 
with UCRT will print a warning for %td but will support it.


Best
Tomas


FYI, https://builder.r-hub.io/ is a great, free service for testing on
various platforms in the cloud.  Also, if you host your package code
on GitHub, it's a small step to configure GitHub Actions to check your
packages across platforms on their servers.  It's free and fairly
straightforward.  There should be plenty of tutorials and examples
online for how to do that with R packages.  So, no need to mock around
with Linux containers etc.

/Henrik

On Tue, Nov 28, 2023 at 12:30 PM Daniel Kelley  wrote:
To HB: I also maintain a package that has this problem.  I do not 
have access to a linux machine (or a machine with the C++ version in 
question) so I spent quite a while trying to get docker set up. That 
was a slow process because I had to install R, a bunch of packages, 
some other software, and so forth.  Anyway, the docker container I 
had used didn't seem to have a compiler that gave these warnings. 
But, by then, I saw that the machine used by


devtools::check_win_devel()

was giving those warnings :-)

So, now there is a way to debug these things.

PS. I also tried using rhub, but it takes a long time and often 
results in a PREPERROR.


On Nov 28, 2023, at 3:58 PM, Henrik Bengtsson 
 wrote:


CAUTION: The Sender of this email is not from within Dalhousie.

"%td" is not supported on all platforms/compilers.  This is what I got
when I added it to 'matrixStats';

* using log directory 
'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'

* using R Under development (unstable) (2023-11-26 r85638 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* using options '--no-manual --as-cran'
* checking for file 'matrixStats/DESCRIPTION' ... OK
* this is package 'matrixStats' version '1.1.0-9003'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'matrixStats' can be installed ... [22s] 
WARNING

Found the following significant warnings:
binCounts.c:25:81: warning: unknown conversion type character 't' in
format [-Wformat=]
binCounts.c:25:11: warning: too many arguments for format 
[-Wformat-extra-args]

binMeans.c:26:60: warning: unknown conversion type character 't' in
format [-Wformat=]
binMeans.c:26:67: warning: unknown conversion type character 't' in
format [-Wformat=]
...
See 
'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'

for details.
* used C compiler: 'gcc.exe (GCC) 12.2.0'

It worked fine on Linux. Because of this, I resorted to the coercion
strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
int'.

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Ivan Krylov]

On Wed, 29 Nov 2023 06:11:23 +1100
Hugh Parsonage  wrote:

> Rprintf("%lld", (long long) xlength(x));

This is fine. long longs are guaranteed to be at least 64 bits in size
and are signed, just like lengths in R.

> Rprintf("%td, xlength(x));

Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
to fail on an (increasingly rare) 32-bit system where R_xlen_t is int
(which is an implementation detail).

In my opinion, ptrdiff_t is just the right type for array lengths if
they have to be signed (which is useful for Fortran interoperability),
so Rprintf("%td", (ptrdiff_t)xlength(x)) would be my preferred option
for now. By definition of ptrdiff_t, you can be sure [*] that there
won't be any vectors on your system longer than PTRDIFF_MAX.

> using the string macro found in Mr Kalibera's commit of r85641:
> R_PRIdXLEN_T

I think this will be the best solution once we can afford
having our packages depend on R >= 4.4.

-- 
Best regards,
Ivan

[*] https://en.cppreference.com/w/c/types/ptrdiff_t posits that there
may exist long vectors that fit in SIZE_MAX (unsigned) elements but not
PTRDIFF_MAX (signed) elements. If such vector exists, subtracting two
pointers to its insides may result in undefined behaviour. This may be
already possible in a 32-bit process on Linux running with a 3G
user-space / 1G kernel-space split. The only way around the problem is
to use unsigned types for lengths, but that would preclude Fortran
compatibility.

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

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Henrik Bengtsson]

Daniel, I get those compiler warnings for '%td" MS Windows. It works
fine on Linux.

FYI, https://builder.r-hub.io/ is a great, free service for testing on
various platforms in the cloud.  Also, if you host your package code
on GitHub, it's a small step to configure GitHub Actions to check your
packages across platforms on their servers.  It's free and fairly
straightforward.  There should be plenty of tutorials and examples
online for how to do that with R packages.  So, no need to mock around
with Linux containers etc.

/Henrik

On Tue, Nov 28, 2023 at 12:30 PM Daniel Kelley  wrote:
>
> To HB: I also maintain a package that has this problem.  I do not have access 
> to a linux machine (or a machine with the C++ version in question) so I spent 
> quite a while trying to get docker set up. That was a slow process because I 
> had to install R, a bunch of packages, some other software, and so forth.  
> Anyway, the docker container I had used didn't seem to have a compiler that 
> gave these warnings.  But, by then, I saw that the machine used by
>
> devtools::check_win_devel()
>
> was giving those warnings :-)
>
> So, now there is a way to debug these things.
>
> PS. I also tried using rhub, but it takes a long time and often results in a 
> PREPERROR.
>
> On Nov 28, 2023, at 3:58 PM, Henrik Bengtsson  
> wrote:
>
> CAUTION: The Sender of this email is not from within Dalhousie.
>
> "%td" is not supported on all platforms/compilers.  This is what I got
> when I added it to 'matrixStats';
>
> * using log directory 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
> * using R Under development (unstable) (2023-11-26 r85638 ucrt)
> * using platform: x86_64-w64-mingw32
> * R was compiled by
> gcc.exe (GCC) 12.3.0
> GNU Fortran (GCC) 12.3.0
> * running under: Windows Server 2022 x64 (build 20348)
> * using session charset: UTF-8
> * using options '--no-manual --as-cran'
> * checking for file 'matrixStats/DESCRIPTION' ... OK
> * this is package 'matrixStats' version '1.1.0-9003'
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for executable files ... OK
> * checking for hidden files and directories ... OK
> * checking for portable file names ... OK
> * checking serialization versions ... OK
> * checking whether package 'matrixStats' can be installed ... [22s] WARNING
> Found the following significant warnings:
> binCounts.c:25:81: warning: unknown conversion type character 't' in
> format [-Wformat=]
> binCounts.c:25:11: warning: too many arguments for format 
> [-Wformat-extra-args]
> binMeans.c:26:60: warning: unknown conversion type character 't' in
> format [-Wformat=]
> binMeans.c:26:67: warning: unknown conversion type character 't' in
> format [-Wformat=]
> ...
> See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
> for details.
> * used C compiler: 'gcc.exe (GCC) 12.2.0'
>
> It worked fine on Linux. Because of this, I resorted to the coercion
> strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
> I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
> int'.
>
> /Henrik
>
> On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov  wrote:
>
>
> On Wed, 29 Nov 2023 06:11:23 +1100
> Hugh Parsonage  wrote:
>
> Rprintf("%lld", (long long) xlength(x));
>
>
> This is fine. long longs are guaranteed to be at least 64 bits in size
> and are signed, just like lengths in R.
>
> Rprintf("%td, xlength(x));
>
>
> Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
> to fail on an (increasingly rare) 32-bit system where R_xlen_t is int
> (which is an implementation detail).
>
> In my opinion, ptrdiff_t is just the right type for array lengths if
> they have to be signed (which is useful for Fortran interoperability),
> so Rprintf("%td", (ptrdiff_t)xlength(x)) would be my preferred option
> for now. By definition of ptrdiff_t, you can be sure [*] that there
> won't be any vectors on your system longer than PTRDIFF_MAX.
>
> using the string macro found in Mr Kalibera's commit of r85641:
> R_PRIdXLEN_T
>
>
> I think this will be the best solution once we can afford
> having our packages depend on R >= 4.4.
>
> --
> Best regards,
> Ivan
>
> [*] https://en.cppreference.com/w/c/types/ptrdiff_t posits that there
> may exist long vectors that fit in SIZE_MAX (unsigned) elements but not
> PTRDIFF_MAX (signed) elements. If such vector exists, subtracting two
> pointers to its insides may result in undefined behaviour. This may be
> already possible in a 32-bit process on Linux running with a 3G
> user-space / 1G kernel-space split. The only way around the problem is
> to use unsigned types for lengths, but that would preclude Fortran
> compatibility.
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
> 

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Tomas Kalibera]

On 11/28/23 21:50, Henrik Bengtsson wrote:

Daniel, I get those compiler warnings for '%td" MS Windows. It works
fine on Linux.


Please let me clarify. %td works in R on Windows in R 4.3 and R-devel, 
when using the recommended toolchain, which is Rtools43. It also worked 
with R 4.2 and Rtools42. It works since R has switched to UCRT on 
Windows. I assume you are not using a recommended toolchain and this is 
why you are getting the warning - please let me know if this is not the 
case and I will try to help.


There is a bug in GCC, still present in gcc 12 and gcc 10, due to which 
gcc displays warnings about the format even when it is supported. The 
details are complicated, but in short, it accidentally applies both 
Microsoft format and C99/GNU format checks to printf functions with UCRT 
- so you get a warning whenever the two formats disagree, which includes 
printing a 64 bit integer.  Also for %td which is not supported by 
Microsoft format. Or say %zu (size_t) or %Lf (long double). I've been 
patching GCC in Rtools42 and Rtools43 to avoid this problem, so you 
don't get the warning there. My patch has been picked up also by Msys2, 
I didn't check whether it is still there or not. Finally a new 
implementation of the patch was accepted to GCC trunk, so eventually 
this will no longer be needed. But regardless which version of GCC 
Rtools44 will use, I will make sure it will accept C99 printf formats 
without warnings. An unpatched GCC 10 or 12 with UCRT will print a 
warning for %td but will support it.


Best
Tomas


FYI, https://builder.r-hub.io/ is a great, free service for testing on
various platforms in the cloud.  Also, if you host your package code
on GitHub, it's a small step to configure GitHub Actions to check your
packages across platforms on their servers.  It's free and fairly
straightforward.  There should be plenty of tutorials and examples
online for how to do that with R packages.  So, no need to mock around
with Linux containers etc.

/Henrik

On Tue, Nov 28, 2023 at 12:30 PM Daniel Kelley  wrote:

To HB: I also maintain a package that has this problem.  I do not have access 
to a linux machine (or a machine with the C++ version in question) so I spent 
quite a while trying to get docker set up. That was a slow process because I 
had to install R, a bunch of packages, some other software, and so forth.  
Anyway, the docker container I had used didn't seem to have a compiler that 
gave these warnings.  But, by then, I saw that the machine used by

devtools::check_win_devel()

was giving those warnings :-)

So, now there is a way to debug these things.

PS. I also tried using rhub, but it takes a long time and often results in a 
PREPERROR.

On Nov 28, 2023, at 3:58 PM, Henrik Bengtsson  
wrote:

CAUTION: The Sender of this email is not from within Dalhousie.

"%td" is not supported on all platforms/compilers.  This is what I got
when I added it to 'matrixStats';

* using log directory 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
* using R Under development (unstable) (2023-11-26 r85638 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* using options '--no-manual --as-cran'
* checking for file 'matrixStats/DESCRIPTION' ... OK
* this is package 'matrixStats' version '1.1.0-9003'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'matrixStats' can be installed ... [22s] WARNING
Found the following significant warnings:
binCounts.c:25:81: warning: unknown conversion type character 't' in
format [-Wformat=]
binCounts.c:25:11: warning: too many arguments for format [-Wformat-extra-args]
binMeans.c:26:60: warning: unknown conversion type character 't' in
format [-Wformat=]
binMeans.c:26:67: warning: unknown conversion type character 't' in
format [-Wformat=]
...
See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
for details.
* used C compiler: 'gcc.exe (GCC) 12.2.0'

It worked fine on Linux. Because of this, I resorted to the coercion
strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
int'.

/Henrik

On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov  wrote:


On Wed, 29 Nov 2023 06:11:23 +1100
Hugh Parsonage  wrote:

Rprintf("%lld", (long long) xlength(x));


This is fine. long longs are guaranteed to be at least 64 bits in size
and are signed, just like lengths in R.

Rprintf("%td, xlength(x));


Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
to fail on an (increasingly rare) 

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Tomas Kalibera]

On 11/28/23 20:51, Ivan Krylov wrote:

On Wed, 29 Nov 2023 06:11:23 +1100
Hugh Parsonage  wrote:


Rprintf("%lld", (long long) xlength(x));

This is fine. long longs are guaranteed to be at least 64 bits in size
and are signed, just like lengths in R.
Right, this has been my choice for R-devel, at least for now. It still 
has downsides. In principle, it is not guaranteed that ptrdiff_t won't 
become bigger than long long at some point (but it is extremely unlikely 
anyone would run into that in R ever with array indexes). Then, on the 
other hand, it may be a waste in some cases, ptrdiff_t is smaller and in 
theory the generated code may be faster in some cases (that of course 
wouldn't matter for errors or I/O, but maybe in theory it could with 
purely string operations).



Rprintf("%td, xlength(x));

Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
to fail on an (increasingly rare) 32-bit system where R_xlen_t is int
(which is an implementation detail).

In my opinion, ptrdiff_t is just the right type for array lengths if
they have to be signed (which is useful for Fortran interoperability),
so Rprintf("%td", (ptrdiff_t)xlength(x)) would be my preferred option
for now. By definition of ptrdiff_t, you can be sure [*] that there
won't be any vectors on your system longer than PTRDIFF_MAX.


Yes, that is fine, too, with the cast, as long as R_xlen_t is not bigger 
than ptrdiff_t. You would have a problem if it ever changed in R. I 
don't think it is likely, but, technically, the formal guarantees in the 
C standard about for which array indexing ptrdiff_t are somewhat weak, 
maybe we might need to change this to support bigger arrays or maybe use 
the type R_xlen_t also for something slightly different that needs to be 
bigger.



using the string macro found in Mr Kalibera's commit of r85641:
R_PRIdXLEN_T

I think this will be the best solution once we can afford
having our packages depend on R >= 4.4.


Yes, the goal was to allow most C99 way using this macro, so e.g.

Rprintf("my index %" R_PRIdXLEN_T "\n", xlength(x));

(note the space before and after the macro in concatenation to be C++ 
friendly). This doesn't have the limitations described before, but, 
there is a problem with translations. I am still looking into that, but 
from what I can tell, gettext doesn't make this possible. A good support 
would allow strings described this way and also translated this way, 
using the symbolic name of the macro, not the expansion.


But, unless you use gettext/translations, this last option is probably 
best. Yet you would have to define the macro if not defined to support R 
4.3 and older versions.


Tomas





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

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Henrik Bengtsson]

"%td" is not supported on all platforms/compilers.  This is what I got
when I added it to 'matrixStats';

* using log directory 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
* using R Under development (unstable) (2023-11-26 r85638 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* using options '--no-manual --as-cran'
* checking for file 'matrixStats/DESCRIPTION' ... OK
* this is package 'matrixStats' version '1.1.0-9003'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'matrixStats' can be installed ... [22s] WARNING
Found the following significant warnings:
binCounts.c:25:81: warning: unknown conversion type character 't' in
format [-Wformat=]
binCounts.c:25:11: warning: too many arguments for format [-Wformat-extra-args]
binMeans.c:26:60: warning: unknown conversion type character 't' in
format [-Wformat=]
binMeans.c:26:67: warning: unknown conversion type character 't' in
format [-Wformat=]
...
See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
for details.
* used C compiler: 'gcc.exe (GCC) 12.2.0'

It worked fine on Linux. Because of this, I resorted to the coercion
strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
int'.

/Henrik

On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov  wrote:
>
> On Wed, 29 Nov 2023 06:11:23 +1100
> Hugh Parsonage  wrote:
>
> > Rprintf("%lld", (long long) xlength(x));
>
> This is fine. long longs are guaranteed to be at least 64 bits in size
> and are signed, just like lengths in R.
>
> > Rprintf("%td, xlength(x));
>
> Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
> to fail on an (increasingly rare) 32-bit system where R_xlen_t is int
> (which is an implementation detail).
>
> In my opinion, ptrdiff_t is just the right type for array lengths if
> they have to be signed (which is useful for Fortran interoperability),
> so Rprintf("%td", (ptrdiff_t)xlength(x)) would be my preferred option
> for now. By definition of ptrdiff_t, you can be sure [*] that there
> won't be any vectors on your system longer than PTRDIFF_MAX.
>
> > using the string macro found in Mr Kalibera's commit of r85641:
> > R_PRIdXLEN_T
>
> I think this will be the best solution once we can afford
> having our packages depend on R >= 4.4.
>
> --
> Best regards,
> Ivan
>
> [*] https://en.cppreference.com/w/c/types/ptrdiff_t posits that there
> may exist long vectors that fit in SIZE_MAX (unsigned) elements but not
> PTRDIFF_MAX (signed) elements. If such vector exists, subtracting two
> pointers to its insides may result in undefined behaviour. This may be
> already possible in a 32-bit process on Linux running with a 3G
> user-space / 1G kernel-space split. The only way around the problem is
> to use unsigned types for lengths, but that would preclude Fortran
> compatibility.
>
> __
> 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

[R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Hugh Parsonage]

Hello,

I've been asked to update my package which contains numerous instances of

Rprintf("%lld", xlength(x));

that is, erroneously using %lld for objects of type R_xlen_t.  Having
searched for the correct way, I seem to have come across 3 competing
approaches:

Rprintf("%lld", (long long) xlength(x));
Rprintf("%td, xlength(x));
or
using the string macro found in Mr Kalibera's commit of r85641: R_PRIdXLEN_T

Which would be most advisable for my update, required in the next fortnight?


Hugh Parsonage

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

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Reed A. Cartwright]

If you want to future proof your code, the first or third is the way to go.

However, I prefer '%td' for readability. If R ever changes how R_xlen_t is
defined, I assume the checks will alert me to the need to change the format
string.

On Tue, Nov 28, 2023, 12:12 Hugh Parsonage  wrote:

> Hello,
>
> I've been asked to update my package which contains numerous instances of
>
> Rprintf("%lld", xlength(x));
>
> that is, erroneously using %lld for objects of type R_xlen_t.  Having
> searched for the correct way, I seem to have come across 3 competing
> approaches:
>
> Rprintf("%lld", (long long) xlength(x));
> Rprintf("%td, xlength(x));
> or
> using the string macro found in Mr Kalibera's commit of r85641:
> R_PRIdXLEN_T
>
> Which would be most advisable for my update, required in the next
> fortnight?
>
>
> Hugh Parsonage
>
> __
> R-package-devel@r-project.org mailing list
>
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!Z8-N4e22USctsG9tcHzIQD68xn2kfOxHbsIkktS-KaUNastoH7N_u-Rcd7A334uZhvRptIIDwDWKTXqgS8lSCAPOTA$
>

[[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] Canonical way to Rprintf R_xlen_t

[Tomas Kalibera]

On 11/28/23 21:55, Daniel Kelley wrote:

I hope it's okay to ask this on the present thread, rather than starting a new 
one...

On this issue of the C format for various integer-type items, I am finding that 
checks made with devtools::check_win_devel() give different results than those 
made with the github R-CMD-check action named ubuntu-latest-devel.  Which (if 
either) might be best for someone trying to fix up code for a CRAN release?

# Details

The code

NumericVector a;
::R_error("size %ld", a.size());

does not lead to warnings with R-CMD-check/ubuntu-latest-devel compilation, but 
it does with devtools::check_win_devel().  And the reverse is true with the code

NumericVector a;
::R_error("size %lld", a.size());

so one of these two methods must not be a good way to know if I'm doing the 
right thing.  I don't want to submit an update to CRAN that will lead to 
problems there, so I am keen to find a way to test this aspect without making a 
new submission (and thereby wasting time for the kind folks who run CRAN).


I think the best way to deal with these is to look at the lines and 
arguments identified by any of the compilers on any of the test 
platforms you have, and then based on reading the code and learning what 
the types really are (or are guaranteed to be) decide on how to fix. The 
presence and wording of the warnings may be compiler specific. In some 
cases even platform specific, because some C types have different size 
on different platforms, or map to different underlying types.


So, if the line above was identified by the compiler, check the 
documentation for NumericVector::size(), which type does it guarantee to 
return. The compiler warning may give a hint (what the type is in your 
build), but indeed it wouldn't consult the documentation. If the type is 
R_xlen_t (I didn't check if it is), then you could do e.g.


::R_error("size %lld", (long long)a.size());

or better

::R_error("size %" R_PRIdXLEN_T ", a.size());

as discussed elsewhere in this thread.

It is not a good idea to just use the type given in the warning, because 
that may not be portable. In this case, your compiler warning (on Linux) 
may have said "long int", which may have been how "ptrdiff_t" is defined 
on the platform by the compiler, which is probably how R_xlen_t is 
defined on your platform. But, it may be different elsewhere. On your 
second platform, the compiler warning may have said "long long int" (on 
Windows), which may have been how "ptrdiff_t" is defined there by the 
compiler, and on that platform, "long int" is different from "long long 
int", so the former didn't work.


If you use the Winbuilder service maintained by Uwe Ligges, you will 
have the same setup as one of the platforms used for CRAN incoming checks.


Best
Tomas



Thanks.

Dan.


On Nov 28, 2023, at 4:30 PM, Reed A. Cartwright  wrote:

CAUTION: The Sender of this email is not from within Dalhousie.

If I have read the R's change log correctly, C99 printf format is now
supported on Windows. I think the change was made in the last week.

On Tue, Nov 28, 2023, 13:01 Henrik Bengtsson 
wrote:


"%td" is not supported on all platforms/compilers.  This is what I got
when I added it to 'matrixStats';

* using log directory
'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
* using R Under development (unstable) (2023-11-26 r85638 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* using options '--no-manual --as-cran'
* checking for file 'matrixStats/DESCRIPTION' ... OK
* this is package 'matrixStats' version '1.1.0-9003'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'matrixStats' can be installed ... [22s] WARNING
Found the following significant warnings:
binCounts.c:25:81: warning: unknown conversion type character 't' in
format [-Wformat=]
binCounts.c:25:11: warning: too many arguments for format
[-Wformat-extra-args]
binMeans.c:26:60: warning: unknown conversion type character 't' in
format [-Wformat=]
binMeans.c:26:67: warning: unknown conversion type character 't' in
format [-Wformat=]
...
See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
for details.
* used C compiler: 'gcc.exe (GCC) 12.2.0'

It worked fine on Linux. Because of this, I resorted to the coercion
strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
int'.

/Henrik

On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov 
wrote:

On Wed, 29 Nov 2023 06:11:23 +1100
Hugh Parsonage  wrote:

Re: [R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Daniel Kelley]

To HB: I also maintain a package that has this problem.  I do not have access 
to a linux machine (or a machine with the C++ version in question) so I spent 
quite a while trying to get docker set up. That was a slow process because I 
had to install R, a bunch of packages, some other software, and so forth.  
Anyway, the docker container I had used didn't seem to have a compiler that 
gave these warnings.  But, by then, I saw that the machine used by

devtools::check_win_devel()

was giving those warnings :-)

So, now there is a way to debug these things.

PS. I also tried using rhub, but it takes a long time and often results in a 
PREPERROR.

On Nov 28, 2023, at 3:58 PM, Henrik Bengtsson  
wrote:

CAUTION: The Sender of this email is not from within Dalhousie.

"%td" is not supported on all platforms/compilers.  This is what I got
when I added it to 'matrixStats';

* using log directory 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
* using R Under development (unstable) (2023-11-26 r85638 ucrt)
* using platform: x86_64-w64-mingw32
* R was compiled by
gcc.exe (GCC) 12.3.0
GNU Fortran (GCC) 12.3.0
* running under: Windows Server 2022 x64 (build 20348)
* using session charset: UTF-8
* using options '--no-manual --as-cran'
* checking for file 'matrixStats/DESCRIPTION' ... OK
* this is package 'matrixStats' version '1.1.0-9003'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'matrixStats' can be installed ... [22s] WARNING
Found the following significant warnings:
binCounts.c:25:81: warning: unknown conversion type character 't' in
format [-Wformat=]
binCounts.c:25:11: warning: too many arguments for format [-Wformat-extra-args]
binMeans.c:26:60: warning: unknown conversion type character 't' in
format [-Wformat=]
binMeans.c:26:67: warning: unknown conversion type character 't' in
format [-Wformat=]
...
See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
for details.
* used C compiler: 'gcc.exe (GCC) 12.2.0'

It worked fine on Linux. Because of this, I resorted to the coercion
strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
int'.

/Henrik

On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov 
mailto:krylov.r...@gmail.com>> wrote:

On Wed, 29 Nov 2023 06:11:23 +1100
Hugh Parsonage  wrote:

Rprintf("%lld", (long long) xlength(x));

This is fine. long longs are guaranteed to be at least 64 bits in size
and are signed, just like lengths in R.

Rprintf("%td, xlength(x));

Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
to fail on an (increasingly rare) 32-bit system where R_xlen_t is int
(which is an implementation detail).

In my opinion, ptrdiff_t is just the right type for array lengths if
they have to be signed (which is useful for Fortran interoperability),
so Rprintf("%td", (ptrdiff_t)xlength(x)) would be my preferred option
for now. By definition of ptrdiff_t, you can be sure [*] that there
won't be any vectors on your system longer than PTRDIFF_MAX.

using the string macro found in Mr Kalibera's commit of r85641:
R_PRIdXLEN_T

I think this will be the best solution once we can afford
having our packages depend on R >= 4.4.

--
Best regards,
Ivan

[*] https://en.cppreference.com/w/c/types/ptrdiff_t posits that there
may exist long vectors that fit in SIZE_MAX (unsigned) elements but not
PTRDIFF_MAX (signed) elements. If such vector exists, subtracting two
pointers to its insides may result in undefined behaviour. This may be
already possible in a 32-bit process on Linux running with a 3G
user-space / 1G kernel-space split. The only way around the problem is
to use unsigned types for lengths, but that would preclude Fortran
compatibility.

__
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


[[alternative HTML version deleted]]

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

[Bioc-devel] How to declare optional system requirement for package

[Alex Wong via Bioc-devel]

Hi there,

I am the author of SpliceWiz. My package contains several wrapper functions
that run the STAR aligner on systems where it is installed. If STAR is not
found, these functions do nothing other than return a helpful message that
says STAR is not available. The vast majority of the functions in the
package does not depend on STAR, thus STAR is a highly optional requirement
for my package.

What is the best way to convey this in the DESCRIPTION file? Is it
acceptable to add the following line?

> SystemRequirements: STAR (optional)

Kind Regards,

Alex

-- 

*Alex Wong BSc(Med)/MBBS FRACP FRCPA PhD*
Research Officer, Gene and Stem Cell Therapy Program, Centenary Institute

-- 
 

[[alternative HTML version deleted]]

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