Re: [Rd] Slow try in combination with do.call
> Martin Maechler
> on Thu, 16 Sep 2021 17:48:41 +0200 writes:
> Alexander Kaever
> on Thu, 16 Sep 2021 14:00:03 + writes:
>> Hi,
>> It seems like a try(do.call(f, args)) can be very slow on error
depending on the args size. This is related to a complete deparse of the call
using deparse(call)[1L] within the try function. How about replacing
deparse(call)[1L] by deparse(call, nlines = 1)?
>> Best,
>> Alex
> an *excellent* idea!
> I have checked that the resulting try() object continues to contain the
> long large call; indeed that is not the problem, but the
> deparse()ing *is* as you say above.
> {The experts typically use tryCatch() directly, instead of try() ,
> which may be the reason other experienced R developers have not
> stumbled over this ...}
> Thanks a lot, notably also for the clear repr.ex. below.
> Best regards,
> Martin
OTOH, I find so many cases of deparse(*)[1] (or similar) in
R's own sources, I'm wondering
if I'm forgetting something ... and using nlines=* is not always
faster & equivalent and hence better ??
Martin
>> Example:
>> fun <- function(x) {
>> stop("testing")
>> }
>> d <- rep(list(mtcars), 1)
>> object.size(d)
>> # 72MB
>> system.time({
>> try(do.call(fun, args = list(x = d)))
>> })
>> # 8s
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Slow try in combination with do.call
> Alexander Kaever
> on Thu, 16 Sep 2021 14:00:03 + writes:
> Hi,
> It seems like a try(do.call(f, args)) can be very slow on error depending
on the args size. This is related to a complete deparse of the call using
deparse(call)[1L] within the try function. How about replacing
deparse(call)[1L] by deparse(call, nlines = 1)?
> Best,
> Alex
an *excellent* idea!
I have checked that the resulting try() object continues to contain the
long large call; indeed that is not the problem, but the
deparse()ing *is* as you say above.
{The experts typically use tryCatch() directly, instead of try() ,
which may be the reason other experienced R developers have not
stumbled over this ...}
Thanks a lot, notably also for the clear repr.ex. below.
Best regards,
Martin
> Example:
> fun <- function(x) {
> stop("testing")
> }
> d <- rep(list(mtcars), 1)
> object.size(d)
> # 72MB
> system.time({
> try(do.call(fun, args = list(x = d)))
> })
> # 8s
> Unsere Informationen zum Datenschutz finden Sie
hier.
> Evotec International GmbH, Hamburg. Amtsgericht Hamburg HRB 72242
> Geschäftsführung: Dr. Cord Dohrmann, Dr. Craig Johnstone, Enno Spillner
> STATEMENT OF CONFIDENTIALITY.
> This email and any attachments may contain confidential, proprietary,
privileged and/or private information.
> If received in error, please notify us immediately by reply email and
then delete this email and any attachments from your system. Thank you.
> __
> 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
[Rd] Slow try in combination with do.call
Hi,
It seems like a try(do.call(f, args)) can be very slow on error depending on
the args size. This is related to a complete deparse of the call using
deparse(call)[1L] within the try function. How about replacing
deparse(call)[1L] by deparse(call, nlines = 1)?
Best,
Alex
Example:
fun <- function(x) {
stop("testing")
}
d <- rep(list(mtcars), 1)
object.size(d)
# 72MB
system.time({
try(do.call(fun, args = list(x = d)))
})
# 8s
Unsere Informationen zum Datenschutz finden Sie
hier.
Evotec International GmbH, Hamburg. Amtsgericht Hamburg HRB 72242
Geschäftsführung: Dr. Cord Dohrmann, Dr. Craig Johnstone, Enno Spillner
STATEMENT OF CONFIDENTIALITY.
This email and any attachments may contain confidential, proprietary,
privileged and/or private information.
If received in error, please notify us immediately by reply email and then
delete this email and any attachments from your system. Thank you.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] IFC package - Solaris error polygon edge not found (zero-width or zero-height?)
Replying to myself and with some additional investigations I just tried once again on rhub - Oracle Solaris 10, x86, 32 bit, R-release and got the same error with a conditional font family modification where when Sys.info()["sysname"] == "SunOS", - pdf(), family argument is set to its default value "Helvetica" - gridExtra::ttheme_default, base_family argument is se to its default value "" Otherwise, "serif" is used In addition, the error in solaris shares "polygon edge not found" lately reported by Iñaki Úcar Though, I don't have the warning part, and mine is not happening during vignette rebuilding 2021-Aug-10, [R-pkg-devel] "polygon edge not found" on macos-arm64 >Dear CRAN maintainers, > >I see there's a new WARN on the recently added macos-arm64 platform >for quite a number of packages. Specifically, vignette rebuilding >fails with "polygon edge not found" (example in [1]). In addition, >there are a number of warnings like this: > >Warning in grid.Call(C_stringMetric, as.graphicsAnnot(x$label)) : > no font could be found for family "Arial" > >Is this something package authors should worry about in submissions? > >[1] https://cran.r-project.org/web/checks/check_results_simmer.html On Thu, Sep 16, 2021 at 12:15 PM git demont wrote: > Hello community, > > I plan to submit a new version of IFC package to CRAN. > > I checked it locally, on win-builder and on rhub. Almost everything looks > OK except for: > - Debian Linux, R-devel, GCC ASAN/UBSAN > - Oracle Solaris 10, x86, 32 bit, R-release > > On Debian Linux, R-devel, GCC ASAN/UBSAN, I get a PREPERROR, I suspect it > is a false pos since it says that xml2 package can not be installed. > My main concern is about Oracle Solaris 10, x86, 32 bit, R-release where > the function ExportToReport leads to the error reported in the title see: > https://artifacts.r-hub.io/IFC_0.1.2.tar.gz-0e84aed564a1488894eb7e34990443af/IFC.Rcheck/IFC-Ex.Rout > > However I got no error on Oracle Solaris 10, x86, 32 bit, R release, > Oracle Developer Studio 12.6 > > Some googling points to https://github.com/tidyverse/ggplot2/issues/2252. > The code of ExportToReport, is here > https://github.com/gitdemont/IFC/blob/master/R/ExportToReport.R, > The issue links this solaris error to ggplot but threads also mention grid > / font... > So my guess is that it could be related with the fact that I apply font > modifications through gridExtra::ttheme_default and in pdf() by using > "serif" in ExportToReport > > Do you think, this is only on rhub but will not happen on CRAN ? > I did several modifications since last CRAN update, but previous CRAN > version of IFC package already included those font family modifications in > ExportToReport (https://github.com/cran/IFC/blob/master/R/ExportToReport.R > ) > and did not produce solaris error in CRAN results ( > https://cran.r-project.org/web/checks/check_results_IFC.html) > > Nonetheless should it be safer to use other font family only for solaris ? > In such case what would you be your recommendations to check it (e.g. > Sys.info()["sysname"], I don't know the returned value on solaris) and to > apply another font family (but which one) > > Maybe, it is something else. But, in such case, I have absolutely no idea > where it comes from what I can do. > > Best, > Yohann > > > > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] IFC package - Solaris error polygon edge not found (zero-width or zero-height?)
Hello community, I plan to submit a new version of IFC package to CRAN. I checked it locally, on win-builder and on rhub. Almost everything looks OK except for: - Debian Linux, R-devel, GCC ASAN/UBSAN - Oracle Solaris 10, x86, 32 bit, R-release On Debian Linux, R-devel, GCC ASAN/UBSAN, I get a PREPERROR, I suspect it is a false pos since it says that xml2 package can not be installed. My main concern is about Oracle Solaris 10, x86, 32 bit, R-release where the function ExportToReport leads to the error reported in the title see: https://artifacts.r-hub.io/IFC_0.1.2.tar.gz-0e84aed564a1488894eb7e34990443af/IFC.Rcheck/IFC-Ex.Rout However I got no error on Oracle Solaris 10, x86, 32 bit, R release, Oracle Developer Studio 12.6 Some googling points to https://github.com/tidyverse/ggplot2/issues/2252. The code of ExportToReport, is here https://github.com/gitdemont/IFC/blob/master/R/ExportToReport.R, The issue links this solaris error to ggplot but threads also mention grid / font... So my guess is that it could be related with the fact that I apply font modifications through gridExtra::ttheme_default and in pdf() by using "serif" in ExportToReport Do you think, this is only on rhub but will not happen on CRAN ? I did several modifications since last CRAN update, but previous CRAN version of IFC package already included those font family modifications in ExportToReport (https://github.com/cran/IFC/blob/master/R/ExportToReport.R) and did not produce solaris error in CRAN results ( https://cran.r-project.org/web/checks/check_results_IFC.html) Nonetheless should it be safer to use other font family only for solaris ? In such case what would you be your recommendations to check it (e.g. Sys.info()["sysname"], I don't know the returned value on solaris) and to apply another font family (but which one) Maybe, it is something else. But, in such case, I have absolutely no idea where it comes from what I can do. Best, Yohann [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
