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
В 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
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()
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
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
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
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
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
>
В 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
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:
>
>
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
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
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
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
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
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
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
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,
"%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
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)
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,
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
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,
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
24 matches
Mail list logo
