Re: [Rd] suggestion: "." in [lsv]apply()

[Sokol Serguei]

Thanks Simon,

Now, I see better your argument.

Le 16/04/2020 à 22:48, Simon Urbanek a écrit :
... I'm not arguing against the principle, I'm arguing about your 
particular proposal as it is inconsistent and not general.
This sounds promising for me. May be in a (new?) future, R core will 
come with a correct proposal for this principle?
Meanwhile, to avoid substitute(), I'll look on the side of formula 
syntax deviation as your example x ~> i + x suggested.


Best,
Serguei.

Personally, I find the current syntax much clearer and readable 
(defining anything by convention like . being the function variable 
seems arbitrary and "dirty" to me), but if you wanted to define a 
shorter syntax, you could use something like x ~> i + x. That said, I 
really don't see the value of not using function(x) [especially these 
days when people are arguing for long variable names with the 
justification that IDEs do all the work anyway], but as I said, my 
argument was against the actual proposal, not general ideas about 
syntax improvement. Cheers, Simon
On 17/04/2020, at 3:53 AM, Sokol Serguei  
wrote: Simon, Thanks for replying. In what follows I won't try to 
argue (I understood that you find this a bad idea) but I would like 
to make clearer some of your point for me (and may be for others). Le 
16/04/2020 à 16:48, Simon Urbanek a écrit :

Serguei,
On 17/04/2020, at 2:24 AM, Sokol Serguei  
wrote: Hi, I would like to make a suggestion for a small syntactic 
modification of FUN argument in the family of functions 
[lsv]apply(). The idea is to allow one-liner expressions without 
typing "function(item) {...}" to surround them. The argument to the 
anonymous function is simply referred as ".". Let take an example. 
With this new feature, the following call sapply(split(mtcars, 
mtcars$cyl), function(d) summary(lm(mpg ~ wt, d))$r.squared) # 4 6 
8 #0.5086326 0.4645102 0.4229655 could be rewritten as 
sapply(split(mtcars, mtcars$cyl), summary(lm(mpg ~ wt, 
.))$r.squared) "Not a big saving in typing" you can say but 
multiplied by the number of [lsv]apply usage and a neater look, I 
think, the idea merits to be considered. 
It's not in any way "neater", not only is it less readable, it's 
just plain wrong. What if the expression returned a function? 
do you mean like in l=sapply(1:3, function(i) function(x) i+x) 
l[[1]](3) # 4 l[[2]](3) # 5 This is indeed a corner case but a pair 
of () or {} can keep wsapply() in course: l=wsapply(1:3, (function(x) 
.+x)) l[[1]](3) # 4 l[[2]](3) # 5
How do you know that you don't want to apply the result of the call? 
A small example (if it is significantly different from the one above) 
would be very helpful for me to understand this point.
For the same reason the implementation below won't work - very often 
you just pass a symbol that evaluates to a function and always en 
expression that returns a function and there is no way to 
distinguish that from your new proposed syntax. 

Even with () or {} around such "dotted" expression? Best, Serguei.
When you feel compelled to use substitute() you should hear alarm 
bells that something is wrong ;). You can certainly write a new 
function that uses a different syntax (and I'm sure someone has 
already done that in the package space), but what you propose is 
incompatible with *apply in R (and very much not R syntax). Cheers, 
Simon
To illustrate a possible implementation, I propose a wrapper 
example for sapply(): wsapply=function(l, fun, ...) { 
s=substitute(fun) if (is.name(s) || is.call(s) && 
s[[1]]==as.name("function")) { sapply(l, fun, ...) # legacy call } 
else { sapply(l, function(d) eval(s, list(.=d)), ...) } } Now, we 
can do: wsapply(split(mtcars, mtcars$cyl), summary(lm(mpg ~ wt, 
.))$r.squared) or, traditional way: wsapply(split(mtcars, 
mtcars$cyl), function(d) summary(lm(mpg ~ wt, d))$r.squared) the 
both work. How do you feel about that? Best, Serguei. 
__ 
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

[Rd] Demo for linking native routines between R packages

[Zhang, Jitao David via R-devel]

Dear R developers,

I want to advertise a small project for the educational purpose to show
people how to link native routines.

In R programming, we need to link to native routines in C, C++, or Fortran
from the R environment. In most cases, the linking works within one
package, namely the R code in a package calls the native code in the same
package.

This is not necessarily always the case. Sometimes, a piece of C or R code
in a package needs to link to native routines in another R package.
The *Writing
R Extensions manual describes *how to do this in the section *Linking to
native routines in other packages*. However, some details were not clear to
me, and I could find no demo dedicated to this purpose.

Therefore, I decided to build a demo that is available at my Github
repository Accio/demo-linking-native
. Besides implementing the
linking of native routines between R packages, the project also documents
issues that I met and how I solved them.

In case you find the demo useful or you have suggestions on how to improve
it, please let me know. I wonder whether you think it is a good idea to
suggest to the core team to add the project to the manual so that other
people can understand the process better with the demo.

In case of questions, let me know.

Best wishes,
David

-- 

*Dr. Jitao David Zhang | 张继涛 | A Computational Biologist in Drug Discovery*

*Building 93/3.38, **Tel +41 61 688 62 51*

*Roche Pharmaceutical Research and Early Development
(pRED) | Pharmaceutical Sciences, BiOmics, BEDA (see http://**go.roche.com/BEDA
**) | Roche Innovation Center Basel | F.
Hoffmann-La-Roche AG | CH-4070 Basel | Switzerland*
*Core working hours - No Meetings: Mo/8:30-16:00; Tu/8:30-17:00;
We/8:30-16:00; Th/9:00-11:30*
*Available for meetings: Mo/16:00-17:00; We/16:00-17:00**; Th/11:00-17:00;
Fr/8:00-10:00*

Confidentiality Note: This message is intended only for ...{{dropped:13}}

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

Re: [Rd] Demo for linking native routines between R packages

[Davis Vaughan]

Nice David! I also wrote up something similar a little while back
https://github.com/DavisVaughan/cexport

-Davis

On Fri, Apr 17, 2020 at 7:09 AM Zhang, Jitao David via R-devel <
r-devel@r-project.org> wrote:

> Dear R developers,
>
> I want to advertise a small project for the educational purpose to show
> people how to link native routines.
>
> In R programming, we need to link to native routines in C, C++, or Fortran
> from the R environment. In most cases, the linking works within one
> package, namely the R code in a package calls the native code in the same
> package.
>
> This is not necessarily always the case. Sometimes, a piece of C or R code
> in a package needs to link to native routines in another R package.
> The *Writing
> R Extensions manual describes *how to do this in the section *Linking to
> native routines in other packages*. However, some details were not clear to
> me, and I could find no demo dedicated to this purpose.
>
> Therefore, I decided to build a demo that is available at my Github
> repository Accio/demo-linking-native
> . Besides implementing the
> linking of native routines between R packages, the project also documents
> issues that I met and how I solved them.
>
> In case you find the demo useful or you have suggestions on how to improve
> it, please let me know. I wonder whether you think it is a good idea to
> suggest to the core team to add the project to the manual so that other
> people can understand the process better with the demo.
>
> In case of questions, let me know.
>
> Best wishes,
> David
>
> --
>
> *Dr. Jitao David Zhang | 张继涛 | A Computational Biologist in Drug Discovery*
>
> *Building 93/3.38, **Tel +41 61 688 62 51*
>
> *Roche Pharmaceutical Research and Early Development
> (pRED) | Pharmaceutical Sciences, BiOmics, BEDA (see http://**
> go.roche.com/BEDA
> **) | Roche Innovation Center Basel | F.
> Hoffmann-La-Roche AG | CH-4070 Basel | Switzerland*
> *Core working hours - No Meetings: Mo/8:30-16:00; Tu/8:30-17:00;
> We/8:30-16:00; Th/9:00-11:30*
> *Available for meetings: Mo/16:00-17:00; We/16:00-17:00**; Th/11:00-17:00;
> Fr/8:00-10:00*
>
> Confidentiality Note: This message is intended only for ...{{dropped:13}}
>
> __
> 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] Demo for linking native routines between R packages

[Zhang, Jitao David via R-devel]

Dear Davis,

Thank you a lot for sharing this, and I am happy that I was not the only
one who need to do it once to learn:)

I proposed to add my repo to the manual. I think it makes sense to add both
of ours, if possible, or we could merge them together and add that to the
manual.

Long-term URL stability is apparently an issue, but I think we may find a
solution there.

Anyway, thanks a lot for sharing!

Best wishes,
David

On Fri, Apr 17, 2020 at 3:12 PM Davis Vaughan  wrote:

> Nice David! I also wrote up something similar a little while back
> https://github.com/DavisVaughan/cexport
>
> -Davis
>
> On Fri, Apr 17, 2020 at 7:09 AM Zhang, Jitao David via R-devel <
> r-devel@r-project.org> wrote:
>
>> Dear R developers,
>>
>> I want to advertise a small project for the educational purpose to show
>> people how to link native routines.
>>
>> In R programming, we need to link to native routines in C, C++, or Fortran
>> from the R environment. In most cases, the linking works within one
>> package, namely the R code in a package calls the native code in the same
>> package.
>>
>> This is not necessarily always the case. Sometimes, a piece of C or R code
>> in a package needs to link to native routines in another R package.
>> The *Writing
>> R Extensions manual describes *how to do this in the section *Linking to
>> native routines in other packages*. However, some details were not clear
>> to
>> me, and I could find no demo dedicated to this purpose.
>>
>> Therefore, I decided to build a demo that is available at my Github
>> repository Accio/demo-linking-native
>> . Besides implementing the
>> linking of native routines between R packages, the project also documents
>> issues that I met and how I solved them.
>>
>> In case you find the demo useful or you have suggestions on how to improve
>> it, please let me know. I wonder whether you think it is a good idea to
>> suggest to the core team to add the project to the manual so that other
>> people can understand the process better with the demo.
>>
>> In case of questions, let me know.
>>
>> Best wishes,
>> David
>>
>> --
>>
>> *Dr. Jitao David Zhang | 张继涛 | A Computational Biologist in Drug
>> Discovery*
>>
>> *Building 93/3.38, **Tel +41 61 688 62 51*
>>
>> *Roche Pharmaceutical Research and Early Development
>> (pRED) | Pharmaceutical Sciences, BiOmics, BEDA (see http://**
>> go.roche.com/BEDA
>> **) | Roche Innovation Center Basel | F.
>> Hoffmann-La-Roche AG | CH-4070 Basel | Switzerland*
>> *Core working hours - No Meetings: Mo/8:30-16:00; Tu/8:30-17:00;
>> We/8:30-16:00; Th/9:00-11:30*
>> *Available for meetings: Mo/16:00-17:00; We/16:00-17:00**; Th/11:00-17:00;
>> Fr/8:00-10:00*
>>
>> Confidentiality Note: This message is intended only for ...{{dropped:13}}
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

-- 

*Dr. Jitao David Zhang | 张继涛 | A Computational Biologist in Drug Discovery*

*Building 93/3.38, **Tel +41 61 688 62 51*

*Roche Pharmaceutical Research and Early Development
(pRED) | Pharmaceutical Sciences, BiOmics, BEDA (see http://**go.roche.com/BEDA
**) | Roche Innovation Center Basel | F.
Hoffmann-La-Roche AG | CH-4070 Basel | Switzerland*
*Core working hours - No Meetings: Mo/8:30-16:00; Tu/8:30-17:00;
We/8:30-16:00; Th/9:00-11:30*
*Available for meetings: Mo/16:00-17:00; We/16:00-17:00**; Th/11:00-17:00;
Fr/8:00-10:00*

Confidentiality Note: This message is intended only for ...{{dropped:13}}

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

Re: [Rd] Demo for linking native routines between R packages

[Dirk Eddelbuettel]

Jitao,

Thanks for writing this up.

You could add a section on 'prior art' and references.  The canonical example
always was (c.f. Writing R Extensions)

  lme4 <-> Matrix

which was followed early by the CRAN packages

  zoo <-> xts
  
upon which I built

  xts <-> RcppXts
  
with a write-up (from 2013 !!) here: 
https://gallery.rcpp.org/articles/accessing-xts-api/

Via private mail, I helped then-maintainer Vincent connect expm:

  expm <-> Matrix

and built two packages on CRAN _for the very purpose of exporting API
functions to be called_ (which in both cases are from base R as R Core is
very careful not get tied into exporting APIs, which is both understandable
and a source of added difficulty for us package writers)

  RApiDatetime
  RApiSerialize

The latter one is use by my RcppRedis package, Travers' very nice qs package
and Tim's rpg package.

To my reading, the R Community is drifting more and more towards collective
amnesia where prior work is (pick any one the following)

 - ignored altogether
 - reinvented by another package
 - shadowed by another package
 
rather than extended, improved and/or cited.  That is a collective loss for
all of us. It would be nice if you could stear back a little and reference
prior related work. My apologies to other packages in this area I have not
listed. We really should have a common reference for this.

Cheers, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Demo for linking native routines between R packages

[Davis Vaughan]

I tried to do this a little. I mentioned xts along with:
bdsmatrix https://github.com/cran/bdsmatrix
cleancall https://github.com/r-lib/cleancall/

On Fri, Apr 17, 2020 at 9:40 AM Dirk Eddelbuettel  wrote:

>
> Jitao,
>
> Thanks for writing this up.
>
> You could add a section on 'prior art' and references.  The canonical
> example
> always was (c.f. Writing R Extensions)
>
>   lme4 <-> Matrix
>
> which was followed early by the CRAN packages
>
>   zoo <-> xts
>
> upon which I built
>
>   xts <-> RcppXts
>
> with a write-up (from 2013 !!) here:
> https://gallery.rcpp.org/articles/accessing-xts-api/
>
> Via private mail, I helped then-maintainer Vincent connect expm:
>
>   expm <-> Matrix
>
> and built two packages on CRAN _for the very purpose of exporting API
> functions to be called_ (which in both cases are from base R as R Core is
> very careful not get tied into exporting APIs, which is both understandable
> and a source of added difficulty for us package writers)
>
>   RApiDatetime
>   RApiSerialize
>
> The latter one is use by my RcppRedis package, Travers' very nice qs
> package
> and Tim's rpg package.
>
> To my reading, the R Community is drifting more and more towards collective
> amnesia where prior work is (pick any one the following)
>
>  - ignored altogether
>  - reinvented by another package
>  - shadowed by another package
>
> rather than extended, improved and/or cited.  That is a collective loss for
> all of us. It would be nice if you could stear back a little and reference
> prior related work. My apologies to other packages in this area I have not
> listed. We really should have a common reference for this.
>
> Cheers, Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

[Rd] How to find detritis rejected by "R CMD check" on Debian?

[Spencer Graves]

Hello:


  How can someone help me find and fix the following, contained in 
00check.log on Debian for "https://github.com/JamesRamsay5/fda":



NOTE
Found the following files/directories:
  ‘fdaMatlabPath.m’
* checking for detritus in the temp directory ... OK


  See:


https://win-builder.r-project.org/incoming_pretest/fda_5.1.3_20200416_225207/Debian/00check.log


  Thanks,
  Spencer Graves

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

Re: [Rd] How to find detritis rejected by "R CMD check" on Debian?

[Dirk Eddelbuettel]

Spencer,

On 17 April 2020 at 09:14, Spencer Graves wrote:
|    How can someone help me find and fix the following, contained in 
| 00check.log on Debian for "https://github.com/JamesRamsay5/fda":
| 
| NOTE
| Found the following files/directories:
|    ‘fdaMatlabPath.m’
| * checking for detritus in the temp directory ... OK

Obviously from your package, so you could use a tool like 'grep' locally.

We can just turn to Gabor's handy CRAN mirror at GitHub, open the
repo at github.com/cran/fda and enter the filename in the search.
Second hit is

  writeLines(d2a, 'fdaMatlabPath.m')

which is obviously a file _you write_ and not not delete just as
the package checking diagnostic suggests. As frequently suggested here or on
r-package-devel (where this belonged), prefix paths by `tempdir()` or change
there first.

Dirk



-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] How to find detritis rejected by "R CMD check" on Debian?

[Duncan Murdoch]

On 17/04/2020 10:14 a.m., Spencer Graves wrote:

Hello:


    How can someone help me find and fix the following, contained in
00check.log on Debian for "https://github.com/JamesRamsay5/fda":


NOTE
Found the following files/directories:
    ‘fdaMatlabPath.m’
* checking for detritus in the temp directory ... OK


    See:



That would have resulted from running the example in ?fdaMatlabPath.

You could stop that from happening in a test by using

if (interactive())
  fdaMatlabPath()

but it still potentially wipes out a user's file.  Can't you ask the 
user for the filename to write to, and have the example write to 
tempdir() instead of the current directory?


Duncan Murdoch

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

Re: [Rd] How to find detritis rejected by "R CMD check" on Debian?

[Ivan Krylov]

This should probably have been addressed to R-pkg-devel, not Rd.

On Fri, 17 Apr 2020 09:14:44 -0500
Spencer Graves  wrote:

> Found the following files/directories:
>    ‘fdaMatlabPath.m’

This is not the "detritus in the temp directory"; the message is related
to the previous line in the log:

>> * checking for non-standard things in the check directory ... NOTE

I searched the repo for the file name in question and got a few hits
[1]. R CMD check runs the \examples{}, including those in
man/fdaMatlabPath.Rd. The function from R/fdaMatlabPath.R, called from
the examples, writes a file in the current directory [2], which
happens to be the check directory during R CMD check. In order to
conform to the CRAN policy, the function should receive the target file
name as a parameter instead, and the example should pass a file path
somewhere in tempdir().

-- 
Best regards,
Ivan

[1] https://github.com/JamesRamsay5/fda/search?q=fdaMatlabPath.m

[2]
https://github.com/JamesRamsay5/fda/blob/ca077f87f69efcfc434eeea39f4fff6136fcfaeb/R/fdaMatlabPath.R#L33

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

Re: [Rd] Demo for linking native routines between R packages

[Zhang, Jitao David via R-devel]

Dear Davis and Dirk,

Thank you very much for the suggestions, which are very valuable and
helpful.

I will add references to prior examples, document my project with the clear
step-by-step-style document of Davis's project, and come back again to the
mailing list.

Best wishes,
David

On Fri, Apr 17, 2020 at 3:40 PM Dirk Eddelbuettel  wrote:

>
> Jitao,
>
> Thanks for writing this up.
>
> You could add a section on 'prior art' and references.  The canonical
> example
> always was (c.f. Writing R Extensions)
>
>   lme4 <-> Matrix
>
> which was followed early by the CRAN packages
>
>   zoo <-> xts
>
> upon which I built
>
>   xts <-> RcppXts
>
> with a write-up (from 2013 !!) here:
> https://gallery.rcpp.org/articles/accessing-xts-api/
>
> Via private mail, I helped then-maintainer Vincent connect expm:
>
>   expm <-> Matrix
>
> and built two packages on CRAN _for the very purpose of exporting API
> functions to be called_ (which in both cases are from base R as R Core is
> very careful not get tied into exporting APIs, which is both understandable
> and a source of added difficulty for us package writers)
>
>   RApiDatetime
>   RApiSerialize
>
> The latter one is use by my RcppRedis package, Travers' very nice qs
> package
> and Tim's rpg package.
>
> To my reading, the R Community is drifting more and more towards collective
> amnesia where prior work is (pick any one the following)
>
>  - ignored altogether
>  - reinvented by another package
>  - shadowed by another package
>
> rather than extended, improved and/or cited.  That is a collective loss for
> all of us. It would be nice if you could stear back a little and reference
> prior related work. My apologies to other packages in this area I have not
> listed. We really should have a common reference for this.
>
> Cheers, Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>


-- 

*Dr. Jitao David Zhang | 张继涛 | A Computational Biologist in Drug Discovery*

*Building 93/3.38, **Tel +41 61 688 62 51*

*Roche Pharmaceutical Research and Early Development
(pRED) | Pharmaceutical Sciences, BiOmics, BEDA (see http://**go.roche.com/BEDA
**) | Roche Innovation Center Basel | F.
Hoffmann-La-Roche AG | CH-4070 Basel | Switzerland*
*Core working hours - No Meetings: Mo/8:30-16:00; Tu/8:30-17:00;
We/8:30-16:00; Th/9:00-11:30*
*Available for meetings: Mo/16:00-17:00; We/16:00-17:00**; Th/11:00-17:00;
Fr/8:00-10:00*

Confidentiality Note: This message is intended only for ...{{dropped:13}}

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

Re: [Rd] Demo for linking native routines between R packages

[Jan Gorecki]

Dirk, Thank you for a comprehensive set of resources on that.

Yet, I think the proposal here make sense.
Packages you mentioned are real-life package. It would be way easier
to learn from a package that is meant to only show this single thing.
For the same reason I think it also make sense to have a "hello world
from C" package linked from WRE. All those native routines
registration, the proper way, is not really that obvious. It would be
much easier to learn from a package that doesn't have any other logic.

Best wishes,
Jan Gorecki

On Fri, Apr 17, 2020 at 3:32 PM Zhang, Jitao David via R-devel
 wrote:
>
> Dear Davis and Dirk,
>
> Thank you very much for the suggestions, which are very valuable and
> helpful.
>
> I will add references to prior examples, document my project with the clear
> step-by-step-style document of Davis's project, and come back again to the
> mailing list.
>
> Best wishes,
> David
>
> On Fri, Apr 17, 2020 at 3:40 PM Dirk Eddelbuettel  wrote:
>
> >
> > Jitao,
> >
> > Thanks for writing this up.
> >
> > You could add a section on 'prior art' and references.  The canonical
> > example
> > always was (c.f. Writing R Extensions)
> >
> >   lme4 <-> Matrix
> >
> > which was followed early by the CRAN packages
> >
> >   zoo <-> xts
> >
> > upon which I built
> >
> >   xts <-> RcppXts
> >
> > with a write-up (from 2013 !!) here:
> > https://gallery.rcpp.org/articles/accessing-xts-api/
> >
> > Via private mail, I helped then-maintainer Vincent connect expm:
> >
> >   expm <-> Matrix
> >
> > and built two packages on CRAN _for the very purpose of exporting API
> > functions to be called_ (which in both cases are from base R as R Core is
> > very careful not get tied into exporting APIs, which is both understandable
> > and a source of added difficulty for us package writers)
> >
> >   RApiDatetime
> >   RApiSerialize
> >
> > The latter one is use by my RcppRedis package, Travers' very nice qs
> > package
> > and Tim's rpg package.
> >
> > To my reading, the R Community is drifting more and more towards collective
> > amnesia where prior work is (pick any one the following)
> >
> >  - ignored altogether
> >  - reinvented by another package
> >  - shadowed by another package
> >
> > rather than extended, improved and/or cited.  That is a collective loss for
> > all of us. It would be nice if you could stear back a little and reference
> > prior related work. My apologies to other packages in this area I have not
> > listed. We really should have a common reference for this.
> >
> > Cheers, Dirk
> >
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >
>
>
> --
>
> *Dr. Jitao David Zhang | 张继涛 | A Computational Biologist in Drug Discovery*
>
> *Building 93/3.38, **Tel +41 61 688 62 51*
>
> *Roche Pharmaceutical Research and Early Development
> (pRED) | Pharmaceutical Sciences, BiOmics, BEDA (see 
> http://**go.roche.com/BEDA
> **) | Roche Innovation Center Basel | F.
> Hoffmann-La-Roche AG | CH-4070 Basel | Switzerland*
> *Core working hours - No Meetings: Mo/8:30-16:00; Tu/8:30-17:00;
> We/8:30-16:00; Th/9:00-11:30*
> *Available for meetings: Mo/16:00-17:00; We/16:00-17:00**; Th/11:00-17:00;
> Fr/8:00-10:00*
>
> Confidentiality Note: This message is intended only for ...{{dropped:13}}
>
> __
> 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