Re: [R-pkg-devel] Export everything whose name does not start with ".".

[Hugh Parsonage]

It would have been helpful for that person to specify their candidate
regex, rather than just saying it could be simpler.

That out of the way, I believe

   exportPattern("^[^.]")

would be sufficient since the square brackets remove any special
meaning the dot has. For an alternative, given the limitations on
syntactic identifiers in R (namely, that they must start with either a
dot or letters), one might also consider

   exportPattern("^[A-Za-z]")


On Sat, 16 Mar 2024 at 11:03, Rolf Turner  wrote:
>
>
> There was fairly recently a discussion on this list of a problem whose
> solution involved having code in NAMESPACE which exported everything
> whose name did not start with ".".
>
> In the course of this discussion it was remarked that the code given in
> "Writing R Extensions", explicitly
>
>exportPattern("^[^\\.]")
>
> wasn't quite right and could/should have a simpler form.
>
> I don't really understand what's going on --- regular expressions
> completely blow me away.
>
> Can someone please inform me as to what the simpler form should be?
>
> [What really frustrates me is that I was *sure* I had saved the emails
> pertaining to this discussion, but now I cannot find any  deleted> trace of what I thought I'd saved!]
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Stats. Dep't. (secretaries) phone:
>  +64-9-373-7599 ext. 89622
> Home phone: +64-9-480-4619
>
> __
> 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] Additional Issues: Intel

[Hugh Parsonage]

My package grattan fails the Intel[1] check with

  Error: segfault from C stack overflow

I am unable to immediately see where in the test suite this error has
occurred.  I seek advice on how to fix this error.  The only hunch I
have is that the package uses C code and includes structs with arrays
on the stack, which perhaps are excessive for the Intel check machine,
but am far from confident that's the issue.  The repository is at


[1]https://www.stats.ox.ac.uk/pub/bdr/Intel/grattan.out

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

Re: [R-pkg-devel] checking CRAN incoming feasibility

[Hugh Parsonage]

>  Surely the software just has to check
that there is web connection to a CRAN mirror.

Nope! The full code is in tools:::.check_package_CRAN_incoming  (the
body of which filled up my entire console), but to name a few checks
it has to do: check that the name of the package is not the same as
any other, including archived packages (which means that it has to
download the package metadata), make sure the licence is ok, see if
the version number is ok. 10 minutes is quite a lot though. I suspect
the initial connection may have been faulty.

On Tue, 16 Jan 2024 at 16:15, Rolf Turner  wrote:
>
>
> This post essentially amounts to idle curiosity.  I don't really expect
> that anything can be done about the problem that I perceive.
>
> When I check a package using --as-cran, the code spits out a line
>
> checking CRAN incoming feasibility ...
>
> and then disappears into a black hole for what seems an eternity (5 or
> 10 minutes).
>
> Why does this step take so long?  Surely the software just has to check
> that there is web connection to a CRAN mirror.  I would have thought
> that this would be executed virtually instantaneously.
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Stats. Dep't. (secretaries) phone:
>  +64-9-373-7599 ext. 89622
> Home phone: +64-9-480-4619
>
> __
> 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] Canonical way to Rprintf R_xlen_t

[Hugh Parsonage]

Hello,

I've been asked to update my package which contains numerous instances of

Rprintf("%lld", xlength(x));

that is, erroneously using %lld for objects of type R_xlen_t.  Having
searched for the correct way, I seem to have come across 3 competing
approaches:

Rprintf("%lld", (long long) xlength(x));
Rprintf("%td, xlength(x));
or
using the string macro found in Mr Kalibera's commit of r85641: R_PRIdXLEN_T

Which would be most advisable for my update, required in the next fortnight?


Hugh Parsonage

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

Re: [R-pkg-devel] How to identify what flags "Additional Issues" for UBSAN

[Hugh Parsonage]

In line 
https://github.com/alarm-redist/redist/blob/f1ed042841469456c1d8c149092bc818e2a5c1a5/src/wilson.cpp#L165

int max_try = 50 * remaining * ((int) std::log(remaining));

you need to ensure remaining > 0.  At some point it became -1.

On Thu, 23 Mar 2023 at 22:07, Ivan Krylov  wrote:
>
> В Wed, 22 Mar 2023 15:51:54 +
> "Kenny, Christopher"  пишет:
>
> > Is there an easy way to identify what is causing the flag?
>
> Unfortunately, it's _all_ the sanitizer errors.
>
> > wilson.cpp:165:34: runtime error: signed integer overflow:
> > -2147483648 * -1 cannot be represented in type 'int'
>
> > However, my understanding is that these errors should be expected, as
> > the input is controlled from within the package and checking for
> > these types of errors in every loop would push against the purpose of
> > using C++ for performance here.
>
> You'd be right to think that signed integer overflow just wraps around
> on modern CPUs with no adverse effects on the rest of the execution.
> Unfortunately, you'd also need to convince the C++ optimiser, and it's
> currently allowed to think otherwise.
>
> In C++, signed integer overflow (and other similar errors, such as
> casing NaN to an integer) is undefined behaviour, which, according to
> the standard, means that anything can happen after that, ranging from
> nothing out of order to a crash and also to silent corruption of
> important research results. Other languages define integer overflow to
> have a more limited impact (wrap the value around or at least guarantee
> a crash), but not C and C++. [*]
>
> Thankfully, I only see one spot where you encounter UB, in
> src/wilson.cpp line 165, which should be relatively easy to fix by
> adjusting your strategy for calculating the maximum number of tries.
> (Do you get a NaN when `remaining` is -1? Why is it -1? Or is it 0?)
>
> --
> Best regards,
> Ivan
>
> [*]
> Some old gcc version used to launch the game Nethack when certain kinds
> of UB were encountered. The situation has improved in some ways since
> that and worsened in others: modern C and C++ compilers, especially
> Clang, use UB to guide their optimisation efforts, so if the optimiser
> can prove "if A is true then UB happens", it optimises with the
> assumption that A is false.
>
> Combined with optimizer bugs, this understanding of undefined
> behaviour may lead to funny situations where the inability of the
> compiler to prove certain facts about the program leads to
> mathematically inconsistent results:
> https://blog.regehr.org/archives/140
>
> __
> 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] [UNCLASSIFIED] Remotes in description when submitting a package until a dependency is fixed

[Hugh Parsonage]

I think you've misunderstood that excerpt.  By "temporary development
state", it means _between_ CRAN releases; packages in a development
state are not suitable for CRAN, as the policy states:

> CRAN hosts packages of publication quality and is not a development platform.

You'll need to stop depending on that package until it's fixed and the
fix is on CRAN. That said, it looks like it might be relatively
straightforward to disentangle yourself from the package -- just
rewrite the offending example?

On Wed, 16 Nov 2022 at 15:35, Bernd.Gruber  wrote:
>
> Hi,
>
> I have a package (dartR) that needs to be updated by CRAN (and got a time set 
> until a certain date). It depends on a package that is currently showing 
> errors in the CRAN results and therefore fails. The maintainer of that 
> package is busily trying to rectify the error (as can be seen be repeated 
> submissions in the last weeks), but was not able yet to fix it. As we are 
> running out of time my approach would be to have a version of the package 
> that fixes it and use Remotes: in the description. It runs fine without 
> errors.
>
> In the R-packages book I read the following:
>
> "It's important to note that you should not submit your package to CRAN in 
> the intermediate state, meaning with a Remotes field and with a dependency 
> required at a version that's not available from CRAN or Bioconductor. For 
> CRAN packages, this can only be a temporary development state, eventually 
> resolved when the dependency updates on CRAN and you can bump your minimum 
> version accordingly."
>
> So is it okay to submit our package with a remote statement until the 
> maintainer of the other package has fixed their issues?
>
> Thanks in advance,
> Bernd
>
>
> ==
> Dr Bernd Gruber  )/_
>  _.--..---"-,--c_
> Professor Ecological Modelling  \|..'   ._O__)_
> Tel: (02) 6206 3804 ,=._.+   _ \..--( /
> Fax: (02) 6201 2328   \\.-''_.-' \ ( \_
> Institute for Applied Ecology  `'''   `\__   /\
> Faculty of Science and Technology  ')
> University of Canberra   ACT 2601 AUSTRALIA
> Email: bernd.gru...@canberra.edu.au
> WWW: 
> bernd-gruber
> ==
>
> [UC Logo]
>
> [Its time to control your Future. Apply now to study with Australia's fastest 
> rising University. *QS, 2022]
>
>
>
> The Ngunnawal people are the Traditional Custodians of the ACT where UC's 
> Bruce Campus is situated and are an integral and celebrated part of UC's 
> culture. We also acknowledge other First Nations Peoples.
>
> Australian Government Higher Education Registered Provider (CRICOS) #00212K. 
> TEQSA Provider ID: PRV12003 (Australian University)
> Email 
> Disclaimer
>
> [UC Facebook][UC Twitter] 
>  [UC Instagram] 
>  [UC Linkedin] 
>  [UC Youtube] 
>  [University of Canberra] 
> 
>
> [[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] Best way to cache a dataframe available for all functions in a package

[Hugh Parsonage]

Agreed. One can also initialise such an environment as a package option in
.onLoad which may be better or worse depending in part on how much
restriction you want to place on the environment

On Sat, 27 Nov 2021 at 12:41 am, Lionel Henry  wrote:

> Hello,
>
> The trick is to store cached objects in an environment. In our team
> some of us have started calling this environment "the" to reflect that
> the elements in that environment are global singletons.
>
> Create the environment somewhere in your package:
>
> ```
> the <- new.env(parent = emptyenv())
> ```
>
> Then you can initialise and/or retrieve like this:
>
> ```
> my_data <- function() {
>   if (is.null(the$data)) {
> the$data <- generate_data()
>   }
>   the$data
> }
> ```
>
> This is much better than initialising on load. Downloading on load
> would slow down loading your package and any packages that depend on
> it. Also the download might fail, causing the loading of your package
> to fail in turn.
>
> Best,
> Lionel
>
> On 11/26/21, X FiM  wrote:
> > Dear all,
> >
> > I am writing a package that needs to load some data from a URL and have
> > such data (meta data) available when using other functions in the
> package,
> > and I would like some advice on how to properly manage such situation.
> >
> >
> > My first guess would be to create a function to downloads that meta data,
> > and make this function run when loading the package. I am even familiar
> > with this, and I could manage.
> >
> > But the second part, making this sort of data frame available for other
> > functions in the package, how can I achieve it? Of course I can call the
> > function that downloads and prepares the data at every use of the other
> > functions, but that would mean connecting to the Internet again and
> again.
> > So, in other words, is there a way to "cache" into memory a data frame
> > (without having to create an object)?
> >
> > How could I achieve such thing? What are the kind of keywords that I need
> > to use when looking for help?
> >
> > Thank you very much,
> >
> > --
> > Xavier
> >
> >   [[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
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] S3 is.unsorted registration

[Hugh Parsonage]

I would like to register an S3 method for `is.unsorted` for my
package's class "factor256" but I'm having trouble honouring the
`strictly` argument.  I've defined

is.unsorted.factor256 <- function(x, na.rm = FALSE, strictly = FALSE) {
  strictly
}

i.e. the class is sorted iff strictly = TRUE

However, the strictly argument appears to be ignored

x <- integer(2)
class(x) <- "factor256"

is.unsorted(x)  # FALSE [expected]
is.unsorted(x, strictly = TRUE)  # FALSE [unexpected]

The method is definitely being dispatched as when I change the function to

is.unsorted.factor256 <- function(x, na.rm = FALSE, strictly = FALSE) {
  cat("dispatching\n")
  strictly
}

I see the dispatch:

is.unsorted(ff, strictly = T)
#> dispatching
#> [1] FALSE

and

> methods("is.unsorted")
[1] is.unsorted.factor256
see '?methods' for accessing help and source code

I note that if I omit the na.rm = argument I will get the intended
result (I was drawn to the solution by noting the .Internal call has
omitted it) but I'm wondering whether this is correct.


Best,


Hugh Parsonage.

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

Re: [R-pkg-devel] Workaround for code/documentation mismatch

[Hugh Parsonage]

What is the behaviour of %while% if not preceded by an expression wrapped
in do() ?

On Wed, 11 Aug 2021 at 1:26 pm, Andrew Simmons  wrote:

> Hello,
>
>
> I've written two functions to emulate do while/until loops seen in other
> languages, but I'm having trouble documenting its usage. The function is
> typically used like:
>
> do ({
> expr1
> expr2
> ...
> }) %while% (cond)
>
> so I want to document it something like:
>
> do(expr) %while% (cond)
> do(expr) %until% (cond)
>
> to look like the documentation for 'while' and 'if', but R CMD check
> produces a "Code/documentation mismatch" warning, complaining that the
> documentation should look like:
>
> expr %while% cond
> expr %until% cond
>
> So, my question is, is there a way to bypass the
> * checking for code/documentation mismatches
> portion of R CMD check, at least for one file? Some way to acknowledge that
> the code and documentation will mismatch, but that's okay.
>
>
> Thank you!
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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 parallel:::sendMaster despite warnings

[Hugh Parsonage]

Happily, package parallel is open-source. If you would like to make
use of the unexported functions, you could copy the source code with
acknowledgement into your package. Naturally this might be a lot of
work and risks different behaviour between your package and parallel,
but neither might be that terrible for you.  And certainly would be
better than trying to pretend that the functions you want are exported
from parallel.

On Fri, 23 Jul 2021 at 23:09, David Norris  wrote:
>
> I can confirm that getFromNamespace() does indeed circumvent the WARNING.
> I might otherwise prefer ':::', however, for making its 'bad intentions' so 
> clear.
> I was very much aware of the cautionary language under `?readChild`, but 
> wondered whether *in practice* more liberal community policies might be in 
> force pending the maturation of the futureverse.
> Although the sparse history of the relevant file hardly supports 
> "might-break-at-any-time" alarmism, I do note that the last commit (in May 
> 2020) introduced an argument sendMaster(raw.asis=TRUE) that I am actually 
> using.
> https://github.com/wch/r-source/commits/trunk/src/library/parallel/R/unix/mcfork.R
>
> (Also agree with Yohann that ideally one might support Windows with a warning 
> such as data.table issues regarding my Mac's non-support for OpenMP.)
>
> Best, David
>
> From: Sebastian Meyer 
> Organization: Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU)
> Date: Friday, July 23, 2021 at 8:05 AM
> To: David Norris , 
> "r-package-devel@r-project.org" 
> Subject: Re: [R-pkg-devel] Using parallel:::sendMaster  despite warnings
>
> Am 23.07.21 um 13:19 schrieb David Norris:
> Because parallelized progress reporting in the futureverse.org incurs 
> latencies too great for my application 
> (https://github.com/HenrikBengtsson/progressr/issues/118), I have found it 
> necessary to implement my own progress reporting using some of the 
> non-exported functionality from `parallel`. (I do appreciate that Windows 
> lacks the fork() system call, and will not support this. But am willing to 
> make this an OS_type: unix-only package.)
>
> Of course, I get a WARNING for this:
>
> ── R CMD check results  precautionary 0.2.6 
> 
> Duration: 6m 41.8s
>
> ❯ checking dependencies in R code ... WARNING
> Unexported objects imported by ':::' calls:
>   ‘parallel:::readChild’ ‘parallel:::selectChildren’
>   ‘parallel:::sendMaster’
>   See the note in ?`:::` about the use of this operator.
>   Including base/recommended package(s):
>   ‘parallel’
>
> Is this warning an absolute deal-killer on CRAN? Is there a 'correct' way to 
> do `:::` that avoids the warning altogether?
>
> The 'parallel' functions your package intends to access seem to be
> intentionally unexported. Their help page says: "They are not available
> on Windows, and not exported from the namespace", and "This is a very
> low-level interface for expert use only: it not regarded as part of the
> R API and subject to change without notice."
>
> Correspondingly, the CRAN Repository Policy says
>
> Also, ::: should not be used to access undocumented/internal objects in base 
> packages (nor should other means of access be employed). Such usages can 
> cause packages to break at any time, even in patched versions of R.
>
> which kind of answers both of your questions. The policy thus implicitly
> advises against using getFromNamespace().
>
> Best regards,
>
> Sebastian Meyer
>
>
> Kind regards,
> David Norris
>
> __
> mailto: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] OpenMP on MacOS

[Hugh Parsonage]

Ensure you surround all your omp pragmas like so:

#ifdef _OPENMP
#pragma omp parallel ...
#endif

Essentially, detecting the operating system is not enough -- you need
to condition your use of OpenMP if and only if _OPENMP is available.

You should also do the same for

#if _OPENMP
#include 
#endif

Note that this will also make your loops sequential when OpenMP is not
available.

On Mon, 7 Jun 2021 at 21:52, Konrad Krämer via R-package-devel
 wrote:
>
> Dear all,
> I have a problem regarding OpenMP on Mac OS. Recently I submitted my package 
> to CRAN (https://cran.r-project.org/web/packages/paropt/index.html). However, 
> there seems to be a problem with 'fopenmp' on Mac OS using clang++. I have 
> read many forums regarding the topic. Thus, I know that there is no support 
> for OpenMp on Mac OS (at least using the default clang compiler).
> The error was: clang: error: unsupported option '-fopenmp'
> Is it possible to detect the operating system and set according to this the 
> compile flags and use also a sequentiell version of the code?
> Or is there a better way to cope with this problem?
> Many thanks in advance for your help.
> Regards,
> Konrad
> [[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] Finding dependencies (Was: problem with submitting to CRAN (windows))

[Hugh Parsonage]

First I confirmed "gtools" %in% tools::package_dependencies("mvSLOUCH")[[1]]

then

lapply(tools::package_dependencies("mvSLOUCH"),
tools::package_dependencies, recursive = TRUE)

was sufficient to identify the chain.

On Wed, 2 Jun 2021 at 21:08, Duncan Murdoch  wrote:
>
> On 02/06/2021 6:57 a.m., Hugh Parsonage wrote:
> > mvSLOUCH <--- TreeSim <-- phytools <-- gtools
> >
> > On Wed, 2 Jun 2021 at 20:35, Krzysztof Bartoszek  
> > wrote:
> >>
> >> Thank you. The only problem, as I wrote, is that neither my package, 
> >> mvSLOUCH, nor any package that mvSLOUCH imports from depends on gtools.
> >> In particular nowhere in mvSLOUCH do I use any call to anything from 
> >> gtools nor to any function called combinations.
>
> Hugh, could you describe how you found this dependency chain?  This sort
> of problem comes up now and then, and I've always used a slow manual
> search.  It would be nice to know if there's an automatic way to answer
> the question
>
> "Why does package xxx appear to require yyy?"
>
> Duncan Murdoch

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

Re: [R-pkg-devel] problem with submitting to CRAN (windows)

[Hugh Parsonage]

mvSLOUCH <--- TreeSim <-- phytools <-- gtools

On Wed, 2 Jun 2021 at 20:35, Krzysztof Bartoszek  wrote:
>
> Thank you. The only problem, as I wrote, is that neither my package, 
> mvSLOUCH, nor any package that mvSLOUCH imports from depends on gtools.
> In particular nowhere in mvSLOUCH do I use any call to anything from gtools 
> nor to any function called combinations.
>
> Best wishes
> Krzysztof Bartoszek
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, June 2, 2021 10:25 AM, Hugh Parsonage 
>  wrote:
>
> > Probably a consequence of gtools having build errors
> > (https://cran.r-project.org/web/checks/check_results_gtools.html)
> >
> > I'd recommend reconsidering use of the package until the problems are
> > resolved. In the meantime, put gtools is Suggests for the use of
> > combinations(). Note the base R functions choose and combn that might
> > be sufficient (and certainly more available).
> >
> > On Wed, 2 Jun 2021 at 20:17, Krzysztof Bartoszek krz...@protonmail.ch wrote:
> >
> > > Dear all,
> > > I am trying to submit an update of my mvSLOUCH package to CRAN an am 
> > > getting the following problem from the automatic pretest:
> > > Dear maintainer,
> > > package mvSLOUCH_2.6.5.tar.gz does not pass (yesterday and today) the 
> > > incoming checks automatically, please see the following pre-tests:
> > > Windows: 
> > > https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Windows/00check.log
> > > Status: 1 ERROR
> > > Debian: 
> > > https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Debian/00check.log
> > > Status: OK
> > > The windows error in 
> > > https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Windows/00install.out
> > > is
> > > ** byte-compile and prepare package for lazy loading
> > > Error: object 'combinations' is not exported by 'namespace:gtools'
> > > Execution halted
> > > ERROR: lazy loading failed for package 'mvSLOUCH'
> > > Interestingly when I today submited to winbuilder (devel) no such issues 
> > > are raised (yesterday the same issue was raised by winbuilder-devel):
> > > https://win-builder.r-project.org/Ou1tDLkY8HVB/
> > > It feels a bit strange that this package dependency fails only for 
> > > Windows, especially as neither mvSLOUCH nor any of the packages it 
> > > imports from depend on gtools.
> > > I would be very grateful for assistance.
> > > Best wishes
> > > Krzysztof Bartoszek
> > > Sent with ProtonMail Secure Email.
> > > [[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] problem with submitting to CRAN (windows)

[Hugh Parsonage]

Probably a consequence of gtools having build errors
(https://cran.r-project.org/web/checks/check_results_gtools.html)

I'd recommend reconsidering use of the package until the problems are
resolved.  In the meantime, put gtools is Suggests for the use of
combinations().  Note the base R functions choose and combn that might
be sufficient (and certainly more available).

On Wed, 2 Jun 2021 at 20:17, Krzysztof Bartoszek  wrote:
>
> Dear all,
> I am trying to submit an update of my mvSLOUCH package to CRAN an am getting 
> the following problem from the automatic pretest:
> Dear maintainer,
>
> package mvSLOUCH_2.6.5.tar.gz does not pass (yesterday and today) the 
> incoming checks automatically, please see the following pre-tests:
> Windows: 
> 
> Status: 1 ERROR
> Debian: 
> 
> Status: OK
>
> The windows error in 
> https://win-builder.r-project.org/incoming_pretest/mvSLOUCH_2.6.5_20210602_103000/Windows/00install.out
> is
> ** byte-compile and prepare package for lazy loading
> Error: object 'combinations' is not exported by 'namespace:gtools'
> Execution halted
> ERROR: lazy loading failed for package 'mvSLOUCH'
>
> Interestingly when I today submited to winbuilder (devel) no such issues are 
> raised (yesterday the same issue was raised by winbuilder-devel):
> https://win-builder.r-project.org/Ou1tDLkY8HVB/
>
> It feels a bit strange that this package dependency fails only for Windows, 
> especially as neither mvSLOUCH nor any of the packages it imports from depend 
> on gtools.
>
> I would be very grateful for assistance.
>
> Best wishes
> Krzysztof Bartoszek
>
> Sent with ProtonMail Secure Email.
> [[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] \donttest{} and writing outputs to tempdir()

[Hugh Parsonage]

Are you able to provide a link to your package?  It's a bit hard to
guess what's causing your examples etc to have these problems.

On Wed, 2 Jun 2021 at 14:40, Danielle Maeser  wrote:
>
> Hello,
>
> I received the following comments from a CRAN maintainer, and I don't
> understand why they were an issue. I'd appreciate any insight you can
> provide.
>
> Danielle
>
>
>
>
>
>
>
> *All your examples are wrapped in \donttest{} and therefore do not
> gettested.Please unwrap the examples if that is feasible and if they can
> beexecuted in < 5 sec for each Rd file or create additionally small
> toyexamples to allow automatic testing.*
>
> I don't think I can unwrap the examples in \donttest{} because they cannot
> be executed in <5 seconds for each Rd file, and the automatic testing of
> toy data is satisfied in the vignettes I provide for each function.
> Therefore, I am not sure what change to make here.
>
>
>
>
> *Please ensure that your functions do not write by default or in
> yourexamples/vignettes/tests in the user's home filespace (including
> thepackage directory and getwd()). This is not allowed by CRAN policies.In
> your examples/vignettes/tests you can write to tempdir().*
>
> Additionally, all of my vignettes write the output of each function to
> tempdir(). Therefore, I am not sure why this is a problem.
> --
> 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

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

[R-pkg-devel] Valgrind warning: invalid size of 4, is it due to a simple overrun?

[Hugh Parsonage]

Hello,

I received a valgrind warning about my package, hutilscpp, from CRAN
(thank you).  I believe I've tracked down and fixed the problem, but I
wasn't able to reproduce the error on rhub (including with
--leak-check=full etc) so I'd like to know if I'm missing something.

The valgrind warning is "Invalid write of size 4" and refers to this
line 
https://github.com/HughParsonage/hutilscpp/blob/508f134b3f388653985eca372ed5f4f8b8eb3471/src/Cwhich_even.c#L43

the context for this line is:

const double * xp = REAL(xx);
for (R_xlen_t i = 0, j = 0; i < N; ++i) {
  int is_even = R_finite(xp[i]) && (fmod(xp[i], 2) == 0);
  ansp[j] = (int)(i + 1);// # < line 43
  j += is_even;
}

where ansp is a pointer to an integer vector whose length is the
number of "even" doubles in xx.  I can see that the problem arises
when the last even number occurs before the end of the vector xx, at
which point j == length(ansp), yet the loop continues.  I've amended
the i < N in the for loop to (i < N && j < n_even) which I believe is
sufficient, but obviously I thought it was ok before.

I'd rather not resubmit only to discover that I've overlooked something else.

As a supplementary question, does the valgrind check depend on the
runtime values in the test suite or does it perform fuzz testing?  In
other words, do I need to add tests to reproduce?

Best,


Hugh.

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

Re: [R-pkg-devel] Problems with too much testing

[Hugh Parsonage]

My 2c is that if a package has actually tested something like that
(say, the ordering of a list's elements), then it is 100% likely that
a script out there depends on that behaviour too.  In other words, the
change is not inconsequential.  R users are in debt to package
developers but I think it behoves us to take special care not to
underestimate the work involved when a package's behaviour changes.

On Fri, 16 Apr 2021 at 20:09, Duncan Murdoch  wrote:
>
> I'm updating the rgl package, and have come across the following problem.
>
> Some packages that depend on rgl and do careful testing are detecting
> inconsequential changes.  A typical case is the nat package, which has
> extensive testing, some of which comes down to checking results from rgl
> functions using testthat::is_equal().  I rewrote some parts of the rgl
> code, and so some rgl objects differ in irrelevant ways.  For example,
>
>obj <- list(x = NULL)
>
> differs from
>
>obj <- list()
>obj[["x"]] <- NULL
>
> (the first is length 1, the second ends up with no entries).  All tests
> in rgl would be like
>
>if (is.null(obj[["x"]])) ...
>
> so the tests evaluate the same, but testthat::is_equal() doesn't return
> TRUE, because the objects are different.
>
> Another example would be
>
>obj <- list()
>obj$a <- 1
>obj$b <- 2
>
> which differs from
>
>obj <- list()
>obj$b <- 2
>obj$a <- 1
>
> in the order of the components, but since rgl always accessed them by
> name, that makes no difference.
>
> So what I'm looking for is a strategy to hide internal implementation
> details.  (I'm using a compare_proxy() method now which standardizes the
> objects, but that seems very specific to testthat version 3.  I'd like
> ideas for something more robust.)
>
> Duncan Murdoch
>
> __
> 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 on r-oldrel-macos-x86_64

[Hugh Parsonage]

If you click on WARN in the table on your check results page (i.e. if
you go to 

) you will see in the first line:

* using R version 3.6.2 (2019-12-12)

Hope that helps.

On Sun, 25 Oct 2020 at 21:10, Helmut Schütz  wrote:
>
> Dear all,
>
> we faced a warning on r-oldrel-macos-x86_64:
> https://cran.r-project.org/web/checks/check_results_PowerTOST.html
> I'm not concerned about "Pandoc (>= 1.12.3) and/or pandoc-citeproc not
> available" in the first 5 vignettes since there were no problem in the
> previous releases.
> However I found this on stackoverflow:
> https://stackoverflow.com/questions/50789125/how-to-get-an-rmarkdown-vignette-for-r-package-to-escape-cran-warnings-on-solari
> RolandAsc commented:
> "In my understanding you can only see this warning if there is an error
> (either because warnings are being converted to errors or because there
> is another subsequent error), else it just doesn't come through. This is
> not an answer but maybe an explanation."
> Seems to be correct. In my code a data.frame is assigned with a column
> "foo" and _without_ stringsAsFactors = FALSE. Later a function is called
> which requires "foo" as character.
> The default stringsAsFactors was changed to FALSE in R4.0.0. Hence, my
> question: How "old" is the old releaseon CRAN's test machines/ macos?
> oldrel on windows is OK.
>
> What shall we do?
> Re-submit with the same release-number(either add stringsAsFactors =
> FALSE or call the function with as.character("foo")with an explanation?
>
> Helmut
>
> --
> Ing. Helmut Schütz
> BEBAC – Consultancy Services for
> Bioequivalence and Bioavailability Studies
> Neubaugasse 36/11
> 1070 Vienna, Austria
> E helmut.schu...@bebac.at
> W https://bebac.at/
> F https://forum.bebac.at/
>
> __
> 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] details of CRAN's r-devel-linux-x86_64-debian-clang

[Hugh Parsonage]

_R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_

not

 R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_

(i.e. you seem to have dropped the initial underscore)?

On Sun, 25 Oct 2020 at 20:01, Jan Gorecki  wrote:
>
> Dear community,
>
> I am getting an error on CRAN on r-devel-linux-x86_64-debian-clang machine 
> only:
>
>   S3 method lookup found 'as.x.y' on search path
>
> I know how to fix the error. I am interested to know how to reproduce
> this error locally. I tried combination of
> R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_
> and
> _R_S3_METHOD_LOOKUP_REPORT_SEARCH_PATH_USES_
> but didn't manage to reproduce the error.
>
> What is the proper way to set up checks to detect these kinds of issues?
>
> Moreover, I kindly request to provide "details" for other CRAN
> machines in flavors page:
> https://cran.r-project.org/web/checks/check_flavors.html
> "Details" are currently provided only for 3 machines there. Having
> "details" for r-devel-linux-x86_64-debian-clang would probably answer
> my question without involving readers of this mailing list.
>
> Best Regards,
> Jan Gorecki
>
> __
> 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] Licenses

[Hugh Parsonage]

It’s necessary but not sufficient to use a licence from license.db

On Fri, 23 Oct 2020 at 3:12 am, Duncan Murdoch 
wrote:

> On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
> >
> >
> >> On Oct 22, 2020, at 11:19 AM, Marc Schwartz 
> wrote:
> >>
> >> On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes <
> kevin.r.coom...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I am developing a package and getting a NOTE from R CMD check about
> licenses and ultimate dependencies on a restrictive license, which I can't
> figure out how to fix.
> >>>
> >>> My package imports flowCore, which has an Artistic-2.0 license.
> >>> But flowCore imports cytolib, which has a license from the Fred
> Hutchinson Cancer Center that prohibits commercial use.
> >>>
> >>> I tried using the same license as flowCore, but still get the NOTE.
> Does anyone know which licenses can be used to be compatible with the Fred
> Hutch license? Or can I just do what flowCore apparently does and ignore
> the NOTE?
> >>>
> >>> Thanks,
> >>>   Kevin
> >>
> >>
> >> Hi Kevin,
> >>
> >> I have not looked at BioC's licensing requirements, but presumably,
> they are ok with the non-commercial use restrictions placed on users of
> cytolib, thus also on flowCore.
> >>
> >> If you want your package to be on CRAN, those restrictions on users are
> not allowed by CRAN's policy:
> >>
> >> https://cran.r-project.org/web/packages/policies.html
> >>
> >> "Such packages are not permitted to require (e.g., by specifying in
> ‘Depends’, ‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a
> package or external software which restricts users or usage."
> >>
> >>
> >> Thus, you would seem to need to make a decision on hosting your package
> on CRAN, but without the need to import from flowCore/cytolib, or consider
> hosting your package on BioC, with the attendant restrictions on commercial
> use.
> >>
> >> Regards,
> >>
> >> Marc Schwartz
> >
> >
> > Well
> >
> > Now that I look at:
> >
> >https://svn.r-project.org/R/trunk/share/licenses/license.db
> >
> > there are a few licenses listed there that do place restrictions on
> commercial use.
> >
> > These include some Creative Commons Non-Commercial use variants and the
> ACM license.
> >
> > Is the license DB file out of date, or is there an apparent conflict
> with the CRAN policy that I quoted above?
> >
> > Anyone with an ability to comment?
>
> Presumably CRAN would not accept the non-FOSS licenses that are listed
> in license.db, but R could still do computations on them, as described
> in ?library in the "Licenses" section.
>
> 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

[R-pkg-devel] Tracking down cause of UBSAN error

[Hugh Parsonage]

Hello,

I am getting a UBSAN-clang failure on my package hutilscpp
(). However I cannot
reproduce the error on rhub, nor can I see an obvious problem with the
code.  (Though obviously there is something wrong.)

The testthat.Rout log from CRAN reads (relevantly):

> test_check("hutilscpp")
/data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25:
runtime error: nan is outside the range of representable values of
type 'long'
#0 0x7f817412275e in long Rcpp::internal::caster(double) 
/data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25
#1 0x7f817412275e in long
Rcpp::internal::primitive_as(SEXPREC*)
/data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/as.h:39:21
#2 0x7f81740f9a50 in long Rcpp::internal::as(SEXPREC*,
Rcpp::traits::r_type_primitive_tag)
/data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/as.h:44:20
#3 0x7f81740f9a50 in long Rcpp::as(SEXPREC*)
/data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/as.h:152:16
#4 0x7f81740f9a50 in Rcpp::InputParameter::operator long()
/data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/InputParameter.h:34:38
#5 0x7f81740f9a50 in _hutilscpp_do_which_first__
/data/gannet/ripley/R/packages/tests-clang-SAN/hutilscpp/src/RcppExports.cpp:647:65
#6 0x6e187d in R_doDotCall
/data/gannet/ripley/R/svn/R-devel/src/main/dotcode.c:629:17
#7 0x844c13 in bcEval
/data/gannet/ripley/R/svn/R-devel/src/main/eval.c:7677:21
#8 0x828ab9 in Rf_eval
/data/gannet/ripley/R/svn/R-devel/src/main/eval.c:727:8

The RcppExports.cpp 647:65 refers to the commented line starting
"rcpp_result_gen" below
// do_which_first__
R_xlen_t do_which_first__(SEXP x, int op, SEXP y, R_xlen_t nx,
R_xlen_t ny, int y1i, int y2i, double y1d, double y2d);
RcppExport SEXP _hutilscpp_do_which_first__(SEXP xSEXP, SEXP opSEXP,
SEXP ySEXP, SEXP nxSEXP, SEXP nySEXP, SEXP y1iSEXP, SEXP y2iSEXP, SEXP
y1dSEXP, SEXP y2dSEXP) {
BEGIN_RCPP
Rcpp::RObject rcpp_result_gen;
Rcpp::traits::input_parameter< SEXP >::type x(xSEXP);
Rcpp::traits::input_parameter< int >::type op(opSEXP);
Rcpp::traits::input_parameter< SEXP >::type y(ySEXP);
Rcpp::traits::input_parameter< R_xlen_t >::type nx(nxSEXP);
Rcpp::traits::input_parameter< R_xlen_t >::type ny(nySEXP);
Rcpp::traits::input_parameter< int >::type y1i(y1iSEXP);
Rcpp::traits::input_parameter< int >::type y2i(y2iSEXP);
Rcpp::traits::input_parameter< double >::type y1d(y1dSEXP);
Rcpp::traits::input_parameter< double >::type y2d(y2dSEXP);
rcpp_result_gen = Rcpp::wrap(do_which_first__(x, op, y, nx, ny, y1i,
y2i, y1d, y2d)); // line 647, column 65 is between nx and ny
return rcpp_result_gen;
END_RCPP
}

The ny R_xlen_t value is used in a switch statement in the C++ code.
My attempt to fix this code was to limit the values of ny to 1, 2, or
3 before being passed to do_which_first__().  However, since I was not
able to reproduce the UBSAN error on rhub I'm not sure if this fix is
successful.  I would prefer not to submit a package before being
completely sure the UBSAN error has been resolved.


Thank you for any help,


Hugh.

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

Re: [R-pkg-devel] installed package size problem on Mac but not Linux nor Windows

[Hugh Parsonage]

One of your vignettes is a 52-page pdf. It may be more suitable to provide
a link to it rather than distributing it with the package, or distribute an
excerpt.

Some the images in the PDFs could be PDFs themselves, or be pngs with lower
resolution.

On Tue, 22 Sep 2020 at 5:04 pm, Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

> Hello, All:
>
>
>   R CMD check of "https://github.com/sbgraves237/Ecfun; on Mac
> produces
> the following NOTE:
>
>
> * checking installed package size ... NOTE
>installed size is  5.9Mb
>sub-directories of 1Mb or more:
>  doc   5.2Mb
>
>
>   It doesn't do that with Travis CI[1] nor on a Windows 10
> computer I
> have.  "Writing R Extensions" suggested using "--compact-vignettes" with
> qpdf.  That changed nothing.
>
>
>   Suggestions?
>   Will this be problem on CRAN?
>   Thanks,
>   Spencer
>
>
> [1]
> https://travis-ci.org/github/sbgraves237/Ecfun/builds/727906753
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] package CatDataAnalysis

[Hugh Parsonage]

If you’re not the author of the data, you can’t submit it as such. The
website has a copyright message on it which, while not definitive, doesn’t
suggest the use you’re proposing would be allowed.

Bear in mind that you may expose CRAN not just yourself to liability if you
try to conceal true authorship.

I’d recommend asking the author of that website for permission. Either he
says that’s fine in which case you have permission, or he doesn’t and you
dodge a bullet.


On Mon, 29 Jun 2020 at 2:45 am, Charles Geyer  wrote:

> Actually the wooldridge package does not seem to satisfy any of the
> specific requests CRAN asked me for.  I have checked several other CRAN
> packages for textbooks and they don't seem to satisfy those requirements
> either.  So this seems to be a new idea from CRAN.
>
> On Sun, Jun 28, 2020 at 11:32 AM Neal Fultz  wrote:
>
> > I'm not sure exactly what cran is asking for, but the wooldridge
> > package is a good example of a text book data set package, so maybe
> > you can use the same format they did.
> >
> > https://cran.r-project.org/web/packages/wooldridge/index.html
> >
> > Best,
> >
> > Neal
> >
> > On Sun, Jun 28, 2020 at 9:08 AM Charles Geyer 
> > wrote:
> > >
> > > I have a package that has the datasets for Categorical Data Analysis by
> > > Agresti that do not appear in the book.  The whole package is a github
> > repo
> > > https://github.com/cjgeyer/CatDataAnalysis.  All of the data were
> > > translated mechanically using the R script foo.R included in the repo
> > (but
> > > not in the package) from Agresti's web site
> > > http://www.stat.ufl.edu/~aa/cda/data.html.
> > >
> > > This package seems to be a useful service to students and teachers.
> The
> > > data
> > > are much simpler to use with this package than trying to get the data
> > from
> > > Agresti's web page (foo.R has 277 lines of code).
> > >
> > > When I submitted the package to CRAN, I got the following response.
> > >
> > > > The Description field of the DESCRIPTION file is intended to be a
> (one
> > > > paragraph) description of what the package does and why it may be
> > > > useful. Please elaborate. Tell the users what the datasets are about
> > and
> > > > what they contain so they can use them even when they haven't read
> your
> > > > book.
> > >
> > > > Please fix and resubmit, and document what was changed in the
> > submission
> > > > comments.
> > >
> > > In an alternate universe without copyright law this seems a reasonable
> > > request.  In this universe it seems to be asking for trouble.  I know
> > about
> > > fair use, but I am not a lawyer and do not want to walk the borderline
> > > between fair use and copyright violation.
> > >
> > > The package as it is seems OK because it comes from the author's public
> > web
> > > site and these data were never in the book.
> > >
> > > Please note that I made Alan Agresti (with his acquiescence) the author
> > of
> > > the package because it is his book and his data, but I (or rather
> foo.R)
> > > did all the work.
> > >
> > > I replied to cran.r-project.org, but that was apparently sent to
> > /dev/null.
> > >
> > > This book is IMHO the authoritative textbook on the subject.  Amazon
> > sales
> > > rank agrees.  The book is used for many courses.  So this package would
> > be
> > > very helpful as is to many students and teachers.
> > >
> > > So what to do?  Is there any way to get this package on CRAN?
> > >
> > > --
> > > Charles Geyer
> > > Professor, School of Statistics
> > > Resident Fellow, Minnesota Center for Philosophy of Science
> > > University of Minnesota
> > > char...@stat.umn.edu
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > __
> > > R-package-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
>
> --
> Charles Geyer
> Professor, School of Statistics
> Resident Fellow, Minnesota Center for Philosophy of Science
> University of Minnesota
> char...@stat.umn.edu
>
> [[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] Rbuildignore a file type from a top level directory only

[Hugh Parsonage]

Perhaps

^[^/]+\.R$

On Sun, 21 Jun 2020 at 22:31, Jan Gorecki  wrote:
>
> Hi R developers,
>
> What is the proper way to define an entry in .Rbuildignore file to
> exclude *.R files from a top level directory of R package?
> Using ^.*\.R$ excludes every R script, including those in sub-directories.
>
> Thank you,
> Jan Gorecki
>
> __
> 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] Including fst in inst/extdata

[Hugh Parsonage]

For reference, the file mode was not set as executable; however,
`file` was reporting a particular file (only one of several .fst
files) as a  DOS executable (COM, 0x8C-variant), which according to
comments in the code of "file" appears to be a common false positive.
Converting the character columns to ASCII and changing the order of
the columns changed the output of file to 'data'.  Dropping a column
also prevented the false identification.

On Mon, 27 Apr 2020 at 22:12, Dirk Eddelbuettel  wrote:
>
>
> Hugh,
>
> On 27 April 2020 at 16:02, Hugh Parsonage wrote:
> | I would like to include some fst files (produced by fst::write_fst) in
> | inst/extdata so that (a) users can update them between releases and
> | (b) to take advantage of fst's benefits. However, when I do this and
>
> Good idea, it is a very capable format!
>
> | run R CMD check I get the warning "Found the following executable
> | file: "inst/extdata/file.fst"
>
> That refers to the file modes which will be (in octal notation) 775 or 755.
>
> | I'm not sure whether this qualifies as a "rare false positive" as WRE
> | mentions, but if it isn't is there a way to include fst files in a
> | package without raising a warning?
>
> Turn the execute bit off i.e. make them 664 or 644 and warning goes away.
>
> In short, this has nothing to do with the .fst extension or content.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[R-pkg-devel] Including fst in inst/extdata

[Hugh Parsonage]

I would like to include some fst files (produced by fst::write_fst) in
inst/extdata so that (a) users can update them between releases and
(b) to take advantage of fst's benefits. However, when I do this and
run R CMD check I get the warning "Found the following executable
file: "inst/extdata/file.fst"
I'm not sure whether this qualifies as a "rare false positive" as WRE
mentions, but if it isn't is there a way to include fst files in a
package without raising a warning?


Hugh Parsonage.

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

Re: [R-pkg-devel] note about dependency on archived package

[Hugh Parsonage]

The note is there to remind CRAN that the package previously had problems
serious enough to warrant archival. Since you have solved the problem, you
do not need to do anything else in your submission.

On Wed, 18 Mar 2020 at 7:23 am, Gianmarco Alberti <
gianmarcoalbe...@gmail.com> wrote:

> Hello,
>
> After checking my package with win builder, I got 1 note that I seem to
> not fully understand:
>
> CRAN repository db overrides:
>  X-CRAN-Comment: Archived on 2020-03-17 as depends on archived package
>'spatialEco'.
>
> Do you have any suggestion?
> There is not reference to that package in my NAMESPACE, nor it is listed
> among the dependencies.
>
> Full log here:
> https://win-builder.r-project.org/98x9zsbaHsp1/00check.log
>
> Best
> Gm
>
> 
> Dr Gianmarco Alberti (PhD Udine)
> Lecturer in Spatial Forensics
> Coordinator of the BA course in Criminology
> Department of Criminology
> Faculty for Social Wellbeing
> Room 332, Humanities B (FEMA)
> University of Malta, Msida, Malta (Europe) - MSD 2080
> tel +356 2340 3718
>
> Academic profiles
> https://www.researchgate.net/profile/Gianmarco_Alberti4
> https://malta.academia.edu/GianmarcoAlberti
>
> Google Scholar profile
> https://scholar.google.com/citations?user=tFrJKQ0J=en
>
> Correspondence Analysis website
> http://cainarchaeology.weebly.com/
>
> R packages on CRAN:
> CAinterprTools
> https://cran.r-project.org/web/packages/CAinterprTools/index.html
>
> GmAMisc
> https://cran.r-project.org/package=GmAMisc
>
> movecost
> https://cran.r-project.org/web/packages/movecost/index.html
> 
>
> [[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] GitHub problems

[Hugh Parsonage]

You published your token. You should revoke it.

You probably don’t have the right permissions associated with git.



On Sat, 14 Mar 2020 at 2:14 pm, Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:

> Hello, All:
>
>
>What do you suggest Jim Ramsay and I do to migrate the fda
> package to GitHub?
>
>
>Jim successfully created an empty repository:
>
>
> https://github.com/JamesRamsay5/fda
>
>
>He told me he had officially made me a "contributor".  I did:
>
>
> git clone https://@github.com/JamesRamsay5/fda
> Cloning into 'fda'...
> warning: You appear to have cloned an empty repository.
> Checking connectivity... done.
>
>
>Then I copied files into this directory, did "git add" and "git
> commit".
>
>
>Then I did "git push", and it wouldn't let me:
>
>
> SpenceravessMBP:fda sbgraves$ git push
> remote: Permission to JamesRamsay5/fda.git denied to sbgraves237.
> fatal: unable to access
> '
> https://892da70262d9a4faa857b8602145414d6b210...@github.com/JamesRamsay5/fda/':
>
> The requested URL returned error: 403
>
>
>Suggestions?
>Thanks,
>Spencer Graves
>
> __
> 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] win-builder down?

[Hugh Parsonage]

Are CRAN staff located in Europe only? Is there a case to have a limited
staff across multiple timezones with a rolling roster? Obviously if
something is reported it’s best if it can be actioned immediately.

On Sun, 1 Mar 2020 at 12:29 pm, Henrik Bengtsson 
wrote:

> FYI, in past when queues got stuck, Uwe told me it's often a package that
> launches an external process (e.g. java.exe) that doesn't terminate and
> prevents R CMD check from terminating/timing out. He got watchdogs to kill
> such stray events but there are false negatives.
>
> A couple of weeks ago I proposed to add a placeholder for the package
> currently tested and Uwe said he might look into it, e.g.
>
> $ curl ftp://win-builder.r-project.org/R-devel/
> 02-05-20  03:10PM  2359737 bayestestR_0.5.2.tar.gz
> 02-05-20  11:42AM  0
> some.pkg_0.0.1.tar.gz-PROCESSING
> 02-05-20  11:56AM  5053108 catdata_1.2.2.tar.gz
>
> Even if it doesn't solve the problem, it'll communicate to "us" that
> something is stuck and what it is.
>
> Anyway, we can help out by reporting (like this) when a queue look stuck.
> Then I think it helps to clarify which queue/builder is stuck.
>
> Henrik
>
>
> On Sat, Feb 29, 2020, 15:13 Rolf Turner  wrote:
>
> >
> > On 1/03/20 11:44 am, Max Kuhn wrote:
> >
> > > On February 29, 2020 at 5:06:35 PM, Rolf Turner (
> r.tur...@auckland.ac.nz
> > > ) wrote:
> > >>
> > >> On 1/03/20 2:23 am, Hadley Wickham wrote:
> > >>
> > >> > Is it down again? I'm seeing the same problem again.
> > >> > Hadley
> > >> >
> > >> > On Sat, Feb 22, 2020 at 2:41 PM Hadley Wickham  > > wrote:
> > >> >>
> > >> >> Hi all,
> > >> >>
> > >> >> Is win-builder down? I submitted a couple of packages >24 hours
> ago,
> > >> >> and haven't heard back.
> > >> >>
> > >> >> Hadley
> > >>
> > >> Me too. Submitted a package about 18 hours ago, and so far not a
> > >> sausage. Although it's churlish to complain, one gets used to a
> service
> > >> that has been provided and gets annoyed when the service disappears.
> > >
> > > True, but it would be unnecessary if `R CMD check —as-cran` did exactly
> > > the same thing as win-builder (as well as the extra, informal checks
> > > done on a first submission).
> >
> > Not entirely true.  The package that I am currently trying to get built
> > is for use by some consulting clients and is not (yet) for public
> > release.  So I can't/don't submit it to CRAN so as to get a Windoze
> > binary that way.
> >
> > cheers,
> >
> > Rolf
> >
> > P.S. I note that the winbuilder web site says:
> >
> > >  Please do not upload Bioconductor packages or CRAN packages.
> > >  Both Bioconductor and CRAN do have build systems 
> >
> > I presume that this exhortation is of some antiquity and is "no longer
> > operative".
> >
> > R.
> >
> > --
> > Honorary Research Fellow
> > Department of Statistics
> > University of Auckland
> > Phone: +64-9-373-7599 ext. 88276
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[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] function name conflict problem

[Hugh Parsonage]

Package karon is the problem. Is that package in your depends or imports?
Does that package use Depends?

On Wed, 5 Feb 2020 at 8:24 am,  wrote:

> In trying to develop a package to be submitted to CRAN, when I do Install
> and Reload or devtools::check(), I get the warning:
>
>
>
> Warning: replacing previous import 'ellipse::pairs' by 'graphics::pairs'
> when loading 'karon'
>
> Warning: replacing previous import 'MVN::mvn' by 'mgcv::mvn' when loading
> 'karon'
>
>
>
> I need one function each from the packages ellipse and mgcv (I do not need
> pairs from ellipse and mvn from mgcv).  To restrict to the function that I
> need, I have used the commands
>
> @importFrom  ellipse  ellipse
>
> @importFrom  mgcv  in.out
>
>
>
> NAMESPACE includes the lines
>
> importFrom(ellipse,ellipse)
>
> importFrom(mgcv,in.out)
>
>
>
> However, DESCRIPTION does not restrict the functions imported from ellipse
> and mgcv; it has
>
> Imports: MVN, MASS, scatterplot3d, rgl, mgcv, randomForest, rpart,
> partykit,
> Formula, ellipse,..
>
>
>
> Do these warnings need to be solved before submitting to CRAN?
>
> Is it necessary to edit DESCRIPTION  If so, what should be done?
>
> Is there some other potential solution?
>
>
>
> Thanks!
>
>
> [[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 while checking if Pandoc is available

[Hugh Parsonage]

Change | to ||

On Fri, 6 Dec 2019 at 11:08 pm, Pere Millan Martinez 
wrote:

> Yesterday the publication of the new brinton package war archived
> (https://cran.r-project.org/web/packages/brinton/index.html) because the
> following line produces the following error:
>
> if(rmarkdown::pandoc_available() == FALSE | rmarkdown::pandoc_version()
> < "1.12.3") {stop("'brinton' requires Pandoc v < 1.12.3
> (https://pandoc.org/)")}
>
> Error in if (rmarkdown::pandoc_available() == FALSE |
> rmarkdown::pandoc_version() <:
> argument is of length zero
>
> The checks of the knitr package produce similar errors
> (https://cran.r-hub.io/web/checks/check_results_knitr.html) but knitr is
> available in CRAN (furtunatelly).
> Also, I have been punished by prof. Brian Ripley so I can not resubmit
> the package until January.
>
> Do you have any clue about how to fix this? Does to punish rookies have
> sense in this case?
>
> Thanks in advance,
> -Pere Millán
>
>
>
> On 10/11/2019 11:31, Pere Millan Martinez wrote:
> > Hello,
> >
> > I'm trying to submit a first version of the brinton package but the
> > CRAN-pretest on Debian produces the following NOTE:
> >
> > Check: for detritus in the temp directory, Result: NOTE
> >Found the following files/directories  :
> >  ‘calibre_4.2.0_tmp_BPGKxL’ ‘calibre_4.2.0_tmp_D8BXMj’
> >  ‘calibre_4.2.0_tmp_M8RU75’ ‘calibre_4.2.0_tmp_TipWj0’
> >  ‘calibre_4.2.0_tmp_f0mVQS’ ‘calibre_4.2.0_tmp_fHEPce’
> >  ‘runtime-hornik’
> >
> > The 'brinton' package stores files in the temporary folder (which I
> > think is ok) but I can not figure out
> > the relationship between the files that are stored with
> > 'calibre_4.2.0'. Is this note a false positive or this
> > is something that I should fix prior to submit?
> >
> > Thank you,
> > Pere Millán-Martínez
>
> [[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] Issue with Biostrings-- can't find the base rgb function on r-devel

[Hugh Parsonage]

rgb is from package grDevices not package base.

On Thu, 5 Dec 2019 at 2:48 pm, Dalgleish, James (NIH/NCI) [V] via
R-package-devel  wrote:

> Question:
>
> NIPTeR is experiencing new warnings when loading Biostrings. I have the
> exact same warnings with my package, CNVScope.
>
> It seems a little odd that the base function rgb cannot be found. What can
> cause a base package to not be found? I can't replicate this issue on
> either of my linux or windows machines or on winbuilder.
>
> I have already asked the Bioconductor community, but didn't get a response
> (https://support.bioconductor.org/p/126878/).
>
> Thanks,
> James Dalgleish
> Maintainer, CNVScope
> NIH/NCI
> Source: https://cran.r-project.org/web/checks/check_results_NIPTeR.html
> Check Details
> Version: 1.0.2
> Check: whether the package can be unloaded cleanly
> Result: WARN
> Error: package or namespace load failed for 'NIPTeR':
>  .onLoad failed in loadNamespace() for 'Biostrings', details:
>  call: rgb(1, 1, 1)
>  error: could not find function "rgb"
> Execution halted
> Flavor: r-devel-linux-x86_64-debian-clang
>
> Version: 1.0.2
> Check: whether the namespace can be loaded with stated dependencies
> Result: WARN
> Error: .onLoad failed in loadNamespace() for 'Biostrings', details:
>  call: rgb(1, 1, 1)
>  error: could not find function "rgb"
> Execution halted
>
> A namespace must be able to be loaded with just the base namespace
> loaded: otherwise if the namespace gets loaded by a saved object, the
> session will be unable to start.
>
> Probably some imports need to be declared in the NAMESPACE file.
> Flavor: r-devel-linux-x86_64-debian-clang
>
> Version: 1.0.2
> Check: dependencies in R code
> Result: NOTE
> Error: package or namespace load failed for 'NIPTeR':
>  .onLoad failed in loadNamespace() for 'Biostrings', details:
>  call: rgb(1, 1, 1)
>  error: could not find function "rgb"
> Call sequence:
> 6: stop(msg, call. = FALSE, domain = NA)
> 5: value[[3L]](cond)
> 4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 3: tryCatchList(expr, classes, parentenv, handlers)
> 2: tryCatch({
>  attr(package, "LibPath") <- which.lib.loc
>  ns <- loadNamespace(package, lib.loc)
>  env <- attachNamespace(ns, pos = pos, deps, exclude, include.only)
>  }, error = function(e) {
>  P <- if (!is.null(cc <- conditionCall(e)))
>  paste(" in", deparse(cc)[1L])
>  else ""
>  msg <- gettextf("package or namespace load failed for %s%s:\n %s",
>  sQuote(package), P, conditionMessage(e))
>  if (logical.return)
>  message(paste("Error:", msg), domain = NA)
>  else stop(msg, call. = FALSE, domain = NA)
>  })
> 1: library(package, lib.loc = lib.loc, character.only = T
> Execution halted
> Flavor: r-devel-linux-x86_64-debian-clang
>
> Version: 1.0.2
> Check: R code for possible problems
> Result: NOTE
> Error: .onLoad failed in loadNamespace() for 'Biostrings', details:
>  call: rgb(1, 1, 1)
>  error: could not find function "rgb"
> Execution halted
> Flavor: r-devel-linux-x86_64-debian-clang
>
>
> [[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] roxygen2 7.0.1 backslash escape error

[Hugh Parsonage]

You could (a) install the updated roxygen from github and rebuild the man/
files ; (b) manually edit the Rd files without using roxygen ; or (c)
remove the examples until you can apply the fix.

On Sun, 1 Dec 2019 at 1:26 am, Yoni  wrote:

> I received a message from CRAN yesterday stating my package is erroring on
> all the systems all of a sudden.
>
> https://cran.r-project.org/web/checks/check_results_texPreview.html
>
> After some investigation the root of the errors looks like it came from the
> new release of roxygen2 (7.0.1).
>
> https://github.com/r-lib/roxygen2/issues/990
>
> Is there anything I can do in the interim to fix this problem since I do
> not know when this apparent bug fix will be pushed to CRAN, relieving my
> errors in the documentation builds, which could be beyond the warning
> period (2019-12-13), which the package will be removed from CRAN.
>
> Thank you
>
> [[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] Problem loading package on Windoze --- update.

[Hugh Parsonage]

I wonder if Dropbox “smartsync” is the culprit here. I’ve noticed this
feature can create confusion between programs when Dropbox provides (a link
to) the file when it is opened but only when it recognizes the file is
being opened.

On Tue, 5 Nov 2019 at 7:46 pm, Gábor Csárdi  wrote:

> I am not sure what the first issue was, but the second is an old R
> issue. It happens when you update a package while its package (or
> help) database, the rdb file mentioned in the error message, is open
> in the current R session, i.e. when the package is loaded. The
> database keeps an index to the objects within the database on the
> disk. And when the package is updated, this index will be invalid,
> which R detects as a corrupt rdb file. Restarting R solves the
> problem.
>
> Btw. would R core be interested in a patch for this? I am not sure if
> the situation is fixable, because the package is already loaded, and
> we can't just reload it, but R could give a better error message. For
> the help database, it might make sense to just re-open the database?
>
> Gabor
>
> On Tue, Nov 5, 2019 at 12:53 AM Rolf Turner 
> wrote:
> >
> >
> > I've just heard from another member of the client group and he cannot
> > reproduce the problem.  I.e. he can install both the source package and
> > the binary that I sent out, without error.
> >
> > So the problem seems to be in the system used by that first member of
> > the client group who contacted me.
> >
> > Sorry for the noise.
> >
> > cheers,
> >
> > Rolf
> >
> > On 5/11/19 12:37 PM, Rolf Turner wrote:
> > >
> > > I am developing a package ("ldEst" --- lethal dose estimation) for a
> > > group of consulting clients.  (The package may in the future be
> released
> > > upon the unsuspecting public, but for the moment it has to stay
> > > confidential, sad to say.)
> > >
> > > The clients run Windoze (sad to say).  In the past I have sent them the
> > > source of the package, which they have the facilities to install.  The
> > > latest release of the package however threw an error:
> > >
> > >>> install.packages("C:/Users/abel122/Dropbox/PFR/ldEst_3.0-12.tar.gz",
> > >>> repos = NULL, type = "source")
> > >>
> > >> Error in rawToChar(block[seq_len(ns)]) :   embedded nul in string:
> > >>
> '\037‹\b\0\0\0\0\0\0\003ì}\a`\024ÕÖ0‚\200,HGºN–¶\033&›ì¦\001aÁ\220Є„\022\b\201\020p³;I\006¶„-)T\021P\024\005,
> > >> \002Š" E¤ƒ\024\001)‚"*J\023”&\210R\024\vEšÿ=·LÙ’„÷ž¼ïû~xÏìîÌ'
> > >> Warning in install.packages :
> > >>   installation of package
> > >> ‘C:/Users/abel122/Dropbox/PFR/ldEst_3.0-12.tar.gz’ had non-zero exit
> > >> status
> > >
> > > Flummoxed by this I thought I'd just get Uwe Ligges' win-builder to
> > > build a Windoze binary, and sent that to the clients.  The win-build
> > > went without problem, but when I sent the binary to one of the clients
> > > he got the error:
> > >
> > >> Error: package or namespace load failed for ‘ldEst’ in get(method,
> > >> envir = home):
> > >>  lazy-load database
> > >> 'C:/Users/abel122/Documents/R/win-library/3.6/ldEst/R/ldEst.rdb' is
> > >> corrupt
> > >> In addition: Warning messages:
> > >> 1: In .registerS3method(fin[i, 1], fin[i, 2], fin[i, 3], fin[i, 4],  :
> > >>   restarting interrupted promise evaluation
> > >> 2: In get(method, envir = home) :
> > >>   restarting interrupted promise evaluation
> > >> 3: In get(method, envir = home) : internal error -3 in R_decompress1
> > >
> > > I (sad to say) have no idea what any of this really means.
> > >
> > > The package installs, loads, and  runs just fine on my Ubuntu system,
> > > and builds without error on win-builder.
> > >
> > > Can any suggest a way that I might track down what's causing the
> error(s).
> > >
> > > I realise this is a big ask without your having the package to
> > > experiment on, but I thought that someone clever out there might be
> able
> > > to offer some insight.  E.g. what might I do to find out what is
> > > triggering that "embedded nul in string" business?
> > >
> > > Thanks for any tips.
> >
> > __
> > 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 counts as an API change?

[Hugh Parsonage]

> The approach I take is a major version increment is required if it
> requires an existing unit test to be changed or if it requires a reverse
> dependency to change a unit test.
>
> (With the exception of tests marked explicitly as unstable.)
>
> In my view the test suite is a good way to advertise exactly what
> developers can rely on in minor version upgrades.
>
> On Wed, 25 Sep 2019 at 11:52 pm, David Hugh-Jones <
> davidhughjo...@gmail.com> wrote:
>
>> Hi all,
>>
>> Philosophical question. My package follows semantic versioning (
>> https://semver.org). Incompatible API changes should trigger a major
>> version upgrade. OK, but what counts as an incompatible change to an R
>> API?
>> Suppose my current function signature is
>>
>> foo <- function (a, b, c, d)
>>
>> and the new one is
>>
>> foo <- function (a, b, c, d, e)
>>
>> is that compatible? What if I add an argument, but not at the end:
>>
>> foo <- function (a, b, c, e, d)
>>
>> That would be incompatible if people have been calling the arguments by
>> order rather than by name. But sometimes that is unlikely: I doubt if many
>> people write
>>
>> lm(y ~ x, mydata, z==3, f, na.omit, "qr", FALSE, FALSE, TRUE, TRUE, FALSE)
>>
>> Should I be strict or relaxed about this?
>>
>> Cheers,
>> 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] R package manual failing only on R-devel-linux-x86_64-debian-gcc

[Hugh Parsonage]

Unfortunately this error is caused by a hyperlink straddling a page, so
it’s difficult to solve uniformly.

The LaTeX error message provides a clue as to where the hyperlink might be
(near an \item near a \code) but no exact location.

My advice would be to look where you have hyperlinks (including cross
references) in your documentation and either reword the documentation or
omit hyperlinks until you can produce a full pdf manual. Then, examine
where the hyperlink might have straddled two pages and more surgically
reword that paragraph/list to enable the original intent to be typeset.

The hyperlink may also occur in a bibliography where you may have to make
more drastic omissions or additions in order for compilation to succeed.

On Wed, 19 Jun 2019 at 12:37 am, Zhian Kamvar  wrote:

> Hello,
>
> I'm having a really strange problem that I cannot reproduce locally (Ubuntu
> bionic) or on Rhub. I've run into an issue where the R package manual is
> failing only on this platform with ancient LaTeX runes that I struggle to
> decipher [0]
>
> > * checking PDF version of manual ... WARNING
> > LaTeX errors when creating PDF version.
> > This typically indicates Rd problems.
> > LaTeX errors found:
> > ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level
> than \pd
> > fstartlink.
> > \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
> >   \fi \fi
> > l.186 \item \code
> > !  ==> Fatal error occurred, no output PDF file produced!
> > * checking PDF version of manual without hyperrefs or index ... OK
> > * checking for non-standard things in the check directory ... NOTE
> > Found the following files/directories:
> >   ‘poppr-manual.tex’
> >
> >
> The only information I could find on the error was a question with answers
> that were more questions: https://stackoverflow.com/q/2765229/2752888
>
> Uwe Ligges was kind enough to trigger a second build to see if this was an
> anomaly, but the same incantation appeared again. I've tried building this
> on Rhub debian-devel-gcc, but could not reproduce the error [1] and no
> other platform does this.
>
> Has anyone seen this before?
>
> Thanks,
> Zhian
>
> [0]:
>
> https://win-builder.r-project.org/incoming_pretest/poppr_2.8.3_20190618_151346/Debian/00check.log
> [1]:
>
> https://builder.r-hub.io/status/original/poppr_2.8.3.tar.gz-130d92cdeb2c4c46b94d8cc13b8921b9
>
> [[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] .Rd, LaTeX and Unicode

[Hugh Parsonage]

utf8x is deprecated

https://tex.stackexchange.com/questions/13067/utf8x-vs-utf8-inputenc#13070



On Tue, 18 Jun 2019 at 7:52 pm, Serguei Sokol 
wrote:

> Hi,
>
> I am preparing a package where I would like to use UTF characters in .Rd
> files. When the LaTeX comes to play, I got well known errors e.g.:
> ! Package inputenc Error: Unicode character ∂ (U+2202)
> (inputenc)not set up for use with LaTeX.
>
> It is coherent with what is said on this page
> https://developer.r-project.org/Encodings_and_R.html :
> "Since LaTeX cannot handle Unicode we would have to convert the encoding
> of latex help files or use Lambda (and tell it they were in UTF-8)."
>
> But LaTeX can support UTF8 as shown with this small example:
>
> \documentclass{article}
> \usepackage[mathletters]{ucs}
> \usepackage[utf8x]{inputenc}
>
> \begin{document}
>  The vorticity ω is defined as $ω = ∇ × u$.
> \end{document}
>
> I can compile it with my LaTeX without problem. May be you too?
> So my suggestion would be to place these two lines somewhere in LaTeX
> header generated by R doc system:
> \usepackage[mathletters]{ucs}
> \usepackage[utf8x]{inputenc}
>
> Note "utf8x" and not just "utf8" which is crucial for this example.
> With a hope that it would fix unicode errors from LaTeX.
>
> Best,
> Serguei.
>
> __
> 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] CRAN student assistants

[Hugh Parsonage]

I can't speak for Hadley, but my read of his email was that CRAN has
appointed new staff and while extra staff are clearly justified, it
was unclear how they were appointed and whether they had equal
seniority and authority as existing members. Indeed, the fact they use
titles which are clearly junior would suggest that they may not be.
His citation of the initially rejected packages was, from my read, not
intended to obtain special treatment for those packages, but simply to
make transparent his perception.

His request for additional details about the new appointments did not
strike me as too concerning either. My take was that he was not
wanting to find out more about the individuals themselves but to
better understand the process by which the CRAN team is formed. I
would echo his desire to better understand the process. CRAN (as
opposed to an arbitrary CRAN-like repository) is, as you and Hadley
agree, widely well-regarded. But outsiders -- for example systems
administrators of enterprise networks who are new to R -- may ask R
users to conduct due diligence on CRAN before whitelisting packages.
Some basic knowledge about the vetting and appointment of the
gatekeepers may be crucial in these matters. Naturally, CRAN as a free
service has no obligation at all to disclose such information nor to
assist with others' navigation of IT systems. But one is entitled to
ask.

Of course, Hadley could find all this out for himself, but this would
not be helpful to me and other outsiders. And I think this is what
motivated him to post publicly.

CRAN administration is a highly specialized job involving judgement
and experience; and so a criticism over the handling of one or two
submissions by obviously new appointees is hardly a reflection of the
individuals' general competence. If Uwe can make such mistakes, I
hardly think an error or two by someone else is that damning!



On 15/05/2019, Joris Meys  wrote:
> Dear Hadley,
>
> a follow up mail: You know who they are. Your organisation has the policy
> to add all email correspondence with CRAN to the github repo.
>
> https://github.com/r-lib/gargle/tree/master/cran-correspondence
>
> That's how I now also found out who they are. One is a doctor. She has a
> PhD. The mere fact you insinuate that this woman could be a student, is
> disturbing. The other obtained an engineer degree in 2011, and is currently
> obtaining a second one in Economics while working as a project assistant.
> Also here I find it disturbing you question the competence of someone with
> that experience, and who was selected by people known for their
> thoroughness.
>
> In light of this new information, I fail to understand why you even bother
> asking for information you had already. I would appreciate if you would
> stop gaslighting about CRAN and show those ladies the respect they deserve.
>
> Kind regards
> Joris
>
> On Wed, May 15, 2019 at 11:06 AM Joris Meys  wrote:
>
>> Dear Hadley,
>>
>> given you're on the list of R foundation members, I rest assured you have
>> other channels to ask about the identity of new CRAN staff directly to
>> those responsible. Their names and paychecks are of no interest to the
>> general dev world. I can understand CRAN doesn't want to make these names
>> public, in order to avoid thousands of beginning devs mailing them
>> directly
>> with questions that should be answered elsewhere.
>>
>> I'd like to take a moment to thank CRAN for extending their workforce.
>> Given the increased workload, this was long overdue. I'm fully confident
>> the responsible CRAN maintainers made a thorough selection of competent
>> people. They're not known for their laissez-faire attitude.
>>
>> I further note that:
>>
>> 1) the devoid package is on CRAN.
>>
>> 2) Where cat() is used in gargle, message() is a better option for the
>> following reason:
>>
>> > myfun <- function(){cat("Yes");message("No")}
>> > suppressMessages(myfun())
>> Yes
>>
>> This is how I train my students, but you're entitled to your own opinion
>> obviously. When the opinion of a dev differs from CRAN however, it's up
>> to
>> them to argue with CRAN about why their vision is correct. A third party
>> public complaint seems to be the norm lately, but in our region such
>> things
>> are generally frowned upon, as it's considered basic politeness to solve
>> differences with the people directly.
>>
>> Finally, I'd like to point out that one can easily use the argument
>> "repos" in install.packages() to install from a different repository. So
>> there's absolutely no problem to have your own repo where you hire the
>> people and make the rules. That might save you a few emails to the dev
>> lists.
>>
>> I hope your ongoing problems with CRAN get resolved soon.
>> All the best.
>>
>> Joris
>>
>> On Tue, May 14, 2019 at 5:26 PM Hadley Wickham 
>> wrote:
>>
>>> Hi all,
>>>
>>> Several people on my team have received responses to their CRAN
>>> submissions from new members of the CRAN team who appear to be 

[R-pkg-devel] Use of assignInNamespace in package

[Hugh Parsonage]

Hello,

I'm considering a package submission. I have used assignInNamespace,
which is hideous but seems better than the alternatives. I see that it
returns a NOTE on R CMD check, suggesting that it is not absolutely
prohibited, but would require justification.

The justification I would make is that it fixes a spurious warning
emitted by the namespace and that the assignInNamespace call would
require user intervention or the presence of an (unset) package option
or environment variable before being run. The alternatives would be to
use `suppressWarnings` (but this risks suppressing other, valid
warnings), to fork the package and submit the patched version as a
standalone package to CRAN first (which seems excessive or without
merit given the patch would be just one line), or to write a message
on package startup with the intended `assignInNamespace` call,
together with a recommendation to copy and run it before continuing
(which seems worse than assigning it within the package, considering
the message may be copied wrongly, and would have to be done on every
load).

I note the CRAN policy on 'malicious or anti-social' behaviour. My
read of 'Limited exceptions may be allowed in interactive sessions if
the package obtains confirmation from the user.' is that the usage
I've described may be allowed.  Agreement with the namespace owner
seems to offer another justification, though I haven't heard back from
the maintainer. (The patch is fairly inconsequential so the lack of
response is understandable.)

I also note the Warning in ?getFromNamespace regarding this function,
but as I said, it seems the least worst option.


Best,

Hugh.

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

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Hugh Parsonage]

Does your package import or depend on 'GmAMisc'? This package appears
to Depend on both spatstat and pROC.

Alternatively you have imported both packages in your NAMESPACE.

If neither of these clues help, could you post your DESCRIPTION and
NAMESPACE files? Probably all we'd need.



On 6 August 2018 at 06:21, Gianmarco Alberti  wrote:
> I am building a R package, and I am facing an issue caused (as far as I 
> understand) by the fact that some functions out of my package rely on two 
> fuctions having the same name and coming from 2 different packages:
>
> pROC::roc
> spatstat::roc
>
> When checking the package via devtools::check(), I get the following warning:
>
> Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when 
> loading ‘GmAMisc’
>
> Note that both packages are listed among the Imports in my package's 
> DESCRIPTION file, and that (within my functions) I have actually used 
> spatstat::roc and pROC::roc where needed.
>
> I have done some web-search but I could not locate any workaround that 
> actually fixes my issue.
>
> Do you have any suggestion on the matter?
>
> **
> Dr Gianmarco Alberti (PhD)
> (currently)
> Research Support Officer II
> Department of Classics and Archaeology
> Faculty of Arts
> University of Malta
>
> (starting from 3rd September 2018)
> Lecturer in Spatial Forensics
> Department of Criminology
> Faculty for Social Wellbeing
> University of Malta
> https://www.researchgate.net/profile/Gianmarco_Alberti4
> http://cainarchaeology.weebly.com/
> **
>
>
> [[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] Get an empty note for "checking DESCRIPTION meta-information" when I run devtools::build_win()

[Hugh Parsonage]

Thank you. Could you provide the contents of DESCRIPTION too? That might
provide the richest clue. If you have a link to an online copy of the
package that could be helpful too.

On Wed, 25 Jul 2018 at 12:01 Eggleston, Barry  wrote:

> I am working through my first package submission.  When I checked my
> package using devtools::build_win(), I got no errors and two notes.  One
> note is simply the expected note that my package is a new submission.  My
> second note involves DESCRIPTION meta-information, but nothing is printed
> so I don't know what to focus on.  I have copied the important parts of my
> 00check.log from CRAN below for context.  What areas of my DESCRIPTION file
> might create such an empty note?  Thanks in advance for any help you might
> give me.
>
> * checking CRAN incoming feasibility ... NOTE
> Maintainer: 'Barry Eggleston mailto:beggles...@rti.org
> >>'
>
> New submission
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for hidden files and directories ... OK
> * checking for portable file names ... OK
> * checking whether package 'BayesCTDesign' can be installed ... OK
> * checking installed package size ... OK
> * checking package directory ... OK
> * checking DESCRIPTION meta-information ... NOTE
>
> * checking top-level files ... OK
> * checking for left-over files ... OK
> * checking index information ... OK
> * checking package subdirectories ... OK
> * checking R files for non-ASCII characters ... OK
> * checking R files for syntax errors ... OK
> * loading checks for arch 'i386'
> ** checking whether the package can be loaded ... OK
> ** checking whether the package can be loaded with stated dependencies ...
> OK
> ** checking whether the package can be unloaded cleanly ... OK
> ** checking whether the namespace can be loaded with stated dependencies
> ... OK
> ** checking whether the namespace can be unloaded cleanly ... OK
> ** checking loading without being on the library search path ... OK
> ** checking use of S3 registration ... OK
> * loading checks for arch 'x64'
> ** checking whether the package can be loaded ... OK
> ** checking whether the package can be loaded with stated dependencies ...
> OK
> ** checking whether the package can be unloaded cleanly ... OK
> ** checking whether the namespace can be loaded with stated dependencies
> ... OK
> ** checking whether the namespace can be unloaded cleanly ... OK
> ** checking loading without being on the library search path ... OK
> ** checking use of S3 registration ... OK
> * checking dependencies in R code ... OK
> * checking S3 generic/method consistency ... OK
> * checking replacement functions ... OK
> * checking foreign function calls ... OK
> * checking R code for possible problems ... [41s] OK
> * checking Rd files ... OK
> * checking Rd metadata ... OK
> * checking Rd line widths ... OK
> * checking Rd cross-references ... OK
> * checking for missing documentation entries ... OK
> * checking for code/documentation mismatches ... OK
> * checking Rd \usage sections ... OK
> * checking Rd contents ... OK
> * checking for unstated dependencies in examples ... OK
> * checking examples ...
> ** running examples for arch 'i386' ... [19s] OK
> ** running examples for arch 'x64' ... [22s] OK
> * checking PDF version of manual ... OK
> * DONE
> Status: 2 NOTEs
>
> Barry
>
>
> [[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] Versioning conventions

[Hugh Parsonage]

3.5.1.0 with the 4th number (0) for within-release changes.

Lovely package by the way -- I was looking for it earlier this year
but thought it had been lost!

The link in the GitHub description appears broken, however.

On 10 July 2018 at 23:59, David Hugh-Jones  wrote:
> Hi all,
>
> Just updated my rcheology package with data on functions for R 3.5.1 (no
> change from R 3.5.0 afaik). See https://github.com/hughjonesd/rcheology.
>
> I'm wondering how to version this package. It's not on CRAN yet so it would
> be good to get things right.
>
> Possibilities:
>
> * Just copy the R versions, so the new version would be 3.5.1
> Advantages: easy to understand. Disadvantages: semantic versioning would
> follow R, not the package itself (which does contain a single function with
> a public API); what if I make changes between R releases.
> * ownversion.major.minor-Rversion.major.minor e.g. 0.1.0-3.5.1
> Advantages: shows the R version clearly, contains own semantic versioning
> information. Disadvantages: long.
> * ownversion.major.minor-Rversionmajorminor e.g. 0.1.0-351
> Advantage: as above but shorter. Disadvantages: if we hit e.g. 3.10.0, then
> go back to 4.0.0, then we'd end up going backward in the last component.
>
> Any ideas?
>
> Cheers,
> David
>
> [[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] FW: [CRAN-pretest-archived] CRAN submission bwt 1.1.0

[Hugh Parsonage]

Hi,

There are a few problems with the submission. Probably more than can
be resolved by people on the mailing list. Speaking generally, a
WARNING in a CRAN check is something that *must* be fixed, rather than
something which you can just acknowledge. The two warnings that you
mentioned are that you probably have (in your DESCRIPTION file)

License: GNU General Public License v3.0

when you should have

License: GPL-3

The second warning is about undocumented code objects. You can choose
not to export them, but if you do export them as you currently are,
you will need to document them.

I notice that there are other problems too: consult the links in the
auto-generated email from CRAN, see the 00check file. You should fix
every problem until there are no ERRORS, WARNINGS, or NOTEs.


Best.

On 31 May 2018 at 00:03, khoong Wei Hao  wrote:
> Hi Everyone,
>
> I encountered an issue during my submission of my package (see original 
> message below).
>
> I ran checks and tests with testthat::test_dir("tests/") and 
> devtoos::check(), and all seemed fine except some issues with undocumented 
> objects which I did note in the .Rd file, and the documentation appeared in 
> the console as I ran the package. The following is my R console output:
>
>> devtools::check()
> Updating bwt documentation
> Loading bwt
> First time using roxygen2. Upgrading automatically...
> Warning: The existing 'NAMESPACE' file was not generated by roxygen2, and 
> will not be overwritten.
> Setting env vars 
> 
> CFLAGS  : -Wall -pedantic
> CXXFLAGS: -Wall -pedantic
> Building bwt 
> 
> "C:/PROGRA~1/R/R-33~1.2/bin/x64/R" --no-site-file --no-environ --no-save 
> --no-restore --quiet CMD build  \
>   "C:\Users\khoongwh\Documents\bwt" --no-resave-data --no-manual
>
> * checking for file 'C:\Users\khoongwh\Documents\bwt/DESCRIPTION' ... OK
> * preparing 'bwt':
> * checking DESCRIPTION meta-information ... OK
> * checking for LF line-endings in source and make files
> * checking for empty or unneeded directories Removed empty directory 'bwt/man'
> Removed empty directory 'bwt/tests/testthat'
> * building 'bwt_1.1.0.tar.gz'
>
> Setting env vars 
> 
> _R_CHECK_CRAN_INCOMING_ : FALSE
> _R_CHECK_FORCE_SUGGESTS_: FALSE
> Checking bwt 
> 
> "C:/PROGRA~1/R/R-33~1.2/bin/x64/R" --no-site-file --no-environ --no-save 
> --no-restore --quiet CMD check  \
>   "C:\Users\khoongwh\AppData\Local\Temp\RtmpKmUMRO/bwt_1.1.0.tar.gz" 
> --as-cran --timings --no-manual
>
> * using log directory 
> 'C:/Users/khoongwh/AppData/Local/Temp/RtmpKmUMRO/bwt.Rcheck'
> * using R version 3.3.2 (2016-10-31)
> * using platform: x86_64-w64-mingw32 (64-bit)
> * using session charset: ISO8859-1
> * using options '--no-manual --as-cran'
> * checking for file 'bwt/DESCRIPTION' ... OK
> * checking extension type ... Package
> * this is package 'bwt' version '1.1.0'
> * package encoding: UTF-8
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for .dll and .exe files ... OK
> * checking for hidden files and directories ... OK
> * checking for portable file names ... OK
> * checking whether package 'bwt' can be installed ... OK
> * checking package directory ... OK
> * checking DESCRIPTION meta-information ... WARNING Non-standard license 
> specification:
>   GNU General Public License v3.0
> Standardizable: FALSE
> * checking top-level files ... OK
> * checking for left-over files ... OK
> * checking index information ... OK
> * checking package subdirectories ... OK
> * checking R files for non-ASCII characters ... OK
> * checking R files for syntax errors ... OK
> * checking whether the package can be loaded ... OK
> * checking whether the package can be loaded with stated dependencies ... OK
> * checking whether the package can be unloaded cleanly ... OK
> * checking whether the namespace can be loaded with stated dependencies ... OK
> * checking whether the namespace can be unloaded cleanly ... OK
> * checking loading without being on the library search path ... OK
> * checking dependencies in R code ... OK
> * checking S3 generic/method consistency ... OK
> * checking replacement functions ... OK
> * checking foreign function calls ... OK
> * checking R code for possible problems ... OK
> * checking for missing documentation entries ... WARNING Undocumented code 
> objects:
>   'bwt' 'ibwt'
> All user-level objects in a package should have documentation entries.
> See chapter 'Writing R documentation files' in the 'Writing R 

[R-pkg-devel] Very large packages in Additional_repositories

[Hugh Parsonage]

Dear list,

I'm considering submitting a package to CRAN. The package would be a
'foyer' or API to a much larger package (>1GB tarball) containing
geographical data that the 'foyer' package would use to perform tasks
like geocoding. The foyer package would be usable, though quite
limited, as a standalone package, and I can technically pass an R CMD
check by placing the 1 GB package in Suggests and using an
Additional_repository, but it takes a long time to retrieve and
install from the Additional_repository. While I believe the downside
of long install times would be acceptable for end-users (who would
only need to install the package once a year), for CRAN it could
occupy a large part of the check farm and have to occur much more
frequently.

The package once installed makes good use of lazy loading; in
particular, it would be basically unusable if the CRAN package had to
connect and download the necessary pieces from the large package each
time it was required. I thought about breaking up the package into
lots of little packages; however, even though the package is not
strictly atomic, its indivisible elements would still be too large for
CRAN.

My questions are:
  would this 'foyer' package be acceptable to CRAN? and, if so,
  what can I do so that the foyer package doesn't eat up CRAN's
computing resources (either on submission or once accepted) when
checking Suggests:


Best,

Hugh.

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

Re: [R-pkg-devel] [FORGED] Re: How to (conditionally) use an archived package (without Suggests)?

[Hugh Parsonage]

Not to mention a drat repository you can just fork with a single click!
On Mon, 26 Feb 2018 at 3:25 am, Dirk Eddelbuettel  wrote:

>
> On 25 February 2018 at 15:00, Marius Hofert wrote:
> | okay, so (afaik) this is just a github repos which contains an exact
> | copy of the github version of the problematic package (here: loon). I
>
> Be very careful with terminology here:
>
>  -- "github repo" is to most people a source code repo
>  -- drat uses github and its "automatic webserver" to provide an "R repo",
> ie
> a repository for R packages (ie .tar.gz, binaries for macOS and windows
> work too if you build them).
>
> I have long joked that I wrote more documentation than code for drat, and
> it
> still confused the hell out of people.  But there are numerous vignettes, a
> useR talk I have and of course the long and very detailed paper.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> 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] How to (conditionally) use an archived package (without Suggests)?

[Hugh Parsonage]

The relevant part of the repository policy:

> Packages on which a CRAN package depends should be available from a 
> mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’ fields 
> are not from such a repository, where to obtain them at a repository should 
> be specified in an ‘Additional_repositories’ field of the DESCRIPTION file 
> (as a comma-separated list of repository URLs) or for other means of access, 
> described in the ‘Description’ field.

My understanding is that "should be available" means "if it's not
available, expect a NOTE (at least) and you should address this note
in your submission". Also, I think "available" means "available and
installable".

For example, I get a NOTE for 'taxstats', a suggested package of
grattan that isn't on CRAN:

* checking CRAN incoming feasibility ... NOTE
Suggests or Enhances not in mainstream repositories:
taxstats
Availability using Additional_repositories specification:
taxstats yes https://hughparsonage.github.io/drat/


However, the reason taxstats is not on CRAN is because it's too big,
not because it's unable to be installed or has other problems. At the
time it was archived, package loon could only be installed on OSX as
far as I can see, which may disqualify it from even being suggested.
My understanding is that CRAN does indeed check the package with
non-mainstream packages installed (at least on initial submission).
You may be better off just hoisting the functions you need outside of
loon (with attribution and while respecting the licence) if you really
need them.

(You say that package loon's problems are easy to fix. You may be able
to accede to be its maintainer but I don't know the details of this
process. The CRAN repository policy contemplates this when the package
is orphaned, but I'm not sure if it's the same process when the
package is archived.)





On 25 February 2018 at 11:59, Dirk Eddelbuettel  wrote:
>
> On 24 February 2018 at 19:41, Duncan Murdoch wrote:
> | Don't throw an error, work around it.  If you have no alternative code,
> | then don't test the "bar" code unless "bar" is installed.
> |
> | The basic idea is that your package should pass tests without errors
> | even if "bar" is not available.
>
> 100% agreed.
>
> | I think Dirk is wrong saying that "bar" has to be available; CRAN isn't
> | going to go looking for it.  But they do want your package to pass all
> | tests even if none of the Suggests packages is available.
>
> I might be wrong but I thought all package in Imports, LinkingTo, Depends and
> Suggests are actually checked for availability.
>
> CRAN and BioC work by default, others can be added via Additional_repository
> in DESCRIPTION.  And as I recall, not mentioning one leads to some complaint
> from R CMD check. But I may well misremember.
>
> Best, Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> 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] Strange Additional_repositories NOTE followed by package install error

[Hugh Parsonage]

Thank you Uwe & Neal,

Following your suggestion, I tried inserting a binary version of the
package into the repository. I first tried inserting the package into
R 3.4; however, the note persists on winbuilder for R-release:

* using log directory 'd:/RCompile/CRANguest/R-release/grattan.Rcheck'
* using R version 3.4.3 (2017-11-30)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'grattan/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'grattan' version '1.5.3.2'
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Hugh Parsonage <hugh.parson...@gmail.com>'

Possibly mis-spelled words in DESCRIPTION:
  Grattan (18:24)
  indices (17:77)
  repos (19:34)
  taxstats (19:23)

Suggests or Enhances not in mainstream repositories:
  taxstats
Availability using Additional_repositories specification:
  taxstats   no   ?
  ?   ?   https://hughparsonage.github.io/drat/
Additional repositories with no packages:
  https://hughparsonage.github.io/drat/

 (ephemeral link: https://win-builder.r-project.org/4SMyJyP2fZcC/00check.log )

whereas when I run R CMD check --as-cran on a local machine, as well
as on appveyor, I get the expected NOTE.

─  using log directory
'C:/Users/hughp/AppData/Local/Temp/Rtmp4IHBGp/file3b0053a64c53/grattan.Rcheck'
─  using R version 3.4.3 (2017-11-30)
─  using platform: x86_64-w64-mingw32 (64-bit)
─  using session charset: ISO8859-1
─  using option '--as-cran'
✔  checking for file 'grattan/DESCRIPTION'
─  checking extension type ... Package
─  this is package 'grattan' version '1.5.3.2'
N  checking CRAN incoming feasibility
   Maintainer: 'Hugh Parsonage <hugh.parson...@gmail.com>'

   Suggests or Enhances not in mainstream repositories:
 taxstats
   Availability using Additional_repositories specification:
 taxstats   yes   https://hughparsonage.github.io/drat/

The newly inserted binary package appears to install fine on
Appveyor's instance:

Rscript -e "is.null(install.packages('taxstats', repos =
'https://hughparsonage.github.io/drat'))"
Installing package into 'c:/RLibrary'
(as 'lib' is unspecified)
trying URL 
'https://hughparsonage.github.io/drat/bin/windows/contrib/3.4/taxstats_0.0.5.1415.zip'
Content type 'application/zip' length 78843919 bytes (75.2 MB)
==
downloaded 75.2 MB
package 'taxstats' successfully unpacked and MD5 sums checked
The downloaded binary packages are in
C:\Users\appveyor\AppData\Local\Temp\1\Rtmp6HCDYs\downloaded_packages
[1] TRUE


I understand that available.packages() using caching, but rebooting my
computer did not change this result (I'm not sure if this is
sufficient to eliminate the possibility that caching is masking a
problem).


Sorry that this package is causing problems on CRAN. Very appreciative
of your patience.


Hugh.

On 6 February 2018 at 04:19, Uwe Ligges <lig...@statistik.tu-dortmund.de> wrote:
> 1.
> The repository is obviously *not* available for Windows as
>
> https://hughparsonage.github.io/drat/bin/windows/contrib/3.5/PACKAGES
>
> does not exist.
>
>
> 2.
>> Since the failures only occur on Windows machines, and have only
>> appeared recently, I have considered modifying the DESCRIPTION file to
>> 'trick' win-builder into reinstalling taxstats
>
>
> -> This is strictly prohibited and you will be banned of CRAN if you try
> that.
>
> Best,
> Uwe Ligges
>
>
>
>
> On 05.02.2018 12:28, Hugh Parsonage wrote:
>>
>> I am unable to reproduce a recent R CMD check failure on CRAN
>> concerning a package of mine: grattan.
>>
>> This package Suggests: taxstats which is a large package hosted by an
>> Additional repository: https://hughparsonage.github.io/drat/
>>
>> When I run this check locally, on travis, and on appveyor with
>> _R_CHECK_CRAN_INCOMING_ = true I get the expected NOTE:
>>
>>
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: ‘Hugh Parsonage <hugh.parson...@gmail.com>’
>> Suggests or Enhances not in mainstream repositories:
>>taxstats
>> Availability using Additional_repositories specification:
>> taxstats   yes   https://hughparsonage.github.io/drat/
>>
>>
>> However, on CRAN (including win-builder) I get the rather curious NOTE:
>>
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: 'Hugh Parsonage <hugh.parson...@gmail.com>'
>>
>> Suggests or Enhances not in mainstream repositories:
>>taxstats
>> Availability using Additional_repositories specification:
>>taxstats   no   ?
>>?   ?   https://hughparsonage.github.io/drat/
>> Additional repositories with no packages:
>>https://hughparsonage.github.io/drat/
>>
>

[R-pkg-devel] Strange Additional_repositories NOTE followed by package install error

[Hugh Parsonage]

I am unable to reproduce a recent R CMD check failure on CRAN
concerning a package of mine: grattan.

This package Suggests: taxstats which is a large package hosted by an
Additional repository: https://hughparsonage.github.io/drat/

When I run this check locally, on travis, and on appveyor with
_R_CHECK_CRAN_INCOMING_ = true I get the expected NOTE:


* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Hugh Parsonage <hugh.parson...@gmail.com>’
Suggests or Enhances not in mainstream repositories:
  taxstats
Availability using Additional_repositories specification:
taxstats   yes   https://hughparsonage.github.io/drat/


However, on CRAN (including win-builder) I get the rather curious NOTE:

* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Hugh Parsonage <hugh.parson...@gmail.com>'

Suggests or Enhances not in mainstream repositories:
  taxstats
Availability using Additional_repositories specification:
  taxstats   no   ?
  ?   ?   https://hughparsonage.github.io/drat/
Additional repositories with no packages:
  https://hughparsonage.github.io/drat/


followed by errors resulting from failures to install 'taxstats' when
code such as the following is run to re-build vignettes:

if (requireNamespace("taxstats", quietly = TRUE)){
  library(taxstats)
} else {
  templib <- tempfile()
  hutils::provide.dir(templib)
  install.packages("taxstats",
   lib = templib,
   repos = "https://hughparsonage.github.io/drat/;,
   type = "source")
  library("taxstats", lib.loc = templib)
}


Since the failures only occur on Windows machines, and have only
appeared recently, I have considered modifying the DESCRIPTION file to
'trick' win-builder into reinstalling taxstats, as I suspect there may
be caching issues. However, given that the 'taxstats' package takes a
fairly long time to install, I don't want to do this nor submit to
CRAN in case I am missing something else that's causing the check to
fail.

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

[R-pkg-devel] Is it ever appropriate (or mandatory) to Suggests: R (>= version) ?

[Hugh Parsonage]

I believe it is a requirement that if package A imports package B, and
package B lists package C in Depends: then package A must also list
package C in Depends:
A popular stackoverflow answer states this.[1] I can't find any other
source but it makes sense.

What if package B is suggested by package A and package B depends on a
certain version of R? That is if package A *suggests* package B and
package B lists Depends: R (>= ver). In such a case, is it necessary
to list this dependency in Suggests? Certainly endnote 12 of WRE says
it would be necessary if the dependency were for a package, but
doesn't seem to mention similar dependencies on R version. And, as far
as I can see, no package on CRAN lists R in Suggests, so it would to
be non-standard if not prohibited.

S <- available.packages()
S[grepl("(?https://stackoverflow.com/a/8638902/1664978

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

Re: [R-pkg-devel] R-package did not pass the incoming checks automatically

[Hugh Parsonage]

Use the url at the bottom of the linked page, i.e.
https://cran.r-project.org/package=ewoc

On Sun, 21 Jan 2018 at 5:06 am, Roy Mendelssohn - NOAA Federal <
roy.mendelss...@noaa.gov> wrote:

> Hi Márcio:
>
> I do not have solutions to your specific problems, but the errors do
> appear to be coming from the development version of R.  When you run
> devtools::build_win(), run it twice,  once as:
>
> devtools::build_win(version = "R-release")
>
> and once with
>
> devtools::build_win(version = "R-devel")
>
> which is then more likely to produce the CRAN results before you submit.
> Also,  as Henrik Bengtsson explained on this list a few weeks ago:
>
> > As far as I understand it, the new R-devel tests basically tests your
> > package with the minimal setup of packages (a "sandboxed" .libPaths())
> > inferred from you DESCRIPTION (by excluding Suggests of the packages
> > you depend on, which is where I think 'webshot' lives).
>
> So R-devel can give different results,  and you need to make certain that
> your Imports and Suggests includes anything that might not be loaded.
>
> Hope this helps some.
>
> -Roy
>
> > On Jan 20, 2018, at 9:47 AM, Márcio Augusto Diniz 
> wrote:
> >
> > Hello all,
> >
> > I submitted my package (
> > https://cran.r-project.org/web/packages/ewoc/index.html) to CRAN and it
> did
> > not pass the automatic checks of win_builder. However,  I did not have
> the
> > same error or warning messages when I ran devtools::win_builder() and
> > devtools::run_examples() before. I had the same notes, though.
> >
> > See message from win_builder() CRAN:
> >
> > * using log directory 'd:/RCompile/CRANincoming/R-devel/ewoc.Rcheck'
> > * using R Under development (unstable) (2018-01-19 r74138)
> > * using platform: x86_64-w64-mingw32 (64-bit)
> > * using session charset: ISO8859-1
> > * checking for file 'ewoc/DESCRIPTION' ... OK
> > * checking extension type ... Package
> > * this is package 'ewoc' version '0.1.1'
> > * checking CRAN incoming feasibility ... NOTE
> > Maintainer: 'Marcio A. Diniz '
> >
> > Found the following (possibly) invalid URLs:
> >  URL: https://cran.rstudio.com/web/packages/ewoc/index.html
> >From: README.md
> >Status: 200
> >Message: OK
> >CRAN URL not in canonical form
> >  Canonical CRAN.R-project.org URLs use https.
> > * checking package namespace information ... OK
> > * checking package dependencies ... OK
> > * checking if this is a source package ... OK
> > * checking if there is a namespace ... OK
> > * checking for hidden files and directories ... OK
> > * checking for portable file names ... OK
> > * checking serialized R objects in the sources ... OK
> > * checking whether package 'ewoc' can be installed ... OK
> > * checking installed package size ... OK
> > * checking package directory ... OK
> > * checking DESCRIPTION meta-information ... OK
> > * checking top-level files ... OK
> > * checking for left-over files ... OK
> > * checking index information ... OK
> > * checking package subdirectories ... OK
> > * checking R files for non-ASCII characters ... OK
> > * checking R files for syntax errors ... OK
> > * loading checks for arch 'i386'
> > ** checking whether the package can be loaded ... OK
> > ** checking whether the package can be loaded with stated dependencies
> ...
> > OK
> > ** checking whether the package can be unloaded cleanly ... OK
> > ** checking whether the namespace can be loaded with stated dependencies
> > ... OK
> > ** checking whether the namespace can be unloaded cleanly ... OK
> > ** checking loading without being on the library search path ... OK
> > ** checking use of S3 registration ... OK
> > * loading checks for arch 'x64'
> > ** checking whether the package can be loaded ... OK
> > ** checking whether the package can be loaded with stated dependencies
> ...
> > OK
> > ** checking whether the package can be unloaded cleanly ... OK
> > ** checking whether the namespace can be loaded with stated dependencies
> > ... OK
> > ** checking whether the namespace can be unloaded cleanly ... OK
> > ** checking loading without being on the library search path ... WARNING
> > Error: package or namespace load failed for 'ewoc' in namespaceExport(ns,
> > exports):
> > undefined exports: iter, nextElem, isplit, irnorm, irunif, irbinom,
> > irnbinom, irpois, icount, idiv, ireadLines, iread.table, icountn, iapply
> > In addition: Warning message:
> > S3 methods 'iter.default', 'iter.iter', 'iter.matrix', 'iter.data.frame',
> > 'iter.function', 'nextElem.containeriter', 'nextElem.matrixiter',
> > 'nextElem.dataframeiter', 'nextElem.funiter', 'nextElem.abstractiter',
> > 'as.list.iter', 'isplit.default', 'isplit.data.frame' were declared in
> > NAMESPACE but not found
> > Execution halted
> >
> > It looks like this package has a loading problem when not on .libPaths:
> > see the messages for details.
> > ** checking use of S3 registration ... OK
> > * checking dependencies in R code ... 

[R-pkg-devel] rcnst issue

[Hugh Parsonage]

I recently noticed a package of mine, TeXCheckR, is failing "rcnst"
under "Additional issues". My package is one of only three to fail
this check. I'd like help from the mailing list to fix this issue (or
to be told not to fix it if it should not be fixed).

I read
  https://github.com/kalibera/cran-checks/blob/master/rcnst/CONSTANTS.md
and the report at
  
https://github.com/kalibera/cran-checks/blob/master/rcnst/results/TeXCheckR/00check.log

The text at CONSTANTS.md and the relevant entry at
 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Named-objects-and-copying
suggests that this error is only contemplated with packages with
compiled (C/C++) code. Since R automatically handles NAMED, my
understanding was that an R package that does not need compilation
should never encounter this error. Clearly my understanding is wrong,
as TeXCheckR does not require compilation yet fails this test.

The only clue I have is that the error occurs during a test of a
function which (through another package) calls %fin% from the
fastmatch package. Package fastmatch does require compilation and does
appear to modify the value of c(".", "?"). Do I need to stop using
%fin% inside packages to avoid this error, or is the cause of the
error elsewhere? I have some doubt that %fin% is totally to blame as
the package through which %fin% is eventually called does not
encounter the same error.


Many thanks,

Hugh Parsonage
Grattan Institute

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

[R-pkg-devel] CRAN policy on binary submission

[Hugh Parsonage]

On https://cran.r-project.org/ , it says

> Note that we generally do not accept submissions of precompiled binaries due 
> to security reasons

I note it says 'generally', not 'always'. Are there any packages on
CRAN which were submitted as precompiled binaries? Under what
circumstances would CRAN accept binaries?


Hugh

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

Re: [R-pkg-devel] Assignments to the Global environment

[Hugh Parsonage]

I'm not CRAN, but something like this might be permissible while
satisfying your requirements.

   z <- function(..., assign.env = parent.frame(1))
assign(as.character(s), temp3, envir = assign.env)

The problem with assigning to the global environment is that z might
be called where it is expected to only have a local effect. If users
really want to assign to the global environment, providing an option
might be appropriate.

   z <- function(y, s, assign.env = getOption("TSEtools.z.env",
parent.frame(1))) assign(as.character(s), temp3, envir = assign.env)

   options("TSEtools.z.env" = .GlobalEnv)


On Sun, 7 Jan 2018 at 23:21 Saeb  wrote:
>
> The function downloads the list of index's value and assigned them to
> the individual's name correspond with the indexes. If remove the
> .GlobalEnv, then we can not return the values in output.
>
> Since, the data is updated daily, I think that the storage on device is
> not user friendly enough.
>
> I already used the following code with same R report:
>
> assign(as.character(s), temp3, envir = .GlobalEnv)
>
> |
> |
>
>
> On 01/07/2018 01:30 AM, Uwe Ligges wrote:
> > Let me add: Frequently you can use storage in an enmvironment in yur
> > package, if that helps to avoid assigning into .GlobalEnv.
> >
> > Best,
> > Uwe Ligges
> >
> > On 06.01.2018 22:07, peter dalgaard wrote:
> >> You probably need to tell us what you are trying to achieve. Why do
> >> you want to assign temp3 to a variable with its name in s into the
> >> global environment? Not doing that would clearly eliminate the Note:,
> >> but presumably it has a function. However, writing to the global
> >> environment, especially to variables with arbitrary names, is
> >> potentially antisocial behaviour, since it may overwrite user variables.
> >>
> >> Incidentally, why do you write .GlobalEnv as as.environment(1)? Is is
> >> as intended?
> >>
> >> -pd
> >>
> >>> On 6 Jan 2018, at 20:36 , Saeb  wrote:
> >>>
> >>> * checking R code for possible problems ... [4s] NOTE
> >>> Found the following assignments to the global environment:
> >>> File 'TSEtools/R/getTSE.R':
> >>> assign(as.character(s), temp3, envir = as.environment(1))
> >>>
> >>> Please let me know, how can I eliminate this problem? I didn't find out
> >>> any good information on websites!
> >>
>
>
> [[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] Imports: vs Suggests:

[Hugh Parsonage]

I write to clarify when a package should be in Imports: vs Suggests:.
Does the absence of warnings following a R CMD check --as-cran
guarantee that packages are placed in the correct field?

For example, consider a package with only one exported function:

isTrue <- function(x) hutils::AND(x, TRUE)

When I run R CMD check on this package with an otherwise valid
DESCRIPTION and NAMESPACE, I get a warning about an undeclared import.
That I understand.

But if I add

Suggests: hutils

to DESCRIPTION then R CMD check passes with no warnings. (hutils is
installed on my machine, so I don't receive a note about a package
being unavailable for checking.) My understanding is that because
isTrue won't run without hutils, the package must include hutils under
Imports (or Depends:) not Suggests: , but the R CMD check result gives
the impression that this decision is at the discretion of the package
author. In 'Writing R Extensions', there is a caveat that packages may
be in Suggests: rather than Imports if they are "loaded in the body of
functions", but I don't understand the distinction.

Furthermore, would it make a difference if instead of hutils being
used it was a base package (like stats) or a recommended package (like
KernSmooth)?


Hugh Parsonage
Grattan Institute

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