Re: [R-pkg-devel] documentation of generic '['
Hi Stefano,
did you try moving the method to a separate file already? I've noticed that
documentation of classes and methods in the same .Rd file isn't very
straightforward. You need a \usage{} section to document the method, and
that's likely to cause trouble when used in a class document.
In any case, afaik you need a :
\S4method{generic}{signature_list}(argument_list)
in the usage section, and you have to refer to the method as
\alias{[, encore,ANY,ANY-method}
See
https://cran.r-project.org/doc/manuals/R-exts.html#Documenting-S4-classes-and-methods
Cheers
Joris
On Wed, Mar 9, 2016 at 1:10 PM, Berri, Stefano wrote:
> Hi.
>
> I am having problems with R CMD check around documentation of method "[".
> I am pretty sure I didn't have this WARNING when I used R-3.0.2. I have
> tried many things, but I am not sure how to fix it.
>
>
> $ R CMD check encore
> ...
> * using R version 3.2.3 (2015-12-10)
> ...
> * checking for missing documentation entries ... WARNING
> Undocumented S4 methods:
> generic '[' and siglist 'encore,ANY,ANY'
> All user-level objects in a package (including S4 classes and methods)
> should have documentation entries.
> See chapter 'Writing R documentation files' in the 'Writing R
> Extensions' manual.
> ...
>
> Everything else is OK, there is an unrelated NOTE we are addressing
>
> # R CODE ##
>
> setMethod("[", "encore", function(x,i,j,drop){
> ... code here ...
> })
>
> # DOCUMENTATION #
>
> \name{encore-class}
> \Rdversion{0.1}
> \docType{class}
> \alias{encore}
> \alias{subtraction-class}
> \alias{encore-class}
> \alias{dConn-class}
>
> \alias{[,encore-method}
>
> ... description of the class, no explicit description of method "[" though
>
> ##
>
> I have tried various things searching around, but I seem to introduce new
> WARNINGS without removing the one I have.
>
> I have read the "Writing R documentation files", but there is no special
> description of method "[", and I am struggling to understand what's wrong.
>
> Thank you very much in advance
>
> Stefano
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Creating Accessor Methods
Hi Glenn,
that is actually as easy as defining a generic and defining a method for
each class to extract the slot. I do this literally in every package I
write.
setGeneric('duration', function(x, ...) standardGeneric('duration')
setMethod('duration', signature = 'MBSCashFlow', function(x) { x@Duration})
setMethod('duration', signature = 'REMICCashFlow', function(x) {x@Duration})
etc...
I suggest you take a close look at Hadley Wickham's books 'Advanced R' and
'R packages', both freely available online.
This is the relevant section of the first book :
http://adv-r.had.co.nz/OO-essentials.html
This is the other book : http://r-pkgs.had.co.nz/
Cheers
Joris
On Thu, Mar 10, 2016 at 3:05 PM, Glenn Schultz wrote:
> All,
>
> I have a package with to S4 classes (MBSCashFlow, REMICCashFlow and
> BondCashFlow) all of which contain the slot Duration. I would like have an
> accessor Duration that would work on multiple signatures. Is this
> possible? I have checked my books, help, BioConductor tutorials and it
> appears that this is not possible. Has anyone ever run into this situation?
>
> Best Glenn
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Changing a package's name
I'll chime in from the other side of the ocean: I didn't even know that the Huxtables was their family name, and I've watched the Cosby show often as a kid. I did a quick check in the office and of the 12 R users I asked, exactly 0 knew who the Huxtables were. So I wouldn't worry too much about it. Cheers Joris On Mon, Jun 12, 2017 at 3:58 PM, Dason Kurkiewicz wrote: > Hi David, > > Honestly I'm from the US and know about the scandal with Cosby but > don't think that it would be an issue for your package. First off > it's the name of the fictional family - not Bill Cosby's name > directly. There are more members of the family than just what Bill > portrayed. If you show me anybody that sees your package name and > says something like "well I guess that author is for sexual assault" > then I doubt they're really thinking at a capacity to do any sort of > real work anyways. There are other "Huxtable"s that exist by the way: > https://en.wikipedia.org/wiki/Ada_Louise_Huxtable is a prime example > that comes to mind for me. A quote from Carter Wiseman: "Huxtable's > insistence on intellectual rigor and high design standards made her > the conscience of the national architectural community". That doesn't > seem like a bad person to have an association with if you ask me. > > Changing the package's name seems to be much too high of a cost (if > even possible) to shake the extremely loose association one might see > the package having with Bill Cosby. It's not like you called your > package "ISIS". I would highly recommend just not worrying about it. > > -Dason Kurkiewicz > > On Sun, Jun 11, 2017 at 7:46 PM, Fox, John wrote: > > Dear David, > > > > No one at CRAN has responded yet, so I'll take a stab at it. > > > > First, you're right about the resonance of "huxtable" for North > Americans, and if the package were mine, I'd be slightly embarrassed about > the name. > > > > CRAN generally will not allow you to rename a package, for several > obvious reasons: For example, packages that depend on yours would break > (but there don't appear to be any yet), users might be confused, and there > would be a discontinuity in archived versions of the package. See < > https://stat.ethz.ch/pipermail/r-devel/2013-August/067264.html> for a > comment by one of the CRAN maintainers about renaming packages. > > > > You could, however, ask the CRAN maintainers for a dispensation, > explaining the reason for the desired change. > > > > Best, > > John > > > > - > > John Fox, Professor > > McMaster University > > Hamilton, Ontario > > Canada L8S 4M4 > > web: socserv.mcmaster.ca/jfox > > > > > > > > From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf > of David Hugh-Jones [davidhughjo...@gmail.com] > > Sent: June 11, 2017 9:51 AM > > To: R package devel > > Subject: [R-pkg-devel] Changing a package's name > > > > Hello all, > > > > A short while ago I released the "huxtable" package for writing HTML and > > LaTeX tables: > > https://www.github.com/hughjonesd/huxtable > > > > The name seemed cute to me, but I later found out that to Americans it > has > > special associations. The Huxtables were the family in the Cosby show. > That > > would be fine, except that Bill Cosby is now on trial for one case of > rape, > > and there are accusations of many other cases. > > > > So, two questions: > > > > * Do you think I should change the name? > > > > Comments welcome from Americans and others on this difficult cultural > issue. > > > > * If I do, what's the best and least disruptive way to do it? Bear in > mind > > that I have a couple of thousand users. > > > > My first thought would be to release an update which gives a warning > about > > the future change when the package is loaded; then release a package with > > the new name and continue development on this branch. > > > > David > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Exporting S3 methods for base generics
Hi Charles,
if a generic exists already in the base, you only have to export the actual
S3 method. Your problem is that base::pmax() is not a generic S3 function.
So R gives you the correct warning: the S3 generic in your package will
always mask the base pmax function. And that's not really a problem,
especially since you ensured the base functionality with your default
method.
If you want to avoid that warning, use S4.
#' @rdname
setGeneric("pmax")
#' @rdname pmax
#' @method pmax myclass
#' @export
setMethod("pmax",
"myclass",
function(...){
# do some stuff
})
More information on how to deal with dots can be found on the help page
?dotsMethods.
If you have a generic in the base package (eg plot is such one), you only
define the method and use:
#' @export
plot.myclass <- function(x, y, ...){
# do some more stuff
}
Cheers
Joris
On Mon, Jun 26, 2017 at 6:28 PM, Charles Determan
wrote:
> Greetings R users,
>
> I was wondering how others are exporting S3 methods in their packages when
> the generic is in 'base'. For example, let's say I want to export a new
> pmax method. The only way I have found to get this to work is by
> redefining the function with 'UseMethod' and setting the default method.
>
> #' @export
> pmax <- function(...){ UseMethod("pmax") }
> #' @export
> pmax.default <- function(..., na.rm=FALSE){ base::pmax(..., na.rm=FALSE) }
>
> setClass("myclass")
>
> #' @export
> pmax.myclass <- function(..., na.rm = FALSE){
> print('myclass pmax!')
> }
>
> Although this works, I get the 'warning'
>
> The following objects are masked from 'package:base':
>
> pmax
>
>
> I would like the package build and loading to be as clean as possible but
> if this is acceptable and not considered a problem I will let it go. It
> just seems odd that one would to redefine a the generic when in states in
> the docs for 'pmax' that it will also work on classed S3 objects but
> perhaps I am reading this incorrectly.
>
> Thanks,
> Charles
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Exporting S3 methods for base generics
Hi Charles,
my mistake. I forgot that pmax has an extra argument na.rm. I'm surprised
you could define the method, as this normally should return an error from
conformMethod().
So:
#' @rdname pmax
setGeneric("pmax", signature = "...")
should work. I've used this myself in quite a number of packages.
Cheers
Joris
On Mon, Jun 26, 2017 at 7:20 PM, Charles Determan
wrote:
> Thanks for the reply Joris, although I am not sure what I could be doing
> wrong. I implement exactly the lines you show and yet I just get the
> following error when I call 'pmax' on the class.
>
> > pmax(x, 0)
>
> Error in mmm < each :
> comparison (3) is possible only for atomic and list types
> In addition: Warning message:
> In is.na(mmm) : is.na() applied to non-(list or vector) of type 'S4'
>
> Regards,
> Charles
>
> On Mon, Jun 26, 2017 at 12:10 PM, Joris Meys wrote:
>
>> Hi Charles,
>>
>> if a generic exists already in the base, you only have to export the
>> actual S3 method. Your problem is that base::pmax() is not a generic S3
>> function. So R gives you the correct warning: the S3 generic in your
>> package will always mask the base pmax function. And that's not really a
>> problem, especially since you ensured the base functionality with your
>> default method.
>>
>> If you want to avoid that warning, use S4.
>>
>> #' @rdname
>> setGeneric("pmax")
>>
>> #' @rdname pmax
>> #' @method pmax myclass
>> #' @export
>> setMethod("pmax",
>> "myclass",
>> function(...){
>> # do some stuff
>> })
>>
>> More information on how to deal with dots can be found on the help page
>> ?dotsMethods.
>>
>> If you have a generic in the base package (eg plot is such one), you only
>> define the method and use:
>>
>> #' @export
>> plot.myclass <- function(x, y, ...){
>># do some more stuff
>> }
>>
>> Cheers
>> Joris
>>
>>
>>
>> On Mon, Jun 26, 2017 at 6:28 PM, Charles Determan
>> wrote:
>>
>>> Greetings R users,
>>>
>>> I was wondering how others are exporting S3 methods in their packages
>>> when
>>> the generic is in 'base'. For example, let's say I want to export a new
>>> pmax method. The only way I have found to get this to work is by
>>> redefining the function with 'UseMethod' and setting the default method.
>>>
>>> #' @export
>>> pmax <- function(...){ UseMethod("pmax") }
>>> #' @export
>>> pmax.default <- function(..., na.rm=FALSE){ base::pmax(..., na.rm=FALSE)
>>> }
>>>
>>> setClass("myclass")
>>>
>>> #' @export
>>> pmax.myclass <- function(..., na.rm = FALSE){
>>> print('myclass pmax!')
>>> }
>>>
>>> Although this works, I get the 'warning'
>>>
>>> The following objects are masked from 'package:base':
>>>
>>> pmax
>>>
>>>
>>> I would like the package build and loading to be as clean as possible but
>>> if this is acceptable and not considered a problem I will let it go. It
>>> just seems odd that one would to redefine a the generic when in states in
>>> the docs for 'pmax' that it will also work on classed S3 objects but
>>> perhaps I am reading this incorrectly.
>>>
>>> Thanks,
>>> Charles
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>>
>>
>> --
>> Joris Meys
>> Statistical consultant
>>
>> Ghent University
>> Faculty of Bioscience Engineering
>> Department of Mathematical Modelling, Statistics and Bio-Informatics
>>
>> tel : +32 9 264 59 87 <+32%209%20264%2059%2087>
>> joris.m...@ugent.be
>> ---
>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>
>
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Exporting S3 methods for base generics
Hi Charles,
that particular construct (with the dots) I only have in proprietary
packages, so I can't share the code for those. If you have the package on a
repo on github, you can give me a link and a pointer as to what file you're
working on, and I can take a look.
You also find some nice examples on the help page of ?dotsMethods
Cheers
Joris
On Mon, Jun 26, 2017 at 7:42 PM, Charles Determan
wrote:
> Could you point to one of these packages you refer to? I'm still having
> problems and not sure why at the moment.
>
> Thanks
>
> On Mon, Jun 26, 2017 at 12:32 PM, Joris Meys wrote:
>
>> Hi Charles,
>>
>> my mistake. I forgot that pmax has an extra argument na.rm. I'm surprised
>> you could define the method, as this normally should return an error from
>> conformMethod().
>>
>> So:
>> #' @rdname pmax
>> setGeneric("pmax", signature = "...")
>>
>> should work. I've used this myself in quite a number of packages.
>>
>> Cheers
>> Joris
>>
>> On Mon, Jun 26, 2017 at 7:20 PM, Charles Determan
>> wrote:
>>
>>> Thanks for the reply Joris, although I am not sure what I could be doing
>>> wrong. I implement exactly the lines you show and yet I just get the
>>> following error when I call 'pmax' on the class.
>>>
>>> > pmax(x, 0)
>>>
>>> Error in mmm < each :
>>> comparison (3) is possible only for atomic and list types
>>> In addition: Warning message:
>>> In is.na(mmm) : is.na() applied to non-(list or vector) of type 'S4'
>>>
>>> Regards,
>>> Charles
>>>
>>> On Mon, Jun 26, 2017 at 12:10 PM, Joris Meys
>>> wrote:
>>>
>>>> Hi Charles,
>>>>
>>>> if a generic exists already in the base, you only have to export the
>>>> actual S3 method. Your problem is that base::pmax() is not a generic S3
>>>> function. So R gives you the correct warning: the S3 generic in your
>>>> package will always mask the base pmax function. And that's not really a
>>>> problem, especially since you ensured the base functionality with your
>>>> default method.
>>>>
>>>> If you want to avoid that warning, use S4.
>>>>
>>>> #' @rdname
>>>> setGeneric("pmax")
>>>>
>>>> #' @rdname pmax
>>>> #' @method pmax myclass
>>>> #' @export
>>>> setMethod("pmax",
>>>> "myclass",
>>>> function(...){
>>>> # do some stuff
>>>> })
>>>>
>>>> More information on how to deal with dots can be found on the help page
>>>> ?dotsMethods.
>>>>
>>>> If you have a generic in the base package (eg plot is such one), you
>>>> only define the method and use:
>>>>
>>>> #' @export
>>>> plot.myclass <- function(x, y, ...){
>>>># do some more stuff
>>>> }
>>>>
>>>> Cheers
>>>> Joris
>>>>
>>>>
>>>>
>>>> On Mon, Jun 26, 2017 at 6:28 PM, Charles Determan <
>>>> cdeterma...@gmail.com> wrote:
>>>>
>>>>> Greetings R users,
>>>>>
>>>>> I was wondering how others are exporting S3 methods in their packages
>>>>> when
>>>>> the generic is in 'base'. For example, let's say I want to export a
>>>>> new
>>>>> pmax method. The only way I have found to get this to work is by
>>>>> redefining the function with 'UseMethod' and setting the default
>>>>> method.
>>>>>
>>>>> #' @export
>>>>> pmax <- function(...){ UseMethod("pmax") }
>>>>> #' @export
>>>>> pmax.default <- function(..., na.rm=FALSE){ base::pmax(...,
>>>>> na.rm=FALSE) }
>>>>>
>>>>> setClass("myclass")
>>>>>
>>>>> #' @export
>>>>> pmax.myclass <- function(..., na.rm = FALSE){
>>>>> print('myclass pmax!')
>>>>> }
>>>>>
>>>>> Although this works, I get the 'warning'
>>>>>
>>>>> The following objects are masked from 'package:base':
>>>>>
>>>&
Re: [R-pkg-devel] Exporting S3 methods for base generics
Ah, good point :-) You can avoid that by using inheritance, but now you're
on a route to refactoring your entire package actually. See also this
question on stackoverflow for a nice example of how this can be done:
https://stackoverflow.com/questions/26963900/generalizing-three-dots-argument-dispatch-s4-methods-for-argument-set-i
If neither class can inherit from the other in a logical way, you could
define a virtual "superclass" they both inherit from, and define the pmax
method for that virtual class. In R you do this using setClassUnion(), see
also ?setClassUnion and the section on virtual classes in ?setClass.
Hope this helps
Cheers
Joris
On Mon, Jun 26, 2017 at 7:56 PM, Charles Determan
wrote:
> Ah, I see now. I came across this previous post (
> http://r.789695.n4.nabble.com/override-pmin-pmax-for-my-
> own-matrix-td4715903.html) which mentioned the caveat that all the
> elements passed to ... must be the same. When I pass two of the same class
> it works but I believe I will need to go back to the S3 if I want different
> classes passed to the call.
>
> Charles
>
> On Mon, Jun 26, 2017 at 12:42 PM, Charles Determan
> wrote:
>
>> Could you point to one of these packages you refer to? I'm still having
>> problems and not sure why at the moment.
>>
>> Thanks
>>
>> On Mon, Jun 26, 2017 at 12:32 PM, Joris Meys wrote:
>>
>>> Hi Charles,
>>>
>>> my mistake. I forgot that pmax has an extra argument na.rm. I'm
>>> surprised you could define the method, as this normally should return an
>>> error from conformMethod().
>>>
>>> So:
>>> #' @rdname pmax
>>> setGeneric("pmax", signature = "...")
>>>
>>> should work. I've used this myself in quite a number of packages.
>>>
>>> Cheers
>>> Joris
>>>
>>> On Mon, Jun 26, 2017 at 7:20 PM, Charles Determan >> > wrote:
>>>
>>>> Thanks for the reply Joris, although I am not sure what I could be
>>>> doing wrong. I implement exactly the lines you show and yet I just get the
>>>> following error when I call 'pmax' on the class.
>>>>
>>>> > pmax(x, 0)
>>>>
>>>> Error in mmm < each :
>>>> comparison (3) is possible only for atomic and list types
>>>> In addition: Warning message:
>>>> In is.na(mmm) : is.na() applied to non-(list or vector) of type 'S4'
>>>>
>>>> Regards,
>>>> Charles
>>>>
>>>> On Mon, Jun 26, 2017 at 12:10 PM, Joris Meys
>>>> wrote:
>>>>
>>>>> Hi Charles,
>>>>>
>>>>> if a generic exists already in the base, you only have to export the
>>>>> actual S3 method. Your problem is that base::pmax() is not a generic S3
>>>>> function. So R gives you the correct warning: the S3 generic in your
>>>>> package will always mask the base pmax function. And that's not really a
>>>>> problem, especially since you ensured the base functionality with your
>>>>> default method.
>>>>>
>>>>> If you want to avoid that warning, use S4.
>>>>>
>>>>> #' @rdname
>>>>> setGeneric("pmax")
>>>>>
>>>>> #' @rdname pmax
>>>>> #' @method pmax myclass
>>>>> #' @export
>>>>> setMethod("pmax",
>>>>> "myclass",
>>>>> function(...){
>>>>> # do some stuff
>>>>> })
>>>>>
>>>>> More information on how to deal with dots can be found on the help
>>>>> page ?dotsMethods.
>>>>>
>>>>> If you have a generic in the base package (eg plot is such one), you
>>>>> only define the method and use:
>>>>>
>>>>> #' @export
>>>>> plot.myclass <- function(x, y, ...){
>>>>># do some more stuff
>>>>> }
>>>>>
>>>>> Cheers
>>>>> Joris
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 26, 2017 at 6:28 PM, Charles Determan <
>>>>> cdeterma...@gmail.com> wrote:
>>>>>
>>>>>> Greetings R users,
>>>>>>
>>>>>> I was wondering how others are exporting S3 methods in their packages
>>>>>> when
>&
[R-pkg-devel] Using non-exported functions from another package with :::
Hi all, I'm working on a very small package where I redesign the inputs of Shiny to have the label inline instead of above the actual widget. To avoid having to rewrite quite big parts of Shiny, I need access to a number of internal functions. I do this using :::, but R CMD check obviously gives a note, indicating that this is "a bad idea". I understand why this is in most cases a bad idea, but I see no other option apart from literally copying these functions (and the ones they depend on) all into my package. Hence my questions: - is it acceptable to get a package using ::: on CRAN? When I run R CMD check --as-cran it only gives a note, but just to be sure... - anybody a better option to be able to use eg shiny:::selectizeIt, shiny:::selectOptions etc? Thank you in advance Joris -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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 non-exported functions from another package with :::
Hi Duncan, I hoped against all odds to get a different answer, but alas you confirm my biggest fears. I'll get in touch with the shiny guys and hope they'll grant me my wishes. Cheers Joris On Thu, Jul 6, 2017 at 12:03 AM, Duncan Murdoch wrote: > On 05/07/2017 3:19 PM, Joris Meys wrote: > >> Hi all, >> >> I'm working on a very small package where I redesign the inputs of Shiny >> to >> have the label inline instead of above the actual widget. To avoid having >> to rewrite quite big parts of Shiny, I need access to a number of internal >> functions. I do this using :::, but R CMD check obviously gives a note, >> indicating that this is "a bad idea". >> >> I understand why this is in most cases a bad idea, but I see no other >> option apart from literally copying these functions (and the ones they >> depend on) all into my package. >> >> Hence my questions: >> >> - is it acceptable to get a package using ::: on CRAN? When I run R CMD >> check --as-cran it only gives a note, but just to be sure... >> > > No. > > >> - anybody a better option to be able to use eg shiny:::selectizeIt, >> shiny:::selectOptions etc? >> > > Talk to the maintainer of shiny, and ask them to export those functions > (or equivalent ones). This might be more successful if you write the help > pages and send them a Github pull request explaining your need, since that > makes it essentially no immediate work (just long term support work). > > Duncan Murdoch > > > >> Thank you in advance >> Joris >> >> > -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] tibbles are not data frames
Here's one difference: atib <- tibble(a = 1:5, b = letters[5:1]) atib[3,"a"] as.data.frame(atib)[3,"a"] The second line returns a tibble (no dropping dimensions), the third line does (dropping dimensions). Huge difference if you use [ , aColumn] to select a vector from a data frame. Cheers Joris On Tue, Sep 26, 2017 at 10:57 AM, Stefan McKinnon Høj-Edwards wrote: > Hi Göran, > > Could you please elaborate on which kind of subsetting that Hadley > dislikes? > I am yet to encounter operations on data frames that are not possible on > tribbles. > > Kindly, > Stefan McKinnon Hoj-Edwards > > Stefan McKinnon Høj-Edwards > ph.d. Genetics > +44 (0)776 231 2464 > +45 2888 6598 > Skype: stefan_edwards > > 2017-09-26 8:30 GMT+01:00 Göran Broström : > > > I am beginning to get complaints from users of my CRAN packages > > (especially 'eha') to the effect that they get error messages like > "Error: > > Unsupported use of matrix or array for column indexing". > > > > It turns out that they are sticking in tibbles into functions that expect > > data frames as input. And I am using the kind of subsetting that Hadley > > dislikes (eha is an old package, much older than tibbles). It is of > course > > a simple matter to change the code so it handles both data frames and > > tibbles correctly, but this affects many functions, and it will take some > > time. And when the next guy introduces 'troubles' as an improvement of > > 'tibbles', I will have to rewrite the code again. > > > > While I like Hadley's way of doing it, I think it is a mistake to let a > > tibble also be of class data frame. To me it is a matter of inheritance > and > > backwards compability: A tibble should add nice things to a data frame, > not > > change basic behaviour, in order to call itself a data frame. > > > > Is it correct to let a tibble be of class "data.frame"? > > > > Göran Broström > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] tibbles are not data frames
I don't like the dropping of dimensions either. That doesn't change the fact that a tibble reacts different from a data.frame. So tibbles do not inherit correctly from the class data.frame, and it can thus be argued that it's against OOP paradigms to pretend tibbles inherit from the class data.frame. Defensive coding techniques would check if it's a tibble and return an error saying a data.frame is expected. Unless tibbles inherit correctly from data.frame. I have nothing against tibbles. But calling them "data.frame" raises expectations that can't be fulfilled. On Tue, Sep 26, 2017 at 11:23 AM, Stefan McKinnon Høj-Edwards wrote: > Thanks for the examples. Personally, I have been struck out multiple times > by data frames dropping dimensions, so I have a distaste for this dropping > behaviour. > > Personally, I prefer data frame *not* to drop dimensions. They are not > arrays, where slicing drops a dimension makes sense because all entries are > same data type. > You can pull out a column in vector form from both tribbles and data frame > with the $ index; subsetting a row from a data frame and forcing it into an > atomic vector will require cast all columns to lowest common denominator, > often character. > > So I would argue that yes, tribbles are data.frame with extra bells and > whistles, even if I do not understand the use of list columns. > > I suggest a defensive coding technique; if you need a data frame subset to > really be a vector, cast it as a vector. Users *will* attempt to throw > unexpected structures at your methods. When your methods fails in > mysterious ways because it didn't extract a vector, users will be > stupefied. Fail at `as.vector` will indicate why. > > Kindly, > Stefan > > Stefan McKinnon Høj-Edwards > ph.d. Genetics > +44 (0)776 231 2464 <+44%207762%20312464> > +45 2888 6598 <+45%2028%2088%2065%2098> > Skype: stefan_edwards > > 2017-09-26 10:05 GMT+01:00 Joris Meys : > >> Here's one difference: >> >> atib <- tibble(a = 1:5, b = letters[5:1]) >> atib[3,"a"] >> as.data.frame(atib)[3,"a"] >> >> The second line returns a tibble (no dropping dimensions), the third line >> does (dropping dimensions). Huge difference if you use [ , aColumn] to >> select a vector from a data frame. >> >> Cheers >> Joris >> >> On Tue, Sep 26, 2017 at 10:57 AM, Stefan McKinnon Høj-Edwards < >> s...@iysik.com> wrote: >> >>> Hi Göran, >>> >>> Could you please elaborate on which kind of subsetting that Hadley >>> dislikes? >>> I am yet to encounter operations on data frames that are not possible on >>> tribbles. >>> >>> Kindly, >>> Stefan McKinnon Hoj-Edwards >>> >>> Stefan McKinnon Høj-Edwards >>> ph.d. Genetics >>> +44 (0)776 231 2464 >>> +45 2888 6598 >>> Skype: stefan_edwards >>> >>> 2017-09-26 8:30 GMT+01:00 Göran Broström : >>> >>> > I am beginning to get complaints from users of my CRAN packages >>> > (especially 'eha') to the effect that they get error messages like >>> "Error: >>> > Unsupported use of matrix or array for column indexing". >>> > >>> > It turns out that they are sticking in tibbles into functions that >>> expect >>> > data frames as input. And I am using the kind of subsetting that Hadley >>> > dislikes (eha is an old package, much older than tibbles). It is of >>> course >>> > a simple matter to change the code so it handles both data frames and >>> > tibbles correctly, but this affects many functions, and it will take >>> some >>> > time. And when the next guy introduces 'troubles' as an improvement of >>> > 'tibbles', I will have to rewrite the code again. >>> > >>> > While I like Hadley's way of doing it, I think it is a mistake to let a >>> > tibble also be of class data frame. To me it is a matter of >>> inheritance and >>> > backwards compability: A tibble should add nice things to a data >>> frame, not >>> > change basic behaviour, in order to call itself a data frame. >>> > >>> > Is it correct to let a tibble be of class "data.frame"? >>> > >>> > Göran Broström >>> > >>> > __ >>> > R-package-devel@r-project.org mailing list >>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel &
Re: [R-pkg-devel] tibbles are not data frames
On Tue, Sep 26, 2017 at 11:56 AM, Gábor Csárdi wrote: > > I have yet to see an OOP system in which a subclass cannot override the > methods > of its superclass. Not only is this in line with OOP paradigms, it is > actually one of > the essential OOP features. > Fair enough. And I shouldn't have used the word "inherit" in the first place, we're talking S3 after all. Fwiw, overriding a method to do the exact same except for one detail isn't encouraged in the OOP world either. > To be more constructive, if you have a function that only works with > data frame inputs, then > it is good practice to check that the supplied input is indeed a data > frame. This is > independent of tibbles. > Actually it's not independent of tibbles as illustrated by others. is.data.frame() returns TRUE for tibbles. It doesn't for matrices or vectors. > > In practice it seems to me that an easy fix is to just call > as.data.frame on the input. This should > either convert it to a data frame, or throw an error. For tibbles it > drops the tbl* classes. > This would also allow matrices or vectors to be converted to data.frames, and that might or might not be warranted. I agree that the S3 system allows you to do this, and think it's up to the package manager to decide whether or not they would allow their users to use tibbles instead of data.frame objects. I think the bigger frustration is that tibble users are more prone to expect all code to work exactly like it does with data.frames. Which it obviously doesn't. -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] tibbles are not data frames
Where its parent class _sometimes_ returns an atomic vector and > _sometimes_ returns a data frame. > > Hadley > Indeed. And a tibble doesn't, so there's a conflict. Nobody said data.frame works better than tibble. Actually, we all agree that the legacy behaviour sucks. But it exists, and causes conflicts when users expect a tibble to behave the same as a data.frame. It does not. -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] tibbles are not data frames
On Tue, Sep 26, 2017 at 3:38 PM, Hadley Wickham wrote: > > So we should never try and improve upon legacy behaviour? I don't > understand what you're arguing for here. If a tibble didn't inherit > from a data frame, it would be useless. > > Hadley > > -- > http://hadley.nz > I didn't say that. I said a tibble does not react always like a data.frame, and you of all people know very well that this is by design. I consider this a good design choice, but it also means one shouldn't expect that all code that works with a data.frame will also work with a tibble. By design. That's what initiated this entire discussion, and that is a correct assessment. I am not arguing for any change, and said before that it is up to the package developer to choose whether he/she takes tibbles into account. It's not because I comment on tibbles or the tidyverse, that it is meant as a frontal attack on your work. I cannot repeat enough how much I value that. But the difference should be acknowledged, and imho in the first place by the user. I for one am happy this discussion pops up, because it's a piece of information I give to my students as well: convert to a data.frame when you start your analysis just to play safe. And this discussion shows why that is -for the time being!- a good advice. The moment tibbles become the default data format in R, or some R++, or in Julia for all I care, I'll be more than happy to burn that drop = FALSE on a stake. But for now we can't ignore the differences and the potential for conflicts when you try to use a tibble instead of a data.frame. With respect Joris -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] tibbles are not data frames
On Tue, Sep 26, 2017 at 5:33 PM, Hadley Wickham wrote:
> > I for one am happy this discussion pops up, because it's a piece of
> > information I give to my students as well: convert to a data.frame when
> you
> > start your analysis just to play safe. And this discussion shows why
> that is
> > -for the time being!- a good advice. The moment tibbles become the
> default
> > data format in R, or some R++, or in Julia for all I care, I'll be more
> than
> > happy to burn that drop = FALSE on a stake. But for now we can't ignore
> the
> > differences and the potential for conflicts when you try to use a tibble
> > instead of a data.frame.
>
> I think this is sub-optimal advice because most functions do work fine
> with tibbles.
Most. Not all. Either tibbles work exactly like a data.frame, or they
don't. If they do, I wouldn't give that advice. But they don't.
It is only a few packages (largely written some time
> ago) that don't. And typically, if they don't work with tibbles,
> you'll get a (usually slightly confusing) error message because some
> function will get a data frame instead of a vector. So as far I can
> tell, you only need to as.data.frame() retrospectively, not
> prospectively. Are you aware of any code that returns an incorrect
> result (i.e. no error) when given a tibble instead of a data frame?
>
x <- tibble(a = 1:5, b = 5:1)
relcount <- function(x, id){
table(x[,id]) / length(x[,id])
}
relcount(x, "a")
relcount(as.data.frame(x), "a")
You're welcome.
>
> Hadley
>
> --
> http://hadley.nz
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Help with Devtools Error
Dear Adrian,
I think the problem is rather obvious: plotMDS cannot be found. So if this
is a function of your own package, you forgot to export it. If it's a
function from another package, the package isn't loaded so it should be
added as Depends, Imports or Suggests. And when added as Suggests, you need
a library() statement in your example to load the function.
But as far as I can judge from the little info you gave, exporting the
function should do it.
On Fri, Oct 20, 2017 at 5:38 AM, Adrian Cunningham
wrote:
> Hello,
>
>
> I hope that this email finds you all well. Any help with the following
> error messages that I am getting when I run devtools::check() on my
> package would be greatly appreciated. I think that it is a Namespace
> error - but when I try to export my function, it doesn't pass the
> install check of the devtools check.
>
> Thank you in advance!
>
>
> * checking examples ...
> ** running examples for arch 'i386' ... ERROR
> Running examples in 'MDSPlot-Ex.R' failed
> The error most likely occurred in:
>
> > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> > ### Name: PlotMDS
> > ### Title: PlotMDS
> > ### Aliases: PlotMDS
> > ### Keywords: ~kwd1 ~kwd2
> >
> > ### ** Examples
> >
> > PlotMDS()
> Error in PlotMDS() : could not find function "PlotMDS"
> Execution halted
> ** running examples for arch 'x64' ... ERROR
> Running examples in 'MDSPlot-Ex.R' failed
> The error most likely occurred in:
>
> > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> > ### Name: PlotMDS
> > ### Title: PlotMDS
> > ### Aliases: PlotMDS
> > ### Keywords: ~kwd1 ~kwd2
> >
> > ### ** Examples
> >
> > PlotMDS()
> Error in PlotMDS() : could not find function "PlotMDS"
> Execution halted
> * checking PDF version of manual ... OK
> * DONE
> Status: 2 ERRORs, 4 WARNINGs, 5 NOTEs
>
>
> Best,
>
> *Adrian Cunningham, M.A.*
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] discovering if a function in a package is called under RStudio
Hi,
you can use rstudioapi::isAvailable() for that. There's other packages with
similar functionality (eg the assertive package), and you can always check
whether Sys.getenv("RSTUDIO") == "1".
Cheers
Joris
On Fri, Feb 9, 2018 at 9:09 AM, Georgi Boshnakov <
georgi.boshna...@manchester.ac.uk> wrote:
> Hi,
>
> Is there a canonical way for a function to discover if it has been called
> in a session under RStudio?
> I looked the at the options() but none seems to be dedicated to this.
>
> Thanks,
> Georgi Boshnakov
>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package check help: Package required but not available
Hi David,
When looking at apaDvalueTable.R, there's nothing that prevents the
MBESS::ci.msd() call to be executed when show.conf.interval is FALSE. Even
then the function will calculate it, just not show the result. So running
your example on Solaris will still give you an error. You'll have to add an
extra condition to prevent this.
On a sidenote: please use message() instead of cat() to send messages to
the user. Then anyone who doesn't want to see them (eg bcs they do a
simulation) can simply use suppressMessages() for that.
Cheers
Joris
On Thu, Mar 1, 2018 at 5:05 PM, David Stanley wrote:
> Hi Everyone,
>
> I’m new to this list but hopefully you can help me.
>
> I’m working on updating my apaTables package (most recent code:
> https://github.com/dstanley4/apaTables)
>
> However, I’m encountering problems passing the CRAN check because of a
> package I use (MBESS). MBESS is available on all platforms except
> r-patched-solaris-x86 (see https://cran.r-project.org/
> web/checks/check_results_apaTables.html)
>
> To work around this I did three things that have not worked.
>
> 1) I modified the DESCRIPTION file. I moved MBESS from Imports to Suggests
>
> 2) I manipulated a flag (show.confidence.interval) in my file
> apaDvalueTable.R show that it is always FALSE if the following is FALSE:
> requireNamespace("MBESS", quietly = TRUE) . That is, if the package is not
> there do no calculate the confidence intervals that require it. But I still
> fail the check. Is this perhaps because I didn’t wrap the MBESS command on
> line 97 with an “if” using requireNamespace? This command will never be
> executed without the package though because of the flag.
>
> 3) I also wrapped a command that uses MBESS in apaRegressionTable.R (line
> 276) that uses MBESS.
>
> Any help much appreciated in resolving this "Package required but not
> available” problem.
>
> (Detailed CRAN message below. Fixing the Notes issues are easy.)
>
> Cheers,
> David
>
>
>
> David Stanley, PhD | Associate Professor
> Department of Psychology | University of Guelph
> 4002 MacKinnon | 50 Stone Rd E | Guelph, ON | N1G 2W1
> dstan...@uoguelph.ca<mailto:dstan...@uoguelph.ca> | 519-824-4120 Ext.
> 58590
> uoguelph.ca/psychology/users/david-stanley<http://uoguelph.
> ca/psychology/users/david-stanley>
> @dstanley4
>
>
> Dear maintainer,
>
> package apaTables_2.0.1.tar.gz does not pass the incoming checks
> automatically, please see the pre-test at:
> <https://win-builder.r-project.org/incoming_pretest/
> 180301_161113_apaTables_201/00check.log>
> Status: 2 NOTEs
>
> Current CRAN status: ERROR: 1, OK: 11
> See: <https://CRAN.R-project.org/web/checks/check_results_apaTables.html>
>
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on
> the R-package-devel mailing list:
> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> If you are fairly certain the rejection is a false positive, please
> reply-all to this message and explain.
>
> More details are given in the directory:
> <https://win-builder.r-project.org/incoming_pretest/
> 180301_161113_apaTables_201>
> The files will be removed after roughly 7 days.
>
>
> Best regards,
> CRAN teams' auto-check service
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Roxygen: function documentation to get \item{...} in .rd file
Hi Knut,
If you want to add parameters, you need to use the tag @param :
#' @param x a numeric vector
will translate to:
\item{x}{a numeric vector}
in the \arguments section of the .Rd file.
If you want to add extra description lists (eg for elements of a list in
the output), you can use \describe:
#' \describe{
#'\item{name}{a numeric vector with names}
#' }
If you're not familiar with roxygen2 at all, you can start at the vignette
here: https://cran.r-project.org/web/packages/roxygen2/vignettes/rd.html
More information can be found in the book of Hadley on writing packages,
section about documentation : http://r-pkgs.had.co.nz/man.html
Cheers
Joris
On Mon, Mar 12, 2018 at 8:07 PM, Knut Krueger
wrote:
> I am converting a package from creating the .rd files manually to
> roxygen.
>
> I do not know how to add the additional parameters to the function
> description, so that the \item{...}{ some parameters } will be created in
> the .rd file
>
> Kind regards Knut
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Roxygen: function documentation to get \item{...} in .rd file
Hi Knut,
on a sidenote: did you try the Rd2roxygen package? That could also make
your work a lot easier.
https://cran.r-project.org/web/packages/Rd2roxygen/index.html
Cheers
Joris
On Mon, Mar 12, 2018 at 8:15 PM, Joris Meys wrote:
> Hi Knut,
>
> If you want to add parameters, you need to use the tag @param :
>
> #' @param x a numeric vector
>
> will translate to:
>
> \item{x}{a numeric vector}
>
> in the \arguments section of the .Rd file.
>
> If you want to add extra description lists (eg for elements of a list in
> the output), you can use \describe:
>
> #' \describe{
> #'\item{name}{a numeric vector with names}
> #' }
>
> If you're not familiar with roxygen2 at all, you can start at the vignette
> here: https://cran.r-project.org/web/packages/roxygen2/vignettes/rd.html
>
> More information can be found in the book of Hadley on writing packages,
> section about documentation : http://r-pkgs.had.co.nz/man.html
>
> Cheers
> Joris
>
> On Mon, Mar 12, 2018 at 8:07 PM, Knut Krueger
> wrote:
>
>> I am converting a package from creating the .rd files manually to
>> roxygen.
>>
>> I do not know how to add the additional parameters to the function
>> description, so that the \item{...}{ some parameters } will be created in
>> the .rd file
>>
>> Kind regards Knut
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
>
> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
>
> tel: +32 (0)9 264 61 79 <+32%209%20264%2061%2079>
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Dealing with not so temporary files
Duncan gave one option. The other option is to provide a specific write2disk() function or so that allows the user to determine whether he/she wants to save the data. Then the user can decide exactly where he wants to find it. The other important part is the format in which it's saved. Users can simply use save() or write.csv() (or any of the readr functions if you must) to store whatever data they want in the format they want. There's a lot of database connections possible as well if that's needed. The only reason I see to provide a specific write function or argument, is when the storage is done in a nonstandard format. And then it makes sense to provide both read_myformat() and write_myformat() in some form. That's what I as an R user would expect. Fwiw: I have seen the commotion on that discussion recently as well, but this is really nothing new. For as long as I remember, writing to disk only happens when you use a function that does explicitly that. Which makes sense as well, as eg my students often run R in a shared environment during classes, and sysadmins don't like software that starts writing files everywhere. Cheers Joris On Tue, Mar 13, 2018 at 12:32 AM, Duncan Murdoch wrote: > On 12/03/2018 6:26 PM, Roy Mendelssohn - NOAA Federal wrote: > >> Hi All: >> >> Recently there was a proper admonishment to a developer that it is bad >> etiquette writing to a user's home directory, and for temporary files use >> the functions tempdir() and tempfile(). I am working on a new package >> (presently on Github) that downloads data from a remote server, reads the >> data into R, but I would like to save that file for the user to access >> later if they so desire. Saving to the "temp directory" is not a good >> option for that, want to put it somewhere where the user can easily find >> it. What is the proper etiquette for this? Even if I provide an argument >> for the user to specify the location to save the file, I should provide a >> default location. >> > > Why not provide an argument whose default is something given by tempfile()? > > Duncan Murdoch > > > >> Any suggestions appreciated. >> >> -Roy >> >> >> >> >> >> ** >> "The contents of this message do not reflect any position of the U.S. >> Government or NOAA." >> ** >> Roy Mendelssohn >> Supervisory Operations Research Analyst >> NOAA/NMFS >> Environmental Research Division >> Southwest Fisheries Science Center >> ***Note new street address*** >> 110 McAllister Way >> Santa Cruz, CA 95060 >> Phone: (831)-420-3666 >> Fax: (831) 420-3980 >> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/ >> >> "Old age and treachery will overcome youth and skill." >> "From those who have been given much, much will be expected" >> "the arc of the moral universe is long, but it bends toward justice" -MLK >> Jr. >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> >> > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Dealing with not so temporary files
Hi Gabor,
That's indeed the case, but I see good reasons for the CRAN policy when we
take reproducability into account. Afaik, CRAN and R always strived to
provide tools that give the same output regardless of the machine they're
running on when opened in a fresh R session. If packages store settings on
disk without explicitly asking the user, you increase the risk of code
generating different results on different machines without the user
necessarily be aware of it, or why it happens.
Obviously there's much to say in favor of allowing packages to store
settings, but there's a trade off between user experience and
reproducability that needs to be taken into account imho.
Cheers
Joris
On Thu, Mar 15, 2018 at 11:14 AM, Gábor Csárdi
wrote:
> This seems to be a good occasion to note that the CRAN policy does not
> seem to conform
> the industry standards. Applications can actually store user level
> configuration information,
> cached data, logs, etc. in the user's home directory, and there
> standard way to do this.
>
> Here is the Apple recommendation:
> https://developer.apple.com/library/content/documentation/
> FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/
> FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1
>
> AFAIK all modern Linux distributions use the XDG standard, or
> something close to it:
> https://specifications.freedesktop.org/basedir-spec/
> basedir-spec-latest.html
>
> On Windows there are APIs to retrieve the right locations, but
> generally it is all in
> `%APPDATA%`: https://msdn.microsoft.com/en-us/library/dd378457(v=vs.85).
> aspx
>
> The rappdirs package helps you to select the right location, in a
> platform independent way.
> Of course according to the CRAN policy, you still need to ask the user
> interactively
> before writing to the directories that rappdirs returns.
>
> I think a good practice is to use "R" as the application name, and
> within that a subdirectory
> that is the package name. This is a way to do it, for configuration files:
>
> ## Windows
> ❯ rappdirs::user_config_dir("R", version = "mypackage")
> [1] "C:/Users/gaborcsardi/AppData/R/R/mypackage"
>
> ## macOS
> ❯ rappdirs::user_config_dir("R", version = "mypackage")
> [1] "/Users/gaborcsardi/Library/Application Support/R/mypackage"
>
> ## Linux
> ❯ rappdirs::user_config_dir("R", version = "mypackage", os = "unix")
> [1] "/Users/gaborcsardi/.config/R/mypackage"
>
> Gabor
>
> On Tue, Mar 13, 2018 at 8:52 AM, Joris Meys wrote:
> > Duncan gave one option. The other option is to provide a specific
> > write2disk() function or so that allows the user to determine whether
> > he/she wants to save the data. Then the user can decide exactly where he
> > wants to find it.
> >
> > The other important part is the format in which it's saved. Users can
> > simply use save() or write.csv() (or any of the readr functions if you
> > must) to store whatever data they want in the format they want. There's a
> > lot of database connections possible as well if that's needed. The only
> > reason I see to provide a specific write function or argument, is when
> the
> > storage is done in a nonstandard format. And then it makes sense to
> provide
> > both read_myformat() and write_myformat() in some form. That's what I as
> an
> > R user would expect.
> >
> > Fwiw: I have seen the commotion on that discussion recently as well, but
> > this is really nothing new. For as long as I remember, writing to disk
> only
> > happens when you use a function that does explicitly that. Which makes
> > sense as well, as eg my students often run R in a shared environment
> during
> > classes, and sysadmins don't like software that starts writing files
> > everywhere.
> >
> > Cheers
> > Joris
> >
> >
> >
> > On Tue, Mar 13, 2018 at 12:32 AM, Duncan Murdoch <
> murdoch.dun...@gmail.com>
> > wrote:
> >
> >> On 12/03/2018 6:26 PM, Roy Mendelssohn - NOAA Federal wrote:
> >>
> >>> Hi All:
> >>>
> >>> Recently there was a proper admonishment to a developer that it is bad
> >>> etiquette writing to a user's home directory, and for temporary files
> use
> >>> the functions tempdir() and tempfile(). I am working on a new package
> >>> (presently on Github) that downloads data from a remote server, reads
> the
> >>> data into R, but I would like to save that file for the user to access
> >>> later
Re: [R-pkg-devel] Dealing with not so temporary files
On Thu, Mar 15, 2018 at 12:27 PM, Rainer Krug wrote: > > Yes - that is definitely true, but the one does not exclude the other. I > actually think giving permission once, and than forgetting about it, is > worse than knowing: Stop - user configuration is loaded - unless I tell it > not to be loaded. > Indeed, with the caveat that it's up to the package author to add the startup message, and that will be missed when startup messages are suppressed. > > And one could go one step further: If R would provide a standardised API > to store package configuration data, the loading could be disabled with > e.g. —vanilla. > If it's standardized and included in R itself, I'm all for it. Cheers Joris -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Byte-compilation problem for R-package ddalpha after update to R 3.5.0
Dear pavlo,
fwiw, the binary of ddalpha 1.3.2 installs just fine on Windows 10. When
building from source, I get a whole lot of warnings about uninitialized
variables, comparisons between signed and unsigned integers. The
compilation of the source code doesn't have a large impact on the memory. I
can confirm that the last step of the installation process (the byte
compiling of the actual package) requires at least 8 Gb. I have 8Gb DDR3 of
which 2.5 Gb is used by other processes. During the build process it fills
up and at one point I have another 3 Gb in swap. That works on Windows 10
(the installation process exits successfully) but might well be the reason
why on other systems you get the errors you see.
One thing I noticed, is humongously huge code files (eg dataf.tecator.R is
a whopping 624 Kb). I would start with storing the data structures you
include as a .RDS file in a data folder (eg a file tefactor.rda containing
a data structure tefactor) , and rewrite the functions as
dataf.tefactor <- function() {return(tefactor) }
That will save in total several Mb of code files that need to be processed
by the byte compiler. Not sure this will solve the problem, but it's a low
hanging fruit ready to pick. If you're not sure what I'm talking about, you
can link me to the github repo (if you have one) and I'll take a look.
Cheers
Joris
On Mon, Apr 30, 2018 at 2:32 AM, MOZHAROVSKYI Pavlo <
pavlo.mozharovs...@ensai.fr> wrote:
>
> After the R-update to version 3.5.0 there seems to be a problem with our
> R-package ddalpha. As it seems that the problem is connected to the
> newly introduced byte-compilation on installation, we feel unable to
> locate its root cause and ask for your help.
>
> During the byte-compilation of the package ddalpha (latest (CRAN)
> version 1.3.2), an immense amount of memory (more than 4Gb) is consumed.
> Further, byte-compilation takes at least several minutes to complete on
> Windows and MacOS, while it throws an error on the Linux system where it
> does not install at all:
>
> Error message:
> Error in system2(file.path(R.home("bin"), "R"), c(if (nzchar(arch))
> paste0("--arch=", :
>cannot popen ' '/usr/lib64/R/bin/R' --no-save --slave 2>&1 <
> '/tmp/RtmpU4dXOt/file3fb5b89c507'', probable reason 'Cannot allocate
> memory'
>
> We suspect a mistake in the design of our package and would appreciate
> your advice. From our side, we are ready to undertake necessary actions
> as soon as possible.
>
> Here are the existing discussions on this topic:
>
> - SO:
> https://stackoverflow.com/questions/50028566/cannot-
> allocate-memory-while-re-installing-r-package-ddalpha-under-arch-linu
> - Arch Linux: https://bbs.archlinux.org/viewtopic.php?id=236517
> - RStudio Community:
> https://community.rstudio.com/t/memory-allocation-problem-
> while-re-installing-ddalpha-package-after-upgrade-to-r-3-5-0/7663/3
>
> Thank you a lot for your help!
>
> Best regards,
> Pavlo
>
>
> --
>
> Pavlo Mozharovskyi
> ENSAI - Campus de Ker-Lann
> Rue Blaise Pascal - BP 37203
> 35172 Bruz cedex
> FRANCE
>
> Tel: +33 (0)2 99 05 32 55
> Fax: +33 (0)2 99 05 32 05
> Email: pavlo.mozharovs...@ensai.fr
>
> http://www.ensai.fr/enseignant/alias/pavlo-mozharovskyi.html
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] checksums change after publication on CRAN?
In a discussion of twitter it was pointed out that the checksums of packages change after publication on CRAN. One example is the Matrix package version 1.2-12, which was available on CRAN already on nov 17, 2017 but got a different checksum on nov 20, 2017. This caused issues in eg easybuilders. (see reference here : https://github.com/easybuilders/easybuild-easyconfigs/pull/6118 ) I went through the Matrix SVN repo, and there is no commit whatsoever that adds the last line in the DESCRIPTION file. This line reads: Date/Publication: 2017-11-20 18:57:47 UTC I wondered how this happens, and it looks like CRAN adds this automatically days after the source is available for download. This is suboptimal imho as it would technically mean that you can have two files of the same package version with different checksums. It leads people to believe packages on CRAN can be changed without bumping the version number, and technically that's what it boils down to. Anyone who knows what's going on there? Reference to twitter discussion with Kenneth Hoste about this : https://twitter.com/kehoste/status/990484417721389056 Kind regards Joris -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] checksums change after publication on CRAN?
I wrongfully stated that CRAN added a line. The line was not added but changed (and not in the SVN repo). A diff between both downloads is available here: https://gist.github.com/boegel/2ea28647f00ddd9b18f9b1a0ac6dd2b4 Cheers Joris On Mon, Apr 30, 2018 at 6:03 PM, Joris Meys wrote: > In a discussion of twitter it was pointed out that the checksums of > packages change after publication on CRAN. One example is the Matrix > package version 1.2-12, which was available on CRAN already on nov 17, 2017 > but got a different checksum on nov 20, 2017. This caused issues in eg > easybuilders. > > (see reference here : https://github.com/easybuilders/easybuild- > easyconfigs/pull/6118 ) > > I went through the Matrix SVN repo, and there is no commit whatsoever that > adds the last line in the DESCRIPTION file. This line reads: > > Date/Publication: 2017-11-20 18:57:47 UTC > > I wondered how this happens, and it looks like CRAN adds this > automatically days after the source is available for download. > > This is suboptimal imho as it would technically mean that you can have two > files of the same package version with different checksums. It leads people > to believe packages on CRAN can be changed without bumping the version > number, and technically that's what it boils down to. > > Anyone who knows what's going on there? > > Reference to twitter discussion with Kenneth Hoste about this : > https://twitter.com/kehoste/status/990484417721389056 > > Kind regards > Joris > > -- > Joris Meys > Statistical consultant > > Department of Data Analysis and Mathematical Modelling > Ghent University > Coupure Links 653, B-9000 Gent (Belgium) > > <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> > > tel: +32 (0)9 264 61 79 > --- > Biowiskundedagen 2017-2018 > http://www.biowiskundedagen.ugent.be/ > > --- > Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] File link does not exist : how to get the correct one?
Hi all,
The latest changes in R cause a lot of Rd warnings about file links that
don't exist and are treated as a topic. One example is
\code{\link[stats]{fitted}}
Now if I look at ?fitted , the name of the page (top left corner) is given
as "fitted". So I would expect that the code above should just work fine,
but it generates the warning.
How can one get these names without having to browse through the directory
with html files?
Cheers
Joris
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Creating S3 methods for S4 classes
Dear all,
per the manual, one should create and register both the S3 and a S4 method
if one needs a method for an S4 class for a function using S3 dispatching.
This is cumbersome, and not very optimal.
I was wondering if there's a better way to do this. Currently I recreate a
generic in my package and create a default method that sends all the other
classes to the S3 generic, eg:
setGeneric("predict")
setMethod("predict", "ANY", stats::predict)
I'm not sure if this hasn't any adverse consequences, as it is not the
recommended approach
It would be great if these generics could be made available through stats4.
If this would be the prefered route, I volunteer to create the patch for
that.
Any thoughts?
Cheers
Joris
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Errors in my package
On Thu, May 24, 2018 at 10:11 PM, Steven Spiriti wrote: > > > x <- 0:30/30 > > truey <- x*sin(10*x) > > set.seed(10556) > > y <- truey + rnorm(31, 0, 0.2) > > xy.freekt <- freelsgen(x, y, degree = 2, numknot = 2, 555) > > coef(xy.freekt) > Error: $ operator not defined for this S4 class > Execution halted > The error and the code of the function tell me there is a problem with dispatching. You treat xy.freekt as an S4 class and R thinks so too. The coef generic is S3. The default method for this generic extracts object$coefficients, and that can't work on an S4 class. This would explain the error you see: instead of using the appropriate method, the dispatching apparently uses the default S3 method. Can you link us to a github repo or so where we can see the code? I suspect either a problem with the NAMESPACE or with the class definitions. Are you sure freelsgen returns the class you expect it to return? Cheers Joris -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] FW: [CRAN-pretest-archived] CRAN submission bwt 1.1.0
cation: > > GNU General Public License v3.0 > > Standardizable: FALSE > > > > checking for missing documentation entries ... WARNING Undocumented code > objects: > > 'bwt' 'ibwt' > > All user-level objects in a package should have documentation entries. > > See chapter 'Writing R documentation files' in the 'Writing R > Extensions' manual. > > > > May I know how can I proceed? I am kind of lost a this pint in time, > even after looking up CRAN's documentations.. If it helps, attached in this > email is my .tar.gz file which I have submitted earlier. > > > > Thank you and I apologize for any inconvenience that I may have caused.. > > > > Warmest Regards, > > > > Wei Hao Khoong (Mr) > > > > -Original Message- > > From: uwe.lig...@r-project.org > > Sent: Wednesday, 30 May 2018 12:11 AM > > To: khoongwei...@hotmail.com > > Cc: cran-submissi...@r-project.org > > Subject: [CRAN-pretest-archived] CRAN submission bwt 1.1.0 > > > > Dear maintainer, > > > > package bwt_1.1.0.tar.gz does not pass the incoming checks > automatically, please see the following pre-tests: > > > > > > Status: 3 WARNINGs, 3 NOTEs > > Debian: <https://win-builder.r-project.org/incoming_pretest/ > bwt_1.1.0_20180529_101440/Debian/00check.log> > > Status: 3 WARNINGs, 3 NOTEs > > > > > > > > Please fix all problems and resubmit a fixed version via the webform. > > If you are not sure how to fix the problems shown, please ask for help > on the R-package-devel mailing list: > > <https://stat.ethz.ch/mailman/listinfo/r-package-devel> > > If you are fairly certain the rejection is a false positive, please > reply-all to this message and explain. > > > > More details are given in the directory: > > <https://win-builder.r-project.org/incoming_pretest/ > bwt_1.1.0_20180529_101440/> > > The files will be removed after roughly 7 days. > > > > No strong reverse dependencies to be checked. > > > > Best regards, > > CRAN teams' auto-check service > > > > __ > > 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 > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] FW: [CRAN-pretest-archived] CRAN submission bwt 1.1.0
Hi Khoong,
About your error: I now realized that's the output at your local console.
To test your package, you should run R CMD check --as-cran bwt_1.1.0.tar.gz
from the command line. So the error has nothing to do with CRAN but with
you testing your development directory structure as opposed to the file you
sent to CRAN.
Cheers
Joris
On Wed, May 30, 2018 at 5:17 PM, Joris Meys wrote:
> Hi Khoong,
>
> I'm going to address the elephant in the room: your package is not ready
> for CRAN, and I'm not even sure CRAN is the right place for that code.
>
> There's two large issues with your package, next to the license problem
> Hugh pointed out already:
>
> 1. R code needs to be in subdirectory R, the Rd file needs to be in a
> subdirectory called man. In the tar.gz file, both are in the main folder.
> That's never going to work.
>
> 2. Your Rd file is seriously messed up. The name and alias contain what
> should be the title, the title isn't filled in. I suggest you take a look
> at roxygen2 to help you write the documentation, or go through Writing R
> extensions again to check the details on the man pages.
>
> \name{bwt}
> \alias{ibwt}
>
> will at least get the one warning about undocumented objects away.
>
> 3. The package in its entirity is 2 rather short functions. I'm not from
> CRAN, but I don't know if that would pass the "non-trivial contribution"
> test. You might want to think about a package that could import your code
> rather than submitting a separate package. Not saying the code is not
> valuable or the package has no place on CRAN, but you might get questions
> on that and then it's better to be prepared with a good answer as to why
> this really should be on CRAN.
>
> Your error otoh looks like something that is not your fault. As far as I
> know, having a test suite using testthat is not obligatory for a CRAN
> package. Yet, CRAN did try to run the tests and errored because it couldn't
> find any. I'll raise that at R-devel and see what's going on there.
> Nevertheless, adding a few tests would be a good idea. testthat lets you do
> that rather easily, and you can find more information in the vignettes of
> that package and Hadley's book on writing packages.
>
> Hope this helps
> Cheers
> Joris
>
>
>
> On Wed, May 30, 2018 at 4:52 PM, Hugh Parsonage
> wrote:
>
>> Hi,
>>
>> There are a few problems with the submission. Probably more than can
>> be resolved by people on the mailing list. Speaking generally, a
>> WARNING in a CRAN check is something that *must* be fixed, rather than
>> something which you can just acknowledge. The two warnings that you
>> mentioned are that you probably have (in your DESCRIPTION file)
>>
>> License: GNU General Public License v3.0
>>
>> when you should have
>>
>> License: GPL-3
>>
>> The second warning is about undocumented code objects. You can choose
>> not to export them, but if you do export them as you currently are,
>> you will need to document them.
>>
>> I notice that there are other problems too: consult the links in the
>> auto-generated email from CRAN, see the 00check file. You should fix
>> every problem until there are no ERRORS, WARNINGS, or NOTEs.
>>
>>
>> Best.
>>
>> On 31 May 2018 at 00:03, khoong Wei Hao wrote:
>> > Hi Everyone,
>> >
>> > I encountered an issue during my submission of my package (see original
>> message below).
>> >
>> > I ran checks and tests with testthat::test_dir("tests/") and
>> devtoos::check(), and all seemed fine except some issues with undocumented
>> objects which I did note in the .Rd file, and the documentation appeared in
>> the console as I ran the package. The following is my R console output:
>> >
>> >> devtools::check()
>> > Updating bwt documentation
>> > Loading bwt
>> > First time using roxygen2. Upgrading automatically...
>> > Warning: The existing 'NAMESPACE' file was not generated by roxygen2,
>> and will not be overwritten.
>> > Setting env vars --
>> --
>> > CFLAGS : -Wall -pedantic
>> > CXXFLAGS: -Wall -pedantic
>> > Building bwt --
>>
>> --
>> > "C:/PROGRA~1/R/R-33~1.2/bin/x64/R" --no-site-file --no-environ
>> --no-save --no-restore --quiet CMD build \
>> > "C:\Users
[R-pkg-devel] Differences between documentation and CRAN requirements: an update needed?
Dear all,
Two recent tweets pointed out that apparently there were some changes to
the CRAN requirements for packages. Yet, not all requirements are
consistent with documentation or previous communication. These issues also
come up more often lately, partly because people start to be more vocal
about them on different social media. Let me illustrate:
One is about DOI requirements and the apparent rule against using
\dontrun{}. I do get the strict requirements for DOI citations, but I was
baffled to find out that using \dontrun{} is now frowned upon.
https://twitter.com/thosjleeper/status/1005850352997019649?s=19
I've tried to find the information that says \dontrun{} shouldn't be used
but couldn't find it. In contrary, it is still documented in writing R
extensions as a valid option:
https://cran.r-project.org/doc/manuals/R-exts.html#index-_005cdontrun
The second one is more worrisome. It deals with the use of
R_GetConnection() and R CMD check apparently now complains with a NOTE that
this function and the function R_WriteConnection() are not part of the
public API.
https://github.com/tidyverse/readr/issues/856#issuecomment-391787058
The note in R CMD check Yet, in the NEWS file for R 3.3.0 the following is
found:
The connections interface now includes a function R_GetConnection() which
allows packages implementing connections to convert R connection objects to
Rconnection handles. Code which previously used the low-level R-internal
getConnection() entry point should switch.
So at least that function has been part of the API at one point. I've tried
to find the point where this function was removed from the public API, but
again I turned up a blank.
Hence my question:
Without meaning any disrespect towards the huge effort done daily by the
CRAN maintainers, I would like to ask if it is possible to communicate an
update on the requirements or adjust the documentation that is refered to
accordingly. Specifically the note of R CMD check points to the part about
portable code in writing R extensions, I couldn't locate anything remotely
helpful there.
I do not want to contest the decisions made, but it's hard to train/help
people correctly if we can't rely on the official documentation any longer
to know what is and what is not accepted. And for the moment that seems to
be the case.
Cheers
Joris
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Checksums changed on CRAN without any visible modifications to files.
Dear all, I have another report of checksums for CRAN packages that changed without any visible change to the package itself. https://github.com/easybuilders/easybuild-easyconfigs/pull/6446 At the time of the release of R3.5, pkgmaker was at version 0.22. A bit after the release, this version was archived and replaced by the new one (0.27). Somewhere in that process the checksum for the tarball of version 0.22 changed. The only explanation I can come up with, is that either because of the release of R3.5 or because of the archiving the tarball was recreated and has a different timestamp. That's the only way I know a MD5 checksum of a tarball can change without any change to the files in there. Anyone knows what is going on here, and how this can be circumvented at the client side? Cheers Joris -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Checksums changed on CRAN without any visible modifications to files.
On Wed, Jun 13, 2018 at 3:16 PM, Uwe Ligges wrote: > > When CRAN repacks and changes the DESCRIPTION file, the checksums change, > of course. > > Best, > Uwe Ligges > > Dear Uwe, I understood that from the previous issue. In this case however, none of the files -including the DESCRIPTION file- were changed. Am I right in suspecting that a package is repacked when moved to the archive? I suspect that the tool used to repack the package is using gzip, and it is possible to repack without adding a timestamp as explained here : https://serverfault.com/questions/110208/different-md5sums-for-same-tar-contents I can explain the different checksums when some things are changed to our HPC sysadmins, but they have -understandibly- difficulties with checksums changing for released source tarballs. Is it possible to adapt the archiving so that at least for identical tarballs the md5 sums remain the same? Or if you have other suggestions to deal with this without having to change hardcoded checksums in the easybuild repos, that would be very welcome too. Cheers Joris -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Checksums changed on CRAN without any visible modifications to files.
Dear Uwe, Thank you for willing to take a look. In the report it was about the following tarballs : pkgmaker_0.22.tar.gz rngtools_1.2.4.tar.gz RcppProgress_0.4.tar.gz Our sysadmin tried diff -ru, but couldn't find any difference in the text files. Cheers Joris On Thu, Jun 14, 2018 at 5:46 PM, Uwe Ligges wrote: > > > On 13.06.2018 15:40, Joris Meys wrote: > >> >> >> On Wed, Jun 13, 2018 at 3:16 PM, Uwe Ligges < >> lig...@statistik.tu-dortmund.de <mailto:lig...@statistik.tu-dortmund.de>> >> wrote: >> >> >> When CRAN repacks and changes the DESCRIPTION file, the checksums >> change, of course. >> >> Best, >> Uwe Ligges >> >> >> Dear Uwe, >> >> I understood that from the previous issue. In this case however, none of >> the files -including the DESCRIPTION file- were changed. Am I right in >> suspecting that a package is repacked when moved to the archive? >> > > No, we do not repack generally then. Perhaps the package got orphaned? > > > Which package / tarball were you talking about? I can take a look why that > one was changed and inspect why the checksum changed. > > Best, > Uwe Ligges > > > > I > >> suspect that the tool used to repack the package is using gzip, and it is >> possible to repack without adding a timestamp as explained here : >> >> https://serverfault.com/questions/110208/different-md5sums- >> for-same-tar-contents >> >> I can explain the different checksums when some things are changed to our >> HPC sysadmins, but they have -understandibly- difficulties with checksums >> changing for released source tarballs. Is it possible to adapt the >> archiving so that at least for identical tarballs the md5 sums remain the >> same? Or if you have other suggestions to deal with this without having to >> change hardcoded checksums in the easybuild repos, that would be very >> welcome too. >> >> Cheers >> Joris >> >> -- >> Joris Meys >> Statistical consultant >> >> Department of Data Analysis and Mathematical Modelling >> Ghent University >> Coupure Links 653, B-9000 Gent (Belgium) >> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+ >> Gent,%C2%A0Belgium&entry=gmail&source=g> >> >> tel: +32 (0)9 264 61 79 >> --- >> Biowiskundedagen 2017-2018 >> http://www.biowiskundedagen.ugent.be/ >> >> --- >> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php >> > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Checksums changed on CRAN without any visible modifications to files.
Dear Uwe, sorry to bother you again with it, but I was wondering if you had some more idea about what happened. I just received another one, this time about mgcv_1.8-23.tar.gz. It goes beyond my understanding as to why the MD5 sums would change without any change to the package. Is there anything I can check at this side to make it easier for you? Cheers Joris On Thu, Jun 14, 2018 at 6:55 PM, Joris Meys wrote: > Dear Uwe, > > Thank you for willing to take a look. In the report it was about the > following tarballs : > > pkgmaker_0.22.tar.gz > rngtools_1.2.4.tar.gz > RcppProgress_0.4.tar.gz > > Our sysadmin tried diff -ru, but couldn't find any difference in the text > files. > > Cheers > Joris > > On Thu, Jun 14, 2018 at 5:46 PM, Uwe Ligges de> wrote: > >> >> >> On 13.06.2018 15:40, Joris Meys wrote: >> >>> >>> >>> On Wed, Jun 13, 2018 at 3:16 PM, Uwe Ligges < >>> lig...@statistik.tu-dortmund.de <mailto:lig...@statistik.tu-dortmund.de>> >>> wrote: >>> >>> >>> When CRAN repacks and changes the DESCRIPTION file, the checksums >>> change, of course. >>> >>> Best, >>> Uwe Ligges >>> >>> >>> Dear Uwe, >>> >>> I understood that from the previous issue. In this case however, none of >>> the files -including the DESCRIPTION file- were changed. Am I right in >>> suspecting that a package is repacked when moved to the archive? >>> >> >> No, we do not repack generally then. Perhaps the package got orphaned? >> >> >> Which package / tarball were you talking about? I can take a look why >> that one was changed and inspect why the checksum changed. >> >> Best, >> Uwe Ligges >> >> >> >> I >> >>> suspect that the tool used to repack the package is using gzip, and it >>> is possible to repack without adding a timestamp as explained here : >>> >>> https://serverfault.com/questions/110208/different-md5sums-f >>> or-same-tar-contents >>> >>> I can explain the different checksums when some things are changed to >>> our HPC sysadmins, but they have -understandibly- difficulties with >>> checksums changing for released source tarballs. Is it possible to adapt >>> the archiving so that at least for identical tarballs the md5 sums remain >>> the same? Or if you have other suggestions to deal with this without having >>> to change hardcoded checksums in the easybuild repos, that would be very >>> welcome too. >>> >>> Cheers >>> Joris >>> >>> -- >>> Joris Meys >>> Statistical consultant >>> >>> Department of Data Analysis and Mathematical Modelling >>> Ghent University >>> Coupure Links 653, B-9000 Gent (Belgium) >>> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+G >>> ent,%C2%A0Belgium&entry=gmail&source=g> >>> >>> tel: +32 (0)9 264 61 79 >>> --- >>> Biowiskundedagen 2017-2018 >>> http://www.biowiskundedagen.ugent.be/ >>> >>> --- >>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php >>> >> > > > -- > Joris Meys > Statistical consultant > > Department of Data Analysis and Mathematical Modelling > Ghent University > Coupure Links 653, B-9000 Gent (Belgium) > > <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> > > tel: +32 (0)9 264 61 79 > --- > Biowiskundedagen 2017-2018 > http://www.biowiskundedagen.ugent.be/ > > --- > Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Checksums changed on CRAN without any visible modifications to files.
Correction: In the case of mgcv it was the publication date that changed for some reason. Our sysadmins keep reaching out to me in the hope to resolve this. Is there a way they can reach out so this can be clarified? For reference, the latest issue on mgcv : https://github.com/easybuilders/easybuild-easyconfigs/issues/6501 Cheers Joris On Wed, Jun 27, 2018 at 3:30 PM, Joris Meys wrote: > Dear Uwe, > > sorry to bother you again with it, but I was wondering if you had some > more idea about what happened. I just received another one, this time about > mgcv_1.8-23.tar.gz. It goes beyond my understanding as to why the MD5 sums > would change without any change to the package. Is there anything I can > check at this side to make it easier for you? > > Cheers > Joris > > On Thu, Jun 14, 2018 at 6:55 PM, Joris Meys wrote: > >> Dear Uwe, >> >> Thank you for willing to take a look. In the report it was about the >> following tarballs : >> >> pkgmaker_0.22.tar.gz >> rngtools_1.2.4.tar.gz >> RcppProgress_0.4.tar.gz >> >> Our sysadmin tried diff -ru, but couldn't find any difference in the text >> files. >> >> Cheers >> Joris >> >> On Thu, Jun 14, 2018 at 5:46 PM, Uwe Ligges < >> lig...@statistik.tu-dortmund.de> wrote: >> >>> >>> >>> On 13.06.2018 15:40, Joris Meys wrote: >>> >>>> >>>> >>>> On Wed, Jun 13, 2018 at 3:16 PM, Uwe Ligges < >>>> lig...@statistik.tu-dortmund.de <mailto:lig...@statistik.tu-dortmund.de>> >>>> wrote: >>>> >>>> >>>> When CRAN repacks and changes the DESCRIPTION file, the checksums >>>> change, of course. >>>> >>>> Best, >>>> Uwe Ligges >>>> >>>> >>>> Dear Uwe, >>>> >>>> I understood that from the previous issue. In this case however, none >>>> of the files -including the DESCRIPTION file- were changed. Am I right in >>>> suspecting that a package is repacked when moved to the archive? >>>> >>> >>> No, we do not repack generally then. Perhaps the package got orphaned? >>> >>> >>> Which package / tarball were you talking about? I can take a look why >>> that one was changed and inspect why the checksum changed. >>> >>> Best, >>> Uwe Ligges >>> >>> >>> >>> I >>> >>>> suspect that the tool used to repack the package is using gzip, and it >>>> is possible to repack without adding a timestamp as explained here : >>>> >>>> https://serverfault.com/questions/110208/different-md5sums-f >>>> or-same-tar-contents >>>> >>>> I can explain the different checksums when some things are changed to >>>> our HPC sysadmins, but they have -understandibly- difficulties with >>>> checksums changing for released source tarballs. Is it possible to adapt >>>> the archiving so that at least for identical tarballs the md5 sums remain >>>> the same? Or if you have other suggestions to deal with this without having >>>> to change hardcoded checksums in the easybuild repos, that would be very >>>> welcome too. >>>> >>>> Cheers >>>> Joris >>>> >>>> -- >>>> Joris Meys >>>> Statistical consultant >>>> >>>> Department of Data Analysis and Mathematical Modelling >>>> Ghent University >>>> Coupure Links 653, B-9000 Gent (Belgium) >>>> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+G >>>> ent,%C2%A0Belgium&entry=gmail&source=g> >>>> >>>> tel: +32 (0)9 264 61 79 >>>> --- >>>> Biowiskundedagen 2017-2018 >>>> http://www.biowiskundedagen.ugent.be/ >>>> >>>> --- >>>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php >>>> >>> >> >> >> -- >> Joris Meys >> Statistical consultant >> >> Department of Data Analysis and Mathematical Modelling >> Ghent University >> Coupure Links 653, B-9000 Gent (Belgium) >> >> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> >> >> tel: +32 (0)9 264 61 79 >> --- >> Biowiskundedagen 2017-2018 >> http://www.biowiskundedagen.ugent.be/ >> >>
Re: [R-pkg-devel] Questions about making a database package (Rpolyhedra)
Hi Ale, I'd personally use a more specific solution like github LFS (large file storage) for a versioned database. You should also check with CRAN itself, as they keep high standards for everything that's not a standard install. More specifically (from CRAN policies) : Downloads of additional software or data as part of package installation or startup should only use secure download mechanisms (e.g., ‘https’ or ‘ftps’). Personally I would store that information in a public database somewhere with a (minimal) API. This can then be extended without inflating the download and would allow people to install only a subset of what they need. That would also allow people to also port your work to other language by simply writing a wrapper around the DB API. It's not a necessity, but I thought it was worth mentioning as an option. Cheers Joris On Wed, Jun 27, 2018 at 10:22 PM, alejandro baranek < alejandrobara...@gmail.com> wrote: > By now, we are on that situation: +- 150 polyhedra published. > But +800 able to publish and because of package size cannot publish all of > them. > > It is not a problem on github, it's a problem on CRAN, with building (fixed > testing timing with simple sample techniques) timing. I would like to hear > more from experienced package developers about this issues, but we seemed > to found a solution. > > We decided to make another github repo RpolyhedraDB. When you install the > package, it downloads the database from the correct tag marked in the data > folder of the package in a home directory of the user. So package will be > minimal for CRAN, will be RR and will install database on first use (In > case of TRAVIS or other qa/continuous integration, it will install it of > course). It will be possible to setup different DB size using the TAGS, in > case we find it preferable to the users. > > > Best, Ale. > > > 2018-03-29 4:43 GMT-03:00 Berry Boessenkool > : > > > > > I assume you cannot simply reduce the 150 to a few for demonstration > > purposes? > > > > > > I have seen people using DRAT packages on github for data, but gh is > > limited in size restrictions as well... > > > > > > No expert in this, but maybe this helps a little bit... > > > > Berry > > > > > > > > - > > > > > > > > > > > > -- > > *From:* R-package-devel on > behalf > > of alejandro baranek > > *Sent:* Tuesday, March 27, 2018 19:26 > > *To:* r-package-devel@r-project.org > > *Subject:* [R-pkg-devel] Questions about making a database package > > (Rpolyhedra) > > > > Hello group: > > > > We released Rpolyhedra V0.2 last month. It is able to scrape +800 > polyhedra > > definitions from public sources. At V0.2.4 we are publishing only 150 > > because the time needed for scrape all the polyhedra, testing and the > > resulting size of the package. The difference is a configuration in > zzz.R, > > very simple to change (Who wants to try it, can build the package for > > themeselves) > > Only the source files of polyhedra definitions are +12MB of size (We are > > including it in the data folder for package self suficience). > > > > But we have doubts about good practices for publishing a database > package. > > > > We think the solution is to split the package in an internal > > Rpolyhedra-lib, opensource but not in CRAN, and Rpolyhedra with a catalog > > sewhich enables to connect with that repo for downloading scraped > polyhedra > > on-demand. > > > > We have to think further the way of connecting both repositories, but > > before touching any code, want to listen to experienced package > developers > > and the community in general, about to do this. > > Do you know any package with analog behavior than this package? We didn't > > find it. > > > > Best, Ale. > > -- > > alejandro baranek > > @ken4rab <https://twitter.com/ken4rab> > > qbotics <http://qbotics.tumblr.com/> | surferinvaders > > <http://surferinvaders.tumblr.com> | algebraic-soundscapes > > <http://imaginary.org/content/algebraic-soundscapes> | surfer-shuffle > > <http://imaginary.org/program/surfer-shuffle> > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > > > -- > alejandro baranek > @ken4rab <https://twitter.com/ken4rab> > qbotics <http://qbotics.tumblr.com/> | surferi
Re: [R-pkg-devel] Checksums changed on CRAN without any visible modifications to files.
Thx Henrik. That's indeed one of the issues: right now these minor and defendable changes are not reflected in the version or filename. Hence there's really no way to know the tarball (and hence the checksums) changed other than a build suddenly failing. Our sysadmin proposed to add eg _1 or _patched to the updated tarball, but I also realize this would require a lot of changes in other places. I wish I knew a way this could be avoided without causing trouble elsewhere, but I'm not inventive enough alas. The other three packages mentioned in that issue, don't even show a visible change. So in those cases, all (text) files in the tarball are identical and yet the checksum somehow changed as well. There it's even more baffling, but I'm more confident that this should be solvable on CRAN without interfering with other things. Cheers Joris On Thu, Jun 28, 2018 at 6:50 PM, Henrik Bengtsson < henrik.bengts...@gmail.com> wrote: > Below are more details on/examples of changes due to ORCID URLs being > added to the DESCRIPTION file (from > https://github.com/easybuilders/easybuild-easyconfigs/pull/6446# > issuecomment-396574744): > > $ diff -ru RWeka.orig RWeka > diff -ru RWeka.orig/DESCRIPTION RWeka/DESCRIPTION > --- RWeka.orig/DESCRIPTION 2018-01-07 16:27:10.0 +0100 > +++ RWeka/DESCRIPTION 2018-05-23 11:45:56.0 +0200 > @@ -26,12 +26,12 @@ > License: GPL-2 > NeedsCompilation: no > Packaged: 2018-01-07 15:04:47 UTC; hornik > -Author: Kurt Hornik [aut, cre] (-0003-4198-9911), > +Author: Kurt Hornik [aut, cre] (<https://orcid.org/-0003-4198-9911>), >Christian Buchta [ctb], >Torsten Hothorn [ctb], >Alexandros Karatzoglou [ctb], >David Meyer [ctb], > - Achim Zeileis [ctb] (-0003-0918-3766) > + Achim Zeileis [ctb] (<https://orcid.org/-0003-0918-3766>) > Maintainer: Kurt Hornik > Repository: CRAN > Date/Publication: 2018-01-07 16:17:29 > diff -ru RWeka.orig/MD5 RWeka/MD5 > --- RWeka.orig/MD5 2018-01-07 16:27:10.0 +0100 > +++ RWeka/MD5 2018-05-23 11:45:56.0 +0200 > @@ -1,5 +1,5 @@ > 5ee28414fe580928907527d9e4217845 *CHANGELOG > -4aae74779d3a1de0fdc64beec22078ee *DESCRIPTION > +fe0f10b7f193e91112c978228acaa5ae *DESCRIPTION > 41b1dde3a37014e3c2c5fa208fc47167 *NAMESPACE > f9a81f720aebf5398a94efa32a2047a5 *R/AAA.R > e8b6adbe6a0b2cf61f433762e1fd16dd *R/arff.R > > It looks like such updates to existing tarballs cause troubles > downstream (e.g. EasyBuild). Although these updates are minor (in a > functional sense), it does mean that we cannot guarantee that everyone > gets identical installs. > > /Henrik > On Wed, Jun 27, 2018 at 7:03 AM Joris Meys wrote: > > > > Correction: In the case of mgcv it was the publication date that changed > > for some reason. Our sysadmins keep reaching out to me in the hope to > > resolve this. Is there a way they can reach out so this can be clarified? > > > > For reference, the latest issue on mgcv : > > https://github.com/easybuilders/easybuild-easyconfigs/issues/6501 > > > > Cheers > > Joris > > > > On Wed, Jun 27, 2018 at 3:30 PM, Joris Meys wrote: > > > > > Dear Uwe, > > > > > > sorry to bother you again with it, but I was wondering if you had some > > > more idea about what happened. I just received another one, this time > about > > > mgcv_1.8-23.tar.gz. It goes beyond my understanding as to why the MD5 > sums > > > would change without any change to the package. Is there anything I can > > > check at this side to make it easier for you? > > > > > > Cheers > > > Joris > > > > > > On Thu, Jun 14, 2018 at 6:55 PM, Joris Meys > wrote: > > > > > >> Dear Uwe, > > >> > > >> Thank you for willing to take a look. In the report it was about the > > >> following tarballs : > > >> > > >> pkgmaker_0.22.tar.gz > > >> rngtools_1.2.4.tar.gz > > >> RcppProgress_0.4.tar.gz > > >> > > >> Our sysadmin tried diff -ru, but couldn't find any difference in the > text > > >> files. > > >> > > >> Cheers > > >> Joris > > >> > > >> On Thu, Jun 14, 2018 at 5:46 PM, Uwe Ligges < > > >> lig...@statistik.tu-dortmund.de> wrote: > > >> > > >>> > > >>> > > >>> On 13.06.2018 15:40, Joris Meys wrote: > > >>> > > >>>> > > >>>> > > >>>> On Wed, Jun 13, 2018 at 3:16 PM, Uwe Ligges < > > >>>> lig...@sta
Re: [R-pkg-devel] Weird error on CRAN linux check
On Wed, Jul 4, 2018 at 4:22 PM, Hadley Wickham wrote:
> I don't think it's related to the error, but you shouldn't be exporting
> this:
>
> export("align<-.huxtable")
>
> You should generally only export the method.
>
Hadley means to say that you should generally only export the generic, not
the individual methods.
More information here:
https://cran.r-project.org/doc/manuals/R-exts.html#Registering-S3-methods
Cheers
Joris
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Weird error on CRAN linux check
I just took a look at your repo, and two remarks:
- you use roxygen, and used both @export and @S3method. The latter one is
deprecated, so you should use only @export, or @method (see eg Hadley's
answer here : https://github.com/klutometis/roxygen/issues/741 )
- You're using some code in attributes.R that should generate all the
getters and setters automatically, but it looks as if these objects aren't
generated in the right order/environment/... to be registered correctly.
The part where I get confused, is the following. After installing:
> ht <- huxtable(a = 1:3, b = 1:3)
> align(ht)
Error in UseMethod("align") :
no applicable method for 'align' applied to an object of class
"c('huxtable', 'data.frame')"
> methods(align)
[1] align.huxtable*
see '?methods' for accessing help and source code
> getFromNamespace("align.huxtable","huxtable")
function (ht)
attr(ht, "align")
The last line is what bothers me. That should be
, like this:
> environment(huxtable)
So you generate the functions, they somehow get registered but they get
created in the wrong environment as far as I can tell. That's where I would
start looking.
CHeers
Joris
On Wed, Jul 4, 2018 at 8:12 PM, David Hugh-Jones
wrote:
> I figured that. Actually I just tried this. I now get the interesting
> result that all calls to a generic fail with the UseMethod error...?
>
> On Wed, 4 Jul 2018 at 16:12, Joris Meys wrote:
>
>> On Wed, Jul 4, 2018 at 4:22 PM, Hadley Wickham
>> wrote:
>>
>>> I don't think it's related to the error, but you shouldn't be exporting
>>> this:
>>>
>>> export("align<-.huxtable")
>>>
>>> You should generally only export the method.
>>>
>>
>> Hadley means to say that you should generally only export the generic,
>> not the individual methods.
>> More information here:
>>
>> https://cran.r-project.org/doc/manuals/R-exts.html#Registering-S3-methods
>>
>> Cheers
>> Joris
>> --
>> Joris Meys
>> Statistical consultant
>>
>> Department of Data Analysis and Mathematical Modelling
>> Ghent University
>> Coupure Links 653, B-9000 Gent (Belgium)
>>
>> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
>>
>> tel: +32 (0)9 264 61 79
>> ---
>> Biowiskundedagen 2017-2018
>> http://www.biowiskundedagen.ugent.be/
>>
>> ---
>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>
> --
> Sent from Gmail Mobile
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Weird error on CRAN linux check
On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch wrote: > > That shouldn't matter. That function was created in a local environment > whose parent is (probably by the > huxtable:::make_setter_getters function, but I didn't check). > > Duncan Murdoch > > I would think it does matter. Methods are found on the search path, but the environment where the methods are defined is not on the search path. It's a child environment of the namespace, and hence cannot be reached from either the global environment or the namespace if I understood it correctly. Cheers Joris -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Weird error on CRAN linux check
I see that you realized it was Inaki who gave you he patch, not me :-)
I've been looking into this further, and the toy example David put up is
actually not the right one to look at. In that example the generic is
created in the namespace. But in the original huxtable that was not the
case. Try the following :
foo.barrista <- function(x, ...){
cat("In barrista\n")
}
make_a_method <- function (x){
assign("foo", function(x, ...){
UseMethod("foo")
} ,envir = getNamespace('testMethod'))
assign("foo.bar", function (x, ...) cat("In foo.bar"),
envir = getNamespace('testMethod'))
}
make_a_method()
With a namespace:
S3method(foo,bar)
S3method(foo,barrista)
export(foo)
And test code :
thebar <- structure(1, class = c("bar", "data.frame"))
thebarrista <- structure(1, class = "barrista")
foo(thebarrista)
foo(thebar)
In both cases the correct method cannot be found. When the methods are both
exported and registered (i.e. add export(foo.bar) and export(foo.barrista)
to NAMESPACE), everything goes fine again on Windows.I went back to the
original version you sent to CRAN, and that doesn't cause any problems on
Windows either. So when the methods are exported and registered, the
problem apparently only exists on Linux.
The other thing I've noticed, is that align() is called from within the
function huxtable() without problem. So the method is found when the
generic is called by a function in the namespace, but not when the generic
is called from the global env. The patch of Inaki makes sure that the
_generic_ is assigned in the namespace itself instead of a child
environment.
To the previous minimal example, add:
baz <- function(x) foo(x)
and to the NAMESPACE:
export(baz)
If you try now:
baz(thebar)
baz(thebarrista)
the correct methods are found. But foo(thebar) etc still doesn't find the
correct ones.
On a sidenote: roxygen is really not helping here. @export literally
exports all these methods as they're not recognized as S3methods. So here
you actually need the deprecated tag @S3method. I wish Hadley would revert
the deprecation, as @export fails to recognize S3 methods correctly in
other cases as well.
On Thu, Jul 5, 2018 at 1:19 PM, Duncan Murdoch
wrote:
> On 05/07/2018 5:22 AM, David Hugh-Jones wrote:
>
>>
>> Wow, this is extremely helpful. I've applied Joris' patch. By the way,
>> the github master has the change that I stopped exporting methods, as per
>> Hadley's suggestion; this caused *all* functions created via
>> make_getter_setters to fail. Version 4.0.1 on CRAN has the methods
>> exported, which was masking the error in most cases. I don't know why
>> bold() was failing in certain cases only... in any case, the patch seems to
>> fix things.
>>
>>
> That's a roxygen2 bug or misuse. If you use the code below without the
> roxygen2 processing, and manually build the NAMESPACE file as
>
> export(foo)
> S3method(foo, bar)
>
> then things are fine. I don't know roxygen2 well enough to know what else
> you should have done to get your NAMESPACE file to look like that.
>
> Duncan Murdoch
>
>
> Here is a brief test case that shows the original problem. I don't know
>> whether this reveals any problem in base R:
>>
>> # in package mypackage:
>> #' @export
>> foo <- function (x, ...) UseMethod('foo')
>> make_a_method <- function () assign("foo.bar", function (x, ...) cat("In
>> foo.bar"), pos = getNamespace('mypackage'))
>> make_a_method()
>>
>> # in the console:
>> library(mypackage)
>> mypackage:::foo.bar
>> ## function (x, ...) cat("In foo.bar")
>> ##
>> ##
>> x <- structure(1, class='bar')
>> foo(x)
>> ## Error in UseMethod("foo") :
>> ## no applicable method for 'foo' applied to an object of class "bar"
>>
>> Also, I know I shouldn't be using @s3method ... it's on the TODO list... !
>>
>> Cheers,
>> David
>>
>>
>> On Thu, 5 Jul 2018 at 09:07, Iñaki Úcar > i.uca...@gmail.com>> wrote:
>>
>> El mié., 4 jul. 2018 a las 22:47, Duncan Murdoch
>> (mailto:murdoch.dun...@gmail.com>>)
>> escribió:
>> >
>> > On 04/07/2018 4:04 PM, Joris Meys wrote:
>> > >
>> > >
>> > > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch
>> mailto:murdoch.dun...@gmail.com>
>> > > <mailto:murdoch.dun...@gmail.com
>>
>> <mailto:murdoch.dun...@gmail.com>>> wrote:
&g
Re: [R-pkg-devel] Weird error on CRAN linux check
For the record: I've checked this in R 3.5.0 and R 3.4.4, and in both cases
this problem exists.
Also, I need to correct myself: The correct way to document with roxygen is
to use _both_ the @method and @export tag:
@method foo bar
@export
That registers the S3 method correctly (and hence doesn't export the method
itself).
On Thu, Jul 5, 2018 at 4:18 PM, Joris Meys wrote:
> I see that you realized it was Inaki who gave you he patch, not me :-)
>
> I've been looking into this further, and the toy example David put up is
> actually not the right one to look at. In that example the generic is
> created in the namespace. But in the original huxtable that was not the
> case. Try the following :
>
> foo.barrista <- function(x, ...){
> cat("In barrista\n")
> }
>
> make_a_method <- function (x){
> assign("foo", function(x, ...){
> UseMethod("foo")
> } ,envir = getNamespace('testMethod'))
>
> assign("foo.bar", function (x, ...) cat("In foo.bar"),
> envir = getNamespace('testMethod'))
> }
> make_a_method()
>
> With a namespace:
>
> S3method(foo,bar)
> S3method(foo,barrista)
> export(foo)
>
> And test code :
>
> thebar <- structure(1, class = c("bar", "data.frame"))
> thebarrista <- structure(1, class = "barrista")
>
> foo(thebarrista)
> foo(thebar)
>
> In both cases the correct method cannot be found. When the methods are
> both exported and registered (i.e. add export(foo.bar) and
> export(foo.barrista) to NAMESPACE), everything goes fine again on Windows.I
> went back to the original version you sent to CRAN, and that doesn't cause
> any problems on Windows either. So when the methods are exported and
> registered, the problem apparently only exists on Linux.
>
> The other thing I've noticed, is that align() is called from within the
> function huxtable() without problem. So the method is found when the
> generic is called by a function in the namespace, but not when the generic
> is called from the global env. The patch of Inaki makes sure that the
> _generic_ is assigned in the namespace itself instead of a child
> environment.
>
> To the previous minimal example, add:
>
> baz <- function(x) foo(x)
>
> and to the NAMESPACE:
>
> export(baz)
>
> If you try now:
>
> baz(thebar)
> baz(thebarrista)
>
> the correct methods are found. But foo(thebar) etc still doesn't find the
> correct ones.
>
> On a sidenote: roxygen is really not helping here. @export literally
> exports all these methods as they're not recognized as S3methods. So here
> you actually need the deprecated tag @S3method. I wish Hadley would revert
> the deprecation, as @export fails to recognize S3 methods correctly in
> other cases as well.
>
>
> On Thu, Jul 5, 2018 at 1:19 PM, Duncan Murdoch
> wrote:
>
>> On 05/07/2018 5:22 AM, David Hugh-Jones wrote:
>>
>>>
>>> Wow, this is extremely helpful. I've applied Joris' patch. By the way,
>>> the github master has the change that I stopped exporting methods, as per
>>> Hadley's suggestion; this caused *all* functions created via
>>> make_getter_setters to fail. Version 4.0.1 on CRAN has the methods
>>> exported, which was masking the error in most cases. I don't know why
>>> bold() was failing in certain cases only... in any case, the patch seems to
>>> fix things.
>>>
>>>
>> That's a roxygen2 bug or misuse. If you use the code below without the
>> roxygen2 processing, and manually build the NAMESPACE file as
>>
>> export(foo)
>> S3method(foo, bar)
>>
>> then things are fine. I don't know roxygen2 well enough to know what
>> else you should have done to get your NAMESPACE file to look like that.
>>
>> Duncan Murdoch
>>
>>
>> Here is a brief test case that shows the original problem. I don't know
>>> whether this reveals any problem in base R:
>>>
>>> # in package mypackage:
>>> #' @export
>>> foo <- function (x, ...) UseMethod('foo')
>>> make_a_method <- function () assign("foo.bar", function (x, ...) cat("In
>>> foo.bar"), pos = getNamespace('mypackage'))
>>> make_a_method()
>>>
>>> # in the console:
>>> library(mypackage)
>>> mypackage:::foo.bar
>>> ## function (x, ...) cat("In foo.bar")
>>> ##
>>> ##
>>> x <- structure(1, class='bar')
>>> foo(x)
&g
Re: [R-pkg-devel] Proper way to document helper functions not accessible by user.
Hi Barry, could you specify wh osked you to provide examples? R CHECK doesn't give me any warnings. If it was asked by the people of CRAN itself, you can explain that these are internal functions and the help pages are only there for reference to advanced users. But I'm not sure if they'll accept that. So here's a few things you can do: 1. Remove the roxygen comment tag and just use #. The info stays in the code file, but no help pages are generated for these functions. Do notify CRAN when resubmitting that you removed these help files as these are all internal functions. 2. Just add the most basic 1-line example to the help page to satisfy CRAN's request. Personally I more often use the second option, mainly to aid myself and make it easier for people to understand how the code base works. But that's personal flavour. Cheers Joris On Mon, Aug 13, 2018 at 3:09 PM Eggleston, Barry wrote: > Hello, > > I am working through my first submission and making good progress with the > CRAN review system, but now I need to understand the best practice for > dealing with helper functions. I am building a package that only exports > 12 functions for direct user access, but it has many helper functions not > directly accessible to the user. In my R code I am using roxygen2 to write > my help pages. I have written roxygen2 notes to create help pages for > every function, but for all the helper functions I am using the keyword > 'internal' so they don't show up in the index of help pages and available > functions. In future releases I may export these functions for direct > access, but for now I want to keep them internal. Within each help page of > these non-accessible helper functions, I have placed '#None' in the > @examples section, since nobody will be able to call the functions > directly. In my submission review I was asked to give examples for these > functions, because my package still has the .Rd files f > or these helper functions in the submitted .tar.gz file. How do I proper > handle documentation of these helper functions? Can I remove the roxygen2 > notes that create the .Rd files for these helper functions, so the package > does not contain .Rd files for them? > > Thanks, > Barry > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Help
Hi Rhys, the notes are quite clear: your examples are running too long. That's easily avoided by using smaller data or limiting the amount of non-necessary operations in the examples. For the rest is looks OK to me. Best thing you can do now is fix the examples so they don't run as long, and resubmit. As explained in the CRAN policies, you can use the webform again and add a note in the optional comment field explaining how you solved the issue. If the examples are already minimal, mail to the CRAN team ( cran-submissi...@r-project.org ) and explain why it is not possible to cut down in the runtime of the examples. But imho you better do the effort of cutting the examples down a bit. More info on resubmission : https://cran.r-project.org/web/packages/policies.html#Re_002dsubmission Hope this helps Cheers Joris On Fri, Sep 21, 2018 at 2:16 PM Rhys D Munden wrote: > Hi, > received the below email about uploading a package, but I'm not sure how to > solve these problems. > Thanks > > Rhys > > > > > > Dear maintainer, > > package SitesInterest_1.0.tar.gz does not pass the incoming checks > automatically, please see the following pre-tests: > Windows: < > > https://win-builder.r-project.org/incoming_pretest/SitesInterest_1.0_20180921_110843/Windows/00check.log > > > Status: 3 NOTEs > Debian: < > > https://win-builder.r-project.org/incoming_pretest/SitesInterest_1.0_20180921_110843/Debian/00check.log > > > Status: 2 NOTEs > > > > Please fix all problems and resubmit a fixed version via the webform. > If you are not sure how to fix the problems shown, please ask for help on > the R-package-devel mailing list: > <https://stat.ethz.ch/mailman/listinfo/r-package-devel> > If you are fairly certain the rejection is a false positive, please > reply-all to this message and explain. > > More details are given in the directory: > < > > https://win-builder.r-project.org/incoming_pretest/SitesInterest_1.0_20180921_110843/ > > > The files will be removed after roughly 7 days. > > No strong reverse dependencies to be checked. > > Best regards, > CRAN teams' auto-check service > Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64 > Check: CRAN incoming feasibility, Result: NOTE > Maintainer: 'Rhys Munden ' > > New submission > > Flavor: r-devel-windows-ix86+x86_64 > Check: running examples for arch 'i386', Result: NOTE > Examples with CPU or elapsed time > 10s >user system elapsed > plot_radii_results 65.03 1.85 67.40 > print_colour_assignment 62.57 1.67 64.18 > plot.hoops 28.10 0.22 28.48 > plot.schematic 27.91 0.33 28.54 > plot_bars_and_hoops 27.50 0.20 27.97 > plot_bar_chart 11.79 0.16 12.16 > Alt_Alg 11.30 0.17 11.49 > print_site_visits 11.15 0.11 11.32 > Sites 11.09 0.14 11.26 > print_sites_pos 11.00 0.13 11.25 > > Flavor: r-devel-windows-ix86+x86_64 > Check: running examples for arch 'x64', Result: NOTE > Examples with CPU or elapsed time > 10s >user system elapsed > plot_radii_results 72.07 2.03 74.27 > print_colour_assignment 71.87 1.67 74.10 > plot_bars_and_hoops 31.25 0.20 31.48 > plot.schematic 30.73 0.30 31.24 > plot.hoops 30.51 0.14 30.72 > Sites 13.12 0.05 13.19 > plot_bar_chart 12.87 0.20 13.09 > print_sites_pos 12.76 0.18 12.85 > Alt_Alg 12.37 0.14 12.48 > print_site_visits 12.20 0.15 12.42 > > Flavor: r-devel-windows-ix86+x86_64 > Check: Overall checktime, Result: NOTE > Overall checktime 11 min > 10 min > > Flavor: r-devel-linux-x86_64-debian-gcc > Check: examples, Result: NOTE > Examples with CPU or elapsed time > 10s > user system elapsed > plot_radii_results 34.112 2.036 36.148 > print_colour_assignment 33.912 2.016 35.932 > plot.hoops 14.900 0.200 15.100 > plot.schematic 14.316 0.292 14.608 > plot_bars_and_hoops 14.248 0.288 14.537 > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgi
Re: [R-pkg-devel] CRAN Non-Triviality Requirement
Hi Thomas, I would argue that one dataset - even a new one - could be added to another package. The pizzapoll doesn't look like a scientific breakthrough, but it might be a nice dataset for teaching and/or testing new models. So I see value in making it available on CRAN one way or another. If you would consider adding your data to another package, there's a list of fairly recent packages on this link: https://rviews.rstudio.com/2017/11/01/r-data-packages/ But I have to be honest as well. CRAN now contains not one but two packages with ... Chuck Norris quotes. Nothing else. Just Chuck Norris quotes. Both published this year btw. https://cran.r-project.org/package=norris https://cran.r-project.org/package=roundhouse There's also the "non-trivial" package cowsay that lets animals tell you the error messages etc. https://cran.r-project.org/package=cowsay Or what do you think of the rfoaas package, that provides you F***k off as a service? https://cran.r-project.org/package=rfoaas Plenty of other examples of totally bonker packages with absolutely no use whatsoever even remotely related to something close to scientific. So that CRAN policy looks pretty meaningless to me. I'd say: go ahead. If all that garbage can be on CRAN, there's plenty of room there for a nice dataset about a pizzapoll. Cheers Joris PS: Yes, this is a frustration of mine, as I try to make my contributions worthwhile and teach my students the same. And I hate it when said students then come back at me with "but what about this package?". If a policy is not enforced, then why bother installing it in the first place? On Wed, Sep 26, 2018 at 12:20 PM Thomas Levine <_...@thomaslevine.com> wrote: > I want to publish a single dataset, and I am concerned about part of the > CRAN policies. The preamble of the policies [1] says, > > > A package's contribution has to be non-trivial > > The single dataset [2, 3] is recent and not very widely known. > Is it considered trivial? > > If so, what would be a good way to publish the dataset? For example, > is there a package for contributed datasets, akin to datasets in base? > > [1] https://cran.r-project.org/web/packages/policies.html > [2] https://thomaslevine.com/scm/pizzapoll > [3] https://thomaslevine.com/scm/pizzapoll/uv/pizzapoll_2018.9.10.tar.gz > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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 halts on @example in shiny::runApp()
Hi Lindsay,
this is normal and to be expected, as shiny blocks R and shifts focus to
the browser. This only makes sense in interactive modus, as your app needs
input from a user before it does anything.
So for your shiny examples, you always have to use \dontrun{}.
Cheers
Joris
On Mon, Nov 19, 2018 at 3:14 PM L Rutter
wrote:
> Hello all:
>
> R CMD check does not complete for my package and halts at the line "*
> checking examples ..." I suspect the halting is due to @examples
> hanging in certain R/foo.R files, where shiny::runApp() is called for
> a shiny app located in a separate directory in this type of format:
>
> appDir <- system.file("shiny-examples", "plotLitreApp", package =
> "bigPint")
> shiny::runApp(appDir, display.mode = "normal")
>
> I suspect this is the problem because I previously had \dontrun{}
> around my @examples that used shiny apps and R CMD check worked fine.
> When I run the example code for these shiny apps directly into R, the
> shiny app works no problem. An example of one such R/foo.R file
> causing this hanging problem is located in the developing package at:
>
> https://github.com/lrutter/bigPint/blob/master/R/plotLitreApp.R
>
> Any advice on how to successfully use the @examples for this script
> and not halt R CMD check would be much appreciated!
>
> Thank you!...
> Lindsay
>
> ______
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Dependencies in DESCRIPTION: Imports vs. Suggests
Dear Paul,
the correct form is something like:
if( requireNamespace("abind", quietly = TRUE) )
{ abind::foo() # do sth with abind} else {
message("you need to install the pkg abind for this example")
}
In general you should avoid sending out code that installs packages. Some
people work with specific versions of packages and don't want them
overwritten by a call to install.packages(). Others use specific libraries
on their computer instead of the default. The CRAN requirements are there
to protect people from unexpected changes to their setup.
Cheers
Joris
On Mon, Nov 19, 2018 at 9:04 PM Paul Hargarten
wrote:
> Hi all,
>
> I am relatively new in creating R packages. I have created a new package
> called *"foo"* and submitted it to CRAN for review.
> I am wondering the difference between "Imports" and "Suggests" dependencies
> in DESCRIPTION file. According to my understanding, the "Imports" field
> contains all packages required for my functions to work; the "suggests"
> field contains packages that* foo* uses but doesn't require them.
> Programmers
> place these suggested packages to run examples, to run tests, and build
> vignettes, according to Hadley Wickham (also see
> <http://r-pkgs.had.co.nz/description.html
> <http://r-pkgs.had.co.nz/description.html> >). I think that this field
> exists to limit the user the burden of downloading extra packages.
>
> As suggested packages are not installed, I should add the following line in
> examples that use this package. For instance,* abind* was listed as a
> suggested package for *foo;* so I should add this line anywhere before I
> use any functions in *abind. *
> * > if( !requireNamespace("abind", quietly = TRUE) )
> { install.packages("abind")}*
>
> But I got an error from CRAN that I should not install packages in the
> examples. I suppose that these packages should be in the "Import" field in
> DESCRIPTION file. But, I am confused why that would be the case given that
> these packages were used in the examples only and not in any functions in
> *foo. *
>
> Thus, I am wondering how you decide which packages are suggested compared
> to
> imported.
>
>
> --
> Paul Hargarten, M.S.
> PhD Candidate
> Biostatistics, VCU School of Medicine
> Biochemistry and Molecular Biology, B.S.; Chemistry, B.A. ; Mathematics,
> minor
> hargart...@vcu.edu
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[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] Cannot reproduce errors for an already-accepted package
Hi David, all errors I see go back to scalaConnect(). As far as I could judge, on CRAN this function doesn't return a TRUE or FALSE but a missing value for some reason. As apparently all the failing tests need to call that function, none of those can exit correctly. Why this works on rhub or win-builder but not on CRAN is beyond me. Cheers Joris On Fri, Nov 30, 2018 at 5:36 PM David B. Dahl wrote: > I am having a hard time reproducing errors in Windows that CRAN finds on my > already-accepted rscala package. Details of the ERROR's are here: > > https://cran.r-project.org/web/checks/check_results_rscala.html > > In particular, CRAN's Windows check fails on tests written using the > testthat package. > > Unfortunately, I cannot reproduce the errors on any of the following > platforms: > > + My Windows 10 test machine running R 3.5.1. > + The win-builder service (https://win-builder.r-project.org/) > + The rhub service (https://github.com/r-hub/rhub) > > Does anyone have advice on how to reproduce the errors? Thanks. > > -- David > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Can I put my small data-sets into one .rda file in my CRAN package?
Hi Michael, in the data() function you have to use the name of the rda file, not the name of the dataset you need. So say you have the datasets validity and data2 in a file called alldata.rda, you need to do: data(alldata) and that will make both validity and data2 available to the user. imho it only makes sense to combine data in one .rda file when they're also related (for example an dataset with species and the similarity matrix for those species). Hope this helps Cheers Joris On Wed, Dec 5, 2018 at 4:19 PM Michael Dewey wrote: > At the moment my package (metap) has a number of small data-sets each as > a separate .rda file. It works fine. I thought it would be neater to put > them all into one file which I called data.rda (original choice of name > there). > > Now when I do R CMD build metap > it fails when trying to build the vignette when that executes > data(validity) > where validity is contained in data.rda. > > I cannot find anything in writing R extensions which explicitly forbids > this but equally nothing which explicitly permits it. Am I missing > something? Obviously this is not an important problem and as the title > says the solution should work on CRAN too. > > -- > Michael > http://www.dewey.myzen.co.uk/home.html > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] shadowing a method from the stats package
Hi, technically you don't need permission for this. You only need permission if you tamper with the namespace of the stats package, which you don't. You just hide a function from another package, which is rather common actually (eg dplyr::lag() and stats::lag() ). Then again, I'm not sure this will always work, as you rely heavily on the search path for your function to be found before the one in stats. I would be interested as well in hearing how this can be solved in a more robust way, but I can't really come up with something myself. Interesting problem! Cheers Joris On Fri, Jan 11, 2019 at 10:14 PM wrote: > Hello, > > I created a package for working with a new probability > distribution called unifed. The source code can be found at > https://gitlab.com/oquijano/unifed . > > This distribution is suitable for GLMs. I have included a a > function called unifed in the package that returns a family that can > be used with the glm function. > > For a unifed glm, it is necessary for the dispersion parameter to > be equal to one. The summary method of the glm class does this > automatically for the poisson and binomial distributions and I would > like the same for the unifed. In order to achieve this, I am > including a summary.glm function in the package so it shadows > stats::summary.glm when the package is attached. This function is > actually just a wrapper around stats::summary.glm. It simply checks > if the family is unifed; If this is the case it calls > stats::summary.glm with dispersion=1 and otherwise it simply calls > stats::summary.glm with the same parameters. Therefore introducing > this in the namespace does not break or change the behavior of any > existing code that uses summary.glm > > According to the CRAN policies I need permission from the > maintainer of the package for doing this. The maintainer of the package > is the R core team. To whom should I write to ask for this permission? > Otherwise is there a different way in which I could achieve the right > default behavior and respect the CRAN policies? > > > Thank you for your time. > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] submitting to github
Hi Troels,
origin: none means that git created a local repository but didn't link it
to a github account yet. If you're not that familiar with git, I suggest
you take a look at Github Desktop. We use that with our students, and even
I still use it sometimes. Github Desktop allows you to publish a local
repository to github with one click. You just have to set your credentials
after installing.
More info on adding a remote through shell :
https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/
More info on Github Desktop : https://desktop.github.com/
Hope this helps
Cheers
Joris
On Fri, Jan 25, 2019 at 10:22 AM Troels Ring wrote:
> Hi Stefan – thanks for the question: I have a newly developed package
> which I need to have on github for a publication. So, while there still a
> minor problems in the package as it is, I started to trying to interact
> with github so really I am trying to put a working package onto github.
>
> All best
>
> Troels
>
>
>
> Fra: Stefan McKinnon Høj-Edwards
> Sendt: 25. januar 2019 09:59
> Til: Troels Ring ; package-develop <
> r-package-devel@r-project.org>
> Emne: Re: [R-pkg-devel] submitting to github
>
>
>
> Hej Troels,
>
>
>
> What exactly are you trying to acheive here? I.e., are you trying to 1)
> put a new project onto github, or 2) copy a repository on github to your
> local computer, or 3) do as 2) and then update it your current
> modifications?
>
>
>
>
> Stefan McKinnon Høj-Edwards
>
> Mobile: (+45) 2888 6598
>
>
>
>
>
> Den fre. 25. jan. 2019 kl. 09.51 skrev Troels Ring <mailto:tr...@gvdnet.dk> >:
>
> Dear friends - I'm sorry to bother but seem to be unable to interact
> constructively with github.
>
>
>
> I try to follow the instructions from Hadley (thanks) - i.e. I have a
> small trial-project which functions well. Since I have tried many times I
> start from shell with
>
> rm -rf .git
>
> and then select version control using git (tools, project options,git/svn)
> -
> and origin is still marked as "none" after restarting RStudio.
>
> Then from shell again: git init
>
> Yielding
>
> Initialized empty Git repository in
> C:/Users/Troels/Dropbox/Rown/ABCharge/.git/
>
> Rstudio restarted, package reopened: origin still "none"
>
> Git panel appears OK.
>
>
>
> Now from github: add new repository (non present after prior deletions!)
>
> Named as package name - repeated in description - repository created
>
>
>
> Shell opened from RStudio
>
> git remote add origin https://github.com/troelsring/ABCharge.git - works
> without problems - an origin seems correctly accepted in RStudio - but
> then:
>
> git push -u origin master - results in:
>
>
>
> error: src refspec master does not match any.
>
> error: failed to push some refs to
> 'https://github.com/troelsring/ABCharge.git' below in red
>
>
>
> I seem (also!) to have problems with the SSH keys - Rstudio marks that I
> have a key in c:/Users/Troels/.ssh/id_rsa -
>
> but when I run file.exists("~/.ssh/id_rsa.pub")
> [1] FALSE - Is returned - but that is not the issue I guess? I have anyway
> made a public key as suggested.
>
> I have spent hours seeking on the many pages for explanation for this
> probably simple problem.
> All best
> Troels
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN submission examples don't run
Dear Timothy,
Uwe meant to include that code in the _examples_, not in your actual
functions. Whenever an example is expected to open a web page, use
if(interactive()) to avoid it from being run by the test infrastructure.
On a sidenote: It would make sense to add this as a first check to
functions which can only work when called interactively. That's up to you.
However, beware of errors created when the function is not run
interactively, as this would also cause your examples to give errors.
Cheers
Joris
On Tue, Mar 5, 2019 at 11:56 AM Horia Yeb wrote:
> Thank Uwe for the answer,
> But the purpose of the package is –when the input data is dealt with– open
> a .html page. Does that mean in my R code I should write :
> []
> if(interactive())
> {
> .Call(C++ code)
> }
> In my c++ code the interactive part is a*system(html_path);*is
> there an equivalent C++ condition to check if interactive?
>
> So either I protect the whole C++ function with the interactive check,
> either I protect the system() call?
>
> Thanks, Uwe for the interactive() function I'm new to R and don't know all
> the functions.
>
> Regards,
> Timothy
>
> On Tue, 5 Mar 2019 at 11:35, Uwe Ligges
> wrote:
>
> > Apparently your checks wait for the brower beeing closed.
> >
> > Do not expect interactions in the examples. Please only run non
> > interactive functionality in the examples and enclose ingteractice parts
> > within
> >
> > if(interactive()){
> >
> > ...}
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> > On 05.03.2019 11:10, Horia Yeb wrote:
> > > Hi all,
> > > I am still trying to submit my first package, I've corrected a few bibs
> > and
> > > bobs and submitted with running examples. On my computer running check
> > > --as-cran, the examples run perfectly, but on submission they don't
> seem
> > to
> > > run for some reason.
> > > Here is the return from submission, 3 NOTEs ( the first one is checking
> > > CRAN incoming feasibility ...) .
> > >
> > >
> > > [snipet]
> > >
> > > * checking compiled code ... OK
> > > * checking examples ...
> > > ** running examples for arch 'i386' ... [53m] NOTE
> > > Examples with CPU or elapsed time > 10s
> > > user system elapsed
> > > DataViz-package 0.05 0.02 1844.87
> > > throwchart 0.03 0.00 1319.79
> > > ** running examples for arch 'x64' ... [49m] NOTE
> > > Examples with CPU or elapsed time > 10s
> > > user system elapsed
> > > DataViz-package 0.03 0.00 1319.66
> > > throwchart 0.02 0.01 1619.35
> > > * checking PDF version of manual ... OK
> > > * DONE
> > > Status: 3 NOTEs
> > >
> > >
> > >
> > >
> > >
> > > So I think that the examples aren't running at all rather than taking
> 50m
> > > to run. The examples run an R function calling C++ function that
> > > systematically opens an .html file in a browser. I could see this as a
> > > problem maybe?
> > >
> > > When looking at the pdfs in the package.check in examples the pdf file
> > > "Package-Ex" is empty/not working , could this be a reason for the
> > > malfunction? Or is it normal?
> > > Here is the report :
> > >
> >
> https://win-builder.r-project.org/incoming_pretest/DataViz_0.2_20190228_113204/Windows/00check.log
> > >
> > >
> > >
> > > Any help would be appreciated!
> > > Regards,
> > >
> > > Timothy
> > >
> > > [[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
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN student assistants
Dear Hadley,
given you're on the list of R foundation members, I rest assured you have
other channels to ask about the identity of new CRAN staff directly to
those responsible. Their names and paychecks are of no interest to the
general dev world. I can understand CRAN doesn't want to make these names
public, in order to avoid thousands of beginning devs mailing them directly
with questions that should be answered elsewhere.
I'd like to take a moment to thank CRAN for extending their workforce.
Given the increased workload, this was long overdue. I'm fully confident
the responsible CRAN maintainers made a thorough selection of competent
people. They're not known for their laissez-faire attitude.
I further note that:
1) the devoid package is on CRAN.
2) Where cat() is used in gargle, message() is a better option for the
following reason:
> myfun <- function(){cat("Yes");message("No")}
> suppressMessages(myfun())
Yes
This is how I train my students, but you're entitled to your own opinion
obviously. When the opinion of a dev differs from CRAN however, it's up to
them to argue with CRAN about why their vision is correct. A third party
public complaint seems to be the norm lately, but in our region such things
are generally frowned upon, as it's considered basic politeness to solve
differences with the people directly.
Finally, I'd like to point out that one can easily use the argument "repos"
in install.packages() to install from a different repository. So there's
absolutely no problem to have your own repo where you hire the people and
make the rules. That might save you a few emails to the dev lists.
I hope your ongoing problems with CRAN get resolved soon.
All the best.
Joris
On Tue, May 14, 2019 at 5:26 PM Hadley Wickham wrote:
> Hi all,
>
> Several people on my team have received responses to their CRAN
> submissions from new members of the CRAN team who appear to be student
> assistants (judging from their job titles: "Studentischer
> administrativer Mitarbeiter"). From the outside, they appear to be
> exercising editorial control[^1] and conducting design reviews[^2].
>
> CRAN is a critical piece of R community infrastructure, and I am sure
> these students have been surrounded by the proper checks and balances,
> but it's not obvious what their role is from the outside. I'd really
> appreciate knowing a little more about them:
>
> * Who are they?
>
> * Are they paid employees or volunteers?
>
> * What is their scope of work?
>
> * How are they trained?
>
> * If we believe that they have made a mistake, how do we request
> review from a senior CRAN member?
>
> * They appear to be able to apply additional discretionary criteria
> that are not included in R CMD check or documented in the CRAN policies.
> Is this true? If so, what is the scope of these additional checks?
>
> Hadley
>
> [^1]: The devoid package was rejected because the student assistant
> did not understand the purpose of the package.
>
> [^2]: The gargle package was rejected because the student assistant
> believed that the use of cat() was incorrect. It was not.
>
> --
> http://hadley.nz
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
Joris Meys
Statistical consultant
Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN student assistants
Dear Hadley,
a follow up mail: You know who they are. Your organisation has the policy
to add all email correspondence with CRAN to the github repo.
https://github.com/r-lib/gargle/tree/master/cran-correspondence
That's how I now also found out who they are. One is a doctor. She has a
PhD. The mere fact you insinuate that this woman could be a student, is
disturbing. The other obtained an engineer degree in 2011, and is currently
obtaining a second one in Economics while working as a project assistant.
Also here I find it disturbing you question the competence of someone with
that experience, and who was selected by people known for their
thoroughness.
In light of this new information, I fail to understand why you even bother
asking for information you had already. I would appreciate if you would
stop gaslighting about CRAN and show those ladies the respect they deserve.
Kind regards
Joris
On Wed, May 15, 2019 at 11:06 AM Joris Meys wrote:
> Dear Hadley,
>
> given you're on the list of R foundation members, I rest assured you have
> other channels to ask about the identity of new CRAN staff directly to
> those responsible. Their names and paychecks are of no interest to the
> general dev world. I can understand CRAN doesn't want to make these names
> public, in order to avoid thousands of beginning devs mailing them directly
> with questions that should be answered elsewhere.
>
> I'd like to take a moment to thank CRAN for extending their workforce.
> Given the increased workload, this was long overdue. I'm fully confident
> the responsible CRAN maintainers made a thorough selection of competent
> people. They're not known for their laissez-faire attitude.
>
> I further note that:
>
> 1) the devoid package is on CRAN.
>
> 2) Where cat() is used in gargle, message() is a better option for the
> following reason:
>
> > myfun <- function(){cat("Yes");message("No")}
> > suppressMessages(myfun())
> Yes
>
> This is how I train my students, but you're entitled to your own opinion
> obviously. When the opinion of a dev differs from CRAN however, it's up to
> them to argue with CRAN about why their vision is correct. A third party
> public complaint seems to be the norm lately, but in our region such things
> are generally frowned upon, as it's considered basic politeness to solve
> differences with the people directly.
>
> Finally, I'd like to point out that one can easily use the argument
> "repos" in install.packages() to install from a different repository. So
> there's absolutely no problem to have your own repo where you hire the
> people and make the rules. That might save you a few emails to the dev
> lists.
>
> I hope your ongoing problems with CRAN get resolved soon.
> All the best.
>
> Joris
>
> On Tue, May 14, 2019 at 5:26 PM Hadley Wickham
> wrote:
>
>> Hi all,
>>
>> Several people on my team have received responses to their CRAN
>> submissions from new members of the CRAN team who appear to be student
>> assistants (judging from their job titles: "Studentischer
>> administrativer Mitarbeiter"). From the outside, they appear to be
>> exercising editorial control[^1] and conducting design reviews[^2].
>>
>> CRAN is a critical piece of R community infrastructure, and I am sure
>> these students have been surrounded by the proper checks and balances,
>> but it's not obvious what their role is from the outside. I'd really
>> appreciate knowing a little more about them:
>>
>> * Who are they?
>>
>> * Are they paid employees or volunteers?
>>
>> * What is their scope of work?
>>
>> * How are they trained?
>>
>> * If we believe that they have made a mistake, how do we request
>> review from a senior CRAN member?
>>
>> * They appear to be able to apply additional discretionary criteria
>> that are not included in R CMD check or documented in the CRAN policies.
>> Is this true? If so, what is the scope of these additional checks?
>>
>> Hadley
>>
>> [^1]: The devoid package was rejected because the student assistant
>> did not understand the purpose of the package.
>>
>> [^2]: The gargle package was rejected because the student assistant
>> believed that the use of cat() was incorrect. It was not.
>>
>> --
>> http://hadley.nz
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematica
Re: [R-pkg-devel] CRAN student assistants
On Thu, May 16, 2019 at 4:59 PM Hadley Wickham wrote: > Hi all, > > I am most interested in understanding what level of > discretion CRAN's "Studentischer administrativer Mitarbeiter" have to > critique the implementation of R packages Ing. is the german title for "Engineer". You made her name public in the repositories of your own organisation. So at least have the decency to google her before you question her competence in public. Your obvious lack of understanding about the Austrian education system is no excuse for questioning her competence. > I mean no disrespect towards the CRAN maintainers > The respectful thing to do, is to discuss this IN PRIVATE with Dr. Ligges at the next R foundation in case you really need to know. The unrespectful thing to do, is to gaslight on a public mailing list to the point you make others, like Alejandro, question the competence of CRAN maintainers. > > I do recognise that my question "Who are they?" may have been > perceived as overly intrusive. The word is "bewildering", as you know their names, and your organisation shared personally identifying information (i.e. her email address which includes the institute she WORKS for) on their github repo. > To clarify: I don't want to know names > or other personally identifying information, but I would like to know > in general terms how many there are, and what backgrounds they have. > That's again something you can ask Dr. Ligges IN PRIVATE at the next R foundation meeting, and not a subject for an open mailing list. And after this exchange, I would totally understand if he refuses to answer that. > Similarly, I don't want to know how much they are paid, just whether > or not they are volunteers or employees. > The budgetary arrangements between a university and their _employee_ are of no concern to the mailing list. Asking about such arrangements for an employee that's not yours, is considered highly impolite in Europe. RStudio has been very vocal on numerous occasions about standards they hold. I would appreciate if the chief scientist of RStudio abides by those standards. Thank you. -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Maintainer a Group
FWIW, at our department I'm the designated "maintainer" for most of the packages developed here. While I worked on quite a few of them, I'm not involved in all. We chose to do it this way exactly for the reasons mentioned in this thread, and out of respect for the wishes of CRAN. I'm not a researcher myself but officially "technical staff" (i.e. I have a fixed position at the uni and I'm not a professor). That makes me the "natural" responsible for following up on our packages. That said, people leaving the research department shouldn't be that much of a problem, as long as there's some system to keep track of packages developed. When that's in place, the package can be designated to another member of the research group and the information on CRAN can easily be updated. I don't think CRAN would object to that :-) It just requires the research group to stay aware of previous work. And that can sometimes be a challenge in itself... Cheers Joris On Tue, Jun 25, 2019 at 11:55 PM John Muschelli wrote: > So a single email is not a mailing list and it's a research group, so not > really a corporate entity. I don't see WHY explicitly this isn't allowed. > I understand that this decision has been made with a lot of thought in > mind, though. This would make it much easier for research groups to not > orphan packages because the maintainer/student leaves and we can't really > centralize our code bases. > > Best, > John > > > On Tue, Jun 25, 2019 at 5:48 PM Max Turgeon > wrote: > > > Hi John, > > > > "Writing R Extensions" is quite explicit about this: > > > > For a CRAN package it should be a *person*, not a mailing list and not a > > corporate entity > > > > Best, > > Max > > > > On Jun 25, 2019 3:45 PM, John Muschelli wrote: > > Dear Package Devs, > > Does anyone have any thoughts on whether a maintainer can be an > > organization/group instead of a person for CRAN? I don't see there being > > an issue as long as the "maintainer" is responsive and fixes issues. > Just > > figured I'd ask before trying this for some packages. > > > > Best, > > John > > > > [[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 > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] Require -package.Rd?
Dear Dr. Vichtbauer, I'm not a CRAN member, but I personally think this is a sensible requirement. I try to include those in every package myself, even if it's only to direct people to a vignette. That said, I do look for vignettes first when I encounter an unfamiliar package actually. That format gives more possibilities for giving a good introduction to the package imho. My humble 2 cents Cheers Joris On Tue, Sep 24, 2019 at 2:17 PM Viechtbauer, Wolfgang (SP) < wolfgang.viechtba...@maastrichtuniversity.nl> wrote: > Hi All, > > When starting to work with an unfamiliar package, one might typically look > for vignettes, a paper/book accompanying the package, a package website, > and of course the help files themselves, but > > help(package="") > > is often not so useful -- such a listing of functions (with titles) might > not clarify what the main 'workhorses' of the package are and how to get > started. Personally, the first thing I do is try: > > help() > > in the hopes that the package author(s) have created a > -package.Rd file to get new users started (or to point them to > appropriate places to get going). In my experience, if such a package help > file is available, it is tremendously useful. > > Unfortunately, many packages do not provide a -package.Rd file. I > am curious how others and CRAN members would feel about making this a > requirement (not retrospectively, but at least for new / resubmissions). > > Best, > Wolfgang > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> tel: +32 (0)9 264 61 79 --- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[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] compression of vignettes
Dear Mark,
You rely on external packages like rcmdcheck and devtools, so if you insist on
using those, you should contact the package authors.
The workflow as described in the manual :
https://cran.r-project.org/doc/manuals/R-exts.html#Checking-and-building-packages
is as follows :
R CMD build pkg --compact-vignettes
R CMD check pkg_x.y.z.tar.gz --as-cran
In a basic Travis script this can be used as:
script:
- R CMD build . --compact-vignettes=gs+qpdf
- R CMD check *tar.gz --as-cran
You find more information here :
https://towardsdatascience.com/travis-ci-for-r-advanced-guide-719cb2d9e0e5
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: R-package-devel on behalf of R.
Mark Sharp
Sent: Thursday, November 21, 2019 5:08 PM
To: R Package Devel
Subject: [R-pkg-devel] compression of vignettes
I have been unsuccessful with all of the following attempts to have compression
of dynamically generated vignettes during the build on travis-ci and within
RStudio. Help is appreciated.
I have tried the following travis-ci YAML to have vignettes compressed.
script:
- R -e 'r <- rcmdcheck::rcmdcheck(".", args = c('--no-manual'), build_args =
c('--compact-vignettes=both'); devtools::test(); quit(save = "no", status = if
(length(c(r$errors, r$warnings)) > 0) { 1 } else { 0 }, runLast = FALSE)'
script:
- R -e 'r <- rcmdcheck::rcmdcheck(".", args = c('--no-manual',
'--compact-vignettes=gs+qpdf'); devtools::test(); quit(save = "no", status = if
(length(c(r$errors, r$warnings)) > 0) { 1 } else { 0 }, runLast = FALSE)'
script:
- R -e 'r <- rcmdcheck::rcmdcheck(".", args = c('--no-manual',
'--compact-vignettes="gs+qpdf"'); devtools::test(); quit(save = "no", status =
if (length(c(r$errors, r$warnings)) > 0) { 1 } else { 0 }, runLast = FALSE)'
I have tried the following build arguments in RStudio
--as-cran --compact-vignettes=gs+qpdf
--as-cran --compact-vignettes=both
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
__
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] Possibly invalid URL note about canonical form of link to cran package
Dear all, I link in a vignette to the CRAN page of another package using the following form: https://cloud.r-project.org/package=kernlab<https://cloud.r-project.org/package=pkgname> I believed this was the correct way to do it, but I get following note in R CMD check --as-cran : Found the following (possibly) invalid URLs: URL: https://cloud.r-project.org/package=kernlab (moved to https://cloud.r-project.org/web/packages/kernlab/index.html) From: inst/doc/xnet_ShortIntroduction.html Status: 200 Message: OK CRAN URL not in canonical form Canonical CRAN.R-project.org URLs use https. So now I'm a bit confused. Aren't we supposed to use the canonical form as mentioned on every CRAN package page, or should I use cran.r-project.org specifically? I wanted to use cloud.r-project.org to limit traffic to the CRAN repo directly. Advice is appreciated, I'd like to submit this package before the holidays. 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 [[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] 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
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
Sent: Friday, January 10, 2020 2:17 PM
To: Joris Meys; 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
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
Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method
Hi Brian, I get what you want to do, but S3 isn't suited for that at all. If all elements in ... have to be the same class, you can use S4 (see ?dotsMethods). If not, then using S3 makes even less sense. Take following example: x <- list() y <- c(1,2) foo(x,y) will dispatch to foo.list() foo(y,x) will dispatch to foo.character() You'll be in a world of hurt if you want to maintain or update that code. If you insist on using S3, you'll have to fix the position (and hence the name) of the argument you want to dispatch on. my 2 cents 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: R-package-devel on behalf of Smith, Brian J Sent: Friday, January 17, 2020 4:59 PM To: Duncan Murdoch; r-package-devel@r-project.org Subject: Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method Thanks Duncan. I was surprised too when first realizing this was possible. I believe the reason it works is that UseMethod dispatches on the first supplied argument by default. So, really the dispatch is on the first element of the ellipsis. The 'c' function works like this, albeit as a primitive function. I would like to dispatch on the ellipsis to allow a user to name values being passed in. Defining an initial x argument would indeed eliminate the warning, but would not allow for user-naming of the value. I could have the user pass a list of values to x and do dispatching manually, but that seems like more steps for the user and more complication for the implementation than ought to be necessary. There are other downsides to that approach in my particularly application... The issue mentioned below about calling the function with no arguments can be solved by defining the following default method. foo.default <- function(...) list(...) __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method
umfff. foo(y,x) will dispatch to foo.numeric() obviously __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method
Hi Brian,
I agree that the way R CMD check reports on this, can be improved.
For your case (as far as I understand it), you can try dispatching explicitly
on the first element of the dots by using the object argument of UseMethod.
This works for me.
foo <- function(..., data){
UseMethod("foo", ..1)
}
foo.factor <- function(..., data){
x <- list(...)
x$data <- data
x
}
foo.formula <- function(..., data){
x <- list(...)
x$data <- data
x
}
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: Smith, Brian J
Sent: Friday, January 17, 2020 9:18 PM
To: Smith, Brian J; Joris Meys; Duncan Murdoch; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] [External] Re: S3 generic/method consistency
warning for formula method
I spoke too soon. dotsMethods will not work for me since it does not allow for
mixing of the ellipsis with other formal arguments. For example, the following
will not work if argument 'data' is not a formula; e.g. a data frame.
setGeneric("foo2", function(...) standardGeneric("foo2"))
setMethod("foo2", "formula",
function(..., data) list(...)
)
What is the recommended course of action if the validity of an R CMD check
warning is in doubt? In this case, the warning message indicates an
inconsistency that does not exist and references documentation that does not
seem to explain the actual issue.
-Original Message-
From: R-package-devel On Behalf Of
Smith, Brian J
Sent: Friday, January 17, 2020 11:45 AM
To: Joris Meys ; Duncan Murdoch
; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning
for formula method
Thanks for the tip about dotsMethods. I am mainly working with S4 objects in
my package, so that approach would fit well. The following S4 method seems to
work and pass R CMD checks.
setGeneric("foo2", function(...) standardGeneric("foo2"))
setMethod("foo2", "formula",
function(...) list(...)
)
In my actual implementation of S3 methods, I do check that all ... elements are
of the same class to avoid ending up in a world of hurt. Converting them to S4
methods will save me from having to do those checks - nice!
>From a language definition point of view though, I am still bothered that a
>check warning is triggered by the S3 formula method but not by others. That
>just seems inconsistent, and I have not yet seen any language documentation to
>explain the inconsistency. Are we sure this is not an issue with the R CMD
>check implementation?
Nevertheless, it looks like I have a way to get rid of the warning.
-Original Message-
From: Joris Meys
Sent: Friday, January 17, 2020 10:12 AM
To: Smith, Brian J ; Duncan Murdoch
; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning
for formula method
Hi Brian,
I get what you want to do, but S3 isn't suited for that at all. If all elements
in ... have to be the same class, you can use S4 (see ?dotsMethods). If not,
then using S3 makes even less sense. Take following example:
x <- list()
y <- c(1,2)
foo(x,y) will dispatch to foo.list()
foo(y,x) will dispatch to foo.character()
You'll be in a world of hurt if you want to maintain or update that code. If
you insist on using S3, you'll have to fix the position (and hence the name) of
the argument you want to dispatch on.
my 2 cents
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: R-package-devel on behalf of
Smith, Brian J
Sent: Friday, January 17, 2020 4:59 PM
To: Duncan Murdoch; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [External] Re: S3 generic/method consistency
warning for formula method
Thanks Duncan.
I was surprised too when first realizing this was possible. I believe the
reason it works is that UseMethod dispatches on the first supplied argument by
default. So, really the dispatch is on the first element of the ellipsis. The
'c' function works like this, albeit as a primitive function.
I would like to dispatch on the ellipsis to allow a user to name values being
passed in. Defining an initial x argument would indeed eliminate the warning,
but would not allow for user-naming of the value. I could have the user pass a
list of values to x and do dispatching manually, but that seems like more steps
for the u
Re: [R-pkg-devel] How to provide a finalized PDF file in a package?
Dear Neonira, as Thierry said, the inst folder serves that purpose. To be a bit more specific: any documentation you provide that doesn't need building, goes in the inst/doc folder. That's also where R CMD build creates the output of vignettes created with Sweave or knitr. You find more information in this section of the manual: https://cran.r-project.org/doc/manuals/R-exts.html#Writing-package-vignettes 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: R-package-devel on behalf of Thierry Onkelinx Sent: Tuesday, January 21, 2020 4:55 PM To: neonira Arinoem Cc: R-package-devel Subject: Re: [R-pkg-devel] How to provide a finalized PDF file in a package? Dear Neonira. Whatever file you place in the inst folder, will be available for the users when they install the package. Best regards, ir. Thierry Onkelinx Statisticus / Statistician Vlaamse Overheid / Government of Flanders INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND FOREST Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance thierry.onkel...@inbo.be Havenlaan 88 bus 73, 1000 Brussel www.inbo.be /// To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey /// <https://www.inbo.be> Op di 21 jan. 2020 om 16:50 schreef neonira Arinoem : > I create a cheat sheet using MS-OFFICE and converted it at a PDF format. > > I wonder in which folder of my package I should place it to be installed > with the package. > > I tried instinctively in vignettes, but it doesn't seem to work correctly, > as I do not find it back in my package installation folder. > > Best. > Neonira > > [[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-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Internet security software?
Hi Spencer, I've abandoned Bitdefender for the reason you give: it gave me too much trouble with false positives and seemingly random blocking of all kinds of tools at one point. But the reason is not Bitdefender in itself. It worked perfectly fine until the updates came for the Spectre and Meltdown vulnerabilities. Somehow these patches messed with the workings of Bitdefender, leading to the problems you describe. As Windows 7 is no longer maintained, these problems won't be solved. So first of all, you should abandon Windows 7. Even if it would work fine, it's a huge security risk. No point in having an antivirus if you run an OS that's no longer maintained. Either move to Windows 10 or change for a Linux distro (Ubuntu is imho the one Windows users find most easy to adapt to. Your mileage may vary). As for antivirus, I'm now using Kaspersky and am liking it so far (2 years now). I find it less intrusive than Bitdefender as well, even though I had no complaints in the past. 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 Spencer Graves Sent: Monday, February 24, 2020 10:49 PM To: List r-package-devel Subject: [R-pkg-devel] Internet security software? Hello, All: What antivirus / internet security software do you use and recommend? I've used Bitdefender for years. However, I've been encountering an increasing number of problems with software I've used for years. Some of my problems disappear when I turn off parts of Bitdefender. However, I've been unable to use RStudio on my Windows 7 computer since early last November. Also, when I turn off certain features of Bitdefender, "R CMD build sos" (with sos cloned from "https://github.com/sbgraves237/sos";) completes in a few minutes. With Bitdefender configured normally, "R CMD build sos" stops without warning on "* creating vignettes". I've left it for days like that without it moving beyond that point. No error message but also no progress. Rather than doing a web search for alternative internet security software, I thought I'd ask you all: If some of you have had similar problems with other antivirus / internet security software, I think I'd be more likely to hear it from you than from a web search. Some of my problems may not be due to Bitdefender, but I know that some are, and Bitdefender tech support answers the phone but fails to fix these problems. Thanks, Spencer Graves __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0
Hi Stefan,
first of all, thank you for taking the time and effort to link Julia and R.
That said, I would strongly encourage you to go for a reticulate-like approach.
There's a good reason for that. Once you start mixing languages, you really
want to have some indication what code is ran in what language. Especially
since I can imagine at one point there'll be a Julia function masking an R
function of the same name, and that is going to cause a world of hurt and
confusion.
If you don't like environments, you can try to use namespace functionality.
There's the "namespace" package that allows you to create one, and some
internal namespace functions are visible (eg namespaceExport() from base).
That's going to be the closest to mimicking R packages, but it's beyond my
knowledge to know how feasible this approach actually is. I hope someone else
chimes in, especially if this is dangerous for other reasons I overlooked.
Kind regards
Joris
Joris Meys
Statistician
T +32 9 264 61 79
Department Data Analysis and Mathematical Modelling
Campus Coupure, Block A 1st floor 110.050, Coupure links 653, B-9000 Ghent,
Belgium
T administration office +32 9 264 59 32
www.ugent.be
e-maildisclaimer
From: R-package-devel on behalf of
Stefan Lenz IMBI
Sent: Thursday, April 9, 2020 10:41 AM
To: Jeff Newmiller; r-package-devel@r-project.org; Duncan Murdoch
Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission
JuliaConnectoR 0.5.0
It is important for me to get my package into CRAN.
I haven't gotten any answer from the CRAN maintainers. I already tried to
submit a version of the package before some months and haven't gotten any reply
then.
The replies you gave me (thanks to all engaged in the discussion) were mixed.
I still think that the library-like import is a good feature, but if it is not
possible to get this package on CRAN with it, I will change it with returning
an environment like reticulate.
My question now is:
So what would be the process how to proceed?
Is there anybody who can make a decision in such cases?
Or do I make this decision myself after I lost hope that it will be accepted
the way it is now?
Stefan
ursprüngliche Nachricht-
Von: Jeff Newmiller [jdnew...@dcn.davis.ca.us]
An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de],
r-package-devel@r-project.org, Duncan Murdoch [murdoch.dun...@gmail.com]
Datum: Tue, 07 Apr 2020 09:52:52 -0700
-
> I did not say "interfere"... I said "problems with consistency". I don't think
> your wholesale import of functions without corresponding help pages is
> consistent with the normal use of R, which will make reading R code written
> with
> this mechanism in place a painful source of trouble for help forums.
>
> On the other hand, if the code is prefaced with an environment name then
> there will
> be no expectation that a help page should exist on the part of someone
> reading that
> code for the first time. (It will be no less obscure, but at least it won't be
> misleading.)
>
> On April 7, 2020 9:40:02 AM PDT, Stefan Lenz IMBI
> wrote:
>>Thank you very much for your comment.
>>Could you elaborate how you think that it could interfere with the help
>>system?
>>I haven't yet connected the Julia help with the R help, as the R help
>>system is quite complex and RStudio handles it again differently. So
>>it's simply like the functions were declared on the command line. They
>>have no help.
>>A simply way to print the help for a Julia function, e.g. the function
>>"first", is to call
>> juliaEval("@doc first")
>>This then simply prints the output on the command line.
>>
>>
>>ursprüngliche Nachricht-
>>Von: Jeff Newmiller [jdnew...@dcn.davis.ca.us]
>>An: r-package-devel@r-project.org, Duncan Murdoch
>>[murdoch.dun...@gmail.com], Stefan Lenz IMBI
>>[l...@imbi.uni-freiburg.de]
>>Datum: Mon, 06 Apr 2020 10:51:53 -0700
>>-
>>
>>
>>> One could take the position that the library and require functions
>>were a mistake
>>> to begin with and that all contributed packages should be accessed
>>using ::... or
>>> one could recognize that these functions are an expected feature of R
>>at this
>>> point and then it is not defensible to ban the proposed approach of
>>importing
>>> names as Stefan wants to. I don't think it is fair to require this
>>higher level of
>>> specificity just because it involves use of attach.
>>>
>>> That said, another feature of R
Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0
Hi Stefan, you need the function makeNamespace() to create the environment as a namespace. Look at the examples in the help files, I found them rather instructive. I also hope someone else chimes in to shed some light on whether or not that approach would be acceptable. Joris Meys Statistician T +32 9 264 61 79 Department Data Analysis and Mathematical Modelling Campus Coupure, Block A 1st floor 110.050, Coupure links 653, B-9000 Ghent, Belgium T administration office +32 9 264 59 32 www.ugent.be e-maildisclaimer From: Stefan Lenz IMBI Sent: Thursday, April 9, 2020 5:30 PM To: Joris Meys; Jeff Newmiller; r-package-devel@r-project.org; Duncan Murdoch Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0 Hi! Thanks for pointing to the package "namespace". I experimented with it but I couldn't really figure out how it is supposed to work: The following code leads to strange errors that I don't understand: > nse <- list2env(list(data="x", asdf = 2)) > namespace::registerNamespace(name = "NewNamespace", env = nse) > NewNamespace::asdf Error in asNamespace(ns) : not a namespace It would really be interesting if someone could comment on whether the namespace approach is feasible, how it is supposed to work, and whether/how it would be better than using attach. Greetings! Stefan ----ursprüngliche Nachricht- Von: Joris Meys [joris.m...@ugent.be] An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], Jeff Newmiller [jdnew...@dcn.davis.ca.us], r-package-devel@r-project.org, Duncan Murdoch [murdoch.dun...@gmail.com] Datum: Thu, 9 Apr 2020 12:59:23 + - > Hi Stefan, > > first of all, thank you for taking the time and effort to link Julia and R. > That > said, I would strongly encourage you to go for a reticulate-like approach. > There's a good reason for that. Once you start mixing languages, you really > want > to have some indication what code is ran in what language. Especially since I > can > imagine at one point there'll be a Julia function masking an R function of > the same > name, and that is going to cause a world of hurt and confusion. > > If you don't like environments, you can try to use namespace functionality. > There's the "namespace" package that allows you to create one, and some > internal > namespace functions are visible (eg namespaceExport() from base). That's > going to be the closest to mimicking R packages, but it's beyond my knowledge > to > know how feasible this approach actually is. I hope someone else chimes in, > especially if this is dangerous for other reasons I overlooked. > > Kind regards > Joris > > Joris Meys > Statistician > T +32 9 264 61 79 > > Department Data Analysis and Mathematical Modelling > > Campus Coupure, Block A 1st floor 110.050, Coupure links 653, B-9000 Ghent, > Belgium > T administration office +32 9 264 59 32 > > www.ugent.be > > e-maildisclaimer > > > > From: R-package-devel on behalf > of Stefan Lenz IMBI > Sent: Thursday, April 9, 2020 10:41 AM > To: Jeff Newmiller; r-package-devel@r-project.org; Duncan Murdoch > Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission > JuliaConnectoR 0.5.0 > > It is important for me to get my package into CRAN. > I haven't gotten any answer from the CRAN maintainers. I already tried to > submit a > version of the package before some months and haven't gotten any reply then. > The replies you gave me (thanks to all engaged in the discussion) were mixed. > I still think that the library-like import is a good feature, but if it is not > possible to get this package on CRAN with it, I will change it with returning > an > environment like reticulate. > My question now is: > So what would be the process how to proceed? > Is there anybody who can make a decision in such cases? > Or do I make this decision myself after I lost hope that it will be accepted > the way > it is now? > > Stefan > > > ursprüngliche Nachricht- > Von: Jeff Newmiller [jdnew...@dcn.davis.ca.us] > An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], > r-package-devel@r-project.org, Duncan Murdoch > [murdoch.dun...@gmail.com] > Datum: Tue, 07 Apr 2020 09:52:52 -0700 > - > > >> I did not say "interfere"... I said "problems with consistency". I don't >> think >> your wholesale import of functions without corresponding help pages is >> consistent with the normal
Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0
You're right, that's enough to not dig any further. I remembered it from the
earlier days of devtools, but they removed that dependency ages ago. I also
believe now the namespace package predates the later changes to the namespace
mechanism. Forget what I said, I should have spent a bit more time testing it
myself first.
Kind regards
Joris
Joris Meys
Statistician
T +32 9 264 61 79
Department Data Analysis and Mathematical Modelling
Campus Coupure, Block A 1st floor 110.050, Coupure links 653, B-9000 Ghent,
Belgium
T administration office +32 9 264 59 32
www.ugent.be
e-maildisclaimer
From: Stefan Lenz IMBI
Sent: Thursday, April 9, 2020 6:09 PM
To: Joris Meys; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission
JuliaConnectoR 0.5.0
When I execute the example, I also get a strange behaviour:
library(namespace)
ns <- makeNamespace("myNamespace")
assign("test",7, env=ns)
ls(env=ns)
When I now want to invoke any help for a function, I get a warning message:
> ?loadNamespace
Warning message:
In find.package(if (is.null(package)) loadedNamespaces() else package, :
there is no package called ‘myNamespace’
Also sessionInfo doesn't work any more:
> sessionInfo()
Error in if (pkgpath == "") { : argument is of length zero
I don't think this is a good sign
Stefan
--------ursprüngliche Nachricht-
Von: Joris Meys [joris.m...@ugent.be]
An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], r-package-devel@r-project.org
Datum: Thu, 9 Apr 2020 15:37:09 +
-
> Hi Stefan,
>
> you need the function makeNamespace() to create the environment as a
> namespace.
> Look at the examples in the help files, I found them rather instructive. I
> also
> hope someone else chimes in to shed some light on whether or not that approach
> would be acceptable.
>
>
> Joris Meys
> Statistician
> T +32 9 264 61 79
>
> Department Data Analysis and Mathematical Modelling
>
> Campus Coupure, Block A 1st floor 110.050, Coupure links 653, B-9000 Ghent,
> Belgium
> T administration office +32 9 264 59 32
>
> www.ugent.be
>
> e-maildisclaimer
>
>
>
> From: Stefan Lenz IMBI
> Sent: Thursday, April 9, 2020 5:30 PM
> To: Joris Meys; Jeff Newmiller; r-package-devel@r-project.org; Duncan
> Murdoch
> Subject: Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission
> JuliaConnectoR 0.5.0
>
> Hi!
> Thanks for pointing to the package "namespace".
> I experimented with it but I couldn't really figure out how it is supposed to
> work:
>
> The following code leads to strange errors that I don't understand:
>
> > nse <- list2env(list(data="x", asdf = 2))
> > namespace::registerNamespace(name = "NewNamespace", env = nse)
> > NewNamespace::asdf
> Error in asNamespace(ns) : not a namespace
>
> It would really be interesting if someone could comment on whether the
> namespace
> approach is feasible, how it is supposed to work, and whether/how it would be
> better than using attach.
> Greetings!
> Stefan
>
>
> ursprüngliche Nachricht-
> Von: Joris Meys [joris.m...@ugent.be]
> An: Stefan Lenz IMBI [l...@imbi.uni-freiburg.de], Jeff Newmiller
> [jdnew...@dcn.davis.ca.us], r-package-devel@r-project.org, Duncan
> Murdoch [murdoch.dun...@gmail.com]
> Datum: Thu, 9 Apr 2020 12:59:23 +
> -
>
>
>> Hi Stefan,
>>
>> first of all, thank you for taking the time and effort to link Julia and R.
>> That
>> said, I would strongly encourage you to go for a reticulate-like approach.
>> There's a good reason for that. Once you start mixing languages, you really
>> want
>> to have some indication what code is ran in what language. Especially since
>> I can
>> imagine at one point there'll be a Julia function masking an R function of
>> the same
>> name, and that is going to cause a world of hurt and confusion.
>>
>> If you don't like environments, you can try to use namespace functionality.
>> There's the "namespace" package that allows you to create one, and some
>> internal
>> namespace functions are visible (eg namespaceExport() from base). That's
>> going to be the closest to mimicking R packages, but it's beyond my
>> knowledge to
>> know how feasible this approach actually is. I hope someone else chimes in,
>> especially if this is dangerous for other reasons I overlooked.
>>
>>
Re: [R-pkg-devel] how to specify to let a package only build 64bit on CRAN
Hi Jan, To add to the suggestion of Gabor and Duncan, it might be a good idea to add a packageStartupMessage that warns the user about the problem when running on a 32bit system. You can easily extract that info from R.Version()$arch . That might help negotiating with CRAN. Kind regards Joris Joris Meys Statistician T +32 9 264 61 79 Department Data Analysis and Mathematical Modelling Campus Coupure, Block A 1st floor 110.050, Coupure links 653, B-9000 Ghent, Belgium T administration office +32 9 264 59 32 www.ugent.be e-maildisclaimer From: R-package-devel on behalf of Jan Wijffels Sent: Monday, May 11, 2020 2:46 PM To: Duncan Murdoch Cc: r-package-devel@r-project.org Subject: Re: [R-pkg-devel] how to specify to let a package only build 64bit on CRAN Duncan, Thanks for the reply. Let me make this more clear. The R package reticulate works on 32bit and 64bit. My golgotha package depends on reticulate and an extra Python package called torch which is not available for 32bit platforms. This is specified in the DESCRIPTION file at https://github.com/bnosac/golgotha/blob/master/DESCRIPTION#L17 For that reason R CMD check will fail on CRAN for 32bit. Hence my question. How do I specify this in the package such that I can distribute it on CRAN. best, Jan Jan Wijffels Statistician www.bnosac.be | +32 486 611708 ‐‐‐ Original Message ‐‐‐ On Monday 11 May 2020 14:39, Duncan Murdoch wrote: > On 11/05/2020 7:54 a.m., Jan Wijffels wrote: > > > Hello everyone, > > I have a package which I would like to host on CRAN. The package is at > > https://github.com/bnosac/golgotha > > The package only builds on 64bit however because the package uses R package > > reticulate which requires a python library called torch which does not > > build on 32 bit platforms. > > So installation only works using INSTALL_opts = "--no-multiarch" > > How do you specify this to the CRAN maintainers that this is the way it > > should be set up on CRAN such that it only is built for 64bit systems. > > I don't see how your package has any 32 bit dependence, since it has no > src directory. It's probably sufficient to declare the dependency on > reticulate, which indirectly implies the 32 bit dependence. But if > reticulate works on 32 bit systems as long as users don't need "torch", > then just state that. > > One thing I'd recommend: you should try to change the dependency from > Depends to Imports. If there are a few reticulate functions that you > want your users to have access to, you can import them and re-export > them so they're available from your package as well. > > Duncan __ 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
