Re: [Rd] NEWS, WISHLIST, THANKS
On Thu, 9 Jun 2005 15:41:32 -0400 Gabor Grothendieck wrote: I have NEWS, WISHLIST and THANKS files in the 'dyn' package in the same directory as the DESCRIPTION file but I noticed that they did not survive the move to CRAN, at least on Windows. Moving to CRAN per se has nothing to do with this. If the files have been in the source package you submitted (they have been, including a safety copy DESCRIPTION~ which you might want to eliminate in future versions), they are also in the source package on CRAN. The point is that they are not installed and hence not included in binary packages. How do I incorporate them so that they are not omitted? Put them into the inst/ subdirectory, then they will also be installed. Z __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Q] Example Data Files for Package
Paul: If the example data files for a package are extremely large, What is extremely large here? Mega/giga/terrabytes? should they just be put in a different package specifically for example data? If so, are these data packages normally submitted to CRAN/BioC or mentioned in README with directions specifying where to download on developer site? That depends on the value of extremely large. Up to a certain extent (a few hundred KB or so), I would put them into the package. Otherwise include a README or (maybe even better) a man page that has the example code and explains where to obtain the data. If these files are all dot-tsv (.tsv), they would seem appropriate for the data directory. For large data sets consider to save() the data to .rda to reduce memory usage. Also try the `compress' option. To give you an impression: the spam data set in package kernlab has dimension 4601 x 58 and is 180K in compressed binary format. Writing R Extensions doesn't specifically mention this as a valid file extension for that directory. Glancing around at some other packages, I see a number that create an 'extdata' directory. Is there a consensus on where alternative data files should be put within a package? In most situations, I would recommend to include data just as usual in the data directory. my EUR 0.02 Z __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Lemon drops
On 15 Mar 2005 18:26:46 +0100 Peter Dalgaard wrote: Marc Schwartz [EMAIL PROTECTED] writes: On Tue, 2005-03-15 at 18:05 +0100, Peter Dalgaard wrote: I bumped into the following situation: Browse[1] coef deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 Browse[1] coef[,1] [1] 462 Browse[1] coef[,1,drop=F] deg0NA (Intercept)462 where I really wanted neither, but (Intercept) 462 Anyone happen to know a neat way out of the conundrum? I can think of rowSums(coef[,1,drop=F]) or of course val - coef[,1] names(val) - rownames(x)) but the first one is sneaky and the second gets a bit tedious... Peter, How about something like this: x deg0NA deg4NA deg8NA deg0NP deg4NP deg8NP (Intercept)462510528492660762 IV1 1 2 3 4 5 6 x[1] (Intercept) 462 str(x[1]) Named num 462 - attr(*, names)= chr (Intercept) Does that work or am I missing something? You're missing the context. What I really need is something that will extract a column of a matrix as a vector in the usual way, but will not get confused if there is only one row. Maybe: coef[,1,drop=FALSE][1:nrow(coef)] ? Z -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] CRAN Task Views: ctv package available
On Sat, 12 Mar 2005, Gorjanc Gregor wrote: Hello! First of all congratulations for a nice approach to present R fields in more coherent way. When I started with R I was often frustrated with long list of packages, similarities between them, ... If I would take a slow approach (one thing at a time) things would be easier from the start, but usually one wants to know what a new program is capable of. This is esential if one wants really to switch to R. About ctv: Paul Gilbert wrote: For my own purposes the Econometrics view is just fine, but I do sometimes get questions about dse from people in fields that are different enough that they might not even know to look in Econometrics. A time series view might be useful even if it only said see also ... . Another approach to this might be to have sub-views so, for example, Econometrics and Control theory could both point to Time series. Achim Zeileis responded: Yes, that is, of course, an obvious idea but it requires more coordination between the different views, hence we've decided not to support hierarchically ordered views. Re: ControlTheory. If someone would raise his hand and provide a view for that, it would be great. It could, of course, link to the Econometrics view (and vice versa) but they wouldn't have a formally defined subset in a TimeSeries view. I think that there is a lot of fields where this views cover the same stuff. When I first read about ctv I thought it will be implemented more in somewhat hierarchical or kind of multiple way, since for example linear models come usefull in many different fields and some people might never look under Econometrics view as Paul stated. I realize that hierarchical/multiple is far from easy and I do not have any clear idea how to implement it, but it would probably easier to maintain larger set of views in such a way and it would be easier to generate new ones. Yes, the implementation would not be the main problem, but the maintenance. For hierarchical views, there needs to be much more communication and coordination between the maintainers of related views. My idea was to keep the work low for the maintainers...hoping that there would be more people volunteering to maintain a view related to their field of research or application. Z -- Lep pozdrav / With regards, Gregor GORJANC --- University of Ljubljana Biotechnical FacultyURI: http://www.bfro.uni-lj.si/MR/ggorjan Zootechnical Department mail: gregor.gorjanc at bfro.uni-lj.si Groblje 3 tel: +386 (0)1 72 17 861 SI-1230 Domzale fax: +386 (0)1 72 17 888 Slovenia, Europe __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN Task Views: ctv package available
Paul, thanks for the feedback. If I understand this correctly, I think it is a great idea. Just to be sure I do understand, would you expect there might also be a Time Series view, which would probably overlap some with the Econometrics view? In principle, the presence of an Econometrics view does not preclude the existence of a TimeSeries or Finance view (I already talked with Dirk privately about the latter). Even if the overlap in packages would be substantial, there could be value added via the information on the corresponding HTML page. Currently, my personal opinion would be that we don't need a separate TimeSeries view and that we should extend the information on the Econometrics page instead. But it's not unlikely that I could be convinced otherwise :-) So if you've got suggestions in that direction, just let me know. Best, Z __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 package etc
On Tue, 08 Feb 2005 22:19:46 - (GMT) (Ted Harding) wrote: On 08-Feb-05 Kurt Hornik wrote: Afaic, one of the issues is that it seems common practice to refer to collections of code as libraries or packages, and we're trying to use these rather general-purpose terms in a very precise meaning, and obviously not very successful, in particular because the use oflibrary is highly non-standard. One idea might be to replace thelibrary by something else like ... a place where R knows where to find packages ... hmm, now that's too long, so ... The only issue I have with library vs package (or vice versa) is the following. I *know* that a collection of functions etc. (such as nlme) is properly called a package. I could (and do) get ticked off if I refer to it as a library. However, if I want to use it then I enter library(nlme) As a result, the little daemons who potter around re-wiring my mental circuits sometimes cross-connect these two. As a result, I can inadvertently refer to the nlme library. An example is a recent mailing of mine to the list where I twice referred to a certain library (and was amiably rebuked by Martic Maechler) -- but then I saw that I had also twice referred to the same package in the same mail! Personally I don't mind whether it is called package or library, though using the command library() to load a package does tend, as described, to get me treading on my own shoelaces. But, a propos, is there an R entity called a library (other than the command) as distinct from a package? A *library* is a directory in which you can find R *packages* (just as in real life you can find books in a library) and with library(foo, lib.loc = /path/to/bar) you want to get the package (book) foo from the library bar located at /path/to/bar. So the two are really distinct...in real life, you also wouldn't say that you have been in the book where they had a lot of libraries on the shelves, would you? ;-) But as Kurt explained: this distinction between library and package is specific to R and does not correspond to common practice for other software systems. Z If so, then I can accept the necessity for disciplined distinction between them, since calling one sort of thing by the name of another sort of thing necessarily creates confusion. But if not, then I'm inclined to feel that a bit of loose talk is acceptable (since then a reference to a library would be understood as a reference to a package, since what else would it be?) Just my thoughts ... Ted. E-Mail: (Ted Harding) [EMAIL PROTECTED] Fax-to-email: +44 (0)870 094 0861 Date: 08-Feb-05 Time: 22:19:46 -- XFMail -- __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] * creating vignettes ... ERROR
On Fri, 21 Jan 2005 17:33:25 +0100 Philippe Hupé wrote:
Dear R developers,
I had some problem when building package: for exemple when building
the package e1071 available from CRAN, I get the following message
error:
* checking for file 'e1071/DESCRIPTION' ... OK
* preparing 'e1071':
* cleaning src
* running cleanup
* creating vignettes ... ERROR
/usr/lib/R/bin/texi2dvi: pdflatex exited with bad status, quitting.
/usr/lib/R/bin/texi2dvi: see svmdoc.log for errors.
Error in texi2dvi(file = bft, pdf = TRUE, clean = FALSE, quiet =
quiet) :
running texi2dvi on svmdoc.tex failed
Execution halted
works for me
The system I use is:
R2.0.1 under Debian Linux (testing) with kernel 2.6.9-1-686
The pdflatex version is:
pdfeTeX (Web2C 7.4.5) 3.14159-1.10b-2.1
kpathsea version 3.4.5
Copyright (C) 1997-2003 The NTS Team (eTeX)/Han The Thanh (pdfTeX).
Kpathsea is copyright (C) 1997-2003 Free Software Foundation, Inc.
There is NO warranty. Redistribution of this software is
covered by the terms of both the pdfeTeX copyright and
the GNU General Public License.
For more information about these matters, see the files
named COPYING and the pdfeTeX source.
Primary author of pdfeTeX: The NTS Team (eTeX)/Han The Thanh (pdfTeX).
Kpathsea written by Karl Berry and others.
I attached the log file svmdoc.log.
That did not come true. But my guess is that running LaTeX is what fails
(and that the problem is neither in R nor in the Per script).
From looking briefly at svmdoc.Rnw, it has a
\usepackage{Sweave}
so it expects that Sweave.sty is somewhere in your search path. Is that
the case?
Furthermore, the R code in vignettes should always run, but compiling
the resulting .tex file just has to work at build time. So there are
vignettes (at least in my packages) that depend on local sty/bib/bst
files not included in the package and thus cannot be (easily) compiled
by other people.
Z
I have a quick look on the perl script build and it seem there is a
grep for error.
In the log file there is a line with the following:
file:line:error style messages enabled
it is just the summary of the option used when running pdflatex and
then an error is systematically reported.
If you have any idea where the problem comes from?
Thanks,
Philippe
--
Philippe Hupé
UMR 144 - Service Bioinformatique
Institut Curie
Laboratoire de Transfert (4ème étage)
26 rue d'Ulm
75005 Paris - France
Email : [EMAIL PROTECTED]
Tél : +33 (0)1 44 32 42 75
Fax : +33 (0)1 42 34 65 28
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.vector(as.vector(x)) is FALSE
On Sun, 17 Oct 2004 01:51:47 + (UTC) Gabor Grothendieck wrote: The following, which was recently discussions on the rcom-l list, is a situation where coercing x1mat to a vector using as.vector results in an object that is.vector says is not a vector: R x1mat-matrix(list(1,1.1,1+1i,a,NA,NaN), 3, 2) R is.vector(as.vector(x1mat)) [1] FALSE If you give it a particular mode, it produces a vector: R as.vector(x1mat, mode = character) [1] 11.1 1+1i aNA NaN R as.vector(x1mat, mode = numeric) [1] 1.0 1.1 1.0 NA NA NaN Warning messages: 1: imaginary parts discarded in coercion 2: out-of-range values treated as 0 in coercion to raw A somewhat similar and simpler example is: R x - data.frame(a = 1:5, b = 6:10) R is.vector(as.vector(x)) [1] FALSE because data.frames are also already vectors of mode list. The man page of as.vector provides a similar example with: R as.vector(x, mode = numeric) Error in as.vector(x, mode = numeric) : (list) object cannot be coerced to double I had discussed this with Kurt (and maybe R-devel, but I cannot find it in the archives) some time ago and the bottom line--if I recall correctly--was that is.vector() and as.vector() do not behave in the way that is.vector(as.vector(x)) always gives TRUE (or an error). Z __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot() does not draw bars correctly in R 1.9.0 (PR#6776)
On Fri, 16 Apr 2004 11:40:46 +0200 (CEST) [EMAIL PROTECTED] wrote:
Bars are not stacked, but superimposed. This happens even with the
first example of barplot:
tN - table(Ni - rpois(100, lambda=5))
r - barplot(tN, col='gray')
AFAICS, this problem occurs exactly for 1-way tables like above. If
barplot(as.vector(tN), col = gray)
is used instead, everything is as it was in 1.8.1. The reason is that in
the new version of barplot.default the following code (which
remained unchanged) does not do anymore what do what one would want:
if (is.vector(height)) {
height - cbind(height)
beside - TRUE
}
else if (is.array(height) (length(dim(height)) == 1)) {
height - rbind(height)
beside - TRUE
}
that is, vectors and 1-way tables are treated differently which lead to
the problem. Using cbind() instead of rbind() in the second half,
overcomes this problem.
However, the colors are then chosen in the same way as for vectors,
resulting in different colors than in R 1.8.1. Maybe the default color
choice should then be modified as well.
Z
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 1
minor = 9.0
year = 2004
month = 04
day = 12
language = R
Windows XP Professional (build 2600) Service Pack 1.0
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:utils, Autoloads, package:base
...°}))
) ) ) ) )
( ( ( ( ( Prof. Philippe Grosjean
\ ___ )
\/ECO\ ( Numerical Ecology of Aquatic Systems
/\___/ ) Mons-Hainaut University, Pentagone
/ ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium
/NUM\/ )
\___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12
\ ) email: [EMAIL PROTECTED]
) ) ) ) ) SciViews project coordinator (http://www.sciviews.org)
( ( ( ( (
...
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot() does not draw bars correctly in R 1.9.0 (PR#6777)
On Fri, 16 Apr 2004 11:40:46 +0200 (CEST) [EMAIL PROTECTED] wrote:
Bars are not stacked, but superimposed. This happens even with the
first example of barplot:
=20
tN - table(Ni - rpois(100, lambda=3D5))
r - barplot(tN, col=3D'gray')
AFAICS, this problem occurs exactly for 1-way tables like above. If
barplot(as.vector(tN), col =3D gray)
is used instead, everything is as it was in 1.8.1. The reason is that in
the new version of barplot.default the following code (which
remained unchanged) does not do anymore what do what one would want:
if (is.vector(height)) {
height - cbind(height)
beside - TRUE
}
else if (is.array(height) (length(dim(height)) =3D=3D 1)) {
height - rbind(height)
beside - TRUE
}
that is, vectors and 1-way tables are treated differently which lead to
the problem. Using cbind() instead of rbind() in the second half,
overcomes this problem.
However, the colors are then chosen in the same way as for vectors,
resulting in different colors than in R 1.8.1. Maybe the default color
choice should then be modified as well.
Z
--please do not edit the information below--
=20
Version:
platform =3D i386-pc-mingw32
arch =3D i386
os =3D mingw32
system =3D i386, mingw32
status =3D
major =3D 1
minor =3D 9.0
year =3D 2004
month =3D 04
day =3D 12
language =3D R
=20
Windows XP Professional (build 2600) Service Pack 1.0
=20
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:utils, Autoloads, package:base
=20
...=B0}))
) ) ) ) )
( ( ( ( ( Prof. Philippe Grosjean
\ ___ )
\/ECO\ ( Numerical Ecology of Aquatic Systems
/\___/ ) Mons-Hainaut University, Pentagone
/ ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium
/NUM\/ )
\___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12
\ ) email: [EMAIL PROTECTED]
) ) ) ) ) SciViews project coordinator (http://www.sciviews.org)
( ( ( ( (
...
=20
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
=20
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot() does not draw bars correctly in R 1.9.0 (PR#6776)
On Fri, 16 Apr 2004 09:59:02 -0400 Duncan Murdoch wrote:
On Fri, 16 Apr 2004 15:44:52 +0200, Achim Zeileis
[EMAIL PROTECTED] wrote :
On Fri, 16 Apr 2004 11:40:46 +0200 (CEST) [EMAIL PROTECTED]
wrote:
Bars are not stacked, but superimposed. This happens even with the
first example of barplot:
tN - table(Ni - rpois(100, lambda=5))
r - barplot(tN, col='gray')
AFAICS, this problem occurs exactly for 1-way tables like above. If
barplot(as.vector(tN), col = gray)
is used instead, everything is as it was in 1.8.1. The reason is that
in the new version of barplot.default the following code (which
remained unchanged) does not do anymore what do what one would want:
if (is.vector(height)) {
height - cbind(height)
beside - TRUE
}
else if (is.array(height) (length(dim(height)) == 1)) {
height - rbind(height)
beside - TRUE
}
that is, vectors and 1-way tables are treated differently which lead
to the problem. Using cbind() instead of rbind() in the second half,
overcomes this problem.
However, the colors are then chosen in the same way as for vectors,
resulting in different colors than in R 1.8.1. Maybe the default
color choice should then be modified as well.
I'm pretty sure the problem is due to this change,
Of course, yes. Kurt and I have been working on this and as I recall
used mainly vectors and matrices for testing and obviously not 1-way
tables.
a few lines below the ones you listed:
1.8.1: width - rep(width, length.out = NR * NC)
1.9.0: width - rep(width, length.out = NR)
This change was made at the same time as the offset arg was
introduced; is it intentional?
Yes, we changed it in that way so that the col, width and offset
arguments are expanded (if necessary) in a similar way. Compare for
example
x - cbind(1:3, 2)
barplot(x, width = 1:2, beside = FALSE)
barplot(x, width = 1:2, beside = TRUE)
in 1.8.1 and 1.9.0. In the new version the code tries to find a
(statistically) sensible grouping in both cases. One could argue that in
certain cases the widths of each bar should be controlled and they
should not be grouped...depends on what you want to do if length(width)
does not match the number of bars drawn.
Z
Duncan Murdoch
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot() does not draw bars correctly in R 1.9.0 (PR#6778)
On Fri, 16 Apr 2004 09:59:02 -0400 Duncan Murdoch wrote:
On Fri, 16 Apr 2004 15:44:52 +0200, Achim Zeileis
[EMAIL PROTECTED] wrote :
On Fri, 16 Apr 2004 11:40:46 +0200 (CEST) [EMAIL PROTECTED]
wrote:
Bars are not stacked, but superimposed. This happens even with the
first example of barplot:
tN - table(Ni - rpois(100, lambda=5))
r - barplot(tN, col='gray')
AFAICS, this problem occurs exactly for 1-way tables like above. If
barplot(as.vector(tN), col = gray)
is used instead, everything is as it was in 1.8.1. The reason is that
in the new version of barplot.default the following code (which
remained unchanged) does not do anymore what do what one would want:
if (is.vector(height)) {
height - cbind(height)
beside - TRUE
}
else if (is.array(height) (length(dim(height)) == 1)) {
height - rbind(height)
beside - TRUE
}
that is, vectors and 1-way tables are treated differently which lead
to the problem. Using cbind() instead of rbind() in the second half,
overcomes this problem.
However, the colors are then chosen in the same way as for vectors,
resulting in different colors than in R 1.8.1. Maybe the default
color choice should then be modified as well.
I'm pretty sure the problem is due to this change,
Of course, yes. Kurt and I have been working on this and as I recall
used mainly vectors and matrices for testing and obviously not 1-way
tables.
a few lines below the ones you listed:
1.8.1: width - rep(width, length.out = NR * NC)
1.9.0: width - rep(width, length.out = NR)
This change was made at the same time as the offset arg was
introduced; is it intentional?
Yes, we changed it in that way so that the col, width and offset
arguments are expanded (if necessary) in a similar way. Compare for
example
x - cbind(1:3, 2)
barplot(x, width = 1:2, beside = FALSE)
barplot(x, width = 1:2, beside = TRUE)
in 1.8.1 and 1.9.0. In the new version the code tries to find a
(statistically) sensible grouping in both cases. One could argue that in
certain cases the widths of each bar should be controlled and they
should not be grouped...depends on what you want to do if length(width)
does not match the number of bars drawn.
Z
Duncan Murdoch
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] texi2dvi and buildVignettes() on Windows
I am currently writing a (private) package in which I produce pdf
files from within R using LaTeX. To do so I mainly copied some lines
from the buildVignettes() function in the tools package. This uses the
texi2dvi which is included in R's bin directory:
system(paste(file.path(R.home(), bin, texi2dvi),
--quiet --pdf, bft))
This runs fine on Linux and I assumed that as it is included in
buildVignettes() it should also work on Windows (which is important
for me because I want to share the package with a couple of colleagues
working on Windows). But apparently, texi2dvi is not provided in the
Windows distribution of R.
I already asked Duncan privately about this who kindly tried to run
buildVignettes() on the vignette in my lmtest package. He got the
results:
quote
I get the following:
buildVignettes('lmtest')
Warning message:
F:\R\rw1080/bin/texi2dvi not found
The help for buildVignettes says it's an internal command; perhaps the
thing that calls it has some workaround for Windows. I only see it
being called from src/scripts/build.in, which runs under Windows, but
I can't see any attempt to work around this limitation, so maybe it's
just not working.
/quote
So maybe I am missing something here (which is rather likely as I'm
not used to Windows at all...) but is it possible that
buildVignettes() does not work on Windows? If it has some workaround I
would be glad to learn how that works. Other suggestions on how to
compile LaTeX from within R in some (more or less) cross-platform way
are of course also very welcome.
thanks in advance,
Z
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hist (PR#4395)
On Thursday 02 October 2003 20:48, [EMAIL PROTECTED] wrote: It is not really a bug but a strange choice. So why do you file it as a bug? When the option freq=F chosen, hist should plot relative frequency. It plots proportional to relative frequency by the factor of bin width. Is there a reason for this? Yes. A more normal choice seems to be to have it independent of the bin width. No, because then the histogram could not be used as a density estimate which is possible if the relative frequencies are proportional to the are and not the height of the segments. Z __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
