Re: [R-pkg-devel] how to specify to let a package only build 64bit on CRAN

[Joris Meys]

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

Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

[Joris Meys]

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.
>>
>> Kind regards
>> Joris
>>
>> Joris Meys
>

Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

[Joris Meys]

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 use of R, which will make reading R code writt

Re: [R-pkg-devel] [FWD] [CRAN-pretest-archived] CRAN submission JuliaConnectoR 0.5.0

[Joris Meys]

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 packages is the integrated help
>>system...
>>> i

Re: [R-pkg-devel] How to provide a finalized PDF file in a package?

[Joris Meys]

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: [Rd] A bug understanding F relative to FALSE?

[Joris Meys]

As others have pointed out, this is expected behaviour. Let me get on that
hill I'll die on: it is absolutely not suitable. It is way beyond time to
remove T and F as unprotected kind-of-synonyms for TRUE and FALSE, given
the amount of times I had to point out that:

T <- t(matrix(0:3,nrow=2))
isTRUE(T)

was the reason the code didn't do what it's supposed to do. (Also don't use
T as short for "Transpose of my matrix", but that's another hill.)

As we've become more strict on the use of T and F in packages, maybe 4.0.0
is a good milestone to finally drop this relic from the past? One can
dream...

Kind regards
Joris

On Wed, Jan 15, 2020 at 3:14 PM IAGO GINÉ VÁZQUEZ  wrote:

> Hi all,
>
> Is the next behaviour suitable?
>
> identical(F,FALSE)
>
> ## [1] TRUE
>
> utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE))
>
> ##line1 col1 line2 col2 id parenttoken terminal  text
> ## 14 11 1   10 14  0 exprFALSE
> ## 1  11 11  1  3 SYMBOL_FUNCTION_CALL TRUE c
> ## 3  11 11  3 14 exprFALSE
> ## 2  12 12  2 14  '(' TRUE (
> ## 4  13 13  4  6   SYMBOL TRUE F
> ## 6  13 13  6 14 exprFALSE
> ## 5  14 14  5 14  ',' TRUE ,
> ## 9  15 19  9 10NUM_CONST TRUE FALSE
> ## 10 15 19 10 14 exprFALSE
> ## 11 1   10 1   10 11 14  ')' TRUE )
>
> I would expect that token for F is the same as token for FALSE.
>
>
> Thank you!
>
> Iago
>
>
> [[alternative HTML version deleted]]
>
> ______
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method

[Joris Meys]

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 user and more complication for the i

Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method

[Joris Meys]

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

[Joris Meys]

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] Possible unknown color in r

[Joris Meys]

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] Possible unknown color in r

[Joris Meys]

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: [Rd] Get memory address of an R data frame

[Joris Meys]

Hi Lille,

To my understanding, there's no need to get the actual memory address of
the R data frame, as using .Call() or .External() can be used in a "call by
reference" way as well. This would be contrary to standard R behaviour, so
if you use that in a package, make sure you indicate this!

There's a detailed explanation on how to deal with R objects in C code in
the manual "Writing R extensions" here :

https://cran.r-project.org/doc/manuals/R-exts.html#Handling-R-objects-in-C

Especially check the section "Named objects and copying", which explains in
more detail how to control the standard R behaviour. Also keep in mind that
data frames are list-like structures, which are handled differently from
atomic vectors.

Hope this helps.
Kind regards
Joris

On Thu, Jan 9, 2020 at 12:48 PM lille stor  wrote:

> Hello,
>
> I would like for my C function to be able to manipulate some values stored
> in an R data frame.
>
> To achieve this, a need the (real) memory address where the R data frame
> stores its data (hopefully in a contiguous way). Then, from R, I call the C
> function and passing this memory address as a parameter.
>
> The question: how can we get the memory address of the R data frame?
>
> Thank you!
>
> L.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Request R code this paper

[Joris Meys]

Dear,

you mailed the developers mailing list of Bioconductor, i.e. the list for 
people who develop packages for the Bioconductor suite. Please mail the authors 
of the paper instead. If you know the package they used, the source code of 
each package can be found on the bioconductor website.

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: Bioc-devel  on behalf of Salwa El-Aty 

Sent: Tuesday, January 7, 2020 3:49 AM
To: Bioc-devel@r-project.org
Subject: [Bioc-devel] Request  R code  this paper

Dear Sir
I want to help me about to send  the  R Codes of   paper which title
  "Generalized  endpoint -inflated  binomial model" .COMPUTATION STATISTICS AND 
DATA ANALYSIS .89  , 2015
Best Regards
Salwa. A.Mousa

Sent from my Samsung device

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[R-pkg-devel] Possibly invalid URL note about canonical form of link to cran package

[Joris Meys]

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

[Bioc-devel] Submitting a package with heavy data and vignette

[Joris Meys]

Dear,


we're planning on submitting a new package to Bioconductor. Due to the fact 
that this package revolves around simulation methods for massive datasets, the 
vignette necessarily need about 10 Mb of data and way more than 5 minutes to 
build. We were wondering how we would proceed best to submit this package. 
Downsizing the data and build time is alas not possible, as it would make the 
example in the vignette totally irrelevant.


I was thinking about the following construct:

- a main software package with the actual simulation functionality

- a "data" package depending on the main software package with only the example 
data and vignette.


We would love to hear your view on this, as we'd like to limit the amount of 
issues for both you and us once we submit the package(s). Other suggestions are 
more than welcome too.


Thank you in advance

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]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] compression of vignettes

[Joris Meys]

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

Re: [Rd] New matrix function

[Joris Meys]

As a package is a collection of functions, and as "base" is not used to
refer to the base package but to all packages that form "base R" (so utils,
graphics, stats, methods, parallel, ...), the functions in the parallel
package are one example of functions incorporated in "base R" from a
package. Actually two, because the functions in parallel are based on both
snow and multicore.

This has no relation to changes in implementation (which often don't happen
due to back-compatibility issues in edge cases).

Kind regards
Joris

On Fri, Oct 11, 2019 at 4:42 PM Morgan Morgan 
wrote:

> I think you are confusing package and function here. Plus some of the R
> Core packages, that you mention, contain functions that should probably be
> replaced by functions with better implementation from packages on CRAN.
>
> Best regards
> Morgan
>
> On Fri, 11 Oct 2019 15:22 Joris Meys,  wrote:
>
>>
>>
>> On Fri, Oct 11, 2019 at 3:55 PM Morgan Morgan 
>> wrote:
>>
>>> How do you prove usefulness of a feature?
>>> Do you have an example of a feature that has been added after proving to
>>> be
>>> useful in the package space first?
>>>
>>> Thank you,
>>> Morgan
>>>
>>
>> The parallel package (a base package like utils, stats, ...) was added as
>> a drop-in replacement of the packages snow and multicore for parallel
>> computing. That's one example, but sure there's more.
>>
>> 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=gmail=g>
>>
>> ---
>> Biowiskundedagen 2018-2019
>> 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=gmail=g>

---
Biowiskundedagen 2018-2019
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] should base R have a piping operator ?

[Joris Meys]

on should be general enough
> > * 3) the function should have a large amount of potential of users
> > * 4) the function should be robust, and not require extensive maintenance
> > * 5) the function should be stable, we shouldn't expect new features
> ever 2
> > months
> > * 6) the function should have an intuitive interface in the context of
> the
> > rest ot base R
> >
> > I guess 1 and 6 could be held against my proposal, because :
> > (1) everything can be done without pipes
> > (6) They are somewhat surprising (though with explicit dots not that
> much,
> > and not more surprising than say `bquote()`)
> >
> > In my opinion the + offset the -.
> >
> > I wouldn't advise taking magrittr's pipe (providing the license allows
> so)
> > for instance, because it makes a lot of design choices and has a complex
> > behavior, what I propose is 2 lines of code very unlikely to evolve or
> > require maintenance.
> >
> > Antoine
> >
> > PS: I just receive the digest once a day so If you don't "reply all" I
> can
> > only react later.
> >
> > Le sam. 5 oct. 2019 à 19:54, Hugh Marera  a
> écrit :
> >
> > > I exaggerated the comparison for effect. However, it is not very
> > difficult
> > > to find functions in dplyr or data.table or indeed other packages that
> > one
> > > may wish to be in base R. Examples, for me, could include
> > > data.table::fread, dplyr::group_by & dplyr::summari[sZ]e combo, etc.
> > Also,
> > > the "popularity" of magrittr::`%>%` is mostly attributable to the
> > tidyverse
> > > (an advanced superset of R). Many R users don't even know that they are
> > > installing the magrittr package.
> > >
> > > On Sat, Oct 5, 2019 at 6:30 PM Iñaki Ucar 
> > wrote:
> > >
> > >> On Sat, 5 Oct 2019 at 17:15, Hugh Marera 
> wrote:
> > >> >
> > >> > How is your argument different to, say,  "Should dplyr or data.table
> > be
> > >> > part of base R as they are the most popular data science packages
> and
> > >> they
> > >> > are used by a large number of users?"
> > >>
> > >> Two packages with many features, dozens of functions and under heavy
> > >> development to fix bugs, add new features and improve performance, vs.
> > >> a single operator with a limited and well-defined functionality, and a
> > >> reference implementation that hasn't changed in years (but certainly
> > >> hackish in a way that probably could only be improved from R itself).
> > >>
> > >> Can't you really spot the difference?
> > >>
> > >> Iñaki
> > >>
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2018-2019
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Require -package.Rd?

[Joris Meys]

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=gmail=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

[Joris Meys]

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=gmail=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

[Joris Meys]

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=gmail=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

[Joris Meys]

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 Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9

Re: [R-pkg-devel] CRAN student assistants

[Joris Meys]

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=gmail=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: [Rd] R 3.5.3 having trouble spawning a new process on my Windows 10 machine

[Joris Meys]

Hi Sam,

Is your PATH set on your user environment variables or on the system?
Did you try to remove the entry for R-3.5.2 ?

I have tested with a standard install, and I can't reproduce your error. I
have the exact same path in my system PATH environment variable for 3.5.3,
and nothing for other versions.

Sorry I can't be of any more help.
Cheers
Joris

On Mon, Mar 25, 2019 at 4:54 PM Sam Albers  wrote:

> Hi all,
>
> I am noticing some strange behaviour so I am bringing to this list. In the
> past when I have submitted bugs to bugzilla, I have come here first for
> confirmation/advice. Hopefully this is appropriate.
>
> Upgrading from R 3.5.2 to R 3.5.3 seems to have elicited some strange
> behaviour on my Windows machine. R seems to have trouble spawning a new
> process on my machine. You can noticing with all sort of packages, like
> devtools, which try to spawn new R processes. Here is the replication of
> the beahviour:
>
>
>
> ## On R 3.5.3
> Open a command prompt:
>
> H:\>R
> '"C:\PROGRA~1\R\R-35~1.3/bin/x64/Rterm.exe"' is not recognized as an
> internal or external command,
> operable program or batch file.
>
> H:\>Rscript -e "sessionInfo()"
> R version 3.5.3 (2019-03-11)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 17134)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=English_Canada.1252  LC_CTYPE=English_Canada.1252
> [3] LC_MONETARY=English_Canada.1252 LC_NUMERIC=C
> [5] LC_TIME=English_Canada.1252
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.3
>
>
>
> ## On 3.5.2
> H:\>R
>
> R version 3.5.2 (2018-12-20) -- "Eggshell Igloo"
> Copyright (C) 2018 The R Foundation for Statistical Computing
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
>   Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
> > q()
> Save workspace image? [y/n/c]: n
>
> H:\>Rscript -e "sessionInfo()"
> R version 3.5.2 (2018-12-20)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 17134)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=English_Canada.1252  LC_CTYPE=English_Canada.1252
> [3] LC_MONETARY=English_Canada.1252 LC_NUMERIC=C
> [5] LC_TIME=English_Canada.1252
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.2
>
>
>
> ## Considerations
> - I have manually removed both my .Renviron and .Rprofile files just to
> ensure those weren't muddling up anything.
> - I have my PATH set like this "C:\Program Files\R\R-3.5.3\bin"  for 3.5.3
> and "C:\Program Files\R\R-3.5.2\bin" for 3.5.2
> - R 3.5.3 works final if I just open the default console that ships with R.
> But then anytime I try to launch a new process I get the above error.
>
> A similar issue has been raised up before
> https://stat.ethz.ch/pipermail/r-devel/2017-September/074921.html
> https://stat.ethz.ch/pipermail/r-devel/2015-September/071714.html
>
> Am I missing something obvious here? Many thanks in advance for taking a
> look.
>
> Regards,
>
> Sam
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2018-2019
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] CRAN submission examples don't run

[Joris Meys]

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=gmail=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: [Rd] Improved Data Aggregation and Summary Statistics in R

[Joris Meys]

Dear Sebastian,

Initially I was a bit hesitant to think about yet another way to summarize
data, but your illustrations convinced me this is actually a great addition
to the toolset currently available in different R packages. Many of us have
written custom functions to get the required tables for specific data sets,
but this would reduce that effort to simply using the right collap() call.

Like Inaki, I'm very interested in trying it out if you have the code
available somewhere.

Cheers
Joris





On Wed, Feb 27, 2019 at 9:01 AM Sebastian Martin Krantz <
sebastian.kra...@graduateinstitute.ch> wrote:

> Dear Developers,
>
> Having spent time developing and thinking about how data aggregation and
> summary statistics can be enhanced in R, I would like to present my
> ideas/efforts in the form of two commands:
>
> The first, which for now I called 'collap', is an upgrade of aggregate that
> accommodates and extends the functionality of aggregate in various
> respects, most importantly to work with multilevel and multi-type data,
> multiple function calls, highly customized aggregation tasks, a much
> greater flexibility in the passing of inputs and tidy output.
>
> The second function, 'qsu', is an advanced and flexible summary command for
> cross-sectional and multilevel (panel) data (i.e. it can provide overall,
> between and within entities statistics, and allows for grouping, custom
> functions and transformations). It also provides a quick method to compute
> and output within-transformed data.
>
> Both commands are efficiently built from core R, but provide for optional
> integration with data.table, which renders them extremely fast on large
> datasets. An explanation of the syntax, a demonstration and benchmark
> results are provided in the attached vignette.
>
> Since both commands accommodate existing functionality while adding
> significant basic functionality, I though that their addition to the stats
> package would be a worthwhile consideration. I am happy for your feedback.
>
> Best regards,
>
> Sebastian Krantz
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2018-2019
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] submitting to github

[Joris Meys]

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=gmail=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

[Bioc-devel] SSH keys for the newly accepted package RCM

[Joris Meys]

Dear,

I'm the maintainer of the new package RCM, written by Stijn Hawinkel. In
the issue on github Stijn was asked to submit a SSH key to Bioconductor (
https://github.com/Bioconductor/Contributions/issues/949#issuecomment-451232446
).

I am also the maintainer of the unifiedWMWqPCR package and my SSH key has
been registered by Bioconductor before. Is it necessary for the author to
submit one as well, or is my key as a maintainer enough?

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=gmail=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]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] OfficeScan deletes Rterm as malware

[Joris Meys]

Dear Roland,

quite surprising, as online scans of TrendMicro turn up completely clean.
It looks like a false positive, which you can report to TrendMicro as
explained here :

https://success.trendmicro.com/solution/1115668-preventing-behavior-monitoring-false-detections-in-officescan#collapse1

On the same website they explain how you can whitelist it. I'll check at
home with a few other antiviruses, but I'm pretty certain this is a case of
TrendMicro being overly enthousiast in its protection.

Cheers
Joris

On Thu, Dec 20, 2018 at 2:52 PM Roland Fuß  wrote:

> I'm not sure if the problem is actually with R but thought I should
> report this anyway.
>
> After Peter's email regarding the R 3.5.2 release today, I installed the
> Windows version right away (directly from CRAN and not from a mirror).
>
> Unfortunately, my institute's AV sofware TrendMicro OfficeScan 12.0.5147
> Service Pack 1 stops and deletes Rterm.exe when running Rcmd.exe INSTALL
> with a local source package. It reports "OfficeScan detected a Behavior
> Monitoring policy violation and blocked the offending process(es)." and
> "Unauthorized File Encryption" by Rterm.exe.
>
> I've deinstalled R 3.5.2 for now and switched back to 3.5.1, which works
> fine.
>
> Best,
>
> Roland Fuß
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] Dealing with .git folder when using R CMD INSTALL

[Joris Meys]

I'm sorry, I should have indeed given a better description.

The package I'm seeing the issue with, can be found here :
https://github.com/CenterForStatistics-UGent/RCM

The problem becomes visible when opening an RStudio session and running
BiocCheck::BiocCheck() (This is a Bioconductor package)

> BiocCheck::BiocCheck()
This is BiocCheck version 1.18.0. BiocCheck is a
work in progress. Output and severity of issues may
change. Installing package...
* Checking vignette directory...
This is a software package
# of chunks: 39, # of eval=FALSE: 4 (10%)
* Checking version number...
Checking version number validity...
Package version 0.99.0; pre-release
* Checking R Version dependency...
* Checking package size...
Skipped... only checked on source tarball
* Checking individual file sizes...
* WARNING: The following files are over 5MB in size:
  '.git/objects/pack/pack-92e66ff77b78e7fa5121747871adeaa41fb1feb6.pack'
...

And at this point I start hitting myself so I can utter an apology and
inform you that BiocCheck doesn't check filesize on the installed package
but on the original project directory.

My mistake, and I should have been more careful before bothering you all.
Cheers
Joris


On Thu, Dec 6, 2018 at 4:14 PM Dirk Eddelbuettel  wrote:

>
> On 6 December 2018 at 15:59, Ralf Stubner wrote:
> | On 06.12.18 15:19, Joris Meys wrote:
> | > I know this R CMD build ignores these files and folders by default,
> but R
> | > CMD INSTALL doesn't apparently.
> |
> | to me this is not apparent. I just tried "R CMD INSTALL ." in a package
> | directory with a .git directory. This went without any problems. What do
> | you observe?
>
> Seconded. I joked off-list to Joris that this post failed to contain a MCVE
> (== minimally complete verifiable example).  Witness below -- two
> installations from a directory containing .git yet none in the installed
> directory.  Could what you describe be particular to your OS or filesystem?
>
> edd@rob:~/git/dang$ ls -a
> .  dang_0.0.7.tar.gz  dang.Rproj   .gitignore  R
> .Rhistory
> .. dang_0.0.8.tar.gz  DESCRIPTION  man .Rbuildignore
> .Rproj.user
> ChangeLog  dang.Rcheck.git NAMESPACE   README.md
> .travis.yml
> edd@rob:~/git/dang$ R CMD INSTALL .
> * installing to library ‘/usr/local/lib/R/site-library’
> * installing *source* package ‘dang’ ...
> ** R
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** testing if installed package can be loaded
> * DONE (dang)
> edd@rob:~/git/dang$ ls -a /usr/local/lib/R/site-library/dang/
> .  ..  DESCRIPTION  help  html  INDEX  Meta  NAMESPACE  R
> edd@rob:~/git/dang$ install.r
> * installing *source* package found in current working directory ...
> * installing *source* package ‘dang’ ...
> ** R
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** testing if installed package can be loaded
> * DONE (dang)
> edd@rob:~/git/dang$ ls -a /usr/local/lib/R/site-library/dang/
> .  ..  DESCRIPTION  help  html  INDEX  Meta  NAMESPACE  R
> edd@rob:~/git/dang$
>
>
> Dirk
>
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] Dealing with .git folder when using R CMD INSTALL

[Joris Meys]

On Thu, 6 Dec 2018, 16:04 Ralf Stubner  On 06.12.18 15:19, Joris Meys wrote:
> > I know this R CMD build ignores these files and folders by default, but R
> > CMD INSTALL doesn't apparently.
>
> to me this is not apparent. I just tried "R CMD INSTALL ." in a package
> directory with a .git directory. This went without any problems. What do
> you observe?
>

When running BiocCheck, I get complaints about file sizes in the .git
folder. Checking the code I have noticed it uses R CMD INSTALL on the pkg
directory. As .Rbuildignore is afaik not taken into account by INSTALL, I
reckoned somewhere in the process R CMD INSTALL drags the .git folder along.

I might have been too quick with my assessment, I will dig a bit deeper
tonight

Cheers
Joris

>
> cheerio
> ralf
>
> --
> Ralf Stubner
> Senior Software Engineer / Trainer
>
> daqana GmbH
> Dortustraße 48
> 14467 Potsdam
>
> T: +49 331 23 61 93 11
> F: +49 331 23 61 93 90
> M: +49 162 20 91 196
> Mail: ralf.stub...@daqana.com
>
> Sitz: Potsdam
> Register: AG Potsdam HRB 27966
> Ust.-IdNr.: DE300072622
> Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] Dealing with .git folder when using R CMD INSTALL

[Joris Meys]

On Thu, 6 Dec 2018, 15:37 Dirk Eddelbuettel 
>
> These have been auto-ignored by R CMD build for a loong time. Are you
> maybe making the mistake of installing from a _directory_ as opposed to
> first
> creating a tarball?
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


That's indeed what devtools::install () and BiocCheck () are doing, and I
wondered if R CMD INSTALL could be made to ignore at least those.

Thx for the confirmation
Cheers
Joris

[[alternative HTML version deleted]]

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

[Rd] Dealing with .git folder when using R CMD INSTALL

[Joris Meys]

Dear all,

quite a few package tools depend on R CMD INSTALL today for rapid testing
of a package, eg:

- devtools::install()
- BiocCheck::BiocCheck()

I've noticed that at least BiocCheck() doesn't ignore version control
folders like .git. Trying to find out why this was, lead me to R CMD
INSTALL.

I know this R CMD build ignores these files and folders by default, but R
CMD INSTALL doesn't apparently. Is there a way to tell R CMD INSTALL to
ignore at least the .git folder, or are there plans to add this the R CMD
INSTALL? And if so, where do I file the request best?

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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Can I put my small data-sets into one .rda file in my CRAN package?

[Joris Meys]

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=gmail=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

[Joris Meys]

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=gmail=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

[Joris Meys]

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=gmail=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()

[Joris Meys]

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=gmail=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

[Rd] Checksums of packages change on CRAN without change in version number

[Joris Meys]

Dear all,

I report the same problem again, as one of our sysadmins at the university
ran into the same issue again. Every so often they find an in-place update
of an R package which almost always amounts to a small change in the
DESCRIPTION file. This does cause the checksums to change, and we end up
with two packages with the exact same version number but different
checksums.

To date there hasn't been any satisfactory answer on how to avoid having to
update our own configuration builds a week after the initial update due to
these stealthy checksum changes.

It's also an increasing safety concern for our IT department, as they
seriously frown upon software that makes in-place changes. According to
them, there's no way they can know whether it is a legitimate change to the
package, or the result of some kind of hack. They have to rely on trust,
which is a dangerous thing to do in an IT context and which they like to
avoid.

github report on the issue (this time it's mgcv) :
https://github.com/easybuilders/easybuild-easyconfigs/pull/7122#pullrequestreview-172031060

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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] Suggestion: Make CRAN source URLs immutable

[Joris Meys]

FWIW, you can get the URL and extract the link with extension from there.
Archived packages are always tarballs, so that makes the following possible:

url <- "https://cran.r-project.org/package=httr=1.3.0;

library(RCurl)

pkgurl <- gsub(".*(https://cran.+\\.tar.gz).*",
   "\\1",
   getURL(url))

install.packages(pkgurl, type = "source", repos = NULL)

Cheers
Joris


On Fri, Nov 2, 2018 at 5:42 PM Iñaki Ucar  wrote:

> On Wed, 24 Oct 2018 at 11:40, Kurt Hornik  wrote:
> >
> > >>>>> Kurt Wheeler writes:
> >
> > Try e.g.
> >
> > https://cran.r-project.org/package=httr=1.3.1
> > https://cran.r-project.org/package=httr=1.3.0
>
> This is a nice feature that I didn't know. I recently proposed
> enforcing this scheme in Fedora's packaging guidelines, because in
> this way, a SPEC would build correctly even if the package was updated
> and the old version was archived (is this guaranteed to continue to
> work in future? I assumed so...).
>
> There is an odd thing about this format though, and that is the
> absence of a file extension. This is a redirection, yes, but the
> spectool can't trust the filename that is sent by the remote server,
> and uses only the filename extracted from the URL.
>
> Without extension, RPM doesn't know how to unpack the sources. So we
> have to do the following similarly odd trick (note the "#"):
>
> Source0:
> https://cran.r-project.org/package=%{packname}=%{version}#/%{packname}_%{version}.tar.gz
>
> Did you consider this problem? Is there any alternate immutable URL
> *with* extension? If not, is there any potential issue with the trick
> above?
>
> Regards,
> --
> Iñaki Ucar
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] CRAN Non-Triviality Requirement

[Joris Meys]

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=gmail=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: [Bioc-devel] Installation procedure on website outdated

[Joris Meys]

Thank you for the information. I've linked our IT to the vignette of
BiocManager for the time being.

Cheers
Joris

On Fri, Sep 21, 2018 at 3:10 PM Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> The old installation is still valid for the current release 3.7.   We
> planned to update this page as it got closer to the next release 3.8.  As
> the release 3.8 is fast approaching (end of Oct) we will most likely be
> updating this page in the very near future.
>
>
> Thank you for bringing it to our attention.
>
> Cheers,
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Bioc-devel  on behalf of Joris
> Meys 
> *Sent:* Friday, September 21, 2018 7:22:18 AM
> *To:* bioc-devel
> *Subject:* [Bioc-devel] Installation procedure on website outdated
>
> Dear all,
>
> I wanted to point our IT departement to the new installation procedure of
> Bioconductor, and to my astonishment that information starts with
>
> source("https://bioconductor.org/biocLite.R;)
>
> No mention of BiocManager there. This information really needs updating
> imho, or is there a reason why the old installation procedure is still
> mentioned there?
>
> https://www.bioconductor.org/install/
>
> 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=gmail=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]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. 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=gmail=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]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] Help

[Joris Meys]

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%A0Belgium=gmail=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

[Bioc-devel] Installation procedure on website outdated

[Joris Meys]

Dear all,

I wanted to point our IT departement to the new installation procedure of
Bioconductor, and to my astonishment that information starts with

source("https://bioconductor.org/biocLite.R;)

No mention of BiocManager there. This information really needs updating
imho, or is there a reason why the old installation procedure is still
mentioned there?

https://www.bioconductor.org/install/

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=gmail=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]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] A different error in sample()

[Joris Meys]

To be more clear: I do NOT state that the function "round" is used. I read
the documentation as "non integer positive numerical values will be
replaced by the next smallest integer", the important part being the NEXT
smallest integer, i.e. how ceiling() does it. So that's exactly what I
would expect. If "replaced by" causes less confusion than "rounded to" or
"truncated to", then use that.

I do agree that this wording would still indicate that this happens prior
to the sampling, whereas the output indicates that this is done after the
sampling. I can reproduce the sample() outcome using runif() as follows:

> table(ceiling(runif(1,0,2.1)))
   123
4774 4756  470

> table(ceiling(runif(1,0,3)))
   123
3273 3440 3287

I don't know if that's the intended behaviour, but there is some logic in
it. It's up to the R core team to decide if this is OK and rephrase the
help page so it becomes more clear what actually happens, or simply add
something like

if( (x%%1) != 0) x <- ceiling(x)

prior to the sampling algorithm.

Cheers
Joris

On Thu, Sep 20, 2018 at 9:44 AM lmo via R-devel 
wrote:

> Although it seems to be pretty weird to enter a numeric vector of length
> one that is not an integer as the first argument to sample(), the results
> do not seem to match what is documented in the manual. In addition, the
> results below do not support the use of round rather than truncate in the
> documentation. Consider the code below.
> The first sentence in the details section says: "If x has length 1, is
> numeric (in the sense of is.numeric) and x >= 1, sampling via sample takes
> place from 1:x."
> In the console:> 1:2.001
> [1] 1 2
> > 1:2.9
> [1] 1 2
>
> truncation:
> > trunc(2.9)
> [1] 2
>
> So, this seems to support the quote from in previous emails: "Non-integer
> positive numerical values of n or x will be truncated to the next smallest
> integer, which has to be no larger than .Machine$integer.max."
> However, again in the console:> set.seed(123)
>  > table(sample(2.001, 1, replace=TRUE))
>
>123
> 5052 49417
>
> So, neither rounding nor truncation is occurring. Next, define a sequence.
> > x <- seq(2.001, 2.51, length.out=20)
> Now, grab all of the threes from sample()-ing this sequence.
>
>  > set.seed(123)
> > threes <- sapply(x, function(y) table(sample(y, 1, replace=TRUE))[3])
>
> Check for NAs (I cheated here and found a nice seed).> any(is.na(threes))
> [1] FALSE
> Now, the (to me) disturbing result.
>
> > is.unsorted(threes)
> [1] FALSE
>
> or equivalently
>
> > all(diff(threes) > 0)
> [1] TRUE
>
> So the number of threes grows monotonically as 2.001 moves to 2.5. As I
> hinted above, the monotonic growth is not assured. My guess is that the
> growth is stochastic and relates to some "probability weighting" based on
> how close the element of x is to 3. Perhaps this has been brought up
> before, but it seems relevant to the current discussion.
> A potential aid to this issue would be something like
> if(length(x) == 1 && !all.equal(x, as.integer(x))) warning("It is a bad
> idea to use vectors of length 1 in the x argument that are not integers.")
> Hope that helps,luke
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] A different error in sample()

[Joris Meys]

I believe the word "truncated" is causing the confusion. 3 is "the next
smallest integer" following 2.5. But it is not the truncation done by
trunc(). Rewording to "rounding the next smallest integer" would get rid of
that confusion imho.

Cheers
Joris

On Wed, Sep 19, 2018 at 7:57 PM Duncan Murdoch 
wrote:

> This may be a doc error or a coding bug.
>
> The help page for sample says:
>
> "Non-integer positive numerical values of n or x will be truncated to
> the next smallest integer, which has to be no larger than
> .Machine$integer.max."
>
> This is not true:
>
>  > table(sample(2.5, 100, replace = TRUE))
>
>   1  2  3
> 399933 399716 200351
>
> We shouldn't have those 3's if truncation of x had occurred.
>
> Duncan Murdoch
>
>  > sessionInfo()
> R version 3.5.1 (2018-07-02)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS High Sierra 10.13.6
>
> Matrix products: default
> BLAS:
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
> LAPACK:
> /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
>
> locale:
> [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.1 tools_3.5.1
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] memory footprint of readRDS()

[Joris Meys]

Thx William and Brian for your swift responses, very insightful. I'll have
to hunt for more memory.

Cheers
Joris

On Tue, Sep 18, 2018 at 6:16 PM William Dunlap  wrote:

> The ratio of object size to rds file size depends on the object.  Some
> variation is due to how header information is stored in memory and in the
> file but I suspect most is due to how compression works (e.g., a vector of
> repeated values can be compressed into a smaller file than a bunch of
> random bytes).
>
> f <- function (data, ...)  {
> force(data)
> tf <- tempfile()
> on.exit(unlink(tf))
> save(data, file = tf)
> c(`obj/file size` = as.numeric(object.size(data)/file.size(tf)))
> }
>
> > f(rep(0,1e6))
> obj/file size
>  1021.456
> > f(rep(0,1e6), compress=FALSE)
> obj/file size
> 0.986
> > f(rep(89.7,1e6))
> obj/file size
>  682.6555
> > f(log(1:1e6))
> obj/file size
>  1.309126
> > f(vector("list",1e6))
> obj/file size
>  2021.744
> > f(as.list(log(1:1e6)))
> obj/file size
>  8.907579
> > f(sample(as.raw(0:255),size=8e6,replace=TRUE))
> obj/file size
> 0.9998433
> > f(rep(as.raw(0:255),length=8e6))
> obj/file size
>  254.5595
> > f(as.character(1:1e6))
> obj/file size
>   23.5567
>
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Tue, Sep 18, 2018 at 8:28 AM, Joris Meys  wrote:
>
>> Dear all,
>>
>> I tried to read in a 3.8Gb RDS file on a computer with 16Gb available
>> memory. To my astonishment, the memory footprint of R rises quickly to
>> over
>> 13Gb and the attempt ends with an error that says "cannot allocate vector
>> of size 5.8Gb".
>>
>> I would expect that 3 times the memory would be enough to read in that
>> file, but apparently I was wrong. I checked the memory.limit() and that
>> one
>> gave me a value of more than 13Gb. So I wondered if this was to be
>> expected, or if there could be an underlying reason why this file doesn't
>> want to open.
>>
>> Thank you in advance
>> 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=gmail=g
>> >
>>
>> ---
>> Biowiskundedagen 2017-2018
>> http://www.biowiskundedagen.ugent.be/
>>
>> ---
>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

[Rd] memory footprint of readRDS()

[Joris Meys]

Dear all,

I tried to read in a 3.8Gb RDS file on a computer with 16Gb available
memory. To my astonishment, the memory footprint of R rises quickly to over
13Gb and the attempt ends with an error that says "cannot allocate vector
of size 5.8Gb".

I would expect that 3 times the memory would be enough to read in that
file, but apparently I was wrong. I checked the memory.limit() and that one
gave me a value of more than 13Gb. So I wondered if this was to be
expected, or if there could be an underlying reason why this file doesn't
want to open.

Thank you in advance
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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Joris Meys]

On Thu, Aug 30, 2018 at 5:58 PM Martin Maechler 
wrote:

>
> I agree "in theory".
> Thank you, Henrik, for bringing it up!
>
> In practice I think we should start having a warning signalled.
>

I agree. I wouldn't know who would count on the automatic selection of the
first value, but better safe than sorry.


> I have checked the source code in the mean time, and the check
> is really very cheap
> { because it can/should be done after checking isNumber(): so
>   then we know we have an atomic and can use XLENGTH() }
>
>
That was my idea as well after going through the source code. I didn't want
to state it as I don't know enough of the code base and couldn't see if
there were complications I missed. Thank you for confirming!

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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Joris Meys]

On Thu, Aug 30, 2018 at 2:09 PM Dénes Tóth  wrote:

> Note that `||` and `&&` have never been symmetric:
>
> TRUE || stop() # returns TRUE
> stop() || TRUE # returns an error
>
>
Fair point. So the suggestion would be to check whether x is of length 1
and whether y is of length 1 only when needed. I.e.

c(TRUE,FALSE) || TRUE

would give an error and

TRUE || c(TRUE, FALSE)

would pass.

Thought about it a bit more, and I can't come up with a use case where the
first line must pass. So if the short circuiting remains and the extra
check only gives a small performance penalty, adding the error could indeed
make some bugs more obvious.

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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1

[Joris Meys]

I have to agree with Emil here. && and || are short circuited like in C and
C++. That means that

TRUE || c(TRUE, FALSE)
FALSE && c(TRUE, FALSE)

cannot give an error because the second part is never evaluated. Throwing a
warning or error for

c(TRUE, FALSE) || TRUE

would mean that the operator gives a different result depending on the
order of the objects, breaking the symmetry. Also that would be undesirable.

Regarding logical(0): per the documentation, it is indeed so that ||, &&
and isTRUE always return a length-one logical vector. Hence the NA.

On a sidenote: there is no such thing as a scalar in R. What you call
scalar, is really a length-one vector. That seems like a detail, but is
important in understanding why this admittedly confusing behaviour actually
makes sense within the framework of R imho. I do understand your objections
and suggestions, but it would boil down to removing short circuited
operators from R.

My 2 cents.
Cheers
Joris

On Wed, Aug 29, 2018 at 5:03 AM Henrik Bengtsson 
wrote:

> # Issue
>
> 'x || y' performs 'x[1] || y' for length(x) > 1.  For instance (here
> using R 3.5.1),
>
> > c(TRUE, TRUE) || FALSE
> [1] TRUE
> > c(TRUE, FALSE) || FALSE
> [1] TRUE
> > c(TRUE, NA) || FALSE
> [1] TRUE
> > c(FALSE, TRUE) || FALSE
> [1] FALSE
>
> This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the
> same) and it also applies to 'x && y'.
>
> Note also how the above truncation of 'x' is completely silent -
> there's neither an error nor a warning being produced.
>
>
> # Discussion/Suggestion
>
> Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a
> mistake.  Either the code is written assuming 'x' and 'y' are scalars,
> or there is a coding error and vectorized versions 'x | y' and 'x & y'
> were intended.  Should 'x || y' always be considered an mistake if
> 'length(x) != 1' or 'length(y) != 1'?  If so, should it be a warning
> or an error?  For instance,
> '''r
> > x <- c(TRUE, TRUE)
> > y <- FALSE
> > x || y
>
> Error in x || y : applying scalar operator || to non-scalar elements
> Execution halted
>
> What about the case where 'length(x) == 0' or 'length(y) == 0'?  Today
> 'x || y' returns 'NA' in such cases, e.g.
>
> > logical(0) || c(FALSE, NA)
> [1] NA
> > logical(0) || logical(0)
> [1] NA
> > logical(0) && logical(0)
> [1] NA
>
> I don't know the background for this behavior, but I'm sure there is
> an argument behind that one.  Maybe it's simply that '||' and '&&'
> should always return a scalar logical and neither TRUE nor FALSE can
> be returned.
>
> /Henrik
>
> PS. This is in the same vein as
> https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
> - in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
> _R_CHECK_LENGTH_1_CONDITION_=true
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] conflicted: an alternative conflict resolution strategy

[Joris Meys]

On Fri, Aug 24, 2018 at 2:27 PM Hadley Wickham  wrote:

>
> My questions are not about how to develop a package, R CMD check, or
> how to get it on CRAN, but instead about the semantics of the packages
> I am working on. My opinion is supported by the fact that a number of
> members of the R core team have responded (both on list and off) and
> have not expressed concern about my choice of venue.
>

If those moderating the lists are fine with it, all good.

Cheers
Joris


> That said, I am happy to change venues (or simply not email at all) if
> there is widespread concern that my emails are inappropriate.
>
> Hadley
>
> --
> http://hadley.nz
>


-- 
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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] conflicted: an alternative conflict resolution strategy

[Joris Meys]

; attach order:
>
> head(conflict_scout(c("devtools", "usethis")))
> #> 26 conflicts:
> #> * `use_appveyor`   : [usethis]
> #> * `use_build_ignore`   : [usethis]
> #> * `use_code_of_conduct`: [usethis]
> #> * `use_coverage`   : [usethis]
> #> * `use_cran_badge` : [usethis]
> #> * `use_cran_comments`  : [usethis]
> #> ...
>
> Finally, as mentioned above, the user can declare preferences:
>
> conflict_prefer("select", "MASS")
> #> [conflicted] Will prefer MASS::select over any other package
> conflict_scout(c("dplyr", "MASS"))
> #> 1 conflict:
> #> * `select`: [MASS]
>
> I’d love to hear what people think about the general idea, and if there
> are any obviously missing pieces.
>
> Thanks!
>
> Hadley
>
>
> --
> http://hadley.nz
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Proper way to document helper functions not accessible by user.

[Joris Meys]

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=gmail=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: [Rd] vctrs: a type system for the tidyverse

[Joris Meys]

Hi Hadley,

my point actually came from a data analyst point of view. A character
variable is something used for extra information, eg the "any other ideas?"
field of a questionnaire. A categorical variable is a variable describing
categories defined by the researcher. If it is made clear that a factor is
the object type needed for a categorical variable, there is no confusion.
All my students get it. But I agree that in many cases people are taught
that a factor is somehow related to character variables. And that does not
make sense from a data analyst point of view if you think about variables
as continuous, ordinal and nominal in a model context.

So I don't think adding more confusing behaviour and pitfalls is a solution
to something that's essentially a misunderstanding. It's something that's
only solved by explaining it correctly imho.

Cheers
Joris

On Thu, Aug 9, 2018 at 2:36 PM Hadley Wickham  wrote:

>
> I 100% agree with you, and is this the behaviour that vctrs used to
> have and dplyr currently has (at least in bind_rows()). But
> pragmatically, my experience with dplyr is that people find this
> behaviour confusing and unhelpful. And when I played the full
> expression of this behaviour in vctrs, I found that it forced me to
> think about the levels of factors more than I'd otherwise like to: it
> made me think like a programmer, not like a data analyst. So in an
> ideal world, yes, I think factors would have stricter behaviour, but
> my sense is that imposing this strictness now will be onerous to most
> analysts.
>
> Hadley
>
> --
> http://hadley.nz
>


-- 
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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] vctrs: a type system for the tidyverse

[Joris Meys]

 I sent this to  Iñaki personally by mistake. Thank you for notifying me.

On Wed, Aug 8, 2018 at 7:53 PM Iñaki Úcar  wrote:

>
> For what it's worth, I always thought about factors as fundamentally
> characters, but with restrictions: a subspace of all possible strings.
> And I'd say that a non-negligible number of R users may think about
> them in a similar way.
>

That idea has been a common source of bugs and the most important reason
why I always explain my students that factors are a special kind of
numeric(integer), not character. Especially people coming from SPSS see
immediately the link with categorical variables in that way, and understand
that a factor is a modeling aid rather than an alternative for characters.
It is a categorical variable and a more readable way of representing a set
of dummy variables.

I do agree that some of the factor behaviour is confusing at best, but that
doesn't change the appropriate use and meaning of factors as categorical
variables.

Even more, I oppose the ideas that :

1) factors with different levels should be concatenated.

2) when combining factors, the union of the levels would somehow be a good
choice.

Factors with different levels are variables with different information, not
more or less information. If one factor codes low and high and another
codes low, mid and high, you can't say whether mid in one factor would be
low or high in the first one. The second has a higher resolution, and
that's exactly the reason why they should NOT be combined. Different levels
indicate a different grouping, and hence that data should never be used as
one set of dummy variables in any model.

Even when combining factors, the union of levels only makes sense to me if
there's no overlap between levels of both factors. In all other cases, a
researcher will need to determine whether levels with the same label do
mean the same thing in both factors, and that's not guaranteed. And when
we're talking a factor with a higher resolution and a lower resolution, the
correct thing to do modelwise is to recode one of the factors so they have
the same resolution and every level the same definition before you merge
that data.

So imho the combination of two factors with different levels (or even
levels in a different order) should give an error. Which R currently
doesn't throw, so I get there's room for improvement.

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=gmail=g>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Weird error on CRAN linux check

[Joris Meys]

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)
>>> ## Error in UseMethod("foo") :
>>> ##  no applicable method for 'foo' applied to an object of c

Re: [R-pkg-devel] Weird error on CRAN linux check

[Joris Meys]

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:
>>  > >
>>  > >
>>  > > That shouldn't matter.  That function was created in a local

Re: [R-pkg-devel] Weird error on CRAN linux check

[Joris Meys]

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=gmail=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=gmail=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

[Joris Meys]

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=gmail=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.

[Joris Meys]

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...@statistik.tu-dortmund.de <mailto:li

Re: [R-pkg-devel] Checksums changed on CRAN without any visible modifications to files.

[Joris Meys]

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=gmail=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=gmail=g>
>>
>> tel: +32 (0)9 264 61 79
>> ---
>> Biowiskundedagen 2017-2018
>> http://www.biowiskundedagen.ugent.be/
>>
>> ---
>> Disclaimer : http://hel

Re: [R-pkg-devel] Checksums changed on CRAN without any visible modifications to files.

[Joris Meys]

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=gmail=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=gmail=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=gmail=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: [Bioc-devel] BiocManager now on CRAN

[Joris Meys]

Dear Marcel,

A big thanks to you and the entire bioconductor team. I will spread the
word among my colleagues. I also noticed that the installation instructions
aren't adapted yet on the bioconductor site (
https://www.bioconductor.org/install/). Probably I'm just rushing here and
you are working on it, but I thought to inform you anyway as our courses
link to that website for official installation instructions.

Cheers
Joris

On Wed, Jun 20, 2018 at 6:23 PM, Marcel Ramos 
wrote:

> Dear bioc-devs,
>
>
> A month ago we notified you about our "next generation" changes to
> BiocInstaller.
>
> Thanks to all beta testers and those who provided feedback and
> suggestions for a new package name.
>
>
> I am pleased to inform you that BiocManager is now on CRAN:
> https://cran.r-project.org/web/packages/BiocManager/index.html
>
>
> As mentioned in our last email, you can now install BiocManager using:
>
> ```
> install.packages("BiocManager")
> BiocManager::install("YourPackageNameHere")
> ```
>
> Action Item:
>
>-   Please modify the vignettes in your bioc-devel packages to
> reflect the use of BiocManager
>
>
> After the next couple of weeks or so, we will be identifying packages in
> bioc-devel (3.8) that still
> mention BiocInstaller / biocLite.
>
>
> Best regards,
> Marcel
>
> Bioconductor Core Team
> Roswell Park Cancer Institute
> Dept. of Biostatistics & Bioinformatics
> Elm & Carlton Streets
> Buffalo, New York 14263
>
>
> On 05/09/2018 06:11 PM, Martin Morgan wrote:
> > Developers --
> >
> > A preliminary heads-up and request for comments.
> >
> > Almost since project inception, we've used the commands
> >
> >   source("https://bioconductor.org/biocLite.R;)
> >   biocLite(pkgs)
> >
> > to install packages. This poses security risks (e.g., typos in the
> > url) and deviates from standard R package installation procedures.
> >
> >
> > We'd like to move to a different system where a base package, call it
> > 'BiocManager', is installed from CRAN and used to install Bioconductor
> > packages
> >
> >   if (!"BiocManager" %in% rownames(installed.packages()))
> >   install.packages("BiocManager")
> >   BiocManager::install(pkgs)
> >
> > This establishes a secure chain from user R session to Bioconductor
> > package installation. It is also more consistent with base R package
> > installation procedures.
> >
> > BiocManager exposes four functions
> >
> >   - install() or update packages
> >
> >   - version() version of Bioconductor in use
> >
> >   - valid() are all Bioconductor packages from the same Bioconductor
> > version?
> >
> >   - repositories() url location for Bioconductor version-specific
> > repositories
> >
> > install() behaves like biocLite(), using the most current version of
> > Bioconductor for the version of R in use. It stores this state using a
> > Bioconductor package 'BiocVersion', which is nothing more than a
> > sentinel for the version in use. One can also 'use devel' or a
> > particular version of Bioconductor (consistent with the version of R)
> > with
> >
> >   BiocManager::install(version = "3.8")   # or the synonym "devel"
> >
> >
> > We intend to phase this in over several release cycles, and to
> > continue to support the traditional biocLite() route for versions
> > before BiocManager becomes available.
> >
> > We also intend to change the overall versioning of 'Bioconductor'
> > itself, where releases are always even (3.8, 3.10, 3.12, ...) and
> > 'devel' always odd.
> >
> > Obviously this is a large change, eventually requiring updates to many
> > locations on our web site and individual vignettes.
> >
> >
> > Of course the key question is the name of the 'BiocManager' package.
> > It cannot easily be 'BiocInstaller', because of the differences in way
> > CRAN and Bioconductor version packages. Some possible names are
> > '
> > BiocInstall::install()
> > BiocPackages::install()
> > BiocManager
> > BiocMaestro
> >
> >
> > Your comments are welcome...
> >
> > Martin
> >
> >
> > This email message may contain legally privileged and/or...{{dropped:2}}
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
> This email message may contain legally privileged and/or...{{dropped:4}}
&g

Re: [R-pkg-devel] Checksums changed on CRAN without any visible modifications to files.

[Joris Meys]

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=gmail=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=gmail=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.

[Joris Meys]

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=gmail=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.

[Joris Meys]

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=gmail=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: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

[Joris Meys]

On Tue, Jun 12, 2018 at 6:28 PM, Martin Maechler  wrote:

>
> I think we should allow 'year' to be "double" instead, and so it
> could also be +Inf or -Inf and we'd nicely cover
> the conversions from and to 'numeric' -- which is really used
> internally for dates and date-times in  POSIXct.
>
> Martin
>
>
That would be perfect and tackles both consistency with other formats and
the confusing print() output. 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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

[R-pkg-devel] Differences between documentation and CRAN requirements: an update needed?

[Joris Meys]

 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=gmail=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: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

[Joris Meys]

On Mon, Jun 11, 2018 at 11:12 AM, Martin Maechler <
maech...@stat.math.ethz.ch> wrote:

>
> and a Date vector *is* atomic .. (so I'm confused about what
> that issue is .. but read one.
>

Indeed. I tend to exclude everything with a formal class from "atomic" (eg
factors et al) because they do behave differently sometimes, but
technically that's not correct. Thank you for pointing that out.


> Indeed.  I could argue it is wrong to treat '+/- Inf' as NA for
> dates (as well as for date times), because the Inf *does*
> contain information in some sense:
>
>  Infinitely far in the future
> vs   Infinitely far in the past
>
> which may make sense in some case ... in the same sense +Inf and
> -Inf do make sense for numbers in some cases.
>
> Martin
>

I considered that too. But as shown in the code above: anything that relies
on POSIXlt to process the date, will actually convert the Inf value to NA.

The problem becomes a bit more confusing, as as.POSIXct() does not convert
to NA.

> x <-  as.Date(Inf, origin = '1970-01-01')
> is.na(x)
[1] FALSE
> is.na(as.POSIXct(x))
[1] FALSE
> is.na(as.POSIXlt(x))
[1] TRUE

I can guess why this happens. For a date that's infinitely far in the
future, it is impossible to determine an exact hour, minute, second, day,
month, ... So these values in the POSIXlt "list" format can't be anything
but NA.

So I totally understand the value of having Inf dates. The trade-off to
consider here is whether we strive for consistency among the different
datetime classes, or strive for correct representation of the actual value
of the date.

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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

[Joris Meys]

And now I've seen I copied the wrong part of ?is.na

> The default method for is.na applied to an atomic vector returns a
logical vector of the same length as its argument x, containing TRUE for
those elements marked NA or, for numeric or complex vectors, NaN, and FALSE
otherwise.

Key point being "atomic vector" here.


On Sat, Jun 9, 2018 at 1:41 PM, Joris Meys  wrote:

> Hi Werner,
>
> on ?is.na it says:
>
> > The default method for anyNA handles atomic vectors without a class and
> NULL.
>
> I hear you, and it is confusing to say the least. Looking deeper, the
> culprit seems to be in the conversion of a Date to POSIXlt prior to the
> formatting:
>
> > x <- as.Date(Inf,origin = '1970-01-01')
> > is.na(as.POSIXlt(x))
> [1] TRUE
>
> Given this implicit conversion, I'd argue that as.Date should really
> return NA as well when passed an infinite value. The other option is to
> provide an is.na method for the Date class, which is -given is.na is an
> internal generic- rather trivial:
>
> > is.na.Date <- function(x) is.na(as.POSIXlt(x))
> > is.na(x)
> [1] TRUE
>
> This might be a workaround for your current problem without needing
> changes to R itself. But this will give a "wrong" answer in the sense that
> this still works:
>
> > Sys.Date() - x
> Time difference of -Inf days
>
> I personally would go for NA as the "correct" date for an infinite value,
> but given that this will have implications in other areas, there is a
> possibility of breaking code and it should be investigated a bit further
> imho.
> Cheers
> Joris
>
>
>
>
> On Fri, Jun 8, 2018 at 11:21 PM, Werner Grundlingh 
> wrote:
>
>> Indeed. as_date is from lubridate, but the same holds for as.Date.
>>
>> The output and it's interpretation should be consistent, otherwise it
>> leads
>> to confusion when programming. I understand that the difference exists
>> after asking a question on Stack Overflow:
>>   https://stackoverflow.com/q/50766089/914686
>> This understanding is never mentioned in the documentation - that an Inf
>> date is actually represented as NA:
>>   https://www.rdocumentation.org/packages/base/versions/3.5.0/
>> topics/as.Date
>> So I'm of the impression that the display should be fixed as a first
>> option
>> (thereby providing clarity/transparency in terms of back-end and output),
>> or the documentation amended (to highlight this) as a second option.
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>
>
> ---
> 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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

[Joris Meys]

Hi Werner,

on ?is.na it says:

> The default method for anyNA handles atomic vectors without a class and
NULL.

I hear you, and it is confusing to say the least. Looking deeper, the
culprit seems to be in the conversion of a Date to POSIXlt prior to the
formatting:

> x <- as.Date(Inf,origin = '1970-01-01')
> is.na(as.POSIXlt(x))
[1] TRUE

Given this implicit conversion, I'd argue that as.Date should really return
NA as well when passed an infinite value. The other option is to provide an
is.na method for the Date class, which is -given is.na is an internal
generic- rather trivial:

> is.na.Date <- function(x) is.na(as.POSIXlt(x))
> is.na(x)
[1] TRUE

This might be a workaround for your current problem without needing changes
to R itself. But this will give a "wrong" answer in the sense that this
still works:

> Sys.Date() - x
Time difference of -Inf days

I personally would go for NA as the "correct" date for an infinite value,
but given that this will have implications in other areas, there is a
possibility of breaking code and it should be investigated a bit further
imho.
Cheers
Joris




On Fri, Jun 8, 2018 at 11:21 PM, Werner Grundlingh 
wrote:

> Indeed. as_date is from lubridate, but the same holds for as.Date.
>
> The output and it's interpretation should be consistent, otherwise it leads
> to confusion when programming. I understand that the difference exists
> after asking a question on Stack Overflow:
>   https://stackoverflow.com/q/50766089/914686
> This understanding is never mentioned in the documentation - that an Inf
> date is actually represented as NA:
>   https://www.rdocumentation.org/packages/base/versions/3.
> 5.0/topics/as.Date
> So I'm of the impression that the display should be fixed as a first option
> (thereby providing clarity/transparency in terms of back-end and output),
> or the documentation amended (to highlight this) as a second option.
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

[Bioc-devel] eval() and evalq() of BiocGenerics used in Rcpp causes segfault in some cases

[Joris Meys]

Dear all,

the following issue drew my attention. The new package "conflicted"
manipulates the search path and by doing so, highlighted that Rcpp is using
the BiocGenerics version of evalq() in case BiocGenerics is loaded.
Otherwise it uses the base version.

This is easily fixed in Rcpp by using base::evalq() - ( which will require
all packages based on Rcpp to be recompiled. )

I wondered whether there is code that expects Rcpp to use the dispatching
of the BiocGenerics version of eval() and that would fail after the fix is
applied. Honestly, imho it shouldn't, but better safe than sorry. If you
have pointers, I can check the patch in these contexts and hopefully
prevent possible problems before they arise.

Reference to the issue :
https://github.com/RcppCore/Rcpp/issues/861#issuecomment-395199660

Cheers

-- 
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=gmail=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]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] FW: [CRAN-pretest-archived] CRAN submission bwt 1.1.0

[Joris Meys]

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\khoongwh\Documents\bwt" --no-resave-data --no-manual
>> >
&g

Re: [Rd] CRAN checks give errors when no tests are included

[Joris Meys]

Never mind my previous mail. It was his local check, not CRAN. My apologies
for not paying enough attention.
Cheers
Joris

On Wed, May 30, 2018 at 5:33 PM, Joris Meys  wrote:

> Dear all,
>
> as a follow-up to the question asked on R-package-devel (see link below):
>
> Someone sent a package to CRAN with a few problems. There's more things
> wrong with the submission, but one thing that really caught my eye was the
> following error:
>
> Warning message:
> running command '"C:/PROGRA~1/R/R-33~1.2/bin/x64/R" CMD BATCH --vanilla
> "testthat.R" "testthat.Rout"' had status 1  ERROR Running the tests in
> 'tests/testthat.R' failed.
> Last 13 lines of output:
>
>   Type 'demo()' for some demos, 'help()' for on-line help, or
>   'help.start()' for an HTML browser interface to help.
>   Type 'q()' to quit R.
>
>   > library(testthat)
>   Warning message:
>   package 'testthat' was built under R version 3.3.3
>   > library(bwt)
>   >
>   > test_check("bwt")
>   Error: No tests found for bwt
>   Execution halted
> * DONE
>
> I checked the package and it had no tests subfolder. Yet -as far as I can
> judge- CRAN tried to run tests anyway and error'd when there were none to
> be found. This would make sense of adding tests was obligatory, but I can't
> find that back in the CRAN policies. Is this a hiccup at CRAN's side or am
> I missing something obvious?
>
> Cheers
> Joris
>
> link to the original mail on r-package-devel : https://stat.ethz.ch/
> pipermail/r-package-devel/2018q2/002782.html
>
> --
> 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=gmail=g>
>
> ---
> 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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

[Rd] CRAN checks give errors when no tests are included

[Joris Meys]

Dear all,

as a follow-up to the question asked on R-package-devel (see link below):

Someone sent a package to CRAN with a few problems. There's more things
wrong with the submission, but one thing that really caught my eye was the
following error:

Warning message:
running command '"C:/PROGRA~1/R/R-33~1.2/bin/x64/R" CMD BATCH --vanilla
"testthat.R" "testthat.Rout"' had status 1  ERROR Running the tests in
'tests/testthat.R' failed.
Last 13 lines of output:

  Type 'demo()' for some demos, 'help()' for on-line help, or
  'help.start()' for an HTML browser interface to help.
  Type 'q()' to quit R.

  > library(testthat)
  Warning message:
  package 'testthat' was built under R version 3.3.3
  > library(bwt)
  >
  > test_check("bwt")
  Error: No tests found for bwt
  Execution halted
* DONE

I checked the package and it had no tests subfolder. Yet -as far as I can
judge- CRAN tried to run tests anyway and error'd when there were none to
be found. This would make sense of adding tests was obligatory, but I can't
find that back in the CRAN policies. Is this a hiccup at CRAN's side or am
I missing something obvious?

Cheers
Joris

link to the original mail on r-package-devel :
https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002782.html

-- 
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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] FW: [CRAN-pretest-archived] CRAN submission bwt 1.1.0

[Joris Meys]

tensions' 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=gmail=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

[Joris Meys]

On Thu, May 24, 2018 at 10:11 PM, Steven Spiriti <puzzleste...@gmail.com>
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=gmail=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: [Rd] Creating S3 methods for S4 classes (coming from r-package-devel)

[Joris Meys]

On Thu, May 24, 2018 at 6:20 PM, Michael Lawrence <lawrence.mich...@gene.com
> wrote:

> You only have to make an S4 method if there is already an S4 generic.
> If there is just an S3 generic, then just define S3 methods on it.


I was refering to the recommendations in ?Methods_for_S3 (
https://stat.ethz.ch/R-manual/R-devel/library/methods/html/Methods_for_S3.html).
:

"Two possible mechanisms for implementing a method corresponding to an S4
class, there are two possibilities are to register it as an S3 method with
the S4 class name or to define and set an S4 method, which will have the
side effect of creating an S4 generic version of this function.

For most situations either works, but the recommended approach is to do
both:"

The reasoning is described there as well, and I have no reason to believe
that information is not up to date. I can get away with defining an S3
generic, but this stops being useful when using superclasses for reasons
mentioned in the documentation.

I
> think we should stay away from defining S4 generics when there is no
> good reason for them. Good reasons include multiple dispatch, or a
> non-default signature. Neither of those apply in this case.
>

I would personally prefer to use dispatching that's tailored to the type of
class I work with, as that seems more consistent. But I agree we should
avoid defining generics for the same function in different packages, hence
my proposal about stats4.


-- 
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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

[Rd] Creating S3 methods for S4 classes (coming from r-package-devel)

[Joris Meys]

 Dear all,

I asked this question on r-package-devel but Martin Maechler pointed out
this was more suited on R-devel. So here it goes:

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

(Original mail on r-package-devel :
https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002757.html )


-- 
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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

[R-pkg-devel] Creating S3 methods for S4 classes

[Joris Meys]

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=gmail=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?

[Joris Meys]

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=gmail=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: [Bioc-devel] Package download when using functions from affy and oligo

[Joris Meys]

Dear all,

sorry for the delayed response, due to some unfortunate events I had to
prioritize my family the past week.

You find an RStudio project in a zipped folder on this link :
https://jorismeys.stackstorage.com/s/3ik0vMwsvueuT5a

It contains a script called testOligo.R that can be sourced and nukes my R
session in the second step of the rma() function. It also contains the
faulty .gz files. If you need more information, don't hesitate to contact
me.

Regarding improving general maintainability, I'm willing to help out on
that. Problem is that I'm rather behind with my own work, so I'm short on
time for the moment. I'll fork affy tomorrow (need to give class now) and
let's start from there then?

Cheers
Joris



On Sat, May 5, 2018 at 5:17 PM, Vincent Carey <st...@channing.harvard.edu>
wrote:

> How about a google drive?  This problem of autodownloading should be
> addressed directly.
> These facilities are still important but their maintenance is clearly a
> lower priority as the
> technologies handled have diminished use in the field.  I think we should
> be able to team up and remove autoinstallation elements of these packages,
> and
> perhaps improve general maintainability -- Joris, can you pick
> one, make a github repo that we can collaborate on revising, and then
> we can start?  It will involve a deprecation process.
>
> On Sat, May 5, 2018 at 10:54 AM, Joris Meys <jorism...@gmail.com> wrote:
>
>> Thank you for the answer.
>>
>> I was trying to create a reproducible example before I vented maybe a bit
>> too much in my previous mail.
>>
>> I managed to get closer to the problem and it is related to data that was
>> corrupted at download. I can send you a reproducible example that bombs R,
>> but I will have to send the specific data files as well. How do I send
>> them
>> best?
>>
>> Cheers
>> Joris
>>
>> On Sat, 5 May 2018, 00:09 James W. MacDonald, <jmac...@uw.edu> wrote:
>>
>> > I think there are multiple complaints here, so I'll take them one at a
>> > time.
>> >
>> > On Fri, May 4, 2018 at 3:56 PM, Obenchain, Valerie <
>> > valerie.obench...@roswellpark.org> wrote:
>> >
>> >> Joris,
>> >>
>> >> Sorry I don't have much to offer here. I've cc'd the authors of oligo
>> and
>> >> affy who may have some insight.
>> >>
>> >> Valerie
>> >>
>> >>
>> >> On 05/02/2018 11:35 AM, Joris Meys wrote:
>> >>
>> >> Dear,
>> >>
>> >> I've noticed that using certain functions in affy and oligo (eg
>> >> oligo::read.celfiles and affy::bg.correct) start with downloading
>> another
>> >> package and end with either R crashing or a warning that -after
>> >> installation succeeded- the package is not available.
>> >
>> >
>> > This is true for oligo, and perhaps a bit annoying. If you don't have
>> the
>> > package installed already, it gets the package, installs it, and then
>> says
>> > it's not available. This is an easy enough fix.
>> >
>> >
>> > After which using
>> >> some functions of both packages still crash R.
>> >>
>> >
>> > I don't know what to do with that. What functions?
>> >
>> >
>> >>
>> >> The warning I get when trying oligo::read.celfiles() on a single CEL
>> file
>> >> right after installing it about the pd.hugene.1.0.st.v1 package. The
>> even
>> >> more annoying thing is that on my machine it insists on building from
>> >> source, whereas on another Windows machine without Rtools, it
>> downloads a
>> >> binary.
>> >>
>> >
>> > That is an options setting that gets changed when you install Rtools.
>> The
>> > 'pkgType' option gets set to 'both' because you can now install both
>> kinds.
>> > And in install.packages it ends up getting switched from 'both' to
>> > 'source'. I haven't dug any further into that because I am not sure I
>> see
>> > why it's a problem. In the end there isn't a difference between
>> installing
>> > a source or a binary pdInfoPackage, and trying to get it to 'do the
>> right
>> > thing' might have some unforeseen consequences that I would rather not
>> have
>> > to worry about. This is really an 'if it ain't broke, don't fix it'
>> > scenario, IMO.
>> >
>> >
>> >
>> >>
>> >> Reason it frustrates the heck out of me, is that both affy and olig

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[Joris Meys]

I can confirm that Excel does all kind of strange things when opening a csv
file and saving it from Excel, including adding unnecessarily another set
of quotes around already qouted text fields. But I never had problems with
Excel not getting linux-type line endings correctly. I'll see if I can make
Excel mess it up, but given the amount of excel crap I had to endure over
the years, I'd be surprised if I missed such behaviour until now.

Cheers
Joris

On Wed, May 9, 2018 at 3:09 PM, peter dalgaard <pda...@gmail.com> wrote:

> There was a hint in the Twitterverse that Excel has issues with line
> endings in .csv. Can anyone elaborate on that? Then again, Excel goes
> belly-up on comma separators in central European locales anyway...
>
> -pd
>
> > On 8 May 2018, at 22:47 , Hadley Wickham <h.wick...@gmail.com> wrote:
> >
> >
> > Also note that MS just announced support for unix line endings in notepad
> >
> > https://blogs.msdn.microsoft.com/commandline/2018/05/08/
> extended-eol-in-notepad/
> >
> > Hadley
> >
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] CRAN R 3.5 binary - where is it?

[Joris Meys]

As Herve also indicated already, your best shot is the R-SIG-Debian list
for questions on debian like systems. That said, the maintainer Michael
Rutter announced the 3.5 binaries for all supported Ubuntu distros a few
weeks ago, but they're not on CRAN. For some reason not completely clear to
me, they reside at a launchpad now:

https://launchpad.net/~marutter/+archive/ubuntu/rrutter3.5

So you have to add that repo to the repolist using apt add-repository as
explained on the link above, and then the installation procedure is the
same as explained on the CRAN page Herve linked you to :

https://cran.r-project.org/bin/linux/ubuntu/

Cheers
Joris

On Thu, May 10, 2018 at 9:13 PM, Kenneth Condon <roonysga...@gmail.com>
wrote:

> Hi all,
>
> It sounds like the best thing to do is go back to the original binary and
> remove the source installation.
>
> Clarice, you know I can't even remember if I did that - I think I might try
> fix the current dependency issue tomorrow, but if any more come up, Ill go
> back to the begining do as you suggested with the binary again.
>
> Herve, the link I provided has R3.4.4 .deb binaries from 2018 - not sure
> where you are getting the 2014 from.
>
> Thanks,
> Kenneth
>
> On Thu, May 10, 2018 at 7:43 PM, Clarice Groeneveld <
> clari.groenev...@gmail.com> wrote:
>
> > Hi Kenneth,
> >
> > I see you're on Ubuntu 14.04. Have you tried in Terminal:
> > sudo apt-get update
> > sudo apt-get upgrade
> >
> > to upgrade your R version?
> >
> > Best,
> > Clarice.
> >
> > Em qui, 10 de mai de 2018 às 14:20, Kenneth Condon <
> roonysga...@gmail.com>
> > escreveu:
> >
> >> Hi all,
> >>
> >> I want to submit a package to bioconductor this week but first I want to
> >> build it on the latest R 3.5 release (with bioconductor 3.7). However,
> >> CRAN
> >> only has 3.4 binaries
> >> <https://cran.r-project.org/bin/linux/ubuntu/trusty/?C=N;O=A> so I've
> had
> >> to build 3.5 from source which has unfortunately sent me to dependency
> >> hell.
> >>
> >> Rather than spending the next 3 days fixing all dependencies, does
> anyone
> >> know when the 3.5 dependency is likely to surface?
> >>
> >> I think bioconductor 3.7 cannot be installed on R 3.4 so any advice
> would
> >> be appreciated.
> >>
> >> Thanks,
> >> Kenneth.
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-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=gmail=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]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[Joris Meys]

Martin, also from me a heartfelt thank you for taking care of this. Some
thoughts on Henrik's response:

On Mon, May 7, 2018 at 2:28 AM, Henrik Bengtsson <henrik.bengts...@gmail.com
> wrote:

>
> I still argue that the current behavior cause more harm than it helps.
>

I agree with your analysis of the problems this legacy behaviour causes.

Deprecating the default mode="w" on Windows can be done in steps, e.g.
> by making the argument mandatory for a while. This could be done on
> all platforms because we're already all affected, i.e. we need to
> specify 'mode' to avoid surprises.
>

That sounds like a reasonable way to move away from this discrepancy
between OS.


> What about case-insensitive matching, e.g. data.ZIP and data.Rdata?
>

Totally agree, and easily solved by eg adding ignore.case = TRUE to the
grep() call.


> A quick scan of the R source code suggests that R is also working with
> the following filename extensions (using various case styles):
>
> What about all the other file extensions that we know for sure are binary?
>

If the default isn't changed, doesn't it make more sense to actually turn
the logic around? Text files that are downloaded over the internet are
almost always .txt, .csv, or a few other extensions used for text data .
Those are actually the only files where some people with very old Windows
programs for text processing can get into trouble. So instead of adding
every possible binary extension, one can put "wb" as default and change to
"w" if it is a text file instead of the other way around. That would not
change the concept of the behaviour, but ensures that the function doesn't
fail to detect a binary file. Not detecting a text file is far less of a
problem, as not converting the line endings doesn't destruct the file.

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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Package download when using functions from affy and oligo

[Joris Meys]

Thank you for the answer.

I was trying to create a reproducible example before I vented maybe a bit
too much in my previous mail.

I managed to get closer to the problem and it is related to data that was
corrupted at download. I can send you a reproducible example that bombs R,
but I will have to send the specific data files as well. How do I send them
best?

Cheers
Joris

On Sat, 5 May 2018, 00:09 James W. MacDonald, <jmac...@uw.edu> wrote:

> I think there are multiple complaints here, so I'll take them one at a
> time.
>
> On Fri, May 4, 2018 at 3:56 PM, Obenchain, Valerie <
> valerie.obench...@roswellpark.org> wrote:
>
>> Joris,
>>
>> Sorry I don't have much to offer here. I've cc'd the authors of oligo and
>> affy who may have some insight.
>>
>> Valerie
>>
>>
>> On 05/02/2018 11:35 AM, Joris Meys wrote:
>>
>> Dear,
>>
>> I've noticed that using certain functions in affy and oligo (eg
>> oligo::read.celfiles and affy::bg.correct) start with downloading another
>> package and end with either R crashing or a warning that -after
>> installation succeeded- the package is not available.
>
>
> This is true for oligo, and perhaps a bit annoying. If you don't have the
> package installed already, it gets the package, installs it, and then says
> it's not available. This is an easy enough fix.
>
>
> After which using
>> some functions of both packages still crash R.
>>
>
> I don't know what to do with that. What functions?
>
>
>>
>> The warning I get when trying oligo::read.celfiles() on a single CEL file
>> right after installing it about the pd.hugene.1.0.st.v1 package. The even
>> more annoying thing is that on my machine it insists on building from
>> source, whereas on another Windows machine without Rtools, it downloads a
>> binary.
>>
>
> That is an options setting that gets changed when you install Rtools. The
> 'pkgType' option gets set to 'both' because you can now install both kinds.
> And in install.packages it ends up getting switched from 'both' to
> 'source'. I haven't dug any further into that because I am not sure I see
> why it's a problem. In the end there isn't a difference between installing
> a source or a binary pdInfoPackage, and trying to get it to 'do the right
> thing' might have some unforeseen consequences that I would rather not have
> to worry about. This is really an 'if it ain't broke, don't fix it'
> scenario, IMO.
>
>
>
>>
>> Reason it frustrates the heck out of me, is that both affy and oligo
>> crashed the R session in different ways. During installation of a package,
>> during use of a function, and at different points when comparing my
>> machine
>> with the one of our students. The culprit seems to be in one of the
>> underlying packages, but I wasn't even able to detect which package is the
>> culprit, let alone which function crashes everything.
>>
>
> I understand your frustration, but that's not enough to go on. I have
> never, in like 18 years, had either oligo or affy randomly segfault on me.
> I understand that it is happening for you, but unless you can come up with
> a reproducible example, it's not possible for anybody to help.
>
>
>>
>> Is there a way around this so I can ensure that at least I have the same
>> setup as they have and I can try to come up with a reproducible example to
>> report this critical bug?
>>
>
> Again, I am not sure what to do with that. I am not sure what 'a way
> around this' pertains to, and ensuring you have the same setup as 'they
> have' seems to be something only you can accomplish. Is there some reason
> you cannot ensure that you have the same setup on two different computers?
>
> Best,
>
> Jim
>
>
>>
>> Thank you in advance
>> Joris
>>
>>
>>
>>
>>
>> This email message may contain legally privileged and/or confidential
>> information.  If you are not the intended recipient(s), or the employee or
>> agent responsible for the delivery of this message to the intended
>> recipient(s), you are hereby notified that any disclosure, copying,
>> distribution, or use of this email message is prohibited.  If you have
>> received this message in error, please notify the sender immediately by
>> e-mail and delete this email message from your computer. Thank you.
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
>
> --
> James W. MacDonald, M.S.
> Biostatistician
> University of Washington
> Environmental and Occupational Health Sciences
> 4225 Roosevelt Way NE, # 100
> Seattle WA 98105-6099
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] length of `...`

[Joris Meys]

>> g(...)
> >>> }
> >>> g <- function(...) {
> >>> firstExpr <- substitute(...())[[1]]
> >>> c(list(...)[[1]], eval(firstExpr, envir = parent.frame()))
> >>> }
> >>>
> >>> Calling g(x) correctly prints "global" twice, but calling f(x)
> incorrectly
> >>> prints
> >>>
> >>> [1] "global" "f"
> >>>
> >>> You can get the first element of ... without evaluating the rest
> using ..1,
> >>> but I don't know a way to do this for general n in pre-3.5.0 base
> R.
> >>
> >> If you don't mind using a package:
> >>
> >> # works with R 3.1 and up
> >> library(rlang)
> >>
> >> x <- "global"
> >> f <- function(...) {
> >> x <- "f"
> >> g(...)
> >> }
> >> g <- function(...) {
> >> dots <- enquos(...)
> >> eval_tidy(dots[[1]])
> >> }
> >>
> >> f(x, stop("!"))
> >> #> [1] "global"
> >> g(x, stop("!"))
> >> #> [1] "global"
> >>
> >> Hadley
> >>
>
> > --
> > Hervé Pagès
>
> > Program in Computational Biology
> > Division of Public Health Sciences
> > Fred Hutchinson Cancer Research Center
> > 1100 Fairview Ave. N, M1-B514
> > P.O. Box 19024
> > Seattle, WA 98109-1024
>
> > E-mail: hpa...@fredhutch.org
> > Phone:  (206) 667-5791
> > Fax:(206) 667-1319
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[Joris Meys]

On Fri, May 4, 2018 at 8:34 AM, Tomas Kalibera <tomas.kalib...@gmail.com>
wrote:

> The current heuristic/hack is in line with the compatibility approach: it
> detects files that are obviously binary, so it changes the default behavior
> only for cases when it would obviously cause damage.
>
> Tomas


Well, I was trying to download a .gz file and download.file() didn't detect
that. Reason for that is obviously that the link doesn't contain .gz but
%2Egz , using the ASCII code for the dot instead of the dot itself. That's
general practice in a lot of links.

Hence I propose to change the line in download.file() that does this check
to:

  if (missing(mode) && length(grep("\\.(gz|bz2|xz|tgz|zip|rda|RData)$",
   URLdecode(url

using URLdecode() ensures that .gz, .RData etc will be detected correctly
in an encoded URL.

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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Strange error for windows build

[Joris Meys]

These functions all come from the stringi package. My first thought wpuld
be a namespace conflict.
Cheers
Joris

On Thu, 3 May 2018, 18:58 Christopher John, 
wrote:

> Dear Bioconductor
>
> I am getting a new weird error from today I think with my M3C package:
>
> http://bioconductor.org/packages/3.7/bioc/html/M3C.html
>
> Error in namespaceExport(ns, exports) :
>   undefined exports: %s!=%, %s!==%, %s+%, %s<%, %s<=%, %s==%, %s===%,
> %s>%, %s>=%, %stri!=%, %stri!==%, %stri+%, %stri<%, %stri<=%,
> %stri==%, %stri===%, %stri>%, %stri>=%, stri_datetime_add<-,
> stri_sub<-, stri_subset<-, stri_subset_charclass<-,
> stri_subset_coll<-, stri_subset_fixed<-, stri_subset_regex<-, stri_c,
> stri_c_list, stri_cmp, stri_cmp_eq, stri_cmp_equiv, stri_cmp_ge,
> stri_cmp_gt, stri_cmp_le, stri_cmp_lt, stri_cmp_neq, stri_cmp_nequiv,
> stri_compare, stri_conv, stri_count, stri_count_boundaries,
> stri_count_charclass, stri_count_coll, stri_count_fixed,
> stri_count_regex, stri_count_words, stri_datetime_add,
> stri_datetime_create, stri_datetime_fields, stri_datetime_format,
> stri_datetime_fstr, stri_datetime_now, stri_datetime_parse,
> stri_datetime_symbols, stri_detect, stri_detect_charclass,
> stri_detect_coll, stri_detect_fixed, stri_detect_regex, stri_dup,
> stri_duplicated, stri_duplicated_any, stri_enc_detect,
> stri_enc_detect2, stri_enc_fromutf32, stri_enc_get, stri_enc_info,
> stri_enc_isascii, stri_enc_isutf16be, stri_enc_isutf16le,
> stri_enc_isutf32be, stri_enc_isutf32le, stri_enc_isutf8,
> stri_enc_list, stri_enc_mark, stri_enc_set, stri_enc_toascii,
> stri_enc_tonative, stri_enc_toutf32, stri_enc_toutf8, stri_encode,
> stri_endswith, stri_endswith_charclass, stri_endswith_coll,
> stri_endswith_fixed, stri_escape_unicode, stri_extract,
> stri_extract_all, stri_extract_all_boundaries,
> stri_extract_all_charclass, stri_extract_all_coll,
> stri_extract_all_fixed, stri_extract_all_regex,
> stri_extract_all_words, stri_extract_first,
> stri_extract_first_boundaries, stri_extract_first_charclass,
> stri_extract_first_coll, stri_extract_first_fixed,
> stri_extract_first_regex, stri_extract_first_words, stri_extract_last,
> stri_extract_last_boundaries, stri_extract_last_charclass,
> stri_extract_last_coll, stri_extract_last_fixed,
> stri_extract_last_regex, stri_extract_last_words, stri_flatten,
> stri_info, stri_isempty, stri_join, stri_join_list, stri_length,
> stri_list2matrix, stri_locale_get, stri_locale_info, stri_locale_list,
> stri_locale_set, stri_locate, stri_locate_all,
> stri_locate_all_boundaries, stri_locate_all_charclass,
> stri_locate_all_coll, stri_locate_all_fixed, stri_locate_all_regex,
> stri_locate_all_words, stri_locate_first,
> stri_locate_first_boundaries, stri_locate_first_charclass,
> stri_locate_first_coll, stri_locate_first_fixed,
> stri_locate_first_regex, stri_locate_first_words, stri_locate_last,
> stri_locate_last_boundaries, stri_locate_last_charclass,
> stri_locate_last_coll, stri_locate_last_fixed, stri_locate_last_regex,
> stri_locate_last_words, stri_match, stri_match_all,
> stri_match_all_regex, stri_match_first, stri_match_first_regex,
> stri_match_last, stri_match_last_regex, stri_na2empty, stri_numbytes,
> stri_opts_brkiter, stri_opts_collator, stri_opts_fixed,
> stri_opts_regex, stri_order, stri_pad, stri_pad_both, stri_pad_left,
> stri_pad_right, stri_paste, stri_paste_list, stri_rand_lipsum,
> stri_rand_shuffle, stri_rand_strings, stri_read_lines, stri_read_raw,
> stri_remove_empty, stri_replace, stri_replace_all,
> stri_replace_all_charclass, stri_replace_all_coll,
> stri_replace_all_fixed, stri_replace_all_regex, stri_replace_first,
> stri_replace_first_charclass, stri_replace_first_coll,
> stri_replace_first_fixed, stri_replace_first_regex, stri_replace_last,
> stri_replace_last_charclass, stri_replace_last_coll,
> stri_replace_last_fixed, stri_replace_last_regex, stri_replace_na,
> stri_reverse, stri_sort, stri_split, stri_split_boundaries,
> stri_split_charclass, stri_split_coll, stri_split_fixed,
> stri_split_lines, stri_split_lines1, stri_split_regex,
> stri_startswith, stri_startswith_charclass, stri_startswith_coll,
> stri_startswith_fixed, stri_stats_general, stri_stats_latex, stri_sub,
> stri_subset, stri_subset_charclass, stri_subset_coll,
> stri_subset_fixed, stri_subset_regex, stri_timezone_get,
> stri_timezone_info, stri_timezone_list, stri_timezone_set,
> stri_trans_char, stri_trans_general, stri_trans_isnfc,
> stri_trans_isnfd, stri_trans_isnfkc, stri_trans_isnfkc_casefold,
> stri_trans_isnfkd, stri_trans_list, stri_trans_nfc, stri_trans_nfd,
> stri_trans_nfkc, stri_trans_nfkc_casefold, stri_trans_nfkd,
> stri_trans_tolower, stri_trans_totitle, stri_trans_toupper, stri_trim,
> stri_trim_both, stri_trim_left, stri_trim_right,
> stri_unescape_unicode, stri_unique, stri_width, stri_wrap,
> stri_write_lines
> ERROR: lazy loading failed for package 'M3C'
> * removing
> 

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[Joris Meys]

Thank you Henrik and Martin for explaining what was going on. Very
insightful!

On Thu, May 3, 2018 at 4:21 PM, Jeroen Ooms <jeroeno...@gmail.com> wrote:

> On Thu, May 3, 2018 at 2:42 PM, Henrik Bengtsson
> <henrik.bengts...@gmail.com> wrote:
> > Use mode="wb" when you download the file. See
> > https://github.com/HenrikBengtsson/Wishlist-for-R/issues/30.
> >
> > R core, and others, is there a good argument for why we are not making
> this
> > the default download mode? It seems like a such a simple fix to such a
> > common "mistake".
>
> I'd like to second this feature request. This default behaviour is
> unexpected and often leads to r scripts that were written on
> mac/linux, to produce corrupted files on windows, checksum mismatches,
> etc.
>
> Even for text files, the default should be to download the file as-is.
> Trying to "fix" line-endings should be opt-in, never the default.
> Downloading a file via a browser or ftp client on windows also doesn't
> change the file, why should R?
>

I third the feature request.


>
>
> On Thu, May 3, 2018 at 3:02 PM, Duncan Murdoch <murdoch.dun...@gmail.com>
> wrote:
> > Many downloads are text files (HTML, CSV, etc.), and if those are
> downloaded
> > in binary, a Windows user might end up with a file that Notepad can't
> > handle, because it would have Unix-style line endings.
>
> True but I don't think this is relevant. The same holds e.g. for the R
> files in source packages, which also have unix line endings. Most
> Windows users will use an actual editor that understands both types of
> line endings, or can convert between the two.
>
> Downloading-file should do just that.
>

Again, I agree. In my (limited) experience the only program that fails to
properly display \n as a line ending, is Notepad. But it can still open the
file regardless. If line ending conflicts cause bugs, it's almost always a
unix-like OS struggling with Windows-style endings. I have yet to meet the
first one the other way around.

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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[Joris Meys]

Dear all,

I've been diving a bit deeper into this per request of Tomas Kalibra, and
found the following :

- the lock on the file is only after trying to read it using oligo, so
that's not a R problem in itself. The problem is independent of extrenal
packages.

- using Windows' fc utility and cygwin's cmp utility I found out that every
so often the download.file() function inserts an extra byte. There's no
real obvious pattern in how these bytes are added, but the file downloaded
using download.file() is actually larger (in this case by about 8 kb). The
file xxx_inR.CEL.gz is read in using:

setwd("E:/Temp/genexpr/Compare")
id <- "GSM907854"
flink <- paste0("
https://www.ncbi.nlm.nih.gov/geo/download/?acc=GSM907854=file=GSM907854%2ECEL%2Egz
")
fname <- paste0(id,"_inR.CEL.gz")
download.file(flink,
  destfile = fname)

The file xxx_direct.CEL.gz is downloaded from
https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSM907854 (download link
at the bottom of the page).

Output of dir in CMD:

05/03/2018  11:02 AM 4,529,547 GSM907854_direct.CEL.gz
05/03/2018  11:17 AM 4,537,668 GSM907854_inR.CEL.gz

or from R :

> diff(file.size(dir())) # contains both CEL files.
[1] 8121

Strangely enough I get the following message from download.file() :

Content type 'application/octet-stream' length 4529547 bytes (4.3 MB)
downloaded 4.3 MB

So the reported length is exactly the same as if I would download the file
directly, but the file on disk itself is larger. So it seems
download.file() is adding bytes when saving the data on disk.  This
behaviour is independent of antivirus and/or firewalls turned on or off.

Also keep in mind that these are NOT standard gzipped files. These files
are a specific format for Affymetrix Human Gene 1.0 ST Arrays.

If I need to run other tests, please let me know.
Kind regards

Joris

On Wed, May 2, 2018 at 9:21 PM, Joris Meys <jorism...@gmail.com> wrote:

> Dear all,
>
> I've noticed by trying to download gz files from here :
> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSM907811
>
> At the bottom one can download GSM907811.CEL.gz . If I download this
> manually and try
>
> oligo::read.celfiles("GSM907811.CEL.gz")
>
> everything works fine. (oligo is a bioConductor package)
>
> However, if I download using
>
> download.file("https://www.ncbi.nlm.nih.gov/geo/download/
> ?acc=GSM907811=file=GSM907811%2ECEL%2Egz",
>   destfile = "GSM907811.CEL.gz")
>
> The file is downloaded, but oligo::read.celfiles() returns the following
> error:
>
> Error in checkChipTypes(filenames, verbose, "affymetrix", TRUE) :
>   End of gz file reached unexpectedly. Perhaps this file is truncated.
>
> Moreover, if I try to delete it after using download.file(), I get a
> warning that permission is denied. I can only remove it using Windows file
> explorer after I closed the R session, indicating that the connection is
> still open. Yet, showConnections() doesn't show any open connections either.
>
> Session info below. Note that I started from a completely fresh R session.
> oligo is needed due to the specific file format of these gz files. They're
> not standard tarred files.
>
> Cheers
> Joris
>
> Session Info
> 
> -
>
> R version 3.5.0 (2018-04-23)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows >= 8 x64 (build 9200)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=English_United Kingdom.1252  LC_CTYPE=English_United
> Kingdom.1252
> [3] LC_MONETARY=English_United Kingdom.1252 LC_NUMERIC=C
>
> [5] LC_TIME=English_United Kingdom.1252
>
> attached base packages:
> [1] stats4parallel  stats graphics  grDevices utils datasets
> methods
> [9] base
>
> other attached packages:
>  [1] pd.hugene.1.0.st.v1_3.14.1 DBI_0.8
> oligo_1.44.0
>  [4] Biobase_2.39.2 oligoClasses_1.42.0
> RSQLite_2.1.0
>  [7] Biostrings_2.48.0  XVector_0.19.9
> IRanges_2.13.28
> [10] S4Vectors_0.17.42  BiocGenerics_0.25.3
>
> loaded via a namespace (and not attached):
>  [1] Rcpp_0.12.16compiler_3.5.0
>  [3] BiocInstaller_1.30.0GenomeInfoDb_1.15.5
>  [5] bitops_1.0-6iterators_1.0.9
>  [7] tools_3.5.0 zlibbioc_1.25.0
>  [9] digest_0.6.15   bit_1.1-12
> [11] memoise_1.1.0   preprocessCore_1.41.0
> [13] lattice_0.20-35 ff_2.2-13
> [15] pkgconfig_2.0.1 Matrix_1.2-14
> [17] foreach_1.4.4   DelayedArray_0.5.31
> [19] yaml_2.1.18 GenomeInfoDbData_1.1.0
> [21] affxparser_1.52.0   

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[Joris Meys]

Using the correct mode absolutely solves it. Apologies for not trying the
obvious.

Cheers
Joris

On Thu, May 3, 2018 at 2:10 PM, Martin Morgan <martin.mor...@roswellpark.org
> wrote:

>
>
> On 05/02/2018 03:21 PM, Joris Meys wrote:
>
>> Dear all,
>>
>> I've noticed by trying to download gz files from here :
>> https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSM907811
>>
>> At the bottom one can download GSM907811.CEL.gz . If I download this
>> manually and try
>>
>> oligo::read.celfiles("GSM907811.CEL.gz")
>>
>> everything works fine. (oligo is a bioConductor package)
>>
>> However, if I download using
>>
>> download.file("
>> https://www.ncbi.nlm.nih.gov/geo/download/?acc=GSM907811
>> mat=file=GSM907811%2ECEL%2Egz
>> ",
>>destfile = "GSM907811.CEL.gz")
>>
>
> On windows, the 'mode' argument to download.file() needs to be "wb" (write
> binary) for binary files.
>
> Martin
>
>
>> The file is downloaded, but oligo::read.celfiles() returns the following
>> error:
>>
>> Error in checkChipTypes(filenames, verbose, "affymetrix", TRUE) :
>>End of gz file reached unexpectedly. Perhaps this file is truncated.
>>
>> Moreover, if I try to delete it after using download.file(), I get a
>> warning that permission is denied. I can only remove it using Windows file
>> explorer after I closed the R session, indicating that the connection is
>> still open. Yet, showConnections() doesn't show any open connections
>> either.
>>
>> Session info below. Note that I started from a completely fresh R session.
>> oligo is needed due to the specific file format of these gz files. They're
>> not standard tarred files.
>>
>> Cheers
>> Joris
>>
>> Session Info
>> 
>> -
>>
>> R version 3.5.0 (2018-04-23)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows >= 8 x64 (build 9200)
>>
>> Matrix products: default
>>
>> locale:
>> [1] LC_COLLATE=English_United Kingdom.1252  LC_CTYPE=English_United
>> Kingdom.1252
>> [3] LC_MONETARY=English_United Kingdom.1252
>> LC_NUMERIC=C
>> [5] LC_TIME=English_United Kingdom.1252
>>
>> attached base packages:
>> [1] stats4parallel  stats graphics  grDevices utils datasets
>> methods
>> [9] base
>>
>> other attached packages:
>>   [1] pd.hugene.1.0.st.v1_3.14.1 DBI_0.8
>> oligo_1.44.0
>>   [4] Biobase_2.39.2 oligoClasses_1.42.0
>> RSQLite_2.1.0
>>   [7] Biostrings_2.48.0  XVector_0.19.9
>> IRanges_2.13.28
>> [10] S4Vectors_0.17.42  BiocGenerics_0.25.3
>>
>> loaded via a namespace (and not attached):
>>   [1] Rcpp_0.12.16compiler_3.5.0
>>   [3] BiocInstaller_1.30.0GenomeInfoDb_1.15.5
>>   [5] bitops_1.0-6iterators_1.0.9
>>   [7] tools_3.5.0 zlibbioc_1.25.0
>>   [9] digest_0.6.15   bit_1.1-12
>> [11] memoise_1.1.0   preprocessCore_1.41.0
>> [13] lattice_0.20-35 ff_2.2-13
>> [15] pkgconfig_2.0.1 Matrix_1.2-14
>> [17] foreach_1.4.4   DelayedArray_0.5.31
>> [19] yaml_2.1.18 GenomeInfoDbData_1.1.0
>> [21] affxparser_1.52.0   bit64_0.9-7
>> [23] grid_3.5.0  BiocParallel_1.13.3
>> [25] blob_1.1.1  codetools_0.2-15
>> [27] matrixStats_0.53.1  GenomicRanges_1.31.23
>> [29] splines_3.5.0   SummarizedExperiment_1.9.17
>> [31] RCurl_1.95-4.10 affyio_1.49.2
>>
>>
>>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. 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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

[Rd] download.file does not process gz files correctly (truncates them?)

[Joris Meys]

Dear all,

I've noticed by trying to download gz files from here :
https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSM907811

At the bottom one can download GSM907811.CEL.gz . If I download this
manually and try

oligo::read.celfiles("GSM907811.CEL.gz")

everything works fine. (oligo is a bioConductor package)

However, if I download using

download.file("
https://www.ncbi.nlm.nih.gov/geo/download/?acc=GSM907811=file=GSM907811%2ECEL%2Egz
",
  destfile = "GSM907811.CEL.gz")

The file is downloaded, but oligo::read.celfiles() returns the following
error:

Error in checkChipTypes(filenames, verbose, "affymetrix", TRUE) :
  End of gz file reached unexpectedly. Perhaps this file is truncated.

Moreover, if I try to delete it after using download.file(), I get a
warning that permission is denied. I can only remove it using Windows file
explorer after I closed the R session, indicating that the connection is
still open. Yet, showConnections() doesn't show any open connections either.

Session info below. Note that I started from a completely fresh R session.
oligo is needed due to the specific file format of these gz files. They're
not standard tarred files.

Cheers
Joris

Session Info
-

R version 3.5.0 (2018-04-23)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

locale:
[1] LC_COLLATE=English_United Kingdom.1252  LC_CTYPE=English_United
Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252
LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252

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

other attached packages:
 [1] pd.hugene.1.0.st.v1_3.14.1 DBI_0.8
oligo_1.44.0
 [4] Biobase_2.39.2 oligoClasses_1.42.0
RSQLite_2.1.0
 [7] Biostrings_2.48.0  XVector_0.19.9
IRanges_2.13.28
[10] S4Vectors_0.17.42  BiocGenerics_0.25.3

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.16compiler_3.5.0
 [3] BiocInstaller_1.30.0GenomeInfoDb_1.15.5
 [5] bitops_1.0-6iterators_1.0.9
 [7] tools_3.5.0 zlibbioc_1.25.0
 [9] digest_0.6.15   bit_1.1-12
[11] memoise_1.1.0   preprocessCore_1.41.0
[13] lattice_0.20-35 ff_2.2-13
[15] pkgconfig_2.0.1 Matrix_1.2-14
[17] foreach_1.4.4   DelayedArray_0.5.31
[19] yaml_2.1.18 GenomeInfoDbData_1.1.0
[21] affxparser_1.52.0   bit64_0.9-7
[23] grid_3.5.0  BiocParallel_1.13.3
[25] blob_1.1.1  codetools_0.2-15
[27] matrixStats_0.53.1  GenomicRanges_1.31.23
[29] splines_3.5.0   SummarizedExperiment_1.9.17
[31] RCurl_1.95-4.10 affyio_1.49.2


-- 
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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

[Bioc-devel] Package download when using functions from affy and oligo

[Joris Meys]

Dear,

I've noticed that using certain functions in affy and oligo (eg
oligo::read.celfiles and affy::bg.correct) start with downloading another
package and end with either R crashing or a warning that -after
installation succeeded- the package is not available. After which using
some functions of both packages still crash R.

The warning I get when trying oligo::read.celfiles() on a single CEL file
right after installing it about the pd.hugene.1.0.st.v1 package. The even
more annoying thing is that on my machine it insists on building from
source, whereas on another Windows machine without Rtools, it downloads a
binary.

Reason it frustrates the heck out of me, is that both affy and oligo
crashed the R session in different ways. During installation of a package,
during use of a function, and at different points when comparing my machine
with the one of our students. The culprit seems to be in one of the
underlying packages, but I wasn't even able to detect which package is the
culprit, let alone which function crashes everything.

Is there a way around this so I can ensure that at least I have the same
setup as they have and I can try to come up with a reproducible example to
report this critical bug?

Thank you in advance
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=gmail=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]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] checksums change after publication on CRAN?

[Joris Meys]

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 <joris.m...@ugent.be> 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=gmail=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=gmail=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?

[Joris Meys]

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=gmail=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

[Joris Meys]

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=gmail=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: [Bioc-devel] Switch to SSH protocol for git clone instructions on package landing pages?

[Joris Meys]

Using SSH will only work when they have a public key on the git server
registered. Otherwise they will get the dreaded "Please make sure you have
the correct access rights and the repository exists" error message. The
same happens when I forget to add the correct key to my pageant. In my
humble opinion it doesn't pay off to make it more difficult for general
users to download the source code in order to make the process more simple
for your developers.

Cheers
Joris

On Sun, Apr 29, 2018 at 4:03 PM, Peter Hickey <peter.hic...@gmail.com>
wrote:

> The one-liner on the package landing page describing how to check out
> a package from the git repo uses HTTPS rather than ssh, e.g.:
>
> # From https://bioconductor.org/packages/bsseq/
> git clone https://git.bioconductor.org/packages/bsseq
>
> However, as a developer we should be using the SSH protocol
> (https://bioconductor.org/developers/how-to/git/faq/).
>
> Is there any reason not to use the SSH protocol (i.e. git clone
> g...@git.bioconductor.org:packages/bsseq) in the instructions given on
> the landing page? It seems to me an unnecessary source of friction,
> particularly for new developers who will end up with the dreaded
> "fatal: remote error: FATAL: W any packages/myPackage nobody DENIED by
> fallthru (or you mis-spelled the reponame)" error message if they
> don't know to switch protocols
> (https://bioconductor.org/developers/how-to/git/faq/)
>
> Cheers,
> Pete
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-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=gmail=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]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] predict.glm returns different results for the same model

[Joris Meys]

Hi Hadley,

This is related to how the terms are constructed. If you look at terms(m1)
versus terms(m2), you see that in the case of m1 the knots are added to the
attribute predvars. Contrary, when using splines::ns() this doesn't happen.
Compare:

mf <- model.frame(claim ~ ns(wind, df = 5), data = dat)
mt <-  terms(mf)

with

mf2 <- model.frame(claim ~ splines::ns(wind, df = 5), data = dat)
mt2 <-  terms(mf)

The culprit is actually in makepredictcall.ns, specifically:

if (as.character(call)[1L] != "ns")
return(call)

Obviously the call starting with predict::ns() will cause the function to
return the call unaltered. In the case of ns() it processes the knot
information. And that difference causes the difference in predictions.

So it is a bug imho. Especially since I don't understand the logic. The
variable has class 'ns', so makepredictcall() dispatches correctly. That
extra check in the function makepredictcall.ns seems unnecessary to me and
might be simply removed.

Cheers
Joris

On Fri, Apr 27, 2018 at 3:25 PM, Hadley Wickham <h.wick...@gmail.com> wrote:

> Hi all,
>
> Very surprising (to me!) and mystifying result from predict.glm(): the
> predictions vary depending on whether or not I use ns() or
> splines::ns(). Reprex follows:
>
> library(splines)
>
> set.seed(12345)
> dat <- data.frame(claim = rbinom(1000, 1, 0.5))
> mns <- c(3.4, 3.6)
> sds <- c(0.24, 0.35)
> dat$wind <- exp(rnorm(nrow(dat), mean = mns[dat$claim + 1], sd =
> sds[dat$claim + 1]))
> dat <- dat[order(dat$wind), ]
>
> m1 <- glm(claim ~ ns(wind, df = 5), data = dat, family = binomial)
> m2 <- glm(claim ~ splines::ns(wind, df = 5), data = dat, family = binomial)
>
> # The model coefficients are the same
> unname(coef(m1))
> #> [1]  0.5194712 -0.8687737 -0.6803954  4.0838947  2.3908674  4.1564128
> unname(coef(m2))
> #> [1]  0.5194712 -0.8687737 -0.6803954  4.0838947  2.3908674  4.1564128
>
> # But the predictions are not!
> newdf <- data.frame(wind = seq(min(dat$wind), max(dat$wind), length = 5))
> unname(predict(m1, newdata = newdf))
> #> [1] 0.51947119 0.03208719 2.82548847 3.90883496 4.06743266
> unname(predict(m2, newdata = newdf))
> #> [1]  0.5194712 -0.5666554 -0.1731268  2.8134844  3.9295814
>
> Is this a bug?
>
> (Motivating issue from this ggplot2 bug report:
> https://github.com/tidyverse/ggplot2/issues/2426)
>
> Thanks!
>
> Hadley
>
>
>
> --
> http://hadley.nz
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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=gmail=g>

---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

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

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "

[Joris Meys]

On Wed, Apr 25, 2018 at 11:52 PM, Rahmatallah, Yasir <yrahmatal...@uams.edu>
wrote:

> Dear all,
>
> Build report show that many packages still have check warnings due to
> missing file links (cross referencing pages from other packages) under
> windows. The issue happens because there are different man pages for
> different operating systems. My package (GSAR) shows the same warning under
> Windows in the build report, although it locally passes R CMD build and R
> CMD check without warnings. Although not a perfect solution, substituting
> the linking in the .Rd file \code{\link[pkg:bar]{foo}} with
> \code{\link{foo}} or \code{\link[pkg]{foo}} was suggested in a recent
> discussion
> https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013315.html


Actually, that is the correct solution. As per "Writing R Extensions",
\link[pkg]{name} searches for a html file with the name name.html in
package pkg. In a number of cases the name of the html help file is not the
same as the function you want to point to. For example, ppois and qpois etc
are discussed in a page called Poisson. Also in "Writing R Extensions" they
mention that if you want to use another name as a link, you should do
\link[pkg:name]{foo}. In our example: \link[stats:Poisson]{ppois}

https://cran.r-project.org/doc/manuals/R-exts.html#Cross_002dreferences

>
> I understood that although a check warning is produced (under Windows
> only), it will be accepted (considered as advice) and packages that
> currently show it will proceed to Bioc release. Is that correct? There are
> still many packages showing this warning in yesterday's report
> http://bioconductor.org/checkResults/3.7/bioc-LATEST/#show=warnings
>

As this is the case for even recommended packages like the survival
package, I don't see how this would be a reason to reject a package. But it
still makes sense to adapt your links in the way it is specified in the
official R manual.

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=gmail=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]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel