Re: [Rd] cross-platform portable code in CRAN Repository Policy
Thank you very much for all your responses. It's very clear to me what I need to do and what service I should use for testing now. Thanks, Da On Fri, Jan 27, 2017 at 5:40 PM, Henrik Bengtsson < henrik.bengts...@gmail.com> wrote: > 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 > provided for free by Travis (Linux and macOS) and AppVeyor (Windows) > in combination with GitHub (or GitLab, ...). By adding simple > .travis.yml and appveyor.yml to your Git repos (e.g. > https://github.com/HenrikBengtsson/globals), they run R CMD check > --as-cran and covr::package_coverage() etc for you more or less on the > fly, e.g. > > * https://travis-ci.org/HenrikBengtsson/globals > * https://ci.appveyor.com/project/HenrikBengtsson/globals > > /Henrik > > PS. Thanks to everyone who made all of the above possible. > > On Fri, Jan 27, 2017 at 2:17 PM, Dirk Eddelbuettel wrote: > > > > 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 > > | > Redhat, does it count as two platforms? > > | > > > | > > | I think that Linux is just one. Is it hard to make it work on macOS? > > | > > | I am not saying that if it is Linux-only then it definitely cannot > make it > > | to CRAN. > > | A CRAN maintainer will decide that. > > > > Gabor is *way* too modest here to not mention the *fabulous* tool he has > > written (with the [financial] support of the R Consortium): R Hub. > > > > These days I just do'rhub::check_for_cran()' and four tests launch > > covering the three required OSs as well as the required r-devel and > r-release > > versions. Results tickle in within minutes by mail; the windows one > (which > > is slowest) is also display. You need a one-time token handshake. > > > > I strongly recommend the service. > > > > Dirk > > > > -- > > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > > > __ > > 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] RFC: tapply(*, ..., init.value = NA)
> Henrik Bengtsson
> on Fri, 27 Jan 2017 09:46:15 -0800 writes:
> 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 0 for FUN=sum or
>> FUN=length, TRUE for > FUN=all, -Inf for FUN=max, etc.
>> But that would take time and would > break code for which
>> FUN did not work on length-0 objects.
>>
>> > Bill Dunlap > TIBCO Software > wdunlap tibco.com
>>
>> I had the same idea (after my first post), so I agree
>> that would be nice. One could argue it would take time
>> only if the user is too lazy to specify the value, and we
>> could use tryCatch(FUN(X[0]), error = NA) to safeguard
>> against those functions that fail for 0 length arg.
>>
>> But I think the main reason for _not_ setting such a
>> default is back-compatibility. In my proposal, the new
>> argument would not be any change by default and so all
>> current uses of tapply() would remain unchanged.
>>
>>> Henrik Bengtsson on
>>> Thu, 26 Jan 2017 07:57:08 -0800 writes:
>>
>> > On a related note, the storage mode should try to match
>> ans[[1]] (or > unlist:ed and) when allocating 'ansmat' to
>> avoid coercion and hence a full > copy.
>>
>> Yes, related indeed; and would fall "in line" with Bill's
>> idea. OTOH, it could be implemented independently, by
>> something like
>>
>> if(missing(init.value)) init.value <- if(length(ans))
>> as.vector(NA, mode=storage.mode(ans[[1]])) else NA
> I would probably do something like:
> ans <- unlist(ans, recursive = FALSE, use.names = FALSE)
> if (length(ans)) storage.mode(init.value) <- storage.mode(ans[[1]])
> ansmat <- array(init.value, dim = extent, dimnames = namelist)
> instead. That completely avoids having to use missing() and the value
> of 'init.value' will be coerced later if not done upfront. use.names
> = FALSE speeds up unlist().
Thank you, Henrik.
That's a good idea to do the unlist() first, and with 'use.names=FALSE'.
I'll copy that.
On the other hand, "brutally" modifying 'init.value' (now called 'default')
even when the user has specified it is not acceptable I think.
You are right that it would be coerced anyway subsequently, but
the coercion will happen in whatever method of `[<-` will be
appropriate.
Good S3 and S4 programmers will write such methods for their classes.
For that reason, I'm even more conservative now, only fiddle in
case of an atomic 'ans' and make use of the corresponding '['
method rather than as.vector(.) ... because that will fulfill
the following new regression test {not fulfilled in current R}:
identical(tapply(1:3, 1:3, as.raw),
array(as.raw(1:3), 3L, dimnames=list(1:3)))
Also, I've done a few more things -- treating if(.) . else . as a
function call, etc and now committed as rev 72040 to
R-devel... really wanting to get this out.
We can bet if there will be ripples in (visible) package space,
I give it relatively high chance for no ripples (and much higher
chance for problems with the more aggressive proposal..)
Thank you again, for your "thinking along" and constructive
suggestions.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Subject: Milestone: 10000 packages on CRAN
Amazing!
I join Henrik in expressing my humble gratitude to all the R and CRAN gurus
like Brian Ripley, Duncan Murdoch, Luke Tierney, Martin Maechler, Uwe Ligges,
Kurt Hornik, Peter Dalgaard, Simon Urbanek, and many others.
Thank you & Best regards,
Ravi
From: R-devel on behalf of Henrik Bengtsson
Sent: Friday, January 27, 2017 9:52 PM
To: R-devel
Subject: [Rd] Subject: Milestone: 1 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 there, there are ~3 persons who are about to submit
their first packages to CRAN today and ~3 persons who will submit
another package of theirs. And by the amazing work of the CRAN team,
these packages are inspected and quality controlled before going live
- which often happens within a day or so.
As usual and it can't be said too many times: A big thank you to the
CRAN team, to the R core, to all package developers, to our friendly
community, to everyone out there helping others, and to various online
services that simplify package development. We can all give back by
carefully reporting bugs to the maintainers, properly citing packages
we use in publications (see citation("pkg")), and help newcomers to
use R.
Milestones:
2017-01-27 1 pkgs (+6.3/day over 158 days) 5845 mnts (+3.5/day)
2016-08-22 9000 pkgs (+5.7/day over 175 days) 5289 mnts (+5.8/day)
2016-02-29 8000 pkgs (+5.0/day over 201 days) 4279 mnts (+0.7/day)
2015-08-12 7000 pkgs (+3.4/day over 287 days) 4130 mnts (+2.4/day)
2014-10-29 6000 pkgs (+3.0/day over 335 days) 3444 mnts (+1.6/day)
2013-11-08 5000 pkgs (+2.7/day over 442 days) 2900 mnts (+1.2/day)
2012-08-23 4000 pkgs (+2.1/day over 469 days) 2350 mnts
2011-05-12 3000 pkgs (+1.7/day over 585 days)
2009-10-04 2000 pkgs (+1.1/day over 906 days)
2007-04-12 1000 pkgs
2004-10-01 500 pkgs
2003-04-01 250 pkgs
2002-09-17 68 pkgs
1997-04-23 12 pkgs
These data are for CRAN only [1-13]. There are many more packages
elsewhere, e.g. Bioconductor, GitHub, R-Forge etc.
[1] http://cran.r-project.org/web/packages/
[2] https://en.wikipedia.org/wiki/R_(programming_language)#Milestones
[3] http://www.r-pkg.org/
[4] Private data
[5] https://stat.ethz.ch/pipermail/r-devel/2007-April/045359.html
[6] https://stat.ethz.ch/pipermail/r-devel/2009-October/055049.html
[7] https://stat.ethz.ch/pipermail/r-devel/2011-May/061002.html
[8] https://stat.ethz.ch/pipermail/r-devel/2012-August/064675.html
[9] https://stat.ethz.ch/pipermail/r-devel/2013-November/067935.html
[10] https://stat.ethz.ch/pipermail/r-devel/2014-October/069997.html
[11] https://stat.ethz.ch/pipermail/r-package-devel/2015q3/000393.html
[12] https://stat.ethz.ch/pipermail/r-devel/2016-February/072388.html
[13] https://stat.ethz.ch/pipermail/r-devel/2016-August/073011.html
All the best,
Henrik
(just a user)
__
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
