Re: [Rd] default destfile in download.file()

2016-02-19 Thread Uwe Ligges 



On 18.02.2016 12:01, Jeroen Ooms wrote:

A nice default value for the `destfile` argument in download.file() would
be `basename(url)` i.e. the name of the downloaded file. This would
correspond to default behavior in many other web/ftp clients and makes code
slightly more concise:

   download.file("https://svn.r-project.org/R/trunk/doc/CRAN_mirrors.csv";)
   mirrors <- read.csv("CRAN_mirrors.csv")


This contradicts our approach not to overwrite files in the user 
filespace that are not explicitly mentioned as an argument.


Best,
Uwe Ligges




[[alternative HTML version deleted]]

__
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

Re: [Rd] should `data` respect default.stringsAsFactors()?

2016-02-19 Thread peter dalgaard 

On 19 Feb 2016, at 16:02 , Cook, Malcolm  wrote:

> Hi,
> 
>> Aha... Hadn't noticed that stringsAsFactors only works via as.is in 
>> read.table.
>> 
>> Yes, the doc should probably be fixed. The code probably not 
> 
> Agreed.  
> 
> Is someone on-list authorized and willing to make the documentation change?  
> I suppose I could learn what it takes to be a "player", but for such a 
> trivial fix, it probably is overkill.  Dissenting opinions?

I have fixed it for r-devel.

-pd

> 
>> -- packages
>> loading different data sets depending on user options is an even worse idea
>> than havíng the option in the first place... (I don't mean having the 
>> possibility, I
>> mean the default.stringsAsFactor thing).
>> 
>> In general, read.table() gets many things wrong
> 
> I agree with you that "read.table() gets many things wrong" and I too have my 
> favorite workarounds - but that was not my concern.  My concern is that 
> data() does not work as documented.
> 
> ~Malcolm
> 
>> , if you don't set switches
>> and/or postprocess. E.g., even when you do intend to read factors, the
>> alphabetical level order is often not desired. My favourite workaround for
>> data() is to drop a corresponding foo.R file in the ./data directory. This 
>> will be
>> run in preference to loading foo.txt (or foo.csv, etc) and can contain, like,
>> 
>> dd <- read.table(foo.txt,.)
>> dd$cook <- factor(dd$cook, levels=c("rare","medium","well-done"))
>> 
>> etc.
>> 
>> -pd
>> 
>> 
>> 
>>> On 19 Feb 2016, at 01:39 , Joshua Ulrich  wrote:
>>> 
>>> On Thu, Feb 18, 2016 at 6:03 PM, Cook, Malcolm 
>> wrote:
 Hi Peter,
 
 Sorry if I was not clear.  Perhaps an example will make my point:
 
> data(iris)
> class(iris$Species)
 [1] "factor"
> write.table(iris,'data/myiris.tab')
> data(myiris)
> class(myiris$Species)
 [1] "factor"
> rm(myiris)
> options(stringsAsFactors = FALSE)
> data(myiris)
> class(myiris$Species)
 [1] "factor"
> myiris<-read.table("data/myiris.tab",header=TRUE)
> class(myiris$Species)
 [1] "character"
 
 I am surprised to find that in the above
 setting the global option stringsAsFactors = FALSE does NOT effect
>> how Species is being read in by the `data` function
 whereas
   setting the global option stringsAsFactors = FALSE DOES effect how
>> Species is being read in by read.table
 
 especially since data is documented as calling read.table.
 
>>> To be explicit, it's documented as calling read.table(..., header =
>>> TRUE) in this case, but it actually calls read.table(..., header =
>>> TRUE, as.is = FALSE), which results in class(myiris$Species) of
>>> "factor".
>>> 
>>> R> myiris<-read.table("data/myiris.tab",header=TRUE,as.is=FALSE)
>>> R> class(myiris$Species)
>>> [1] "factor"
>>> 
>>> So it seems like adding as.is = FALSE to the call in the documentation
>>> would clear this up.
>>> 
 In my opinion, one or the other should change (the behavior of data, or the
>> documentation).
 
  ,
 
 ~ Malcolm
 
 
> -Original Message-
> From: peter dalgaard [mailto:pda...@gmail.com]
> Sent: Thursday, February 18, 2016 3:32 PM
> To: Cook, Malcolm 
> Cc: r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] should `data` respect default.stringsAsFactors()?
> 
> What the  are you on about? data() does many things, only some
>> of
> which call read.table() et al., and the ones that do have no special
>> treatment
> of stringsAsFactors.
> 
> -pd
> 
>> On 18 Feb 2016, at 21:25 , Cook, Malcolm  wrote:
>> 
>> Hiya,
>> 
>> Probably been debated elsewhere
>> 
>> I note that R's `data` function does not respect default.stringsAsFactors
>> 
>> By my lights, it should, especially as it is documented to call 
>> read.table,
> which DOES respect.
>> 
>> Oh, but:  http://r.789695.n4.nabble.com/stringsAsFactors-FALSE-
> tp921891p921893.html
>> 
>> Compelling.  I have to agree.
>> 
>> So, I change my mind.
>> 
>> By my lights, `data` should then be documented to NOT respect
> default.stringsAsFactors.
>> 
>> Else?
>> 
>> ~Malcolm Cook
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> --
> 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
>>> 
>>> 
>>> 
>>> --
>>> Joshua Ulrich  |  about.me/joshuaulrich
>>> FOSS Trading  |  www.fosstrading.com

Re: [Rd] should `data` respect default.stringsAsFactors()?

2016-02-19 Thread Cook, Malcolm 
Hi,

 > Aha... Hadn't noticed that stringsAsFactors only works via as.is in 
 > read.table.
 > 
 > Yes, the doc should probably be fixed. The code probably not 

Agreed.  

Is someone on-list authorized and willing to make the documentation change?  I 
suppose I could learn what it takes to be a "player", but for such a trivial 
fix, it probably is overkill.  Dissenting opinions?

> -- packages
 > loading different data sets depending on user options is an even worse idea
 > than havíng the option in the first place... (I don't mean having the 
 > possibility, I
 > mean the default.stringsAsFactor thing).
 > 
 > In general, read.table() gets many things wrong

I agree with you that "read.table() gets many things wrong" and I too have my 
favorite workarounds - but that was not my concern.  My concern is that data() 
does not work as documented.

~Malcolm

> , if you don't set switches
 > and/or postprocess. E.g., even when you do intend to read factors, the
 > alphabetical level order is often not desired. My favourite workaround for
 > data() is to drop a corresponding foo.R file in the ./data directory. This 
 > will be
 > run in preference to loading foo.txt (or foo.csv, etc) and can contain, like,
 > 
 > dd <- read.table(foo.txt,.)
 > dd$cook <- factor(dd$cook, levels=c("rare","medium","well-done"))
 > 
 > etc.
 > 
 > -pd
 > 
 > 
 > 
 > > On 19 Feb 2016, at 01:39 , Joshua Ulrich  wrote:
 > >
 > > On Thu, Feb 18, 2016 at 6:03 PM, Cook, Malcolm 
 > wrote:
 > >> Hi Peter,
 > >>
 > >> Sorry if I was not clear.  Perhaps an example will make my point:
 > >>
 > >>> data(iris)
 > >>> class(iris$Species)
 > >> [1] "factor"
 > >>> write.table(iris,'data/myiris.tab')
 > >>> data(myiris)
 > >>> class(myiris$Species)
 > >> [1] "factor"
 > >>> rm(myiris)
 > >>> options(stringsAsFactors = FALSE)
 > >>> data(myiris)
 > >>> class(myiris$Species)
 > >> [1] "factor"
 > >>> myiris<-read.table("data/myiris.tab",header=TRUE)
 > >>> class(myiris$Species)
 > >> [1] "character"
 > >>
 > >> I am surprised to find that in the above
 > >>  setting the global option stringsAsFactors = FALSE does NOT 
 > >> effect
 > how Species is being read in by the `data` function
 > >> whereas
 > >>setting the global option stringsAsFactors = FALSE DOES effect how
 > Species is being read in by read.table
 > >>
 > >> especially since data is documented as calling read.table.
 > >>
 > > To be explicit, it's documented as calling read.table(..., header =
 > > TRUE) in this case, but it actually calls read.table(..., header =
 > > TRUE, as.is = FALSE), which results in class(myiris$Species) of
 > > "factor".
 > >
 > > R> myiris<-read.table("data/myiris.tab",header=TRUE,as.is=FALSE)
 > > R> class(myiris$Species)
 > > [1] "factor"
 > >
 > > So it seems like adding as.is = FALSE to the call in the documentation
 > > would clear this up.
 > >
 > >> In my opinion, one or the other should change (the behavior of data, or 
 > >> the
 > documentation).
 > >>
 > >>  ,
 > >>
 > >> ~ Malcolm
 > >>
 > >>
 > >>> -Original Message-
 > >>> From: peter dalgaard [mailto:pda...@gmail.com]
 > >>> Sent: Thursday, February 18, 2016 3:32 PM
 > >>> To: Cook, Malcolm 
 > >>> Cc: r-de...@stat.math.ethz.ch
 > >>> Subject: Re: [Rd] should `data` respect default.stringsAsFactors()?
 > >>>
 > >>> What the  are you on about? data() does many things, only some
 > of
 > >>> which call read.table() et al., and the ones that do have no special
 > treatment
 > >>> of stringsAsFactors.
 > >>>
 > >>> -pd
 > >>>
 >  On 18 Feb 2016, at 21:25 , Cook, Malcolm  wrote:
 > 
 >  Hiya,
 > 
 >  Probably been debated elsewhere
 > 
 >  I note that R's `data` function does not respect 
 >  default.stringsAsFactors
 > 
 >  By my lights, it should, especially as it is documented to call 
 >  read.table,
 > >>> which DOES respect.
 > 
 >  Oh, but:  http://r.789695.n4.nabble.com/stringsAsFactors-FALSE-
 > >>> tp921891p921893.html
 > 
 >  Compelling.  I have to agree.
 > 
 >  So, I change my mind.
 > 
 >  By my lights, `data` should then be documented to NOT respect
 > >>> default.stringsAsFactors.
 > 
 >  Else?
 > 
 >  ~Malcolm Cook
 > 
 >  __
 >  R-devel@r-project.org mailing list
 >  https://stat.ethz.ch/mailman/listinfo/r-devel
 > >>>
 > >>> --
 > >>> 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
 > >
 > >
 > >
 > > --
 > > Joshua Ulrich  |  about.me/joshuaulrich
 > > FOSS Trading  |  www.fosstrading.com
 > > R/Finance 201

Re: [Rd] should `data` respect default.stringsAsFactors()?

2016-02-19 Thread Cook, Malcolm 
Joshua,

> On Thu, Feb 18, 2016 at 6:03 PM, Cook, Malcolm  wrote:
 > > Hi Peter,
 > >
 > > Sorry if I was not clear.  Perhaps an example will make my point:
 > >
 > >> data(iris)
 > >> class(iris$Species)
 > > [1] "factor"
 > >> write.table(iris,'data/myiris.tab')
 > >> data(myiris)
 > >> class(myiris$Species)
 > > [1] "factor"
 > >> rm(myiris)
 > >> options(stringsAsFactors = FALSE)
 > >> data(myiris)
 > >> class(myiris$Species)
 > > [1] "factor"
 > >> myiris<-read.table("data/myiris.tab",header=TRUE)
 > >> class(myiris$Species)
 > > [1] "character"
 > >
 > > I am surprised to find that in the above
 > >   setting the global option stringsAsFactors = FALSE does NOT 
 > > effect
 > how Species is being read in by the `data` function
 > > whereas
 > > setting the global option stringsAsFactors = FALSE DOES effect how
 > Species is being read in by read.table
 > >
 > > especially since data is documented as calling read.table.
 > >
 > To be explicit, it's documented as calling read.table(..., header =
 > TRUE) in this case, but it actually calls read.table(..., header =
 > TRUE, as.is = FALSE), which results in class(myiris$Species) of
 > "factor".

Aha - makes sense.

 > 
 > R> myiris<-read.table("data/myiris.tab",header=TRUE,as.is=FALSE)
 > R> class(myiris$Species)
 > [1] "factor"
 > 
 > So it seems like adding as.is = FALSE to the call in the documentation
 > would clear this up.

I agree - thanks for digging into the source - you have unearthed the root 
cause.

~Malcolm

 > > In my opinion, one or the other should change (the behavior of data, or the
 > documentation).
 > >
 > >  ,
 > >
 > > ~ Malcolm
 > >
 > >
 > >  > -Original Message-
 > >  > From: peter dalgaard [mailto:pda...@gmail.com]
 > >  > Sent: Thursday, February 18, 2016 3:32 PM
 > >  > To: Cook, Malcolm 
 > >  > Cc: r-de...@stat.math.ethz.ch
 > >  > Subject: Re: [Rd] should `data` respect default.stringsAsFactors()?
 > >  >
 > >  > What the  are you on about? data() does many things, only some
 > of
 > >  > which call read.table() et al., and the ones that do have no special
 > treatment
 > >  > of stringsAsFactors.
 > >  >
 > >  > -pd
 > >  >
 > >  > > On 18 Feb 2016, at 21:25 , Cook, Malcolm  wrote:
 > >  > >
 > >  > > Hiya,
 > >  > >
 > >  > > Probably been debated elsewhere
 > >  > >
 > >  > > I note that R's `data` function does not respect 
 > > default.stringsAsFactors
 > >  > >
 > >  > > By my lights, it should, especially as it is documented to call 
 > > read.table,
 > >  > which DOES respect.
 > >  > >
 > >  > > Oh, but:  http://r.789695.n4.nabble.com/stringsAsFactors-FALSE-
 > >  > tp921891p921893.html
 > >  > >
 > >  > > Compelling.  I have to agree.
 > >  > >
 > >  > > So, I change my mind.
 > >  > >
 > >  > > By my lights, `data` should then be documented to NOT respect
 > >  > default.stringsAsFactors.
 > >  > >
 > >  > > Else?
 > >  > >
 > >  > > ~Malcolm Cook
 > >  > >
 > >  > > __
 > >  > > R-devel@r-project.org mailing list
 > >  > > https://stat.ethz.ch/mailman/listinfo/r-devel
 > >  >
 > >  > --
 > >  > 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
 > 
 > 
 > 
 > --
 > Joshua Ulrich  |  about.me/joshuaulrich
 > FOSS Trading  |  www.fosstrading.com
 > R/Finance 2016 | www.rinfinance.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Reading from an existing connection in compiled code

2016-02-19 Thread Jon Clayden 
Dear all,

I'd like to be able to read from an arbitrary R connection (in the
sense of ?connections), which would be passed to an R function by the
user and then down into some C code via .Call.

The R API, in file R_ext/Connections.h, specifies a function,
R_ReadConnection, which takes a pointer to an Rconn struct as its
first argument, and does what I want. The struct itself is also
defined in that header, but I see no way of retrieving a struct of
that type, aside from getConnection (the C function), which is not
part of the API. As far as I can tell, the external pointer associated
with the connection also does not point to the struct directly.

So, could anyone please tell me whether there is a supported way to
convert a suitable SEXP to a pointer to the associated Rconn struct?

Thanks in advance.

Jon

(This question was also posted yesterday to StackOverflow
,
but no definitive answer has been posted.)

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

Re: [Rd] R, AIX 64-bit builds - trying to understand root cause for message: "Error: Line starting 'Package: tools ...' is malformed!"

2016-02-19 Thread Michael Felt 

Hi Simon,

I have been busy with work, but I finally got around to repackaging 
libiconv for AIX - in a way that both adds GNU libiconv support 
(libiconv.so.2 member) and is both 32 and 64 bit without breaking 
support for IBM iconv applications.


I concur that iconv is a pain as IBM and GNU made different decesions 
about an 'implementor' choice to call a translation to an error or not - 
when the output map(?) does not include a character. IBM choose to 
output ASCII 32 (space) and GNU calls it an error. The standard states 
it is an error when a char (or code) is used in the input, but is not in 
the input table. Enough said imho - IBM and GNU differ in their approach 
and autotools test for this difference.


So, I have a way to have both approaches available via /usr/lib. For a 
bit more detail please see: http://www.aixtools.net/index.php/libiconv - 
I do hope this 'fixes' the libiconv issues! for OSS.


Using this library you should be able to replace: (what you sent in an 
earlier e-mail as your configure statement)


On 2016-01-04 15:52, Simon Urbanek wrote:

>  I would be "pleased" if you would try packages - i.e., none of "Toolbox" or 
Perzl rpm's.
>  

R requires iconv, so you have to get that somehow. I tried to bypass the check 
and build it anyway against the system one, but that fails as there is a iconv 
conversion further down the line that is not supported. Building iconv is a 
PITA because it conflicts with the system one so other tools break when you 
modify the load path. Perzl's iconv fixes that by incorporating both the system 
objects and the GNU ones into the same binary and that seems to work reliably 
so far. That is the only dependency I was using (his iconv doesn't have any 
dependencies itself).



configure CC=xlc_r CXX=xlc++_r F77=xlf_r FC=xlf95_r LIBS='-L/opt/freeware/lib 
/opt/freeware/lib/libiconv.a -lpthread' --prefix=/opt/freeware 
CPPFLAGS=-I/opt/freeware/include

with export OBJECT_MODE=64 in the env (and libiconv from perzl.org RPMs - iconv 
is a serious pain).


with

export OBJECT_MODE=64
configure CC=xlc_r CXX=xlc++_r F77=xlf_r FC=xlf95_r LIBS='-lpthread' 
--prefix=/opt/freeware


You may even be able to replace --prefix=/opt/freeware to --prefix=/opt (I use 
the latter to not step on anything in /opt/freeware)

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

Re: [Rd] should `data` respect default.stringsAsFactors()?

2016-02-19 Thread peter dalgaard 
Aha... Hadn't noticed that stringsAsFactors only works via as.is in read.table. 

Yes, the doc should probably be fixed. The code probably not -- packages 
loading different data sets depending on user options is an even worse idea 
than havíng the option in the first place... (I don't mean having the 
possibility, I mean the default.stringsAsFactor thing). 

In general, read.table() gets many things wrong, if you don't set switches 
and/or postprocess. E.g., even when you do intend to read factors, the 
alphabetical level order is often not desired. My favourite workaround for 
data() is to drop a corresponding foo.R file in the ./data directory. This will 
be run in preference to loading foo.txt (or foo.csv, etc) and can contain, 
like, 

dd <- read.table(foo.txt,.) 
dd$cook <- factor(dd$cook, levels=c("rare","medium","well-done"))

etc.

-pd



> On 19 Feb 2016, at 01:39 , Joshua Ulrich  wrote:
> 
> On Thu, Feb 18, 2016 at 6:03 PM, Cook, Malcolm  wrote:
>> Hi Peter,
>> 
>> Sorry if I was not clear.  Perhaps an example will make my point:
>> 
>>> data(iris)
>>> class(iris$Species)
>> [1] "factor"
>>> write.table(iris,'data/myiris.tab')
>>> data(myiris)
>>> class(myiris$Species)
>> [1] "factor"
>>> rm(myiris)
>>> options(stringsAsFactors = FALSE)
>>> data(myiris)
>>> class(myiris$Species)
>> [1] "factor"
>>> myiris<-read.table("data/myiris.tab",header=TRUE)
>>> class(myiris$Species)
>> [1] "character"
>> 
>> I am surprised to find that in the above
>>  setting the global option stringsAsFactors = FALSE does NOT effect 
>> how Species is being read in by the `data` function
>> whereas
>>setting the global option stringsAsFactors = FALSE DOES effect how 
>> Species is being read in by read.table
>> 
>> especially since data is documented as calling read.table.
>> 
> To be explicit, it's documented as calling read.table(..., header =
> TRUE) in this case, but it actually calls read.table(..., header =
> TRUE, as.is = FALSE), which results in class(myiris$Species) of
> "factor".
> 
> R> myiris<-read.table("data/myiris.tab",header=TRUE,as.is=FALSE)
> R> class(myiris$Species)
> [1] "factor"
> 
> So it seems like adding as.is = FALSE to the call in the documentation
> would clear this up.
> 
>> In my opinion, one or the other should change (the behavior of data, or the 
>> documentation).
>> 
>>  ,
>> 
>> ~ Malcolm
>> 
>> 
>>> -Original Message-
>>> From: peter dalgaard [mailto:pda...@gmail.com]
>>> Sent: Thursday, February 18, 2016 3:32 PM
>>> To: Cook, Malcolm 
>>> Cc: r-de...@stat.math.ethz.ch
>>> Subject: Re: [Rd] should `data` respect default.stringsAsFactors()?
>>> 
>>> What the  are you on about? data() does many things, only some of
>>> which call read.table() et al., and the ones that do have no special 
>>> treatment
>>> of stringsAsFactors.
>>> 
>>> -pd
>>> 
 On 18 Feb 2016, at 21:25 , Cook, Malcolm  wrote:
 
 Hiya,
 
 Probably been debated elsewhere
 
 I note that R's `data` function does not respect default.stringsAsFactors
 
 By my lights, it should, especially as it is documented to call read.table,
>>> which DOES respect.
 
 Oh, but:  http://r.789695.n4.nabble.com/stringsAsFactors-FALSE-
>>> tp921891p921893.html
 
 Compelling.  I have to agree.
 
 So, I change my mind.
 
 By my lights, `data` should then be documented to NOT respect
>>> default.stringsAsFactors.
 
 Else?
 
 ~Malcolm Cook
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>>> --
>>> 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
> 
> 
> 
> -- 
> Joshua Ulrich  |  about.me/joshuaulrich
> FOSS Trading  |  www.fosstrading.com
> R/Finance 2016 | www.rinfinance.com

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