Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)

2024-01-04 Thread Tiago Olivoto
Dear all,
Thanks all for the tips and sorry for the automatic reply.
Best regards,
Olivoto

Em qui., 4 de jan. de 2024 às 18:00, Iris Simmons 
escreveu:

> You cannot and should not ignore this.
>
> An R package should never ever be assigning variables into environments
> for which they haven't been granted permission to do so. You should ask the
> user whether they want the object assigned in the global environment before
> doing so, and the default should be no so that it will not be assigned in
> non interactive sessions.
>
> On Thu, Jan 4, 2024, 15:54 Tiago Olivoto  wrote:
>
>> Hi everyone!
>> I which a happy new year!
>>
>>
>> I'm coding a shiny app and I would like to include an option so that the
>> users can assign the results to the global environment for further
>> analysis.
>>
>> I have written the following code, which checks if 'globalvarname' (the
>> name of object to be created in the global environment) already exists,
>> returning an error if so, and asking to the user change the name.
>>
>> code
>> ---
>> observeEvent(input$savetoglobalenv, {
>>  ### more code here
>>
>>   if (exists(input$globalvarname, envir = globalenv())) {
>> sendSweetAlert(
>>   session = session,
>>   title = "Error",
>>   text = paste0("The object'", input$globalvarname, "' already exists
>> in the global environment. Please, change the name."),
>>   type = "success"
>> )
>>   } else {
>> assign(input$globalvarname, report, envir = globalenv())
>> ask_confirmation(
>>   inputId = "myconfirmation",
>>   type = "warning",
>>   title = "Close the App?",
>>   text = paste0("The object'", input$globalvarname, "' has been
>> created
>> in the Global environment. To access the created object, you need first to
>> stop the App. Do you really want to close the app now?"),
>>   btn_labels = c("Nope", "Yep"),
>>   btn_colors = c("#FE642E", "#04B404")
>> )
>>   }
>> })
>> -
>>
>> Thus, the object is only created when the user decides to assign such an
>> object to the global environment. As the object's name is checked, there
>> is
>> no way of replacing some object already available in the global
>> environment.
>>
>> Of course, when running devtools::check(), a NOTE is returned
>>
>> Found the following assignments to the global environment:
>>   Arquivo 'plimanshiny/R/mod_analyze.R':
>>
>> Can I ignore this safely?
>> Is there any suggestion to handly this without using 'assign()'
>>
>> Thanks in advance,
>> Olivoto
>>
>> [[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] Assigning an object to the global environment (shiny package)

2024-01-04 Thread Tiago Olivoto
Hi everyone!
I which a happy new year!


I'm coding a shiny app and I would like to include an option so that the
users can assign the results to the global environment for further analysis.

I have written the following code, which checks if 'globalvarname' (the
name of object to be created in the global environment) already exists,
returning an error if so, and asking to the user change the name.

code
---
observeEvent(input$savetoglobalenv, {
 ### more code here

  if (exists(input$globalvarname, envir = globalenv())) {
sendSweetAlert(
  session = session,
  title = "Error",
  text = paste0("The object'", input$globalvarname, "' already exists
in the global environment. Please, change the name."),
  type = "success"
)
  } else {
assign(input$globalvarname, report, envir = globalenv())
ask_confirmation(
  inputId = "myconfirmation",
  type = "warning",
  title = "Close the App?",
  text = paste0("The object'", input$globalvarname, "' has been created
in the Global environment. To access the created object, you need first to
stop the App. Do you really want to close the app now?"),
  btn_labels = c("Nope", "Yep"),
  btn_colors = c("#FE642E", "#04B404")
)
  }
})
-

Thus, the object is only created when the user decides to assign such an
object to the global environment. As the object's name is checked, there is
no way of replacing some object already available in the global environment.

Of course, when running devtools::check(), a NOTE is returned

Found the following assignments to the global environment:
  Arquivo 'plimanshiny/R/mod_analyze.R':

Can I ignore this safely?
Is there any suggestion to handly this without using 'assign()'

Thanks in advance,
Olivoto

[[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 CMD check --as-cran Warning in read.dcf(con, c(.get_standard_repository_db_fields(), "Path")) : URL 'https://CRAN.R-project.org/src/contrib/PACKAGES.gz': Timeout of 60 seconds was

2023-09-09 Thread Tiago Olivoto
Hi,
I had a similar issue while submitting a bug fix of my package {pliman}
using devtools::release()


Have you checked on win-builder (with `check_win_devel()`)?

1: Absolutely
2: I forget
3: Not yet

Seleção: 1
Error in utils::download.file("
https://cran.R-project.org/web/packages/packages.rds;,  :
  download from 'https://cran.R-project.org/web/packages/packages.rds'
failed
In addition: Warning messages:
1: In utils::download.file("
https://cran.R-project.org/web/packages/packages.rds;,  :
  downloaded length 0 != reported length 0
2: In utils::download.file("
https://cran.R-project.org/web/packages/packages.rds;,  :
  URL 'https://cran.R-project.org/web/packages/packages.rds': Timeout of 60
seconds was reached
---

Thanks
Olivoto

Em sáb., 9 de set. de 2023 às 14:45, Hu Yue  escreveu:

> Hello,
>
> I encountered a problem when running ‘R CMD check –as-cran’ at the step
> ‘checking CRAN incoming feasibility’.
>
> The error message is as follows:
>
> * checking CRAN incoming feasibility ...Warning in read.dcf(con,
> c(.get_standard_repository_db_fields(), "Path")) :
>
>   URL 'https://CRAN.R-project.org/src/contrib/PACKAGES.gz': Timeout of 60
> seconds was reached
>
>
>
> Does anyone know how to deal with this issue?
>
>
>
> Thanks,
>
> Yue
>
> [[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 declare Bioconductor Dependencies in the Description File of my R Package

2023-03-16 Thread Tiago Olivoto
Thanks Duncan,
I'm in the way of a new CRAN submission and I will make sure to call
check_ebi() in the body of each function. This should ensure that the check
for EBImage will be called even with pliman::object_edge( ... ), for
example.

Best regards,
Olivoto

Em qui., 16 de mar. de 2023 às 14:15, Duncan Murdoch <
murdoch.dun...@gmail.com> escreveu:

> On 16/03/2023 12:36 p.m., Tiago Olivoto wrote:
> > Hi,
> > My package pliman depends on EBImage which is in Bioconductor. I have
> > created a function check_ebi() <
> >
> https://github.com/TiagoOlivoto/pliman/blob/e6efc4b6a2396600939e308c235aeb9ab47af375/R/utilities.R#L534
> >
> > that is called in .onAttach() <
> > https://github.com/TiagoOlivoto/pliman/blob/master/R/zzz.R#L36>  and
> checks
> > if EBImage is installed. If not, the function asks the user to install
> it.
>
> If some other package loads but doesn't attach pliman, and is missing
> EBImage, does it fail gracefully?  That's also important.  I'd test what
> happens if a user runs pliman::object_edge( ... ) .  (That function
> isn't in the CRAN version, just the Github version, so I haven't tried
> this.)
>
> Duncan Murdoch
>
>
> > Both EBImage and BiocManager are listed as suggests <
> > https://github.com/TiagoOlivoto/pliman/blob/master/DESCRIPTION#L22>
> >
> > I believe that this could be a possible solution
> > Best regards,
> > Olivoto
> >
> >
> > Em qui., 16 de mar. de 2023 às 11:18, Ruff, Sergej <
> > sergej.r...@tiho-hannover.de> escreveu:
> >
> >> I am currently building a package which uses the "limma"-package as a
> >> dependency.
> >>
> >> I want to submit my package to CRAN.
> >>
> >> Do I need to declare Bioconductor-dependencies such as Limma differently
> >> in the Description-File of my Package?
> >>
> >> The Check-Function in R shows no Notes, Warnings or Errors, but I am not
> >> sure if that means that limma will install when installing my package
> from
> >> CRAN.
> >>
> >> Currently I am declaring limma like this:
> >>
> >> Suggests:
> >>
> >>  limma
> >>
> >>
> >>
> >> Can CRAN identify that limma is a Bioconductor-Package and will it Limma
> >> install, when installing my package from CRAN?
> >>
> >>  [[alternative HTML version deleted]]
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package

2023-03-16 Thread Tiago Olivoto
Hi Sergej,

I sincerely don't know if the position of biocView really matters (I'll try
it when preparing for the new CRAN release of pliman). I believe that
biocView will not allow you to put limma in the imports field and
automatically install it from Bioconductor, as you can see here in this
discussion <
https://stackoverflow.com/questions/54411495/bioconductor-packages-not-installing-with-biocviews-specification-in-description
>

In my case, I had no errors when submitting pliman to CRAN using EBImage as
suggests (I haven't yet tried to use biocView: and EBImage in the Imports
section).

Best regards,
Olivoto

Em qui., 16 de mar. de 2023 às 14:01, Ruff, Sergej <
sergej.r...@tiho-hannover.de> escreveu:

> thank you.
>
>
> I see you added biocView: below your suggested Dependencies. Is it
> necessary for CRAN to identify Bioconductor Dependencies and if so, should
> I add it below or above the suggested packages? Do I also need BiocManager
> among my Suggests?
>
>
> Last question: How does CRAN work with Bioconductor Dependencies? Will
> CRAN accept limma as a dependency or will my submission be rejected?
>
>
> Best regards,
>
> Sergej
> --
> *Von:* Tiago Olivoto 
> *Gesendet:* Donnerstag, 16. März 2023 17:36:47
> *An:* Ruff, Sergej
> *Cc:* r-package-devel@r-project.org
> *Betreff:* Re: [R-pkg-devel] How to declare Bioconductor Dependencies in
> the Description File of my R Package
>
> Hi,
> My package pliman depends on EBImage which is in Bioconductor. I have
> created a function check_ebi() <
> https://github.com/TiagoOlivoto/pliman/blob/e6efc4b6a2396600939e308c235aeb9ab47af375/R/utilities.R#L534>
> that is called in .onAttach() <
> https://github.com/TiagoOlivoto/pliman/blob/master/R/zzz.R#L36>  and
> checks if EBImage is installed. If not, the function asks the user to
> install it. Both EBImage and BiocManager are listed as suggests <
> https://github.com/TiagoOlivoto/pliman/blob/master/DESCRIPTION#L22>
>
> I believe that this could be a possible solution
> Best regards,
> Olivoto
>
>
> Em qui., 16 de mar. de 2023 às 11:18, Ruff, Sergej <
> sergej.r...@tiho-hannover.de> escreveu:
>
>> I am currently building a package which uses the "limma"-package as a
>> dependency.
>>
>> I want to submit my package to CRAN.
>>
>> Do I need to declare Bioconductor-dependencies such as Limma differently
>> in the Description-File of my Package?
>>
>> The Check-Function in R shows no Notes, Warnings or Errors, but I am not
>> sure if that means that limma will install when installing my package from
>> CRAN.
>>
>> Currently I am declaring limma like this:
>>
>> Suggests:
>>
>> limma
>>
>>
>>
>> Can CRAN identify that limma is a Bioconductor-Package and will it Limma
>> install, when installing my package from CRAN?
>>
>> [[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 declare Bioconductor Dependencies in the Description File of my R Package

2023-03-16 Thread Tiago Olivoto
Hi,
My package pliman depends on EBImage which is in Bioconductor. I have
created a function check_ebi() <
https://github.com/TiagoOlivoto/pliman/blob/e6efc4b6a2396600939e308c235aeb9ab47af375/R/utilities.R#L534>
that is called in .onAttach() <
https://github.com/TiagoOlivoto/pliman/blob/master/R/zzz.R#L36>  and checks
if EBImage is installed. If not, the function asks the user to install it.
Both EBImage and BiocManager are listed as suggests <
https://github.com/TiagoOlivoto/pliman/blob/master/DESCRIPTION#L22>

I believe that this could be a possible solution
Best regards,
Olivoto


Em qui., 16 de mar. de 2023 às 11:18, Ruff, Sergej <
sergej.r...@tiho-hannover.de> escreveu:

> I am currently building a package which uses the "limma"-package as a
> dependency.
>
> I want to submit my package to CRAN.
>
> Do I need to declare Bioconductor-dependencies such as Limma differently
> in the Description-File of my Package?
>
> The Check-Function in R shows no Notes, Warnings or Errors, but I am not
> sure if that means that limma will install when installing my package from
> CRAN.
>
> Currently I am declaring limma like this:
>
> Suggests:
>
> limma
>
>
>
> Can CRAN identify that limma is a Bioconductor-Package and will it Limma
> install, when installing my package from CRAN?
>
> [[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] Checking package dependencies before loading namespace

2021-09-06 Thread Tiago Olivoto
Thanks to all for the suggestions!
Best,
Tiago

Em sáb., 4 de set. de 2021 às 23:45, Martin Morgan 
escreveu:

> Actually, I think the right thing to do is to tell the user what to do
> ("To use this feature, install EBImage following the directions at
> https://bioconductor.org/packages/EBImage') instead of doing it for them.
>
> Martin
>
> From: Tiago Olivoto 
> Date: Friday, September 3, 2021 at 2:14 PM
> To: Martin Morgan 
> Cc: Uwe Ligges , R Package Devel <
> r-package-devel@r-project.org>
> Subject: Re: [R-pkg-devel] Checking package dependencies before loading
> namespace
> Thanks for your response Martin,
> I'm definitely thinking to use BiocManager::install("EBImage") since it is
> the official suggestion of the Bioconductor community. Anyway, I've been
> learning a lot from this discussion. Thanks all!!
> Best,
> Tiago
>
> Em sex., 3 de set. de 2021 às 12:58, Martin Morgan  mtmorgan.b...@gmail.com> escreveu:
> The specific repository you've chosen is not what you want to do. This
> will always install EBImage from Bioconductor version 3.13, but
> Bioconductor version 3.13 is only relevant for R-4.1 (see
> https://bioconductor.org/about/release-announcements/)
>
> Personally, I would encourage you to follow the Bioconductor community
> best practice of BiocManager::install("EBImage"). In that way you will get
> the version of EBImage that has been tested with other Bioconductor
> packages in the same release, and on the version of R in use by your user.
>
> If you were to use a specific repository, it should the one that is as
> good as base R can do (this can be different from the version that
> BiocManager would choose because R's release cycle is different from
> Bioconductor's). I think this is most easily accomplished by
> utils::chooseBioCmirror(), and then selecting the 0-Bioconductor
> repository. That's a lot to tell your users... Maybe others in the R
> community have a better way (the key information is in
> tools:::.BioC_version_associated_with_R_version(), but that is not an
> exported function so not recommended for CRAN packages...)
>
> Martin Morgan
>
> On 9/1/21, 8:13 AM, "R-package-devel on behalf of Tiago Olivoto"  r-package-devel-boun...@r-project.org on behalf of mailto:
> tiagooliv...@gmail.com> wrote:
>
> Thank you, Duncan and Uwe for the suggestions.
>  I followed your instructions and created a function to check for
> EBImage
> that is only called in an interactive section and, if necessary, ask
> the
> user to install the package with install.packages("EBImage", repos="
> https://bioconductor.org/packages/3.13/bioc;)
>
> Best,
> Tiago
>
> Em qua., 1 de set. de 2021 às 03:53, Uwe Ligges <
> mailto:lig...@statistik.tu-dortmund.de> escreveu:
>
> > Two more comments.
> >
> > 1. Note that your code only works in interactice mode, not when
> checking
> > your package as it waits infinitely for the user's choice.
> >
> > 2. I do not see an advantage of installing BiocManager if EBImage is
> > needed, the essential part is simply to select BioC as a repository
> to
> > install packages from.
> >
> > Best,
> > Uwe Ligges
> >
> >
> > On 31.08.2021 23:33, Duncan Murdoch wrote:
> > > People shouldn't be able to install your package unless the "hard"
> > > dependencies are available.
> > >
> > > If EBImage isn't essential to your package, you should make it a
> "soft"
> > > dependency by listing it in Suggests and checking for it every
> time you
> > > use it.
> > >
> > > Duncan Murdoch
> > >
> > > On 31/08/2021 3:20 p.m., Tiago Olivoto wrote:
> > >> Dear all,
> > >> I have a package called pliman
> > >> <https://CRAN.R-project.org/package=pliman>
> > >> which depends on the Bioconductor package EBImage.
> > >>
> > >> When running install.packages("pliman") I get the following
> warning
> > >>
> > >> Warning in install.packages :  dependency ‘EBImage’ is not
> available
> > >>
> > >> and thus when loading the package with library(pliman), the
> following
> > >> error
> > >> occurs
> > >>
> > >> Erro: package or namespace load failed for ‘pliman’ in
> loadNamespace(i,
> > >> c(lib.loc, .libPaths()), versionCheck = 

Re: [R-pkg-devel] Checking package dependencies before loading namespace

2021-09-03 Thread Tiago Olivoto
Thanks for your response Martin,
I'm definitely thinking to use BiocManager::install("EBImage") since it is
the official suggestion of the Bioconductor community. Anyway, I've been
learning a lot from this discussion. Thanks all!!
Best,
Tiago

Em sex., 3 de set. de 2021 às 12:58, Martin Morgan 
escreveu:

> The specific repository you've chosen is not what you want to do. This
> will always install EBImage from Bioconductor version 3.13, but
> Bioconductor version 3.13 is only relevant for R-4.1 (see
> https://bioconductor.org/about/release-announcements/)
>
> Personally, I would encourage you to follow the Bioconductor community
> best practice of BiocManager::install("EBImage"). In that way you will get
> the version of EBImage that has been tested with other Bioconductor
> packages in the same release, and on the version of R in use by your user.
>
> If you were to use a specific repository, it should the one that is as
> good as base R can do (this can be different from the version that
> BiocManager would choose because R's release cycle is different from
> Bioconductor's). I think this is most easily accomplished by
> utils::chooseBioCmirror(), and then selecting the 0-Bioconductor
> repository. That's a lot to tell your users... Maybe others in the R
> community have a better way (the key information is in
> tools:::.BioC_version_associated_with_R_version(), but that is not an
> exported function so not recommended for CRAN packages...)
>
> Martin Morgan
>
> On 9/1/21, 8:13 AM, "R-package-devel on behalf of Tiago Olivoto" <
> r-package-devel-boun...@r-project.org on behalf of tiagooliv...@gmail.com>
> wrote:
>
> Thank you, Duncan and Uwe for the suggestions.
>  I followed your instructions and created a function to check for
> EBImage
> that is only called in an interactive section and, if necessary, ask
> the
> user to install the package with install.packages("EBImage", repos="
> https://bioconductor.org/packages/3.13/bioc;)
>
> Best,
> Tiago
>
> Em qua., 1 de set. de 2021 às 03:53, Uwe Ligges <
> lig...@statistik.tu-dortmund.de> escreveu:
>
> > Two more comments.
> >
> > 1. Note that your code only works in interactice mode, not when
> checking
> > your package as it waits infinitely for the user's choice.
> >
> > 2. I do not see an advantage of installing BiocManager if EBImage is
> > needed, the essential part is simply to select BioC as a repository
> to
> > install packages from.
> >
> > Best,
> > Uwe Ligges
> >
> >
> > On 31.08.2021 23:33, Duncan Murdoch wrote:
> > > People shouldn't be able to install your package unless the "hard"
> > > dependencies are available.
> > >
> > > If EBImage isn't essential to your package, you should make it a
> "soft"
> > > dependency by listing it in Suggests and checking for it every
> time you
> > > use it.
> > >
> > > Duncan Murdoch
> > >
> > > On 31/08/2021 3:20 p.m., Tiago Olivoto wrote:
> > >> Dear all,
> > >> I have a package called pliman
> > >> <https://CRAN.R-project.org/package=pliman>
> > >> which depends on the Bioconductor package EBImage.
> > >>
> > >> When running install.packages("pliman") I get the following
> warning
> > >>
> > >> Warning in install.packages :  dependency ‘EBImage’ is not
> available
> > >>
> > >> and thus when loading the package with library(pliman), the
> following
> > >> error
> > >> occurs
> > >>
> > >> Erro: package or namespace load failed for ‘pliman’ in
> loadNamespace(i,
> > >> c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
> > >>   there is no package called ‘EBImage’
> > >>
> > >> I created a check function to check if EBImage is available and if
> > >> not, ask
> > >> users if they want to install it
> > >>
> > >> ---
> > >> check_ebi <- function(){
> > >>if(!requireNamespace("EBImage", quietly = TRUE)) {
> > >>  inst <-
> > >>  switch(menu(c("Yes", "No"), title = "Package {EBImage}
> required
> > >> but not
> > >> available.\nDo you want to install it now?"),
> &g

Re: [R-pkg-devel] Checking package dependencies before loading namespace

2021-09-01 Thread Tiago Olivoto
Thank you, Duncan and Uwe for the suggestions.
 I followed your instructions and created a function to check for EBImage
that is only called in an interactive section and, if necessary, ask the
user to install the package with install.packages("EBImage", repos="
https://bioconductor.org/packages/3.13/bioc;)

Best,
Tiago

Em qua., 1 de set. de 2021 às 03:53, Uwe Ligges <
lig...@statistik.tu-dortmund.de> escreveu:

> Two more comments.
>
> 1. Note that your code only works in interactice mode, not when checking
> your package as it waits infinitely for the user's choice.
>
> 2. I do not see an advantage of installing BiocManager if EBImage is
> needed, the essential part is simply to select BioC as a repository to
> install packages from.
>
> Best,
> Uwe Ligges
>
>
> On 31.08.2021 23:33, Duncan Murdoch wrote:
> > People shouldn't be able to install your package unless the "hard"
> > dependencies are available.
> >
> > If EBImage isn't essential to your package, you should make it a "soft"
> > dependency by listing it in Suggests and checking for it every time you
> > use it.
> >
> > Duncan Murdoch
> >
> > On 31/08/2021 3:20 p.m., Tiago Olivoto wrote:
> >> Dear all,
> >> I have a package called pliman
> >> <https://CRAN.R-project.org/package=pliman>
> >> which depends on the Bioconductor package EBImage.
> >>
> >> When running install.packages("pliman") I get the following warning
> >>
> >> Warning in install.packages :  dependency ‘EBImage’ is not available
> >>
> >> and thus when loading the package with library(pliman), the following
> >> error
> >> occurs
> >>
> >> Erro: package or namespace load failed for ‘pliman’ in loadNamespace(i,
> >> c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
> >>   there is no package called ‘EBImage’
> >>
> >> I created a check function to check if EBImage is available and if
> >> not, ask
> >> users if they want to install it
> >>
> >> ---
> >> check_ebi <- function(){
> >>if(!requireNamespace("EBImage", quietly = TRUE)) {
> >>  inst <-
> >>  switch(menu(c("Yes", "No"), title = "Package {EBImage} required
> >> but not
> >> available.\nDo you want to install it now?"),
> >> "yes", "no")
> >>  if(inst == "yes"){
> >>if (!requireNamespace("BiocManager", quietly = TRUE)){
> >>  install.packages("BiocManager")
> >>}
> >>BiocManager::install("EBImage", ask = FALSE, update = FALSE)
> >>  } else{
> >>message("To use {pliman}, first install {EBImage} with
> >> 'BiocManager::install(\"EBImage\")'.")
> >>  }
> >>}
> >> }
> >> ---
> >>
> >> Is there any way to run this function prior to namespace loading? I
> tried
> >> putting check_ebi() into .onLoad() but the same error occurs.
> >>
> >> Thanks in advance for any suggestions.
> >> Tiago
> >>
> >> [[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] Checking package dependencies before loading namespace

2021-08-31 Thread Tiago Olivoto
Dear all,
I have a package called pliman 
which depends on the Bioconductor package EBImage.

When running install.packages("pliman") I get the following warning

Warning in install.packages :  dependency ‘EBImage’ is not available

and thus when loading the package with library(pliman), the following error
occurs

Erro: package or namespace load failed for ‘pliman’ in loadNamespace(i,
c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
 there is no package called ‘EBImage’

I created a check function to check if EBImage is available and if not, ask
users if they want to install it

---
check_ebi <- function(){
  if(!requireNamespace("EBImage", quietly = TRUE)) {
inst <-
switch(menu(c("Yes", "No"), title = "Package {EBImage} required but not
available.\nDo you want to install it now?"),
   "yes", "no")
if(inst == "yes"){
  if (!requireNamespace("BiocManager", quietly = TRUE)){
install.packages("BiocManager")
  }
  BiocManager::install("EBImage", ask = FALSE, update = FALSE)
} else{
  message("To use {pliman}, first install {EBImage} with
'BiocManager::install(\"EBImage\")'.")
}
  }
}
---

Is there any way to run this function prior to namespace loading? I tried
putting check_ebi() into .onLoad() but the same error occurs.

Thanks in advance for any suggestions.
Tiago

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] R package submission fails due to mathjaxr package

2021-06-18 Thread Tiago Olivoto
Hi Mark,
I'm the maintainer of the 'metan' R package that uses mathjaxr. Please, be
sure you are declaring mathjaxr on 'Imports', not 'Suggest' field. In my
case, some time ago, I received an email from the CRAN team suggesting this
change. Please, let us know if this works!
Best,
Tiago


Em sex., 18 de jun. de 2021 às 17:42, Marc Scherstjanoi <
marc.scherstja...@thuenen.de> escreveu:

>
> Hi,
>
> I am about to sumbmit an R package.
>
> It passed the
> "R CMD check /package... --as-cran --no-manual"
> but not the
> "R CMD check /package... --as-cran".
>
> Our way of presenting mathematical equations by using the mathjaxr package
> seems to be not supported.
> As a result, building pdf fails automatically.
>
> We have already been aware of that and would like to submit the
> package manual pdf separately.
>
> How can this be done?
> Can our submission work without the rd to pdf process?
> Or is there a way to include the mathjaxr style for the texing?
>
> Thank you in advance,
>
> Marc
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] [Error] data length differs from size of matrix

2021-06-04 Thread Tiago Olivoto
Exactly Bill!
I'll implement your suggestion (solve_svd(cor.x2)%*%cor.y), to return betas.
Best!
Tiago


Em sex., 4 de jun. de 2021 às 15:12, Bill Dunlap 
escreveu:

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

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] [Error] data length differs from size of matrix

2021-06-04 Thread Tiago Olivoto
Thanks, Bill and Max for your suggestions.
I was using R 4.1.0. After updating to R-devel I was able to reproduce the
error, which was just fixed by using solve() instead solve_svd() in the
line suggested by Bill.

Best regards,
Tiago

Em sex., 4 de jun. de 2021 às 12:41, Bill Dunlap 
escreveu:

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

[[alternative HTML version deleted]]

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


[R-pkg-devel] [Error] data length differs from size of matrix

2021-06-03 Thread Tiago Olivoto
Dear all,
I have received an email from the CRAN team to fix a problem with my R
package metan > to safely retain it on CRAN.

The error is given at 
and seems to be related to data different from size of matrix.

The question is that and I cannot reproduce the error locally and thus not
able to fix anything. By googling the error I've seen similar issues with a
lot of other packages. Could be this be a temporary issue?

Thanks in advance!
Tiago

[[alternative HTML version deleted]]

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


[R-pkg-devel] Installed image not found in Debian

2021-05-11 Thread Tiago Olivoto
Dear all,
I just submitted a new package 'pliman' (
https://github.com/TiagoOlivoto/pliman) and it does not pass the incoming
checks automatically.
I have some images that are under '/inst/tmp_images' to be installed with
the package. In some examples and Vignettes, I use the helper function
image_pliman() <
https://github.com/TiagoOlivoto/pliman/blob/master/R/utils_imagem.R#L125>
to get the patch of a given image

Then, I use image_import() <
https://github.com/TiagoOlivoto/pliman/blob/master/R/utils_imagem.R#L69> to
import the image into R.

All tests passed in Windows <
https://win-builder.r-project.org/incoming_pretest/pliman_0.1.0_20210511_212904/Windows/00check.log>
but an error was got in Debian <
https://win-builder.r-project.org/incoming_pretest/pliman_0.1.0_20210511_212904/Debian/00check.log
>
The error occurs when image_import () has been called, for example

image_import(image_pliman("soybean_touch.jpg"))
Error:  'soybean_touch' not found in
.//srv/hornik/tmp/CRAN/pliman.Rcheck/pliman/tmp_images

It seems that this error comes from this check <
https://github.com/TiagoOlivoto/pliman/blob/master/R/utils_imagem.R#L92-L97>
that checks if the image name is available in the directory. Please, see a
toy example with my data.

# Get the patch of the image
image <- image_pliman("soybean_touch.jpg")
image
[1] "E:/Documents/R/win-library/4.0/pliman/tmp_images/soybean_touch.jpg"

# Get the directory of the image
img_dir <- file_dir(image)
> img_dir
[1] "E:/Documents/R/win-library/4.0/pliman/tmp_images"

# Get all files in the directory
> all_files <- sapply(list.files(img_dir), file_name)
> all_files
background.jpgla_back.jpgla_leaf.jpg  la_leaves.JPG
  "background"  "la_back"  "la_leaf""la_leaves"
la_pattern.JPGla_temp.jpg objects_300dpi.jpg   sev_back.jpg
  "la_pattern"  "la_temp"   "objects_300dpi" "sev_back"
   sev_healthy.jpg   sev_leaf.jpgsev_leaf_nb.jpg  sev_sympt.jpg
 "sev_healthy" "sev_leaf"  "sev_leaf_nb""sev_sympt"
 soy_green.jpg  soybean_grain.jpg  soybean_touch.jpg
   "soy_green""soybean_grain""soybean_touch"

# Get the name of the image and check if it is in the directory
> img_name <- file_name(image)
> img_name
[1] "soybean_touch"

if(!grepl("http", img_dir, fixed = TRUE) & !img_name %in% all_files){
  stop(" '", img_name, "' not found in ", img_dir,  call. = FALSE)
}

In this case, there is no error since  "soybean_touch" is in 'all_files'

I have no idea how to fix this issue and why this error occurs only on
Debian and not on Windows. Any suggestion to fix the error and/or improve
the code will be welcome!
Thanks in advance,
Tiago

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] Using ggplot2 within another package

2021-04-23 Thread Tiago Olivoto
Hi everyone,
One suggestion would be import ggplot2 and using tidy eval operators to
create a function. One simple reproducible example would be

library(ggplot2)
my_hist <- function(df, var){
  ggplot(df, aes({{var}})) +
geom_histogram()
}

df <- data.frame(my_var = rnorm(400, 10, 2))
my_hist(df = df, var = my_var)

All the best
Tiago

Em sex., 23 de abr. de 2021 às 09:04, Mike Collyer 
escreveu:

> Hi Kevin,
>
> I recently developed a plot function in a package that used ggplot and ran
> into the same problem.  I overcame the problem with a first line of
> (useless) code as
>
> myX <- myY <- NULL
>
> I found the solution inelegant but it worked.
>
> cheers!
> Mike
>
> > On Apr 22, 2021, at 4:28 PM, Kevin R. Coombes 
> wrote:
> >
> > Hi,
> >
> > I'm trying to help clean up an R package for someone else to submit to
> CRAN. He has used ggplot2 to implement a plotting function for the kinds of
> things that his packages generates. His plotting routine basically looks
> like (after changing names to protect the innocent):
> >
> > myPlot <- fucntion(myData, ...) {
> ># get ready
> >ggplot(myData, aes(x = myX, y = myY)) +
> >   # add my decorations
> >   theme_bw()
> > }
> >
> > Of course, "R CMD check --as-cran" complains that there is no global
> binding for "myX" or "myY" since they are columns defined in the data.frame
> "myData".
> >
> > What is the best way to work around this issue?
> >
> > Of course, dinosaurs like myself might be tempted to suggest just using
> plain old "plot", so I don't need to see those suggestions.
> >
> > Do I just ignore the usual ggplot conventions and write "myData$myX"
> inside "aes"  in order to appease the CRAN checker? Or is there some
> tidy-er way to solve this problem?
> >
> > Thanks,
> >   Kevin
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] Assigning a variable to global environment

2020-12-11 Thread Tiago Olivoto
Thanks, everyone,

Following Mark suggestion:

The problem I'm trying to solve is:
Users of my package metan (https://CRAN.R-project.org/package=metan),
sometimes need to extract 2-3 variables from a given data.frame and put
them as vectors in the global environment to use in other package's
functions.
Given that df has the columns, ENV, GEN, REP, I would need to run the
following codes
ENV <- df$ENV
GEN <- df$GEN
REP <- df$GEN
I'm looking for a more efficient way to do that and just finished the
following function

as_vector <- function(.data, ...){
  if(missing(...)){
df <- select(.data, everything())
  } else{
df <- select(.data, ...)
  }
  for(i in 1:ncol(df)){
var_name <- names(df[i])
var_name <- ifelse(exists(var_name, envir = .GlobalEnv),
 paste(var_name, "_vct", sep = ""),
 var_name)
assign(var_name, as.vector(df[[i]]), envir = .GlobalEnv)
  }
}

Then, users could simply run as_vector(df) or  as_vector(df, GEN, ENV)
But I'm not sure if this fits with the CRAN policies.
Cherss,
Tiago

Em sex., 11 de dez. de 2020 às 16:03, Ben Bolker 
escreveu:

>I think this solution will *not* be acceptable to CRAN. (The policy
> doesn't say "don't modify the global workspace unless you're careful",
> it says "don't modify the global workspace".)  You can ask for an
> exception, but your chances of success are very low.
>
> It would be best to find a way to solve your problem without
> assigning to the global workspace.  Can you assign to an environment
> that is contained within your package, which all of the functions in
> your package will also have access to?
>
>cheers
>  Ben Bolker
>
> On 12/11/20 1:52 PM, Tiago Olivoto wrote:
> > Thank Matt for your response.
> > Would be an acceptable solution to check if the variable exists first and
> > creating the new variable with a suffix? Please, see the following
> example
> >
> >  var_name <-  "name"
> >  var_name <- ifelse(exists(var_name),
> >   paste(var_name, "_vct", sep = ""),
> >   var_name)
> > and then
> >
> > assign(var_name, 1, envir = .GlobalEnv)
> >
> > Cheers,
> > Tiago
> >
> > Em sex., 11 de dez. de 2020 às 15:20, Matt Denwood 
> escreveu:
> >
> >>
> >>> On 11 Dec 2020, at 18:32, Tiago Olivoto 
> wrote:
> >>>
> >>> Hi everyone,
> >>> This can be a very simple question, but I really have the following
> >> doubt.
> >>>
> >>> CRAN Policies says that 'Packages should not modify the global
> >> environment
> >>> (user’s workspace)'. So, may I or may I not create a function that will
> >>> call internally the following code? (a simple example)
> >>>
> >>> assign("name", 1, envir = .GlobalEnv)
> >>
> >> You may not - and for good reason, as the user may have an existing
> >> variable called “name” that will be destroyed by such an action.  If you
> >> run "R CMD check —as-cran" on a package containing this code you will
> get a
> >> warning (or maybe a note, I can’t remember), and the package would most
> >> likely be refused if you tried to submit it to CRAN.
> >>
> >> Cheers,
> >>
> >> Matt
> >>
> >>
> >>>
> >>> Cheers
> >>> Tiago
> >>>
> >>>[[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>>
> >>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=04%7C01%7Cmd%40sund.ku.dk%7C42392098d3324de389b008d89dfad39d%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C637433048371869663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=NFTbsJDlZNQWajN%2F%2BeftuclrkJSGtTnM9kEtobn9VLs%3Dreserved=0
> >>
> >>
> >
> >   [[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


Re: [R-pkg-devel] Assigning a variable to global environment

2020-12-11 Thread Tiago Olivoto
Thank Matt for your response.
Would be an acceptable solution to check if the variable exists first and
creating the new variable with a suffix? Please, see the following example

var_name <-  "name"
var_name <- ifelse(exists(var_name),
 paste(var_name, "_vct", sep = ""),
 var_name)
and then

assign(var_name, 1, envir = .GlobalEnv)

Cheers,
Tiago

Em sex., 11 de dez. de 2020 às 15:20, Matt Denwood  escreveu:

>
> > On 11 Dec 2020, at 18:32, Tiago Olivoto  wrote:
> >
> > Hi everyone,
> > This can be a very simple question, but I really have the following
> doubt.
> >
> > CRAN Policies says that 'Packages should not modify the global
> environment
> > (user’s workspace)'. So, may I or may I not create a function that will
> > call internally the following code? (a simple example)
> >
> > assign("name", 1, envir = .GlobalEnv)
>
> You may not - and for good reason, as the user may have an existing
> variable called “name” that will be destroyed by such an action.  If you
> run "R CMD check —as-cran" on a package containing this code you will get a
> warning (or maybe a note, I can’t remember), and the package would most
> likely be refused if you tried to submit it to CRAN.
>
> Cheers,
>
> Matt
>
>
> >
> > Cheers
> > Tiago
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=04%7C01%7Cmd%40sund.ku.dk%7C42392098d3324de389b008d89dfad39d%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C637433048371869663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=NFTbsJDlZNQWajN%2F%2BeftuclrkJSGtTnM9kEtobn9VLs%3Dreserved=0
>
>

[[alternative HTML version deleted]]

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


[R-pkg-devel] Assigning a variable to global environment

2020-12-11 Thread Tiago Olivoto
Hi everyone,
This can be a very simple question, but I really have the following doubt.

CRAN Policies says that 'Packages should not modify the global environment
(user’s workspace)'. So, may I or may I not create a function that will
call internally the following code? (a simple example)

assign("name", 1, envir = .GlobalEnv)

Cheers
Tiago

[[alternative HTML version deleted]]

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


[R-pkg-devel] RES: Additional issues for the last version released on CRAN

2020-06-07 Thread Tiago Olivoto
Thanks, Uwe:
Now, metan is on its way to CRAN.
Best
Tiago

-Mensagem original-
De: Uwe Ligges  
Enviada em: domingo, 7 de junho de 2020 14:09
Para: tiagooliv...@gmail.com; r-package-devel@r-project.org
Assunto: Re: [R-pkg-devel] Additional issues for the last version released on 
CRAN

Right, so "reply-all and and explain: Have these been fixed?"

Best,
Uwe Ligges

On 04.06.2020 15:16, Tiago Olivoto wrote:
> Dear all,
> 
> I have submitted a patch release (1.6.0) of my package metan
> (https://cran.r-project.org/web/packages/metan/) to fix an additional 
> issue and implement some improvements. All local checks had no errors 
> or warnings, but after the submission process, I received the following 
> message.
> 
>   
> 
> <<>>
> 
>   
> 
> Dear maintainer,
> 
> package metan_1.6.1.tar.gz has been auto-processed.
> 
> The auto-check found additional issues for the *last* version released 
> on
> CRAN:
> 
>donttest < <https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
> https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
> 
> CRAN incoming checks do not test for these additional issues and you 
> will need an appropriately instrumented build of R to reproduce these.
> 
> Hence please reply-all and explain: Have these been fixed?
> 
> Log dir:
> <https://win-builder.r-project.org/incoming_pretest/metan_1.6.1_202006
> 03_062
> 635/>
> 
> The files will be removed after roughly 7 days.
> 
> Installation time in seconds: 52
> 
> Check time in seconds: 407
> 
> R Under development (unstable) (2020-05-29 r78617)
> 
> Pretests results:
> 
> Windows: <
> <https://win-builder.r-project.org/incoming_pretest/metan_1.6.1_202006
> 03_062
> 635/Windows/00check.log>
> https://win-builder.r-project.org/incoming_pretest/metan_1.6.1_2020060
> 3_0626
> 35/Windows/00check.log>
> 
> Status: OK
> 
> Debian: <
> <https://win-builder.r-project.org/incoming_pretest/metan_1.6.1_202006
> 03_062
> 635/Debian/00check.log>
> https://win-builder.r-project.org/incoming_pretest/metan_1.6.1_2020060
> 3_0626
> 35/Debian/00check.log>
> 
> Status: OK
> 
> Last released version's CRAN status: OK: 12
> 
> See: < 
> <https://CRAN.R-project.org/web/checks/check_results_metan.html>
> https://CRAN.R-project.org/web/checks/check_results_metan.html>
> 
> Last released version's additional issues:
> 
>donttest < <https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
> https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>
> 
> CRAN Web: < <https://cran.r-project.org/package=metan>
> https://cran.r-project.org/package=metan>
> 
> No strong reverse dependencies to be checked.
> 
>   
> 
> <<>>
> 
>   
> 
> I replied to  <mailto:cran-submissi...@r-project.org> >  explaining how the error 
> was fixed, but since this is my first experience with an issue like 
> that, I'm not sure if I need to do anything more or simply await a 
> response from the CRAN team.
> 
> Thanks in advance for any comments or suggestion,
> 
> Tiago
> 
>   
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

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


[R-pkg-devel] Additional issues for the last version released on CRAN

2020-06-04 Thread Tiago Olivoto
Dear all,

I have submitted a patch release (1.6.0) of my package metan
(https://cran.r-project.org/web/packages/metan/) to fix an additional issue
and implement some improvements. All local checks had no errors or warnings,
but after the submission process, I received the following message.

 

<<>>

 

Dear maintainer,

package metan_1.6.1.tar.gz has been auto-processed.

The auto-check found additional issues for the *last* version released on
CRAN:

  donttest < 
https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>

CRAN incoming checks do not test for these additional issues and you will
need an appropriately instrumented build of R to reproduce these.

Hence please reply-all and explain: Have these been fixed?

Log dir:


The files will be removed after roughly 7 days.

Installation time in seconds: 52

Check time in seconds: 407 

R Under development (unstable) (2020-05-29 r78617)

Pretests results:

Windows: <

https://win-builder.r-project.org/incoming_pretest/metan_1.6.1_20200603_0626
35/Windows/00check.log>

Status: OK

Debian: <

https://win-builder.r-project.org/incoming_pretest/metan_1.6.1_20200603_0626
35/Debian/00check.log>

Status: OK

Last released version's CRAN status: OK: 12

See: < 
https://CRAN.R-project.org/web/checks/check_results_metan.html>

Last released version's additional issues:

  donttest < 
https://www.stats.ox.ac.uk/pub/bdr/donttest/metan.out>

CRAN Web: < 
https://cran.r-project.org/package=metan>

No strong reverse dependencies to be checked.

 

<<>>

 

I replied to mailto:cran-submissi...@r-project.org> >  explaining how the error was
fixed, but since this is my first experience with an issue like that, I'm
not sure if I need to do anything more or simply await a response from the
CRAN team.

Thanks in advance for any comments or suggestion,

Tiago

 


[[alternative HTML version deleted]]

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


[R-pkg-devel] RES: RES: RES: MathJax for Rd files

2020-05-13 Thread Tiago Olivoto
I installed the 'devel' version of mathjaxr and tested preview_rd()
All seems to be working fine!
Thank you for the quick and useful implementation!
Best,
Olivoto

-Mensagem original-
De: Viechtbauer, Wolfgang (SP)  
Enviada em: quarta-feira, 13 de maio de 2020 18:26
Para: tiagooliv...@gmail.com; 'Duncan Murdoch' ; 
r-package-devel@r-project.org
Assunto: RE: RES: [R-pkg-devel] RES: MathJax for Rd files

I've added a preview_rd() function to the 'devel' version of mathjaxr:

https://github.com/wviechtb/mathjaxr

If you want to give this a try:

remotes::install_github("wviechtb/mathjaxr")
library(mathjaxr)

Then set the working dir to the root of the package you are working on. Then 
use:

preview_rd(Rdfile)

with the name of the Rd file given as a character string (either with or 
without the .Rd/.rd extension).

By default, the browser (or a new tab in your browser) should open up. But if 
you then make further changes to the Rd file, opening up a new tab each time is 
inconvenient. Use:

preview_rd(Rdfile, view=FALSE)

to prevent that (then just refresh the page in the open tab in your browser to 
see the updates).

One limitation: As far as I can tell, it will not be possible to load MathJax 
from the mathjaxr package when using preview_rd(). So, it will be loaded via 
the CDN, which means that you need an internet connection for equations to 
render.

Best,
Wolfgang

>-Original Message-
>From: Tiago Olivoto [mailto:tiagooliv...@gmail.com]
>Sent: Wednesday, 13 May, 2020 21:25
>To: 'Duncan Murdoch'; Viechtbauer, Wolfgang (SP); r-package-devel@r- 
>project.org
>Subject: RES: RES: [R-pkg-devel] RES: MathJax for Rd files
>
>Definitively this is a better way to find the macros.
>I think a function like 'preview_rd()' could be useful in mathjaxr
>
>Thanks for all support
>Olivoto
>
>-Mensagem original-
>De: Duncan Murdoch  Enviada em: quarta-feira, 
>13 de maio de 2020 16:16
>Para: tiagooliv...@gmail.com; 'Viechtbauer, Wolfgang (SP)'
>; r-package-devel@r- 
>project.org
>Assunto: Re: RES: [R-pkg-devel] RES: MathJax for Rd files
>
>On 13/05/2020 2:30 p.m., Tiago Olivoto wrote:
>> Thank you so much! It works!
>> In my example, I've created a simple helper function, preview_rd()
>>
>> preview_rd <- function(rdfile){ # without '.rd'
>> Rd <- file.path(paste("man/", rdfile, ".rd", sep = "")) # specify the 
>> .Rd file you want to preview outfile <- tempfile(fileext = ".html") 
>> browseURL(tools::Rd2HTML(Rd, outfile, 
>> macros="D:/Documents/R/win-library/4.0/mathjaxr/help/macros/mathjax.R
>> d
>> "))
>> }
>
>Good to hear.  I'd suggest this way to find the macros:
>
>   browseURL(tools::Rd2HTML(Rd, outfile, macros = 
>system.file("help/macros/mathjax.Rd", package = "mathjaxr")))
>
>so that it works if you use it on a different system that puts the 
>library somewhere else.
>
>Duncan Murdoch

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


[R-pkg-devel] RES: RES: RES: MathJax for Rd files

2020-05-13 Thread Tiago Olivoto
Definitively this is a better way to find the macros.
I think a function like 'preview_rd()' could be useful in mathjaxr

Thanks for all support
Olivoto

-Mensagem original-
De: Duncan Murdoch  
Enviada em: quarta-feira, 13 de maio de 2020 16:16
Para: tiagooliv...@gmail.com; 'Viechtbauer, Wolfgang (SP)' 
; r-package-devel@r-project.org
Assunto: Re: RES: [R-pkg-devel] RES: MathJax for Rd files

On 13/05/2020 2:30 p.m., Tiago Olivoto wrote:
> Thank you so much! It works!
> In my example, I've created a simple helper function, preview_rd()
> 
> preview_rd <- function(rdfile){ # without '.rd'
> Rd <- file.path(paste("man/", rdfile, ".rd", sep = "")) # specify the 
> .Rd file you want to preview outfile <- tempfile(fileext = ".html") 
> browseURL(tools::Rd2HTML(Rd, outfile, 
> macros="D:/Documents/R/win-library/4.0/mathjaxr/help/macros/mathjax.Rd
> "))
> }

Good to hear.  I'd suggest this way to find the macros:

   browseURL(tools::Rd2HTML(Rd, outfile, macros = 
system.file("help/macros/mathjax.Rd", package = "mathjaxr")))

so that it works if you use it on a different system that puts the library 
somewhere else.

Duncan Murdoch

> 
> I added the macros \loadmathjax and \mjsdeqn in the mgidi.R file, ran 
> devtools::document() and then preview_rd("mgidi") The html was rendered 
> nicely (in my browser) and shows the equation without installing the package.
> That's what I was looking for.
> Thanks again!
> Olivoto
> 
> -Mensagem original-
> De: Viechtbauer, Wolfgang (SP) 
> 
> Enviada em: quarta-feira, 13 de maio de 2020 14:41
> Para: Duncan Murdoch ; 
> tiagooliv...@gmail.com; r-package-devel@r-project.org
> Assunto: RE: [R-pkg-devel] RES: MathJax for Rd files
> 
> Thanks, Duncan. I was about to respond to suggest the same thing.
> 
> One way of getting this to work:
> 
> Sys.setenv(MATHJAXR.USECDN = "TRUE")
> Rd <- file.path("/.Rd") # specify the .Rd file you want to 
> preview outfile <- tempfile(fileext = ".html") 
> browseURL(tools::Rd2HTML(Rd, outfile, macros=" mathjaxr is installed>/mathjaxr/help/macros/mathjax.Rd"))
> 
> Best,
> Wolfgang
> 
>> -Original Message-
>> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
>> Sent: Wednesday, 13 May, 2020 19:30
>> To: tiagooliv...@gmail.com; Viechtbauer, Wolfgang (SP); 'Helmut 
>> Schütz'; r- package-de...@r-project.org
>> Subject: Re: [R-pkg-devel] RES: MathJax for Rd files
>>
>> On 13/05/2020 12:35 p.m., Tiago Olivoto wrote:
>>> Thanks, Wolfgang and Helmut for the explanations.
>>> When I was trying to use
>>>
>>> #'\if{html}{\out{'>> #''src="<a  rel="nofollow" href="https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-ful">https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-ful</a>
>>> l
>>> .js
>>> #' }}
>>> #'
>>> #'And then typing
>>> #' \ifelse{html}{\out{\[\sqrt{a^2}\]}}{\deqn{\sqrt{a^2}}}
>>> My mgidi.Rd file was produced with devtools::document(); then, I 
>>> just used ?mgidi, and the html page was rendered nicely.
>>>
>>> If I could do the same with mathjaxr, It would be nice, because I 
>>> wouldn't
>> need to install the package to see if the equations are as I expect
>>> Anyway, mathjaxr is a very useful package.
>>> Congratulations on the efforts for developing it.
>>
>> Sounds like it's a devtools issue.  I don't know how they are 
>> simulating the install, but it needs to say to use the mathjaxr 
>> macros when converting the Rd pages.
>>
>> Duncan Murdoch
>>
>>> Best
>>> Olivoto
>>>
>>> -Mensagem original-
>>> De: Viechtbauer, Wolfgang (SP)
>> 
>>> Enviada em: quarta-feira, 13 de maio de 2020 13:14
>>> Para: Helmut Schütz ; 
>>> tiagooliv...@gmail.com; r-
>> package-de...@r-project.org
>>> Assunto: RE: [R-pkg-devel] MathJax for Rd files
>>>
>>> Thanks for the info! Can confirm now that I tried this (I don't 
>>> usually
>> use RStudio). That's an RStudio issue then. My guess is that 'Preview'
>> uses
>> tools::Rd2HTML() and that indeed won't automatically understand 
>> macros coming from mathjaxr (or any add-on package for that matter). 
>> This would be an issue to raise with the RStudio folks then.
>>>
>>> But once a package is installed, the equations are nicely rendered 
>>> also in
>> the RStudio help browser, so that part works.
>>>
>>> B

[R-pkg-devel] RES: RES: MathJax for Rd files

2020-05-13 Thread Tiago Olivoto
Thank you so much! It works!
In my example, I've created a simple helper function, preview_rd()

preview_rd <- function(rdfile){ # without '.rd'
Rd <- file.path(paste("man/", rdfile, ".rd", sep = "")) # specify the .Rd file 
you want to preview
outfile <- tempfile(fileext = ".html")
browseURL(tools::Rd2HTML(Rd, outfile, 
macros="D:/Documents/R/win-library/4.0/mathjaxr/help/macros/mathjax.Rd"))
}

I added the macros \loadmathjax and \mjsdeqn in the mgidi.R file, ran 
devtools::document() and then preview_rd("mgidi")
The html was rendered nicely (in my browser) and shows the equation without 
installing the package.
That's what I was looking for.
Thanks again!
Olivoto

-Mensagem original-
De: Viechtbauer, Wolfgang (SP)  
Enviada em: quarta-feira, 13 de maio de 2020 14:41
Para: Duncan Murdoch ; tiagooliv...@gmail.com; 
r-package-devel@r-project.org
Assunto: RE: [R-pkg-devel] RES: MathJax for Rd files

Thanks, Duncan. I was about to respond to suggest the same thing.

One way of getting this to work:

Sys.setenv(MATHJAXR.USECDN = "TRUE")
Rd <- file.path("/.Rd") # specify the .Rd file you want to preview 
outfile <- tempfile(fileext = ".html") browseURL(tools::Rd2HTML(Rd, outfile, 
macros="/mathjaxr/help/macros/mathjax.Rd"))

Best,
Wolfgang

>-Original Message-
>From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
>Sent: Wednesday, 13 May, 2020 19:30
>To: tiagooliv...@gmail.com; Viechtbauer, Wolfgang (SP); 'Helmut 
>Schütz'; r- package-de...@r-project.org
>Subject: Re: [R-pkg-devel] RES: MathJax for Rd files
>
>On 13/05/2020 12:35 p.m., Tiago Olivoto wrote:
>> Thanks, Wolfgang and Helmut for the explanations.
>> When I was trying to use
>>
>> #'\if{html}{\out{'> #''src="<a  rel="nofollow" href="https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full">https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full</a>
>> .js
>> #' }}
>> #'
>> #'And then typing
>> #' \ifelse{html}{\out{\[\sqrt{a^2}\]}}{\deqn{\sqrt{a^2}}}
>> My mgidi.Rd file was produced with devtools::document(); then, I just 
>> used ?mgidi, and the html page was rendered nicely.
>>
>> If I could do the same with mathjaxr, It would be nice, because I 
>> wouldn't
>need to install the package to see if the equations are as I expect
>> Anyway, mathjaxr is a very useful package.
>> Congratulations on the efforts for developing it.
>
>Sounds like it's a devtools issue.  I don't know how they are 
>simulating the install, but it needs to say to use the mathjaxr macros 
>when converting the Rd pages.
>
>Duncan Murdoch
>
>> Best
>> Olivoto
>>
>> -Mensagem original-
>> De: Viechtbauer, Wolfgang (SP)
>
>> Enviada em: quarta-feira, 13 de maio de 2020 13:14
>> Para: Helmut Schütz ; 
>> tiagooliv...@gmail.com; r-
>package-de...@r-project.org
>> Assunto: RE: [R-pkg-devel] MathJax for Rd files
>>
>> Thanks for the info! Can confirm now that I tried this (I don't 
>> usually
>use RStudio). That's an RStudio issue then. My guess is that 'Preview' 
>uses
>tools::Rd2HTML() and that indeed won't automatically understand macros 
>coming from mathjaxr (or any add-on package for that matter). This 
>would be an issue to raise with the RStudio folks then.
>>
>> But once a package is installed, the equations are nicely rendered 
>> also in
>the RStudio help browser, so that part works.
>>
>> Best,
>> Wolfgang
>>
>>> -Original Message-
>>> From: Helmut Schütz [mailto:helmut.schu...@bebac.at]
>>> Sent: Wednesday, 13 May, 2020 17:01
>>> To: Viechtbauer, Wolfgang (SP); tiagooliv...@gmail.com;
>>> r-package-devel@r- project.org
>>> Subject: Re: [R-pkg-devel] MathJax for Rd files
>>>
>>> Hi Wolfgang,
>>>
>>> Viechtbauer, Wolfgang (SP) wrote on 2020-05-13 16:53:
>>>> Seems like you are using roxygen2. I have little experience with 
>>>> that, as
>>> all my Rd files are 'handcrafted' (plus 100% organic and biodegradable).
>>>
>>> As are mine. ;-)
>>> In the HTML-preview of RStudio the LaTeX is indeed not parsed. I get 
>>> it only (in the HTML man-page and the PDF) if I build the package.
>>>
>>> Helmut
>>>
>>> --
>>> Ing. Helmut Schütz
>>> BEBAC – Consultancy Services for
>>> Bioequivalence and Bioavailability Studies Neubaugasse 36/11
>>> 1070 Vienna, Austria
>>> E helmut.schu...@bebac.at
>>> W https://bebac.at/
>>> F https://forum.bebac.at/

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


[R-pkg-devel] RES: MathJax for Rd files

2020-05-13 Thread Tiago Olivoto
Thanks, Wolfgang and Helmut for the explanations.
When I was trying to use

#'\if{html}{\out{'https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full.js
#' }}
#'
#'And then typing
#' \ifelse{html}{\out{\[\sqrt{a^2}\]}}{\deqn{\sqrt{a^2}}}
My mgidi.Rd file was produced with devtools::document();
then, I just used ?mgidi, and the html page was rendered nicely.

If I could do the same with mathjaxr, It would be nice, because I wouldn't need 
to install the package to see if the equations are as I expect
Anyway, mathjaxr is a very useful package.
Congratulations on the efforts for developing it.

Best
Olivoto

-Mensagem original-
De: Viechtbauer, Wolfgang (SP)  
Enviada em: quarta-feira, 13 de maio de 2020 13:14
Para: Helmut Schütz ; tiagooliv...@gmail.com; 
r-package-devel@r-project.org
Assunto: RE: [R-pkg-devel] MathJax for Rd files

Thanks for the info! Can confirm now that I tried this (I don't usually use 
RStudio). That's an RStudio issue then. My guess is that 'Preview' uses 
tools::Rd2HTML() and that indeed won't automatically understand macros coming 
from mathjaxr (or any add-on package for that matter). This would be an issue 
to raise with the RStudio folks then.

But once a package is installed, the equations are nicely rendered also in the 
RStudio help browser, so that part works.

Best,
Wolfgang

>-Original Message-
>From: Helmut Schütz [mailto:helmut.schu...@bebac.at]
>Sent: Wednesday, 13 May, 2020 17:01
>To: Viechtbauer, Wolfgang (SP); tiagooliv...@gmail.com; 
>r-package-devel@r- project.org
>Subject: Re: [R-pkg-devel] MathJax for Rd files
>
>Hi Wolfgang,
>
>Viechtbauer, Wolfgang (SP) wrote on 2020-05-13 16:53:
>> Seems like you are using roxygen2. I have little experience with 
>> that, as
>all my Rd files are 'handcrafted' (plus 100% organic and biodegradable).
>
>As are mine. ;-)
>In the HTML-preview of RStudio the LaTeX is indeed not parsed. I get it 
>only (in the HTML man-page and the PDF) if I build the package.
>
>Helmut
>
>--
>Ing. Helmut Schütz
>BEBAC – Consultancy Services for
>Bioequivalence and Bioavailability Studies Neubaugasse 36/11
>1070 Vienna, Austria
>E helmut.schu...@bebac.at
>W https://bebac.at/
>F https://forum.bebac.at/

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


[R-pkg-devel] RES: MathJax for Rd files

2020-05-13 Thread Tiago Olivoto
Dear Wolfgang,
Thank you so much for the awesome package
I've installed mathjaxr and it worked.
I have some more questions, with a short example bellow
I created an equation in my mgidi.R file as follows

#' \loadmathjax
#' \mjsdeqn{MGIDI_i = \sum\limits_{j = 1}^f}

And then I ran devtools::document()
The mgidi.Rd contains

\loadmathjax
\mjsdeqn{MGIDI_i = \sum\limits_{j = 1}^f}

But when I try to preview the current document as HTML, the equation is not
rendered and the help page shows
\loadmathjax \mjsdeqnMGIDI_i = \sum\limits_j = 1^f
The equation is only rendered after I install my package locally with
devtools::install(). Is this an expected behavior?

Another question is regarding more complex formulae.
I tried using
#' \loadmathjax
#' \mjsdeqn{MGID{I_i} = {\left[ {\sum\limits_{j = 1}^f {{{\left( {{F_{ij}} -
{F_j}} \right)}^2}} } \right]^{0.5}}}

Even after installing the package locally the equation is not rendered in
the html help page, which shows the tex command. 
I tested the same equation with https://www.mathjax.org/#demo and it seems
to be ok.
Have I missed anything or used any code not supported by mathjaxr?
Thanks in advance
Olivoto

-Mensagem original-
De: Viechtbauer, Wolfgang (SP)
 
Enviada em: quarta-feira, 13 de maio de 2020 04:40
Para: tiagooliv...@gmail.com; r-package-devel@r-project.org
Assunto: RE: [R-pkg-devel] MathJax for Rd files

Dear Olivoto,

There is a package now for this purpose:

https://cran.r-project.org/package=mathjaxr
https://github.com/wviechtb/mathjaxr

Best,
Wolfgang

>-Original Message-
>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On 
>Behalf Of Tiago Olivoto
>Sent: Wednesday, 13 May, 2020 8:55
>To: r-package-devel@r-project.org
>Subject: [R-pkg-devel] MathJax for Rd files
>
>Dear all,
>
>I'm not sure if this is the correct place to make this question, but 
>here I am.
>
>I'm trying to use MathJax for html help files in my package metan
>(https://cran.r-project.org/package=metan)
>
>I have success with the following approach:
>
>Including the following call
>
>#'\if{html}{\out{
>
>#'
>#'src="<a  rel="nofollow" href="https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full.js">https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full.js</a>
>">
>
>#'  
>
>#'}}
>
>And then typing the equations I need. A simple example bellow
>
>#' \ifelse{html}{\out{\[\sqrt{a^2}\]}}{\deqn{\sqrt{a^2}}}
>
>Is there any way to put "tex-chtml-full.js" locally so that everyone 
>that has my package installed see the equations rendered properly even
offline?
>
>Thanks in advance
>
>Olivoto

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


[R-pkg-devel] MathJax for Rd files

2020-05-13 Thread Tiago Olivoto
Dear all,

I'm not sure if this is the correct place to make this question, but here I
am.

I'm trying to use MathJax for html help files in my package metan
(https://cran.r-project.org/package=metan)

I have success with the following approach:

 

Including the following call

 

#'\if{html}{\out{

#'https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full.js";>

#'  

#'}} 

 

And then typing the equations I need. A simple example bellow

 

#' \ifelse{html}{\out{\[\sqrt{a^2}\]}}{\deqn{\sqrt{a^2}}}

 

Is there any way to put "tex-chtml-full.js" locally so that everyone that
has my package installed see the equations rendered properly even offline?

Thanks in advance

Olivoto

 


[[alternative HTML version deleted]]

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


[R-pkg-devel] Error in \donttest{} not observed with --run-donttest option

2020-04-22 Thread Tiago Olivoto
Dear all,

I've submitted the v1.5.0 of my R package metan
 a few days ago to fix some errors
related to a recent upgrade of package 'tibble' to version 3.0.0, with
breaking changes described at
.  When checking locally metan
v1.5.0' with "R CMD check --as-cran --run-donttest metan_1.5.0.tar.gz" no
errors were observed (log file attached).

 

On Monday 13, April, I was notified that "Version 1.5.0 still fails in its
\donttest examples, which should work". Looking to the CRAN Package Check
Results page  I
observed an error that occurred because I used a data set with
non-significant genotype effect to compute an index that requires a
significant genotype effect in all trait. Unfortunately, metan was removed
from CRAN because check problems were not corrected in time.

 

Any idea about why I've not observed any error even using  --run-donttest
option locally?  That function's example had not been changed since the
first release, so, I'm also asking myself why this error was observed only
now, after four successful releases on CRAN.

 

I'd appreciate any comment.

Best regards,

Tiago

 

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


[R-pkg-devel] RES: Error after package update

2020-01-29 Thread Tiago Olivoto
Thanks, Gabor.
The error occurred even when I restarted my section. 
I'm not sure if this was the solution, but I was using a development version of 
'vctrs' (a package that 'tidyselect' depends on)
After installing the stable version of 'vctrs' (v0.2.2) all worked well.
Best regards,
Tiago


> -Mensagem original-
> De: Gábor Csárdi 
> Enviada em: quarta-feira, 29 de janeiro de 2020 10:00
> Para: tiagooliv...@gmail.com
> Cc: R Package Devel 
> Assunto: Re: [R-pkg-devel] Error after package update
> 
> Hi, I don't see this with dplyr 0.8.3 and tidyselect 1.0.0.
> 
> Please make sure that you restart your R session after installing packages,
> otherwise the previous versions might be still loaded.
> One easy way to start a new R process is to use the reprex package to create a
> reproducible example.
> 
> If you still see this problem after restarting R, please open an issue in the
> tidyselect issue tracker:
> https://github.com/r-lib/tidyselect/issues
> 
> Gabor
> 
> On Wed, Jan 29, 2020 at 4:53 AM Tiago Olivoto 
> wrote:
> >
> > Hi everyone,
> >
> > After updating my R package list I just begin to get the following
> > error with dplyr::select()
> >
> > A minimal reproducible example with iris dataset:
> >
> > ---
> >
> > library(dplyr)
> >
> > select(iris, Species)
> >
> >
> >
> > Erro: `...` is not empty.
> >
> >
> >
> > We detected these problematic arguments:
> >
> > * `logical`
> >
> >
> >
> > These dots only exist to allow future extensions and should be empty.
> >
> > Did you misspecify an argument?
> >
> > ---
> >
> >
> >
> > It seems that this error occurs when tidyselect changed from v0.2.5
> > (binary) to v1.0.0 (source)
> >
> > https://cran.r-project.org/web/packages/tidyselect/index.html
> >
> >
> >
> > If I put back 'tidyselect' to v0.2.5 the error doesn't occur.
> >
> > Any idea about why I am getting this error?
> >
> > Best regards,
> >
> >
> >
> > --
> >
> > M.Sc. Tiago Olivoto
> >
> > Ph.D student in Agronomy
> >
> > Department of Plant Science
> >
> > Federal University of Santa Maria
> >
> > 1000 Roraima Ave.
> >
> > Santa Maria, RS 97105-340
> >
> > E-mail:  <mailto:tiagooliv...@gmail.com> tiagooliv...@gmail.com
> >
> >  <https://www.researchgate.net/profile/Tiago_Olivoto2> Research Gate
> >
> >
> > <http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4416862T6
> > >
> > Currículo Lattes
> >
> >
> >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel

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


[R-pkg-devel] Error after package update

2020-01-29 Thread Tiago Olivoto
Hi everyone,

After updating my R package list I just begin to get the following error
with dplyr::select()

A minimal reproducible example with iris dataset:

---

library(dplyr)

select(iris, Species)



Erro: `...` is not empty.



We detected these problematic arguments:

* `logical`



These dots only exist to allow future extensions and should be empty.

Did you misspecify an argument?

---



It seems that this error occurs when tidyselect changed from v0.2.5 (binary)
to v1.0.0 (source)

https://cran.r-project.org/web/packages/tidyselect/index.html



If I put back 'tidyselect' to v0.2.5 the error doesn't occur.

Any idea about why I am getting this error?

Best regards,



--

M.Sc. Tiago Olivoto

Ph.D student in Agronomy

Department of Plant Science

Federal University of Santa Maria

1000 Roraima Ave.

Santa Maria, RS 97105-340

E-mail:  <mailto:tiagooliv...@gmail.com> tiagooliv...@gmail.com

 <https://www.researchgate.net/profile/Tiago_Olivoto2> Research Gate

 <http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4416862T6>
Curr�culo Lattes




[[alternative HTML version deleted]]

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


[R-pkg-devel] RES: RES: Possible unknown color in r

2020-01-10 Thread Tiago Olivoto
Hi Berry, 

Thank you for the note.

When I run my example code with transparent_color() all was working (the
color was transparent).

Now, reproducing the code again it becomes black. Could be this be changed
after package "farver" be updated to v. 2.0.2?

You is right regarding the use of col = NA. I have some functions that uses
ggplot2 and col = NA works with lines

 

library(ggplot2)

ggplot(mpg, aes(displ, hwy)) + 

  geom_smooth(color = NA, method = "lm")

 

but return a warning message with points

ggplot(mpg, aes(displ, hwy)) + 

  geom_point(color = NA)

# Warning message:

# Removed 234 rows containing missing values (geom_point).

 

It seems that the correct "transparent" color I was looking for can be set
without a warning with "#FF00"

ggplot(mpg, aes(displ, hwy)) + 

  geom_point(color = "#FF00")

Thanks for the tips.

Tiago.

 

De: Berry Boessenkool  
Enviada em: sexta-feira, 10 de janeiro de 2020 15:42
Para: 'Joris Meys' ; r-package-devel@r-project.org;
tiagooliv...@gmail.com
Assunto: Re: [R-pkg-devel] RES: Possible unknown color in r

 

 

Side Note: 

plot(1, col="#00FF", cex=4, pch=16)

is black on my machine.

The last two values are alpha (I think) and should be 00 for transparency.

 

Instead of writing an extra function, you could also use col=NA.

 

Berry

 

  _  

From: R-package-devel mailto:r-package-devel-boun...@r-project.org> > on behalf of Tiago Olivoto
mailto:tiagooliv...@gmail.com> >
Sent: Friday, January 10, 2020 18:05
To: 'Joris Meys' mailto:joris.m...@ugent.be> >;
r-package-devel@r-project.org <mailto:r-package-devel@r-project.org>
mailto:r-package-devel@r-project.org> >
Subject: [R-pkg-devel] RES: Possible unknown color in r 

 

Hi Joris,
Thank you for your suggestions.
After installing the version v 2.0.2 of "farver" I was able to reproduce the
WARNING.
To fix this issue, I created a simple helper function:
transparent_color <- function() {
  return("#00FF")
}
And changed "transparent" with "transparent_color()" in my R scripts.
After, I built and check again with 'R CMD check --as-cran
metan_1.2.1.tar.gz' and no longer WARNINGS were observed.
Thanks again,
Tiago

-Mensagem original-
De: Joris Meys mailto:joris.m...@ugent.be> > 
Enviada em: sexta-feira, 10 de janeiro de 2020 10:57
Para: r-package-devel@r-project.org <mailto:r-package-devel@r-project.org> ;
tiagooliv...@gmail.com <mailto:tiagooliv...@gmail.com> 
Assunto: Re: [R-pkg-devel] Possible unknown color in r

Hi Tiago,

It's indeed that. For some reason col2rgb() knows the unofficial
"transparent". Replace this with the correct value from the vector colors(),
i.e. "white". "transparent" is not mentioned in that vector, so it shouldn't
be used in a package. See also ?rgb2col and ?colors.

Cheers
Joris

--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
--

Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php



From: Tiago Olivoto mailto:tiagooliv...@gmail.com>
>
Sent: Friday, January 10, 2020 2:17 PM
To: Joris Meys; r-package-devel@r-project.org
<mailto:r-package-devel@r-project.org> 
Subject: RES: [R-pkg-devel] Possible unknown color in r

Hi Joris,
Thank you so much for your assistance.
I've built and checked my package with:
R CMD build /d/Desktop/metan
R CMD check --as-cran metan_1.2.1.tar.gz

No WARNINGS were observed. Please, see the log file attached.
Sorry for failing in providing the link to access the check results in the
last email. You can see the link to the test that doesn't pass bellow.

Dear maintainer,
 package metan_1.2.1.tar.gz does not pass the incoming checks automatically,
please see the following pre-tests:
Windows:
<https://win-builder.r-project.org/incoming_pretest/metan_1.2.1_20200109_043
<https://win-builder.r-project.org/incoming_pretest/metan_1.2.1_20200109_043
%0b153/Windows/00check.log> 
153/Windows/00check.log>

Status: 1 WARNING, 1 NOTE
Debian:
<https://win-builder.r-project.org/incoming_pretest/metan_1.2.1_20200109_043
<https://win-builder.r-project.org/incoming_pretest/metan_1.2.1_20200109_043
%0b153/Debian/00check.log> 
153/Debian/00check.log>

It sounds strange because in the last submissions the package passed in the
incoming checks, and the only change I've made from v1.2.0 to 1.2.1 was
adding some references in the description file.
Best regards,
Tiago

-Mensagem original-
De: Joris Meys mailto:joris.m...@ugent.be> >
Enviada em: sexta-feira, 10 de janeiro de 2020 09:23
Para: r-package-devel@r-project.org <mailto:r-package-devel@r-project.org> ;
tiagooliv...@gmail.com <mailto:tiagooliv...@gmail.com> 
Assunto: Re: [R-pkg-dev

[R-pkg-devel] RES: Possible unknown color in r

2020-01-10 Thread Tiago Olivoto
Hi Joris,
Thank you so much for your assistance.
I've built and checked my package with:
R CMD build /d/Desktop/metan
R CMD check --as-cran metan_1.2.1.tar.gz

No WARNINGS were observed. Please, see the log file attached.
Sorry for failing in providing the link to access the check results in the
last email. You can see the link to the test that doesn't pass bellow.

Dear maintainer,
 package metan_1.2.1.tar.gz does not pass the incoming checks automatically,
please see the following pre-tests:
Windows:
<https://win-builder.r-project.org/incoming_pretest/metan_1.2.1_20200109_043
153/Windows/00check.log>

Status: 1 WARNING, 1 NOTE
Debian:
<https://win-builder.r-project.org/incoming_pretest/metan_1.2.1_20200109_043
153/Debian/00check.log>

It sounds strange because in the last submissions the package passed in the
incoming checks, and the only change I've made from v1.2.0 to 1.2.1 was
adding some references in the description file.
Best regards,
Tiago

-Mensagem original-
De: Joris Meys  
Enviada em: sexta-feira, 10 de janeiro de 2020 09:23
Para: r-package-devel@r-project.org; tiagooliv...@gmail.com
Assunto: Re: [R-pkg-devel] Possible unknown color in r

Hi Tiago,

Without knowing which package you're talking about or a link to the check
results, it's impossible to know whether that warning is a proper one or a
side effect of something else. 

In general though: it is well known that relying on devtools is not enough
for a good CRAN submission. The guidelines for CRAN clearly state :

"Please ensure that R CMD check --as-cran has been run on the tarball to be
uploaded before submission. This should be done with the current version of
R-devel (or if that is not possible and explained in the submission, current
R-patched or the current release of R.)"

So before submitting a package to CRAN and after running your devtools::
check_etc, open a terminal and run the following commands:

R CMD build path_to_pkg_folder
R CMD check --as-cran package_version.tar.gz

The --as-cran is important, as is doing so against a R-devel. I use devtools
myself extensively, but these checks have to be done outside the RStudio
ecosystem to be sure.

Kind regards
Joris

--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
--

Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php



From: R-package-devel  on behalf of
Tiago Olivoto 
Sent: Friday, January 10, 2020 12:43 PM
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Possible unknown color in r

Dear all,

In the last submission of my package the CRAN team has suggested including
some references in the description field of the DESCRIPTION file.
When I submitted it to CRAN it did not pass the incoming checks
automatically and I got the following WARNING.



Quitting from lines 108-117 (vignettes_metan.Rmd)

Error: processing vignette 'vignettes_metan.Rmd' failed with diagnostics:

Unknown colour name: transparent



It seems that this warning is related to a function with the argument
'col.segm.gen = "transparent"'.

I don't changed anything in this function and in the last submissions no
warning was related.

For curiosity I ran:

> col2rgb("yellow")

  [,1]

red255

green  255

blue 0



> col2rgb("transparent")

  [,1]

red255

green  255

blue   255



No warnings or errors were observed while running devtools::check_rhub(),
devtools::check_win_devel(), and devtools::check_win_release()

Any suggestion?

Best,

Tiago




[[alternative HTML version deleted]]

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


[R-pkg-devel] Possible unknown color in r

2020-01-10 Thread Tiago Olivoto
Dear all,

In the last submission of my package the CRAN team has suggested including
some references in the description field of the DESCRIPTION file.
When I submitted it to CRAN it did not pass the incoming checks
automatically and I got the following WARNING.

 

Quitting from lines 108-117 (vignettes_metan.Rmd) 

Error: processing vignette 'vignettes_metan.Rmd' failed with diagnostics:

Unknown colour name: transparent

 

It seems that this warning is related to a function with the argument
'col.segm.gen = "transparent"'.

I don't changed anything in this function and in the last submissions no
warning was related.

For curiosity I ran:

> col2rgb("yellow")

  [,1]

red255

green  255

blue 0

 

> col2rgb("transparent")

  [,1]

red255

green  255

blue   255

 

No warnings or errors were observed while running devtools::check_rhub(),
devtools::check_win_devel(), and devtools::check_win_release()

Any suggestion?

Best,

Tiago

 


[[alternative HTML version deleted]]

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


[R-pkg-devel] RES: RES: Time for CRAN response

2019-12-15 Thread Tiago Olivoto
Thanks, Duncan and Uwe, for the answers!
I'll resubmit it as soon as possible.
Best regards,
Tiago Olivoto

--
M.Sc. Tiago Olivoto
Doutorando em Agronomia
Departamento de Fitotecnia
Universidade Federal de Santa Maria
Av. Roraima, 1000, Camobi
Santa Maria, RS, 97105-340
E-mail: tiagooliv...@gmail.com
Cel: +55 54 999187863
Research Gate
Currículo Lattes

-Mensagem original-
De: Uwe Ligges  
Enviada em: domingo, 15 de dezembro de 2019 22:27
Para: Duncan Murdoch ; tiagooliv...@gmail.com; 
r-package-devel@r-project.org
Assunto: Re: [R-pkg-devel] RES: Time for CRAN response



On 15.12.2019 23:39, Duncan Murdoch wrote:
> On 15/12/2019 4:57 p.m., Tiago Olivoto wrote:
>> Thank you for the response.
>> As far I remember, I've responded that message by following the link 
>> and selecting "I have read the CRAN policies and would like to submit 
>> this package to CRAN" and " I have checked the submission using R CMD 
>> check --as-cran and a current version of r-devel, as mandated by the 
>> CRAN Repository Policy. (You could do so using the win-builder 
>> service at https://win-builder.r-project.org)", and then clicking on 
>> "upload package to CRAN"
>> These same steps were followed in the first submission, but at that 
>> time I received the following message that was not received in the 
>> last submission.
>>
>>> Dear maintainer,
>>>
>>> package metan_1.0.0.tar.gz has been auto-processed and is pending a 
>>> manual inspection of this new CRAN submission. A CRAN team member 
>>> will typically respond to you within the next 10 working days.
>>
>> Should I try to re-submit it again?
> 
> Probably.  I'd wait 24 hours, to see if someone from CRAN replies with 
> more information.
> 


Thanks, Duncan, here we got:

1. I did not spot a request for help from Nov 25 in the many messsages we 
receive. That one has now been answered.
2. I do not see a submission fom Nov 25. Can you simply resubmit and make sure 
you click on the confirmation link?

Best,
Uwe Ligges



> Duncan Murdoch
> 
>> Best,
>> Tiago Olivoto
>>
>>
>> -Mensagem original-
>> De: Duncan Murdoch  Enviada em: domingo, 15 
>> de dezembro de 2019 17:35
>> Para: tiagooliv...@gmail.com; r-package-devel@r-project.org
>> Assunto: Re: [R-pkg-devel] Time for CRAN response
>>
>> On 15/12/2019 1:29 p.m., Tiago Olivoto wrote:
>>> Dear all,
>>>
>>> I've submitted my package 'metan' to CRAN for the first time a few 
>>> weeks ago and received some suggestions to improve the code. After 
>>> fixing some bugs, I've resubmitted it on November 25, but I still 
>>> don't have any response and the package was not found in incoming/ 
>>> dir on CRAN cran ftp site. Since it is my first experience, I would 
>>> like to have an idea about how long the CRAN team usually decides 
>>> about a package submission.
>>>
>>
>> If it is not in incoming/, something went wrong.  The most common 
>> thing to go wrong is that the maintainer didn't respond to the 
>> confirmation message. That message looks like this for a 
>> resubmission.  I assume first time submissions have a similar message:
>>
>>> Dear Duncan Murdoch
>>> Someone has submitted the package rgl to CRAN.
>>> You are receiving this email to confirm the submission as the 
>>> maintainer of this package.
>>> To confirm the submission to CRAN, follow or copy & paste the 
>>> following link into your browser:
>>> ...
>>
>>
>> When you confirm submission, you'll get another message that looks 
>> like
>> this:
>>
>>> [This was generated from CRAN.R-project.org/submit.html]
>>>
>>> The following package was uploaded to CRAN:
>>> ===
>>>
>>> Package Information:
>>> Package: rgl
>>> Version: 0.100.26
>>   > ...
>>
>> After that, it goes into a queue for checking, and usually within a 
>> few days you'll be told about problems with it or it will be accepted 
>> to CRAN.  (Sometimes you'll be told very quickly, if the automated 
>> checks find a problem.)
>>
>> Duncan Murdoch
>>
> 
> __
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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


[R-pkg-devel] RES: Time for CRAN response

2019-12-15 Thread Tiago Olivoto
Thank you for the response.
As far I remember, I've responded that message by following the link and 
selecting "I have read the CRAN policies and would like to submit this package 
to CRAN" and " I have checked the submission using R CMD check --as-cran and a 
current version of r-devel, as mandated by the CRAN Repository Policy. (You 
could do so using the win-builder service at 
https://win-builder.r-project.org)", and then clicking on "upload package to 
CRAN"
These same steps were followed in the first submission, but at that time I 
received the following message that was not received in the last submission.

> Dear maintainer,
> 
> package metan_1.0.0.tar.gz has been auto-processed and is pending a manual 
> inspection of this new CRAN submission. A CRAN team member will typically 
> respond to you within the next 10 working days.

Should I try to re-submit it again?
Best,
Tiago Olivoto


-Mensagem original-
De: Duncan Murdoch  
Enviada em: domingo, 15 de dezembro de 2019 17:35
Para: tiagooliv...@gmail.com; r-package-devel@r-project.org
Assunto: Re: [R-pkg-devel] Time for CRAN response

On 15/12/2019 1:29 p.m., Tiago Olivoto wrote:
> Dear all,
> 
> I've submitted my package 'metan' to CRAN for the first time a few 
> weeks ago and received some suggestions to improve the code. After 
> fixing some bugs, I've resubmitted it on November 25, but I still 
> don't have any response and the package was not found in incoming/ dir 
> on CRAN cran ftp site. Since it is my first experience, I would like 
> to have an idea about how long the CRAN team usually decides about a package 
> submission.
> 

If it is not in incoming/, something went wrong.  The most common thing to go 
wrong is that the maintainer didn't respond to the confirmation message. That 
message looks like this for a resubmission.  I assume first time submissions 
have a similar message:

> Dear Duncan Murdoch
> Someone has submitted the package rgl to CRAN.
> You are receiving this email to confirm the submission as the 
> maintainer of this package.
> To confirm the submission to CRAN, follow or copy & paste the 
> following link into your browser:
> ...


When you confirm submission, you'll get another message that looks like
this:

> [This was generated from CRAN.R-project.org/submit.html]
> 
> The following package was uploaded to CRAN:
> ===
> 
> Package Information:
> Package: rgl
> Version: 0.100.26
 > ...

After that, it goes into a queue for checking, and usually within a few days 
you'll be told about problems with it or it will be accepted to CRAN.  
(Sometimes you'll be told very quickly, if the automated checks find a problem.)

Duncan Murdoch

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


[R-pkg-devel] Time for CRAN response

2019-12-15 Thread Tiago Olivoto
Dear all,

I've submitted my package 'metan' to CRAN for the first time a few weeks ago
and received some suggestions to improve the code. After fixing some bugs,
I've resubmitted it on November 25, but I still don't have any response and
the package was not found in incoming/ dir on CRAN cran ftp site. Since it
is my first experience, I would like to have an idea about how long the CRAN
team usually decides about a package submission.

Best,

Tiago Olivoto


[[alternative HTML version deleted]]

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


[R-pkg-devel] Fwd: Passing CRAN check when an examples must save a file

2019-09-27 Thread Tiago Olivoto
Dear all,
I had the same problem when I submitted my R package 'metan' to CRAN for
the first time.

"Please ensure that your functions do not write by default or in your
examples/vignettes/tests in the user's home filespace (including the
package directory and getwd()). In your examples/vignettes/tests you can
write to tempdir()"

I have several 'summary()' functions like:








*summary.waasb <- function(object, export = FALSE, file.name
<http://file.name> = "summary_waasb", ...) {  # do all I need here  if
(export == TRUE) {sink(paste0(file.name <http://file.name>, ".txt"))
# do all I need heresink()  }}*

All 'export' arguments are set to 'FALSE'. So, no file is generated in the
user's working directory.
Is the above function not according to the CRAN policies?

In two vignettes I have a code like:



*```{r, eval=FALSE }summary(stat_ge, export = TRUE)```*

Please, note that 'eval = FALSE'. Could this be the problem?
The suggestion is to write to a tempdir() but even looking at the Duncan
Murdoch's answer I cannot see how to do that in my case.
Looking for any suggestion.
Best regards,
Tiago Olivoto









-- Forwarded message -
De: Duncan Murdoch 
Date: sex, 27 de set de 2019 às 09:44
Subject: Re: [R-pkg-devel] Passing CRAN check when an examples must save a
file
To: Zachary Flynn , 


On 26/09/2019 11:43 p.m., Zachary Flynn wrote:
> I am working on a function in a package that saves a file.  I want to
write
> an example to document the function so it must save a file, but when I do,
> the automatic CRAN checks reject the package because there is a
> non-standard file saved in the directory when the second test runs (first,
> it runs a test on Windows where the check error does not occur, then on
> Linux where it does).  The relevant check output is:
>
> * checking for non-standard things in the check directory ... NOTE
> Found the following files/directories:
>‘Produc.csv’
>
> There is no file called Produc.csv anywhere in the directory (the
> error doesn't show up in the first run on Windows).
>
> It is generated by running the example code which automatic CRAN
> testing might be doing in between running the Windows and Linux
> checks?
>
> How do I write an example that must save a file to be an example of
> using the function without triggering this issue?

Save the file to the temporary directory, ẹ.g.

   filename <- file.path(tempdir(), "Prodục.csv")
   write.csv(something, file = filename)

You could clean up at the end of the example with

   unlink(filename)

but you shouldn't rely on this alone to prevent the error:  if you're
writing files, you should *only* be doing it in the temporary directory.

Duncan Murdoch

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

[[alternative HTML version deleted]]

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