Dear David,
A follow-up if you don't mind: one slot of my actual S4 object contains either
NULL or a grid::frameGrob object. As you may know, frameGrob objects inherit
from multiple S3 classes: "frame" "gTree" "grob" "gDesc".
Based upon my understanding of the documentation, I need to define
Thanks David
I will work in this direction.
From: David Kepplinger
Sent: Tuesday, February 9, 2021 19:11
To: Sebastien Bihorel
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] How to get rid of R CMD check warning/note for new
S4 classes
Dear Sabastien,
Your second approach
Hi
I posted the following message on Jan 2nd and got no response... Assuming that
my timing was off (everybody was probably still on vacation or recovering from
New Year's celebration), I am taking the liberty to post it again, hoping that
I'll reach a larger audience today.
--
I am
I had some time, so I updated a toy package I have for explaining R
and Fortran use to use both the .Call and the .Fortran interfaces [1].
I think the actual Fortran code is as close to identical as I can
reasonably make it. On my computer, the .Call interface (_f) is around
4 times as fast as the
Dear Sabastien,
Your second approach is correct, but as the warning suggests, you have to
document the S4 class "character or NULL". The documentation at
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Documenting-S4-classes-and-methods
should get you started.
Best,
David
On Tue,
It is suggested this has to do with the way we are running R CMD check . For
now you may ignore the windows ERROR's. Your reviewer is aware of this as well.
Lori Shepherd
Bioconductor Core Team
Roswell Park Comprehensive Cancer Center
Department of Biostatistics & Bioinformatics
Elm &
Dear Bioc-devel,
Only on tokay2 (windows server), autonomics is giving warnings:
http://bioconductor.org/spb_reports/autonomics_buildreport_20210209130019.html
It looks like something strange is happening on tokay2, or have I overlooked
something?
Thank you for feedback!
Aditya
On 09/02/2021 11:01 a.m., Duncan Murdoch wrote:
I think the WRE manual says that an R_ARCH environment variable will be
set when subarchitectures are involved, but environment variables aren't
accessible in Makevars.
Actually, I probably misread the section about environment variables.
Duncan
On 09/02/2021 11:30 a.m., Sokol Serguei wrote:
Le 09/02/2021 à 17:01, Duncan Murdoch a écrit :
I think the WRE manual says that an R_ARCH environment variable will
be set when subarchitectures are involved, but environment variables
aren't accessible in Makevars.
Is there a standard way to get
Le 09/02/2021 à 17:01, Duncan Murdoch a écrit :
> I think the WRE manual says that an R_ARCH environment variable will
> be set when subarchitectures are involved, but environment variables
> aren't accessible in Makevars.
>
> Is there a standard way to get a value in Makevars which will match
I think the WRE manual says that an R_ARCH environment variable will be
set when subarchitectures are involved, but environment variables aren't
accessible in Makevars.
Is there a standard way to get a value in Makevars which will match
.Platform$r_arch once R is running?
Duncan Murdoch
Hi Martin
Thank you! I very much understand your reservations and know it was a bit
cheeky to poke.
I agree that in those cases where my (naive) patch results in two warnings,
keeping only the new one would better.
No strong opinion about the case where either ncol or nrow is 0. Maybe a
> Wolfgang Huber
> on Sat, 6 Feb 2021 19:49:11 +0100 writes:
> FWIW, I paste below a possible change to the warnings generating part of
the do_matrix function in R/src/main/array.c that adds the kind of warning that
Abby is asking for, and that IMHO would more often help users
13 matches
Mail list logo
