[R-pkg-devel] Workaround for code/documentation mismatch
Hello,
I've written two functions to emulate do while/until loops seen in other
languages, but I'm having trouble documenting its usage. The function is
typically used like:
do ({
expr1
expr2
...
}) %while% (cond)
so I want to document it something like:
do(expr) %while% (cond)
do(expr) %until% (cond)
to look like the documentation for 'while' and 'if', but R CMD check
produces a "Code/documentation mismatch" warning, complaining that the
documentation should look like:
expr %while% cond
expr %until% cond
So, my question is, is there a way to bypass the
* checking for code/documentation mismatches
portion of R CMD check, at least for one file? Some way to acknowledge that
the code and documentation will mismatch, but that's okay.
Thank you!
[[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] Workaround for code/documentation mismatch
When not preceded by an expression wrapped in do(), %while% would throw an
error "do while loop must begin with 'do'". The function %while% looks like
`%while%` <- function (expr, cond)
invisible(.Call(C_do.while, substitute(expr), substitute(cond),
parent.frame()))
and the corresponding C function looks like
SEXP do_dowhile(SEXP expr, SEXP cond, SEXP rho)
{
/* we're looking for an expression of the form
do ( expr )
do ( { expr1 ; expr2 } )
there must NOT be a tag on the second item, the expression within
'do'
that is, we reject expressions of the form
do (var = expr)
do (var = { expr1 ; expr2 } ) */
if (TYPEOF(expr) != LANGSXP || CAR(expr) != install("do"))
error("do while loop must begin with 'do'");
else if (xlength(expr) != 2 || !isNull(TAG(CDR(expr
error("invalid 'expr'");
The 'do' part of the expression is irrelevant and later removed, it's only
required because it makes the syntax look more like other languages.
So the proper way to use %while% is
expr %while% cond
where expr is wrapped with do(), but I think it would be far more
understandable in the usage documentation to have it look like
do(expr) %while% (cond)
If it helps at all with context, I'll provide the R and C scripts I'm using.
On Tue, Aug 10, 2021 at 11:47 PM Hugh Parsonage
wrote:
> What is the behaviour of %while% if not preceded by an expression wrapped
> in do() ?
>
> On Wed, 11 Aug 2021 at 1:26 pm, Andrew Simmons wrote:
>
>> Hello,
>>
>>
>> I've written two functions to emulate do while/until loops seen in other
>> languages, but I'm having trouble documenting its usage. The function is
>> typically used like:
>>
>> do ({
>> expr1
>> expr2
>> ...
>> }) %while% (cond)
>>
>> so I want to document it something like:
>>
>> do(expr) %while% (cond)
>> do(expr) %until% (cond)
>>
>> to look like the documentation for 'while' and 'if', but R CMD check
>> produces a "Code/documentation mismatch" warning, complaining that the
>> documentation should look like:
>>
>> expr %while% cond
>> expr %until% cond
>>
>> So, my question is, is there a way to bypass the
>> * checking for code/documentation mismatches
>> portion of R CMD check, at least for one file? Some way to acknowledge
>> that
>> the code and documentation will mismatch, but that's okay.
>>
>>
>> Thank you!
>>
>> [[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] Workaround for code/documentation mismatch
Hello,
@Martin Maechler:
%until% and %while% use R's builtin repeat function. Something like
do(expr) %until% (cond)
repeat {
expr
if (cond)
break
}
are identical. After %until% and %while% check the arguments look correct,
it makes a call to repeat like above and evaluates it in the same
environment as %until% or %while% was called from. I haven't completely
reinvented the wheel here.
%until% and %while% are slower than repeat, but only by a microsecond or
two.
Admittedly, my documentation for %until% and %while% is dog water compared
to repeat, but I've tried to make it as clear as possible in my
documentation that %until% and %while% use repeat,
and included the link to the documentation for repeat.
@Duncan Murdoch:
I'll try renaming the arguments, thank you for the suggestion. Also, I
didn't realize you could put R comments in \usage with #, so I might try
that as well, thank you!
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] if statements in NAMESPACE file
I noticed in the Writing R Extensions manual, it says that within a NAMESPACE file, "Only very simple conditional processing of if statements is implemented.". I tried it out myself by importing a Windows exclusive function: if (.Platform$OS.type == "windows") importFrom(utils, getWindowsHandles) It also says in the manual that a NAMESPACE file "is not processed as R code", so I'm wondering if anyone knows exactly how if statements are handled within a NAMESPACE file. [[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] if statements in NAMESPACE file
Hello, I'm updating my package 'this.path' which is supposed to retrieve the absolute path of the executing script when called. It's similar to 'here', except that 'here' constructs paths relative to a project directory, whereas 'this.path' constructs paths relative to script directories. I was updating the section where I retrieve the executing script's path while running from a script open in Rgui for Windows, and I needed utils::getWindowsHandles to do such a thing. But utils::getWindowsHandles is a Windows only function, I would imagine that 'utils' contains a similar line of code as above: if (.Platform$OS.type == "windows") getWindowsHandles <- function() ... and then in the NAMESPACE: if (.Platform$OS.type == "windows") export(getWindowsHandles) so I'd like to change my code to getWindowsHandles and import getWindowsHandles from utils, but I can only do that on Windows, and so the conditional importing should work for me. At no point does my function mis-behave because of a attempting to use a function that isn't exported on that platform, because within the function it only uses getWindowsHandles if the OS is Windows. On Thu, Sep 30, 2021 at 11:01 AM Mark Miller wrote: > Returning to the original question, if it's helpful: I'd like to know what > constraints led to considering an export only available on Windows, and see > if we can suggest some other designs. It'd be good to keep the user's > mental model abstracted from the platform they're working on. There are > often unavoidable differences due to platform, but usually they're handled > with warnings and errors rather than selective exports. > > On Thu, Sep 30, 2021 at 3:40 AM Berry Boessenkool < > berryboessenk...@hotmail.com> wrote: > > > > > One of the very best fortunes nominations! > > > > [...] > > > > I suspect something like > > > >if (stats::runif(1) > 0.5) export(someFunction) > > > > would work too, for a particularly frustrating experience for your > > users. It would mean half the installs export the function, and half > > don't. > > > > Duncan Murdoch > > > > > > [[alternative HTML version deleted]] > > > > __ > > 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 > [[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] if statements in NAMESPACE file
You are correct, it most definitely is a convoluted way to identify a path, but this is one incredibly specific scenario. The case I'm talking about only occurs when running a script in Rgui for Windows using Ctrl+R (or pasting into the R Console) to run a piece of code. Scenarios such as running from the Windows command-line / / Unix terminal / / using source, sys.source, RStudio's debugSource, and testthat::source_file are handled in a much different and less convoluted manner. And in this case, the window handle relevant to the script has to exist, otherwise you couldn't open the script in Rgui in the first place. I'm not disagreeing that it's a horrible way to retrieve the path of the executing script, but it's the only way if you're running from an open script in Rgui for Windows. On Thu, Sep 30, 2021 at 5:53 PM Jeff Newmiller wrote: > Expecting a window handle relevant to the script to exist for the purpose > of identifying a path seem to be orthogonal problems to me. But Andrew has > indicated offlist that he has alternate code for other cases only uses this > technique when appropriate. > > I still feel this is too convoluted as a way to identify a path, but if he > covers all cases then my opinion is just an opinion. > > On September 30, 2021 2:34:48 PM PDT, Duncan Murdoch < > murdoch.dun...@gmail.com> wrote: > >On 30/09/2021 5:21 p.m., Jeff Newmiller wrote: > >> What if you are on Windows but running R at the command prompt, or via > cygwin, or in the console window of RStudio? > >> > >> This seems unstable to me. > > > >Sorry, too much context missing. What's unstable? > > > >Duncan Murdoch > > > >> > >> On September 30, 2021 11:52:16 AM PDT, Andrew Simmons < > akwsi...@gmail.com> wrote: > >>> Hello, > >>> > >>> > >>> I'm updating my package 'this.path' which is supposed to retrieve the > >>> absolute path of the executing script when called. It's similar to > 'here', > >>> except that 'here' constructs paths relative to a project directory, > >>> whereas 'this.path' constructs paths relative to script directories. I > was > >>> updating the section where I retrieve the executing script's path while > >>> running from a script open in Rgui for Windows, and I needed > >>> utils::getWindowsHandles to do such a thing. But > utils::getWindowsHandles > >>> is a Windows only function, I > >>> would imagine that 'utils' contains a similar line of code as above: > >>> > >>> > >>> if (.Platform$OS.type == "windows") > >>> getWindowsHandles <- function() ... > >>> > >>> > >>> and then in the NAMESPACE: > >>> > >>> > >>> if (.Platform$OS.type == "windows") > >>> export(getWindowsHandles) > >>> > >>> > >>> so I'd like to change my code to getWindowsHandles and import > >>> getWindowsHandles from utils, but I can only do that on Windows, and > so the > >>> conditional importing should work for me. At no point does my function > >>> mis-behave because of a attempting to use a function that isn't > exported on > >>> that platform, because within the function it only uses > getWindowsHandles > >>> if the OS is Windows. > >>> > >>> > >>> On Thu, Sep 30, 2021 at 11:01 AM Mark Miller < > mark.roman.mil...@gmail.com> > >>> wrote: > >>> > >>>> Returning to the original question, if it's helpful: I'd like to know > what > >>>> constraints led to considering an export only available on Windows, > and see > >>>> if we can suggest some other designs. It'd be good to keep the user's > >>>> mental model abstracted from the platform they're working on. There > are > >>>> often unavoidable differences due to platform, but usually they're > handled > >>>> with warnings and errors rather than selective exports. > >>>> > >>>> On Thu, Sep 30, 2021 at 3:40 AM Berry Boessenkool < > >>>> berryboessenk...@hotmail.com> wrote: > >>>> > >>>>> > >>>>> One of the very best fortunes nominations! > >>>>> > >>>>> [...] > >>>>> > >>>>>I suspect something like > >>>>> > >>>>>
Re: [R-pkg-devel] Is there a better way ...?
I think the simplest answer is to store the variable in the functions
frame. I'm assuming here that the only plot.foo needs access to .fooInfo,
if not this can be changed.
plot.foo <- function (...)
{
.fooInfo
}
environment(plot.foo) <- new.env()
evalq({
.fooInfo <- NULL
}, environment(plot.foo))
Make your function, and do whatever you need with .fooInfo within said
function. Whenever you previously updated .fooInfo in the global
environment, update .fooInfo in plot.foo environment instead.
Also, because .fooInfo is not stored in the package's frame, it won't be
locked when the namespace is sealed. If you created it at the toplevel,
that would create some issues. But this works fine.
On Thu, Oct 21, 2021 at 12:29 AM Rolf Turner
wrote:
>
> I have a plot method (say plot.foo()) that I want to be able to call so
> that if argument "add" is set equal to TRUE, then further structure will
> be added to the same plot. This is to be used *only* in the context in
> which the plot being added to was created using plot.foo().
>
> [Please don't ask me why I don't do everything in a single call to
> plot.foo(). There *are* reasons.]
>
> In order to make sure that the "further structure" has the appropriate
> form, the call to plot.foo(...,add=TRUE,...) needs to access information
> about what was done in the previous call to plot.foo().
>
> Initially I tried to effect this by creating, in a call of the form
> plot.foo(...,add=FALSE,...), an object, say ".fooInfo", in the global
> environment, and then having the call plot.foo(...,add=TRUE,...)
> access the necessary information from ".fooInfo".
>
> It all worked OK, but when I built my package for Windoze, using
> win-builder, I got a note of the form:
>
> > NOTE
> > Found the following assignment to the global environment:
> > File 'pckgename/R/plot.foo.R':
> > assign(".fooInfo", fooInfo, pos = 1)
>
> I thought uh-oh; CRAN will kick up a stink if/when I submit my package.
>
> I think I've figured out a work-around using tempfile(). There
> are difficulties in that tempfile() creates unique names by tacking
> on an alpha-numeric string such as "38348397e595c" to the file name
> that I specify, so the call to plot.foo(...,add=TRUE,...) cannot know
> the *exact* file name. I think I can get around that by grepping on
> "fooInfo" in list.files(tempdir()). I also need to make sure that
> I unlink() any old instances of files in tempdir() with the string
> "fooInfo" in their names before creating a new instance. Elsewise
> ambiguities will ensue.
>
> As I say --- I think this can all be made to work. But
> Am I missing some "obvious" strategy? I.e. is there a
> better/simpler/less convoluted way of handling this problem?
>
> Grateful for any pearls of wisdom.
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
> __
> 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
Re: [R-pkg-devel] Is there a better way ...?
Duncan's version is much clearer than my solution, and the only reason I
use my version is so that the source reference of the function looks
neater, and so that auto-code-indentation won't mess up my source reference
either.
If none of that made sense, don't worry about it, use Duncan's approach.
I think the advantage of Duncan's solution is that getting and setting
.fooInfo is more compact.
It's not clear exactly how you're modifying .fooInfo, but I'll assume
plot.foo is modifying it. Using Duncan's approach, you might do something
like:
plot.foo <- local({
.fooInfo <- 0
function (...)
{
value <- .fooInfo # get .fooInfo
.fooInfo <<- .fooInfo + 1 # set .fooInfo, you must use <<- here
instead of <-
return(value)
}
})
and Deepayan's approach:
..foo.env <- local({
.fooInfo <- 0
environment()
})
plot.foo <- function (...)
{
value <- .foo.env$.fooInfo # get .fooInfo
.foo.env$.fooInfo <- .foo.env$.fooInfo + 1 # set .fooInfo
return(value)
}
Both of these work perfectly fine, so you don't have to worry too much
about which you implement. The differences are mostly just visual
appearance, they have nearly equivalent functionality and performance.
On Thu, Oct 21, 2021 at 2:45 AM Rolf Turner wrote:
>
> On Thu, 21 Oct 2021 02:03:41 -0400
> Duncan Murdoch wrote:
>
> > On 21/10/2021 12:40 a.m., Andrew Simmons wrote:
> > > I think the simplest answer is to store the variable in the
> > > functions frame. I'm assuming here that the only plot.foo needs
> > > access to .fooInfo, if not this can be changed.
> > >
> > >
> > > plot.foo <- function (...)
> > > {
> > > .fooInfo
> > > }
> > > environment(plot.foo) <- new.env()
> > > evalq({
> > > .fooInfo <- NULL
> > > }, environment(plot.foo))
> > >
> > >
> > > Make your function, and do whatever you need with .fooInfo within
> > > said function. Whenever you previously updated .fooInfo in the
> > > global environment, update .fooInfo in plot.foo environment instead.
> > > Also, because .fooInfo is not stored in the package's frame, it
> > > won't be locked when the namespace is sealed. If you created it at
> > > the toplevel, that would create some issues. But this works fine.
> >
> > I agree with the final result, but I'd write the code differently:
> >
> > plot.foo <- local({
> >
> >.fooInfo <- NULL
> >
> >function (...) { ... }
> > })
> >
> > creates an environment, puts .fooInfo into it with value NULL, then
> > creates a function with that environment attached and returns it.
> >
> > I think Andrew's approach will work, but changing a function's
> > environment always worries me. Using local(), the function assigned
> > to plot.foo never has a different environment than the one it ends up
> > with (and I don't need to remember how evalq() works).
>
> Thanks everyone for these suggestions. They seem a great deal
> less shaganappi/kludgy than my previous approaches.
>
> I've never really felt totally comfortable with the environment
> concept, despite have used it quite a bit (basically in a
> hammer-and-hope style.)
>
> Can anyone comment on the difference between Deepayan's suggestion
> (create a new environment in the package) and Duncan's suggestion
> (create an environment that is local to plot.foo())? Are there pros
> and cons between the two?
>
> And Deepayan: what is the rationale for not exporting the new
> environment that you suggest creating? Presumably this guards against
> something. What? I'd just like to extend my (currently minimal)
> comprehension of the issues.
>
> I must admit that Andrew's suggestion kind of overwhelms and bewilders
> me. I really have no idea what evalq() does. I guess I could RTFM,
> but the thought of doing that scares me! :-)
>
> Thanks again everybody.
>
> cheers,
>
> Rolf
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
>
[[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] match.arg With S4 Methods and Missing Inputs
>From the line `function(A, B) standardGeneric("SetOfParams")`, A and B will
always have default values of R_MissingArg
Providing default values within the methods does nothing since A and B have
already been initialized before arriving at the method.
You could do something like:
if (missing(A))
A <- ...
if (missing(B))
B <- ...
within each method, and that would emulate having default values for A and
B.
On Mon, Nov 8, 2021 at 12:00 AM Dario Strbenac
wrote:
> Good day,
>
> How can a parameter take a default value from a vector of permitted ones,
> if it is missing?
>
> setClassUnion("characterOrMissing", c("character", "missing"))
> setClassUnion("integerOrMissing", c("integer", "missing"))
> setClass("SetOfParams", representation(A = "characterOrMissing", B =
> "integer"))
> setGeneric("SetOfParams", function(A, B) standardGeneric("SetOfParams"))
>
> setMethod("SetOfParams", c("missing", "missing"), function() # Empty
> constructor
> {
> new("SetOfParams", A = "M", B = 100L)
> })
>
> setMethod("SetOfParams", c("characterOrMissing", "integerOrMissing"),
> function(A = c("L", "M", "N"), B = 100L)
> {
> A <- match.arg(A)
> new("SetOfParams", A = A, B = B)
> })
>
> SetOfParams(B = 500L)
> Error in match.arg(A) : argument "A" is missing, with no default.
>
> How can I avoid the error about A having no default? I thought I specified
> it so that it does have one, which match.arg would set for me if the user
> did not specify one.
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> __
> 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
Re: [R-pkg-devel] Using function with same name as argument as default argument
Hello,
This isn't something that can be fixed in the parser. If an argument isn't
provided, its default value is evaluated inside the function, so it gives
you a loop where schema = schema(x), but then what's schema, it's
schema(x), thus the recursion error. you could do something like this:
foo <- function (x, schema = schema(x))
{
if (missing(schema)) {
rm(schema)
schema <- schema(x)
}
}
which, while kinda gross looking, means that schema = schema(x) can be
evaluated without causing a recursion error.
On Mon, Aug 8, 2022, 09:11 Jan van der Laan wrote:
> Not sure if this belongs on r-help or r-package-devel; decided for the
> latter as the question is mainly relevant when writing code to be used
> by others.
>
> The issue I run into is that I want to write a function similar to:
>
>
> foo <- function(x, schema = schema(x)) {
>if (is.null(schema)) stop("schema missing")
># ...
> }
>
> with 'schema()' something like (strongly simplified):
>
> schema <- function(x) attr(x, "schema")
>
>
> However using both the argument schema and calling the schema() function
> in one of the default arguments is not allowed ans results in the
> following somewhat cryptic error message:
>
> Error in foo(1:3) :
>promise already under evaluation: recursive default argument
> reference or earlier problems?
>
> I am looking for a clean solution to this. I can rename the argument or
> function, but calling it something other than schema feels impractical
> as both refer to the same thing (the schema of x). The best solution I
> have come up with until now is to define a second function to be used in
> default function arguments:
>
> schema_ <- schema
>
> foo <- function(x, schema = schema_(x)) {
>if (is.null(schema)) stop("schema missing")
># ...
> }
>
> I guess another solution would be:
>
> foo <- function(x, schema) {
>if (missing(schema)) schema <- schema(x)
> }
>
> But then it is not clear for the user from the interface that the
> 'schema' argument can be omitted.
>
> I am hoping some of you have other suggestions.
>
> And, is this something that could be 'fixed' in the R-parser?
>
>
> Thanks,
> Jan
>
> __
> 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
Re: [R-pkg-devel] Inquiry
This issue isn't related to RStudio. The issue is that you're exporting an object without providing any documentation for it. It sounds like you don't want to export it, so you need to go to your NAMESPACE file and remove the part was export(r2). If you do want to export it, then you need to document it, there's no way around that. The documentation doesn't need to be very detailed. On Mon., Sep. 26, 2022, 20:01 , wrote: > Hi there, > I am writing to aks your help for an issuue arising when I am writing my R > package using R studio 1.2.1335 as follows. > ``checking for missing documentation entries ... WARNING > Undocumented code objects: > 'r2' > All user-level objects in a package should have documentation entries." > The function r2.r is among .r files within R folder of my package. > I am not interested to present "r2" in the R topics documented: as a part > of first page of built pdf help file of my package. > I appreciate highly if you could help me to solve this issue. > > -- > This email was Anti Virus checked by Security Gateway. > > [[alternative HTML version deleted]] > > __ > 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
Re: [R-pkg-devel] R package build- C compilation issue related to math.h
You could install VirtualBox if you wanted to test it yourself, or if you have the tarball available online somewhere, I can try building it. On Wed., Oct. 19, 2022, 19:57 Vincent Plagnol, wrote: > Dear all at R-package-devel, > > I am struggling with a R package build. > It builds fine on my mac, which is my usual work environment. But when I > submit to CRAN, while the windows version is fine, the debian version fails > with a cryptic message: > > > > > > > > > > > > > > > ** installing *source* package ‘ExomeDepth’ ...** using staged > installation** libsg++-12 -std=gnu++14 -I"/home/hornik/tmp/R/include" > -DNDEBUG -I/usr/local/include -DUSE_TYPE_CHECKING_STRICT > -D_FORTIFY_SOURCE=2 -fpic -g -O2 -Wall -pedantic -mtune=native -c > CNV_estimate.cpp -o CNV_estimate.ogcc-12 -I"/home/hornik/tmp/R/include" > -DNDEBUG -I/usr/local/include -DUSE_TYPE_CHECKING_STRICT > -D_FORTIFY_SOURCE=2 -fpic -g -O2 -Wall -Wstrict-prototypes -pedantic > -mtune=native -c ExomeDepth_init.c -o ExomeDepth_init.ogcc-12 > -I"/home/hornik/tmp/R/include" -DNDEBUG -I/usr/local/include > -DUSE_TYPE_CHECKING_STRICT -D_FORTIFY_SOURCE=2 -fpic -g -O2 -Wall > -Wstrict-prototypes -pedantic -mtune=native -c VP_gamma.c -o VP_gamma.oIn > file included from gsl_math.h:22, from > VP_gamma.c:23:/usr/include/x86_64-linux-gnu/bits/mathcalls.h:85:1: error: > expected ‘;’ before ‘extern’ 85 | __MATHCALL_VEC (acosh,, (_Mdouble_ > __x)); | > ^~/usr/include/x86_64-linux-gnu/bits/mathcalls.h:87:1: error: > expected ‘;’ before ‘extern’ 87 | __MATHCALL_VEC (asinh,, (_Mdouble_ > __x)); | ^~* > > > It is painful to debug because I don't have a debian machine. Furthermore > the issue seems to be in the file called at line 22 of gsl_math.sh which is > #include > These are rather arcane (to me) building blocks of C and I don't get why it > would suddenly create some issue on Debian (but not on mac or windows). > > My issue is perhaps that I copied substantial amount of the GSL library (as > opposed to using it as dependency) but it would be painful to do otherwise > now (this is an old package that has started to complain only recently). > > Any and all advice is welcome to help me interpret what I see here. > > Thanks, > > Vincent > > [[alternative HTML version deleted]] > > __ > 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
Re: [R-pkg-devel] R Package AQLSchemes
The capital does not matter for CRAN, packages may not be published if an existing package exists by the same name, regardless of case. Plus, the package at https://CRAN.R-project.org/package=AQLSchemes says the maintainer is John Lawson On Tue, Oct 25, 2022, 17:53 Rolf Turner wrote: > On Wed, 26 Oct 2022 10:42:54 +1300 > Rolf Turner wrote: > > > On Tue, 25 Oct 2022 15:01:18 -0600 > > John Lawson wrote: > > > > > I published the R Package AQLSChemes on CRAN in May 2022. The book > > > "An Introduction to Acceptance Sampling and SPC with R" was > > > published after that, and included examples of the use of > > > AQLSChemes package. Since then, I have retired and was not aware > > > that the AQLSChemes package was removed from CRAN. When I try to > > > run code from the book that requires the AQLSChemes package, I get > > > the message that the package doesn't exist. > > > > > > My question is, How can I find out why the package AQLSChemes was > > > removed from CRAN, and what do I need to do to restore it to CRAN? > > > > As Roy Mendelssohn has pointed out, AQLSChemes is there on CRAN. > > > > Perhaps you need to re-install it on your machine. > > Whoops! I neglected to note the crucial fact that it's "AQLSchemes" > --- lower case "c". Makes all the difference! > > cheers, > > Rolf Turner > > > -- > Honorary Research Fellow > Department of Statistics > University of Auckland > Phone: +64-9-373-7599 ext. 88276 > > __ > 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] Compiled code should not call non-API entry points in R
Hi everyone, I had some R code for dealing with connections, and I was using summary.connection(). I rewrote it in C, so I was doing something more like: #include Rconnection Rcon = R_GetConnection(file); Rcon->description or Rcon->class but now, when checking my package, I get the following note: * checking compiled code ... NOTE File 'this.path/libs/x64/this.path.dll': Found non-API call to R: 'R_GetConnection' Compiled code should not call non-API entry points in R. See 'Writing portable packages' in the 'Writing R Extensions' manual. This isn't surprising, (seen here: https://github.com/wch/r-source/blob/50ff41b742a1ac655314be5e25897a12d3096661/src/include/R_ext/Connections.h#L21) says that it is not part of the R API, and later on says that it is subject to change without notice or backwards compatibility. R_GetConnection was added in R 3.3.0, so I added "Depends: R (>= 3.3.0)" to my DESCRIPTION, then I added something like this to my header: #if !defined(R_CONNECTIONS_VERSION) #error why is R_CONNECTIONS_VERSION not defined #elif R_CONNECTIONS_VERSION == 1 extern Rconnection R_GetConnection(SEXP sConn); #else #error this.path is only implemented for R_CONNECTIONS_VERSION 1 #endif but the NOTE still remains. I think I've taken all the precautions I can, is there anything more I can do? Will I be unable to submit the update for my package? Will the CRAN team ignore the NOTE if I explain the precautions I added? __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] cross-ref possible ext.pkg's --not mentioned in DESCRIPTION file-- in non-code sections in .Rd files
Packages in Suggests and Enhances do not create a circular dependency, only
the packages in the Depends and Imports need to be installed at INSTALL and
loaded at load time. Packages in Suggests and Enhances are only needed at
check time, and even then it's more of a desire to be loaded than actually
needing to be loaded.
I would just put them in Suggests or Enhances
On Mon, Nov 7, 2022, 11:10 Peter Ruckdeschel
wrote:
> Hi,
>
> triggered by some new NOTEs uncovering infallacities in my packages on
> CRAN, I stumbled upon
>
> Result: NOTE Undeclared packages ‘distrMod’, ‘RobAStBase’ in Rd xrefs
>
> which is issued in R-devel-linux-x86_64-fedora-clang (but not otherwise).
>
> Digging into it, this comes from a text in a \seealso section where
> through something like
>
> \code{\{link}[]{}
>
> we want to link to a method provided in some extension package
> for a generic
> documented in Rd-file of the current package.
>
> In this case, we intentionally do not have in any of the entries
> "Depends", "Suggests",
> "Imports", "Enhances" in the DESCRIPTION file, as is neither
> needed visible for the
> user, nor for the code in the current package nor for testing code nor for
> example code and vignettes
> of the current package, and because having it in "Suggests" would produce
> a circular dependence
> as has the current package in its "Imports" section.
>
> Of course, in "Writing R extesions" we find that
>
> "Packages referred to by these ‘other forms’ should be declared in the
> DESCRIPTION file, in
>the ‘Depends’, ‘Imports’, ‘Suggests’ or ‘Enhances’ fields. "
>
> so I am aware that this is my fault, as I use these 'other forms' without
> declaration in the DESCRIPTION file.
> Now I guess I could wrap my conditional cross-ref into some R-code,
> testing whether is available,
> i.e., something like
>
> \Sexpr[eval=TRUE,stage=render,results=text]{if("" %in%
> installed.packages()[,1] )
> cat("\\code{\\{link}[]{}") else cat(" from
> package \\pkg{})
>
> and so produce the link only if is installed at rendering time,
> but I would guess such a
> conditional linkage would be something which could be of interest to a
> broader scope of R-package
> developers and hence could and should be implemented in a less cumbersome,
> and more
> efficient way.
>
> Any suggestions welcome,
> best, Peter
>
> --
> %**
> % Prof. Dr. Peter Ruckdeschel
> % Institut fuer Mathematik, Fakultaet V - Mathematik und
> Naturwissenschaften
> % Carl von Ossietzky Universitaet Oldenburg,
> % Postfach 5634, 26111 Oldenburg
> % Office: Wechloy W1 02-227 Tel: +49 (0)441 798-3240 Fax: +49 (0)441
> 798-193240
> %peter.ruckdesc...@uni-oldenburg.de
> %http://www.uni-oldenburg.de/peter-ruckdeschel
> %**
>
> [[alternative HTML version deleted]]
>
> __
> 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
Re: [R-pkg-devel] no visible binding for global variable ‘degree_C’ - CRAN check note
You can declare degree_C as a variable before using set_units():
degree_C <- NULL
set_units(T, degree_C)
you could use globalVariables() somewhere at the top-level in your package:
utils::globalVariables("degree_C")
or you could supply degree_C as a literal character string:
set_units(T, "degree_C")
On Sat, Dec 10, 2022 at 11:13 PM EcoC2S - Irucka Embry
wrote:
>
> In my iemisc package, I am using the units package.
>
> This is an example of how I am using the set_units function:
>
> T <- 20
>
> set_units(T, degree_C)
>
> Upon checking iemisc with devtools for CRAN submission, I receive the
> following note under "checking R code for possible problems":
>
> no visible binding for global variable ‘degree_C’
>
> Please tell me how to avoid that note in my R packages.
>
> Thank you.
>
> Irucka
>
> --
> --
> No fear, Only Love! / ¡No temas, solamente amor!
> -Irucka Ajani Embry, 15 March 2020
>
> Family Partners:
> http://www.sustainlex.org/
> https://www.schoolingsolutions.com/
>
> ---
>
> The business collaboration between EConsulting (tm)
> [https://www.econsultingllc.org/] and EcoC^2S, is Getting Back to
> Nature.
>
> Getting Back to Nature LocalHarvest --
> https://www.localharvest.org/getting-back-to-nature-M73453
> Getting Back to Nature -- https://www.gettingback2nature.farm/
>
> -- Irucka and his twin brother, Obiora, are featured in the Middle
> Tennessee Local Table Magazine Annual issue. The article discusses their
> family farm history and the current work that they are doing under
> Getting
> Back to Nature. The full magazine can be found here [the article begins
> on
> page 18 of the PDF document]:
>
> https://media.gettingback2nature.farm/pdf/LocalTable_ANNUAL_2020_lo_res.pdf
>
> -- Obiora and Irucka were interviewed separately in early 2020 for the
> Natural Resources Defense Council's (NRDC) "Regenerative Agriculture:
> Farm
> Policy for the 21st Century: Policy Recommendations to Advance
> Regenerative
> Agriculture" report written By Arohi Sharma, Lara Bryant, and Ellen Lee.
> The PDF report is available below:
>
> https://www.nrdc.org/sites/default/files/regenerative-agriculture-farm-policy-21st-century-report.pdf
>
> EcoC2S -- https://www.ecoccs.com/
> Principal, Irucka Embry, EIT
>
> Services:
> Growing Food
> Healthy Living Mentor
> Data Analysis with R
> R Training
> Chemistry and Mathematics Tutoring
> Free/Libre and Open Source Software (FLOSS) Consultation
>
> __
> 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 about use of `:::`
Here's another suggestion, not sure if it's any good, but you could
structure your functions like
parse_args <- function (envir = parent.frame())
{
evalq(list(a = a, b = b, ..., y = y, z = z), envir)
<...>
}
exported_fun <- function (a, b, ..., y, z)
{
parse_args()
<...>
}
It's seriously ugly, but it could work. You could also do some bquote
substitution
parse_args_expr <- quote(parse_args(a = a, b = b, ..., y = y, z = z))
exported_fun <- function (a, b, ..., y, z) NULL
body(exported_fun) <- bquote({
.(parse_args_expr)
<...>
})
On Wed, Dec 14, 2022, 20:36 David Kepplinger
wrote:
> Thank you both for the suggestions. I would prefer a clean stack trace in
> case of errors as input errors are caught by this function and hence users
> might very well see errors emitted from it. It seems more informative to me
> if the error message would say "Error in .parse_args…" than "Error in
> new.env(…". But since this solution was suggested by both of you it is
> likely that CRAN too would demand this or a similar approach instead of
> using `:::`. I know `:::` is expansive, but the computations that follow
> are typically at least a few minutes so anything that takes less than a few
> seconds won't be noticeable.
>
> I also thought about using `...` before, but then the signature of the
> user-facing functions would be incomplete and IDEs won't be able to provide
> suggestions.
>
> Thanks for the help!
>
> -- David
>
> On Wed, Dec 14, 2022 at 7:11 PM Simon Urbanek >
> wrote:
>
> > David,
> >
> > why not
> >
> > call[[1]] <- parse_args
> >
> > The assignment is evaluated in your namespace so that makes sure the call
> > is that of your function. The only downside I see is that in a stack
> trace
> > you'll see the definition instead of the name.
> > Or possibly
> >
> > do.call(parse_args, as.list(call[-1]))
> >
> > Cheers,
> > Simon
> >
> > PS: Note that ::: is expensive - it probably doesn't matter here, but
> > would in repeatedly called functions.
> >
> >
> > > On 15/12/2022, at 12:19 PM, David Kepplinger <
> david.kepplin...@gmail.com>
> > wrote:
> > >
> > > Dear List,
> > >
> > > I am working on updating the pense package and refactored some of the
> > > methods. I have several functions which take the same arguments, hence
> > I'm
> > > sending all these arguments to an internal function, called
> > `parse_args()`.
> > > Since I want to evaluate the arguments in the caller's environment, I'm
> > > using the following code
> > >
> > > call <- match.call(expand.dots = TRUE)
> > > call[[1]] <- quote(pense:::parse_args)
> > > args <- eval.parent(call)
> > >
> > > Of course, R CMD CHECK complains about the use of `:::`, as it's almost
> > > never needed. I think the above usage would fall into that area of
> > > "almost", but I'm not sure if (a) there's a better approach and (b) the
> > > CRAN team would agree with me. I would have to test (b) by submitting
> and
> > > working with the CRAN team, but I wanted to ask the list first to see
> if
> > > I'm missing something obvious. I don't want to export the function
> > > parse_args() as it's not useful for a user, and the use is truly
> > internal.
> > >
> > > Thanks and all the best,
> > > David
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > __
> > > 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
>
[[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] Rcmd check skip example
Rd documentation is latex like, so comments can be included with a percent symbol. You should write \% if you intend to write a literal percent symbol. On Wed, Jan 18, 2023, 23:00 mai zhou wrote: > Hi, > > In the process of adding examples to the .RD file, I noticed > Rcmd check seems to skip certain example code. > > I put my example code x%*%y%*%z (matrix multiplication) in the > RD file. After running Rcmd check > (on windows) and look into the xxx.Rcheck directory, > xxx-EX.ROUT file, it seems that the example check stopped > at x (i.e. everything after % sign is ignored, like LaTeX). > > That seems like a bug. Can anyone confirm on newer version? > > Mine: > > > sessionInfo() > R version 4.1.2 (2021-11-01) > Platform: x86_64-w64-mingw32/x64 (64-bit) > Running under: Windows 10 x64 (build 22621) > > Matrix products: default > > locale: > [1] LC_COLLATE=English_United States.1252 > [2] LC_CTYPE=English_United States.1252 > [3] LC_MONETARY=English_United States.1252 > [4] LC_NUMERIC=C > [5] LC_TIME=English_United States.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.1.2emplikAUC_0.3 rootSolve_1.8.2.3 emplik2_1.32 > > > > > Mm... I have Win11, why the sessionInfo() say W10 ? (but that is something > else) > > best, > > Mai Zhou > > [[alternative HTML version deleted]] > > __ > 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
Re: [R-pkg-devel] Package internal function / Undocumented code objects warning
I'm not very familiar with Roxygen, so I might be making incorrect assumptions here. Why are you exporting a function if it's meant to be internal? And the @noRd would indicate that a documentation file is not created. I would remove @noRd or @export On Fri, Feb 24, 2023, 16:11 EcoC2S - Irucka Embry wrote: > Greetings, I am attaching the complete R file for your review. The > vlookup_internal function and all of the functions in the package are > derived from the expss package version 0.10.7. The vlookup function was > modified in later versions so I gathered what I needed from that > previous version and included in the attached R file. > > The vlookup_internal function is meant to be an internal function that > is used by the vlookup and other functions. I have documented the > vlookup_internal function to escape the warning message, but it doesn't > seem to work. > > I am enclosing the warning message below: > > * checking for missing documentation entries ... WARNING > Undocumented code objects: >‘vlookup_internal’ > All user-level objects in a package should have documentation entries. > See chapter ‘Writing R documentation files’ in the ‘Writing R > Extensions’ manual. > > Thank you. > > Irucka Embry > > > -- > -- > No fear, Only Love! / ¡No temas, solamente amor! > -Irucka Ajani Embry, 15 March 2020 > > Family Partners: > http://www.sustainlex.org/ > https://www.schoolingsolutions.com/ > > > --- > > The business collaboration between EConsulting (tm) > [https://www.econsultingllc.org/] and EcoC^2S, is Getting Back to > Nature. > > Getting Back to Nature LocalHarvest -- > https://www.localharvest.org/getting-back-to-nature-M73453 > Getting Back to Nature -- https://www.gettingback2nature.farm/ > > -- Irucka and his twin brother, Obiora, are featured in the Middle > Tennessee Local Table Magazine Annual issue. The article discusses their > family farm history and the current work that they are doing under > Getting > Back to Nature. The full magazine can be found here [the article begins > on > page 18 of the PDF document]: > > https://media.gettingback2nature.farm/pdf/LocalTable_ANNUAL_2020_lo_res.pdf > > -- Obiora and Irucka were interviewed separately in early 2020 for the > Natural Resources Defense Council's (NRDC) "Regenerative Agriculture: > Farm > Policy for the 21st Century: Policy Recommendations to Advance > Regenerative > Agriculture" report written By Arohi Sharma, Lara Bryant, and Ellen Lee. > The PDF report is available below: > > > https://www.nrdc.org/sites/default/files/regenerative-agriculture-farm-policy-21st-century-report.pdf > > EcoC2S -- https://www.ecoccs.com/ > Principal, Irucka Embry, EIT > > Services: > Growing Food > Healthy Living Mentor > Data Analysis with R > R Training > Chemistry and Mathematics Tutoring > Free/Libre and Open Source Software (FLOSS) > Consultation__ > 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] Changing R Package Maintainer
Hi, I'm changing my name and my email address. I've got an update I'd like to submit to CRAN, I've changed my name and email in my DESCRIPTION. I couldn't find any details about changing maintainers in the R manuals unfortunately. Someone online said to just submit the update, CRAN will send one email to the new address confirming the submission, and another to the old address confirming the new maintainer. Someone else said to email CRAN from the old address about the new maintainer and their address, and wait for a response of approval before submission. It was unclear if that would be cran-submissi...@r-project.org or c...@r-project.org, but I'd guess the first. Has anyone else done this before or does anyone know the best procedure? Also, given that this isn't a transfer of ownership, I'm still the same person with a different name, would that make this process easier? Thank you! [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Complex Math Functions in C
Hello, I've been trying to translate some of my slow R code into C code, and I need the complex math functions to be able to do this. I assumed I could access them with #include but it seems as though that file only contains the definition of structure Rcomplex. Any help accessing these functions would be greatly appreciated! [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Rcmd check and sourcing URL issues
Hello, I am the maintainer of this.path <https://CRAN.R-project.org/package=this.path>, and as you can see from the CRAN checks <https://cran.r-project.org/web/checks/check_results_this.path.html>, it flags a NOTE that package testthat <https://CRAN.R-project.org/package=testthat> is undeclared in the R documentation references. this.path allows an R script to know its own path (from 'RStudio', 'RGui', the command-line, and when using 'source' or any source equivalents), and I recently added functionality to this.path when using testthat::source_file. However, I don't know how to go about declaring package testthat such that I can use it reference it in the R documentation WITHOUT forcing testthat to load or attach itself when this.path is loaded or attached (I don't want to declare testthat is the Imports or Depends field of the DESCRIPTION file). Another issue related to this.path and base::source, but the fix for this is more opinionated than the above. If someone sources a URL which contains a call to this.path, should this.path: * skip that source call and look for the next available path (which may or may not exist) * throw an error that this.path is incompatible when sourcing URLs * return the URL from that source call Any help is greatly appreciated, thank you! Regards, Andrew Simmons [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
