Re: [Rd] paths capability FALSE on devel?

[Alexandre Courtiol]

On Wed, 27 Mar 2024 at 12:19, Ivan Krylov  wrote:

> В Wed, 27 Mar 2024 11:28:17 +0100
> Alexandre Courtiol  пишет:
>
> > after installing R-devel the output of
> > grDevices::dev.capabilities()$paths is FALSE, while it is TRUE for R
> > 4.3.3
>
> Your system must be missing Cairo development headers, making x11()
> fall back to type = 'Xlib':
>
> $ R-devel -q -s -e 'x11(); grDevices::dev.capabilities()$paths'
>  [1] TRUE
> $ R-devel -q -s -e \
>  'x11(type="Xlib"); grDevices::dev.capabilities()$paths'
>  [1] FALSE
>
> If that's not the case and capabilities()['cairo'] is TRUE in your
> build of R-devel, please show us the sessionInfo() from your build of
> R-devel.
>
> --
> Best regards,
> Ivan
>

Thanks everyone for your feedback.
Here is the requested information:

> x11()
> grDevices::dev.capabilities()$paths
[1] FALSE
> capabilities()['cairo']
cairo
TRUE
> sessionInfo()
R version 4.3.3 Patched (2024-02-29 r86166)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04.4 LTS

Matrix products: default
BLAS:   /home/courtiol/R-devel/lib/R/lib/libRblas.so
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.10.0

locale:
[1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8   LC_NAME=C
[9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

time zone: Europe/Berlin
tzcode source: system (glibc)

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.3.3

However, since it works on your side, I think there is nothing to worry
about, I must have simply failed to install R-devel properly.

-- 
Alexandre Courtiol, www.datazoogang.de

[[alternative HTML version deleted]]

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

[Rd] paths capability FALSE on devel?

[Alexandre Courtiol]

Hi all,

I don't know if it is a local issue on my hands or not, but after
installing R-devel the output of grDevices::dev.capabilities()$paths is
FALSE, while it is TRUE for R 4.3.3.
Relatedly, I have issues with plotting paths on devel.

At this stage, I simply would like to know if others running R devel and R
4.3.3 can replicate this behaviour and if there are obvious reasons why the
observed change would be expected.

Man thanks,

Alex
-- 
Alexandre Courtiol, www.datazoogang.de

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] The problem with resubmitting the package to the Cran

[Alexandre Courtiol]

Dear Karolina,
It means that you have an unexpected file or folder called
"PARMA21del1_ident" inside your package.
So either remove it or list it in a file called .Rbuildignore which you
place at the root of the package folder.
Best,
Alex

On Thu, 9 Nov 2023 at 09:57, Karolina Marek 
wrote:

> Hello,
>
> I have the following case. I would like to resubmit a package to the Cran -
> per ARMA, which was archived on 2022-05-25, as it required the archived
> package 'matlab'. The new version of the 'matlab' was resubmitted to the
> Cran on 2022-06-01. So we would like that our package will also return to
> the Cran. I didn't change anything significant in the code inside. However,
> when I try to submit the package, I receive the following NOTES:
>
>  checking CRAN incoming feasibility ... NOTE
>
> * checking for non-standard things in the check directory ... NOTE
> Found the following files/directories:
>   ‘PARMA21del1_ident'
>
> I don't know really what this note mean and can I put the package
> anyway to Cran?
>
>
>
> Best regards,
>
> Karolina
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol, www.datazoogang.de

[[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] Warning from orphaned package on check page

[Alexandre Courtiol]

Dear Liam,
I don't understand your question: if your package has plotrix listed as a
dependency, it won't affect plotrix.
Only the opposite would be true. Could you please clarify and indicate
which package you are referring to?
Thanks,
Alex



On Thu, 9 Nov 2023 at 09:57, Liam J. Revell  wrote:

> Dear colleagues.
>
> I'm trying to update a package on CRAN containing a dependency
> (specifically, on the popular graphing package 'plotrix') that has been
> orphaned because the maintainer is deceased.
>
> 'plotrix' is imported by well over 100 other CRAN packages, so I hope it
> is not removed from CRAN. On the other hand, I don't want to certify
> that 'I have fixed all problems shown on the package check page' if this
> is not, in fact, the case.
>
> Can anyone comment on how one might proceed in this situation?
>
> Thank you. -- Liam
>
> --
> Liam J. Revell
> Professor of Biology, University of Massachusetts Boston
> Web: http://faculty.umb.edu/liam.revell/
> Book: Phylogenetic Comparative Methods in R (Princeton University Press,
> 2022)
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol, www.datazoogang.de

[[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 with package containing spatial data

[Alexandre Courtiol]

Hi Igor,

I had the same issue using terra rather than sf a couple of weeks ago.

I thought of solving the issue as follow:


   1.

   store the shapefiles under extdata.
   2.

   create a function that loads the files:

.build_internal_files <- function() {
  ## This function should not be called by the user.
  ## It performs the lazy loading of the data since terra cannot
handle rda files
  assign("CountryBorders",
terra::vect(system.file("extdata/CountryBorders.shp", package =
"IsoriX")), envir = as.environment("package:IsoriX"))
  assign("OceanMask", terra::vect(system.file("extdata/OceanMask.shp",
package = "IsoriX")), envir = as.environment("package:IsoriX"))
}


   1. call that function automatically upon attach using .onAttach():

.onAttach <- function(libname, pkgname) {
.build_internal_files() ## lazy loading of the internal data
}

It seems to work...

Note that .onAttach() is a standard way of defining a function that is
recognised by R and ran when the package is attached.

++

Alex

On Thu, 9 Feb 2023 at 11:11, Duncan Murdoch 
wrote:

> On 09/02/2023 3:56 a.m., Ivan Krylov wrote:
> > В Wed, 8 Feb 2023 11:32:36 -0300
> > Igor L  пишет:
> >
> >> spatial_aisp <- sf::st_read('data-raw/shp_aisp/lm_aisp_2019.shp')
> >>
> >> plot(spatial_aisp) # works
> >>
> >> # Same data from .rda file after use usethis::use_data(spatial_aisp,
> >> overwrite = TRUE)
> >>
> >> x <- ispdata::spatial_aisp
> >>
> >> plot(x) # do not work
> >
> > Does this break in a new R session, but start working when you load the
> > sf namespace? I think that your package needs to depend on sf in order
> > for this to work. Specifying it in Imports may be enough to make the
> > plot.sf S3 method available to the user.
>
> Specifying a package in the Imports field of DESCRIPTION guarantees that
> it will be available to load, but doesn't load it.  Importing something
> from it via the NAMESPACE triggers a load, as does executing code like
> pkg::fn, or explicitly calling loadNamespace("pkg"), or loading a
> package that does one of these things.
>
>
> > You may encounter other problems if you go this way, like R CMD check
> > complaining that you don't use the package you're importing. Loading
> > the data from a file on demand would also load the sf namespace and
> > thus solve the problem.
>
> Workarounds for the check complaints are discussed here, among other
> places:  https://stackoverflow.com/a/75384338/2554330 .
>
> Duncan Murdoch
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol, www.datazoogang.de

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] no visible binding for global variable ‘degree_C’ - CRAN check note

[Alexandre Courtiol]

Irucka,
If you saw still have the note "no visible binding for global variable
‘degree_C’", it implies that somewhere in your package degree_C is still
unquotted...
Do you have your code online for us to help you more effectively?
++

On Mon, 12 Dec 2022 at 17:20, EcoC2S - Irucka Embry 
wrote:

> Hi Iñaki and Andrew, I'm sorry, I'll clarify my statement here.
>
> set_units(T, "degree_C") still produced the R CMD check note, but it
> works with regards to setting the unit for the R expression.
>
> I replaced every instance of set_units(T, degree_C) with set_units(T,
> "degree_C") in a single function (I use the units package throughout
> many functions in my iemisc package) & than I ran R CMD check again. I
> looked for that particular function in the "checking R code for possible
> problems ..." section and I still saw the function name with this note:
> no visible binding for global variable ‘degree_C’.
>
> Using the global variables option does prevent the note from occurring
> in all of my other functions where I set units.
>
> I hope that this clarification helps.
>
> On a side note, I used the units package in other functions; however, I
> have not ever seen a note for the same usage in other functions. I don't
> know why the same usage of the units package in some functions draws a
> note while in other functions there is no note.
>
> Thank you.
>
> Irucka
>
>
> On 12-12-2022 09:58, Iñaki Ucar wrote:
> > On Mon, 12 Dec 2022 at 16:43, EcoC2S - Irucka Embry 
> > wrote:
> >>
> >> Hi Andrew, set_units(T, "degree_C") does not work;
> >
> > Sorry, do you mean that the code fails? Or the code works but you
> > still see the NOTE? In this case, it is possible that you didn't
> > replace all the instances of set_units(T, degree_C) in your files.
> >
> > Iñaki
> >
> >> however, setting
> >> degree_C as a global variable does work.
> >>
> >> Thank you for your suggestion.
> >>
> >> Irucka
> >>
> >>
>
> On 12-12-2022 09:56, Alexandre Courtiol wrote:
> > Hi Irucka,
> > using text to define the unit is valid, so I don't see why it would
> > not work.
> > It would be better than defining a global variable.
> >
> > ``` rT <- 2
> > units::set_units(T, "degree_C")
> > #> 2 [°C]
> > ```
> > Created on 2022-12-12 with [reprex
> > v2.0.2](https://reprex.tidyverse.org)
> >
> > ++
> >
>
> >> On 11-12-2022 00:29, Andrew Simmons wrote:
> >> > You can declare degree_C as a variable before using set_units():
> >> >
> >> > degree_C <- NULL
> >> > set_units(T, degree_C)
> >> >
> >> > you could use globalVariables() somewhere at the top-level in your
> >> > package:
> >> >
> >> > utils::globalVariables("degree_C")
> >> >
> >> > or you could supply degree_C as a literal character string:
> >> >
> >> > set_units(T, "degree_C")
> >> >
> >> > On Sat, Dec 10, 2022 at 11:13 PM EcoC2S - Irucka Embry
> >> >  wrote:
> >> >>
> >> >> In my iemisc package, I am using the units package.
> >> >>
> >> >> This is an example of how I am using the set_units function:
> >> >>
> >> >> T <- 20
> >> >>
> >> >> set_units(T, degree_C)
> >> >>
> >> >> Upon checking iemisc with devtools for CRAN submission, I receive the
> >> >> following note under "checking R code for possible problems":
> >> >>
> >> >> no visible binding for global variable ‘degree_C’
> >> >>
> >> >> Please tell me how to avoid that note in my R packages.
> >> >>
> >> >> Thank you.
> >> >>
> >> >> Irucka
> >> >>
> >> >> --
> >> >> --
> >> >> No fear, Only Love! / ¡No temas, solamente amor!
> >> >> -Irucka Ajani Embry, 15 March 2020
> >> >>
> >> >> Family Partners:
> >> >> http://www.sustainlex.org/
> >> >> https://www.schoolingsolutions.com/
> >> >>
> >> >>
> ---
> >> >>
> >> >> The business collaboration between EConsulting (tm)
> >> >> [https://www.econsultingll

Re: [R-pkg-devel] How to Fix Debian and Linux Check Errors?

[Alexandre Courtiol]

Not sure this is random but all you errors appear on platform that seem to
use LC_CTYPE = C.UTF-8
https://cran.r-project.org/web/checks/check_flavors.html#r-release-linux-x86_64
I would start digging in this direction...

On Mon, 12 Dec 2022 at 14:13, Ismail Otoakhia  wrote:

> I received the link below from CRAN
> https://cran.r-project.org/web/checks/check_results_ardl.nardl.html
>
> I cannot reproduce the error in the example files. Also, I have no idea how
> to fix the error on the r-devel-linux-x86_64-debian-gcc
> <
> https://cran.r-project.org/web/checks/check_flavors.html#r-devel-linux-x86_64-debian-gcc
> >
>  , r-patched-linux-x86_64
> <
> https://cran.r-project.org/web/checks/check_flavors.html#r-patched-linux-x86_64
> >
>  and r-release-linux-x86_64
> <
> https://cran.r-project.org/web/checks/check_flavors.html#r-release-linux-x86_64
> >
>
> Where do I start and how can this error be fixed?
>
> Thanks
>
> E. I Otoakhia
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol, www.datazoogang.de

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] no visible binding for global variable ‘degree_C’ - CRAN check note

[Alexandre Courtiol]

 set_units(T, "degree_C") ## using quotes will prevent the R CMD check note
and will still work in this case.

On Sun, 11 Dec 2022 at 05:13, EcoC2S - Irucka Embry 
wrote:

> In my iemisc package, I am using the units package.
>
> This is an example of how I am using the set_units function:
>
> T <- 20
>
> set_units(T, degree_C)
>
> Upon checking iemisc with devtools for CRAN submission, I receive the
> following note under "checking R code for possible problems":
>
> no visible binding for global variable ‘degree_C’
>
> Please tell me how to avoid that note in my R packages.
>
> Thank you.
>
> Irucka
>
> --
> --
> No fear, Only Love! / ¡No temas, solamente amor!
> -Irucka Ajani Embry, 15 March 2020
>
> Family Partners:
> http://www.sustainlex.org/
> https://www.schoolingsolutions.com/
>
>
> ---
>
> The business collaboration between EConsulting (tm)
> [https://www.econsultingllc.org/] and EcoC^2S, is Getting Back to
> Nature.
>
> Getting Back to Nature LocalHarvest --
> https://www.localharvest.org/getting-back-to-nature-M73453
> Getting Back to Nature -- https://www.gettingback2nature.farm/
>
> -- Irucka and his twin brother, Obiora, are featured in the Middle
> Tennessee Local Table Magazine Annual issue. The article discusses their
> family farm history and the current work that they are doing under
> Getting
> Back to Nature. The full magazine can be found here [the article begins
> on
> page 18 of the PDF document]:
>
> https://media.gettingback2nature.farm/pdf/LocalTable_ANNUAL_2020_lo_res.pdf
>
> -- Obiora and Irucka were interviewed separately in early 2020 for the
> Natural Resources Defense Council's (NRDC) "Regenerative Agriculture:
> Farm
> Policy for the 21st Century: Policy Recommendations to Advance
> Regenerative
> Agriculture" report written By Arohi Sharma, Lara Bryant, and Ellen Lee.
> The PDF report is available below:
>
>
> https://www.nrdc.org/sites/default/files/regenerative-agriculture-farm-policy-21st-century-report.pdf
>
> EcoC2S -- https://www.ecoccs.com/
> Principal, Irucka Embry, EIT
>
> Services:
> Growing Food
> Healthy Living Mentor
> Data Analysis with R
> R Training
> Chemistry and Mathematics Tutoring
> Free/Libre and Open Source Software (FLOSS) Consultation
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol, www.datazoogang.de

[[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 handling datetimes: possible differences between computers

[Alexandre Courtiol]

; > dput(as.POSIXlt(bar))
> > #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
> > #> year = 92L, wday = 0L, yday = 270L, isdst = 0L), class =
> c("POSIXlt",
> > #> "POSIXt"), tzone = "UTC")
> >
> > #Convert to POSIXct specifying Europe/Berlin
> > bar <- lubridate::as_datetime(foo, tz = "Europe/Berlin")
> > dput(as.POSIXlt(bar))
> > #> structure(list(sec = 0, min = 0L, hour = 0L, mday = 27L, mon = 8L,
> > #> year = 92L, wday = 0L, yday = 270L, isdst = 1L, zone = "CEST",
> > #> gmtoff = 7200L), class = c("POSIXlt", "POSIXt"), tzone =
> c("Europe/Berlin",
> > #> "CET", "CEST"))
> > ```
> >
> > Thanks again for all your help.
> > Alex & Liam
> >
> >> On 10 Oct 2022, at 6:40 pm, Hadley Wickham  wrote:
> >>
> >> On Sun, Oct 9, 2022 at 9:31 PM Jeff Newmiller 
> wrote:
> >>>
> >>> ... which is why tidyverse functions and Python datetime handling irk
> me so much.
> >>>
> >>> Is tidyverse time handling intrinsically broken? They have a standard
> practice of reading time as UTC and then using force_tz to fix the
> "mistake". Same as Python.
> >>
> >> Can you point to any docs that lead you to this conclusion so we can
> >> get them fixed? I strongly encourage people to parse date-times in the
> >> correct time zone; this is why lubridate::ymd_hms() and friends have a
> >> tz argument.
> >>
> >> Hadley
> >>
> >> --
> >> http://hadley.nz
> >
>
>

-- 
Alexandre Courtiol, www.datazoogang.de

[[alternative HTML version deleted]]

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

[R-pkg-devel] Issue handling datetimes: possible differences between computers

[Alexandre Courtiol]

Hi R pkg developers,

We are facing a datetime handling issue which manifests itself in a
package we are working on.

In context, we noticed that reading datetime info from an excel file
resulted in different data depending on the computer we used.

We are aware that timezone and regional settings are general sources
of troubles, but the code we are using was trying to circumvent this.
We went only as far as figuring out that the issue happens when
converting a POSIXlt into a POSIXct.

Please find below, a minimal reproducible example where `foo` is
converted to `bar` on two different computers.
`foo` is a POSIXlt with a defined time zone and upon conversion to a
POSIXct, despite using a set time zone, we end up with `bar` being
different on Linux and on a Windows machine.

We noticed that the difference emerges from the system call
`.Internal(as.POSIXct())` within `as.POSIXct.POSIXlt()`.
We also noticed that the internal function in R actually calls
getenv("TZ") within C, which is probably what explains where the
difference comes from.

Such a behaviour is probably expected and not a bug, but what would be
the strategy to convert a POSIXlt into a POSIXct that would not be
machine dependent?

We finally noticed that depending on the datetime used as a starting
point and on the time zone used when calling `as.POSIXct()`, we
sometimes have a difference between computers and sometimes not...
which adds to our puzzlement.

Many thanks.
Alex & Liam


``` r
## On Linux
foo <- structure(list(sec = 0, min = 0L, hour = 0L, mday = 1L, mon =
9L, year = 121L, wday = 5L, yday = 273L, isdst = 0L),
 class = c("POSIXlt", "POSIXt"), tzone = "UTC")

bar <- as.POSIXct(foo, tz = "Europe/Berlin")

bar
#> [1] "2021-10-01 01:00:00 CEST"

dput(bar)
#> structure(1633042800, class = c("POSIXct", "POSIXt"), tzone =
"Europe/Berlin")
```

``` r
## On Windows
foo <- structure(list(sec = 0, min = 0L, hour = 0L, mday = 1L, mon =
9L, year = 121L, wday = 5L, yday = 273L, isdst = 0L),
 class = c("POSIXlt", "POSIXt"), tzone = "UTC")

bar <- as.POSIXct(foo, tz = "Europe/Berlin")

bar
#> [1] "2021-10-01 CEST"

dput(bar)
structure(1633046400, class = c("POSIXct", "POSIXt"), tzone = "Europe/Berlin")
```

-- 
Alexandre Courtiol, www.datazoogang.de

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

Re: [R-pkg-devel] Warning about ggplot although no ggplot is used anywhere in the package

[Alexandre Courtiol]

Hi Riko,
That element_line() is called while loading is not a problem, this is
probably just the loading of the NAMESPACE from rstanarm.
There is nothing wrong with this function.
The problem is only when it is used with the argument `size = ` within it.
You need to figure out when that happens.
++



On Thu, 22 Sept 2022 at 15:49, Kelter, Riko 
wrote:

> Hello everyone,
>
>
> thanks a lot for the help.
>
>
> I tried the approach to use the trace function to identify where the
> element_line() command is actually used. In fact, the vignette
> twodimfbst.Rmd is the problem, but weirdly even if I only *load* the
> rstanarm package the trace function tells me that the code is used.
>
>
> Thus, it seems that one cannot even *load* the rstanarm package without
> getting this warning (see the appended PDF screenshot). In fact, the
> element_line() is identified by the trace function only if the rstanarm or
> fbst package are loaded inside the vignette. I also tried to replace
> rstanarm with rstan instead but the same happens because both packages rely
> on ggplot2.
>
>
> I also appended the .tar.gz package file so you can check the vignette
> code yourself if interested.
>
>
> Has anyone an idea how to avoid this warning on R devel when rstanarm is
> loaded inside a vignette? I currently see no way to solve this except for
> not using rstanarm which is inconvenient.
>
>
> Kind regards,
>
> Riko
>
>
>
>
>
>
> --
> *From:* Alexandre Courtiol 
> *Sent:* 22 September 2022 14:06
> *To:* Kelter, Riko
> *Cc:* r-package-devel@r-project.org
> *Subject:* Re: [R-pkg-devel] Warning about ggplot although no ggplot is
> used anywhere in the package
>
> In rstanarm, the function posterior_vs_prior and pp_validate use
> bayesplot::grid_lines which is defined as:
>
> function (color = "gray50", size = 0.2)
> {
> theme(panel.grid.major = element_line(color = color, size = size),
> panel.grid.minor = element_line(color = color, size = size *
> 0.5))
> }
>
> so bayesplot seems to be the culprit if you use these functions.
>
>
>
> On Thu, 22 Sept 2022 at 13:51, Alexandre Courtiol <
> alexandre.court...@gmail.com> wrote:
>
>> You could trace the ggplot function using trace(ggplot2::element_line)
>> and then load the package and run your examples.
>> Whenever the function is used in the background, it should tell you.
>> ++
>>
>>
>>
>> On Thu, 22 Sept 2022 at 13:40, Duncan Murdoch 
>> wrote:
>>
>>> On 21/09/2022 5:09 p.m., Riko Kelter wrote:
>>> > Hello everyone,
>>> >
>>> > I ran R CMD check --as-cran without any errors. However, when I run a
>>> check on the current version of r-devel I obtain the following strange
>>> error about some ggplot function:
>>> > * installing *source* package 'fbst' ...
>>> > ** using staged installation
>>> > ** R
>>> > ** inst
>>> > ** byte-compile and prepare package for lazy loading
>>> > Warning message:
>>> > The `size` argument of `element_line()` is deprecated as of ggplot2
>>> 3.4.0.
>>> > Please use the `linewidth` argument instead.
>>> > The weird thing is: Although my package fbst depends on the package
>>> rstanarm which itself imports ggplot,
>>> > (1) no package code uses ggplot in any form,
>>> > (2) no examples use any ggplot commands and
>>> > (3) no vignette uses any ggplot command.
>>> >
>>> > Logs are available at https://win-builder.r-project.org/CX36AbHDU6Tl/
>>> > I am thankful for any suggestion why this error occurs.
>>> > All the best and kind regards,
>>> > Riko
>>>
>>> Could you provide the source for the package?  I can see the DESCRIPTION
>>> file at win-builder, but can't install it myself since I don't use
>>> Windows.
>>>
>>> Duncan Murdoch
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>>
>> --
>> Alexandre Courtiol, www.datazoogang.de
>>
>
>
> --
> Alexandre Courtiol, www.datazoogang.de
>


-- 
Alexandre Courtiol, www.datazoogang.de

[[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] Warning about ggplot although no ggplot is used anywhere in the package

[Alexandre Courtiol]

In rstanarm, the function posterior_vs_prior and pp_validate use
bayesplot::grid_lines which is defined as:

function (color = "gray50", size = 0.2)
{
theme(panel.grid.major = element_line(color = color, size = size),
panel.grid.minor = element_line(color = color, size = size *
0.5))
}

so bayesplot seems to be the culprit if you use these functions.



On Thu, 22 Sept 2022 at 13:51, Alexandre Courtiol <
alexandre.court...@gmail.com> wrote:

> You could trace the ggplot function using trace(ggplot2::element_line)
> and then load the package and run your examples.
> Whenever the function is used in the background, it should tell you.
> ++
>
>
>
> On Thu, 22 Sept 2022 at 13:40, Duncan Murdoch 
> wrote:
>
>> On 21/09/2022 5:09 p.m., Riko Kelter wrote:
>> > Hello everyone,
>> >
>> > I ran R CMD check --as-cran without any errors. However, when I run a
>> check on the current version of r-devel I obtain the following strange
>> error about some ggplot function:
>> > * installing *source* package 'fbst' ...
>> > ** using staged installation
>> > ** R
>> > ** inst
>> > ** byte-compile and prepare package for lazy loading
>> > Warning message:
>> > The `size` argument of `element_line()` is deprecated as of ggplot2
>> 3.4.0.
>> > Please use the `linewidth` argument instead.
>> > The weird thing is: Although my package fbst depends on the package
>> rstanarm which itself imports ggplot,
>> > (1) no package code uses ggplot in any form,
>> > (2) no examples use any ggplot commands and
>> > (3) no vignette uses any ggplot command.
>> >
>> > Logs are available at https://win-builder.r-project.org/CX36AbHDU6Tl/
>> > I am thankful for any suggestion why this error occurs.
>> > All the best and kind regards,
>> > Riko
>>
>> Could you provide the source for the package?  I can see the DESCRIPTION
>> file at win-builder, but can't install it myself since I don't use
>> Windows.
>>
>> Duncan Murdoch
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
>
> --
> Alexandre Courtiol, www.datazoogang.de
>


-- 
Alexandre Courtiol, www.datazoogang.de

[[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] Warning about ggplot although no ggplot is used anywhere in the package

[Alexandre Courtiol]

You could trace the ggplot function using trace(ggplot2::element_line)
and then load the package and run your examples.
Whenever the function is used in the background, it should tell you.
++



On Thu, 22 Sept 2022 at 13:40, Duncan Murdoch 
wrote:

> On 21/09/2022 5:09 p.m., Riko Kelter wrote:
> > Hello everyone,
> >
> > I ran R CMD check --as-cran without any errors. However, when I run a
> check on the current version of r-devel I obtain the following strange
> error about some ggplot function:
> > * installing *source* package 'fbst' ...
> > ** using staged installation
> > ** R
> > ** inst
> > ** byte-compile and prepare package for lazy loading
> > Warning message:
> > The `size` argument of `element_line()` is deprecated as of ggplot2
> 3.4.0.
> > Please use the `linewidth` argument instead.
> > The weird thing is: Although my package fbst depends on the package
> rstanarm which itself imports ggplot,
> > (1) no package code uses ggplot in any form,
> > (2) no examples use any ggplot commands and
> > (3) no vignette uses any ggplot command.
> >
> > Logs are available at https://win-builder.r-project.org/CX36AbHDU6Tl/
> > I am thankful for any suggestion why this error occurs.
> > All the best and kind regards,
> > Riko
>
> Could you provide the source for the package?  I can see the DESCRIPTION
> file at win-builder, but can't install it myself since I don't use Windows.
>
> Duncan Murdoch
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol, www.datazoogang.de

[[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] Dispatch for S3 and Ordinary Function with Same Name

[Alexandre Courtiol]

Hi Dario,
I would have suggested using randomForest::predict.randomForest but you
cannot because it is not exported by randomForest :-(
There is probably a better way but my workaround would be for you to define
your own class to avoid the ambiguity in scope.
Whenever you want to use the predict from randomForest rather than yours, I
would just strip out your specific class name.
Hopefully someone will advise something more elegant to force the scoping...
++



On Mon, 29 Aug 2022 at 17:00, Dario Strbenac 
wrote:

> Good day,
>
> If there is a function named predict in my package and another in another
> package, such as randomForest, which is also called in a particular wrapper
> function in my package, how may I ensure that the call to predict inside of
> the wrapper function will call randomForest's prediction function and not
> the predict function defined elsewhere in my package? To illustrate
>
> randomForestPredictInterface <- function(forest, measurementsTest, ...)
> {
>   predictions <- predict(forest, measurementsTest) # Currently, executes
> predict defined in my package.
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol, www.datazoogang.de

[[alternative HTML version deleted]]

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

Re: [Rd] vignettes present in 2 folders or won't work

[Alexandre Courtiol]

Noted Duncan and TRUE...

I cannot do more immediately unfortunately, that is always the issue of
asking a last minute panic attack question before teaching a course
involving the package...
I do have /doc in my .Rbuildignore for reasons I can no longer remember...
I will dig and create a MRE/reprex.
The students will download heavy packages, but they probably won't notice.
*Apologies*

In the meantime, perhaps my question was clear enough to get clarity on:
1) whether having vignettes twice in foders inst/doc and vignettes is
normal or not when vignettes are static.
2) where could anyone find a complete documentation on R vignettes since it
is a recurring issue in this list and elsewhere.

Many thanks

On Sun, 1 Nov 2020 at 18:19, Duncan Murdoch 
wrote:

> You are doing a lot of things that are non-standard, so I doubt if
> anyone is going to be able to help you without access to a simple
> reproducible example of a package that does what you do.  Try to cut out
> as much as you can to make it minimal.  For example,
> devtools::document() (indeed, most of your code) is probably irrelevant
> to your problem with vignettes, but things like your .Rbuildignore file
> are not.
>
> Duncan Murdoch
>
> On 01/11/2020 11:22 a.m., Alexandre Courtiol wrote:
> > Dear all,
> >
> > I am struggling with an issue related to static vignettes: they work, but
> > only when present in double in the tarball -- in the folder inst/doc and
> > vignettes; see below for details.
> >
> > Details:
> >
> > I am pre-compiling heavy vignettes thanks to the vignette builder R.rsp.
> > So basically, I have PDF files which I want the package to use as
> Vignettes.
> >
> > For this, I have the following in my Description file:
> > VignetteBuilder: R.rsp
> >
> > I am organising the vignette by hand using a Makefile (because this is
> the
> > only way that has proven 100% reliable to me, across a variety of
> > situations).
> >
> > In my Makefile, I have something like:
> >
> > build: clean
> >mkdir -p inst/doc
> >mkdir vignettes
> >-cp sources_vignettes/*/*.pdf* vignettes
> >Rscript -e "tools::compactPDF(paths = 'vignettes', gs_quality =
> > 'printer')"
> >cp vignettes/*.pdf* inst/doc
> >Rscript -e "devtools::document()"
> >mkdir inst/extdata/sources_vignettes
> >cp sources_vignettes/*/*.Rnw inst/extdata/sources_vignettes
> >Rscript -e "devtools::build(vignettes = FALSE)"
> >
> > That works fine, the vignettes show up using browseVignettes() after
> > installing the package the normal way.
> >
> > However, after building, the tar.gz contains each pdf corresponding to a
> > vignette twice: once in vignettes and once in inst/doc (which is obvious,
> > when reading the Makefile).
> >
> >  From the reading of "Writing R Extensions" and other material, I cannot
> > tell if that is a must or not, but I hope it is not since I wish to avoid
> > that (my pdfs are large even once compressed).
> >
> > My problem is that when I delete either inst/doc or vignette just before
> > calling the last command of the Makefile (Rscript -e
> > "devtools::build(vignettes = FALSE)"), then browseVignettes() does not
> find
> > the vignettes after a normal installation.
> >
> > If anyone knows of some _complete_ documentation about the ever
> troublesome
> > topic of vignettes building in R, I would be very grateful too...
> >
> > Many thanks!
> >
> > Alex
> >
>
>

-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

[Rd] vignettes present in 2 folders or won't work

[Alexandre Courtiol]

Dear all,

I am struggling with an issue related to static vignettes: they work, but
only when present in double in the tarball -- in the folder inst/doc and
vignettes; see below for details.

Details:

I am pre-compiling heavy vignettes thanks to the vignette builder R.rsp.
So basically, I have PDF files which I want the package to use as Vignettes.

For this, I have the following in my Description file:
VignetteBuilder: R.rsp

I am organising the vignette by hand using a Makefile (because this is the
only way that has proven 100% reliable to me, across a variety of
situations).

In my Makefile, I have something like:

build: clean
  mkdir -p inst/doc
  mkdir vignettes
  -cp sources_vignettes/*/*.pdf* vignettes
  Rscript -e "tools::compactPDF(paths = 'vignettes', gs_quality =
'printer')"
  cp vignettes/*.pdf* inst/doc
  Rscript -e "devtools::document()"
  mkdir inst/extdata/sources_vignettes
  cp sources_vignettes/*/*.Rnw inst/extdata/sources_vignettes
  Rscript -e "devtools::build(vignettes = FALSE)"

That works fine, the vignettes show up using browseVignettes() after
installing the package the normal way.

However, after building, the tar.gz contains each pdf corresponding to a
vignette twice: once in vignettes and once in inst/doc (which is obvious,
when reading the Makefile).

>From the reading of "Writing R Extensions" and other material, I cannot
tell if that is a must or not, but I hope it is not since I wish to avoid
that (my pdfs are large even once compressed).

My problem is that when I delete either inst/doc or vignette just before
calling the last command of the Makefile (Rscript -e
"devtools::build(vignettes = FALSE)"), then browseVignettes() does not find
the vignettes after a normal installation.

If anyone knows of some _complete_ documentation about the ever troublesome
topic of vignettes building in R, I would be very grateful too...

Many thanks!

Alex

-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Seeking for best way to manage package transitive dependencies

[Alexandre Courtiol]

I agree in general, but don't think that the situation is always so
straightforward.
A good example of the complexity is the case of reexported functions:
functions from other packages aimed at being used by users without the need
to load them from their original package.
For a concrete example, let's take the pipe (%>%): the pipe comes
originally from {magrittr} but is reexported by many other packages (e.g.
{dplyr}).
So if your package relies on {dplyr} and reexport the pipe too, then one
could argue that you simply need to import {dplyr} and not {magrittr}.
I am not so sure I would agree with this (but my heart is not settled on
the matter) for 2 reasons:
- first, if you to reexport the pipe, your documentation would (I think)
link to a documentation linking to a documentation...
- second, you would not give credit to the {magrittr} developers (yes, in
part the same people in that case, but that is not the point).
Looking at what RSudio people chose to do in that precise example, it seems
that packages directly refer to {magrittr}.
I think that in the end it is a matter of weighing the pros and cons, and
that may depend on the case.
Re-exports may be a special case but giving credit to the right developers
may be worth thinking about whatever the situation.
++
Alex




On Thu, 10 Oct 2019 at 17:28, Cesko Voeten 
wrote:

> Package B should import only the packages and functions that are used by
> package B. If package B does not use functions from package C, package B
> should not import package C. What package A does is package A's problem,
> not package B's. If package A requires package C, install.packages() will
> automatically install it when package C is being installed, just as package
> C is installed when package B is being installed.
>
> I submit the following thought experiment: suppose that, at a later point
> in time, package A is re-written to not need package C. In this case, it
> would be incorrect for package B to still needlessly import package C.
>
> Best,
> Cesko
>
> Op 10-10-2019 om 17:14 schreef neonira Arinoem:
> > Suppose package B imports package A and package A imports package C.
> >
> > Shall package B import package C, knowing that package B will use
> functions
> > from package A that are using functions from package C ?
> >
> >
> > Currently, package B imports package C. This leads to a note from CRAN
> > stating
> >
> > Namespace in Imports field not imported from: ‘lubridate’
> >All declared Imports should be used.
> >
> > Doing so, I expect package B user not to worry about needed package B
> > dependencies.
> >
> >   What is the best way to to manage package transitive dependencies, in
> such
> > a case ?
> >
> > Neonira.
> >
> >   [[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
>


-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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] Warning Message on Vignettes

[Alexandre Courtiol]

Hi, how to you build your package?

I do:
mkdir -p inst/doc
mkdir vignettes
cp sources_vignettes/*.pdf* vignettes ## for linux add -u after cp
cp sources_vignettes/*.Rnw inst/doc ## for linux add -u after cp
(cd inst/doc/; for f in *.Rnw; do mv "$$f" "$${f%.Rnw}_source.txt"; done;)
Rscript -e "tools::compactPDF(paths = 'vignettes', gs_quality = 'printer')"
Rscript -e "devtools::build()"

Does that work for you?
Alex



On Wed, 3 Jul 2019 at 01:41, Charith Karunarathna <
charith_karunarat...@sfu.ca> wrote:

> (Reposting..)
>
> Hi everyone,
>
> I am getting following two warnings when I submit my R package
> (perfectphyloR) to CRAN.
>
> Warning 1: * checking files in 'vignettes' ... WARNING
>  Files in the 'vignettes' directory but no files in 'inst/doc':
>  'perfectphyloR.html', 'perfectphyloR.html.asis'
>
> Warning 2: * checking package vignettes in 'inst/doc' ... WARNING
>  dir.exists(dir) is not TRUE
>  Package vignette without corresponding single PDF/HTML:
>  'perfectphyloR.html.asis'
>
> I want to make my vignette as a static html vignette (not the PDF).
> Therefore, I followed this documentation,
> https://cran.r-project.org/web/packages/R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf
>
> After including my html vignette (perfectphyloR.html) into the directory
> 'vignette', I created a file called "perfectphyloR.html.asis" and that file
> includes following lines:
>
> %\VignetteIndexEntry{R packages: perfectphyloR}
> %\VignetteEngine{R.rsp::asis}
> %\VignetteKeyword{HTML}
> %\VignetteKeyword{vignette}
> %\VignetteKeyword{package}
>
> Also, I added 'R.rsp' to the DESCRIPTION file as follows:
> 
> Suggests:
> knitr,
> rmarkdown,
> R.rsp
> VignetteBuilder: R.rsp
>
> So, I am wondering something is wrong with my .asis file or I am doing any
> other mistake. Could you help me fix this issue?
>
> Thank you in advance!
>
> Regards,
>
> Charith.
>
>
>
>
> [[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
>


-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

Re: [Rd] "if" function in pure R?

[Alexandre Courtiol]

Thanks a lot Jiefei,

I had thought of defining a binary operator (inspired by pipes) or simply
using an additional condition in the if() calls [e.g. if(foo & fn(bar))
doSomeThing; with fn(bar) returning a logical], but both are workaround
that I do not find as elegant as a proper control-flow construct.

Thus two questions remain:
- is it possible to create a control-flow construct in pure R?
- if yes, how?

Anyone with more insights?
Thanks

On Mon, 27 May 2019 at 04:27, King Jiefei  wrote:

> Hi Alexandre,
>
> I'm not an R expert so this is only my personal thought:
>
> I don't think you can achieve what you want exactly. A possible solution
> would be defining a binary operator %*%, where you can replace the asterisk
> with any function name you want. The function %*% is special since it has
> two arguments, left operand and right operand respectively. You then
> can call the `substitute` function to get its function arguments in an
> expression format and proceed to do what you want. Here is an example to
> show the idea.
>
> *Code:*
>
> `%myOperator%` <- function(x, y) {
>   x = substitute(x)
>   y = substitute(y)
>   return(list(x, y))
> }
>
>
> myIf(i == 1, arg1) %myOperator% {
>   doSomeThing
> }
>
>
> *Results:*
>
> [[1]]
> myIf(i == 1, arg1)
>
> [[2]]
> {
> doSomeThing
> }
>
> I hope that helps.
>
> Best,
> Jiefei
>
> On Sun, May 26, 2019 at 4:45 AM Alexandre Courtiol <
> alexandre.court...@gmail.com> wrote:
>
>> Hi all,
>>
>> Could anyone refer to me to a good source to learn how to program a simple
>> control-flow construct* in R, or provide me with a simple example?
>>
>> Control-flow constructs are programmed as primitives, but I would like to
>> be able to do that (if possible) in pure R.
>>
>> The general context is that those functions are a mystery to me. The
>> motivating example is that I would like to create a function that behave
>> similarly to base::`if` with an extra argument to the function (e.g. to
>> include an error rate on the condition).
>>
>> Many thanks,
>>
>> Alex
>>
>> * control-flow constructs are functions such as if, for, while... that
>> allow for call of the form fn(x) expr to work (see ?Control).
>>
>> --
>> Alexandre Courtiol
>>
>> http://sites.google.com/site/alexandrecourtiol/home
>>
>> *"Science is the belief in the ignorance of experts"*, R. Feynman
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

[Rd] "if" function in pure R?

[Alexandre Courtiol]

Hi all,

Could anyone refer to me to a good source to learn how to program a simple
control-flow construct* in R, or provide me with a simple example?

Control-flow constructs are programmed as primitives, but I would like to
be able to do that (if possible) in pure R.

The general context is that those functions are a mystery to me. The
motivating example is that I would like to create a function that behave
similarly to base::`if` with an extra argument to the function (e.g. to
include an error rate on the condition).

Many thanks,

Alex

* control-flow constructs are functions such as if, for, while... that
allow for call of the form fn(x) expr to work (see ?Control).

-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Problem installing built vignettes

[Alexandre Courtiol]

Hi Chris,
I solved the issue directly in the code after forking your repos and send
you a pull request.
The folder vignette was at the wrong place and I added the .asis files as
well as updated the description file.
I hope it will work on your system.
++

On Sun, 3 Feb 2019 at 08:33, Chris Brien  wrote:

> Hi list members,
>
> I am having a problem installing vignettes for my asremlPlus package (
> https://github.com/briencj/asremlPlus - see VIgnettes branch) and have
> run into a brick wall in my efforts to solve it.  So any help would be
> greatly appreciated.
>
> The basic problem is that the R.rsp package cannot be found by
> loadVignetteBuilder when checking or building the package. Here are the
> details.
>
> I am running R 3.5.1 under Windows 10.
>
> I have compiled the Rmd sources to pdf files and I need to incorporate the
> pdfs without rebuilding them. The reasons are that they rely on having a
> package that is not available from a public R repo, namely asreml, and the
> R code take too much time to run on the CRAN servers.
>
> To deal with this I have tried to use the package R.rsp. Following the
> instructions, for example for WheatVignette.pdf, I have included the
> WheatVignette.pdf.asis with contents
>
> %\VignetteIndexEntry{Wheat data: a spatial analysis example}
> %\VignetteEngine{R.rsp::asis}
> %\VignetteAuthor{Chris Brien}
> %\VignetteKeyword{asremlPlus}
>
> I have the following lines in the DESCRIPTION file:
>
> Suggests: testthat, lattice, emmeans, lmerTest, pbkrtest, R.rsp
> Enhances: asreml
> VignetteBuilder: R.rsp
>
> When I run the following devtools::check call on the package
>
> devtools::check("asremlPlus", manual=TRUE, check_dir="D:/Analyses/R",
> document=FALSE,
> args="--as-cran")
>
> I get the following error message
>
> -  saving partial Rd database (7.6s)
>Error in loadVignetteBuilder(pkgdir, TRUE) :
>  vignette builder 'R.rsp' not found
>Execution halted
> Error in run(bin, args = real_cmdargs, stdout_line_callback =
> real_callback(stdout),  :
>   System command error
>
> To check the availability of R.rsp I did the following:
>
> > .libPaths();find.package("R.rsp")
> [1] "D:/Analyses/R library"   "D:/Analyses/R oldpkg"
>
> [3] "C:/Program Files/StatSoft/R/R-3.5.1/library"
> [1] "D:/Analyses/R library/R.rsp"
>
> I also note that in my HOME directory I have an .Renviron file with the
> following line:
>
> R_LIBS_USER="D:\\Analyses\\R library"
>
> Cheers,
>
>  Chris
>
>  Chris Brien | Adjunct Associate Professor in Statistics
> -
> School of Information Technology &  Mathematical Sciences
> University of South Australia
> GPO Box 2471
> ADELAIDE  5001  South Australia
> Phone:  +61 8 8302 5535   Fax:  +61 8 8302 5785
> Email:   chris.br...@unisa.edu.au
> WEB page:  <http://people.unisa.edu.au/Chris.Brien>
> CRICOS No 00121B
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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 @inheritParams in documenting data

[Alexandre Courtiol]

Hi Troels,
If you want to create a R package (using roxygen2), I would highly
recommend you to read Hadley Wickham's book on the topic.
The book is easy, short, practical and legally free (here:
http://r-pkgs.had.co.nz/).
If you follow it step by step, everything should work fine.
For anything not covered by the book, as Dirk said, look for examples of
packages you know in GitHub.
++
Alex


On Sat, 12 Jan 2019 at 08:46, Troels Ring  wrote:

> Dearfriends , with your help I'm rapidly improving package development.
> When
> documenting data, I seem to be helped mpst by making the rda directly from
> RStudio via file, new file, R documentation then choosing data. However, my
> data files have a lot of params, so I thought I might use @inheritParams
> since these params are already documented elsewhere in the package. Hence,
> in the rda file created directly from RStudio I tried to add @inheritParams
> CMB (since the params are already documented in CMB) but I cannot find
> exactly how to put it in the rda file.
>
> The skeleton has
>
> \describe{
>
>\item{\code(x)}{vector}
>
> And if I put some the params in a comma separated row instead of x they are
> acknowledged in the final rda file -
>
> BUT where and how to put the @inheritParams CMB I cannot find documented.
> Otherwise it seems to run OK
>
>
>
> All best wishes
>
> Troels
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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] Recommendations about adding options to a package in order to change default values of some functions on-the-fly

[Alexandre Courtiol]

Dear Samuel,

Many may object (for good reasons) that adding options would clash with
functional paradigm, but it is possible.
I don't know about the least worse practice but as far as I would do it,
you could:

1. directly write and then read elements in the (hidden) list .Options that
is present in the global environment:
options(test = "blabla") ## add element in .Options
.Options$test ## read element (for use in your own function)

2. you could also create your own alternative to options(), as ex:
https://github.com/courtiol/IsoriX/blob/master/IsoriX/R/options.R
Option 2 has the benefits of not risking conflict with existing names in
.Options and it would thus also not mess up the way other packages may work.
Option 1 uses what is already in place.

I hope this help,
Best

Alex

On Thu, 6 Sep 2018 at 17:18, Samuel  wrote:

> Hi,
>
> I would like to change the default value of some arguments of some
> functions in a package of mine. I don't want to change explicitly the
> calls in the many scripts that have been written. For example, I would
> to change the delimiter in all write.mytable() without changing any
> calls it and without changing the default value currently assigned to
> that delimiter in the declaration of this function. What I would like is
> to add a command at the beginning of the scripts that says "since now,
> the delimiter is ;".
>
> I am thinking about setting global options that those functions will
> read and use to overwrite the default values. Of course the
> write.mytable function has to be modify to exploit these settings, but
> none of the scripts. I think about something similar to the par() and
> options() functions.
>
> I noticed the settings package, but I would like to know if there is a
> simple and recommended solution without adding any dependency.
>
> Hope my question is clear.
>
> Thanks for any advice,
> Samuel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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 o fix this NOTE Maintainer

[Alexandre Courtiol]

It's all good, this is not a problem.

On Fri, 31 Aug 2018, 08:44 Ulavappa Angadi,  wrote:

> Dear sir
>
> how fix this note
>
> checking CRAN incoming feasibility ... NOTEMaintainer: 'Ulavappa B.
> Angadi '
>
> With regards
>
> Angadi U B
> Sr. Scientist
> CABin, IASRI, Pusa, New Delhi
>
> [[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] Printing examples conditionally on another package in Suggests

[Alexandre Courtiol]

Perhaps then something like:
Print <- function(x) if (requireNamespace("some.package", quietly = TRUE))
print(x)
Print("Hi")
Print("Hello")
Print("Goodbye")



On Fri, 10 Aug 2018 at 12:33, Zhian Kamvar  wrote:

> Mainly, I would like to see the value printed after the print statement
> like it would appear in a normal R session:
>
> print("Hi")
> #> [1] "Hi"
> print("Hello")
> #> [1] "Hello"
> print("Goodbye")
> #> [1] "Goodbye"
>
>
> On Fri, Aug 10, 2018 at 11:28 AM Alexandre Courtiol <
> alexandre.court...@gmail.com> wrote:
>
>> Hi Zhian,
>> Could you please explain what behaviour you would like to obtain?
>> I really don't understand what your problem is from your description...
>> Alex
>>
>> On Fri, 10 Aug 2018 at 12:18, Zhian Kamvar  wrote:
>>
>>> Hello,
>>>
>>> I know it's good practice to use
>>>
>>> if (require("some_package")) {
>>>   # some code that needs some_package
>>> }
>>>
>>> In R examples that needs a package listed in Suggests.
>>>
>>> The problem with this approach is that if there are any print statements
>>> within this structure, then they only get printed after the braces and
>>> not
>>> after the lines like so:
>>>
>>> if (TRUE) {
>>>   print("Hi")
>>>   print("Hello")
>>>   print("Goodbye")
>>> }
>>> #> [1] "Hi"
>>> #> [1] "Hello"
>>> #> [1] "Goodbye"
>>>
>>> The only way I can think of circumventing this is by replacing the if
>>> statement with a stopifnot statement:
>>>
>>> stopifnot(require("some_package"))
>>> # some code that needs some_package
>>>
>>> But, I'm not sure if that's okay to do in a function example. Does anyone
>>> have any ideas or suggestions on how to help with this kind of thing?
>>>
>>> Cheers,
>>> Zhian
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>>
>> --
>> Alexandre Courtiol
>>
>> http://sites.google.com/site/alexandrecourtiol/home
>>
>> *"Science is the belief in the ignorance of experts"*, R. Feynman
>>
>

-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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] Printing examples conditionally on another package in Suggests

[Alexandre Courtiol]

Hi Zhian,
Could you please explain what behaviour you would like to obtain?
I really don't understand what your problem is from your description...
Alex

On Fri, 10 Aug 2018 at 12:18, Zhian Kamvar  wrote:

> Hello,
>
> I know it's good practice to use
>
> if (require("some_package")) {
>   # some code that needs some_package
> }
>
> In R examples that needs a package listed in Suggests.
>
> The problem with this approach is that if there are any print statements
> within this structure, then they only get printed after the braces and not
> after the lines like so:
>
> if (TRUE) {
>   print("Hi")
>   print("Hello")
>   print("Goodbye")
> }
> #> [1] "Hi"
> #> [1] "Hello"
> #> [1] "Goodbye"
>
> The only way I can think of circumventing this is by replacing the if
> statement with a stopifnot statement:
>
> stopifnot(require("some_package"))
> # some code that needs some_package
>
> But, I'm not sure if that's okay to do in a function example. Does anyone
> have any ideas or suggestions on how to help with this kind of thing?
>
> Cheers,
> Zhian
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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] vignette via devtools: sometimes found, sometimes not (same package)

[Alexandre Courtiol]

Dear all,

I have finally understood why my package installed from GitHub (via
devtools or drat) would display pre-built vignettes after a call to
browseVignettes() on most but not all computers (despite the vignettes
being physically present in all): if the package is installed on a computer
that has knitr installed, then it works; otherwise it fails.

I can thus fix this by adding knitr in the Imports instead of Suggests, or
by asking people to install with the option dependencies = TRUE.

I am still wondering why knitr is needed (the vignettes are pre-built), but
the workaround seems to work with a 100% success rate.

Thanks for all that tried to fix my issue...

I should have thought about knitr head on but I did not, and neither
sessionInfo() nor devtools::session_info() allows one to know if knitr is
installed or not, and I did not think of checking all installed packages
before.

Best,
Alex

On 20 April 2018 at 09:59, Martin Maechler <maech...@stat.math.ethz.ch>
wrote:

> >>>>> Thierry Onkelinx <thierry.onkel...@inbo.be>
> >>>>> on Fri, 20 Apr 2018 09:14:44 +0200 writes:
>
> > Dear Alex, Another idea is to use pkgdown
> > (http://pkgdown.r-lib.org) to convert all the
> > documentation of your package (include the vignettes) into
> > a website. Then you make that available to your students,
> > e.g. through github pages.
>
> Hmm, sounds nice .. at first:  In teaching (and research!) I particularly
> emphasize people use CRAN (or Bioconductor) packages.
>
> Why on earth is pkgdown not on CRAN ?
>
> Martin Maechler
> ETH Zurich
>
> > Best regards,
>
> > ir. Thierry Onkelinx Statisticus / Statistician
>
> > Vlaamse Overheid / Government of Flanders INSTITUUT VOOR
> > NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
> > AND FOREST Team Biometrie & Kwaliteitszorg / Team
> > Biometrics & Quality Assurance thierry.onkel...@inbo.be
> > Havenlaan 88 bus 73, 1000 Brussel www.inbo.be
>
> > 
> ///
> > To call in the statistician after the experiment is done
> > may be no more than asking him to perform a post-mortem
> > examination: he may be able to say what the experiment
> > died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote
> > is not data. ~ Roger Brinner The combination of some data
> > and an aching desire for an answer does not ensure that a
> > reasonable answer can be extracted from a given body of
> > data. ~ John Tukey
> > 
> ///
>
>
>
>
> > 2018-04-19 18:33 GMT+02:00 Alexandre Courtiol
> > <alexandre.court...@gmail.com>:
> >> Thanks a lot Thierry, I was happy to discover and
> >> implement a "drat" installation workflow.  Unfortunately
> >> it did not solve the issue (but I will stick to drat).
> >> Also, I checked the sessionInfo() and could not find any
> >> package version discriminating accurately between
> >> computers that shows vignettes from those who do not.
> >> Only Windows computer have the issue but this proves
> >> nothing (and other computers with the same OS version are
> >> fine).  Goergi, I did not yet retried outside RStudio (I
> >> am trying not to waste too much time at the beginning of
> >> each course...  I wish I could hijack a problematic
> >> laptop but they don't let me do it as they need them).
> >> ++ Alex
> >>
> >>
> >> On 17 April 2018 at 10:42, Thierry Onkelinx
> >> <thierry.onkel...@inbo.be> wrote:
> >>>
> >>> Dear Alex,
> >>>
> >>> Have a look at drat
> >>> (http://eddelbuettel.github.io/drat/DratForPackageAuthors.html).
> This
> >>> makes it easier to distribute prepackaged R packages
> >>> (including When you uploaded a new version, then the
> >>> student would only have to do drat::addRepo("your_repo")
> >>> and then install.pakages("LM2GLMM") or update.packages()
> >>>
> >>> Best regards,
> >>>
> >>> ir. Thierry Onkelinx Statisticus / Statistician
> >>>
> >>> Vlaamse Overheid / Government of Flanders INSTITUUT VOOR
> >>> NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
> >>> AND

Re: [R-pkg-devel] vignette via devtools: sometimes found, sometimes not (same package)

[Alexandre Courtiol]

Thanks a lot Thierry, I was happy to discover and implement a "drat"
installation workflow.
Unfortunately it did not solve the issue (but I will stick to drat).
Also, I checked the sessionInfo() and could not find any package version
discriminating accurately between computers that shows vignettes from those
who do not.
Only Windows computer have the issue but this proves nothing (and other
computers with the same OS version are fine).
Goergi, I did not yet retried outside RStudio (I am trying not to waste too
much time at the beginning of each course...
I wish I could hijack a problematic laptop but they don't let me do it as
they need them).
++
Alex


On 17 April 2018 at 10:42, Thierry Onkelinx <thierry.onkel...@inbo.be>
wrote:

> Dear Alex,
>
> Have a look at drat
> (http://eddelbuettel.github.io/drat/DratForPackageAuthors.html). This
> makes it easier to distribute prepackaged R packages (including When
> you uploaded a new version, then the student would only have to do
> drat::addRepo("your_repo") and then install.pakages("LM2GLMM") or
> update.packages()
>
> Best regards,
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
> AND FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be
>
> 
> ///
> To call in the statistician after the experiment is done may be no
> more than asking him to perform a post-mortem examination: he may be
> able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does
> not ensure that a reasonable answer can be extracted from a given body
> of data. ~ John Tukey
> ////
> ///
>
>
>
>
> 2018-04-16 19:38 GMT+02:00 Alexandre Courtiol <
> alexandre.court...@gmail.com>:
> > Re,
> >
> > On 16 April 2018 at 17:35, Georgi Boshnakov <
> > georgi.boshna...@manchester.ac.uk> wrote:
> >
> >> Hi,
> >>
> >> The problem is indeed difficult to debug but there are things that can
> be
> >> done to narrow it down.
> >>
> >> 1. Are there 1/3 unlucky computers fixed? (I.e does the problem occur
> >> always on the same computers) Also, do you really mean computer or user?
> >>
> >
> > Yes, I mean computer, not user.
> >
> >>
> >> 2. Are the students working under R studio? If so, does the same problem
> >> appear if the same procedure is run outside R studio.
> >>
> >
> > I will try tomorrow (but from memory I think the answer will be yes).
> >
> >>
> >> 3. Further to 2.,  You mention development mode - do (some) students
> also
> >> have a copy of your repository? This may be aproblem if they don't
> update
> >> it too.
> >>
> >
> > No, only me has the devel version.
> >
> >>
> >> 4. What happens if R is restarted?
> >
> >
> > I will try tomorrow (but I think the answer will be nothing).
> >
> >
> >> 5. It may be worth checking .Rprofle and similar for the concerned
> >> computers (or users, see 1.)
> >>
> >
> > I will try as well but most had a fresh install and did not mess with
> > settings.
> >
> >>
> >> Hope this is of some help.
> >>
> >
> > I will look at all this and also gather the session infos as Ben
> suggested.
> > I think I know how to proceed to get to the bottom of that, but I was
> just
> > hoping that the problem was already well known and the answer as well...
> > If it is for anyone, please reply. Otherwise, I will investigate.
> > Thanks to everyone.
> > Alex
> >
> >
> >>
> >>
> >>  Georgi Boshnakov
> >>
> >>
> >> 
> >> From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf
> >> of Alexandre Courtiol [alexandre.court...@gmail.com]
> >> Sent: 16 April 2018 14:40
> >> To: List r-package-devel
> >> Subject: [R-pkg-devel] vignette via devtools: sometimes found, sometimes
> >> not (same package)
> >>
> >> Dear all,
> >> I am teaching a class and for that I created a R package t

Re: [R-pkg-devel] vignette via devtools: sometimes found, sometimes not (same package)

[Alexandre Courtiol]

Re,

On 16 April 2018 at 17:35, Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:

> Hi,
>
> The problem is indeed difficult to debug but there are things that can be
> done to narrow it down.
>
> 1. Are there 1/3 unlucky computers fixed? (I.e does the problem occur
> always on the same computers) Also, do you really mean computer or user?
>

Yes, I mean computer, not user.

>
> 2. Are the students working under R studio? If so, does the same problem
> appear if the same procedure is run outside R studio.
>

I will try tomorrow (but from memory I think the answer will be yes).

>
> 3. Further to 2.,  You mention development mode - do (some) students also
> have a copy of your repository? This may be aproblem if they don't update
> it too.
>

No, only me has the devel version.

>
> 4. What happens if R is restarted?


I will try tomorrow (but I think the answer will be nothing).


> 5. It may be worth checking .Rprofle and similar for the concerned
> computers (or users, see 1.)
>

I will try as well but most had a fresh install and did not mess with
settings.

>
> Hope this is of some help.
>

I will look at all this and also gather the session infos as Ben suggested.
I think I know how to proceed to get to the bottom of that, but I was just
hoping that the problem was already well known and the answer as well...
If it is for anyone, please reply. Otherwise, I will investigate.
Thanks to everyone.
Alex


>
>
>  Georgi Boshnakov
>
>
> ____
> From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf
> of Alexandre Courtiol [alexandre.court...@gmail.com]
> Sent: 16 April 2018 14:40
> To: List r-package-devel
> Subject: [R-pkg-devel] vignette via devtools: sometimes found, sometimes
> not (same package)
>
> Dear all,
> I am teaching a class and for that I created a R package that mostly
> contains vignettes (the slides of the course).
> I host the package on GitHub because I want the students to download every
> day the latest version of the package.
> Building the vignettes takes a couple of hours so I pre-build the vignettes
> using devtools::build_vignettes before pushing my updates to GitHub.
> The student install the package using
> devtools::install_github("courtiol/LM2GLMM").
> Then, they do library(LM2GLMM) and browseVignettes(package = "LM2GLMM")...
>
> ... and that works on 2/3 of the computers, for the others it says
> vignettes not found.
>
> Any idea why and what can I do to make it 100% success?
> Of course on my laptop it works, so I cannot investigate.
> Also, since they all use different versions of R, devtools or OS... I would
> like to know the one thing that must be changed if it comes from that (but
> I am not sure it does).
>
> I have added a back up function that works for the 1/3 of unfortunate
> students:
>
> get_vignettes <- function() {
>   utils::browseURL(paste0(find.package("LM2GLMM"), "/doc/")) ## for
> installed
>   utils::browseURL(paste0(find.package("LM2GLMM"), "/inst/doc/")) ## for
> development
>   return(invisible(NULL))
> }
>
> This functions opens de vignette folder and that shows that all the
> students actually have the html files installed correctly. But it is ugly
> because then they have to find the good html file and so forth, so I would
> rather have a better solution.
>
> Many thanks,
>
> Alex
>
> --
> Alexandre Courtiol
>
> http://sites.google.com/site/alexandrecourtiol/home
>
> *"Science is the belief in the ignorance of experts"*, R. Feynman
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>



-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

[R-pkg-devel] vignette via devtools: sometimes found, sometimes not (same package)

[Alexandre Courtiol]

Dear all,
I am teaching a class and for that I created a R package that mostly
contains vignettes (the slides of the course).
I host the package on GitHub because I want the students to download every
day the latest version of the package.
Building the vignettes takes a couple of hours so I pre-build the vignettes
using devtools::build_vignettes before pushing my updates to GitHub.
The student install the package using
devtools::install_github("courtiol/LM2GLMM").
Then, they do library(LM2GLMM) and browseVignettes(package = "LM2GLMM")...

... and that works on 2/3 of the computers, for the others it says
vignettes not found.

Any idea why and what can I do to make it 100% success?
Of course on my laptop it works, so I cannot investigate.
Also, since they all use different versions of R, devtools or OS... I would
like to know the one thing that must be changed if it comes from that (but
I am not sure it does).

I have added a back up function that works for the 1/3 of unfortunate
students:

get_vignettes <- function() {
  utils::browseURL(paste0(find.package("LM2GLMM"), "/doc/")) ## for
installed
  utils::browseURL(paste0(find.package("LM2GLMM"), "/inst/doc/")) ## for
development
  return(invisible(NULL))
}

This functions opens de vignette folder and that shows that all the
students actually have the html files installed correctly. But it is ugly
because then they have to find the good html file and so forth, so I would
rather have a better solution.

Many thanks,

Alex

-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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] rgdal not available for checking

[Alexandre Courtiol]

Hi Pascal,
I would not worry about that.
This probably simply means that rgdal is not installed on the computer used
to check the package.
Since gdal is often somewhat difficult to install, I am not going to blame
CRAN.
++
Alex

On 13 March 2018 at 09:50, Pascal Title <pascalti...@gmail.com> wrote:

> Hi,
>
> I'm working on submitting an update to an existing R package to CRAN. I've
> tested it with R CMD check --as-cran and it passes with no errors, warnings
> or notes.
>
> But there is an error currently on the check results page for the current
> version, which you can see here:
> https://cran.r-project.org/web/checks/check_results_envirem.html
>
> The error is only for the r-release-osx-x86_64 platform, where the problem
> is "Package suggested but not available for checking: ‘rgdal’".
>
> I'm not sure what the problem is, as rgdal is a package on CRAN, and I
> can't seem to reproduce this problem on the different platforms that I have
> run R CMD check on, which as mac osx, ubuntu and win-builder. I imagine
> that the same problem will crop up with the updated version of the package.
>
> I've googled the error message, and it looks like there are many R packages
> with the same issue.
>
> Any suggestions for how to deal with this would be great. I could rewrite
> parts of my R package to avoid the use of rgdal in the examples, but that's
> working around the problem rather than addressing it.
>
> thanks!
> -Pascal
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>



-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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] tibbles are not data frames

[Alexandre Courtiol]

ctly from data.frame.
> > >>>
> > >>> I have nothing against tibbles. But calling them "data.frame" raises
> > >>> expectations that can't be fulfilled.
> > >>
> > >> [...]
> > >>
> > >> __
> > >> 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
> > >
> > > --
> > >
> > > _____
> > >
> > > Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen
> > Rechts; Gerichtsstand: Hamburg | www.uke.de
> > > Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr.
> > Dr. Uwe Koch-Gromus, Joachim Prölß, Martina Saurin (komm.)
> > > _
> > >
> > > SAVE PAPER - THINK BEFORE PRINTING
> > > __
> > > 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
>



-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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] tibbles are not data frames

[Alexandre Courtiol]

I could not agree more with Göran and we had to change code in our packages
because if this too. I also see students often facing bugs because of it.
Again, with all the respect I have for Hadley.


On 26 Sep 2017 9:32 a.m., "Göran Broström"  wrote:

I am beginning to get complaints from users of my CRAN packages (especially
'eha') to the effect that they get error messages like "Error: Unsupported
use of matrix or array for column indexing".

It turns out that they are sticking in tibbles into functions that expect
data frames as input. And I am using the kind of subsetting that Hadley
dislikes (eha is an old package, much older than tibbles). It is of course
a simple matter to change the code so it handles both data frames and
tibbles correctly, but this affects many functions, and it will take some
time. And when the next guy introduces 'troubles' as an improvement of
'tibbles', I will have to rewrite the code again.

While I like Hadley's way of doing it, I think it is a mistake to let a
tibble also be of class data frame. To me it is a matter of inheritance and
backwards compability: A tibble should add nice things to a data frame, not
change basic behaviour, in order to call itself a data frame.

Is it correct to let a tibble be of class "data.frame"?

Göran Broström

__
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

[Rd] Bug simulate.lm() --> needs credential to report it

[Alexandre Courtiol]

Dear R developers,

I did not get any reply concerning my email from last week concerning the
bug I found in stats::simulate.lm(). The bug shows up when called upon a
GLM with family gaussian(). I am confident it is a genuine bug related to a
mix-up between weights and prior weights that only impacts the gaussian
family (other families have their own simulate functions defined
elsewhere).

I cannot add the bug in Bugzilla as I have no credential.
Could someone please help me to get credentials so that I can add the bug
in bugzilla?

Thanks a lot,

Simple demonstration for the bug:

set.seed(1L)
y <- 10 + rnorm(n = 100)
mean(y) ##  10.10889
var(y)  ##   0.8067621

mod_glm  <- glm(y ~ 1, family = gaussian(link = "log"))
new.y <- simulate(mod_glm)[, 1]
mean(new.y) ## 10.10553
var(new.y)  ##  0.007243695  # WRONG #

mod_glm$weights <- mod_glm$prior.weights  ## ugly hack showing where the
issue is
new.y <- simulate(mod_glm)[, 1]
mean(new.y) ## 10.13554
var(new.y)  ##  0.8629975  # OK #


-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Issue with including vignettes without building package

[Alexandre Courtiol]

To rephrase my needs, I need to find a way to create the file
/Meta/vignette.rds at install, not build, as all other files for the
vignettes to run are being installed properly.
Has anyone managed to do that?
For now my horrible hack is to have a function calling the vignette through
a call to browseURL(paste0(find.package("XXX"), "/doc/")).
It opens the folder with all the vignette, but it is not as nice as opening
the index in the web browser.
Doing a browseURL on the index.html works but then the links do not... so
that does not help.
Best
Alex

On 20 April 2017 at 22:30, Alexandre Courtiol <alexandre.court...@gmail.com>
wrote:

> Thanks but I don't think so, that would imply them to rebuild the
> vignettes, which is exactly what I want to avoid.
> Without knitr cached chunk it would take forever on their laptops and they
> would also need to install tons of packages...
> ++
>
> On 20 April 2017 at 21:01, Sven E Templer <sven.temp...@gmail.com> wrote:
>
>> Hi Alex,
>>
>>
>> what if you run
>>
>> devtools::install_github(build_vignettes = TRUE)
>>
>> on your students computer?
>>
>> See ?devtools::install
>>
>>
>> Best,
>>
>> Sven
>>
>>
>> > On 20. Apr 2017, at 15:09, Alexandre Courtiol <
>> alexandre.court...@gmail.com> wrote:
>> >
>> > Dear all,
>> >
>> > I am using a package for teaching:
>> > my slides are html vignettes, and it is convenient for students to
>> control
>> > which packages they must install, provide code and datasets.
>> >
>> > As I am often editing the package live during the course, it would be
>> great
>> > if I could just push to github and that the student would just have to
>> run
>> > a devtools::install_github() to get my updated vignettes. I would rather
>> > not to have to build the package before pushing to save time.
>> >
>> > The issues is that I do not want to build the vignettes on install as
>> they
>> > are very slow to build. On my computer however it is quick because I
>> have
>> > cached the knitr chunks output. So I was hoping to just have to run
>> > devtools::build_vignettes() on my machine before pushing the files
>> thereby
>> > created (./inst/doc) and that the student could just
>> > devtools::install_github().
>> >
>> > I cannot make this work: no vignettes are found after install. When I do
>> > check the repository beeing installed on their computers, the html, Rmd
>> and
>> > R files corresponding to the vignettes are present in ./doc, so it is
>> not
>> > an issue of having the wrong .gitgnore configuration.
>> >
>> > I have read about many vignettes related issues on the net, but I did
>> not
>> > find something dealing with this precise issue.
>> >
>> > PS: I know about the R.rsp hack, but I would prefer to find a solution
>> more
>> > direct.
>> >
>> > Best,
>> >
>> > Alex
>> >
>> >
>> >
>> >
>> > --
>> > Alexandre Courtiol
>> >
>> > http://sites.google.com/site/alexandrecourtiol/home
>> >
>> > *"Science is the belief in the ignorance of experts"*, R. Feynman
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> > __
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
>
>
> --
> Alexandre Courtiol
>
> http://sites.google.com/site/alexandrecourtiol/home
>
> *"Science is the belief in the ignorance of experts"*, R. Feynman
>



-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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 including vignettes without building package

[Alexandre Courtiol]

Thanks but I don't think so, that would imply them to rebuild the
vignettes, which is exactly what I want to avoid.
Without knitr cached chunk it would take forever on their laptops and they
would also need to install tons of packages...
++

On 20 April 2017 at 21:01, Sven E Templer <sven.temp...@gmail.com> wrote:

> Hi Alex,
>
>
> what if you run
>
> devtools::install_github(build_vignettes = TRUE)
>
> on your students computer?
>
> See ?devtools::install
>
>
> Best,
>
> Sven
>
>
> > On 20. Apr 2017, at 15:09, Alexandre Courtiol <
> alexandre.court...@gmail.com> wrote:
> >
> > Dear all,
> >
> > I am using a package for teaching:
> > my slides are html vignettes, and it is convenient for students to
> control
> > which packages they must install, provide code and datasets.
> >
> > As I am often editing the package live during the course, it would be
> great
> > if I could just push to github and that the student would just have to
> run
> > a devtools::install_github() to get my updated vignettes. I would rather
> > not to have to build the package before pushing to save time.
> >
> > The issues is that I do not want to build the vignettes on install as
> they
> > are very slow to build. On my computer however it is quick because I have
> > cached the knitr chunks output. So I was hoping to just have to run
> > devtools::build_vignettes() on my machine before pushing the files
> thereby
> > created (./inst/doc) and that the student could just
> > devtools::install_github().
> >
> > I cannot make this work: no vignettes are found after install. When I do
> > check the repository beeing installed on their computers, the html, Rmd
> and
> > R files corresponding to the vignettes are present in ./doc, so it is not
> > an issue of having the wrong .gitgnore configuration.
> >
> > I have read about many vignettes related issues on the net, but I did not
> > find something dealing with this precise issue.
> >
> > PS: I know about the R.rsp hack, but I would prefer to find a solution
> more
> > direct.
> >
> > Best,
> >
> > Alex
> >
> >
> >
> >
> > --
> > Alexandre Courtiol
> >
> > http://sites.google.com/site/alexandrecourtiol/home
> >
> > *"Science is the belief in the ignorance of experts"*, R. Feynman
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>


-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

[Rd] mget call can trigger C stack usage error

[Alexandre Courtiol]

Hi all, not sure if you will call this a bug or something else but the
following silly call trigger a low level error:

foo <- list(x=1)
class(foo) <- "new"
print.new <- function(x, ...) print(mget(names(formals(
foo

> Error: C stack usage  7969412 is too close to the limit



-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

[R-pkg-devel] Selective/Partial LazyData?

[Alexandre Courtiol]

Dear all,
I am preparing a package and using "LazyData: true" in DESCRIPTION makes
things a little more smooth as I have function calling my own data. My
problem is that doing so seem to uncompress the data at installation and
convert them into a Rdata.rdb that is > 1MB, which makes R CMD check, which
them threw a note. Adding "LazyDataCompression: xz" did help a bit, but I
am still far off the 1MB limit (9MB). Since I would rather keep both the
data and the LazyData, I wonder:
- if CRAN would only care about the size of the data within the tarball
(there, all is fine).
- if there is a way not to lazyload _all_ data objects, but only some of
them as I do not need the biggest file to be lazyloaded, just some small
ones.
Sorry if I failed to spot the relevant section in the R manuals... I did
look for it.
Alex

-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[alternative HTML version deleted]]

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

[Rd] invalid comparison in numeric sequence (PR#13551)

[alexandre . courtiol]

Full_Name: alex
Version: 2.8.1
OS: Ubuntu / MacOSX
Submission from: (NULL) (162.38.183.51)


 0.6==0.6
[1] TRUE
 seq(0,1,0.1)==0.4
 [1] FALSE FALSE FALSE FALSE  TRUE FALSE FALSE FALSE FALSE FALSE FALSE
 seq(0,1,0.1)==0.6
 [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE
 seq(0,1,0.1)==0.8
 [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE  TRUE FALSE FALSE


What is wrong with 0.6 ??? (TRUE is missing)
I tried 3 differents computers (2 Ubuntu with R 2.8.1, and one Mac with R 2.8).

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