[Rd] Subject: Milestone: 10000 packages on CRAN

Continuing the tradition to post millennia milestones on CRAN: So, it happened. Today (January 27, 2017 PCT) CRAN reached 10,000 packages [1]. Needless to say, the rate with which new packages are added to CRAN keeps increasing and so does the number of contributors (maintainers). Somewhere out

[Rd] Matrix package breaks as.matrix method

Hi, The Matrix package and the as.matrix method do not seem to be compatible inside of a package. Here's an example. I've created a simple package "mat" that defines an eponymous class and as.matrix method on that class. All is well, unless that package has the Matrix package in its Depends or

Re: [Rd] cross-platform portable code in CRAN Repository Policy

Second this. As the CRAN Policies suggests, there's also the very handy winbuilder service (https://win-builder.r-project.org/) you can use to check your package on Windows. This service has been a valuable workhorse for years. We should also mention the continuous integration (CI) services

Re: [Rd] cross-platform portable code in CRAN Repository Policy

On 27 January 2017 at 21:54, Gábor Csárdi wrote: | On Fri, Jan 27, 2017 at 9:28 PM, Da Zheng wrote: | > What major R platforms does this policy refer to? | > | | Linux, macOS, Windows. | | | > Currently, my package runs in Ubuntu. If it works on both Ubuntu and | >

Re: [Rd] cross-platform portable code in CRAN Repository Policy

On Fri, Jan 27, 2017 at 9:28 PM, Da Zheng wrote: > Hello, > > I'm trying to submit my package to CRAN. When I read the policy, it says: > Package authors should make all reasonable efforts to provide > cross-platform portable code. Packages will not normally be accepted >

Re: [Rd] cross-platform portable code in CRAN Repository Policy

> On Jan 27, 2017, at 3:28 PM, Da Zheng wrote: > > Hello, > > I'm trying to submit my package to CRAN. When I read the policy, it says: > Package authors should make all reasonable efforts to provide > cross-platform portable code. Packages will not normally be accepted

Re: [Rd] cross-platform portable code in CRAN Repository Policy

On 27/01/2017 4:28 PM, Da Zheng wrote: Hello, I'm trying to submit my package to CRAN. When I read the policy, it says: Package authors should make all reasonable efforts to provide cross-platform portable code. Packages will not normally be accepted that do not run on at least two of the major

[Rd] cross-platform portable code in CRAN Repository Policy

Hello, I'm trying to submit my package to CRAN. When I read the policy, it says: Package authors should make all reasonable efforts to provide cross-platform portable code. Packages will not normally be accepted that do not run on at least two of the major R platforms. What major R platforms

Re: [Bioc-devel] xps build problem on toluca2

I will follow your advice and post on bioc-devel. Christian On 01/27/17 19:17, Obenchain, Valerie wrote: Yes, I will be taking over the build responsibilities with help from Herve. We don't want to give the impression that users need to contact us personally to install system dependencies.

Re: [Bioc-devel] xps build problem on toluca2

Yes, I will be taking over the build responsibilities with help from Herve. We don't want to give the impression that users need to contact us personally to install system dependencies. All dependencies should be listed in 'SystemRequirements' field of DESCRIPTION. xps does have root listed so it

Re: [Bioc-devel] xps build problem on toluca2

Dear Valerie, Thank you for your extensive reply. I understand that it does not affect any users. It was only a reminder. Usually, I have contacted Dan personally, but I did not know whom to write. I assume that you are now responsible for the setup. If this is the case I will in the future

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

On Fri, Jan 27, 2017 at 12:34 AM, Martin Maechler wrote: > > > On Jan 26, 2017 07:50, "William Dunlap via R-devel" > > > wrote: > > > It would be cool if the default for tapply's init.value could be > > FUN(X[0]), so it would be

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

> Suharto Anggono Suharto Anggono via R-devel > on Fri, 27 Jan 2017 16:36:59 + writes: > The "no factor combination" case is distinguishable by 'tapply' with simplify=FALSE. >> D2 <- data.frame(n = gl(3,4), L = gl(6,2, labels=LETTERS[1:6]), N=3)

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

The "no factor combination" case is distinguishable by 'tapply' with simplify=FALSE. > D2 <- data.frame(n = gl(3,4), L = gl(6,2, labels=LETTERS[1:6]), N=3) > D2 <- D2[-c(1,5), ] > DN <- D2; DN[1,"N"] <- NA > with(DN, tapply(N, list(n,L), FUN=sum, simplify=FALSE)) ABCDEF 1

Re: [Rd] Suggestion: barplot function

> On Jan 27, 2017, at 8:30 AM, danielren...@lycos.com wrote: > > Hello developers folks! > > First, congratulations for the wonderful work with R. > > For science, barplots with error bars are very important. We were wondering > that is so easy to use the boxplot function: > >

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

If xtabs is enhanced then as.data.frame.table may also need to be modified so that it continues to be usable as an inverse, at least to the degree feasible. On Thu, Jan 26, 2017 at 5:42 AM, Martin Maechler wrote: > Last week, we've talked here about "xtabs(), factors

Re: [Bioc-devel] xps build problem on toluca2

Hi Christian, toluca2 is in the process of being set up and oaxaca is still the official Mac devel builder. There are a number of dependencies that need to be addressed on the new machine and we are working through them. It is important to understand that the error on toluca2 does not affect you

[Rd] Suggestion: barplot function

Hello developers folks! First, congratulations for the wonderful work with R. For science, barplots with error bars are very important. We were wondering that is so easy to use the boxplot function: boxplot(Spores~treatment, col=treatment_colors) But there is no such function for barplots

Re: [Rd] Undefined behavior of head() and tail() with n = 0

Dear Florent, thank you for striving to clearly disentangle and present the issue below. That is a nice "role model" way of approaching such topics! > Florent Angly > on Fri, 27 Jan 2017 10:24:39 +0100 writes: > Martin, I agree with you that +0 and -0

Re: [Bioc-devel] Code quality and bug reports

On 01/27/2017 03:30 AM, Lluís Revilla wrote: Dear Valerie, When I talked about maintenance status I thought something on the line of this badges at http://www.repostatus.org/ : Maybe only the last three status are relevant to Bioconductor : - Active: The project has reached a stable, usable

Re: [Rd] Undefined behavior of head() and tail() with n = 0

Martin, I agree with you that +0 and -0 should generally be treated as equal, and R does a fine job in this respect. The Wikipedia article on signed zero (https://en.wikipedia.org/wiki/Signed_zero) echoes this view but also highlights that +0 and -0 can be treated differently in particular

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

> On Jan 26, 2017 07:50, "William Dunlap via R-devel" > wrote: > It would be cool if the default for tapply's init.value could be > FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE for > FUN=all, -Inf for FUN=max, etc. But that would take

Re: [Bioc-devel] Code quality and bug reports

Dear Valerie, When I talked about maintenance status I thought something on the line of this badges at http://www.repostatus.org/ : Maybe only the last three status are relevant to Bioconductor : - Active: The project has reached a stable, usable state and is being actively developed. -