Re: [Rd] methods(`|`) lists all functions?

[frederik]

On Thu, Dec 08, 2016 at 09:37:59PM -0500, Martin Morgan wrote:
> On 12/08/2016 05:16 PM, frede...@ofb.net wrote:
> > Dear R-Devel,
> > 
> > I was attempting an exercise in Hadley Wickam's book "Advanced R". The
> > exercise is to find the generic with the greatest number of methods.
> > 
> > I found that 'methods(`|`)' produces a list of length 2506, in R
> > 3.3.1. Similar behavior is found in 3.4.0. It seems to include all
> > functions and methods. I imagine something is being passed to "grep"
> > without being escaped.
> 
> Exactly; I've fixed this in r71763 (R-devel).
> 
> Martin Morgan

Thank you.

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

Re: [Rd] methods(`|`) lists all functions?

[Martin Morgan]

On 12/08/2016 05:16 PM, frede...@ofb.net wrote:

Dear R-Devel,

I was attempting an exercise in Hadley Wickam's book "Advanced R". The
exercise is to find the generic with the greatest number of methods.

I found that 'methods(`|`)' produces a list of length 2506, in R
3.3.1. Similar behavior is found in 3.4.0. It seems to include all
functions and methods. I imagine something is being passed to "grep"
without being escaped.


Exactly; I've fixed this in r71763 (R-devel).

Martin Morgan



I hope I didn't miss something in the documentation, and that I'm good
to report this as a bug. I can send it to Bugzilla if that's better.

By the way, how do I produce such a list of functions (or variables)
in a "normal" way? I used 'ls("package:base")' for the exercise,
because I saw this call used somewhere as an example, but I couldn't
find that "package:" syntax documented under ls()... Also found this
confusing:

> environmentName(globalenv())
[1] "R_GlobalEnv"
> ls("R_GlobalEnv")
Error in as.environment(pos) :
  no item called "R_GlobalEnv" on the search list

So I'm not sure if "package:base" is naming an environment, or if
there are different ways to name environments and ls() is using one
form while environmentName is returning another ... It might be good
to add some clarifying examples under "?ls".

Thanks,

Frederick

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




This email message may contain legally privileged and/or...{{dropped:2}}

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

Re: [Rd] wish list: generalized apply

[John P. Nolan]

-Original Message-
From: David Winsemius [mailto:dwinsem...@comcast.net] 
Sent: Thursday, December 8, 2016 4:59 PM
To: John P. Nolan 
Cc: Charles C. Berry 
Subject: Re: [Rd] wish list: generalized apply


> On Dec 8, 2016, at 12:09 PM, John P. Nolan  wrote:
> 
> Dear All,
> 
> I regularly want to "apply" some function to an array in a way that the 
> arguments to the user function depend on the index on which the apply is 
> working.  A simple example is:
> 
> A <- array( runif(160), dim=c(5,4,8) ) x <- matrix( runif(32), nrow=4, 
> ncol=8 ) b <- runif(8)
> f1 <- function( A, x, b ) { sum( A %*% x ) + b } result <- rep(0.0,8) 
> for (i in 1:8) {  result[i] <- f1( A[,,i], x[,i] , b[i] ) }
> 
> This works, but is slow.  I'd like to be able to do something like:
>generalized.apply( A, MARGIN=3, FUN=f1, list(x=x,MARGIN=2), 
> list(b=b,MARGIN=1) ), where the lists tell generalized.apply to pass x[,i] 
> and b[i] to FUN in addition to A[,,i].  
> 
> Does such a generalized.apply already exist somewhere?  While I can write a C 
> function to do a particular case, it would be nice if there was a fast, 
> general way to do this.  

I would have thought that this would achieve the same result:

result <- sapply( seq_along(b) , function(i) { f1( A[,,i], x[,i] , b[i] )} )

Or: 

result <- sapply( seq.int( dim(A)[3] ) , function(i) { f1( A[,,i], x[,i] , b[i] 
)} )

(I doubt it will be any faster, but if 'i' is large, parallelism might help. 
The inner function appears to be fairly efficient.)
-- 

David Winsemius
Alameda, CA, USA



Thanks for the response.  I gave a toy example with 8 iterations to illustrate 
the point,  so I thought I would bump it up to make my point about speed.  But 
to my surprise, using a 'for' loop is FASTER than using 'sapply' as David 
suggest or even 'apply'  on a bit simpler problem.   Here is the example:

n <- 80; m <- 10; k <- 10
A <- array( 1:(m*n*k), dim=c(m,k,n) )
y <- matrix( 1:(k*n), nrow=k, ncol=n )
b <- 1:n
f1 <- function( A, y, b ) { sum( A %*% y ) + b }

# use a for loop
time1 <- system.time( {
result <- rep(0.0,n)
for (i in 1:n) {
  result[i] <- f1( A[,,i], y[,i] , b[i] )
}
result } )

#  use sapply
time2 <- system.time( result2 <- sapply( seq.int( dim(A)[3] ) , function(i) { 
f1( A[,,i], y[,i] , b[i] )} ))

# fix y and b, and use standard apply
time3 <- system.time( result3 <- apply( A, MARGIN=3, FUN=f1, y=y[,1], b=b[1] ) 
) 

# user times, then ratios of user times
c( time1[1], time2[1],time3[1]); c( time2[1]/time1[1], time3[1]/time1[1] )  
#   4.84  5.22  5.32 
#   1.078512  1.099174

So using a for loop saves 8-10% of the execution time as compared to sapply and 
apply!?  Years ago I experimented and found out I could speed things up 
noticeably by replacing loops with apply.  This is no longer the case, at least 
in this simple experiment.  Is this a result of byte code?  Can someone tell us 
when a for loop is going to be slower than using apply?  A more complicated 
loop that computes multiple quantities?  

John

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

Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?

[Paul Murrell]

Hi

Yes, we have regression tests for graphics.

In general, but especially for core R code, I would rather have 
confidence that a fix has not broken existing behaviour before I commit it.


I cannot argue with the point that we could respond to some bug reports 
faster.


Paul

On 09/12/16 12:58, frede...@ofb.net wrote:

Hi Paul,

Thanks for keeping me posted and letting me know what I should do.

Are there regression tests for other graphics functions in R? To me
that sounds a bit unnecessary. I think you get more testing from
people who use R; and having a good turnaround for applying patches
(some have been waiting 5 years) would invite better participation.

Thank you,

Frederick

On Fri, Dec 09, 2016 at 12:01:55PM +1300, Paul Murrell wrote:

Hi

Just taking a bit more of a look at this today (currently fixated on making
sure I can build some good regression tests).

The best thing you can do is to keep reminding me like this :)

Paul

On 09/12/16 11:19, frede...@ofb.net wrote:

Hi Paul,

Thanks for your efforts. Do you have an idea when my patch(es) might
be committed? Is there anything I can do to help move this along?

Thanks,

Frederick

On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote:

Hi

The current status is that I am keen for people to contribute some testing
code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951)

There were also some getGraphicsEvent() changes/fixes suggested by Richard
Bodewits (cc'ed), for which I am also seeking test code.

Paul

On 13/11/16 09:00, frede...@ofb.net wrote:

Hi Paul,

Just checking in to see what the status is.

From my perspective it seems logical to split off X11 into a separate
package, so development can proceed at a reasonable rate, but I
haven't yet tried to see if that's even possible.

Thanks,

Frederick

On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote:

Hi

Taking a look at those patches is now on my todo list, so I may be in touch
with both of you at some point to request some testing.

Paul

On 26/07/16 07:17, frede...@ofb.net wrote:

Dear Daniel Greenidge,

To enable getGraphicsEvent on Cairo, you have two patches to choose
from:

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951

The second one is by me, and the first one is from five years ago by
Hugo Mildenberger.

Both patches are very simple, they move some lines enabling
getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds
the ability to execute code (e.g. for animation) while the interface
is idle.

Top guy Duncan Murdoch has expressed that he doesn't have time to work
on applying these patches, and I haven't had any responses from the
rest of the R Core Team. I was thinking that perhaps your best bet is
to try to create a package called e.g. "X11-fixes" which people can
use to get a better X11 library (there is also a bug waiting to be
fixed from 2001:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702).

I don't know if CRAN would accept such a package, or if you'd have to
distribute it via GitHub, but R has excellent tools to facilitate the
distribution of code via packages. Whether the R kernel exports enough
functions to allow a package to take over event handling, I'm not
sure. I was intending to look more into the details of this
possibility but haven't had time.

Best wishes,

Frederick

On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote:

Hi all,

I'm writing an interactive plotting function for viewing fMRI
datasets. Currently, I get keypresses using
grDevices::getGraphicsEvent().

Unfortunately getGraphicsEvent() only supports the X11(type="Xlib")
graphics device on Unix systems. The Xlib device doesn't support
buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots
causes lots of flickering.

Is there a way to get keypresses while using the cairo graphics
device? Alternatively, is there a way to prevent flickering with the
Xlib graphics device?

Best,
Daniel Greenidge

__
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



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 

Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?

[frederik]

Hi Paul,

Thanks for keeping me posted and letting me know what I should do.

Are there regression tests for other graphics functions in R? To me
that sounds a bit unnecessary. I think you get more testing from
people who use R; and having a good turnaround for applying patches
(some have been waiting 5 years) would invite better participation.

Thank you,

Frederick

On Fri, Dec 09, 2016 at 12:01:55PM +1300, Paul Murrell wrote:
> Hi
> 
> Just taking a bit more of a look at this today (currently fixated on making
> sure I can build some good regression tests).
> 
> The best thing you can do is to keep reminding me like this :)
> 
> Paul
> 
> On 09/12/16 11:19, frede...@ofb.net wrote:
> > Hi Paul,
> > 
> > Thanks for your efforts. Do you have an idea when my patch(es) might
> > be committed? Is there anything I can do to help move this along?
> > 
> > Thanks,
> > 
> > Frederick
> > 
> > On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote:
> > > Hi
> > > 
> > > The current status is that I am keen for people to contribute some testing
> > > code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951)
> > > 
> > > There were also some getGraphicsEvent() changes/fixes suggested by Richard
> > > Bodewits (cc'ed), for which I am also seeking test code.
> > > 
> > > Paul
> > > 
> > > On 13/11/16 09:00, frede...@ofb.net wrote:
> > > > Hi Paul,
> > > > 
> > > > Just checking in to see what the status is.
> > > > 
> > > > From my perspective it seems logical to split off X11 into a separate
> > > > package, so development can proceed at a reasonable rate, but I
> > > > haven't yet tried to see if that's even possible.
> > > > 
> > > > Thanks,
> > > > 
> > > > Frederick
> > > > 
> > > > On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote:
> > > > > Hi
> > > > > 
> > > > > Taking a look at those patches is now on my todo list, so I may be in 
> > > > > touch
> > > > > with both of you at some point to request some testing.
> > > > > 
> > > > > Paul
> > > > > 
> > > > > On 26/07/16 07:17, frede...@ofb.net wrote:
> > > > > > Dear Daniel Greenidge,
> > > > > > 
> > > > > > To enable getGraphicsEvent on Cairo, you have two patches to choose
> > > > > > from:
> > > > > > 
> > > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364
> > > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951
> > > > > > 
> > > > > > The second one is by me, and the first one is from five years ago by
> > > > > > Hugo Mildenberger.
> > > > > > 
> > > > > > Both patches are very simple, they move some lines enabling
> > > > > > getGrahpicsEvent outside of a if(!cairo) statement. My patch also 
> > > > > > adds
> > > > > > the ability to execute code (e.g. for animation) while the interface
> > > > > > is idle.
> > > > > > 
> > > > > > Top guy Duncan Murdoch has expressed that he doesn't have time to 
> > > > > > work
> > > > > > on applying these patches, and I haven't had any responses from the
> > > > > > rest of the R Core Team. I was thinking that perhaps your best bet 
> > > > > > is
> > > > > > to try to create a package called e.g. "X11-fixes" which people can
> > > > > > use to get a better X11 library (there is also a bug waiting to be
> > > > > > fixed from 2001:
> > > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702).
> > > > > > 
> > > > > > I don't know if CRAN would accept such a package, or if you'd have 
> > > > > > to
> > > > > > distribute it via GitHub, but R has excellent tools to facilitate 
> > > > > > the
> > > > > > distribution of code via packages. Whether the R kernel exports 
> > > > > > enough
> > > > > > functions to allow a package to take over event handling, I'm not
> > > > > > sure. I was intending to look more into the details of this
> > > > > > possibility but haven't had time.
> > > > > > 
> > > > > > Best wishes,
> > > > > > 
> > > > > > Frederick
> > > > > > 
> > > > > > On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote:
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > I'm writing an interactive plotting function for viewing fMRI
> > > > > > > datasets. Currently, I get keypresses using
> > > > > > > grDevices::getGraphicsEvent().
> > > > > > > 
> > > > > > > Unfortunately getGraphicsEvent() only supports the 
> > > > > > > X11(type="Xlib")
> > > > > > > graphics device on Unix systems. The Xlib device doesn't support
> > > > > > > buffering (i.e. dev.hold() and dev.flush()), so redrawing the 
> > > > > > > plots
> > > > > > > causes lots of flickering.
> > > > > > > 
> > > > > > > Is there a way to get keypresses while using the cairo graphics
> > > > > > > device? Alternatively, is there a way to prevent flickering with 
> > > > > > > the
> > > > > > > Xlib graphics device?
> > > > > > > 
> > > > > > > Best,
> > > > > > > Daniel Greenidge
> > > > > > > 
> > > > > > > __
> > > > > > > R-devel@r-project.org mailing list
> > > > > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > 

Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?

[Paul Murrell]

Hi

Just taking a bit more of a look at this today (currently fixated on 
making sure I can build some good regression tests).


The best thing you can do is to keep reminding me like this :)

Paul

On 09/12/16 11:19, frede...@ofb.net wrote:

Hi Paul,

Thanks for your efforts. Do you have an idea when my patch(es) might
be committed? Is there anything I can do to help move this along?

Thanks,

Frederick

On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote:

Hi

The current status is that I am keen for people to contribute some testing
code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951)

There were also some getGraphicsEvent() changes/fixes suggested by Richard
Bodewits (cc'ed), for which I am also seeking test code.

Paul

On 13/11/16 09:00, frede...@ofb.net wrote:

Hi Paul,

Just checking in to see what the status is.

From my perspective it seems logical to split off X11 into a separate
package, so development can proceed at a reasonable rate, but I
haven't yet tried to see if that's even possible.

Thanks,

Frederick

On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote:

Hi

Taking a look at those patches is now on my todo list, so I may be in touch
with both of you at some point to request some testing.

Paul

On 26/07/16 07:17, frede...@ofb.net wrote:

Dear Daniel Greenidge,

To enable getGraphicsEvent on Cairo, you have two patches to choose
from:

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951

The second one is by me, and the first one is from five years ago by
Hugo Mildenberger.

Both patches are very simple, they move some lines enabling
getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds
the ability to execute code (e.g. for animation) while the interface
is idle.

Top guy Duncan Murdoch has expressed that he doesn't have time to work
on applying these patches, and I haven't had any responses from the
rest of the R Core Team. I was thinking that perhaps your best bet is
to try to create a package called e.g. "X11-fixes" which people can
use to get a better X11 library (there is also a bug waiting to be
fixed from 2001:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702).

I don't know if CRAN would accept such a package, or if you'd have to
distribute it via GitHub, but R has excellent tools to facilitate the
distribution of code via packages. Whether the R kernel exports enough
functions to allow a package to take over event handling, I'm not
sure. I was intending to look more into the details of this
possibility but haven't had time.

Best wishes,

Frederick

On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote:

Hi all,

I'm writing an interactive plotting function for viewing fMRI
datasets. Currently, I get keypresses using
grDevices::getGraphicsEvent().

Unfortunately getGraphicsEvent() only supports the X11(type="Xlib")
graphics device on Unix systems. The Xlib device doesn't support
buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots
causes lots of flickering.

Is there a way to get keypresses while using the cairo graphics
device? Alternatively, is there a way to prevent flickering with the
Xlib graphics device?

Best,
Daniel Greenidge

__
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



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

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

Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?

[frederik]

Hi Paul,

Thanks for your efforts. Do you have an idea when my patch(es) might
be committed? Is there anything I can do to help move this along?

Thanks,

Frederick

On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote:
> Hi
> 
> The current status is that I am keen for people to contribute some testing
> code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951)
> 
> There were also some getGraphicsEvent() changes/fixes suggested by Richard
> Bodewits (cc'ed), for which I am also seeking test code.
> 
> Paul
> 
> On 13/11/16 09:00, frede...@ofb.net wrote:
> > Hi Paul,
> > 
> > Just checking in to see what the status is.
> > 
> > From my perspective it seems logical to split off X11 into a separate
> > package, so development can proceed at a reasonable rate, but I
> > haven't yet tried to see if that's even possible.
> > 
> > Thanks,
> > 
> > Frederick
> > 
> > On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote:
> > > Hi
> > > 
> > > Taking a look at those patches is now on my todo list, so I may be in 
> > > touch
> > > with both of you at some point to request some testing.
> > > 
> > > Paul
> > > 
> > > On 26/07/16 07:17, frede...@ofb.net wrote:
> > > > Dear Daniel Greenidge,
> > > > 
> > > > To enable getGraphicsEvent on Cairo, you have two patches to choose
> > > > from:
> > > > 
> > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364
> > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951
> > > > 
> > > > The second one is by me, and the first one is from five years ago by
> > > > Hugo Mildenberger.
> > > > 
> > > > Both patches are very simple, they move some lines enabling
> > > > getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds
> > > > the ability to execute code (e.g. for animation) while the interface
> > > > is idle.
> > > > 
> > > > Top guy Duncan Murdoch has expressed that he doesn't have time to work
> > > > on applying these patches, and I haven't had any responses from the
> > > > rest of the R Core Team. I was thinking that perhaps your best bet is
> > > > to try to create a package called e.g. "X11-fixes" which people can
> > > > use to get a better X11 library (there is also a bug waiting to be
> > > > fixed from 2001:
> > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702).
> > > > 
> > > > I don't know if CRAN would accept such a package, or if you'd have to
> > > > distribute it via GitHub, but R has excellent tools to facilitate the
> > > > distribution of code via packages. Whether the R kernel exports enough
> > > > functions to allow a package to take over event handling, I'm not
> > > > sure. I was intending to look more into the details of this
> > > > possibility but haven't had time.
> > > > 
> > > > Best wishes,
> > > > 
> > > > Frederick
> > > > 
> > > > On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote:
> > > > > Hi all,
> > > > > 
> > > > > I'm writing an interactive plotting function for viewing fMRI
> > > > > datasets. Currently, I get keypresses using
> > > > > grDevices::getGraphicsEvent().
> > > > > 
> > > > > Unfortunately getGraphicsEvent() only supports the X11(type="Xlib")
> > > > > graphics device on Unix systems. The Xlib device doesn't support
> > > > > buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots
> > > > > causes lots of flickering.
> > > > > 
> > > > > Is there a way to get keypresses while using the cairo graphics
> > > > > device? Alternatively, is there a way to prevent flickering with the
> > > > > Xlib graphics device?
> > > > > 
> > > > > Best,
> > > > > Daniel Greenidge
> > > > > 
> > > > > __
> > > > > 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
> > > > 
> > > 
> > > --
> > > Dr Paul Murrell
> > > Department of Statistics
> > > The University of Auckland
> > > Private Bag 92019
> > > Auckland
> > > New Zealand
> > > 64 9 3737599 x85392
> > > p...@stat.auckland.ac.nz
> > > http://www.stat.auckland.ac.nz/~paul/
> > > 
> 
> -- 
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>

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

[Rd] methods(`|`) lists all functions?

[frederik]

Dear R-Devel,

I was attempting an exercise in Hadley Wickam's book "Advanced R". The
exercise is to find the generic with the greatest number of methods.

I found that 'methods(`|`)' produces a list of length 2506, in R
3.3.1. Similar behavior is found in 3.4.0. It seems to include all
functions and methods. I imagine something is being passed to "grep"
without being escaped.

I hope I didn't miss something in the documentation, and that I'm good
to report this as a bug. I can send it to Bugzilla if that's better.

By the way, how do I produce such a list of functions (or variables)
in a "normal" way? I used 'ls("package:base")' for the exercise,
because I saw this call used somewhere as an example, but I couldn't
find that "package:" syntax documented under ls()... Also found this
confusing:

> environmentName(globalenv())
[1] "R_GlobalEnv"
> ls("R_GlobalEnv")
Error in as.environment(pos) :
  no item called "R_GlobalEnv" on the search list

So I'm not sure if "package:base" is naming an environment, or if
there are different ways to name environments and ls() is using one
form while environmentName is returning another ... It might be good
to add some clarifying examples under "?ls".

Thanks,

Frederick

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

Re: [Rd] wish list: generalized apply

[David Winsemius]

> On Dec 8, 2016, at 12:09 PM, John P. Nolan  wrote:
> 
> Dear All,
> 
> I regularly want to "apply" some function to an array in a way that the 
> arguments to the user function depend on the index on which the apply is 
> working.  A simple example is:
> 
> A <- array( runif(160), dim=c(5,4,8) )
> x <- matrix( runif(32), nrow=4, ncol=8 ) 
> b <- runif(8)
> f1 <- function( A, x, b ) { sum( A %*% x ) + b } 
> result <- rep(0.0,8) 
> for (i in 1:8) {
>  result[i] <- f1( A[,,i], x[,i] , b[i] )
> }
> 
> This works, but is slow.  I'd like to be able to do something like:
>generalized.apply( A, MARGIN=3, FUN=f1, list(x=x,MARGIN=2), 
> list(b=b,MARGIN=1) ), where the lists tell generalized.apply to pass x[,i] 
> and b[i] to FUN in addition to A[,,i].  
> 
> Does such a generalized.apply already exist somewhere?  While I can write a C 
> function to do a particular case, it would be nice if there was a fast, 
> general way to do this.  

I would have thought that this would achieve the same result:

result <- sapply( seq_along(b) , function(i) { f1( A[,,i], x[,i] , b[i] )} )

Or: 

result <- sapply( seq.int( dim(A)[3] ) , function(i) { f1( A[,,i], x[,i] , b[i] 
)} )

(I doubt it will be any faster, but if 'i' is large, parallelism might help. 
The inner function appears to be fairly efficient.)
-- 

David Winsemius
Alameda, CA, USA

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

Re: [Rd] require(..., quietly=TRUE) does not suppress warning

[Kevin Ushey]

IMHO the strongest argument for suppressing the warning message here is the
fact that

requireNamespace("foo", quietly = TRUE)

does not emit any warning message when the package 'foo' does not exist.

On Thu, Dec 8, 2016 at 12:51 PM, Dan Tenenbaum 
wrote:

> Well, I'm getting a warning (not an error) when the package doesn't exist.
> I interpreted "most often" to mean that suppressing warnings/errors is why
> you'd most often use this argument, as most packages don't emit startup
> messages.
>
> And technically there isn't a problem with attaching the package, since we
> don't even try to attach packages that don't exist.
>
> So yes, very careful parsing of the docs suggests that the behavior is
> correct, but it does seem to violate the 'spirit' of what a user might
> expect. I am pretty sure I have used the 'if (!require("pkg"))
> install.packages("pkg")' pattern before without seeing this warning, so I
> wondered if the behavior had changed, and that's what prompted me to write.
>
> I know I can squelch the warning by wrapping the require() in
> suppressWarnings().
>
> Dan
>
>
> - Original Message -
> > From: "John P. Nolan" 
> > To: "Dan Tenenbaum" , "R-devel" <
> r-devel@r-project.org>
> > Sent: Thursday, December 8, 2016 12:37:02 PM
> > Subject: RE: require(..., quietly=TRUE) does not suppress warning
>
> > Well, it says "most often" no errors/warnings are given, so it is not
> > contradicting the docs!   It looks like the person/team that coded
> require( )
> > decided you should get an error when the package doesn't exist.
> >
> > If you want a silent loading, consider
> > aaa <- try( library(foo,verbose=FALSE,quietly=TRUE),silent=TRUE)
> > and then check to see if aaa is of class "try-error" and check for
> failure
> >
> > John
> > ……..
> >
> > John P. Nolan
> > Math/Stat Dept., American University
> > Gray Hall, 4400 Massachusetts Ave, NW
> > Washington, DC 20016-8050
> > Phone: 202-885-3140
> > E-mail:  jpno...@american.edu
> > Web:   http://fs2.american.edu/jpnolan/www/
> >
> >
> >
> > -Original Message
> > From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Dan
> Tenenbaum
> > Sent: Thursday, December 8, 2016 2:43 PM
> > To: R-devel 
> > Subject: [Rd] require(..., quietly=TRUE) does not suppress warning
> >
> > Hi,
> >
> > The `quietly` argument of `require` is documented as follows:
> >
> > quietly: a logical.  If ‘TRUE’, no message confirming package
> >  attaching is printed, and most often, no errors/warnings are
> >  printed if package attaching fails.
> >
> > However:
> >
> >> require(foo, quietly=TRUE)
> > Warning message:
> > In library(package, lib.loc = lib.loc, character.only = TRUE,
> logical.return =
> > TRUE,  :
> >  there is no package called ‘foo’
> >
> > Am I misreading the docs or is R misbehaving?
> >
> >> sessionInfo()
> > R version 3.3.2 (2016-10-31)
> > Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: macOS Sierra
> 10.12.1
> >
> > locale:
> > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> >
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
> >
> > Dan
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Nit-picky vignette questions

[Brian G. Peterson]

In the text of a vignette, I always refer to them with links, just like
I would in other documentation:

\code{\link[xts]{to.period}}

and if I want to be explicit to the reader (who my be reading a format
where the links don't resolve, I would say something like:

see \code{\link[xts]{to.period}} in the \code{xts} package.

In code examples in the vignette, I would use

xts::to.period()

unless I had done a library() or require() call.

Regards,

Brian

On Thu, 2016-12-08 at 12:43 -0800, Roy Mendelssohn - NOAA Federal
wrote:
> Hi All:
> 
> In writing a vignette and referring to a function in another
> package,  say the function info() in the rerddap package,  it it
> better to refer to it as the "rerddap function info()" or as
> "rerddap::info()". This is for the vignette, not what I do
> internally.
> 
> Similarly in a code example in a vignette, if I am using the ggplot2
> function ggplot(),  which would preferable  (this is a non-working
> example just to show the alternative)
> 
>    require(ggplot2)
>    junk <- ggplot()
> 
> 
> or
> 
>   junk <- ggplot2::ggplot()
> 
> Yes these are nitpicky questions,  but as long as I am doing a
> vignette, I might as well try to do all of it in a way that is
> recommended or preferable.
> 
> Thanks for any thoughts,
> 
> -Roy
> 
> PS - Is there something like the Python related program flake8 for R
> code?   I have both Google and Hadley's style recommendations,  but
> it is nice  (though tedious and painful) to have a program that
> points out any inconsistencies from a recommended standard
> 
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
> 
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected" 
> "the arc of the moral universe is long, but it bends toward justice"
> -MLK Jr.
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [Rd] require(..., quietly=TRUE) does not suppress warning

[Dan Tenenbaum]

Well, I'm getting a warning (not an error) when the package doesn't exist.
I interpreted "most often" to mean that suppressing warnings/errors is why 
you'd most often use this argument, as most packages don't emit startup 
messages. 

And technically there isn't a problem with attaching the package, since we 
don't even try to attach packages that don't exist.

So yes, very careful parsing of the docs suggests that the behavior is correct, 
but it does seem to violate the 'spirit' of what a user might expect. I am 
pretty sure I have used the 'if (!require("pkg")) install.packages("pkg")' 
pattern before without seeing this warning, so I wondered if the behavior had 
changed, and that's what prompted me to write.

I know I can squelch the warning by wrapping the require() in 
suppressWarnings(). 

Dan


- Original Message -
> From: "John P. Nolan" 
> To: "Dan Tenenbaum" , "R-devel" 
> 
> Sent: Thursday, December 8, 2016 12:37:02 PM
> Subject: RE: require(..., quietly=TRUE) does not suppress warning

> Well, it says "most often" no errors/warnings are given, so it is not
> contradicting the docs!   It looks like the person/team that coded  require( )
> decided you should get an error when the package doesn't exist.
> 
> If you want a silent loading, consider
> aaa <- try( library(foo,verbose=FALSE,quietly=TRUE),silent=TRUE)
> and then check to see if aaa is of class "try-error" and check for failure
> 
> John
> ……..
> 
> John P. Nolan
> Math/Stat Dept., American University
> Gray Hall, 4400 Massachusetts Ave, NW
> Washington, DC 20016-8050
> Phone: 202-885-3140
> E-mail:  jpno...@american.edu
> Web:   http://fs2.american.edu/jpnolan/www/
> 
> 
> 
> -Original Message
> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Dan 
> Tenenbaum
> Sent: Thursday, December 8, 2016 2:43 PM
> To: R-devel 
> Subject: [Rd] require(..., quietly=TRUE) does not suppress warning
> 
> Hi,
> 
> The `quietly` argument of `require` is documented as follows:
> 
> quietly: a logical.  If ‘TRUE’, no message confirming package
>  attaching is printed, and most often, no errors/warnings are
>  printed if package attaching fails.
> 
> However:
> 
>> require(foo, quietly=TRUE)
> Warning message:
> In library(package, lib.loc = lib.loc, character.only = TRUE, logical.return =
> TRUE,  :
>  there is no package called ‘foo’
> 
> Am I misreading the docs or is R misbehaving?
> 
>> sessionInfo()
> R version 3.3.2 (2016-10-31)
> Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: macOS Sierra 
> 10.12.1
> 
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> Dan
> 
> __
> 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] require(..., quietly=TRUE) does not suppress warning

[John P. Nolan]

Well, it says "most often" no errors/warnings are given, so it is not 
contradicting the docs!   It looks like the person/team that coded  require( ) 
decided you should get an error when the package doesn't exist.

If you want a silent loading, consider
 aaa <- try( library(foo,verbose=FALSE,quietly=TRUE),silent=TRUE)
and then check to see if aaa is of class "try-error" and check for failure

John
……..

John P. Nolan
Math/Stat Dept., American University
Gray Hall, 4400 Massachusetts Ave, NW
Washington, DC 20016-8050
Phone: 202-885-3140
E-mail:  jpno...@american.edu
Web:   http://fs2.american.edu/jpnolan/www/



-Original Message
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Dan Tenenbaum
Sent: Thursday, December 8, 2016 2:43 PM
To: R-devel 
Subject: [Rd] require(..., quietly=TRUE) does not suppress warning

Hi,

The `quietly` argument of `require` is documented as follows:

 quietly: a logical.  If ‘TRUE’, no message confirming package
  attaching is printed, and most often, no errors/warnings are
  printed if package attaching fails.

However:

> require(foo, quietly=TRUE)
Warning message:
In library(package, lib.loc = lib.loc, character.only = TRUE, logical.return = 
TRUE,  :
  there is no package called ‘foo’

Am I misreading the docs or is R misbehaving?

> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: macOS Sierra 10.12.1

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

Dan

__
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] wish list: generalized apply

[John P. Nolan]

Dear All,

I regularly want to "apply" some function to an array in a way that the 
arguments to the user function depend on the index on which the apply is 
working.  A simple example is:

A <- array( runif(160), dim=c(5,4,8) )
x <- matrix( runif(32), nrow=4, ncol=8 ) 
b <- runif(8)
f1 <- function( A, x, b ) { sum( A %*% x ) + b } 
result <- rep(0.0,8) 
for (i in 1:8) {
  result[i] <- f1( A[,,i], x[,i] , b[i] )
}

This works, but is slow.  I'd like to be able to do something like:
generalized.apply( A, MARGIN=3, FUN=f1, list(x=x,MARGIN=2), 
list(b=b,MARGIN=1) ), where the lists tell generalized.apply to pass x[,i] and 
b[i] to FUN in addition to A[,,i].  

Does such a generalized.apply already exist somewhere?  While I can write a C 
function to do a particular case, it would be nice if there was a fast, general 
way to do this.  

John



John P. Nolan
Math/Stat Dept., American University
Gray Hall, 4400 Massachusetts Ave, NW
Washington, DC 20016-8050
Phone: 202-885-3140
E-mail:  jpno...@american.edu
Web:   http://fs2.american.edu/jpnolan/www/

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

[Rd] require(..., quietly=TRUE) does not suppress warning

[Dan Tenenbaum]

Hi,

The `quietly` argument of `require` is documented as follows:

 quietly: a logical.  If ‘TRUE’, no message confirming package
  attaching is printed, and most often, no errors/warnings are
  printed if package attaching fails.

However:

> require(foo, quietly=TRUE)
Warning message:
In library(package, lib.loc = lib.loc, character.only = TRUE, logical.return = 
TRUE,  :
  there is no package called ‘foo’

Am I misreading the docs or is R misbehaving?

> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: macOS Sierra 10.12.1

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

Dan

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

Re: [Bioc-devel] Advice on build error related to webshot, and possibly related to rmarkdown?

[Hervé Pagès]

Let's keep the discussion on the mailing list.

On 12/07/2016 10:58 PM, Stian Lågstad wrote:

I tried doing that now and got another error: "cannot open the
connection". I don't know how to investigate that further.
Link to new build
report: 
http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161208015500.html


At least the webshot issue is gone. Yes adding it to the Suggests
field is of course a dirty hack. The hope being that it would help
you quickly work around the build failure on oaxaca.



Do you think the issue could be caused by the warning below? Since I'm
only seeing that on oaxaca.
"Warning in engine$weave(file, quiet = quiet, encoding = enc) :
  Pandoc (>= 1.12.3) and/or pandoc-citeproc not available. Falling back
to R Markdown v1."


Both pandoc and pandoc-citeproc are on oaxaca:

  oaxaca:~ biocbuild$ which pandoc
  /usr/local/bin/pandoc
  oaxaca:~ biocbuild$ which pandoc-citeproc
  /usr/local/bin/pandoc-citeproc

And pandoc version is >= 1.12.3:

  oaxaca:~ biocbuild$ pandoc -v | head -n 2
  pandoc 1.17.0.2
  Compiled with texmath 0.8.5, highlighting-kate 0.6.2.

Also we don't see that warning on the daily builds even though
many packages use pandoc/pandoc-citeproc for their vignettes.

So again, I'm not sure what's going on, sorry. Likely a problem on
our side. I suggest you ignore this build error on oaxaca for now.

Cheers,
H.



Thank you.

On Thu, Dec 8, 2016 at 1:07 AM, Hervé Pagès > wrote:

Not clear to me what's going on, I'm not a knitr/rmarkdown expert.
What I see is that knitr suggests webshot probably because it needs
it in some situations. That must be a rare situation though because
webshot is not installed on our build machines, which means that none
of the 1298 software packages currently in BioC devel needs it.

So I'm not sure why it would need it for building your vignette, and
why it would need it only on oaxaca. Anyway maybe it would help to add
webshot to your Suggests field. That will trigger installation of
webshot by the SPB before it tries to build/check your package.
Don't forget to bump again the package version in order to trigger
a new build by the SPB.

H.

On 12/07/2016 12:31 PM, Stian Lågstad wrote:

Thank you both. Could you also advice me on the error I'm receiving
on oaxaca? "there is no package called 'webshot'"
New build
report:

http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161207152203.html



>

On Wed, Dec 7, 2016 at 7:42 PM, Hervé Pagès

>> wrote:

Hi Stian,

The build machines used by the SPB are the same as the
machines used
for the daily builds and they already have the latest BiocStyle
installed (BiocStyle 2.3.23). You can see this by going on
the daily
build report for devel and clicking on any of the link in the
"Installed pkgs" column in the top table:

  https://bioconductor.org/checkResults/3.5/bioc-LATEST/

>

However, the SPB report for your package is from Nov 30 so
it could
be that it predates the fix in BiocStyle. You can trigger a
new build
of your package by just bumping its version on github.

Hope this helps,
H.


On 12/07/2016 07:17 AM, Leonardo Collado Torres wrote:

Hi Stian,

Install BiocStyle 2.3.20 or newer and that error will go
away. See
https://github.com/Bioconductor/BiocStyle/issues/20

> for details.

Best,
Leo

On Wed, Dec 7, 2016 at 7:44 AM, Stian Lågstad

>>
wrote:

Hi,

Could someone please advice me on the errors I'm getting
building my
package? I'm unable to reproduce them locally.

Link to build report:

Re: [Bioc-devel] Advice on build error related to webshot, and possibly related to rmarkdown?

[Andrzej Oleś]

Dear Stian,
according to https://github.com/yihui/knitr/releases/tag/v1.14 the
dependency on webshot, which apparently is used to take website
screenshots, is optional and knitr should use fallback mode if webshot is
not available. Webshot has a list of system dependencies, not sure how hard
to fulfill. I wouldn't recommend adding webshot dependency to your packge,
unless you actually intended to use the functionality provided by it.

Cheers,
Andrzej



On Thu, Dec 8, 2016 at 1:07 AM, Hervé Pagès  wrote:

> Not clear to me what's going on, I'm not a knitr/rmarkdown expert.
> What I see is that knitr suggests webshot probably because it needs
> it in some situations. That must be a rare situation though because
> webshot is not installed on our build machines, which means that none
> of the 1298 software packages currently in BioC devel needs it.
>
> So I'm not sure why it would need it for building your vignette, and
> why it would need it only on oaxaca. Anyway maybe it would help to add
> webshot to your Suggests field. That will trigger installation of
> webshot by the SPB before it tries to build/check your package.
> Don't forget to bump again the package version in order to trigger
> a new build by the SPB.
>
> H.
>
> On 12/07/2016 12:31 PM, Stian Lågstad wrote:
>
>> Thank you both. Could you also advice me on the error I'm receiving
>> on oaxaca? "there is no package called 'webshot'"
>> New build
>> report: http://bioconductor.org/spb_reports/chimeraviz_buildreport_
>> 20161207152203.html
>> > 20161207152203.html>
>>
>> On Wed, Dec 7, 2016 at 7:42 PM, Hervé Pagès > > wrote:
>>
>> Hi Stian,
>>
>> The build machines used by the SPB are the same as the machines used
>> for the daily builds and they already have the latest BiocStyle
>> installed (BiocStyle 2.3.23). You can see this by going on the daily
>> build report for devel and clicking on any of the link in the
>> "Installed pkgs" column in the top table:
>>
>>   https://bioconductor.org/checkResults/3.5/bioc-LATEST/
>> 
>>
>> However, the SPB report for your package is from Nov 30 so it could
>> be that it predates the fix in BiocStyle. You can trigger a new build
>> of your package by just bumping its version on github.
>>
>> Hope this helps,
>> H.
>>
>>
>> On 12/07/2016 07:17 AM, Leonardo Collado Torres wrote:
>>
>> Hi Stian,
>>
>> Install BiocStyle 2.3.20 or newer and that error will go away. See
>> https://github.com/Bioconductor/BiocStyle/issues/20
>>  for
>> details.
>>
>> Best,
>> Leo
>>
>> On Wed, Dec 7, 2016 at 7:44 AM, Stian Lågstad
>> > wrote:
>>
>> Hi,
>>
>> Could someone please advice me on the errors I'm getting
>> building my
>> package? I'm unable to reproduce them locally.
>>
>> Link to build report:
>> http://bioconductor.org/spb_reports/chimeraviz_buildreport_
>> 20161130173413.html
>> > 20161130173413.html>
>> Link to bioconductor submission issue:
>> https://github.com/Bioconductor/Contributions/issues/206
>> 
>>
>> I'm getting an error on creating my vignette: `argumemt is
>> not a character
>> vector`
>> I also get this: `there is no package called 'webshot'`
>>
>> I believe these could be related to this warning: `Warning in
>> engine$weave(file, quiet = quiet, encoding = enc) : Pandoc
>> (>= 1.12.3)
>> and/or pandoc-citeproc not available. Falling back to R
>> Markdown v1.`
>>
>> I use rmarkdown_1.2 locally without problems. Can someone
>> here assist me?
>>
>> Thank you.
>>
>> --
>> Stian Lågstad
>> +47 41 80 80 25 
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org 
>> mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> 
>>
>>
>> ___
>> Bioc-devel@r-project.org 
>> mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> 
>>
>>
>> --
>>