Re: [Bioc-devel] Idea for improved visibility of Bioconductor packages

[Andrzej Oleś]

Hi Dan,

many thanks for introducing the Open Graph Protocol on package landing
pages! It's nice to see how package presentation is constantly improving.

I've noticed is that the Bioconductor logo gets typically resized and
cropped to a rectangular aspect ratio of 1.66 (LinkedIn) or 1.91
(Facebook). The result is a bit disappointing, as the resulting central
cutout is unreadable.

Maybe we could provide an optimized image, both in terms of dimensions and
file size? One possibility would be to use a rectangular logo similar to
the one on twitter, see
https://pbs.twimg.com/profile_images/1993565463/note.jpg

There are some detailed Facebook-specific recommendations available at
https://developers.facebook.com/docs/sharing/best-practices#images

Cheers,
Andrzej

On Tue, Nov 3, 2015 at 2:05 AM, Dan Tenenbaum 
wrote:

>
>
> - Original Message -
> > From: "Jiří Hon" 
> > To: "bioc-devel" 
> > Sent: Thursday, October 29, 2015 7:05:57 AM
> > Subject: Re: [Bioc-devel] Idea for improved visibility of Bioconductor
> packages
>
> > The implementation of Open Graph protocol should solve this, at least
> > for LinkedIn and Facebook. See
> > https://developer.linkedin.com/docs/share-on-linkedin (at the bottom of
> > the page).
>
>
> I've tweaked the package landing pages so their HTML contains (for
> example, for the EBImage package):
>
>   
>   
>   
>   
>   http://bioconductor.org/packages/EBImage/; />
>   http://bioconductor.org/images/logo/jpg/bioconductor_logo_rgb.jpg; />
>
>
> This should cause sites that implement the Open Graph Protocol (like
> LinkedIn and Facebook) to extract these elements from the page.
>
> Adding a custom image for each package will need to wait for another
> iteration. We need to decide on some standard for declaring these images,
> either a field/url in the DESCRIPTION file, and/or a standard location
> within the package.
>
> Dan
>
>
>
> >
> > Jiri Hon
> >
> > Dne 29.10.2015 v 14:59 Jim Hester napsal(a):
> >> It seems to be pulling it from an invisible `#tooltip` div on the page.
> >> This happens to be the first `` block on the page, which is probably
> why
> >> it is being used by linkedin.
> >>
> >> ```html
> >> 
> >>  To install this package, start R and enter:
> >> ## try http:// if https:// URLs are not supported
> >> source("https://bioconductor.org/biocLite.R;)
> >> biocLite("biobroom")
> >>   In most cases, you don't need to download the
> >>  package archive at all.
> >> 
> >> ```
> >>
> >> Probably these results could be improved by moving this tooltip block
> below
> >> the package description, or annotating it with some metadata to exclude
> it
> >> from the linkedin summary (I don't know what that would be).
> >>
> >> On Thu, Oct 29, 2015 at 9:50 AM, Kasper Daniel Hansen <
> >> kasperdanielhan...@gmail.com> wrote:
> >>
> >>> For people like me who might be a bit behind on social media, it might
> be
> >>> nice to identify where the blurb is generated from.  Is it the first
> >>> sentence of the description or ...?
> >>>
> >>> Best,
> >>> Kasper
> >>>
> >>> On Thu, Oct 29, 2015 at 9:48 AM, Andrzej Oleś 
> >>> wrote:
> >>>
>  Hi Thomas,
> 
>  thank you for sharing your idea!
> 
>  One possibility would be to include a package icon/logo next to the
> >>> package
>  name if the package provides one. This file could be saved as
> >>> inst/logo.png
>  or vignettes/logo.png, e.g. see
>  https://github.com/aoles/EBImage/blob/master/vignettes/logo.png
> 
>  Best,
>  Andrzej
> 
>  On Thu, Oct 29, 2015 at 2:27 PM, Thomas Lin Pedersen <
> >>> thomas...@gmail.com>
>  wrote:
> 
> > I just sat down to write a linkedIn update about my recent package
> and
> > noticed that a thumbnail styled summary was added once I put in the
> URL
>  for
> > my package (this is probably old news - I’m not much of a social
> media
> > guy). The summary was a bit dull though, and I was wondering if it
> was
> > possible to change something on the package landing pages to spice
> >>> these
> > thumbnails up a bit, so they would appear more exciting when people
> >>> share
> > their work on Facebook/linkedIn/Twitter…
> >
> > Don’t know how much work this entail - it is definitely in the
> > nice-to-have rather than need-to-have pile of feature requests
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 
>   [[alternative HTML version deleted]]
> 
>  ___
>  Bioc-devel@r-project.org mailing list
>  https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 
> >>>
> >>>  [[alternative HTML version deleted]]
> >>>
> >>> ___
> >>> Bioc-devel@r-project.org 

Re: [Bioc-devel] is.unsorted method for GRanges objects

[Peter Hickey]

Hi Michael,

Sorry, I took this off-list with Hervé. I've written a prototype
is.unsorted,GenomicRanges-method.

I structured it following the lead of order,GenomicRanges-method, so
there's an outer R-level that "translates" the GenomicRanges object to
4 integer vectors (actually the slowest part of the whole process, I
think). These 4 integer vectors are then passed to a lower-level
function that does the actual looped comparisons. Side note, this
lower-level function, isUnsortedIntegerQuads(), is perhaps better
housed in S4Vectors.

isUnsortedIntegerQuads() currently calls an Rcpp function, but I'll
convert that to a plain C function callable using .Call2() tomorrow
morning (Melbourne, Australia time).

I'll then try to figure out the necessary plumbing in order to get it
all up and running as part of the GenomicRanges package. I hope to
finish it all and send through a patch tomorrow, but it depends what
else hits my desk. (I'll add docs and unit tests if the patch is considered
helpful).

Cheers,
Pete

On 3 November 2015 at 22:41, Michael Lawrence  wrote:
> If we're going to do that, it brings up the question of whether
> is.unsorted() could be made to handle multiple vectors like order(). It
> would be nice to implement that logic only once. Suggestions for the API?
> New function? Additional argument? Patches welcome ;)
>
> Michael
>
> On Mon, Nov 2, 2015 at 10:45 PM, Hervé Pagès  wrote:
>>
>> OK. Thanks Pete for the timings. The fact that the relative difference
>> in speed is larger for small n in your brief tests is because one
>> performs roughly in n*log(n) (quicksort-based) and the other one is
>> linear in time. Which is why I assumed (but without doing any testing)
>> that the latter was going to perform better. Anyway it seems that there
>> is just too much overhead involved in that solution to make it a good
>> candidate.
>>
>> So back to square one and to the business of trying to come up with
>> something even more efficient than is.unsorted(order(x)) for
>> GenomicRanges objects. It's indeed important that is.unsorted() be
>> as fast and as memory efficient as possible since it is typically
>> used as a quick/cheap way of checking whether a costly sort is
>> required or not (e.g. with something like if (is.unsorted(x))
>> x <- sort(x)).
>>
>> So it seems that unfortunately we won't be able to do it without
>> writing some C code. Your proposal sounds very reasonable to me. It
>> will perform in linear time (in the worst case) and avoid any copy
>> of the object (that we get with the expensive calls to head() and
>> tail() in my solution). So will be much faster than the 2 R solutions
>> whatever n is. Should work on GenomicRanges objects, not just GRanges
>> (this is easily achieved by passing S4Vectors:::decodeRle(seqnames(x)),
>> start(x), with(x), and S4Vectors:::decodeRle(strand(x)) to the .Call
>> entry point).
>>
>> I'll take your patch if you want to work on this or I can add this
>> to GenomicRanges, let me know. We should probably take this off-list.
>>
>> Thanks,
>> H.
>>
>>
>> On 11/02/2015 09:43 PM, Peter Hickey wrote:
>>>
>>> Thanks for everyones' input.
>>>
>>> @Hervé FWIW, the below benchmark suggests that unfortunately this is a
>>> fair bit slower than is.unsorted(order(gr)) when the length of the
>>> GRanges object is < 10,000,000 (the relative difference in speed is
>>> larger for small n in my brief tests; I didn't check above n >
>>> 10,000,000)
>>>
>>> ```r
>>> # GenomicRanges_1.23.1
>>> library(GenomicRanges)
>>>
>>> # Simulate some random ranges
>>> sim_gr <- function(n) {
>>>GRanges(seqnames = sample(paste0("chr", 1:22), n, replace = TRUE),
>>>ranges = IRanges(sample(n * 10, size = n, replace = TRUE),
>>>width = runif(n, 1, 10)),
>>>strand = sample(c("+", "-", "*"), n, replace = TRUE),
>>>seqinfo = Seqinfo(paste0("chr", 1:22)))
>>>
>>> }
>>>
>>> gr <- sim_gr(1000)
>>>
>>> herve <- function(x, na.rm=FALSE, strictly=FALSE) {
>>>if (length(x) <= 1L)
>>>  return(FALSE)
>>>x1 <- head(x, n=-1)
>>>x2 <- tail(x, n=-1)
>>>if (strictly)
>>>  return(any(x1 >= x2))
>>>any(x1 > x2)
>>> }
>>>
>>> # 22 seconds
>>> system.time(herve(gr))
>>> # 11.3 seconds
>>> system.time(is.unsorted(order(gr)))
>>>
>>> # And when it's already sorted
>>> gr2 <- sort(gr)
>>>
>>> # 4.3 seconds
>>> system.time(herve(gr2))
>>> # 0.2 seconds
>>> system.time(is.unsorted(order(gr2)))
>>> ```
>>>
>>> Roughly, it looks like the head(), tail() calls take approximately 1/4
>>> of the time each, while the any() call takes the remaining 1/2 of the
>>> time. I was thinking it might be possible to make this quite fast by
>>> looping over the GRanges object at the C-level and breaking out of the
>>> loop if gr[i+1] <= gr[i] or gr[i+1] < gr[i], as appropriate. Does this
>>> sound reasonable?
>>>
>>> Cheers,
>>> Pete
>>>
>>> On 3 November 2015 at 14:06, Michael Lawrence 

Re: [Bioc-devel] is.unsorted method for GRanges objects

[Michael Lawrence]

Great. My point was that the "integer quad" algorithm could be generalized
to any number of vectors and made part of base R. But maybe that's too much
work for now.

Michael

On Tue, Nov 3, 2015 at 3:50 AM, Peter Hickey  wrote:

> Hi Michael,
>
> Sorry, I took this off-list with Hervé. I've written a prototype
> is.unsorted,GenomicRanges-method.
>
> I structured it following the lead of order,GenomicRanges-method, so
> there's an outer R-level that "translates" the GenomicRanges object to
> 4 integer vectors (actually the slowest part of the whole process, I
> think). These 4 integer vectors are then passed to a lower-level
> function that does the actual looped comparisons. Side note, this
> lower-level function, isUnsortedIntegerQuads(), is perhaps better
> housed in S4Vectors.
>
> isUnsortedIntegerQuads() currently calls an Rcpp function, but I'll
> convert that to a plain C function callable using .Call2() tomorrow
> morning (Melbourne, Australia time).
>
> I'll then try to figure out the necessary plumbing in order to get it
> all up and running as part of the GenomicRanges package. I hope to
> finish it all and send through a patch tomorrow, but it depends what
> else hits my desk. (I'll add docs and unit tests if the patch is considered
> helpful).
>
> Cheers,
> Pete
>
> On 3 November 2015 at 22:41, Michael Lawrence 
> wrote:
> > If we're going to do that, it brings up the question of whether
> > is.unsorted() could be made to handle multiple vectors like order(). It
> > would be nice to implement that logic only once. Suggestions for the API?
> > New function? Additional argument? Patches welcome ;)
> >
> > Michael
> >
> > On Mon, Nov 2, 2015 at 10:45 PM, Hervé Pagès 
> wrote:
> >>
> >> OK. Thanks Pete for the timings. The fact that the relative difference
> >> in speed is larger for small n in your brief tests is because one
> >> performs roughly in n*log(n) (quicksort-based) and the other one is
> >> linear in time. Which is why I assumed (but without doing any testing)
> >> that the latter was going to perform better. Anyway it seems that there
> >> is just too much overhead involved in that solution to make it a good
> >> candidate.
> >>
> >> So back to square one and to the business of trying to come up with
> >> something even more efficient than is.unsorted(order(x)) for
> >> GenomicRanges objects. It's indeed important that is.unsorted() be
> >> as fast and as memory efficient as possible since it is typically
> >> used as a quick/cheap way of checking whether a costly sort is
> >> required or not (e.g. with something like if (is.unsorted(x))
> >> x <- sort(x)).
> >>
> >> So it seems that unfortunately we won't be able to do it without
> >> writing some C code. Your proposal sounds very reasonable to me. It
> >> will perform in linear time (in the worst case) and avoid any copy
> >> of the object (that we get with the expensive calls to head() and
> >> tail() in my solution). So will be much faster than the 2 R solutions
> >> whatever n is. Should work on GenomicRanges objects, not just GRanges
> >> (this is easily achieved by passing S4Vectors:::decodeRle(seqnames(x)),
> >> start(x), with(x), and S4Vectors:::decodeRle(strand(x)) to the .Call
> >> entry point).
> >>
> >> I'll take your patch if you want to work on this or I can add this
> >> to GenomicRanges, let me know. We should probably take this off-list.
> >>
> >> Thanks,
> >> H.
> >>
> >>
> >> On 11/02/2015 09:43 PM, Peter Hickey wrote:
> >>>
> >>> Thanks for everyones' input.
> >>>
> >>> @Hervé FWIW, the below benchmark suggests that unfortunately this is a
> >>> fair bit slower than is.unsorted(order(gr)) when the length of the
> >>> GRanges object is < 10,000,000 (the relative difference in speed is
> >>> larger for small n in my brief tests; I didn't check above n >
> >>> 10,000,000)
> >>>
> >>> ```r
> >>> # GenomicRanges_1.23.1
> >>> library(GenomicRanges)
> >>>
> >>> # Simulate some random ranges
> >>> sim_gr <- function(n) {
> >>>GRanges(seqnames = sample(paste0("chr", 1:22), n, replace = TRUE),
> >>>ranges = IRanges(sample(n * 10, size = n, replace = TRUE),
> >>>width = runif(n, 1, 10)),
> >>>strand = sample(c("+", "-", "*"), n, replace = TRUE),
> >>>seqinfo = Seqinfo(paste0("chr", 1:22)))
> >>>
> >>> }
> >>>
> >>> gr <- sim_gr(1000)
> >>>
> >>> herve <- function(x, na.rm=FALSE, strictly=FALSE) {
> >>>if (length(x) <= 1L)
> >>>  return(FALSE)
> >>>x1 <- head(x, n=-1)
> >>>x2 <- tail(x, n=-1)
> >>>if (strictly)
> >>>  return(any(x1 >= x2))
> >>>any(x1 > x2)
> >>> }
> >>>
> >>> # 22 seconds
> >>> system.time(herve(gr))
> >>> # 11.3 seconds
> >>> system.time(is.unsorted(order(gr)))
> >>>
> >>> # And when it's already sorted
> >>> gr2 <- sort(gr)
> >>>
> >>> # 4.3 seconds
> >>> system.time(herve(gr2))
> >>> # 0.2 seconds
> >>> system.time(is.unsorted(order(gr2)))

Re: [Bioc-devel] is.unsorted method for GRanges objects

[Michael Lawrence]

If we're going to do that, it brings up the question of whether
is.unsorted() could be made to handle multiple vectors like order(). It
would be nice to implement that logic only once. Suggestions for the API?
New function? Additional argument? Patches welcome ;)

Michael

On Mon, Nov 2, 2015 at 10:45 PM, Hervé Pagès  wrote:

> OK. Thanks Pete for the timings. The fact that the relative difference
> in speed is larger for small n in your brief tests is because one
> performs roughly in n*log(n) (quicksort-based) and the other one is
> linear in time. Which is why I assumed (but without doing any testing)
> that the latter was going to perform better. Anyway it seems that there
> is just too much overhead involved in that solution to make it a good
> candidate.
>
> So back to square one and to the business of trying to come up with
> something even more efficient than is.unsorted(order(x)) for
> GenomicRanges objects. It's indeed important that is.unsorted() be
> as fast and as memory efficient as possible since it is typically
> used as a quick/cheap way of checking whether a costly sort is
> required or not (e.g. with something like if (is.unsorted(x))
> x <- sort(x)).
>
> So it seems that unfortunately we won't be able to do it without
> writing some C code. Your proposal sounds very reasonable to me. It
> will perform in linear time (in the worst case) and avoid any copy
> of the object (that we get with the expensive calls to head() and
> tail() in my solution). So will be much faster than the 2 R solutions
> whatever n is. Should work on GenomicRanges objects, not just GRanges
> (this is easily achieved by passing S4Vectors:::decodeRle(seqnames(x)),
> start(x), with(x), and S4Vectors:::decodeRle(strand(x)) to the .Call
> entry point).
>
> I'll take your patch if you want to work on this or I can add this
> to GenomicRanges, let me know. We should probably take this off-list.
>
> Thanks,
> H.
>
>
> On 11/02/2015 09:43 PM, Peter Hickey wrote:
>
>> Thanks for everyones' input.
>>
>> @Hervé FWIW, the below benchmark suggests that unfortunately this is a
>> fair bit slower than is.unsorted(order(gr)) when the length of the
>> GRanges object is < 10,000,000 (the relative difference in speed is
>> larger for small n in my brief tests; I didn't check above n >
>> 10,000,000)
>>
>> ```r
>> # GenomicRanges_1.23.1
>> library(GenomicRanges)
>>
>> # Simulate some random ranges
>> sim_gr <- function(n) {
>>GRanges(seqnames = sample(paste0("chr", 1:22), n, replace = TRUE),
>>ranges = IRanges(sample(n * 10, size = n, replace = TRUE),
>>width = runif(n, 1, 10)),
>>strand = sample(c("+", "-", "*"), n, replace = TRUE),
>>seqinfo = Seqinfo(paste0("chr", 1:22)))
>>
>> }
>>
>> gr <- sim_gr(1000)
>>
>> herve <- function(x, na.rm=FALSE, strictly=FALSE) {
>>if (length(x) <= 1L)
>>  return(FALSE)
>>x1 <- head(x, n=-1)
>>x2 <- tail(x, n=-1)
>>if (strictly)
>>  return(any(x1 >= x2))
>>any(x1 > x2)
>> }
>>
>> # 22 seconds
>> system.time(herve(gr))
>> # 11.3 seconds
>> system.time(is.unsorted(order(gr)))
>>
>> # And when it's already sorted
>> gr2 <- sort(gr)
>>
>> # 4.3 seconds
>> system.time(herve(gr2))
>> # 0.2 seconds
>> system.time(is.unsorted(order(gr2)))
>> ```
>>
>> Roughly, it looks like the head(), tail() calls take approximately 1/4
>> of the time each, while the any() call takes the remaining 1/2 of the
>> time. I was thinking it might be possible to make this quite fast by
>> looping over the GRanges object at the C-level and breaking out of the
>> loop if gr[i+1] <= gr[i] or gr[i+1] < gr[i], as appropriate. Does this
>> sound reasonable?
>>
>> Cheers,
>> Pete
>>
>> On 3 November 2015 at 14:06, Michael Lawrence 
>> wrote:
>>
>>>
>>>
>>> On Mon, Nov 2, 2015 at 6:39 PM, Hervé Pagès 
>>> wrote:
>>>

 Hi,

 @Pete:

 2a- I would just compare pairs of adjacent elements, taking
 advantage of the fact that <= is vectorized and cheap. So something
 like:

setMethod("is.unsorted", "Vector",
  function(x, na.rm=FALSE, strictly=FALSE)
  {
  if (length(x) <= 1L)
  return(FALSE)
  x1 <- head(x, n=-1)
  x2 <- tail(x, n=-1)
  if (strictly)
  return(any(x1 >= x2))
  any(x1 > x2)
  }
)

 Since this will work on any Vector derivative for which <= and
 subsetting are defined, it's a good candidate for being the default
 "is.unsorted" method for Vector objects. I'll add it to S4Vectors.

 2b- The semantic of is.unsorted() on a GRangesList object or any
 List object in general should be sapply(x, is.unsorted), for
 consistency with order(), sort(), etc:

> sort(IntegerList(4:3, 1:-2))
IntegerList of length 2
[[1]] 3 4
[[2]] -2 -1 0 1

 

Re: [Bioc-devel] BiocStyle::doc_date() not found when testing on Travis via metacran/r-builder

[Andrzej Oleś]

Hi Leonardo,

thank you for reporting your issue with BiocStyle. I haven't experienced it
before.

The error you're getting indicates that BiocStyle might not be loaded
before processing the code from the YAML header. This is normally handled
by the BiocStyle::html_document() function which loads BiocStyle to expose
the functions. You could try using

date: "`r BiocStyle::doc_date()`"

to see whether this helps..

Cheers,
Andrzej

On Tue, Nov 3, 2015 at 5:25 AM, Leonardo Collado Torres 
wrote:

> I should add that in my local machine I have pandoc 1.13.1 installed.
> Also, I just noted that metacran/r-builder uses pandoc 1.12.4.2 at
> https://github.com/metacran/r-builder/blob/master/pkg-build.sh#L17
>
> So this could be a pandoc issue.
>
> On Mon, Nov 2, 2015 at 11:07 PM, Leonardo Collado Torres
>  wrote:
> > Hi,
> > I was going to ask this as an issue at the Bioconductor/BiocStyle
> > repo, but the issue tracker is disabled.
> > I ran into a bug which I'm not sure where it comes from. It happens
> > during R CMD build using BiocStyle to generate an html vignette.
> > For example, here is one such error:
> > Quitting from lines 2-17 (derfinderHelper.Rmd)
> > Error: processing vignette 'derfinderHelper.Rmd' failed with diagnostics:
> > could not find function "doc_date"
> > Execution halted
> > doc_date comes from the yaml for the html vignette in which I use:
> > date: "r doc_date()"
> > The full log for this error message is at:
> >
> https://travis-ci.org/leekgroup/derfinderHelper/builds/88823566#L3158-L3167
> > I used BiocStyle version 1.8.0 (see
> > https://travis-ci.org/leekgroup/derfinderHelper/builds/88823566#L3393)
> > and metacran/r-builder with the following Travis configuration file
> >
> https://github.com/leekgroup/derfinderHelper/blob/86c2f3b38425ee4b089a5aab1716b058926968f7/.travis.yml
> > I got the same error with other packages but wasn't able to reproduce
> > it locally. I tried with pandoc 1.13.1 instead of 1.12.3 and it didn't
> > work either on Travis (using metacran/r-builder). However, switching
> > to R Travis v2 (the one with docs on the Travis website) works.
> > Here is a full log of a case that works
> >
> https://travis-ci.org/leekgroup/derfinderHelper/builds/88925326#L1757-L1765
> > using the same BiocStyle version and the following Travis config file
> >
> https://github.com/leekgroup/derfinderHelper/blob/634aed4148c7bcb69438d0959bd1175ad03bce52/.travis.yml
> > It's also the same R version (3.2.2).
> > I think that something about the R version in metacran/r-builder could
> > be the problem. Before I report this to metacran/r-builder, I was
> > wondering if the BiocStyle maintainers had come up with this type of
> > error before or have any clues on how to resolve it.
> > Thanks,
> > Leo
> > PS I'd like this to work with metacran/r-builder given the R-devel
> > issue with R Travis v2. Although it seems like docker support is on
> > the way https://github.com/kasperdanielhansen/bsseq/issues/5
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] AnnotationHub downtime Wed 11/4

[Dan Tenenbaum]

Hello all,

The AnnotationHub server will be down for maintenance tomorrow (Wed Nov 4) at 
5PM Seattle Time (01:00 UTC).

The downtime should be no longer than one hour, probably much shorter than that.

Thanks,
Dan

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] commit fail in devel branch

[Yu, Guangchuang]

Dear Dan,

Thank you for your quick reply!

It works by specifying my username and password.

Bests,
Guangchuang

On Wed, Nov 4, 2015 at 9:16 AM, Dan Tenenbaum 
wrote:

>
>
> - Original Message -
> > From: "Yu, Guangchuang" 
> > To: "bioc-devel" 
> > Sent: Tuesday, November 3, 2015 5:12:02 PM
> > Subject: [Bioc-devel] commit fail in devel branch
>
> > Dear all,
> >
> > I found devel branch reject my commit by throwing the following msg:
> >
> > ➜  clusterProfiler git:(master) svn ci -m 'facet dotplot'
> > svn: E175013: Commit failed (details follow):
> > svn: E175013: Access to '/bioconductor/!svn/me' forbidden
> >
> > There maybe some file permission issue.
>
> What is the name of your package?
> What is the output of `svn info`?
> Are you specifying your svn username and password? You can do this with:
>
> svn ci --username MYUSERNAME --password MYPASSWORD -m 'facet dotplot
>
> I see that it says 'git' in your prompt but I don't think that's the
> problem
> since if you were not in an svn working copy you would see
> an error to that effect.
>
> Dan
>
>
> >
> > Bests,
> > Guangchuang
> > --
> > --~--~-~--~~~---~--~~
> > Guangchuang Yu, PhD Candidate
> > State Key Laboratory of Emerging Infectious Diseases
> > School of Public Health
> > The University of Hong Kong
> > Hong Kong SAR, China
> > www: http://ygc.name
> > -~--~~~~--~~--~--~---
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>



-- 
--~--~-~--~~~---~--~~
Guangchuang Yu, PhD Candidate
State Key Laboratory of Emerging Infectious Diseases
School of Public Health
The University of Hong Kong
Hong Kong SAR, China
www: http://ygc.name
-~--~~~~--~~--~--~---

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] citation() error for BiocParallel and S4Vectors

[Morgan, Martin]

It is this commit


r69509 | hornik | 2015-10-12 07:06:54 -0400 (Mon, 12 Oct 2015) | 1 line

Fixes for PR #16240 and PR #16550.


which is failing when z$url == meta$URL[1] == NULL. I have bcc'd Kurt Hornik

Martin


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Leonardo 
Collado Torres [lcoll...@jhu.edu]
Sent: Tuesday, November 03, 2015 10:50 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] citation() error for BiocParallel and S4Vectors

Hi,

The daily build report showed a similar error in several of my
packages when building on Linux and Windows. I was able to reproduce
this error under R-devel on Windows and it pops up when using the
citation() function. In particular with BiocParallel and S4Vectors.

This error doesn't pop up in the build report for BiocParallel or
S4Vectors and I believe that's because they are not using the
citation() function in their vignettes. However, I would have guessed
that this error would affect the Bioc-devel landing pages but it
hasn't.

I haven't found any leads when looking at the DESCRIPTION files for
these packages (they don't have a inst/CITATION file). So my guess is
that this is really a bug in citation() for R-devel. If anyone has a
guess please let me know.

I didn't see a thread about this in R-devel (last 3 months) so I'll
likely re-post this there if needed.

Thanks,
Leo


> citation('BiocParallel')
Error in if (!length(z$url) && !is.na(url <- meta$URL[1L])) { :
  missing value where TRUE/FALSE needed
In addition: Warning messages:
1: In citation("BiocParallel") :
  no date field in DESCRIPTION file of package ‘BiocParallel’
2: In is.na(url <- meta$URL[1L]) :
  is.na() applied to non-(list or vector) of type 'NULL'
> traceback()
1: citation("BiocParallel")

> citation('S4Vectors')
Error in if (!length(z$url) && !is.na(url <- meta$URL[1L])) { :
  missing value where TRUE/FALSE needed
In addition: Warning messages:
1: In citation("S4Vectors") :
  no date field in DESCRIPTION file of package ‘S4Vectors’
2: In is.na(url <- meta$URL[1L]) :
  is.na() applied to non-(list or vector) of type 'NULL'
> traceback()
1: citation("S4Vectors")

> sessionInfo()
R Under development (unstable) (2015-11-02 r69589)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

locale:
[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

> packageVersion('BiocParallel')
[1] ‘1.5.0’
> packageVersion('S4Vectors')
[1] ‘0.9.6’

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] citation() error for BiocParallel and S4Vectors

[Leonardo Collado Torres]

Hi,

The daily build report showed a similar error in several of my
packages when building on Linux and Windows. I was able to reproduce
this error under R-devel on Windows and it pops up when using the
citation() function. In particular with BiocParallel and S4Vectors.

This error doesn't pop up in the build report for BiocParallel or
S4Vectors and I believe that's because they are not using the
citation() function in their vignettes. However, I would have guessed
that this error would affect the Bioc-devel landing pages but it
hasn't.

I haven't found any leads when looking at the DESCRIPTION files for
these packages (they don't have a inst/CITATION file). So my guess is
that this is really a bug in citation() for R-devel. If anyone has a
guess please let me know.

I didn't see a thread about this in R-devel (last 3 months) so I'll
likely re-post this there if needed.

Thanks,
Leo


> citation('BiocParallel')
Error in if (!length(z$url) && !is.na(url <- meta$URL[1L])) { :
  missing value where TRUE/FALSE needed
In addition: Warning messages:
1: In citation("BiocParallel") :
  no date field in DESCRIPTION file of package ‘BiocParallel’
2: In is.na(url <- meta$URL[1L]) :
  is.na() applied to non-(list or vector) of type 'NULL'
> traceback()
1: citation("BiocParallel")

> citation('S4Vectors')
Error in if (!length(z$url) && !is.na(url <- meta$URL[1L])) { :
  missing value where TRUE/FALSE needed
In addition: Warning messages:
1: In citation("S4Vectors") :
  no date field in DESCRIPTION file of package ‘S4Vectors’
2: In is.na(url <- meta$URL[1L]) :
  is.na() applied to non-(list or vector) of type 'NULL'
> traceback()
1: citation("S4Vectors")

> sessionInfo()
R Under development (unstable) (2015-11-02 r69589)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

locale:
[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

> packageVersion('BiocParallel')
[1] ‘1.5.0’
> packageVersion('S4Vectors')
[1] ‘0.9.6’

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel