Re: [R-pkg-devel] r-oldrel-linux- not in CRAN checks?

[Vincent van Hees]

Thanks Ivan, In that case I will conclude that it is time to upgrade my
Ubuntu 18 machine. I just wasn't sure whether there is still a need for
keeping my own package Ubuntu 18 compatible, but if dependencies like Rfast
do not do it and if it is even not in the CRAN checks anymore then there is
also limited value in me making the effort.

I have now fixed the message formatting in that issue just in case Rfast
maintainers want to have a look at it.

Vincent

Op di 6 feb. 2024 21:34 schreef Ivan Krylov :

> В Tue, 6 Feb 2024 18:27:32 +0100
> Vincent van Hees  пишет:
>
> > For details see:
> > https://github.com/RfastOfficial/Rfast/issues/99
>
> GitHub processed your plain text description of the problem as if it
> was Markdown and among other things ate the text that used to be there
> between angle brackets:
>
> > #include
> >  ^~~
>
> By digging through the raw source code of the issue at
> https://api.github.com/repos/RfastOfficial/Rfast/issues/99 it is
> possible to find out which header was missing for Rfast:
>
> > ../inst/include/Rfast/parallel.h:20:10:fatal error: tion: No such
> > file or directory
> > #include 
> >  ^~~
> >compilation terminated.
>
> Indeed,  is a C++17 header [1]. While g++ version
> 7.5.0-3ubuntu1~18.04 seems to accept --std=c++17 without complaint, its
> libstdc++-7-dev package is missing this header. Moreover, there's still
> no  in libstdc++-8-dev. I think that you need libstdc++-9
> for that to work, which is not in Bionic; older versions aren't
> C++17-compliant enough to compile Rfast, and C++17 is listed in the
> SystemRequirements of the package.
>
> Installing clang-10 and editing Makeconf to use clang++-10 instead of
> g++ seems to let the compilation proceed. In order to successfully link
> the resulting shared object, I also had to edit Makeconf to specify
> -L/usr/lib/gcc/x86_64-linux-gnu/7 when linking -lgfortran.
>
> If you plan to use this in production, be very careful. I don't know
> about binary compatibility guarantees between g++-7 and clang++-10, so
> you might have to recompile every C++-using R package from source with
> clang++-10 in order to avoid hard-to-debug problems when using them
> together. (It might also work fine. That's the worst thing about such
> problems.)
>
> --
> Best regards,
> Ivan
>
> [1] https://en.cppreference.com/w/cpp/header/execution
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] r-oldrel-linux- not in CRAN checks?

[Vincent van Hees]

Hello,

I noticed that there is no r-oldrel-linux-x86_64... on the CRAN
package results page. Does this mean that CRAN checks no longer run on
old Debian releases?

The reason for asking this is that I am struggling to install Rfast on
Ubuntu 18, which made me wonder whether CRAN/R community no longer
support Ubuntu 18? For details see:
https://github.com/RfastOfficial/Rfast/issues/99

Thanks,

Vincent

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

Re: [R-pkg-devel] How to create a macos-arm64 virtual machine/cloud environment to debug R package?

[Vincent van Hees]

Thanks Tim, I just managed to fix the bug and will prepare a new submission
to CRAN in the upcoming days.


On Wed, 6 Dec 2023 at 11:13, Tim Taylor 
wrote:

> This is just a punt from a quick glance at your tests. Try using the
> following on your local build to ensure it's not a time zone issue
>
> TZ=NZ R CMD check --as-cran
>
> Apologies if this is just noise but whenever I've had issues with
> datetimes and mac tests this is the first thing I check.
>
> Tim
>
>
>
>
> On Wed, 6 Dec 2023, at 9:28 AM, Vincent van Hees wrote:
>
> Hello,
>
> What is the recommended way to create a virtual machine or cloud based R
> environment for debugging R package issues specific to OS macos-arm64?
>
> Details:
> CRAN results show macos-arm64 specific problems for my package:
> https://cran.r-project.org/web/checks/check_results_GGIR.html. I am able
> to
> reproduce them with https://mac.r-project.org/macbuilder/submit.html. I
> suspect something goes wrong with the timestamp creation or handling as
> that has caused issues with this OS for me in the past. All this relates to
> this
> <
> https://github.com/wadpac/GGIR/blob/master/tests/testthat/test_part5_analyseRest.R
> >
> test for this
> <https://github.com/wadpac/GGIR/blob/master/R/g.part5.analyseRest.R>
> function, that in the process calls this
> <https://github.com/wadpac/GGIR/blob/master/R/POSIXtime2iso8601.R> short
> function. I have been trying some edits locally and re-submitting them to
> macbuilder a couple of times to no avail. To debug this efficiently it
> would be good to have access to an R environment for this OS. I do not have
> a physical macos myself.
>
> Vincent
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] How to create a macos-arm64 virtual machine/cloud environment to debug R package?

[Vincent van Hees]

Sorry, I now see that this may actually be a timezone specific issue which
I can now reproduce in Windows by changing the timezone of the timeseries
to "Pacific/Auckland".

This would indicate that macos-arm64 CRAN machines are based in a different
timezone than the other machines, not the arm64 OS as such.

This reminds me that I ran into a similar issues earlier this year where I
struggled to get GitHub Actions to run the macos workflow in a non-default
timezone, which I raised elsewhere:
https://community.rstudio.com/t/upgrading-github-action-workflow-to-address-no-package-called-rcmdcheck-but-unclear-how-to-account-for-timezone/166876
... I should have thought about that first.

Vincent


On Wed, 6 Dec 2023 at 10:28, Vincent van Hees 
wrote:

> Hello,
>
> What is the recommended way to create a virtual machine or cloud based R
> environment for debugging R package issues specific to OS macos-arm64?
>
> Details:
> CRAN results show macos-arm64 specific problems for my package:
> https://cran.r-project.org/web/checks/check_results_GGIR.html. I am able
> to reproduce them with https://mac.r-project.org/macbuilder/submit.html.
> I suspect something goes wrong with the timestamp creation or handling as
> that has caused issues with this OS for me in the past. All this relates to
> this
> <https://github.com/wadpac/GGIR/blob/master/tests/testthat/test_part5_analyseRest.R>
> test for this
> <https://github.com/wadpac/GGIR/blob/master/R/g.part5.analyseRest.R>
> function, that in the process calls this
> <https://github.com/wadpac/GGIR/blob/master/R/POSIXtime2iso8601.R> short
> function. I have been trying some edits locally and re-submitting them to
> macbuilder a couple of times to no avail. To debug this efficiently it
> would be good to have access to an R environment for this OS. I do not have
> a physical macos myself.
>
> Vincent
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] How to create a macos-arm64 virtual machine/cloud environment to debug R package?

[Vincent van Hees]

Hello,

What is the recommended way to create a virtual machine or cloud based R
environment for debugging R package issues specific to OS macos-arm64?

Details:
CRAN results show macos-arm64 specific problems for my package:
https://cran.r-project.org/web/checks/check_results_GGIR.html. I am able to
reproduce them with https://mac.r-project.org/macbuilder/submit.html. I
suspect something goes wrong with the timestamp creation or handling as
that has caused issues with this OS for me in the past. All this relates to
this

test for this

function, that in the process calls this
 short
function. I have been trying some edits locally and re-submitting them to
macbuilder a couple of times to no avail. To debug this efficiently it
would be good to have access to an R environment for this OS. I do not have
a physical macos myself.

Vincent

[[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 of itemize in man file

[Vincent van Hees]

I ran into the same issue last week with .Rd files that were
previously accepted on CRAN and concluded that the package checks are
becoming more critical about this aspect of Rd syntax, which is good.

To reproduce the note outside R-devel and by that identify which files
in your package are affected you could run for every Rd file in your
man folder:

tools::checkRd(Rd = file, listOK = FALSE)

Vincent

On Sun, 22 Oct 2023 at 16:53, Ivan Krylov  wrote:
>
> On Sun, 22 Oct 2023 10:43:08 -0400
> J C Nash  wrote:
>
> >\itemize{
> >  \item{fnchk OK;}{ \code{excode} = 0;
> > \code{infeasible} = FALSE}
>
> The \item command inside \itemize{} lists doesn't take arguments.
> Did you mean \describe{} instead of \itemize{}?
>
> --
> Best regards,
> Ivan
>
> __
> 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] my experiences of maintaining an R package for 10 years

[Vincent van Hees]

Dear all,

This is not a question.
I just put a blog post online with a lengthy overview of how I have
developed and maintained the R package GGIR as available on CRAN for
the past 10 years:
https://www.accelting.com/updates/10th-anniversary-of-ggir/

The package itself is probably not of interest to anyone here as it is
very research domain specific, but you may find it interesting to read
about my personal journey to grow the package into a popular tool
within the research field it is designed for: human movement and sleep
research.

Thanks,

Vincent

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

Re: [R-pkg-devel] Warning 'as.data.frame.POSIXct()' is deprecated

[Vincent van Hees]

Thanks Dirk,
My plan will then be to revise my package to avoid using POSIXlt when
POSIXct is also sufficient, given that I am storing timestamps in
data.frames a lot. In the few instances where POSIXlt may be necessary I
will avoid storing them in a data.frame.
Vincent

On Thu, 6 Jul 2023 at 15:22, Dirk Eddelbuettel  wrote:

>
> On 6 July 2023 at 08:14, Dirk Eddelbuettel wrote:
> |
> | On 6 July 2023 at 14:31, Vincent van Hees wrote:
> | | Thanks, in that case the REPLEX for the issue may need to be:
> | |
> | | > remember = Sys.getenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_")
> | | > Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = TRUE)
> | | > data.frame(time = Sys.time())
> | |  time
> | | 1 2023-07-06 14:29:37
> | | > data.frame(time = as.POSIXlt(Sys.time()))
> | |  time
> | | 1 2023-07-06 14:29:37
> | | Warning message:
> | | Direct call of 'as.data.frame.POSIXct()' is deprecated.  Use
> | | 'as.data.frame.vector()' or 'as.data.frame()' instead
> | | > Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = remember)
> |
> | Does _not_ happen in a plain R session.
> |
> | Does happen when `library(tidyverse)` is executed first. May come from
> | `tibble` or `vectors`, I have a habit of not using those much.
>
> Err, no, wait. I may have confused myself here jumping between R-devel and
> R (release).  Please disregard, and apologies for the noise.
>
> In any event, assigning a POSIXlt (which is an 11-element list) to a single
> column is not a great idiom and we had the POSIXct conversion there for a
> while IIRC.
>
> But assigning a POSIXct to a column should always work, and I would be
> surprised to find a minimally complete reproducible example showing that it
> does not.
>
> Dirk
>
> | Dirk
> |
> | | Vincent
> | |
> | | On Thu, 6 Jul 2023 at 10:41, Tim Taylor <
> tim.tay...@hiddenelephants.co.uk>
> | | wrote:
> | |
> | | > Apologies - I've not had enough caffeine just yet. The reprex below
> | | > highlights the issue but I think the code which implemented the
> change
> | | > *may* need tweaking not lapply.
> | | >
> | | > Tim
> | | >
> | | > On 06/07/2023 09:26, Tim Taylor wrote:
> | | > > This *may* be an issue in lapply.  Let's see what others day.
> Reprex
> | | > > below
> | | > >
> | | > > Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = TRUE)
> | | > > dat <- Sys.Date()
> | | > > as.data.frame(dat)
> | | > > #>  dat
> | | > > #> 1 2023-07-06
> | | > > lapply(dat, as.data.frame)
> | | > > #> Warning: Direct call of 'as.data.frame.Date()' is deprecated.
> Use
> | | > > #> 'as.data.frame.vector()' or 'as.data.frame()' instead
> | | > > #> [[1]]
> | | > > #>   X[[i]]
> | | > > #> 1 2023-07-06
> | | > >
> | | > > Tim
> | | > >
> | | > > On 06/07/2023 08:54, Vincent van Hees wrote:
> | | > >> Dear all,
> | | > >>
> | | > >> I see the following warning in my package test results:
> | | > >>
> | | > >> ```
> | | > >> Warning
> | | > >> Direct call of 'as.data.frame.POSIXct()' is deprecated.  Use
> | | > >> 'as.data.frame.vector()' or 'as.data.frame()' instead
> | | > >> ```
> | | > >>
> | | > >> The warning is not always there and I struggle to make it
> | | > >> reproducible. I
> | | > >> have encountered it in both Ubuntu 22.04 and in Windows 11, in
> both R
> | | > >> 4.3.0
> | | > >> and 4.3.1, in both RStudio and in an GitHub Actions environment
> (example
> | | > >> <
> https://github.com/wadpac/GGIR/actions/runs/5463862340/jobs/9945096566>).
> | | >
> | | > >>
> | | > >> The warning gives the impression that I am doing something that R
> no
> | | > >> longer
> | | > >> supports. However, I am not using the command
> as.data.frame.POSIXct()
> | | > >> anywhere directly in my code.
> | | > >>
> | | > >> When I dive into the code where the warnings occur I see patterns
> like:
> | | > >>
> | | > >> ```
> | | > >> now = Sys.time()
> | | > >> df = data.frame (time = seq(now, now + 10, by =1),  B  = 1:11)
> | | > >> ```
> | | > >>
> | | > >> (this is a simplification of for example:
> | | > >>
> | | >
> h

Re: [R-pkg-devel] Warning 'as.data.frame.POSIXct()' is deprecated

[Vincent van Hees]

Thanks, in that case the REPLEX for the issue may need to be:

> remember = Sys.getenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_")
> Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = TRUE)
> data.frame(time = Sys.time())
 time
1 2023-07-06 14:29:37
> data.frame(time = as.POSIXlt(Sys.time()))
 time
1 2023-07-06 14:29:37
Warning message:
Direct call of 'as.data.frame.POSIXct()' is deprecated.  Use
'as.data.frame.vector()' or 'as.data.frame()' instead
> Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = remember)

Vincent

On Thu, 6 Jul 2023 at 10:41, Tim Taylor 
wrote:

> Apologies - I've not had enough caffeine just yet. The reprex below
> highlights the issue but I think the code which implemented the change
> *may* need tweaking not lapply.
>
> Tim
>
> On 06/07/2023 09:26, Tim Taylor wrote:
> > This *may* be an issue in lapply.  Let's see what others day. Reprex
> > below
> >
> > Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = TRUE)
> > dat <- Sys.Date()
> > as.data.frame(dat)
> > #>  dat
> > #> 1 2023-07-06
> > lapply(dat, as.data.frame)
> > #> Warning: Direct call of 'as.data.frame.Date()' is deprecated.  Use
> > #> 'as.data.frame.vector()' or 'as.data.frame()' instead
> > #> [[1]]
> > #>   X[[i]]
> > #> 1 2023-07-06
> >
> > Tim
> >
> > On 06/07/2023 08:54, Vincent van Hees wrote:
> >> Dear all,
> >>
> >> I see the following warning in my package test results:
> >>
> >> ```
> >> Warning
> >> Direct call of 'as.data.frame.POSIXct()' is deprecated.  Use
> >> 'as.data.frame.vector()' or 'as.data.frame()' instead
> >> ```
> >>
> >> The warning is not always there and I struggle to make it
> >> reproducible. I
> >> have encountered it in both Ubuntu 22.04 and in Windows 11, in both R
> >> 4.3.0
> >> and 4.3.1, in both RStudio and in an GitHub Actions environment (example
> >> <https://github.com/wadpac/GGIR/actions/runs/5463862340/jobs/9945096566>).
>
> >>
> >> The warning gives the impression that I am doing something that R no
> >> longer
> >> supports. However, I am not using the command as.data.frame.POSIXct()
> >> anywhere directly in my code.
> >>
> >> When I dive into the code where the warnings occur I see patterns like:
> >>
> >> ```
> >> now = Sys.time()
> >> df = data.frame (time = seq(now, now + 10, by =1),  B  = 1:11)
> >> ```
> >>
> >> (this is a simplification of for example:
> >>
> https://github.com/wadpac/GGIR/blob/master/tests/testthat/test_read.myacc.csv.R
> >>
> >> )
> >>
> >> Does this mean I am discouraged from putting a vector with POSIXct
> >> values
> >> in a data.frame?
> >> If yes, what would be the recommended work around?
> >>
> >> I have been trying to find documentation or online discussions about
> >> this
> >> warning but no luck so far. I see R NEWS
> >> <https://cran.r-project.org/doc/manuals/r-release/NEWS.html> mentions
> >> updates to POSIXct related objects several times in the past year but
> >> those
> >> seem to be different issues.
> >>
> >> Best,
> >>
> >> Vincent
> >>
> >> [[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] Warning 'as.data.frame.POSIXct()' is deprecated

[Vincent van Hees]

Dear all,

I see the following warning in my package test results:

```
Warning
Direct call of 'as.data.frame.POSIXct()' is deprecated.  Use
'as.data.frame.vector()' or 'as.data.frame()' instead
```

The warning is not always there and I struggle to make it reproducible. I
have encountered it in both Ubuntu 22.04 and in Windows 11, in both R 4.3.0
and 4.3.1, in both RStudio and in an GitHub Actions environment (example
).
The warning gives the impression that I am doing something that R no longer
supports. However, I am not using the command as.data.frame.POSIXct()
anywhere directly in my code.

When I dive into the code where the warnings occur I see patterns like:

```
now = Sys.time()
df = data.frame (time = seq(now, now + 10, by =1),  B  = 1:11)
```

(this is a simplification of for example:
https://github.com/wadpac/GGIR/blob/master/tests/testthat/test_read.myacc.csv.R
)

Does this mean I am discouraged from putting a vector with POSIXct values
in a data.frame?
If yes, what would be the recommended work around?

I have been trying to find documentation or online discussions about this
warning but no luck so far. I see R NEWS
 mentions
updates to POSIXct related objects several times in the past year but those
seem to be different issues.

Best,

Vincent

[[alternative HTML version deleted]]

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

[R-pkg-devel] Guidance on splitting up an R package?

[Vincent van Hees]

Dear all,

I am looking for guidance (blog posts / books / people with expertise) on
how to split up an R package that has grown a lot in complexity and size.
To make it worthwhile, the split needs to ease the maintenance and ongoing
development.

Here are my quick reflections on it:
1. Where possible try to preserve the consistency of the original R
package. So, spin-off packages should ideally become helper-packages to the
original package and tests need to be in place to ensure compatibility of
the original R package is preserved.
2. Keep similar functionality together. For example, a function to read
files does not have to be in the same package as a function to plot the
data, but a function to adjust the color coding of the plots should be
stored near the other plotting functions.
3. Try to isolate external dependencies. For example, if dependency Y
changes I ideally only have to worry about updating one of my R packages to
it instead of several.

I am wondering whether anyone else has ever made a more elaborate mapping
of do's and don'ts when it comes to splitting up an R package or any
software for that matter?

Vincent

[[alternative HTML version deleted]]

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

[R-pkg-devel] Load data inside .Rd documentation file inside the item-field?

[Vincent van Hees]

Dear list,

Is it possible in .Rd documentation to load and use data inside an
item-field like we can integrate R data in text in R markdown files?

Something along the lines of:
\item{max}{
  Numeric, default value = `R max`, controls the upper limit of the plot.
}
where `R max` resolves into the actual default value.

I am guessing this is not possible, but it would be great if someone could
either confirm or point me to the actual way to do this.

Full story with clarification for why I am trying to do this:
The R package I maintain has a function that acts as a data processing
pipeline with over a hundred configuration arguments. Given that it is bad
practice to write a function with this number of input arguments, I use
parameter objects that hold sets of arguments. These objects are then
passed on to the pipeline function. The default values for the parameter
objects are stored in a separate function load_params() that aids in
loading the defaults. Although it makes the code a lot easier to navigate,
it also means that the user will no longer find default argument values in
the standard package documentation.

As a solution I can write a package vignette that loads and displays all
the default argument values. However, for those more oriented towards using
the ? command to get help about the function, it would be nice if the same
default arguments values are also shown in the package documentation, being
the .Rd files accessed via .pdf or with ? in R.

Thanks, Vincent

[[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 feature suggestion: Duplicated function arguments check

[Vincent van Hees]

Thanks for your replies, I only just noticed them as I had daily-digest =
true and someone seems to have removed my e-mail address when replying to
the list. Never mind, I have now switched my daily-digest to false.

Yes - The issue is that "myfun(A = 1, B = 2, B = 4)" in the example below
is ambiguous and only the end-user knows whether B should be 2 or 4.
Either way, I will just implement my own solution. Just wanted to report
that I ran into this situation and maybe others too.

Best, Vincent



On Mon, 8 Nov 2021 at 17:24, Vincent van Hees 
wrote:

> Thanks Duncan, I have tried to make a minimalistic example:
>
> myfun = function(...) {
>   input = list(...)
>   mysum = function(A = c(), B= c()) {
> return(A+B)
>   }
>   if ("A" %in% names(input) & "B" %in% names(input)) {
> print(mysum(A = input$A, B = input$B))
>   }
> }
>
> # test:
> > myfun(A = 1, B = 2, B = 4)
> [1] 3
>
> # So, the second B is ignored.
>
>
>
> On Mon, 8 Nov 2021 at 17:03, Duncan Murdoch 
> wrote:
>
>> On 08/11/2021 10:29 a.m., Vincent van Hees wrote:
>> > Not sure if this is the best place to post this message, as it is more
>> of a
>> > suggestion than a question.
>> >
>> > When an R function accepts more than a handful of arguments there is the
>> > risk that users accidentally provide arguments twice, e.g myfun(A=1,
>> B=2,
>> > C=4, D=5, A=7), and if those two values are not the same it can have
>> > frustrating side-effects. To catch this I am planning to add a check for
>> > duplicated arguments, as shown below, in one of my own functions. I am
>> now
>> > wondering whether this would be a useful feature for R itself to
>> operate in
>> > the background when running any R function that has more than a certain
>> > number of input arguments.
>> >
>> > Cheers, Vincent
>> >
>> > myfun = function(...) {
>> >#check input arguments for duplicate assignments
>> >input = list(...)
>> >if (length(input) > 0) {
>> >  argNames = names(input)
>> >  dupArgNames = duplicated(argNames)
>> >  if (any(dupArgNames)) {
>> >for (dupi in unique(argNames[dupArgNames])) {
>> >  dupArgValues = input[which(argNames %in% dupi)]
>> >  if (all(dupArgValues == dupArgValues[[1]])) { # double
>> arguments,
>> > but no confusion about what value should be
>> >warning(paste0("\nArgument ", dupi, " has been provided more
>> than
>> > once in the same call, which is ambiguous. Please fix."))
>> >  } else { # double arguments, and confusion about what value
>> should
>> > be,
>> >stop(paste0("\nArgument ", dupi, " has been provided more
>> than
>> > once in the same call, which is ambiguous. Please fix."))
>> >  }
>> >}
>> >  }
>> >}
>> ># rest of code...
>> > }
>> >
>>
>> Could you give an example where this is needed?  If a named argument is
>> duplicated, R will catch that and give an error message:
>>
>>> f(a=1, b=2, a=3)
>>Error in f(a = 1, b = 2, a = 3) :
>>  formal argument "a" matched by multiple actual arguments
>>
>> So this can only happen when it is an argument in the ... list that is
>> duplicated.  But usually those are passed to some other function, so
>> something like
>>
>>g <- function(...) f(...)
>>
>> would also catch the duplication in g(a=1, b=2, a=3):
>>
>>> g(a=1, b=2, a=3)
>>Error in f(...) :
>>  formal argument "a" matched by multiple actual arguments
>>
>> The only case where I can see this getting by is where you are never
>> using those arguments to match any formal argument, e.g.
>>
>>list(a=1, b=2, a=3)
>>
>> Maybe this should have been made illegal when R was created, but I think
>> it's too late to outlaw now:  I'm sure there are lots of people making
>> use of this.
>>
>> Or am I missing something?
>>
>> Duncan Murdoch
>>
>

[[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 feature suggestion: Duplicated function arguments check

[Vincent van Hees]

Thanks Duncan, I have tried to make a minimalistic example:

myfun = function(...) {
  input = list(...)
  mysum = function(A = c(), B= c()) {
return(A+B)
  }
  if ("A" %in% names(input) & "B" %in% names(input)) {
print(mysum(A = input$A, B = input$B))
  }
}

# test:
> myfun(A = 1, B = 2, B = 4)
[1] 3

# So, the second B is ignored.



On Mon, 8 Nov 2021 at 17:03, Duncan Murdoch 
wrote:

> On 08/11/2021 10:29 a.m., Vincent van Hees wrote:
> > Not sure if this is the best place to post this message, as it is more
> of a
> > suggestion than a question.
> >
> > When an R function accepts more than a handful of arguments there is the
> > risk that users accidentally provide arguments twice, e.g myfun(A=1, B=2,
> > C=4, D=5, A=7), and if those two values are not the same it can have
> > frustrating side-effects. To catch this I am planning to add a check for
> > duplicated arguments, as shown below, in one of my own functions. I am
> now
> > wondering whether this would be a useful feature for R itself to operate
> in
> > the background when running any R function that has more than a certain
> > number of input arguments.
> >
> > Cheers, Vincent
> >
> > myfun = function(...) {
> >#check input arguments for duplicate assignments
> >input = list(...)
> >if (length(input) > 0) {
> >  argNames = names(input)
> >  dupArgNames = duplicated(argNames)
> >  if (any(dupArgNames)) {
> >for (dupi in unique(argNames[dupArgNames])) {
> >  dupArgValues = input[which(argNames %in% dupi)]
> >  if (all(dupArgValues == dupArgValues[[1]])) { # double
> arguments,
> > but no confusion about what value should be
> >warning(paste0("\nArgument ", dupi, " has been provided more
> than
> > once in the same call, which is ambiguous. Please fix."))
> >  } else { # double arguments, and confusion about what value
> should
> > be,
> >stop(paste0("\nArgument ", dupi, " has been provided more than
> > once in the same call, which is ambiguous. Please fix."))
> >  }
> >}
> >  }
> >}
> ># rest of code...
> > }
> >
>
> Could you give an example where this is needed?  If a named argument is
> duplicated, R will catch that and give an error message:
>
>> f(a=1, b=2, a=3)
>Error in f(a = 1, b = 2, a = 3) :
>  formal argument "a" matched by multiple actual arguments
>
> So this can only happen when it is an argument in the ... list that is
> duplicated.  But usually those are passed to some other function, so
> something like
>
>g <- function(...) f(...)
>
> would also catch the duplication in g(a=1, b=2, a=3):
>
>> g(a=1, b=2, a=3)
>Error in f(...) :
>  formal argument "a" matched by multiple actual arguments
>
> The only case where I can see this getting by is where you are never
> using those arguments to match any formal argument, e.g.
>
>list(a=1, b=2, a=3)
>
> Maybe this should have been made illegal when R was created, but I think
> it's too late to outlaw now:  I'm sure there are lots of people making
> use of this.
>
> Or am I missing something?
>
> Duncan Murdoch
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] R feature suggestion: Duplicated function arguments check

[Vincent van Hees]

Not sure if this is the best place to post this message, as it is more of a
suggestion than a question.

When an R function accepts more than a handful of arguments there is the
risk that users accidentally provide arguments twice, e.g myfun(A=1, B=2,
C=4, D=5, A=7), and if those two values are not the same it can have
frustrating side-effects. To catch this I am planning to add a check for
duplicated arguments, as shown below, in one of my own functions. I am now
wondering whether this would be a useful feature for R itself to operate in
the background when running any R function that has more than a certain
number of input arguments.

Cheers, Vincent

myfun = function(...) {
  #check input arguments for duplicate assignments
  input = list(...)
  if (length(input) > 0) {
argNames = names(input)
dupArgNames = duplicated(argNames)
if (any(dupArgNames)) {
  for (dupi in unique(argNames[dupArgNames])) {
dupArgValues = input[which(argNames %in% dupi)]
if (all(dupArgValues == dupArgValues[[1]])) { # double arguments,
but no confusion about what value should be
  warning(paste0("\nArgument ", dupi, " has been provided more than
once in the same call, which is ambiguous. Please fix."))
} else { # double arguments, and confusion about what value should
be,
  stop(paste0("\nArgument ", dupi, " has been provided more than
once in the same call, which is ambiguous. Please fix."))
}
  }
}
  }
  # rest of code...
}

[[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] URL in RMarkdown file (libcurl error code 35)

[Vincent van Hees]

Sorry, you can ignore my question:
Uwe Liges clarified to me that the other error in my CRAN submission check
is definitely a problem I need to address.
And from this post by Hadley on Twitter I conclude that the URL warning can
be ignored: https://twitter.com/hadleywickham/status/1358170607314235392
Best,
Vincent




On Wed, 17 Feb 2021 at 16:32, Vincent van Hees 
wrote:

> Hello,
> My R package submission got rejected today because of the URL libcurl
> error code 35 issue below (see heading Attempt 1). It seems I have a
> subscription to these errors, because I have been getting them a lot
> through the years. Next, I edited the URL and submitted the package to
> R-devel on win-builder.r-project.org, but there it got flagged again. I
> am struggling to resolve this. Please find below an overview of all my
> attempts so far..
> Could anyone tell me what I am doing wrong?
> Thanks, Vincent
>
> Attempt 1: Warning after CRAN submission
>
> Flavor: r-devel-windows-ix86+x86_64 Check: CRAN incoming feasibility,
> Result: NOTE Maintainer: 'Vincent T van Hees '
> Found the following (possibly) invalid URLs: URL:
> https://journals.humankinetics.com/view/journals/jmpb/2/3/article-p188.xml
> From: inst/doc/GGIR.html Status: Error Message: libcurl error code 35:
> schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
> (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
> received (e.g. handshake failed).
>
> Attemp 2: This is what I submitted to win-builder R-devel. In comparison
> to the CRAN submission this has the doi URL instead of the full journal
> URL.:
>
> Found the following (possibly) invalid URLs: URL:
> https://doi.org/10.1123/jmpb.2018-0063 From: inst/doc/GGIR.html Status:
> Error Message: libcurl error code 35: schannel: next
> InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This
> error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake
> failed).
>
> Attempt 3:
> Putting a URLencode() statement around the URL was suggested somewhere,
> e.g.
> [link](URLencode("https://doi.org/10.1123/jmpb.2018-0063";)),  but this
> breaks the URL on my local machine.
>
> Attempt 4: Curl test (in Ubuntu with curl version 7.68) for the journal
> url to see whether this provides any insight:
>
> vincent@vincent:~$ curl -Is
> https://journals.humankinetics.com/view/journals/jmpb/2/3/article-p188.xml
> HTTP/1.1 200 OK
> server: Apache-Coyote/1.1
> set-cookie: JSESSIONID=AF4859DD2D01CF4E1C16EE530712A13F; Path=/; Secure;
> HttpOnly
> content-type: text/html;charset=UTF-8
> transfer-encoding: chunked
> date: Wed, 17 Feb 2021 15:14:04 GMT
> content-security-policy: frame-ancestors 'self'
> set-cookie: ServerID=hk-web-live-bot24; path=/
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] URL in RMarkdown file (libcurl error code 35)

[Vincent van Hees]

Hello,
My R package submission got rejected today because of the URL libcurl error
code 35 issue below (see heading Attempt 1). It seems I have a subscription
to these errors, because I have been getting them a lot through the years.
Next, I edited the URL and submitted the package to R-devel on
win-builder.r-project.org, but there it got flagged again. I am struggling
to resolve this. Please find below an overview of all my attempts so far..
Could anyone tell me what I am doing wrong?
Thanks, Vincent

Attempt 1: Warning after CRAN submission

Flavor: r-devel-windows-ix86+x86_64 Check: CRAN incoming feasibility,
Result: NOTE Maintainer: 'Vincent T van Hees '
Found the following (possibly) invalid URLs: URL:
https://journals.humankinetics.com/view/journals/jmpb/2/3/article-p188.xml
From: inst/doc/GGIR.html Status: Error Message: libcurl error code 35:
schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
(0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
received (e.g. handshake failed).

Attemp 2: This is what I submitted to win-builder R-devel. In comparison to
the CRAN submission this has the doi URL instead of the full journal URL.:

Found the following (possibly) invalid URLs: URL:
https://doi.org/10.1123/jmpb.2018-0063 From: inst/doc/GGIR.html Status:
Error Message: libcurl error code 35: schannel: next
InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This
error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake
failed).

Attempt 3:
Putting a URLencode() statement around the URL was suggested somewhere, e.g.
[link](URLencode("https://doi.org/10.1123/jmpb.2018-0063";)),  but this
breaks the URL on my local machine.

Attempt 4: Curl test (in Ubuntu with curl version 7.68) for the journal url
to see whether this provides any insight:

vincent@vincent:~$ curl -Is
https://journals.humankinetics.com/view/journals/jmpb/2/3/article-p188.xml
HTTP/1.1 200 OK
server: Apache-Coyote/1.1
set-cookie: JSESSIONID=AF4859DD2D01CF4E1C16EE530712A13F; Path=/; Secure;
HttpOnly
content-type: text/html;charset=UTF-8
transfer-encoding: chunked
date: Wed, 17 Feb 2021 15:14:04 GMT
content-security-policy: frame-ancestors 'self'
set-cookie: ServerID=hk-web-live-bot24; path=/

[[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] url checks not working for me

[Vincent van Hees]

Addressing the errors is not the problem. I want to be able to detect these
problems when I do: R CMD check --as-cran.
At the moment, I can only detect the errors by submitting the package to
CRAN, because only their package check triggers these errors.

On Wed, 26 Aug 2020 at 14:30, Bryan Hanson  wrote:

> At the minimum you should look at the “moved to” URLs and change your
> links to those (some are outright changes in URLs that were redirected and
> some are http to https changes).
>
> Bryan
>
> > On Aug 26, 2020, at 8:22 AM, Vincent van Hees 
> wrote:
> >
> > Hello,
> > URL errors in my DESCRIPTION file and package vignette are not picked up
> > when I do R CMD check --as-cran or devtools::check(). I only know about
> > these errors because CRAN has rejected my package submission and
> instructed
> > me to fix the urls (example at end of this message).
> >
> > I am trying to figure out how I can get R CMD check --as-cran to detect
> > these URL mistakes. From
> > https://cran.r-project.org/web/packages/URL_checks.html I understand
> that I
> > need libcurl installed, which I have.
> >
> > Can anyone tell me whether I am using the wrong combination of libcurl
> > version, R version, and Ubuntu version? (see versions below). If not,
> what
> > else can I do to get the URL checks to work?
> >
> > Thanks, Vincent
> >
> > vincent@vincent-VB:~$ curl-config --version
> > *libcurl 7.58.0*
> >
> > vincent@vincent-VB:~$ curl -V
> > *curl 7.58.0* (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1
> > zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0
> > librtmp/2.3
> > Release-Date: 2018-01-24
> > Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> pop3
> > pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
> > Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM
> NTLM_WB
> > SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
> >
> > vincent@vincent-VB:~$ R --version
> > *R version 4.0.2* (2020-06-22) -- "Taking Off Again"
> > Copyright (C) 2020 The R Foundation for Statistical Computing
> > Platform: x86_64-pc-linux-gnu (64-bit)
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under the terms of the
> > GNU General Public License versions 2 or 3.
> > For more information about these matters see
> > https://www.gnu.org/licenses/.
> >
> > vincent@vincent-VB:~$ lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Ubuntu
> > Description: *Ubuntu 18.04.5 LTS*
> > Release: 18.04
> > Codename: bionic
> >
> > Example of most recent URL mistakes in my package detected by CRAN
> package
> > submission process which I could not detect locally:
> > Found the following (possibly) invalid URLs: URL:
> > http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533
> > (moved to
> >
> https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533)
> > From: inst/CITATION Status: 200 Message: OK URL: https://geneactiv.org/
> > (moved to https://www.activinsights.com/) From: inst/doc/GGIR.html
> Status:
> > 200 Message: OK URL: https://www.accelting.com/ (moved to
> > https://accelting.com/) From: inst/doc/GGIR.html Status: 200 Message: OK
> > URL: https://www.physiology.org/doi/10.1152/japplphysiol.00421.2014
> (moved
> > to https://journals.physiology.org/doi/10.1152/japplphysiol.00421.2014)
> > From: inst/CITATION Status: 200 Message: OK
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] url checks not working for me

[Vincent van Hees]

Hello,
URL errors in my DESCRIPTION file and package vignette are not picked up
when I do R CMD check --as-cran or devtools::check(). I only know about
these errors because CRAN has rejected my package submission and instructed
me to fix the urls (example at end of this message).

I am trying to figure out how I can get R CMD check --as-cran to detect
these URL mistakes. From
https://cran.r-project.org/web/packages/URL_checks.html I understand that I
need libcurl installed, which I have.

Can anyone tell me whether I am using the wrong combination of libcurl
version, R version, and Ubuntu version? (see versions below). If not, what
else can I do to get the URL checks to work?

Thanks, Vincent

vincent@vincent-VB:~$ curl-config --version
*libcurl 7.58.0*

vincent@vincent-VB:~$ curl -V
*curl 7.58.0* (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1
zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0
librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB
SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

vincent@vincent-VB:~$ R --version
*R version 4.0.2* (2020-06-22) -- "Taking Off Again"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
https://www.gnu.org/licenses/.

vincent@vincent-VB:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: *Ubuntu 18.04.5 LTS*
Release: 18.04
Codename: bionic

Example of most recent URL mistakes in my package detected by CRAN package
submission process which I could not detect locally:
Found the following (possibly) invalid URLs: URL:
http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533
(moved to
https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533)
From: inst/CITATION Status: 200 Message: OK URL: https://geneactiv.org/
(moved to https://www.activinsights.com/) From: inst/doc/GGIR.html Status:
200 Message: OK URL: https://www.accelting.com/ (moved to
https://accelting.com/) From: inst/doc/GGIR.html Status: 200 Message: OK
URL: https://www.physiology.org/doi/10.1152/japplphysiol.00421.2014 (moved
to https://journals.physiology.org/doi/10.1152/japplphysiol.00421.2014)
From: inst/CITATION Status: 200 Message: OK

[[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] My test passes in OSx on Travis, but not in OSx on CRAN

[Vincent van Hees]

Thanks Tomas for your quick response, that sounds like a very plausible
explanation.
I will make those corrections and will start prepare a new release.
Best, Vincent



On Fri, 13 Sep 2019 at 13:30, Tomas Kalibera 
wrote:

> The error seems to be because you are trying to write to the user's home
> directory. This is not allowed. Probably by accident your test creates
> "~/testcsv4.csv" (the same problem is present for other test files).
>
> Best
> Tomas
>
> On 9/13/19 1:21 PM, Vincent van Hees wrote:
> > Dear all,
> >
> > I have a test in my R package that passes in OSx on Travis-CI, but it
> does
> > not pass in OSx on CRAN. What does pass on both CRAN and Travis are the
> > Linux tests. Also, on CRAN the Windows flavor passes. So, there seems to
> be
> > an issue specific to the combination OSx and CRAN.
> >
> > The easiest solution for me would be to add 'skip_on_cran()' at the top
> of
> > the test, but that would blind me for serious issues (if any). I already
> > made sure that the seeds are set before random number generators and that
> > value checks are limited to 3 decimal places to deal machine precision
> > issues. Does anyone have suggestions for me on what else I can do to
> > investigate this?
> >
> > Link
> > <
> https://github.com/wadpac/GGIR/blob/master/tests/testthat/test_read.myacc.csv.R
> >
> > to the specific test on GitHub. The function that is being tested first
> > creates dummy csv-files with random data and then checks that my wrapper
> > function around data.table() is able to read and interpret those dummy
> > files.
> > Link <https://cran.r-project.org/web/checks/check_results_GGIR.html> to
> > CRAN results
> > Link <https://travis-ci.org/wadpac/GGIR> to Travis-CI page for the
> package
> >
> > I have a local Windows and Linux machine, but for OSx testing I depend on
> > Travis-CI.
> >
> > Thanks,
> > Vincent
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] My test passes in OSx on Travis, but not in OSx on CRAN

[Vincent van Hees]

Dear all,

I have a test in my R package that passes in OSx on Travis-CI, but it does
not pass in OSx on CRAN. What does pass on both CRAN and Travis are the
Linux tests. Also, on CRAN the Windows flavor passes. So, there seems to be
an issue specific to the combination OSx and CRAN.

The easiest solution for me would be to add 'skip_on_cran()' at the top of
the test, but that would blind me for serious issues (if any). I already
made sure that the seeds are set before random number generators and that
value checks are limited to 3 decimal places to deal machine precision
issues. Does anyone have suggestions for me on what else I can do to
investigate this?

Link

to the specific test on GitHub. The function that is being tested first
creates dummy csv-files with random data and then checks that my wrapper
function around data.table() is able to read and interpret those dummy
files.
Link  to
CRAN results
Link  to Travis-CI page for the package

I have a local Windows and Linux machine, but for OSx testing I depend on
Travis-CI.

Thanks,
Vincent

[[alternative HTML version deleted]]

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

[R-pkg-devel] How to handle deprecated package dependency? 2 suggestions 1 question

[Vincent van Hees]

Dear all,

One of my package dependencies was taken from CRAN a month ago, with
the CRAN message: "...check problems were not corrected despite
reminders" as displayed on the deprecated CRAN package page. I
immediately got in touch with the deprecated package maintainer and
learnt that he is trying to resolve the issue(s).

My suggestions/questions:

1 - Would it be an idea for CRAN to inform reverse dependency package
maintainers when a package is at risk of being taken from CRAN? For
example, by cc-ing them in the warning message? I think such a
heads-up could have helped to prevent the situation.

2 - At the moment the CRAN page for the deprecated package does not
tell me what I can do to help fix the issue:

"Package ‘GENEAread’ was removed from the CRAN repository.
Formerly available versions can be obtained from the archive.
Archived on 2018-05-25 as check problems were not corrected despite reminders".

Would it be an idea to display what those problems were to make it
easier for others, like me, to help fix the issue(s)?

3 - Can you advise on how I can help address the situation, such that
I can upload a much needed update to my own CRAN package GGIR? The
approaches I can think of are: (A) Help the deprecated package
maintainer to fix their issues, which may not be easy, (B) copy the
old code of the deprecated package and create an entirely new but
fixed CRAN package from it myself stripped to only the functionality I
need, which is not ideal of course, or (C) Kindly ask CRAN to put the
deprecated package back online for a couple of months while we look
out for a better solution?

Thanks,
Vincent

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