[R-pkg-devel] Fwd: CRAN Submission rkriging 1.0.1

[Bill Huang]

Hi, Team.

I am working on a package that uses RcppEigen. The package can be installed
successfully locally and passed CRAN auto-check. However, it cannot pass
the gcc-UBSAN test with the following error message: a problem with the LLT
function in Eigen. I am not sure how to fix this. Any suggestion or help is
highly appreciated!

rkriging.Rcheck/rkriging-Ex.Rout:/data/gannet/ripley/R/test-dev/RcppEigen/include/Eigen/src/Cholesky/LLT.h:66:49:
runtime error: load of value 20880, which is not a valid value for type
'ComputationInfo'
 #0 0x7f967645dfc6 in Eigen::LLT, 1>::operator=(Eigen::LLT, 1>&&)
/data/gannet/ripley/R/test-dev/RcppEigen/include/Eigen/src/Cholesky/LLT.h:66
 #1 0x7f967645dfc6 in Kriging::Kriging(Eigen::Matrix const&, Eigen::Matrix const&,
Kernel&, bool const&)
/data/gannet/ripley/R/packages/incoming/rkriging.Rcheck/00_pkg_src/rkriging/src/kriging.cpp:26
 #2 0x7f96769cac53 in
UniversalKriging::UniversalKriging(Eigen::Matrix const&, Eigen::Matrix const&, Kernel&, bool
const&, unsigned long const&,
Rcpp::Function_Impl)
/data/gannet/ripley/R/packages/incoming/rkriging.Rcheck/00_pkg_src/rkriging/src/kriging.cpp:385
 #3 0x7f9676929f68 in Rcpp::Constructor_6, Eigen::Matrix, Kernel&, bool, unsigned long,
Rcpp::Function_Impl >::get_new(SEXPREC**, int)
/data/gannet/ripley/R/test-dev/Rcpp/include/Rcpp/module/Module_generated_Constructor.h:115
 #4 0x7f96767c091f in
Rcpp::class_::newInstance(SEXPREC**, int)
/data/gannet/ripley/R/test-dev/Rcpp/include/Rcpp/module/class.h:131
 #5 0x7f967c9d56a8 in class__newInstance(SEXPREC*)
/tmp/Rtmp7QBClZ/R.INSTALL19fb7f3cfc39c8/Rcpp/src/module.cpp:143

Thank you!
Best,
Chaofan

-- Forwarded message -
From: Uwe Ligges 
Date: Tue, Jul 16, 2024 at 2:19 AM
Subject: Re: CRAN Submission rkriging 1.0.1
To: Bill Huang <10billhuan...@gmail.com>


Please ask on the mailing list 

Best,
Uwe Ligges


On 16.07.2024 08:32, Bill Huang wrote:
> Hi, Uwe.
>
> Thanks for the message! I am not sure how to resolve this issue. Is
> there anyone you know that might be able to help me on this?
>
> Thank you!
> Best,
> Chaofan
>
> On Mon, Jul 15, 2024 at 11:44 AM Uwe Ligges
>  <mailto:lig...@statistik.tu-dortmund.de>> wrote:
>
> Thanks, we still see with gcc-UBSAN
>
>
>
 
rkriging.Rcheck/rkriging-Ex.Rout:/data/gannet/ripley/R/test-dev/RcppEigen/include/Eigen/src/Cholesky/LLT.h:66:49:
> runtime error: load of value 20880, which is not a valid value for
type
> 'ComputationInfo'
>   #0 0x7f967645dfc6 in Eigen::LLT -1, -1>, 1>::operator=(Eigen::LLT -1>, 1>&&)
>
 /data/gannet/ripley/R/test-dev/RcppEigen/include/Eigen/src/Cholesky/LLT.h:66
>   #1 0x7f967645dfc6 in Kriging::Kriging(Eigen::Matrix -1, -1,
> 0, -1, -1> const&, Eigen::Matrix const&,
> Kernel&, bool const&)
>
 
/data/gannet/ripley/R/packages/incoming/rkriging.Rcheck/00_pkg_src/rkriging/src/kriging.cpp:26
>   #2 0x7f96769cac53 in
> UniversalKriging::UniversalKriging(Eigen::Matrix -1> const&, Eigen::Matrix const&, Kernel&,
> bool
> const&, unsigned long const&,
> Rcpp::Function_Impl)
>
 
/data/gannet/ripley/R/packages/incoming/rkriging.Rcheck/00_pkg_src/rkriging/src/kriging.cpp:385
>   #3 0x7f9676929f68 in Rcpp::Constructor_6 Eigen::Matrix, Eigen::Matrix 0, -1, 1>, Kernel&, bool, unsigned long,
> Rcpp::Function_Impl >::get_new(SEXPREC**, int)
>
 
/data/gannet/ripley/R/test-dev/Rcpp/include/Rcpp/module/Module_generated_Constructor.h:115
>   #4 0x7f96767c091f in
> Rcpp::class_::newInstance(SEXPREC**, int)
> /data/gannet/ripley/R/test-dev/Rcpp/include/Rcpp/module/class.h:131
>   #5 0x7f967c9d56a8 in class__newInstance(SEXPREC*)
> /tmp/Rtmp7QBClZ/R.INSTALL19fb7f3cfc39c8/Rcpp/src/module.cpp:143
>
>
> Please fix and resubmit.
>
> Best,
> Uwe Ligges
>
>
>
> On 13.07.2024 23:47, CRAN Package Submission Form wrote:
>  >
>  > [This was generated from CRAN.R-project.org/submit.html
> <http://CRAN.R-project.org/submit.html>]
>  >
>  > The following package was uploaded to CRAN:
>  > ===
>  >
>  > Package Information:
>  > Package: rkriging
>  > Version: 1.0.1
>  > Title: Kriging Modeling
>  > Author(s): Chaofan Huang [aut, cre], V. Roshan Joseph [aut]
>  > Maintainer: Chaofan Huang <10billhuan...@gmail.com
> <mailto:10billhuan...@gmail.com>>
>  > Depends: R (>= 3.0.2)
>  > Description: An 'Eigen'-based computationally efficient 'C++'
> 

[R-pkg-devel] Possible bug in Codoc checking with R CMD Check

[bill]

Hello,

 

I have a function that is used to generate LaTeX code for reporting.  When
doing R CMD check, I get an error that the "\\ldots" argument does not match
between the code and documentation.  I think that the error is coming from
the Codoc check in R CMD check not escaping the backslash before ldots.  Is
my diagnosis correct?  If so, what is the best way to report this as a bug
in R CMD check?

 

The R CMD check warning:

 

Warning: Codoc mismatches from documentation object
'topic_long_table_header':

topic_long_table_header

  Code: function(x, col_names = NULL, above_col_names = "\\hline",

 below_col_names = "\\hline",

 subsequent_page_notification = "\\ldots continued",

 latex_header = NULL, verbatim = NULL)

  Docs: function(x, col_names = NULL, above_col_names = "\\hline",

 below_col_names = "\\hline",

 subsequent_page_notification = "\... continued",

 latex_header = NULL, verbatim = NULL)

  Mismatches in argument default values:

Name: 'subsequent_page_notification' Code: "\\ldots continued" Docs:
"\... continued"

 

The function looks like:

 

topic_long_table_header <- function(x,

col_names=NULL,

above_col_names="\\hline",
below_col_names="\\hline",

subsequent_page_notification="\\ldots
continued",

latex_header=NULL,

verbatim=NULL) {

 # do stuff here

}

 

The .Rd file (generated by roxygen2) looks like:

 

topic_long_table_header(

  x,

  col_names = NULL,

  above_col_names = "hline",

  below_col_names = "hline",

  subsequent_page_notification = "ldots continued",

  latex_header = NULL,

  verbatim = NULL

)

 

If looking in more detail would help, relevant parts of the GitHub repo are:

 

https://github.com/billdenney/TopicLongTableR/blob/main/R/topic_long_table_h
eader_footer.R

https://github.com/billdenney/TopicLongTableR/blob/main/man/topic_long_table
_header.Rd

https://github.com/billdenney/TopicLongTableR/actions/runs/5771551599/job/15
645624146#step:6:99

 

Thanks,

 

Bill


[[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] Inconsistent functionality of c++ code in MatchIt

[Bill Dunlap]

I see the problem when I compile the C++ code on Ubuntu 20.04 and the
latest R-devel with
   C++ compiler: ‘g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
If I change all the unadorned 'abs' calls in src/nn_matchC_vec.cpp with the
prefix 'std::' the problem goes away.

-Bill


On Thu, May 11, 2023 at 11:12 AM Noah Greifer 
wrote:

> Hello,
>
> I'm the mainter of the package *MatchIt*, which uses *Rcpp* to implement
> nearest neighbor matching. One way to customize nearest neighbor
> matching is to add a caliper, which is the largest distance two units can
> be from each other before they are not allowed to be matched. I've had some
> users complain recently that the caliper is not working for them, i.e.,
> even after specifying a caliper, units are being matched who are
> farther apart then the caliper width. I have been unable to replicate this
> problem on my Mac; the caliper always works as intended.
>
> One user noted that even when using the same package version, the
> performance varied across two machines: one obeyed the caliper and one
> didn't. I thought this might be related to the version of R installed, as
> for some users updating R fixed the issue, but for others it didn't. I'm
> kind of at a loss.
>
> I have a suspicion that the problem is related to the function abs() in the
> C++ functions find_right() and find_left() that I wrote to perform the
> matching, which are in nn_match_vec.cpp
> <https://github.com/kosukeimai/MatchIt/blob/master/src/nn_matchC_vec.cpp>.
> I have had problems with abs() before (seemingly related to a namespace
> conflict between std and Rcpp). In this case, abs() is used in the
> following way:
>
> if (abs(distance[ii] - distance[k]) > caliper_dist) {
> //if closest is outside caliper, break; none can be found
> break;
>  }
>
> Here, distance is a NumericVector, and ii and k are ints. My expectation is
> that this would dispatch to std::abs() with a double as its input. It's
> possible something is going wrong there. I'm wondering if this has to do
> with recent changes to R's C++ engine or compilers.
>
> If you want to run code to test whether the caliper is working correctly on
> your machine, you can run the following code:
>
> install.packages("MatchIt")
> data("lalonde", package = "MatchIt")
> m <- MatchIt::matchit(treat ~ age + educ + race + re74,
>   data = lalonde, caliper = .01)
> summary(m)$nn
>
> If the caliper is working correctly, you should see a small matrix that has
> the row
>
> Matched88  88
>
> If not, you would see the row
>
> Matched   185 185
>
> The GitHub issue of people complaining about this is here
> <https://github.com/kosukeimai/MatchIt/issues/163> along with their
> explanations about versions of *MatchIt* and R. The package code is also
> there.
>
> Any thoughts or insights about this would really help! Thank you so much!
>
> Noah
>
> [[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] Sanitize Input Code for a Shiny App

[Bill Denney]

Hi Simon and Ivan,

Thanks for confirming my suspicions.  The most common case for our code
would be generally trusted users within an organization.  So, the main
threat is lower.  But, there may be scenarios that also allow use outside
organizations.

I think that in the end, we will likely do some minimal sanitization of the
input, but then we will also ensure that we do anything in a container with
limits applied from the outside, too.

Thanks,

Bill

On Sun, Feb 26, 2023, 4:57 PM Simon Urbanek 
wrote:

> Bill,
>
> the short answer is you can't limit anything at R level. Any attempts to
> create a list of "bad" commands are trivial to circumvent since you can
> compute on the language in R, so you can construct and call functions with
> trivial operations. Similarly, since R allows the loading of binary code
> the same applies for arbitrary code. So if you give users access to R, you
> should assume that is equivalent to allowing arbitrary code execution.
> Therefore all you can do is limit the resources and reach - as you pointed
> out using a container is a good idea so each session is only limited to a
> single container that goes away when the session ends. Similarly you can
> restrict main parts of R and the system to be read-only in the container.
>
> In practice, that's why real analytic systems are about provenance rather
> than prevention. For example, in RCloud all code is first committed to a
> git repository outside of the container before it can be executed, so
> malicious users can do whatever they want, but they cannot hide the
> malicious code they used as the container cannot manipulate the history.
>
> As for package installation - again, it's impossible to prevent it in
> general unless you make everything read-only which also prevents the users
> from doing meaningful work. So the real question what do you want to allow
> the user to do - why would you need to allow literal R code evaluation? The
> other alternative is to simply limit the interaction not allowing the user
> to submit arbitrary code, only tweak parameters or use GUI to select
> particular choices. Obviously, that is a lot easier to secure.
>
> Cheers,
> Simon
>
>
> > On 27/02/2023, at 8:36 AM, b...@denney.ws wrote:
> >
> > Hello,
> >
> >
> >
> > I'm working to develop a Shiny app where I'd like to have an advanced
> > capability to accept user input and run the code.  For the code received,
> > I'd like to be able to prevent R from doing things other than working
> within
> > the R session.  For example, I want to prevent `system("rm -rf /*")`.
> >
> >
> >
> > One method to achieve this is to run the R session within a Docker
> container
> > and perform the security around the container.  The user could do some
> > things within the container, but they would be limited.
> >
> >
> >
> > What I'd like to be able to do is to sanitize the inputs to ensure that
> it
> > won't to things including installing packages, running system commands,
> > reading and writing to the filesystem, and accessing the network.  I'd
> like
> > to allow the user to do almost anything they want within R, so making a
> list
> > of acceptable commands is not accomplishing the goal.  I could try to do
> > something like:
> >
> >
> >
> > * have acceptable packages loaded, only,
> > * don't allow loading additional packages,
> > * deny a set of known-bad commands (e.g. system, system2, etc.)
> > * deny any attempt to run from additional packages (exclude calls
> with
> > a double-colon or triple-colon)
> >
> >
> >
> > The method I just described seems like it would not work well because it
> > assumes that the known-bad commands is comprehensive and that I'm being
> > creative enough in ways that users could try to break things.
> >
> >
> >
> > Is there a good way to sanitize arbitrary code from users to prevent
> > malicious behavior?
> >
> >
> > Thanks,
> >
> >
> >
> > Bill
> >
> >
> >   [[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

[R-pkg-devel] Sanitize Input Code for a Shiny App

[bill]

Hello,

 

I'm working to develop a Shiny app where I'd like to have an advanced
capability to accept user input and run the code.  For the code received,
I'd like to be able to prevent R from doing things other than working within
the R session.  For example, I want to prevent `system("rm -rf /*")`.

 

One method to achieve this is to run the R session within a Docker container
and perform the security around the container.  The user could do some
things within the container, but they would be limited.

 

What I'd like to be able to do is to sanitize the inputs to ensure that it
won't to things including installing packages, running system commands,
reading and writing to the filesystem, and accessing the network.  I'd like
to allow the user to do almost anything they want within R, so making a list
of acceptable commands is not accomplishing the goal.  I could try to do
something like:

 

*   have acceptable packages loaded, only,
*   don't allow loading additional packages,
*   deny a set of known-bad commands (e.g. system, system2, etc.)
*   deny any attempt to run from additional packages (exclude calls with
a double-colon or triple-colon)

 

The method I just described seems like it would not work well because it
assumes that the known-bad commands is comprehensive and that I'm being
creative enough in ways that users could try to break things.

 

Is there a good way to sanitize arbitrary code from users to prevent
malicious behavior?


Thanks,

 

Bill


[[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] reproducing cran warnings

[Bill Dunlap]

checking whether package ‘epanet2toolkit’ can be installed ... WARNING
Found the following significant warnings:
  report.c:1466:37: warning: argument to ‘sizeof’ in ‘snprintf’ call is the
same expression as the destination; did you mean to provide an explicit
length? [-Wsizeof-pointer-memaccess]
  report.c:1466:61: warning: ‘__builtin___snprintf_chk’ output may be
truncated before the last format character [-Wformat-truncation=]
  rules.c:1364:40: warning: argument to ‘sizeof’ in ‘snprintf’ call is the
same expression as the destination; did you mean to provide an explicit
length? [-Wsizeof-pointer-memaccess]
  rules.c:1371:43: warning: argument to ‘sizeof’ in ‘snprintf’ call is the
same expression as the destination; did you mean to provide an explicit
length? [-Wsizeof-pointer-memaccess]
  rules.c:1371:58: warning: ‘%02d’ directive output may be truncated
writing between 2 and 11 bytes into a region of size between 0 and 6
[-Wformat-truncation=]
See
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/epanet2toolkit-00install.html
for details.


You will get these warnings if you do things like
char *string = (char*)malloc(length);
snprintf(string, sizeof(string), "format ...");
sizeof(string) here is 8 (on a 64 bit machine), no matter what length is.

Change this to either
   char string[64] // 64 had better be big enough
   snprintf(string, sizeof(string), "format ..");
or
   char *string = (char*)malloc(length);
   snprintf(string, length, "format ...");

-Bill


On Fri, Feb 3, 2023 at 8:28 AM Brad Eck  wrote:

> Dear List -
>
> What’s the latest best practice on trying to reproduce warnings raised
> on CRAN checks?
>
> I updated my epanet2toolkit package earlier this week.
> R CMD check —as-cran was clean on RHUB and Winbuilder and my local
> machines.  But on CRAN a few variations are causing warnings.
>
> For example R-devel-debian-gcc is ok on rhub
>
> https://builder.r-hub.io/status/epanet2toolkit_0.6.1.tar.gz-58c1ce1e316317307679f58450a5e17a
>
> But
> not on CRAN:
>
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/epanet2toolkit-00check.html
>
> Thanks in advance for any suggestions.
>
> Brad
>
> [[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] replacements of sprintf in compiled code

[Bill Dunlap]

Even Microsoft added snprintf to Visual C++ in 2015 (not that that matters
for R).

-Bill

On Sat, Jan 21, 2023 at 2:47 AM Duncan Murdoch 
wrote:

> On 21/01/2023 5:33 a.m., Holger Hoefling wrote:
> > Hi,
> >
> > thanks for the tip! Is that available everywhere or do I need to set
> > compiler requirements?
>
> You shouldn't need any special requirements.  I think this was
> standardized in C99, which is supported by default in R.  Not sure which
> C++ version adopted it, but it's available there too.
>
> Duncan Murdoch
>
> >
> > Best
> >
> > Holger Hoefling
> >
> > On Sat, Jan 21, 2023 at 11:27 AM Duncan Murdoch
> > mailto:murdoch.dun...@gmail.com>> wrote:
> >
> > On 21/01/2023 5:15 a.m., Holger Hoefling wrote:
> >  > Hi,
> >  >
> >  > In my recent re-submission with a bug-fix of the hdf5r package, I
> > got a new
> >  > set of warnings from the compiler, one being that I shouldn't be
> > using
> >  > 'sprintf'.
> >  >
> >  > Is there a simple replacement that I can use?
> >
> > You should use snprintf() which has an extra argument to state the
> size
> > of the buffer receiving the string.  For example,
> >
> >char text[32];
> >sprintf(text, "%.4g", value);
> >
> > could be written as
> >
> >char text[32];
> >snprintf(text, 32, "%.4g", value);
> >
> > This will write a string with at most 31 characters before the NUL at
> > the end, and avoids the possibility of a buffer overrun.
> >
> > Duncan Murdoch
> >
>
> __
> 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] corrupted NAMESPACE file

[Bill Dunlap]

Setting the locale to "C" (or perhaps some other non-UTF-8 locale) will
show the BOM bytes.  E.g., on Windows I get:

> Sys.getlocale()
[1] "LC_COLLATE=English_United States.utf8;LC_CTYPE=English_United
States.utf8;LC_MONETARY=English_United
States.utf8;LC_NUMERIC=C;LC_TIME=English_United States.utf8"
> tools::showNonASCIIfile('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
> rawToChar(readBin('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE',
what="raw", n=20))
[1] "export(AmpPhasDec"
> Sys.setlocale(locale="C")
[1] "C"
> tools::showNonASCIIfile('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
1: export(AmpPhasDecomp,
> rawToChar(readBin('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE',
what="raw", n=20))
[1] "\357\273\277export(AmpPhasDec"

-Bill


On Fri, Jan 20, 2023 at 9:16 AM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

> Hi, Ivan and Uwe:
>
>
>   Thanks for your suggestions, but I've so far been unable to get
> them
> to work.  see below.
>
>
> On 1/20/23 9:22 AM, Uwe Ligges wrote:
> >
> >
> > On 20.01.2023 15:53, Ivan Krylov wrote:
> >> В Fri, 20 Jan 2023 08:41:25 -0600
> >> Spencer Graves  пишет:
> >>
> >>> ** byte-compile and prepare package for lazy loading
> >>> Error in parse(nsFile, keep.source = FALSE, srcfile = NULL) :
> >>> 1:1: unexpected input
> >>
> >> tools::showNonASCIIfile('
> https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
> >> # 1: export(AmpPhaseDecomp,
> >>
> >> Your NAMESPACE file starts with a U+FEFF ZERO WIDTH NO-BREAK SPACE.
> >> You'll need to remove it, e.g. by re-creating the first line.
> >
> >
> > Note that this is also called "byte order mark" (BOM). Tell your editor
> > not to create files with BOM.
> >
> > You can also fix in R:
> >
> > x <- readLines(..., encoding="UTF-8-BOM")
> > writeLines(x, ..)
>
>
>   In RStudio 2022.12.0+353 (the current version),
>
>
> tools::showNonASCIIfile('
> https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
>
>
> returned "char(0)".  'readLines' and 'writeLines' as Uwe suggested
> failed to fix it for me.
>
>
>   The first problem I noticed with this was that RStudio could not
> read
> the NAMESPACE file.  When I tried, it said, "File is binary rather than
> text so cannot be opened by the source editor."  I changed something
> using a different editor and did "git commit" and "git push", and got
> the error on GitHub that I reported above.  I copied the file elsewhere,
> deleted it locally and from GitHub, then recreated it in LibreOffice by
> manually typing the first and last lines then copying the rest from a
> copy I had saved elsewhere.  The RStudio would open the file, but I
> still get the same error message as above from both "R CMD build fda"
> locally and from GitHub Action at:
>
>
> https://github.com/JamesRamsay5/fda
>
>
>   Other suggestions?
>   Thanks,
>   Spencer Graves
>
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> >
> >
>
> __
> 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] NOTE about use of `:::`

[Bill Dunlap]

You could add an 'envir' argument to parse_args() and do your eval(...,
envir=envir) stuff inside parse_args().  Then change
  call[[1]] <- quote(pense:::parse_args)
  args <- eval.parent(call)
to
   call[[1]] <- quote(parse_args)
   call$envir <- parent.frame()
   args <- eval(call)
[That code is completely untested.]

-Bill

On Wed, Dec 14, 2022 at 3:19 PM David Kepplinger 
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

Re: [R-pkg-devel] Save and restoring random number seed in a package function

[Bill Dunlap]

> Yes, set.seed() cannot accept .Random.Seed as an input; it can only take
a single integer.

If I recall correctly, S-plus's set.seed() would accept a .Random.seed
value as an input.  It did some basic validation checks on it and set it as
the current .Random.seed.  I don't recall the name of the argument.  The
format of the seed depends on the generator used - I think it used the
nature of the proffered seed to get the likely generator, but there may
have also been arguments to specify the generator explicitly.

I think this would be a nice thing to add to R's set.seed.

-Bill

On Wed, Sep 14, 2022 at 8:11 AM Noah Greifer  wrote:

> Yes, set.seed() cannot accept .Random.Seed as an input; it can only take a
> single integer. As said in this answer
> <https://stackoverflow.com/a/13997608/6348551>, there is a one-way
> relationship between set.seed() and .Random.Seed. My understanding is that
> the recommended way to restore the seed is to assign the saved seed to
> .Random.Seed in the global environment, though this is the method that is
> not allowed by the CRAN policy. Unfortunately saving it in the environment
> of the inner function is not sufficient.
>
> One potential inconsistency with CRAN's policy is that generating a random
> number itself changes the global environment by changing the value of
> .Random.Seed. The boot.array() code just does it manually using assign().
> Indeed, the boot.array() code does less damage to the global environment in
> that it resets the seed to what it would have been had boot.array() not
> been run.
>
> Noah
>
> On Wed, Sep 14, 2022 at 10:39 AM James Pustejovsky 
> wrote:
>
> > I'm interested in this question too. Noah, is there a reason you are
> using
> > assign(".Random.seed",...) rather than set.seed()?
> >
> > On Wed, Sep 14, 2022 at 9:31 AM Noah Greifer 
> > wrote:
> >
> >> Hello fellow developers,
> >>
> >> I am attempting to solve the problem of saving the state of the random
> >> generator so that the state can be recovered in a future call.
> >> Essentially,
> >> my function generates random numbers, performs an operation on them
> >> (saving
> >> the result), and throws them out (saving them would require too much
> >> memory). A second function is meant to take the output of the first
> >> function, generate the same random numbers, and perform a different
> >> operation on them.
> >>
> >> This is exactly what happens in the *boot* package: the boot() function
> >> saves the random seed (extracted from .Random.Seed), and the
> boot.array()
> >> function extracts the saved seed from the boot() output, sets the seed
> to
> >> that value, re-generates the same set of random numbers, and then
> >> re-sets the seed to what it was before boot.array() was called. This has
> >> the following benefits: 1) it allows the same random numbers to be
> drawn;
> >> 2) the random numbers don't need to be saved, which is good because they
> >> would take up a lot of memory and boot.array() is an optional function
> (it
> >> is used in boot.ci() with type = "bca" for those curious); and 3) the
> >> seed
> >> carries on from where it left off before boot.array() was called instead
> >> of
> >> being set to what it was after boot() was called.
> >>
> >> This is implemented in boot in the following way (code abbreviated):
> >>
> >> boot <- function(...) {
> >>   seed <- .Random.Seed
> >>   #Random numbers generated
> >>   out <- list(seed = seed
> >>   #Other stuff is in this list
> >>   )
> >>   out
> >> }
> >>
> >> boot.array <- function(boot.out) {
> >>   #Save current random seed in `temp`
> >>   if (exists(".Random.seed", envir = .GlobalEnv, inherits = FALSE))
> >> temp <- get(".Random.seed", envir = .GlobalEnv, inherits = FALSE)
> >>   else temp <- NULL
> >>
> >>   #Assign saved seed from boot.out
> >>   assign(".Random.seed", boot.out$seed, envir = .GlobalEnv)
> >>
> >>   #Generate same random numbers from boot() call
> >>
> >>   #Restore random seed to what it was before boot.array() call
> >>   if (!is.null(temp))
> >> assign(".Random.seed", temp, envir = .GlobalEnv)
> >>   else rm(.Random.seed, pos = 1)
> >> }
> >>
> >> This seems to work as intended. However, this violates the CRAN policy
> of
> >> chang

Re: [R-pkg-devel] Warning... unable to translate 'Ekstrm' to a wide string; Error... input string 1 is invalid

[Bill Dunlap]

Have you tried changing the \x's in that file with \u's?

> qx <- c("\xf6", "\xf8", "\xdf", "\xfc")
> Encoding(qx) <- "latin1"
> qu <- c("\uf6", "\uf8", "\udf", "\ufc")
> Encoding(qu)
[1] "UTF-8" "UTF-8" "UTF-8" "UTF-8"
> qx == qu
[1] TRUE TRUE TRUE TRUE

(charToRaw shows that qu and qx are not byte-for-byte identical: '=='
coerces the latin1 strings to utf-8.)

-Bill

On Tue, Jul 19, 2022 at 9:38 AM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

> Hi, Tomas:
>
>
> On 7/19/22 2:20 AM, Tomas Kalibera wrote:
> >
> > On 7/19/22 08:37, Spencer Graves wrote:
> >> Hello:
> >>
> >>
> >>   What's the recommended fix for "Warning in gsub(gsLi$pattern,
> >> gsLi$replacement, xo) : unable to translate 'Ekstrm' to a wide
> >> string; Error in gsub(gsLi$pattern, gsLi$replacement, xo) : input
> >> string 1 is invalid"?
> >>
> >>
> >>   This is in:
> >>
> >>
> >>
> https://github.com/sbgraves237/Ecfun/blob/master/man/subNonStandardCharacters.Rd
> >>
> >>
> >>
> >>   R-devel is now rejecting some non-ASCII characters that it
> >> previously accepted;  see below.
> >
> > Please see
> >
> https://blog.r-project.org/2022/06/27/why-to-avoid-%5Cx-in-regular-expressions
> >
> >
> > Looking at the code I guess you should change the strings in icx to use
> > \u escapes instead of \x. The use of \x as it is there was probably
> > correct when the code was ran in Latin-1 encoding, but not in other
> > encodings. Using \u would make it portable. Feel free to ask more if my
> > guess is wrong and reading the blog post doesn't help.
>
>
>   "subNonStandardCharacters.Rd" copies examples from:
>
>
> https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/iconv
>
>
>   This file still contains "\x" in 5 places.  What's the
> recommended
> fix?  Replace "\x" with "\u00" everyplace?
>
>
>   I could try that, but I don't know if I have access to platforms
> that
> would tell me if I fixed it or not ;-)
>
>
>   Thanks very much.
>   Spencer Graves
>
> >
> > Best
> > Tomas
> >
> >
> >
> >>
> >>
> >>   Thanks,
> >>   Spencer Graves
> >>
> >>
> >>  Forwarded Message 
> >> Subject: CRAN package Ecfun and its reverse dependencies
> >> Date: Wed, 13 Jul 2022 06:34:24 +0100
> >> From: Prof Brian Ripley 
> >> Reply-To: c...@r-project.org
> >> To: veronica.vincio...@brunel.ac.uk,
> >> spencer.gra...@effectivedefense.org, hamedhas...@gmail.com,
> >> dennis.pran...@gmail.com
> >> CC: c...@r-project.org
> >>
> >> Dear maintainers,
> >>
> >> This concerns the CRAN packages
> >>
> >>   BDWreg DWreg Ecdat Ecfun gk
> >>
> >> maintained by one of you:
> >>
> >>   Dennis Prangle : gk
> >>   Hamed Haselimashhadi : BDWreg
> >>   Spencer Graves : Ecfun Ecdat
> >>   Veronica Vinciotti: DWreg
> >>
> >> We have asked for an update fixing the check problems shown at
> >> <https://cran.r-project.org/web/checks/check_results_Ecfun.html>
> >> with no update from the maintainer thus far.
> >>
> >> Thus, package Ecfun is now scheduled for archival on 2022-08-08, and
> >> archiving this will necessitate also archiving its CRAN strong reverse
> >> dependencies.
> >>
> >> Please negotiate the necessary actions.
> >>
> >> The CRAN Team
> >>
> >> __
> >> 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

Re: [R-pkg-devel] What influences the size of the rdb file in a package

[Bill Dunlap]

The byte code attached to each function in a package can be surprisingly
large.  E.g., the byte code for the c. 300 line function Matrix:::replTmat
seems to be c. 4.5 times the size of the raw code:

> object.size(Matrix:::replTmat) /
object.size(as.function(as.list(Matrix:::replTmat)))
5.5 bytes

[Is there a more direct way to remove byte code from a function?  Or to
inspect it?]

Building Matrix with --no-byte-compile reduces the size of R/Matrix.rdx by
more than half, from 2.7 MB to 1 MB.

-Bill

On Sat, Oct 30, 2021 at 12:00 AM Mosqueira Sanchez, Iago <
iago.mosque...@wur.nl> wrote:

> As far as I can see only classes, methods and functions are present
> there. I loaded the rdb file and looked at the contents and sizes of
> objects.
>
> Am I right in assuming every method or function imported from another
> package sits in the database? In another S4 package I see that the
> largest objects are nls, cor and lm, which we overload for some S4
> classes.
>
>
>
> Iago
>
> On Fri, 2021-10-29 at 20:21 -0400, Duncan Murdoch wrote:
> > On 29/10/2021 4:23 p.m., Gábor Csárdi wrote:
> > > You probably (accidentally?) put some large object into your
> > > package,
> > > e.g. a non-function object. But it is hard to say more without
> > > seeing
> > > the actual code
> >
> > Yes.  To track it down, you need to understand that an INSTALL
> > executes
> > everything in the .R files, and saves every object that was created.
> > In
> > a simple package, that's just a bunch of functions, but in more
> > complicated situations, you may have created some objects in order
> > to
> > build functions, even though you don't need them:  but unless you
> > remove
> > them, it's very easy to have them included too.
> >
> > Duncan Murdoch
> > > Gabor
> > >
> > > On Fri, Oct 29, 2021 at 10:07 PM Mosqueira Sanchez, Iago
> > >  wrote:
> > > >
> > > > I am getting warnings in some packages about the size of the R
> > > > folder
> > > >
> > > > * checking installed package size ... NOTE
> > > >installed size is 20.5Mb
> > > >sub-directories of 1Mb or more:
> > > >  data   2.4Mb
> > > >  R 17.8Mb
> > > >
> > > > This package contains around 3300 lines of code, if the results
> > > > of
> > > >
> > > > grep -v '^\s*#' *.R | wc
> > > >
> > > > are correct.
> > > >
> > > > Is this size to be expected? Is there anything I might be
> > > > missinmg to
> > > > make it smaller?
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > Iago
> > > > --
> > > > dr. Iago Mosqueira
> > > >
> > > > Wageningen Marine Research
> > > >
> > > > Haringkade 1
> > > > Postbus 68
> > > > 1976CP, IJmuiden
> > > >
> > > > Tel.: +31 (0)317 488 995
> > > > iago.mosque...@wur.nl
> > > > __
> > > > R-package-devel@r-project.org mailing list
> > > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=04%7C01%7Ciago.mosqueira%40wur.nl%7Cab72634b9fed43fd7a2208d99b3b43cd%7C27d137e5761f4dc1af88d26430abb18f%7C0%7C0%7C637711501535857883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=E9aOOkVzR46TP2lah4alc%2F%2B5PmFPX27oDV140kBcrEI%3D&reserved=0
> > >
> > > __
> > > R-package-devel@r-project.org mailing list
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=04%7C01%7Ciago.mosqueira%40wur.nl%7Cab72634b9fed43fd7a2208d99b3b43cd%7C27d137e5761f4dc1af88d26430abb18f%7C0%7C0%7C637711501535867885%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ZMc2qL9zGn9u5Tcf8nRNNffZlkMZVbXvdW3pVgrrI0E%3D&reserved=0
> > >
> __
> 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] Internet resources and Errors

[Bill Dunlap]

Can you tell if the failure to download was due to a Solaris-specific issue
or due to the Solaris test machine not being fully connected to the
internet?

-Bill

On Fri, Sep 24, 2021 at 7:50 AM Roy Mendelssohn - NOAA Federal via
R-package-devel  wrote:

> Hi All:
>
> I am getting dinged again on CRAN  (just Solaris for some reason),  and
> the problem is how to exit if there is a failure of accessing the
> resource,  I know it has been discussed here before,  but I just am not
> understanding what is desired to end properly. As I have been reminded:
>
> 'Packages which use Internet resources should fail gracefully with an
> informative message
> if the resource is not available or has changed (and not give a check
> warning nor error).'
>
> All internet calls are wrapped in 'try()'.  If that shows an error,  I
> write a message to the screen about the error,  and call stop(), perhaps
> with a further message in that call.   Somehow this does not appear to meet
> the standard.Can someone then please tell me what I should do instead.
> The point is I have checked that the access to the internet resources has
> worked,  i have seen that it hasn't,  now what should be the steps to take
> to exit gracefully.
>
> I also want to add to what others have said about the frustrations of
> dealing with Solaris.  I have spent a fair amount of time getting things
> to  work with Solaris which no one uses.  In this instance the package test
> is only failing on Solaris.   Not a good use of limited time IMO.
>
> Thanks for any advice.
>
> -Roy
>
>
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
> __
> 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] Unicode Name Warnings for Package Constant

[bill]

Hello,

 

In the janitor package, we want to optionally support conversion from
Unicode characters that visually map to mu or micro to the character "u".
For that, we were thinking to create an unexported character vector constant
with names of all the Unicode mu/micro characters and values of "u".  As a
work-around, I was able to fix the issue using setNames(), but it was a
non-intuitive fix, and I would prefer to just use create the named character
vector directly.

 

Is there a good way to prevent the warnings below?

 

When running the following (on Windows 10 with R 4.1.0) either during a
normal R session or while checking the package (via devtools::check()), we
get several warnings:

 

mu_to_u <-

  c(

"\u00b5"="u", "\u03bc"="u", "\u3382"="u", "\u338c"="u", "\u338d"="u",

"\u3395"="u", "\u339b"="u", "\u33b2"="u", "\u33b6"="u", "\u33bc"="u"

  )

 

  Warnings in file 'R/clean_names.R':

unable to translate '' to native encoding

unable to translate '' to native encoding

unable to translate '' to native encoding

unable to translate '' to native encoding

unable to translate '' to native encoding

unable to translate '' to native encoding

unable to translate '' to native encoding

unable to translate '' to native encoding

 

I tried wrapping this in suppressWarnings(), but the warnings still
occurred.

 

Thanks,

 

Bill


[[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] can't reproduce 'Additional issues' on CRAN with valgrind

[Bill Dunlap]

I think the following change to str.c, in str_strcpy_internal(), fixes the
valgrind issues.  It was easier to track down after the calloc() was
changed to malloc(), since before it only happened after a realloc().
 $ diff -u rbibutils/src/str.c rbibutils-fixed/src/str.c
--- rbibutils/src/str.c 2021-06-16 04:13:48.0 -0700
+++ rbibutils-fixed/src/str.c   2021-08-06 18:38:56.763556500 -0700
@@ -217,8 +217,8 @@
unsigned long size = str_initlen;
assert( s );
if ( minsize > str_initlen ) size = minsize;
-   // 2021-06-16 was: s->data = (char *) malloc( sizeof( *(s->data) )
* size );
-   // changing to calloc() to avoid this kind of error from
valgrind:
+   s->data = (char *) malloc( sizeof( *(s->data) ) * size );
+   // tried changing to calloc() to avoid this kind of error from
valgrind:
 //  > bibConvert(fn_med, bib, informat = "med")
 //  ==16041== Conditional jump or move depends on
uninitialised value(s)
 //  ==16041==at 0x10CCF2A3: xml_processtag (xml.c:174)
@@ -249,8 +249,9 @@
//
// TODO:
//The data is not really left uninitialised and there may be a
better way to let the compiler know.
+// WWD: fixing str_strcpy_internal takes care of memory misuse.
//
-   s->data = (char *) calloc( size, sizeof( *(s->data) ) );
+   // s->data = (char *) calloc( size, sizeof( *(s->data) ) );
if ( !s->data ) {
  error("Error.  Cannot allocate memory in str_initalloc, requested
%lu characters.\n\n", size );
  // error("\n"); // error( EXIT_FAILURE );
@@ -552,9 +553,9 @@
// Georgi: this fixes the warning about truncation in strncpy
//   strcpy cannot be used here since at least one of the calls
below
//   passes a non-NULL terminated 'p'
-   strncpy( s->data, p, n + 1);
-   // strncpy( s->data, p, n );
-   // s->data[n] = '\0';
+   // strncpy( s->data, p, n + 1); // WWD: ???
+   strncpy( s->data, p, n );
+   s->data[n] = '\0';
s->len = n;
 }

I don't know why valgrind isn't working for you.

-Bill

On Mon, Aug 2, 2021 at 4:23 PM Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:

> Thanks for looking into this. I probably didn’t make it clear that I am
> not questioning the errors on CRAN but my own configuration. I have pretty
> good idea where the error comes from, since the only change from the
> previous CRAN version was in medin.c (function medin_readf from line 94 and
> most probably line 144-145). I think also that all errors have medin.c on
> the trace.
>
>
>
> It would be very helpful if somebody can spot from the description of my
> configuration in the original email where I have gone wrong in the setup of
> R with valgrind.
>
>
>
> >realloc() does not initialize memory.  str.c contains a comment about
> replacing malloc() with calloc() to avoid…
>
>
>
> //The data is not really left uninitialised and there may
> be a better way to let the compiler know.
>
> //
>
> s->data = (char *) calloc( size, sizeof( *(s->data) ) );
>
> if ( !s->data ) {
>
>   error("Error.  Cannot allocate memory in str_initalloc,
> requested %lu characters.\n\n", size );
>
>   // error("\n"); // error( EXIT_FAILURE );
>
> }
>
> s->data[0]='\0';
>
> s->dim=size;
>
> s->len=0;
>
>
>
> My comment is indeed sloppy but the first byte is initialised to zero and
> the rest is used for writing only
>
> (valgrind has no way to know, of course, and it is fair to question how a
> human can possibly be sure).
>
>
>
>
>
> Thanks again,
>
> Georgi Boshnakov
>
>
>
>
>
> *From:* Bill Dunlap 
> *Sent:* 02 August 2021 19:48
> *To:* Georgi Boshnakov 
> *Cc:* r-package-devel@r-project.org
> *Subject:* Re: [R-pkg-devel] can't reproduce 'Additional issues' on CRAN
> with valgrind
>
>
>
> I ran the tests of rbibutils-2.2.2, using the latest devel version of R
> configured to use valgrind, with
>
>
>
> R --debugger=valgrind --debugger-args=--track-origins=yes --quiet -e
> 'testthat::test_package("rbibutils")'
>
>
>
> I saw a lot of 'conditional jump depends on uninitialized value' errors:
>
>
>
> ==27280== Conditional jump or move depends on uninitialised value(s)
> ==27280==at 0x11C420B7: UnknownInlinedFun (xml.c:178)
> ==27280==by 0x11C420B7: xml_parse (xml.c:241)
> ==27280==by 0x11C514EF: medin_processf (

Re: [R-pkg-devel] can't reproduce 'Additional issues' on CRAN with valgrind

[Bill Dunlap]

I ran the tests of rbibutils-2.2.2, using the latest devel version of R
configured to use valgrind, with

R --debugger=valgrind --debugger-args=--track-origins=yes --quiet -e
'testthat::test_package("rbibutils")'

I saw a lot of 'conditional jump depends on uninitialized value' errors:

==27280== Conditional jump or move depends on uninitialised value(s)
==27280==at 0x11C420B7: UnknownInlinedFun (xml.c:178)
==27280==by 0x11C420B7: xml_parse (xml.c:241)
==27280==by 0x11C514EF: medin_processf (medin.c:683)
==27280==by 0x11C67ADE: UnknownInlinedFun (bibcore.c:479)
==27280==by 0x11C67ADE: bibl_read.part.0 (bibcore.c:862)
==27280==by 0x11C68C66: bibprog (bibprog.c:36)
==27280==by 0x11C69327: any2xml_main (any2xml.c:127)
==27280==by 0x307639: do_dotCode (dotcode.c:1814)
==27280==by 0x2B4600: bcEval.lto_priv.0 (eval.c:7128)
==27280==by 0x2DADB7: Rf_eval (eval.c:740)
==27280==by 0x2DD28E: R_execClosure.lto_priv.0 (eval.c:1910)
==27280==by 0x2DE1EC: Rf_applyClosure (eval.c:1836)
==27280==by 0x2DAFD3: Rf_eval (eval.c:863)
==27280==by 0x2D7F22: do_begin (eval.c:2530)
==27280==  Uninitialised value was created by a heap allocation
==27280==at 0x483DFAF: realloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==27280==by 0x11C38DB2: str_realloc.part.0 (str.c:90)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:85)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:543)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:551)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:547)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:607)
==27280==by 0x11C3B63D: str_segcpy (str.c:585)
==27280==by 0x11C4DDFA: medin_readf (medin.c:144)
==27280==by 0x11C67A96: UnknownInlinedFun (bibcore.c:471)
==27280==by 0x11C67A96: bibl_read.part.0 (bibcore.c:862)
==27280==by 0x11C68C66: bibprog (bibprog.c:36)
==27280==by 0x11C69327: any2xml_main (any2xml.c:127)
==27280==by 0x307639: do_dotCode (dotcode.c:1814)

realloc() does not initialize memory.  str.c contains a comment about
replacing malloc() with calloc() to avoid similar problems that valgrind
found.  It states that valgrind is mistaken, that that memory really is
initialized.  Hmm.

I also see the error about reading off the end of a malloc'ed array:

==27280== Invalid read of size 1
==27280==at 0x11C420A8: UnknownInlinedFun (xml.c:174)
==27280==by 0x11C420A8: xml_parse (xml.c:241)
==27280==by 0x11C514EF: medin_processf (medin.c:683)
==27280==by 0x11C67ADE: UnknownInlinedFun (bibcore.c:479)
==27280==by 0x11C67ADE: bibl_read.part.0 (bibcore.c:862)
==27280==by 0x11C68C66: bibprog (bibprog.c:36)
==27280==by 0x11C69327: any2xml_main (any2xml.c:127)
==27280==by 0x307639: do_dotCode (dotcode.c:1814)
==27280==by 0x2B4600: bcEval.lto_priv.0 (eval.c:7128)
==27280==by 0x2DADB7: Rf_eval (eval.c:740)
==27280==by 0x2DD28E: R_execClosure.lto_priv.0 (eval.c:1910)
==27280==by 0x2DE1EC: Rf_applyClosure (eval.c:1836)
==27280==by 0x2DAFD3: Rf_eval (eval.c:863)
==27280==by 0x2D7F22: do_begin (eval.c:2530)
==27280==  Address 0x125028af is 0 bytes after a block of size 10,927
alloc'd
==27280==at 0x483DD99: calloc (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==27280==by 0x11C38DF2: str_initalloc (str.c:253)
==27280==by 0x11C3B66A: UnknownInlinedFun (str.c:541)
==27280==by 0x11C3B66A: UnknownInlinedFun (str.c:551)
==27280==by 0x11C3B66A: UnknownInlinedFun (str.c:547)
==27280==by 0x11C3B66A: UnknownInlinedFun (str.c:607)
==27280==by 0x11C3B66A: str_segcpy (str.c:585)
==27280==by 0x11C4DDFA: medin_readf (medin.c:144)


On Mon, Aug 2, 2021 at 10:11 AM Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:

> An update to my package rbibutils triggered 'Additional issues' on CRAN
> from valgrind, CRAN Package Check Results for Package rbibutils (
> r-project.org)<
> https://cran.r-project.org/web/checks/check_results_rbibutils.html>.
>
> However, running the checks with -use-valgrind  on my machine gives zero
> errors.
> I am on Ubuntu (the latest stable version), my R-devel installation was
> updated earlier today and I rebuild it adding the
> --with-valgrind-instrumentation=2 to the call to configure.
> Valgrind coming with Ubuntu is 3.5.0, so I installed its latest version
> from  github (also no errors).
>
> rbibutils has no dependencies, except that testthat is used for testing.
>
> What am I missing? Do I need to have a separate library for the
> instrumented R-devel version?
>
> As a side note, is there a way to find out if R has been built with
> valgrind? It seems that 'capabilities()' and 'R CMD config' do not offer
> this information.
>
> Thanks,
> Georgi Boshnakov
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-p

Re: [R-pkg-devel] Tracking down inconsistent errors and notes across operating systems

[Bill Dunlap]

I think the problem with RPostgreSQL/sec/RS-DBI.c comes from some changes
to Defn.h and Rinternals.h in RHOME/include that Luke made recently
(2021-07-20, svn 80647).  Since then the line
   #define s_object SEXPREC
in Rdefines.h causes problems.  Should it now be 'struct SEXPREC'?

-Bill


On Thu, Jul 22, 2021 at 7:04 AM Iñaki Ucar  wrote:

> Hi,
>
> On Thu, 22 Jul 2021 at 15:51, Hannah Owens  wrote:
> >
> > Hi all,
> > I am working on an update to a package I have on CRAN called occCite. My
> > latest release attempt didn’t pass incoming automated checks, because
> there
> > is an outstanding error. Additionally, there are some weird notes I would
> > like to get rid of, if anyone has suggestions.
> >
> > The killing error is in r-devel-linux-x86_64-debian-gcc, which is:
> Packages
> > required but not available: 'BIEN', 'taxize', ‘RPostgreSQL'
> >
> > I don’t understand this, as it is the only system that throws this error,
> > and the packages mentioned are available via CRAN. Any suggestions?
>
> This kind of message usually arises when there is some problem with
> those packages on CRAN. Indeed,
>
> https://cran.r-project.org/web/checks/check_results_BIEN.html
> https://cran.r-project.org/web/checks/check_results_taxize.html
> https://cran.r-project.org/web/checks/check_results_RPostgreSQL.html
>
> the three of them have ERRORs in that platform. No issue on your end.
> You reply pointing to that.
>
> > Additionally, there are multiple platforms
> > (r-devel-linux-x86_64-fedora-clang; r-devel-linux-x86_64-fedora-gcc;
> > r-devel-windows-x86_64-gcc10-UCRT; r-patched-solaris-x86;
> > r-release-macos-arm64; r-release-macos-x86_64; r-oldrel-macos-x86_64)
> where
> > two notes pop up:
> >
> > NOTE 1: Namespace in Imports field not imported from: ‘bit64’ All
> declared
> > Imports should be used.
> >
> > The package does use bit64. Any tips on how to address this note?
>
> Are you sure? Your NAMESPACE file does not import(bit64) nor
> importFrom(bit64,) anything.
>
> > NOTE 2: Found 6 marked UTF-8 strings.
> >
> > I presume this is thrown because of the small sample dataset I’ve
> included
> > in the package, but why is it not thrown for all the platforms?
>
> Not all the checks are necessarily done in all the platforms. You can
> silence this NOTE by converting the offending strings in your datasets
> to ASCII and resaving them.
>
> --
> Iñaki Úcar
>
> __
> 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] weird C stack traces from win-builder, due to brms/rstan load?

[Bill Dunlap]

I think the stack trace is omitting the initial underscore in the symbol
name:

> c++filt
_ZN4Rcpp8CppClassC1EPNS_6ModuleEPNS_10class_BaseERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
Rcpp::CppClass::CppClass(Rcpp::Module*, Rcpp::class_Base*,
std::__cxx11::basic_string,
std::allocator >&)

-Bill

On Mon, Jul 5, 2021 at 11:01 AM Duncan Murdoch 
wrote:

> On 05/07/2021 10:32 a.m., Ben Bolker wrote:
> >I'm running into trouble checking a new release of the 'broom.mixed'
> > package <https://cran.r-project.org/web/packages/broom.mixed/index.html>
> > on win-builder.  I think it is some kind of rstan problem.
> >
> > The broom.mixed package loads the brms package, and loads several
> > pre-computed objects from the brms package; I don't think it actually
> > tries to run anything of the functions from brms during the check
> process.
> >
> > At several points during checking (see
> > <https://win-builder.r-project.org/LsDDMqpnX52n/00check.log>), I get
> > voluminous "C stack trace" outputs: once when "Checking dependencies in
> > R code", once when calling require(brms) as part of an example, once
> > when running the tests (not easy to determine the precise location, and
> > once when building the vignettes).
> >
> > The trace starts like this:
> >
> >  C stack trace ===
> >
> >   SETCAR [0x0x6c838a90+32]
> >
>  
> ZN4Rcpp8CppClassC1EPNS_6ModuleEPNS_10class_BaseERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
> [0x0x6ac093ff+1151]
> >   ZN4Rcpp6Module12classes_infoEv [0x0x6ac07467+327]
> >   Z20Module__classes_infoP7SEXPREC [0x0x6abe1c4a+74]
> >   Rf_NewFrameConfirm [0x0x6c7a7d18+33960]
> >   R_initAssignSymbols [0x0x6c7f3259+53849]
> >   Rf_eval [0x0x6c7fcd31+369]
> > ...
> >
> > and goes on for a while.
> >
> > R CMD check runs fine on Linux with recent r-devel.
> >
> > Has anyone seen this?  Other than scrubbing all references to brms
> > and rstan (a second try with one of the brms references avoided instead
> > runs into trouble when loading rstan ...), I don't see what I can do ...
> >
> > <https://win-builder.r-project.org/YArr24tuYZ8G/00check.log>
> >
>
> What error do you get before the stack trace?
>
> The Z... names look like C++ entry points to overloaded functions or
> methods.  There's a command line function (c++filt) that will usually
> turn those into their original readable form.  It's not working for me
> on the names you've got; maybe because I'm on a Mac, and that was
> compiled on Windows.  Perhaps someone else knows how to demangle those
> names?
>
> Duncan Murdoch
>
> __
> 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] [Error] data length differs from size of matrix

[Bill Dunlap]

solve_svd's second argument is 'tolerance', a small scalar value, not the
right hand side of X %*% beta == Y.  It returns the [approximate] inverse
of X, not beta.

solve_svd(cor.x2,cor.y) should probably be solve_svd(cor.x2)%*%cor.y (or
just solve(cor.x2,cor.y)).

-Bill

On Fri, Jun 4, 2021 at 8:41 AM Bill Dunlap  wrote:

> The offending line in path_coeff seems to be
>betas[i, 2:nvar] <- t(solve_svd(cor.x2, cor.y))
> where i is a single integer, nvar is 15, and the right hand side is a 14
> by 14 matrix.  What is this line trying to do?  Did it ever give the
> correct result?
>
> -Bill
>
>
> On Fri, Jun 4, 2021 at 7:39 AM Bill Dunlap 
> wrote:
>
>> That log file includes the line
>> using R Under development (unstable) (2021-05-30 r80413)
>> and later says
>>
>> The error most likely occurred in:
>>
>> > ### Name: path_coeff
>> > ### Title: Path coefficients with minimal multicollinearity
>> > ### Aliases: path_coeff path_coeff_mat
>> >
>> > ### ** Examples
>> >
>> > ## No test:
>> > library(metan)
>> >
>> > # Using KW as the response variable and all other ones as predictors
>> > pcoeff <- path_coeff(data_ge2, resp = KW)
>> Error in matrix(value, n, p) :
>>   data length differs from size of matrix: [196 != 1 x 14]
>> Calls: path_coeff -> [<- -> [<-.data.frame -> matrix
>> Execution halted
>>
>> In the current R-devel the matrix command matrix(value, nrow, ncol) 
>> complains if length(value)>nrow*ncol, so you need to truncate 'value'.  
>> (Previously matrix() would silently truncate value.)
>>
>>
>> -Bill
>>
>>
>> On Thu, Jun 3, 2021 at 5:57 PM Tiago Olivoto 
>> wrote:
>>
>>> Dear all,
>>> I have received an email from the CRAN team to fix a problem with my R
>>> package metan <https://CRAN.R-project.org/package=metan
>>> <https://cran.r-project.org/package=metan>> to safely retain it on CRAN.
>>>
>>> The error is given at <
>>> https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
>>> and seems to be related to data different from size of matrix.
>>>
>>> The question is that and I cannot reproduce the error locally and thus
>>> not
>>> able to fix anything. By googling the error I've seen similar issues
>>> with a
>>> lot of other packages. Could be this be a temporary issue?
>>>
>>> Thanks in advance!
>>> Tiago
>>>
>>> [[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] [Error] data length differs from size of matrix

[Bill Dunlap]

The offending line in path_coeff seems to be
   betas[i, 2:nvar] <- t(solve_svd(cor.x2, cor.y))
where i is a single integer, nvar is 15, and the right hand side is a 14 by
14 matrix.  What is this line trying to do?  Did it ever give the correct
result?

-Bill


On Fri, Jun 4, 2021 at 7:39 AM Bill Dunlap  wrote:

> That log file includes the line
> using R Under development (unstable) (2021-05-30 r80413)
> and later says
>
> The error most likely occurred in:
>
> > ### Name: path_coeff
> > ### Title: Path coefficients with minimal multicollinearity
> > ### Aliases: path_coeff path_coeff_mat
> >
> > ### ** Examples
> >
> > ## No test:
> > library(metan)
> >
> > # Using KW as the response variable and all other ones as predictors
> > pcoeff <- path_coeff(data_ge2, resp = KW)
> Error in matrix(value, n, p) :
>   data length differs from size of matrix: [196 != 1 x 14]
> Calls: path_coeff -> [<- -> [<-.data.frame -> matrix
> Execution halted
>
> In the current R-devel the matrix command matrix(value, nrow, ncol) complains 
> if length(value)>nrow*ncol, so you need to truncate 'value'.  (Previously 
> matrix() would silently truncate value.)
>
>
> -Bill
>
>
> On Thu, Jun 3, 2021 at 5:57 PM Tiago Olivoto 
> wrote:
>
>> Dear all,
>> I have received an email from the CRAN team to fix a problem with my R
>> package metan <https://CRAN.R-project.org/package=metan
>> <https://cran.r-project.org/package=metan>> to safely retain it on CRAN.
>>
>> The error is given at <
>> https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
>> and seems to be related to data different from size of matrix.
>>
>> The question is that and I cannot reproduce the error locally and thus not
>> able to fix anything. By googling the error I've seen similar issues with
>> a
>> lot of other packages. Could be this be a temporary issue?
>>
>> Thanks in advance!
>> Tiago
>>
>> [[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] [Error] data length differs from size of matrix

[Bill Dunlap]

That log file includes the line
using R Under development (unstable) (2021-05-30 r80413)
and later says

The error most likely occurred in:

> ### Name: path_coeff
> ### Title: Path coefficients with minimal multicollinearity
> ### Aliases: path_coeff path_coeff_mat
>
> ### ** Examples
>
> ## No test:
> library(metan)
>
> # Using KW as the response variable and all other ones as predictors
> pcoeff <- path_coeff(data_ge2, resp = KW)
Error in matrix(value, n, p) :
  data length differs from size of matrix: [196 != 1 x 14]
Calls: path_coeff -> [<- -> [<-.data.frame -> matrix
Execution halted

In the current R-devel the matrix command matrix(value, nrow, ncol)
complains if length(value)>nrow*ncol, so you need to truncate 'value'.
(Previously matrix() would silently truncate value.)


-Bill


On Thu, Jun 3, 2021 at 5:57 PM Tiago Olivoto  wrote:

> Dear all,
> I have received an email from the CRAN team to fix a problem with my R
> package metan <https://CRAN.R-project.org/package=metan
> <https://cran.r-project.org/package=metan>> to safely retain it on CRAN.
>
> The error is given at <
> https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
> and seems to be related to data different from size of matrix.
>
> The question is that and I cannot reproduce the error locally and thus not
> able to fix anything. By googling the error I've seen similar issues with a
> lot of other packages. Could be this be a temporary issue?
>
> Thanks in advance!
> Tiago
>
> [[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 vignettes

[Bill Dunlap]

cli does export col_red - did you omit the 'r' when calling it from your
package or vignette?

On Thu, Apr 29, 2021 at 9:29 AM Danielle Maeser  wrote:

> Hi Duncan,
>
> I really appreciate your response. Unfortunately, I am still receiving the
> error below.
>
> If anyone has ideas, I'd appreciate it!
>
> This is the only online forum I can find that discusses the error, but I
> have not found it helpful: https://github.com/r-lib/cli/issues/94
>
>
>
>
> *   ERROR: package installation failedError: 'col_ed' is not an exported
> object from 'namespace:cli'Execution halted*
>
> On Wed, Apr 28, 2021 at 7:32 PM Duncan Murdoch 
> wrote:
>
> > On 28/04/2021 4:41 p.m., Danielle Maeser wrote:
> > > Hi Duncan,
> > >
> > > Thank you for your feedback!
> > >
> > > Unfortunately, when I made the changes recommended I have a new error:
> > >
> > > *trying to use CRAN without setting a mirror
> >
> > That would be a result of your code.  Do you call install.packages() in
> > one of your functions?  Normally you shouldn't do that.
> >
> > > *
> > >
> > > And:
> > > *Error: 'col_ed' is not an exported object from 'namespace:cli'*
> >
> > Similarly, something in your code or NAMESPACE file.  Do you refer to
> > cli::col_ed, or try to import col_ed from cli?
> >
> > > *
> > > *
> > > My description file includes:
> > > *VignetteBuilder: knitr
> > > Depends: R (>= 4.0), knitr
> > > License: GPL-2
> > > Encoding: UTF-8
> > > Roxygen: list(rmarkdown = TRUE)
> > > RoxygenNote: 7.1.1
> > > LazyData: true
> >
> > Do you really have a data subdir in your package? You shouldn't have the
> > LazyData line without one.
> >
> > > Suggests: knitr, rmarkdown*
> >
> > You shouldn't list knitr in both Depends and Suggests.
> >
> > Duncan Murdoch
> >
> > > *
> > > *
> > > And my vignette includes:
> > > *title: "title"
> > > author: "name"
> > > output: rmarkdown::html_vignette
> > > vignette: >
> > >%\VignetteIndexEntry{title}
> > >%\VignetteEngine{knitr::rmarkdown}
> > >%\VignetteEncoding{UTF-8}*
> > > *
> > > *
> > > I'd appreciate any advice!
> > >
> > > Danielle
> > >
> > > On Wed, Apr 28, 2021 at 2:27 PM Duncan Murdoch <
> murdoch.dun...@gmail.com
> > > > wrote:
> > >
> > > On 28/04/2021 2:44 p.m., Danielle Maeser wrote:
> > >  > Hello,
> > >  >
> > >  > I am doing a R CMD check on an R package I have developed.
> > > However, I keep
> > >  > receiving the warning below:
> > >  >
> > >  > *Files in the 'vignettes' directory but no files in 'inst/doc':*
> > >  >
> > >  > And
> > >  >
> > >  > *Files named as vignettes but with no recognized vignette
> engine:*
> > >  >
> > >  > I am pretty sure I have the correct YAML header for my
> vignettes,
> > > and also
> > >  > inst/docs is an older convention for vignettes that's no longer
> > >  > recommended.
> > >  >
> > >  > Do you have an idea of what's going wrong? I have attached my
> > > YAML header
> > >  > below as reference.
> > >
> > > You may be missing the line
> > >
> > > VignetteBuilder: knitr
> > >
> > > in your DESCRIPTION file.  Without that, R won't know how to
> > interpret
> > > your vignette.
> > >
> > > It's also a little unusual to use
> > >
> > > %\VignetteEngine{knitr::markdown}
> > >
> > > nowadays; the more common engine is knitr::rmarkdown (but I believe
> > > both
> > > are still supported).  If you make this change you should also have
> > >
> > > rmarkdown::html_vignette
> > >
> > > as the output format.
> > >
> > > Finally, since a recent update of knitr, you need to make sure that
> > > package holding the output format (i.e. markdown currently,
> > > rmarkdown if
> > > you make the change above) is declared as a Suggested package in
> your
> > > DESCRIPTION file.
> > >
> > > Duncan Murdoch
> > >
> > >  >
> > >  > Sincerely,
> > >  > Danielle
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > *title: "title of this vignette"author: "name"output:
> > >  > markdown::html_vignettevignette: >
> %\VignetteIndexEntry{vignette
> > > title}
> > >  > %\VignetteEngine{knitr::markdown}  %\VignetteEncoding{UTF-8}*
> > >  >
> > >
> > >
> > >
> > > --
> > > Ph.D. Student
> > > Bioinformatics and Computational Biology
> > > University of Minnesota
> > >
> >
> >
>
> --
> Ph.D. Student
> Bioinformatics and Computational Biology
> University of Minnesota
>
> [[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] Using ggplot2 within another package

[Bill Dunlap]

Has there been any thought given to an alternative to globalVariables that
would flag certain arguments to certain functions as being evaluated in a
non-standard way.  E.g.,
usesNSE(FUN="with.default", ARGUMENTS="expr")
usesNSE(FUN="lm", ARGUMENTS=c("weights","subset","offset"))
usesNSE(FUN="~") # missing ARGUMENTS means all args are NSE
This information would be stored in the environment that contains FUN.

-Bill

On Sat, Apr 24, 2021 at 6:18 AM Martin Maechler 
wrote:

> >>>>> Ben Bolker
> >>>>> on Thu, 22 Apr 2021 17:27:49 -0400 writes:
>
> > For some reason that I don't remember, an R core member once told me
> > that they prefer x <- y <- NULL to
> utils::globalVariables(c("x","y")) -
>
> That could have been me.  Even though I think I still have some
> globalVariables() statements in some of my package sources, I've
> decided that it *harms* really, notably for relatively common variable
> names such
> as "x":   It declares them "global"
> { for the purpose of codetools::globalVariables() } everywhere,
> i.e. for all functions in the package namespace and that
> basically kills the reliability of  globalVariables() checking
> for the whole package.
>
>
> > although I have also encountered problems with that strategy in edge
> cases.
>
> well, when?
>
> > Here's an example from StackOverflow from today where for some
> reason
> > I don't understand, evaluation of function arguments interacts with
> > non-standard/lazy evaluation within a dplyr function such that 'foo'
> > works while 'x$foo' doesn't ... don't know if it's a similar case.
>
> >
> https://stackoverflow.com/questions/67218258/getting-error-error-in-usemethodfilter-no-applicable-method-for-filter/67220198#67220198
>
>
> { ceterum censeo ... to use NSE (non-standard-evaluation) for
>   user convenience and to call this (together with really good
>   ideas)  "tidy" has been one of the biggest euphemisms in the history of
>   statistical computing ...  but yes, that's just my personal opinon  }
>
> > On 4/22/21 5:19 PM, Kevin R. Coombes wrote:
> >> Thanks.
> >>
> >> Obviously, long. long ago, (in a galaxy not far enough away), Paul's
> >> suggestion of using "aes_string" was the correct one, since "aes"
> uses
> >> non-standard evaluation. (And to quote somebody from an R fortune
> >> cookie, "The problem with non-standard evaluation is that it is
> >> non-standard.") But teh documentation at the end oft he link
> provided by
> >> Robert explivityl tells you not to do that, since "aes_string is
> >> deprecated".  And reading more carefully into the manual page for
> >> aes_string, one does indeed find the statement that the function is
> >> "soft deprecated". I'm not sure what that means, other than someone
> on
> >> the development team doesn't like it.
> >>
> >> Instead, the vignette says you should
> >>importFrom("rlang", ".data")
> >> in your NAMESPACE, and write
> >>ggplot(myData, aes(x = .data$myX, y = .data$myY))
> >>
> >> And now my dinosaur question: That looks like using one non-standard
> >> hack to cover up the problems with another non-standard hack. Why
> the
> >> heck  is that any better for the developer than writing
> >>ggplot(myData, aes(x = myData$myX, y = myData$myY))
> >>
> >> or using Dirk Eddelbuettel's suggestion of calling
> utils::globalVariables ??
> >>
> >> It's time to tell those kids to get off of my lawn.
> >>   Kevin
> >>
> >> On 4/22/2021 4:45 PM, Robert M. Flight wrote:
> >>> Kevin,
> >>>
> >>> This vignette from ggplot2 itself gives the "officially
> recommended"
> >>> ways to avoid the warnings from R CMD check
> >>>
> >>> https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html
> >>> <https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html>
> >>>
> >>> Cheers,
> >>>
> >>> -Robert
> >>>
> >>> On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
> >>> mailto

Re: [R-pkg-devel] Error on Solaris 10 'memory not mapped'

[Bill Dunlap]

Have you run the offending examples under valgrind on Linux with
gctorture(TRUE)?

-Bill

On Thu, Apr 1, 2021 at 11:51 AM Zhang, Wan  wrote:
>
> Hello,
>
> In our package “BET” version 0.3.4 published on 2021-03-21, there is a 
> “memory not mapped” error on Solaris 10.
>
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/BET-00check.html
>
> I tried to replicate this error with R-hub but it works well. What can I do 
> to simulate CRAN’s environment in S 10 and fix this problem?
>
> Any help from you will be highly appreciated!
>
> Best,
> Wan
>
> [[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] rcmdcheck reports wrong version of lattice

[Bill Dunlap]

I haven't followed all the code branches in tools:::.check_packages(),
but some of them use --vanilla when running the R subprocess that does
the checking.  I think that would mean that libraries in ~/R would not
be in the search path.

-BIll

On Mon, Mar 8, 2021 at 8:45 AM Thierry Onkelinx
 wrote:
>
> Yes, This was the problem. The recent version of lattice was in my home
> folder ~/R/x86_64-pc-linux-gnu-library/4.0 (first element of .libPaths()).
> An older version of lattice was in /usr/lib/R/library (last element of
> .libPaths()).
>
> install.packages("lattice", lib = "/usr/lib/R/library") solved the problem.
>
> So it looks like rcmdcheck ignored the first element of .libPaths(). I'm
> not sure if that is a bug of rcmdcheck. Shall I report an issue?
>
> Best regards,
>
> Thierry
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be
>
> ///
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
> ///
>
> <https://www.inbo.be>
>
>
> Op ma 8 mrt. 2021 om 17:28 schreef Gábor Csárdi :
>
> > Hi,
> >
> > If you think this is a bug in rcmdcheck, then please report an issue
> > here: https://github.com/r-lib/rcmdcheck/issues
> >
> > My guess is that you have another version of lattice in another
> > library, and that version is used with `--as-cran`.
> >
> > Gabor
> >
> > On Mon, Mar 8, 2021 at 5:18 PM Thierry Onkelinx
> >  wrote:
> > >
> > > Dear all,
> > >
> > > rcmdcheck::rcmdcheck() runs fine on my package.
> > rcmdcheck::rcmdcheck(args
> > > = c("--as-cran")) reports an error: package ‘lattice’ was installed
> > before
> > > R 4.0.0: please re-install it
> > > The error persists, even when I reinstall lattice.
> > >
> > > What am I missing?
> > >
> > > Best regards,
> > >
> > > Thierry
> > >
> > > sessioninfo::session_info("lattice")
> > > ─ Session info
> > >
> > 
> > >  setting  value
> > >  version  R version 4.0.4 (2021-02-15)
> > >  os   Ubuntu 18.04.5 LTS
> > >  system   x86_64, linux-gnu
> > >  ui   RStudio
> > >  language nl_BE:nl
> > >  collate  nl_BE.UTF-8
> > >  ctypenl_BE.UTF-8
> > >  tz   Europe/Brussels
> > >  date 2021-03-08
> > >
> > > ─ Packages
> > >
> > 
> > >  package * version date   lib source
> > >  lattice   0.20-41 2020-04-02 [1] CRAN (R 4.0.4)
> > >
> > >
> > > ir. Thierry Onkelinx
> > > Statisticus / Statistician
> > >
> > > Vlaamse Overheid / Government of Flanders
> > > INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
> > AND
> > > FOREST
> > > Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> > > thierry.onkel...@inbo.be
> > > Havenlaan 88 bus 73, 1000 Brussel
> > > www.inbo.be
> > >
> > >
> > ///
> > > To call in the statistician after the experiment is done may be no more
> > > than asking him to perform a post-mortem examination: he may be able to
> > say
> > > what the experiment died of. ~ Sir Ronald Aylmer Fisher
> > > The plural of anecdote is not data. ~ Roge

Re: [R-pkg-devel] How to R CMD build / check using LTO

[Bill Dunlap]

Hi Paul,

I think that changing the Fortran logicals to integers is the easiest
way to fix this up.

In the old days (1990's and maybe later), there were Fortran compilers
that did not map .TRUE. to 1 and .FALSE. to 0, but I suspect that R's
.Fortran does not cater to them.  I avoid Fortran logicals out of
habit.

-Bill

On Thu, Feb 18, 2021 at 1:59 AM Paul Schmidt-Walter
 wrote:
>
> Hi Bill,
>
> thanks a lot for your suggestion!
>
> I managed to use Gabors Docker image to reproduce the warning... I
> already found a solution, by turning LOGICAL to INTEGER in the F77_CALL
> and declare the subroutines' respective variables as
> integer(kind=c_int)... Was that your suggestion? Or is there an easier way?
>
> Thanks
>
> Paul
>
> On 2/17/21 9:48 PM, Bill Dunlap wrote:
> > I suspect your problem is that, at least with the recent gnu
> > compilers, the Fortran 'c_logical' maps to the C _Bool, not the C int.
> >
> > -Bill
> >
> > On Wed, Feb 17, 2021 at 11:38 AM Paul Schmidt-Walter
> >  wrote:
> >> Dear Team,
> >>
> >> My package 'LWFBrook90R' (https://github.com/pschmidtwalter/LWFBrook90R)
> >> was recently released on CRAN, but there are additional LTO Issues
> >> (https://www.stats.ox.ac.uk/pub/bdr/LTO/LWFBrook90R.out) with the
> >> compiled code, that need to be fixed soon.
> >>
> >> I would like to reproduce the LTO warnings locally to see if possible
> >> solutions fix them, but dont know how to build and check with LTO. I am
> >> a newbie on Ubuntu 18.04 and hope to get help in this case.
> >>
> >> There is information provided on how to configure R to reproduce the
> >> test (https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt), but I simply
> >> don't know how to "build with configure --enable-lto" and I also can't
> >> find the "config.site" file on my system to enable the respective
> >> compiler flags (see below).
> >>
> >> Any help is appreciated!
> >>
> >> Paul
> >>
> >> ---
> >>
> >> LTO-Readme.txt:
> >>
> >> Compilation logs for CRAN packages using x86_64 Fedora 32 Linux
> >> (currently using GCC 10.1)built with configure --enable-lto and
> >> config.site:
> >>
> >> CFLAGS="-g -O2 -Wall -pedantic -mtune=native"
> >> FFLAGS="-g -O2 -mtune=native -Wall -pedantic"
> >> CXXFLAGS="-g -O2 -Wall -pedantic -mtune=native -Wno-ignored-attributes
> >> -Wno-deprecated-declarations -Wno-parentheses"
> >> AR=gcc-ar
> >> RANLIB=gcc-ranlib
> >>
> >> Look for [-Wlto-type-mismatch] warnings.  In some cases these involve
> >> Fortran CHARACTER arguments where the length is passed as a 'hidden'
> >> argument at the end, giving mismatches such as
> >>
> >> sblas.f:3951:14: note: type ‘long int’ should match type ‘void’
> >>
> >> To work around these, define USE_FC_LEN_T and include Rconfig.h
> >> (perhaps via R.h) before including BLAS.h or Lapack.h or your own
> >> C proptypes for Fortran functions.  Then amend the actual calls to include
> >> character length arguments: see the example of
> >> src/library/stats/src/rWishart.c
> >>
> >> in the R sources.
> >>
> >> ---
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Paul Schmidt-Walter
> Eckernförder Str. 66
> 24116 Kiel
>

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

Re: [R-pkg-devel] How to R CMD build / check using LTO

[Bill Dunlap]

I suspect your problem is that, at least with the recent gnu
compilers, the Fortran 'c_logical' maps to the C _Bool, not the C int.

-Bill

On Wed, Feb 17, 2021 at 11:38 AM Paul Schmidt-Walter
 wrote:
>
> Dear Team,
>
> My package 'LWFBrook90R' (https://github.com/pschmidtwalter/LWFBrook90R)
> was recently released on CRAN, but there are additional LTO Issues
> (https://www.stats.ox.ac.uk/pub/bdr/LTO/LWFBrook90R.out) with the
> compiled code, that need to be fixed soon.
>
> I would like to reproduce the LTO warnings locally to see if possible
> solutions fix them, but dont know how to build and check with LTO. I am
> a newbie on Ubuntu 18.04 and hope to get help in this case.
>
> There is information provided on how to configure R to reproduce the
> test (https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt), but I simply
> don't know how to "build with configure --enable-lto" and I also can't
> find the "config.site" file on my system to enable the respective
> compiler flags (see below).
>
> Any help is appreciated!
>
> Paul
>
> ---
>
> LTO-Readme.txt:
>
> Compilation logs for CRAN packages using x86_64 Fedora 32 Linux
> (currently using GCC 10.1)built with configure --enable-lto and
> config.site:
>
> CFLAGS="-g -O2 -Wall -pedantic -mtune=native"
> FFLAGS="-g -O2 -mtune=native -Wall -pedantic"
> CXXFLAGS="-g -O2 -Wall -pedantic -mtune=native -Wno-ignored-attributes
> -Wno-deprecated-declarations -Wno-parentheses"
> AR=gcc-ar
> RANLIB=gcc-ranlib
>
> Look for [-Wlto-type-mismatch] warnings.  In some cases these involve
> Fortran CHARACTER arguments where the length is passed as a 'hidden'
> argument at the end, giving mismatches such as
>
> sblas.f:3951:14: note: type ‘long int’ should match type ‘void’
>
> To work around these, define USE_FC_LEN_T and include Rconfig.h
> (perhaps via R.h) before including BLAS.h or Lapack.h or your own
> C proptypes for Fortran functions.  Then amend the actual calls to include
> character length arguments: see the example of
> src/library/stats/src/rWishart.c
>
> in the R sources.
>
> ---
>
> __
> 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] accessing call constructors in Cpp

[Bill Dunlap]

Try using their official names, Rf_ScalarReal, Rf_eval, Rf_install, etc.
You may have #defined R_NO_REMAP in code that you did not show us.

-Bill

On Tue, Jan 5, 2021 at 1:42 PM Oliver Madsen 
wrote:

> This is maybe better suited for Rcpp-devel or another mailing list. If so,
> I apologize. :-)
>
> In a pet project I've been implementing quite a bit of a package structure
> within Cpp, including classes to contain and manipulate structures. As a
> final part of the implementation a user provided R function is to be
> executed with some of the manipulated data. While my first intuition (and
> the smart option) was to implement a method in R for extracting the
> parameters and simply executing the call, I got curious as to how one could
> do this in Cpp.
>
> After researching I found myriad options, one simple method being
> 1) Create a list of named and unnamed arguments
> 2) Extract "do.call" as a Function,
> 3) Test that the function provided is either a CLOSXP (function) or CHARSXP
> (or maybe STRSXP?) and then
> 4) execute the function call.
> but while going further down and checking the source code for do_docall I
> was curious about trying to recreate the call "the old fashioned way", but
> in Cpp. After looking over how it was done in R-source and a few examples
> online I tried implementing a simple call creation and evaluating it with
> Rf_eval
>
> ```cpp
> #include 
> #include 
> //[[Rcpp::export]]
> SEXP add_10_and_5(SEXP rho){ //rho is an environment (new.env() here)
> SEXP REALSXP_10 = PROTECT(ScalarReal(10));
> SEXP REALSXP_5 = PROTECT(ScalarReal(5));
> SEXP out = PROTECT(LCONS(install("+"), LCONS(
>   REALSXP_10, LCONS(
>   REALSXP_5, R_NilValue
>   )
> )));
> UNPROTECT(3);
> return eval(out, rho);
> }
> ```
> (For those who read the old version of Advanced R, this is a very similar
> to the R's C interface section on "PairLists")
>
> Immediately intellisense warned me that "ScalarReal", "install", "lcons"
> and "eval" are all undefined. However, a quick look in
> src/include/Rinternals.h shows that they are forward-declared there, and
> should (in my understanding) be defined. For good measures I tried
> including every header iteratively to no avail.
>
> While it is likely recommended to not do this (and the final product likely
> will be implemented in R), I am curious why I seem unable to access these 4
> from Cpp. I can't seem to spot the reason in the header file itself.
>
> Best regards
> Oliver
>
> [[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] Compiling 32-bit on Windows using 64-bit gcc and -m32

[bill]

> From: Tomas Kalibera  
> > Can I use the 64-bit gcc to build a 32-bit package with the -m32 
> > command line option with Rtools?  And, can that work for CRAN?  Or 
> > more generally, is there a work-around for needing lots of RAM during 
> > compilation with the 32-bit compiler?
> >
> > The background is:
> >
> > I'm trying to compile a the development version of RxODE 
> > (https://github.com/nlmixrdevelopment/RxODE/issues/278), but I'm 
> > hitting 32-bit memory limits (using >3GB and possibly >4GB RAM during 
> > compilation) using the 32-bit version of gcc.
>
> I think this is too much memory to be used for compilation. I think it would 
> be best to
> simplify the code, possibly split it, or just reduce the optimization level, 
> as I read you have > done already anyway. Maybe it doesn't have to be -O0, 
> maybe you can enable some. In 
> the past I've seen similar cases when inlining too aggressively in large 
> files, maybe you
> could just reduce that a bit. It may very well be that reducing the 
> optimization level just a 
> little bit will provide about the same performance, but require far less 
> memory at compile 
> time (in the past there have been cases when -O3 did not produce faster code 
> than -O2 on
> a set of standard benchmarks, of course that may be different in today's 
> compilers).

Yes, we are testing reducing the optimization level.  Using -O0 works to 
compile using ~500 MB.  The code can't be simplified as it is a very long 
algebraic equation.  The function is often used in the middle of an 
optimization routine that can often takes minutes to hours (statistical 
minimization here, not meaning compiler optimization), so optimization is 
preferable.  But, it's a fair point that I don't know the value of the 
different -O optimization levels for what is only long algebra.

Thanks,

Bill

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

[R-pkg-devel] Compiling 32-bit on Windows using 64-bit gcc and -m32

[bill]

Hello,

 

My question is:

Can I use the 64-bit gcc to build a 32-bit package with the -m32 command
line option with Rtools?  And, can that work for CRAN?  Or more generally,
is there a work-around for needing lots of RAM during compilation with the
32-bit compiler?

 

The background is:

I'm trying to compile a the development version of RxODE
(https://github.com/nlmixrdevelopment/RxODE/issues/278), but I'm hitting
32-bit memory limits (using >3GB and possibly >4GB RAM during compilation)
using the 32-bit version of gcc.  Specifically, 

 

"C:/rtools40/mingw32/bin/"gcc [etc., see the link above for the full command
line]

 

yields the error

 

cc1.exe: out of memory allocating 65536 bytes

 

There is no problem building with mingw64, and I played around to confirm
that by using:

 

Sys.setenv(BINPREF="c:/rtools40/mingw64/bin/")

 

And compilation completed successfully (though installation failed as
expected because the compiled .dll couldn't load on 32-bit R).

 

Thanks,

 

Bill


[[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] Check Error Due to Unicode in Documentation

[bill]

Thanks for the quick response both Duncan and Gábor.  I've reported it here in 
case others want to follow-up there: 
https://github.com/r-lib/roxygen2/issues/1121

-Original Message-
From: Gábor Csárdi  
Sent: Thursday, July 23, 2020 5:25 PM
To: Duncan Murdoch 
Cc: b...@denney.ws; R Package Devel 
Subject: Re: [R-pkg-devel] Check Error Due to Unicode in Documentation

On Thu, Jul 23, 2020 at 9:58 PM Duncan Murdoch  wrote:
>
> On 23/07/2020 4:14 p.m., b...@denney.ws wrote:
[...]
>
> If you change the source to include the explicit characters (i.e. use 
> pattern = c("μ", "µ") instead of pattern=c("\u03bc", "\u00b5")), does 
> that help?
>
> It may cause other issues:  WRE recommends against including UTF-8 
> chars in source code.
>
> If that doesn't solve the problem, then it looks like an issue with 
> Roxygen2.  I don't know if there's a way to tell it not to convert \u 
> escapes into the corresponding character.  If there isn't, it seems 
> like that's something they should add.  As a workaround, is there a 
> way to say that this one particular .Rd file should be edited by hand, 
> instead of auto-generated?

I don't think roxygen2 intentionally converts \u sequences, I think this is 
just a consequence of the parse() + deparse() roundtrip:

x <- '"\\u03bc"'
charToRaw(x)
#>  [1] 22 5c 75 30 33 62 63 22
y <- deparse(eval(parse(text = x)))
charToRaw(y)
#> [1] 22 b5 22

Bill, please report a roxygen2 issue at
https://github.com/r-lib/roxygen2/issues and we can probably fix this.
Thanks!

Gabor

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

[R-pkg-devel] Check Error Due to Unicode in Documentation

[bill]

Hello,

 

I have a personal package that I�d eventually like to clean up and either
find other packages to be homes for the functions or perhaps eventually
release it on CRAN.  To that end, I try to keep package checks working.

 

One of the functions that I use is to try to simplify Unicode text to ASCII.
With that, I tend to receive data that is scientifically-focused to the mu
character should be converted to a �u� instead of the standard conversion to
�m�.  On top of that, there are at least two Unicode characters that are
visually the mu character, one is the micro character and the other is an
actual lowercase mu.  This function converts both of those to �u� as
desired.

 

I generate the documentation using roxygen2, but the text in the
documentation aligns with the expected Unicode character, so I think the
issue is not with roxygen.

 

The issue is that Codoc gives the following error:

 

* checking for code/documentation mismatches ... WARNING

Codoc mismatches from documentation object 'unicode_to_ascii':

unicode_to_ascii.character

  Code: function(x, verbose = FALSE, pattern = c("μ", "µ"), replacement

 = c("u", "u"), general_

 

But, the code and documentation appear to be the same.  I think that the
issue relates to something with Unicode support in Codoc, but I�m not sure
how to test for that.  The code is here:

 

https://github.com/billdenney/bsd.report/blob/454caf217c5b333af1d65c7e63bbad
4194320e07/R/unicode_to_ascii.R#L28-L31

 

And the documentation is here:

 

https://github.com/billdenney/bsd.report/blob/454caf217c5b333af1d65c7e63bbad
4194320e07/man/unicode_to_ascii.Rd#L17-L24

 

Do you have any suggestions on how to make this code/documentation work with
Codoc?

 

Thanks,

 

Bill


[[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] Private S3 Method not Found

[bill]

Thanks for the pointer!  Adding "S3method(knit_print_helper_formula,name)" to 
the NAMESPACE seems to have fixed it.

For others who come across this, in roxygen2 parlance, that means using:

#' @method knit_print_helper_formula name
#' @export

Even though the actual export is not desired.

Thanks,

Bill

-Original Message-
From: Duncan Murdoch  

On 17/02/2020 10:05 a.m., b...@denney.ws wrote:
 
> Does anyone know why the S3 method for name class objects is not found 
> when checking the package?

I think you need to register knit_print_helper_formula.name as an S3 method 
even if the generic is not exported.  I forget whether you do this in the 
NAMESPACE file or at runtime using registerS3method.

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

Re: [R-pkg-devel] Private S3 Method not Found

[bill]

Hi Rich,

 

I’m not doing the same thing as Hmisc::latex().  That generates a .tex file and 
compiles it (or at least it appears to try to do that on my system, but it 
stopped partway through for me).

 

When I ran

 

Hmisc::latex(a~b)

 

It generated a .tex file for a table:

 

\begin{table}[!tbp]

\begin{center}

\begin{tabular}{l}

\hline\hline

\multicolumn{1}{c}{}\tabularnewline

\hline

~\tabularnewline

a\tabularnewline

b\tabularnewline

\hline

\end{tabular}\end{center}

\end{table}

 

While I’m wanting an equation:

 

$$a = b$$

 

Thanks,

 

Bill

 

From: Richard M. Heiberger  
Sent: Monday, February 17, 2020 10:31 AM
To: b...@denney.ws
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Private S3 Method not Found

 

Please be consistent with the latex() function in the Hmisc package.  For 
example, for an array x, latex (x) produces a complete latex table environment. 
 See the ?latex helpfile for details.

 

Rich

 

On Mon, Feb 17, 2020 at 10:07 mailto:b...@denney.ws> > wrote:

Hello,



I'm working on a function in a package that will provide an exported
function that will convert formula to LaTeX equations.  For that, it
recursively goes through the formula converting objects of class "formula",
"call", "name", and "(" to LaTeX.



I have a private S3 generic function that I'm using for the conversion, but
for some reason, the generic is not detected, and checking the package fails
for that reason
(https://travis-ci.org/billdenney/bsd.report/jobs/651510333):



no applicable method for 'knit_print_helper_formula' applied to an object of
class "name"

Backtrace:

  1. testthat::expect_equal(...)

  4. bsd.report:::knit_print.formula(a ~ b(c))

  6. bsd.report:::knit_print_helper_formula.formula(x, ..., replacements =
replacements)

  9. bsd.report:::knit_print_helper_formula.call(x[[3]], ...)

10. bsd.report:::knit_print_helper_formula.function_call(x, ...)

11. base::sapply(...)

12. base::lapply(X = X, FUN = FUN, ...)

13. bsd.report:::FUN(X[[i]], ...)



But, there is a knit_print_helper_formula.name 
<http://knit_print_helper_formula.name>  function call defined
(https://github.com/billdenney/bsd.report/blob/master/R/knit_print.formula.R 
<https://github.com/billdenney/bsd.report/blob/master/R/knit_print.formula.R#L60-L79>
 
#L60-L79):



knit_print_helper_formula <- function(x, ...) {

  UseMethod("knit_print_helper_formula")

}



# Some other methods



knit_print_helper_formula.name <http://knit_print_helper_formula.name>  <- 
function(x, ...) {

# Function body

}



Does anyone know why the S3 method for name class objects is not found when
checking the package?



Thanks,



Bill


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org <mailto: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] Private S3 Method not Found

[bill]

Hello,

 

I'm working on a function in a package that will provide an exported
function that will convert formula to LaTeX equations.  For that, it
recursively goes through the formula converting objects of class "formula",
"call", "name", and "(" to LaTeX.

 

I have a private S3 generic function that I'm using for the conversion, but
for some reason, the generic is not detected, and checking the package fails
for that reason
(https://travis-ci.org/billdenney/bsd.report/jobs/651510333):

 

no applicable method for 'knit_print_helper_formula' applied to an object of
class "name"

Backtrace:

  1. testthat::expect_equal(...)

  4. bsd.report:::knit_print.formula(a ~ b(c))

  6. bsd.report:::knit_print_helper_formula.formula(x, ..., replacements =
replacements)

  9. bsd.report:::knit_print_helper_formula.call(x[[3]], ...)

10. bsd.report:::knit_print_helper_formula.function_call(x, ...)

11. base::sapply(...)

12. base::lapply(X = X, FUN = FUN, ...)

13. bsd.report:::FUN(X[[i]], ...)

 

But, there is a knit_print_helper_formula.name function call defined
(https://github.com/billdenney/bsd.report/blob/master/R/knit_print.formula.R
#L60-L79):

 

knit_print_helper_formula <- function(x, ...) {

  UseMethod("knit_print_helper_formula")

}

 

# Some other methods

 

knit_print_helper_formula.name <- function(x, ...) {

# Function body

}

 

Does anyone know why the S3 method for name class objects is not found when
checking the package?

 

Thanks,

 

Bill


[[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] Large Data Package CRAN Preferences

[bill]

Hi Uwe,

Thanks for this information, and it makes sense to me.  Is there a preferred 
way to cache the data locally?

None of the ways that I can think to cache the data sound particularly good, 
and I wonder if I'm missing something.  The ideas that occur to me are:

1. Download them into the package directory `path.package("datapkg")`, but that 
would require an action to be performed on package installation, and I'm 
unaware of any way to trigger an action on installation.
2. Have a user-specified cache directory (e.g. 
`options("datapkg_cache"="/my/cache/location")`), but that would require 
interaction with every use.  (Not horrible, but it will likely significantly 
increase the number of user issues with the package.)
3. Have a user-specified cache directory like #2, but have it default to 
somewhere in their home directory like `file.path(Sys.getenv("HOME"), 
"datapkg_cache")` if they have not set the option.

To me #3 sounds best, but I'd like to be sure that I'm not missing something.

Thanks,

Bill

-Original Message-
From: Uwe Ligges  
Sent: Sunday, December 15, 2019 11:54 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Large Data Package CRAN Preferences

Ideally yoiu wpuld host the data elsewhere and submit a CRAN package that 
allows users to easily get/merge/aggregate the data.

Best,
Uwe Ligges



On 12.12.2019 20:55, b...@denney.ws wrote:
> Hello,
> 
>   
> 
> I have two questions about creating data packages for data that will 
> be updated and in total are >5 MB in size.
> 
>   
> 
> The first question is:
> 
>   
> 
> In the CRAN policy, it indicates that packages should be ?5 MB in size 
> in general.  Within a package that I'm working on, I need access to 
> data that are updated approximately quarterly, including the 
> historical datasets (specifically, these are the SDTM and CDASH 
> terminologies in https://evs.nci.nih.gov/ftp1/CDISC/SDTM/Archive/).
> 
>   
> 
> Current individual data updates are approximately 1 MB when 
> individually saved as .RDS, and the total current set is about 20 MB.  
> I think that the preferred way to generate these packages since there 
> will be future updates is to generate one data package for each update 
> and then have an umbrella package that will depend on each of the individual 
> data update packages.
> That seems like it will minimize space requirements on CRAN since old 
> data will probably never need to be updated (though I will need to access it).
> 
>   
> 
> Is that an accurate summary of the best practice for creating these as 
> a data package?
> 
>   
> 
> And a second question is:
> 
>   
> 
> Assuming the best practice is the one I described above, the typical 
> need will be to combine the individual historical datasets for local 
> use.  An initial test of the time to combine the data indicates that 
> it would take about 1 minute to do, but after combination, the result 
> could be loaded faster.  I'd like to store the combined dataset 
> locally with the umbrella package.  I believe that it is considered 
> poor form to write within the library location for a package except during 
> installation.
> 
>   
> 
> What is the best practice for caching the resulting large dataset 
> which is locally-generated?
> 
>   
> 
> Thanks,
> 
>   
> 
> Bill
> 
> 
>   [[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

[R-pkg-devel] Large Data Package CRAN Preferences

[bill]

Hello,

 

I have two questions about creating data packages for data that will be
updated and in total are >5 MB in size.

 

The first question is:

 

In the CRAN policy, it indicates that packages should be ?5 MB in size in
general.  Within a package that I'm working on, I need access to data that
are updated approximately quarterly, including the historical datasets
(specifically, these are the SDTM and CDASH terminologies in
https://evs.nci.nih.gov/ftp1/CDISC/SDTM/Archive/).

 

Current individual data updates are approximately 1 MB when individually
saved as .RDS, and the total current set is about 20 MB.  I think that the
preferred way to generate these packages since there will be future updates
is to generate one data package for each update and then have an umbrella
package that will depend on each of the individual data update packages.
That seems like it will minimize space requirements on CRAN since old data
will probably never need to be updated (though I will need to access it).

 

Is that an accurate summary of the best practice for creating these as a
data package?

 

And a second question is:

 

Assuming the best practice is the one I described above, the typical need
will be to combine the individual historical datasets for local use.  An
initial test of the time to combine the data indicates that it would take
about 1 minute to do, but after combination, the result could be loaded
faster.  I'd like to store the combined dataset locally with the umbrella
package.  I believe that it is considered poor form to write within the
library location for a package except during installation.

 

What is the best practice for caching the resulting large dataset which is
locally-generated?

 

Thanks,

 

Bill


[[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] How to Document and S3 Method for the Parenthesis Class?

[bill]

That's fair, though it's not 100% consistent because code like the following 
works for symbols, too:

"(\\@" <- 1

(This is selected to show how bad things can be done-- not as an example to 
advocate.)

-Original Message-
From: Jeff Newmiller  
Sent: Thursday, November 7, 2019 10:43 AM
To: r-package-devel@r-project.org; b...@denney.ws
Subject: Re: [R-pkg-devel] How to Document and S3 Method for the Parenthesis 
Class?

There are three types of quoting in R... " and ' are for strings, and ` 
(backtick) is for symbols.

On November 7, 2019 6:35:49 AM PST, b...@denney.ws wrote:
>Hi,
>
> 
>
>Short version of the question:  How does one document a method for the 
>"("
>class in a .Rd file?
>
> 
>
>Details:
>
>I recently contributed to the digest package functions to assist with 
>generating sha1 hashes for formula objects.  Sometimes within formula, 
>the parenthesis ("(") class is used, for example [1]:
>
> 
>
>> class((a~(b+c))[[3]])
>
>[1] "("
>
> 
>
>So, I wrote a method to handle that class, too.  When trying to 
>document it in the .Rd file, I tried the following code, but when 
>checking the documentation, it gets an error:
>
> 
>
>\method{sha1}{"("}(x, digits = 14, zapsmall = 7, ..., algo = "sha1")
>
> 
>
>The error when checking the documentation is:
>
> 
>
>> checking Rd \usage sections ... WARNING
>
>  Bad \usage lines found in documentation object 'sha1':
>
>   method{sha1}{"("}(x, digits = 14, zapsmall = 7, ..., 
>algo = "sha1")
>
>  
>
>  Functions with \usage entries need to have the appropriate \alias
>
>  entries, and all their arguments documented.
>
>  The \usage entries must correspond to syntactically valid R code.
>
>  See chapter 'Writing R documentation files' in the 'Writing R
>
>  Extensions' manual.
>
> 
>
>I have tried variants of escaping the parenthesis like "\(" and "\\("
>and
>the unescaped variant "(", too.
>
> 
>
>Thanks,
>
> 
>
>Bill
>
> 
>
>[1] In case the first thought is, "don't write formula which have a 
>full side within redundant parentheses", something equivalent to this 
>was created by update.formula().
>
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list 
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

--
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] How to Document and S3 Method for the Parenthesis Class?

[bill]

Thank you, Duncan, that fixed it!

-Original Message-
From: Duncan Murdoch  
Sent: Thursday, November 7, 2019 10:27 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] How to Document and S3 Method for the Parenthesis 
Class?

On 07/11/2019 9:35 a.m., b...@denney.ws wrote:
> Hi,
> 
>   
> 
> Short version of the question:  How does one document a method for the "("
> class in a .Rd file?
> 
>   
> 
> Details:
> 
> I recently contributed to the digest package functions to assist with 
> generating sha1 hashes for formula objects.  Sometimes within formula, 
> the parenthesis ("(") class is used, for example [1]:
> 
>   
> 
>> class((a~(b+c))[[3]])
> 
> [1] "("
> 
>   
> 
> So, I wrote a method to handle that class, too.  When trying to 
> document it in the .Rd file, I tried the following code, but when 
> checking the documentation, it gets an error:
> 
>   
> 
> \method{sha1}{"("}(x, digits = 14, zapsmall = 7, ..., algo = "sha1")

I think this should work:

   \method{sha1}{`(`}(x, digits = 14, zapsmall = 7, ..., algo = "sha1")

A quick test case gave me errors from not documenting the args, but not the bad 
\usage line error described below.

Duncan Murdoch

> 
>   
> 
> The error when checking the documentation is:
> 
>   
> 
>> checking Rd \usage sections ... WARNING
> 
>Bad \usage lines found in documentation object 'sha1':
> 
>  method{sha1}{"("}(x, digits = 14, zapsmall = 7, 
> ..., algo = "sha1")
> 
>
> 
>Functions with \usage entries need to have the appropriate \alias
> 
>entries, and all their arguments documented.
> 
>The \usage entries must correspond to syntactically valid R code.
> 
>See chapter 'Writing R documentation files' in the 'Writing R
> 
>Extensions' manual.
> 
>   
> 
> I have tried variants of escaping the parenthesis like "\(" and "\\(" 
> and the unescaped variant "(", too.
> 
>   
> 
> Thanks,
> 
>   
> 
> Bill
> 
>   
> 
> [1] In case the first thought is, "don't write formula which have a 
> full side within redundant parentheses", something equivalent to this 
> was created by update.formula().
> 
> 
>   [[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

[R-pkg-devel] How to Document and S3 Method for the Parenthesis Class?

[bill]

Hi,

 

Short version of the question:  How does one document a method for the "("
class in a .Rd file?

 

Details:

I recently contributed to the digest package functions to assist with
generating sha1 hashes for formula objects.  Sometimes within formula, the
parenthesis ("(") class is used, for example [1]:

 

> class((a~(b+c))[[3]])

[1] "("

 

So, I wrote a method to handle that class, too.  When trying to document it
in the .Rd file, I tried the following code, but when checking the
documentation, it gets an error:

 

\method{sha1}{"("}(x, digits = 14, zapsmall = 7, ..., algo = "sha1")

 

The error when checking the documentation is:

 

> checking Rd \usage sections ... WARNING

  Bad \usage lines found in documentation object 'sha1':

method{sha1}{"("}(x, digits = 14, zapsmall = 7, ...,
algo = "sha1")

  

  Functions with \usage entries need to have the appropriate \alias

  entries, and all their arguments documented.

  The \usage entries must correspond to syntactically valid R code.

  See chapter 'Writing R documentation files' in the 'Writing R

  Extensions' manual.

 

I have tried variants of escaping the parenthesis like "\(" and "\\(" and
the unescaped variant "(", too.

 

Thanks,

 

Bill

 

[1] In case the first thought is, "don't write formula which have a full
side within redundant parentheses", something equivalent to this was created
by update.formula().


[[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] Literal LaTeX Text in Function Arguments

[bill]

Hi Georgi,

Thank you for the detailed investigation!  It looks like you've found the
issue with the psub() call below.

It looks like a more complex regexp, "(? gsub(pattern="(? 
Sent: Saturday, August 24, 2019 12:28 PM
To: b...@denney.ws; 'Duncan Murdoch' ;
r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

It seems that expansion of \ldots occurs in two different circumstances. 

1) The Rd2XXX converters treat specially \ldots and \dots but in different
ways. tools::Rd2latex() defines in its body texify(), which, when called
with a piece of R code, starts by replacing \ldots and \dots with

 x <- psub("[l]{0,1}dots", "...", as.character(x))

Similarly, Rd2ex(), defines a function remap() which does a similar thing.
The 'html' and 'txt' renderers also treat specially \dots and \ldots but
only in more restricted cases. I didn't find what 'R CMD check' does. 

This might explain the differences between 'html'  and 'text' on the one
hand, and 'pdf' output on the other hand. 
(as Duncan pointed out, he didn't see this in html).

But macros starting with '\l'  seem to be expanded in R code in all formats,
if the backslash is not escaped, example a) below illustrates this. I
redefined '\ldots' to demonstrate that this is  not due to the special
treatment that literally replaces \ldots with '...' as above. I think this
follows from the specification of Rd format p. 8 of the 'parseRd' document
referenced in my previous email. 


For illiustration, I added the following lines before the Usage section in
Bill's file topic_long_table_header.Rd.

\renewcommand{\ldots}{Aaaargh }
\renewcommand{\lmydots}{Uuugh }
\renewcommand{\mydots}{this is mydots }

Here the Usage entry for the shown argument  only is modified (with 3
backslashes)

topic_long_table_header(x, col_names = NULL,
  (not changed)
  subsequent_page_notification = "\\\ldots continued \\\lmydots \\\mydots",
  (not changed)
   )

In the pdf file we see 

subsequent_page_notification = "\Aaaargh continued \Uuugh \\mydots"

\ldots and \lmydots are expanded but \mydots is not. I believe that \lmydots
is expanded since it starts with 'l', see my previous email. In this case,
'R CMD check' gives an additional warning about the unescaped backslash: 

...
subsequent_page_notification = "Aaaargh  continued
\Uuugh  \\mydots"

This seems to happen since an attempt is made later to parse \Aaaargh and
\Uuugh. If the Rd entry in the Usage section contaiin only one backslash, as
in  
 subsequent_page_notification = "\ldots continued \lmydots \\\mydots",

then we get in all renderings: 

subsequent_page_notification = "Aaaargh continued Uuugh \\mydots"

'R CMD check' also shows this text (and complains, since it obviously is not
as in the function deifnition,



b) With proper escaping (using 4, instead of 3 backslashes above) we get (in
the pdf rendering):

subsequent_page_notification = "\... continued \\lmydots \\mydots"

\ldots is expanded but the other macros are not. Note that the expansion of
\ldots here is due is due to the specific rendering for LaTeX, which
replaces \\ldots by three dots (...), and doesn't use my Rd definition for
\ldots, suggesting that  this occurs at a different place.


Georgi Boshnakov

From: b...@denney.ws [b...@denney.ws]
Sent: 24 August 2019 14:46
To: 'Duncan Murdoch'; Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Duncan,

The original Rd generated by roxygen2 had 4 backslashes:

https://github.com/billdenney/TopicLongTableR/blob/master/man/topic_long_tab
le_header.Rd#L9

That generated a similar issue but check showed "\..." (backslash then 3
dots) instead of what is shown in the 2 backslashes case when check showed
just "...".

So, while I agree that 4 backslashes would make the most sense for the .Rd
file, there is still an issue somewhere with that 4 backslashes case.

Thanks,

Bill

-Original Message-
From: Duncan Murdoch 
Sent: Saturday, August 24, 2019 8:37 AM
To: b...@denney.ws; 'Georgi Boshnakov' ;
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

On 24/08/2019 7:35 a.m., Duncan Murdoch wrote:
> On 23/08/2019 1:33 p.m., b...@denney.ws wrote:
>> Hi Georgi,
>>
>> Thanks for this pointer.  My guess at this point is that I've found a 
>> bug (or maybe a couple of bugs with 'utils::prompt()' and with the Rd 
>> to help conversion), but let me know if you think otherwise.
>
> It's certainly not a bug in utils:prompt:  that's ne

Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[bill]

Hi Duncan,

The original Rd generated by roxygen2 had 4 backslashes:

https://github.com/billdenney/TopicLongTableR/blob/master/man/topic_long_table_header.Rd#L9

That generated a similar issue but check showed "\..." (backslash then 3 dots) 
instead of what is shown in the 2 backslashes case when check showed just "...".

So, while I agree that 4 backslashes would make the most sense for the .Rd 
file, there is still an issue somewhere with that 4 backslashes case.

Thanks,

Bill

-Original Message-
From: Duncan Murdoch  
Sent: Saturday, August 24, 2019 8:37 AM
To: b...@denney.ws; 'Georgi Boshnakov' ; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

On 24/08/2019 7:35 a.m., Duncan Murdoch wrote:
> On 23/08/2019 1:33 p.m., b...@denney.ws wrote:
>> Hi Georgi,
>>
>> Thanks for this pointer.  My guess at this point is that I've found a 
>> bug (or maybe a couple of bugs with 'utils::prompt()' and with the Rd 
>> to help conversion), but let me know if you think otherwise.
> 
> It's certainly not a bug in utils:prompt:  that's never called except 
> by the user.

Actually, that's wrong.  utils::prompt() is generating bad code:  you need to 
have 4 backslashes in order to display 2.  It is just showing the string as it 
would be deparsed for display, it isn't modifying it so that it is appropriate 
as Rd source.

Duncan Murdoch


> 
> It might be a bug in the .Rd parsing, but I don't think so, because 
> I'm not seeing it when I write the .Rd file manually and view it in HTML.
> 
> It's most likely a bug in the check code, because I am seeing the same 
> "Codoc mismatches" error as you are.  I'm also seeing it in the pdf 
> display of the help page, but not in the HTML or text displays.
> 
> Duncan Murdoch
> 
>>
>> I just did that way, and the usage lines that were generated by 
>> 'utils::prompt()' and copied into the docs are:
>>
>> topic_long_table_header(x, col_names = NULL,
>> above_col_names = "\\hline", below_col_names = "\\hline",
>> subsequent_page_notification = "\\ldots continued",
>> latex_header = NULL, verbatim = NULL)
>>
>> topic_long_table_footer(x, bottom_border = "\\hline",
>> bottom_all_pages = NULL, bottom_last_page = NULL,
>> subsequent_page_notification = "continued \\ldots",
>> verbatim = NULL)
>>
>> It is giving a very similar error with 'R CMD check' (outside devtools).
>> The escape of the backslashes appears to be needed, but "\\ldots" 
>> continues to be translated into "...":
>>
>> Codoc mismatches from documentation object 'topic_long_table_header':
>> topic_long_table_header
>> Code: function(x, col_names = NULL, above_col_names = "\\hline",
>>below_col_names = "\\hline",
>>subsequent_page_notification = "\\ldots continued",
>>latex_header = NULL, verbatim = NULL)
>> Docs: function(x, col_names = NULL, above_col_names = "\hline",
>>below_col_names = "\hline",
>>subsequent_page_notification = "... continued",
>>latex_header = NULL, verbatim = NULL)
>> Mismatches in argument default values:
>>   Name: 'above_col_names' Code: "\\hline" Docs: "\hline"
>>   Name: 'below_col_names' Code: "\\hline" Docs: "\hline"
>>   Name: 'subsequent_page_notification' Code: "\\ldots continued" Docs:
>> "... continued"
>> topic_long_table_footer
>> Code: function(x, bottom_border = "\\hline", bottom_all_pages = NULL,
>>bottom_last_page = NULL, subsequent_page_notification
>>= "continued \\ldots", verbatim = NULL)
>> Docs: function(x, bottom_border = "\hline", bottom_all_pages = NULL,
>>bottom_last_page = NULL, subsequent_page_notification
>>= "continued ...", verbatim = NULL)
>> Mismatches in argument default values:
>>   Name: 'bottom_border' Code: "\\hline" Docs: "\hline"
>>   Name: 'subsequent_page_notification' Code: "continued \\ldots" Docs:
>> "continued ..."
>>
>> Thanks,
>>
>> Bill
>>
>> -Original Message-
>> From: Georgi Boshnakov 
>> Sent: Frida

Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[bill]

Hi Georgi,

Thanks for this pointer.  My guess at this point is that I've found a bug
(or maybe a couple of bugs with 'utils::prompt()' and with the Rd to help
conversion), but let me know if you think otherwise.

I just did that way, and the usage lines that were generated by
'utils::prompt()' and copied into the docs are:

topic_long_table_header(x, col_names = NULL,
  above_col_names = "\\hline", below_col_names = "\\hline",
  subsequent_page_notification = "\\ldots continued",
  latex_header = NULL, verbatim = NULL)

topic_long_table_footer(x, bottom_border = "\\hline",
  bottom_all_pages = NULL, bottom_last_page = NULL,
  subsequent_page_notification = "continued \\ldots",
  verbatim = NULL)

It is giving a very similar error with 'R CMD check' (outside devtools).
The escape of the backslashes appears to be needed, but "\\ldots" continues
to be translated into "...":

Codoc mismatches from documentation object 'topic_long_table_header':
topic_long_table_header
  Code: function(x, col_names = NULL, above_col_names = "\\hline",
 below_col_names = "\\hline",
 subsequent_page_notification = "\\ldots continued",
 latex_header = NULL, verbatim = NULL)
  Docs: function(x, col_names = NULL, above_col_names = "\hline",
 below_col_names = "\hline",
 subsequent_page_notification = "... continued",
 latex_header = NULL, verbatim = NULL)
  Mismatches in argument default values:
Name: 'above_col_names' Code: "\\hline" Docs: "\hline"
Name: 'below_col_names' Code: "\\hline" Docs: "\hline"
Name: 'subsequent_page_notification' Code: "\\ldots continued" Docs:
"... continued"
topic_long_table_footer
  Code: function(x, bottom_border = "\\hline", bottom_all_pages = NULL,
 bottom_last_page = NULL, subsequent_page_notification
 = "continued \\ldots", verbatim = NULL)
  Docs: function(x, bottom_border = "\hline", bottom_all_pages = NULL,
 bottom_last_page = NULL, subsequent_page_notification
 = "continued ...", verbatim = NULL)
  Mismatches in argument default values:
Name: 'bottom_border' Code: "\\hline" Docs: "\hline"
Name: 'subsequent_page_notification' Code: "continued \\ldots" Docs:
"continued ..."

Thanks,

Bill

-Original Message-
From: Georgi Boshnakov  
Sent: Friday, August 23, 2019 11:27 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Bill,

Sorry, I misunderstood the question.

To check if the problem is with R's tools, run
'utils::prompt(topic_long_table_header)" and see the usage section of the
generated file. Presumably, this should be the 'canonical way' to write the
usage entry for the function.
You can copy and paste it in the Rd file generated by roxygen2, then run 'R
CMD build' and 'R CMD check' (outside devtools). 

Georgi


-Original Message-
From: b...@denney.ws [mailto:b...@denney.ws]
Sent: 23 August 2019 15:27
To: Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Georgi,

I'm not trying to use it as part of my documentation, it is one of my
function arguments.  I want the function argument to be displayed correctly
in the help, but it is not.  I'm curious how I should document the
"subsequent_page_notification" function argument in Rd.

Specifically, the actual function definition (R code) looks like:

R code:
--
topic_long_table_header <- function(x,
col_names=NULL,
above_col_names="\\hline",
below_col_names="\\hline",
subsequent_page_notification="\\ldots
continued",
latex_header=NULL) {
  # The function body
}
--

So, I'm not trying to use LaTeX in the .Rd file; I'm trying to use it in R,
and I'm then copying it into the .Rd with extra escaping for the backslashes
(well, roxygen2 is doing the extra escaping).

Rd text
--
topic_long_table_header(x, col_names = NULL,
  above_col_names = "hline", below_col_names = "hline",
  subsequent_page_notification = "ldots continued",
  latex_header = NULL)
--

Thanks,

Bill

-Original Message-
From: Georgi Boshnakov 
Sent: Friday, August 23, 2019 9:52 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: R

Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[bill]

Hi Georgi,

I'm not trying to use it as part of my documentation, it is one of my
function arguments.  I want the function argument to be displayed correctly
in the help, but it is not.  I'm curious how I should document the
"subsequent_page_notification" function argument in Rd.

Specifically, the actual function definition (R code) looks like:

R code:
--
topic_long_table_header <- function(x,
col_names=NULL,
above_col_names="\\hline",
below_col_names="\\hline",
subsequent_page_notification="\\ldots
continued",
latex_header=NULL) {
  # The function body
}
--

So, I'm not trying to use LaTeX in the .Rd file; I'm trying to use it in R,
and I'm then copying it into the .Rd with extra escaping for the backslashes
(well, roxygen2 is doing the extra escaping).

Rd text
--
topic_long_table_header(x, col_names = NULL,
  above_col_names = "hline", below_col_names = "hline",
  subsequent_page_notification = "ldots continued",
  latex_header = NULL)
--

Thanks,

Bill

-Original Message-
From: Georgi Boshnakov  
Sent: Friday, August 23, 2019 9:52 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Rd is not LaTeX, although it resembles it.  You should use only markup
described in WRE.
For example, \dots is for the use case you mention. 

Georgi Boshnakov





-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
Behalf Of b...@denney.ws
Sent: 23 August 2019 04:15
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hello,

 

Does anyone know how to include verbatim \ldots (and maybe other LaTeX) in
an .Rd file correctly? 

 

When LaTeX is in the default arguments for a function, the code is
interpreted which makes the documentation not match the default formal
arguments.

 

An example is:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/R/topic_long_table_header_footer.R#L20

 

Which yields:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/man/topic_long_table_header.Rd#L10

 

Which gives the following warning with `devtools::check()`:

```

checking for code/documentation mismatches ... WARNING

Codoc mismatches from documentation object 'topic_long_table_header':

topic_long_table_header

  Code: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\\ldots continued
 ",

 latex_header = NULL)

  Docs: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\... continued",

 latex_header = NULL)

```

 

I'm not sure, but I think that the solution is to add more protection to the
\s when generating the roxygen or perhaps wrapping the arguments in some
form of verbatim block (if it's available).

 

Thanks,

 

Bill

 

P.S. This is also discussed in https://github.com/r-lib/roxygen2/issues/837
where it appears to be related to the conversion of .Rd to help files not
the roxygen step.

 


[[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

[R-pkg-devel] Literal LaTeX Text in Function Arguments

[bill]

Hello,

 

Does anyone know how to include verbatim \ldots (and maybe other LaTeX) in
an .Rd file correctly? 

 

When LaTeX is in the default arguments for a function, the code is
interpreted which makes the documentation not match the default formal
arguments.

 

An example is:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/R/topic_long_table_header_footer.R#L20

 

Which yields:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/man/topic_long_table_header.Rd#L10

 

Which gives the following warning with `devtools::check()`:

```

checking for code/documentation mismatches ... WARNING

Codoc mismatches from documentation object 'topic_long_table_header':

topic_long_table_header

  Code: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\\ldots continued
 ",

 latex_header = NULL)

  Docs: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\... continued",

 latex_header = NULL)

```

 

I'm not sure, but I think that the solution is to add more protection to the
\s when generating the roxygen or perhaps wrapping the arguments in some
form of verbatim block (if it's available).

 

Thanks,

 

Bill

 

P.S. This is also discussed in https://github.com/r-lib/roxygen2/issues/837
where it appears to be related to the conversion of .Rd to help files not
the roxygen step.

 


[[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] Conditionally register method with generic in other package

[Bill Denney]

> On Dec 6, 2017, at 07:45, Joshua Ulrich  wrote:
> 
> To avoid excessive dependencies, I would like to only register
> foo.bar() if package A is installed at the time package B is
> installed.  If package A is installed after package B, then warn the
> user when package B is loaded and/or attached, so they can re-install
> A and have foo.bar() registered correctly.

One simple solution would be to wrap the instantiation of foo.bar in a require 
test:

if (require(A)) {
  foo.bar <- function(...) {
print("To be or not to be")
  }
} else {
  message("To use the foo.bar function, please install package A.")
}

Thanks,

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

Re: [R-pkg-devel] Testing for a Specific R Error

[Bill Denney]

> On Dec 2, 2017, at 09:43, Duncan Murdoch  wrote:
> 
> I don't think there's anything better than Bill's solution, though I imagine 
> it is possible to ask for translation of the message.  For example, sqrt(-1) 
> currently gives a warning with English message "NaNs produced".

Another idea just occurred to me.  Get the current error text as I'm expecting 
it from R by generating the error in a tryCatch and then test for equality to 
that string.  With that, changes in R (or other packages) would be 
automatically updated, and it would still be a precise test for the error I'm 
wanting to confirm in my test:

tryCatch(as.data.frame(structure(1, class="foo")), error=function(e) e$message)

Capture the output of that tryCatch and test for equality.

Then, it will be robust to language changes and to changes in R or other 
packages.

I'm going to implement that unless someone indicates something that I'm missing.

Thanks,

Bill

> 
> I can ask to translate that into the current session language using
> 
> gettext("NaNs produced", domain = "R")
> 
> Figuring out the right thing for "domain" is likely a little painful: it 
> depends on which package produced the message, and how.
> 
> I don't know if CRAN tests would complain if you tested for equality between 
> a warning message and the result of gettext():  it's still true that if the 
> English warning changed, the test would fail.
> 
> Duncan Murdoch

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

[R-pkg-devel] Testing for a Specific R Error

[Bill Denney]

Hi,

I got a message last night that some of the tests in the PKNCA package do not 
follow best practices.  ("Do not test the exact format of R messages (from R 
itself or from other packages): They change, and they can be translated.")  
Specifically, I test to ensure that an error is generated when a class cannot 
be coerced into a data.frame: 
https://cran.r-project.org/web/checks/check_results_PKNCA.html

I want to ensure that I'm getting an error that the variable cannot be coerced 
into a data.frame.

What is the best practice to ensure that I'm getting a specific R error (about 
coercion) without testing the formatting of the error text?

The only solution that immediately occurs to me is to wrap the coercion in a 
tryCatch and give my own error.  But, then were the R error translated, the 
users of my package would lose the benefit of translation.

Thanks,

Bill

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

Re: [R-pkg-devel] Installing Tests with R Build

[Bill Denney]

Hi Joshua,

The TravisCI link to the first failed build is: 
https://travis-ci.org/billdenney/pknca/builds/305997673
Along with the GitHub commit: 
https://github.com/billdenney/pknca/commit/97495044cb90076ba817e1c8b140c50d35b5a654

My eventual solution was to check for the existence of the tests directory and 
run the vignette if the tests were installed.

Thanks,

Bill

-Original Message-
From: Joshua Ulrich [mailto:josh.m.ulr...@gmail.com] 
Sent: Saturday, November 25, 2017 9:20 AM
To: Bill Denney 
Cc: Dirk Eddelbuettel ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Installing Tests with R Build

On Thu, Nov 23, 2017 at 10:05 AM, Bill Denney  wrote:
> Hi Joshua and Dirk,
>
>> On Nov 23, 2017, at 10:17, Dirk Eddelbuettel  wrote:
>>
>>
>> On 23 November 2017 at 08:07, Joshua Ulrich wrote:
>> | On Wed, Nov 22, 2017 at 4:21 PM, Bill Denney  wrote:
>> | > When running R BUILD now (via Travis CI), I get an error that the build 
>> failed trying to build the vignettes.  For R CMD install, I can add 
>> --install-tests.  Is there a way to control R BUILD so that the installation 
>> includes test installation?
>> | >
>> | Put the tests you want to install into a directory inside the inst/ 
>> | directory (e.g. inst/tests/).
>>
>> Which happens to be the default mode of operations with RUnit.
>>
>> And it is a feature that I happen to _like_ a great deal because it 
>> permits testing of the _installed_ package which is something you 
>> need in real life when eg some of you system libraries may have change.
>
> Putting the tests there seems like a very reasonable solution to the 
> immediate issue.  It contravenes the options to install (or not install) 
> tests ("R CMD INSTALL --install-tests" loses meaning).  I'm going to update 
> the structure of my vignette so that it detects if the tests are there and 
> builds the vignette based on the existence of the tests (making it say 
> "Please install the tests following these instructions...").
>
> I'm immediately ok with reworking the directory structure and tests, but I 
> think it would be preferable long run to:
> Have R CMD BUILD gain an --install-args option so that installation arguments 
> can be controlled (for situations like this and I'm sure others).
>
I just took a closer look at this, and I don't understand why any change is 
necessary.  With a package created by package.skeleton():

josh@thinkpad: ~/git
> R CMD build anRpackage
* checking for file 'anRpackage/DESCRIPTION' ... OK
* preparing 'anRpackage':
* checking DESCRIPTION meta-information ... OK
* installing the package to process help pages
* saving partial Rd database
* creating vignettes ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building 'anRpackage_1.0.tar.gz'


josh@thinkpad: ~/git
> tar -ztf anRpackage_1.0.tar.gz
anRpackage/DESCRIPTION
anRpackage/NAMESPACE
anRpackage/R/
anRpackage/R/file.R
anRpackage/build/
anRpackage/build/partial.rdb
anRpackage/build/vignette.rds
anRpackage/inst/
anRpackage/inst/doc/
anRpackage/inst/doc/file.Rnw
anRpackage/inst/doc/file.pdf
anRpackage/man/
anRpackage/man/anRpackage-package.Rd
anRpackage/tests/
anRpackage/tests/unittests.R
anRpackage/vignettes/
anRpackage/vignettes/file.Rnw

The package builds successfully, and the tests are still in their tests/ 
directory.  Now if I install without the --install-tests flag:

josh@thinkpad: ~/git
> R CMD INSTALL anRpackage_1.0.tar.gz 2>/dev/null

josh@thinkpad: ~/git
> ls -l ~/R/library/anRpackage/
total 32
-rw-r--r-- 1 josh josh  420 Nov 25 08:16 DESCRIPTION drwxr-xr-x 2 josh josh 
4096 Nov 25 08:16 doc drwxr-xr-x 2 josh josh 4096 Nov 25 08:16 help drwxr-xr-x 
2 josh josh 4096 Nov 25 08:16 html
-rw-r--r-- 1 josh josh   59 Nov 25 08:16 INDEX
drwxr-xr-x 2 josh josh 4096 Nov 25 08:16 Meta
-rw-r--r-- 1 josh josh   72 Nov 25 08:16 NAMESPACE
drwxr-xr-x 2 josh josh 4096 Nov 25 08:16 R

You can see there's no tests/ directory.  Now with the --install-tests flag:

josh@thinkpad: ~/git
> R CMD INSTALL anRpackage_1.0.tar.gz --install-tests 2>/dev/null

josh@thinkpad: ~/git
> ls -l ~/R/library/anRpackage/
total 36
-rw-r--r-- 1 josh josh  420 Nov 25 08:17 DESCRIPTION drwxr-xr-x 2 josh josh 
4096 Nov 25 08:17 doc drwxr-xr-x 2 josh josh 4096 Nov 25 08:17 help drwxr-xr-x 
2 josh josh 4096 Nov 25 08:17 html
-rw-r--r-- 1 josh josh   59 Nov 25 08:17 INDEX
drwxr-xr-x 2 josh josh 4096 Nov 25 08:17 Meta
-rw-r--r-- 1 josh josh   72 Nov 25 08:17 NAMESPACE
drwxr-xr-x 2 josh josh 4096 Nov 25 08:17 R drwxr-xr-x 2 josh josh 4096 Nov 25 
08:17 tests

The tests/ directory is present, and I can run the tests:

josh@thinkpad: ~/git
> Rscript -e 'tools::testInstalledPackage("a

Re: [R-pkg-devel] Installing Tests with R Build

[Bill Denney]

Hi Joshua and Dirk,

> On Nov 23, 2017, at 10:17, Dirk Eddelbuettel  wrote:
> 
> 
> On 23 November 2017 at 08:07, Joshua Ulrich wrote:
> | On Wed, Nov 22, 2017 at 4:21 PM, Bill Denney  wrote:
> | > When running R BUILD now (via Travis CI), I get an error that the build 
> failed trying to build the vignettes.  For R CMD install, I can add 
> --install-tests.  Is there a way to control R BUILD so that the installation 
> includes test installation?
> | >
> | Put the tests you want to install into a directory inside the inst/
> | directory (e.g. inst/tests/).
> 
> Which happens to be the default mode of operations with RUnit.
> 
> And it is a feature that I happen to _like_ a great deal because it permits
> testing of the _installed_ package which is something you need in real life
> when eg some of you system libraries may have change.

Putting the tests there seems like a very reasonable solution to the immediate 
issue.  It contravenes the options to install (or not install) tests ("R CMD 
INSTALL --install-tests" loses meaning).  I'm going to update the structure of 
my vignette so that it detects if the tests are there and builds the vignette 
based on the existence of the tests (making it say "Please install the tests 
following these instructions...").

I'm immediately ok with reworking the directory structure and tests, but I 
think it would be preferable long run to:
Have R CMD BUILD gain an --install-args option so that installation arguments 
can be controlled (for situations like this and I'm sure others).

Thank you (and Happy Thanksgiving to those celebrating it),

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

[R-pkg-devel] Installing Tests with R Build

[Bill Denney]

Hi,

I have a package that I'm trying to make a validation vignette for.  The 
validation vignette is intended to assist users with documentation that the 
tests work.

When running R BUILD now (via Travis CI), I get an error that the build failed 
trying to build the vignettes.  For R CMD install, I can add --install-tests.  
Is there a way to control R BUILD so that the installation includes test 
installation?

Thanks,

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

Re: [R-pkg-devel] r-quantities seeking feedback

[Bill Denney]

Hi Iñaki and David,

I fully see the need in a standardized unit package, and I understand the need 
for propagation of errors (though I'm in the opposite camp to David where I 
usually need unit tracking and conversion and rarely need error propagation-- 
though that's because my error propagation is often nonlinear and sometimes not 
normally distributed, so I have to do it myself).

I agree with David in that: error propagation and unit tracking and conversion 
are different with partially-overlapping audiences.  But, I agree with Iñaki 
that there is a need for a consistent framework that can handle both.

The reason for the need of a consistent framework is that if we have two 
separate packages that handle both they generally will be unaware of each other 
and may not play nicely together (ref the recent discussion on tibbles not 
always playing nicely with code expecting data.frames).  I think that three 
packages should generally be the goal:
1) One that handles units
2) One that handles error propagation
3) One that uses the other two to handle both units and error propagation

The components that I didn't see in your discussion of your proposal is 
extension of both libraries.

For units, it should be possible to connect any set of units to any other set 
of units with a new conversion (e.g. mass and molar units could be connected 
with a molecular weight).  And, it should be possible to have multiple unit 
systems that can manage separate sets of rules (often an extension of a basic 
set of rules), and these should be possible to connect together.  The example 
for me again is with molecular weights, I may have molecule 1 that has a 
molecular weight of 100 g/mole and molecule 2 with a molecular weight of 200 
g/mole; I would need to be able to store those at the same time without the 
system confusing the two.  And, I would slow need to store the rule that 2 
count of molecule 1 make 1 count of molecule 2.  (FYI, parts of this are in 
https://github.com/pacificclimate/Rudunits2/pull/9 )

For both units and error propagation, these will need to work with general 
functions in packages that do not explicitly support the new packages.  As an 
example, the lm, glm, gls, etc. (along with thousands of other) functions are 
unlikely to be modified for support of the packages).  There should be some 
mechanism to make a simple wrapper function that looks at the input and 
understands how to map the output. Such as:

lm_quantities <- function(...) {
# look at the LHS of the formula argument, and apply any maths required to 
determine the units of the LHS.
# call lm normally
# assign units and/or error propagation to the result of the lm call
}

That would have to be repeated for any other function of interest.  
Straight-forward examples that are part of the recommended libraries would 
hopefully be covered, and other library authors should have a simple way of 
assessing what the right units and error measures are to add it to their own 
libraries (optionally).

Thanks,

Bill

> On Oct 6, 2017, at 13:13, David Hugh-Jones  wrote:
> 
> One question that comes to mind: what's the synergy? I e why are units and
> errors best handled together? I use standard errors a lot, but never
> units... I would like a standard way to represent uncertainty but don't
> think I need the other stuff.
> Cheers,
> D
> 
>> On Fri, 6 Oct 2017 at 17:25, Iñaki Úcar  wrote:
>> 
>> Dear all,
>> 
>> Edzer Pebesma and I are combining forces into a new GitHub
>> organisation called "r-quantities", to which we have moved the CRAN
>> packages 'units', 'errors' and 'constants'. The idea is to write a new
>> package called 'quantities' to integrate 'units' and 'errors' into a
>> comprehensive solution for dealing with quantity values + uncertainty
>> calculus.
>> 
>> Given that a significant fraction of R users, both practitioners and
>> researchers, use R to analyse measurements, we believe that the R
>> community would benefit from such a project. Moreover, to the best of
>> our knowledge, there exists no such an integrated and automated
>> framework outside the R language.
>> 
>> We would like to share a proposal [1] to be submitted to the R
>> Consortium before October 15. Until then, we kindly invite the R
>> package developers to review it. Any feedback or contribution would be
>> very helpful.
>> 
>> [1] https://github.com/r-quantities/proposal
>> 
>> Regards,
>> Iñaki
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> -- 
> Sent from Gmail Mobile
> 
>[[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

[R-pkg-devel] Loading Libraries Outside of .lib.loc

[Bill Denney]

Hi,

I'm working on a script to test my library (PKNCA) for what the minimum 
required version of its dependencies are.  Specifically, I've received 
bug reports when people are using versions of dplyr < 0.5.0.


To test my package against old versions of libraries, I'm installing old 
versions of packages in separate directories with:



dir.create("/tmp/current", recursive=TRUE)
install.packages("devtools", lib="/tmp/current")


I then try to load the devtools library that I've just installed, and I 
get an error:



library(devtools, lib.loc="/tmp/current")

Error: package or namespace load failed for ‘devtools’:
 .onLoad failed in loadNamespace() for 'devtools', details:
  call: loadNamespace(name)
  error: there is no package called ‘withr’

I would have assumed that lib.loc would cause R to search within the 
directory I just created for the dependencies, too.  But it doesn't 
appear to do so:



library(withr, lib.loc="/tmp/current")



(no error)

Is this intended behavior or a bug?  If intended behavior, I can 
manipulate .lib.loc through something like:


assign(".lib.loc", envir=environment(.libPaths),
   c("/tmp/current", "/usr/local/lib/R/site-library",
 "/usr/lib/R/site-library", "/usr/lib/R/library"))

Thanks,

Bill

P.S. Apologies if this would better fit on a more general mailing list, 
but the only reason I'm bashing at library and install.packages is 
related to package development and testing.


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

Re: [R-pkg-devel] Handling Not-Always-Needed Dependencies? - Part 2

[Bill Denney]

On 8/4/2016 11:51 AM, Dirk Eddelbuettel wrote:

On 4 August 2016 at 11:46, Paul Gilbert wrote:
| If my package has a test that needs another package, but that package is
| not needed in the /R code of my package, then I indicate it as
| "Suggests", not as "Depends" nor as "Imports".  If that package is not
| available when I run R CMD check, should the test pass?

Wrong question.

Better question:  Should the test be running?  My preference is for only
inside of a requireNamespace() (or equivalent) block as the package is not
guaranteed to be present.  In theory.

In practice people seem to unconditionally install it anyway, and think that
is a good idea.  I disagree on both counts but remain in the vocal minority.
As another package maintainer, I had almost the identical question 
reading the previous (long) thread, but the three answers here don't 
give the same answer.  My question I can make even more concrete:


I use the testthat package for my testing.  I never use it in the R code 
itself, and it is explicitly only used for testing.  Should that be 
included as "Depends" because every test requires it or "Suggests" 
because no end user ever needs it?


If "Depends", then it leads to over-installation of the package by end 
users who don't care about running tests locally.  If "Suggests", then 
all of the tests would fail (assuming that Dirk's suggestion is 
implemented).


At a loss,

Bill

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

Re: [R-pkg-devel] Warning that are Unintentionally OS-Specific (Maybe Bug in warning?)

[Bill Denney]

Max and Ben got the right answer.  It is a bug with mclapply dropping 
warnings.  I confirmed by a quick change to the code to just use lapply, 
and the warnings appeared as expected.


I've submitted the bug at 
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17122


Thanks for the help!

Bill


On 7/20/2016 3:40 PM, Ben Bolker wrote:

Digging into the code (specifically by setting
options(warn=2,error=recover), I see that the warning is happening
during this call:

 tmp.results <- parallel::mclapply(X = conc.dose, FUN =
pk.nca.intervals,
 intervals = data$intervals, options = data$options)

Since mclapply "relies on forking and hence is not available on Windows
unless ‘mc.cores = 1’" (from ?mclapply), I can imagine that it's *not*
actually being run in parallel on Windows.  It also wouldn't surprise me
at all if it took a little bit of care to make sure that warnings were
correctly passed back from code chunks run in parallel.

   This StackOverflow post seems to ask the same question as yours:

http://stackoverflow.com/questions/21486658/warnings-suppressed-with-mclapply-in-r

   based on the discussion there, it seems as though it might be worth
bringing this up on r-devel/submitting a bug report ...

Ben Bolker




On 16-07-20 03:13 PM, Bill Denney wrote:

Hi François,

I thought that was the issue, too, but I confirmed it wasn't that by
adding a print statement right above the warning in my code. The print
statement displays the message even when the warning (one line below
with no conditionals between) doesn't show anything.

Also, why would it behave differently when options(warn=1) is set rather
than the default of options(warn=0)?

Thanks,

Bill


On 7/20/2016 3:06 PM, François Michonneau wrote:

Hi Bill,

The problem is not with the warning() function but with your if()
test that triggers the warning. It probably has something to do with
slight differences in rounding. I suggest you use debug() or browser()
on each platform to see why your condition is TRUE or FALSE.

Cheers,
-- François

On Wed, Jul 20, 2016 at 2:42 PM, Bill Denney  wrote:

Hi,

I'm developing the PKNCA package, and I've got an odd difference between
warning behavior on different operating systems that I can't figure out.

When I run the following code on Windows 10 (with R 3.3.0), I get the
following warning:

library(PKNCA)
source("https://raw.githubusercontent.com/billdenney/pknca/master/tests/testthat/generate.data.R";)

tmpconc <- generate.conc(2, 1, 0:24)
tmpconc$conc <- 0
tmpdose <- generate.dose(tmpconc)
myconc <- PKNCAconc(tmpconc, conc~time|treatment+ID)
mydose <- PKNCAdose(tmpdose, dose~time|treatment+ID)
mydata <- PKNCAdata(myconc, mydose)
myresult <- pk.nca(mydata)

Warning messages:
1: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
Too few points for half-life calculation (min.hl.points=3 with only 0
points)
2: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
Too few points for half-life calculation (min.hl.points=3 with only 0
points)

When I run the code on Linux (Ubuntu 16.04 with R 3.3.1), I do not get a
warning.  When I run the code on Linux after "options(warn=1)", I get
the
warning.  I have confirmed that the same code path is taken in both
Windows
and Linux by simply inserting a print statement next to the warning.
The
actual warning code is:

  warning(sprintf(
"Too few points for half-life calculation (min.hl.points=%g
with only
%g points)",
min.hl.points, nrow(dfK)))

This platform inconsistency is causing issues with my package because
the
package expects the warnings, and the user should know about the
warnings.
I've got test cases expecting the warnings, and they fail everywhere but
Windows
(https://cran.r-project.org/web/checks/check_results_PKNCA.html).

Does anyone have an idea why warnings may behave differently on Windows
compared to non-Windows platforms?  Is this a bug in R somewhere?
(I've not
been able to make a simpler example that triggers the issue,
unfortunately.)

Thanks,

Bill

__
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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Warning that are Unintentionally OS-Specific (Maybe Bug in warning?)

[Bill Denney]

Hi François,

I thought that was the issue, too, but I confirmed it wasn't that by 
adding a print statement right above the warning in my code. The print 
statement displays the message even when the warning (one line below 
with no conditionals between) doesn't show anything.


Also, why would it behave differently when options(warn=1) is set rather 
than the default of options(warn=0)?


Thanks,

Bill


On 7/20/2016 3:06 PM, François Michonneau wrote:

Hi Bill,

   The problem is not with the warning() function but with your if()
test that triggers the warning. It probably has something to do with
slight differences in rounding. I suggest you use debug() or browser()
on each platform to see why your condition is TRUE or FALSE.

   Cheers,
   -- François

On Wed, Jul 20, 2016 at 2:42 PM, Bill Denney  wrote:

Hi,

I'm developing the PKNCA package, and I've got an odd difference between
warning behavior on different operating systems that I can't figure out.

When I run the following code on Windows 10 (with R 3.3.0), I get the
following warning:

library(PKNCA)
source("https://raw.githubusercontent.com/billdenney/pknca/master/tests/testthat/generate.data.R";)
tmpconc <- generate.conc(2, 1, 0:24)
tmpconc$conc <- 0
tmpdose <- generate.dose(tmpconc)
myconc <- PKNCAconc(tmpconc, conc~time|treatment+ID)
mydose <- PKNCAdose(tmpdose, dose~time|treatment+ID)
mydata <- PKNCAdata(myconc, mydose)
myresult <- pk.nca(mydata)

Warning messages:
1: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
   Too few points for half-life calculation (min.hl.points=3 with only 0
points)
2: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
   Too few points for half-life calculation (min.hl.points=3 with only 0
points)

When I run the code on Linux (Ubuntu 16.04 with R 3.3.1), I do not get a
warning.  When I run the code on Linux after "options(warn=1)", I get the
warning.  I have confirmed that the same code path is taken in both Windows
and Linux by simply inserting a print statement next to the warning.  The
actual warning code is:

 warning(sprintf(
   "Too few points for half-life calculation (min.hl.points=%g with only
%g points)",
   min.hl.points, nrow(dfK)))

This platform inconsistency is causing issues with my package because the
package expects the warnings, and the user should know about the warnings.
I've got test cases expecting the warnings, and they fail everywhere but
Windows (https://cran.r-project.org/web/checks/check_results_PKNCA.html).

Does anyone have an idea why warnings may behave differently on Windows
compared to non-Windows platforms?  Is this a bug in R somewhere?  (I've not
been able to make a simpler example that triggers the issue, unfortunately.)

Thanks,

Bill

__
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] Warning that are Unintentionally OS-Specific (Maybe Bug in warning?)

[Bill Denney]

Hi,

I'm developing the PKNCA package, and I've got an odd difference between 
warning behavior on different operating systems that I can't figure out.


When I run the following code on Windows 10 (with R 3.3.0), I get the 
following warning:


library(PKNCA)
source("https://raw.githubusercontent.com/billdenney/pknca/master/tests/testthat/generate.data.R";)
tmpconc <- generate.conc(2, 1, 0:24)
tmpconc$conc <- 0
tmpdose <- generate.dose(tmpconc)
myconc <- PKNCAconc(tmpconc, conc~time|treatment+ID)
mydose <- PKNCAdose(tmpdose, dose~time|treatment+ID)
mydata <- PKNCAdata(myconc, mydose)
myresult <- pk.nca(mydata)

Warning messages:
1: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
  Too few points for half-life calculation (min.hl.points=3 with only 0 
points)

2: In pk.calc.half.life(conc = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  :
  Too few points for half-life calculation (min.hl.points=3 with only 0 
points)


When I run the code on Linux (Ubuntu 16.04 with R 3.3.1), I do not get a 
warning.  When I run the code on Linux after "options(warn=1)", I get 
the warning.  I have confirmed that the same code path is taken in both 
Windows and Linux by simply inserting a print statement next to the 
warning.  The actual warning code is:


warning(sprintf(
  "Too few points for half-life calculation (min.hl.points=%g with 
only %g points)",

  min.hl.points, nrow(dfK)))

This platform inconsistency is causing issues with my package because 
the package expects the warnings, and the user should know about the 
warnings.  I've got test cases expecting the warnings, and they fail 
everywhere but Windows 
(https://cran.r-project.org/web/checks/check_results_PKNCA.html).


Does anyone have an idea why warnings may behave differently on Windows 
compared to non-Windows platforms?  Is this a bug in R somewhere?  (I've 
not been able to make a simpler example that triggers the issue, 
unfortunately.)


Thanks,

Bill

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