Re: [Bioc-devel] NAMESPACE question

[Robert Castelo]

hi Martin,

On 10/06/2014 07:24 PM, Martin Morgan wrote:
[...]

There are two 'as.vector' generics, one defined in Matrix and one in
BiocGenerics (and made available via IRanges). These generics have
different methods

 > showMethods(Matrix::as.vector)
Function: as.vector (package base)
x="abIndex", mode="ANY"
x="abIndex", mode="character"
x="ANY", mode="ANY"
x="dgCMatrix", mode="missing"
x="dgeMatrix", mode="missing"
x="diagonalMatrix", mode="missing"
x="dsCMatrix", mode="missing"
x="ldenseMatrix", mode="missing"
x="Matrix", mode="missing"
x="ndenseMatrix", mode="missing"
x="sparseVector", mode="character"
x="sparseVector", mode="missing"

 > showMethods(BiocGenerics::as.vector)
Function: as.vector (package BiocGenerics)
x="ANY"
x="AtomicList"
x="Rle"
x="XDouble"
x="XInteger"
x="XRaw"
x="XString"
x="XStringSet"

so it's important that your code clearly distinguish between generics.
One possibility is to remove importMethodsFrom(IRanges, as.vector) from
the NAMESPACE, and explicitly use IRanges::as.vector(...) in your code.


ok, i've done this as it is the easiest at the moment to meet the 
release schedule. i guess that in the future i should try to avoid using 
the '::' operator by importing exclusively what is needed from each package.



codetoolsBioC::writeNamespaceImports("qpgraph") might provide you with
some guidance (it's not 100% reliable; available via svn at
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC)
about what functionality is being imported.


thanks for the heads up about codetoolsBioC, i've tried it out and seen 
that some of the suggested imports are not necessary but some others i 
was really missing them (which makes me wonder how was it possible that 
he package did not break at those points).


one further question related to NAMESPACE. i subset GRanges objects in 
the package via the '[' operator, i've included this into the NAMESPACE 
file as:


importMethodsFrom(GenomicRanges,
  c, cbind, rbind,
  "mcols<-", start, end, strand, sort,
  "[", "[<-", "[[", "[[<-", "$", "$<-")

however, when the package reaches a subset operation x[i] with x being a 
GRanges object, an entire package loading sequence starts:


Loading required package: GenomicRanges
Loading required package: BiocGenerics
Loading required package: parallel

Attaching package: ‘BiocGenerics’
[... etc ...]

which may look a bit odd to the user. for every other imported method 
the package uses them silently without loading the corresponding 
package, am i importing '[' for GRanges objects from the wrong package? 
is there a way to import '[' so that my package can use it without 
triggering that package loading sequence?



thanks again!
robert.

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

Re: [Bioc-devel] RMarkdown for vignettes (builder issues)

[Gordon Ball]

Sorry to re-open this thread, but it appears that this configuration
works with some builders but not others. There appear to be two
different failure modes:

Works with: oaxaca, perceval (OSX 10.6, 10.9)

Fails with: moscato1 (windows 2008)

InvalidUrlException
"D:%5Cpackagebuilder%5Cjobs%5CSTATegRa_20141007024617%5CR-libs%5CBiocStyle%5Cresources%5Chtml%5Cbioconductor.css"
"Invalid scheme"

This appears to be an error in specific pandoc versions where it
interprets a windows drive letter as a URL scheme - see
https://github.com/jgm/pandoc/issues/1558

Fails with: zin1 (linux ubuntu 12.04)

pandoc: Error running filter pandoc-citeproc
pandoc-citeproc not found in path

The filter for processing references doesn't seem to be available. In
14.04 this is the package `pandoc-citeproc`, but it doesn't appear to be
available for 12.04. I assume this is only an issue if the Rmd document
includes a `bibliography:` field in the header.



Are these issues likely to be addressable for this release? If not, can
we get away with shipping a static vignette to avoid these problems?

(The build log in question is
http://bioconductor.org/spb_reports/STATegRa_0.99.3_buildreport_20141007025338.html
)

Thanks

Gordon Ball


On 04/10/14 00:02, Andrzej Oleś wrote:
> Hi Gordon, James,
> 
> thank you for pointing this out! At the time BiocStyle for markdown
> documents was developed 'rmarkdown' was not yet on CRAN and couldn't
> be used as a vignette builder engine.
> As things changed in the meantime, the approach described by Gordon
> should be just fine. I will update the BiocStyle vignette accordingly.
> 
> Best,
> Andrzej
> 
> On Fri, Oct 3, 2014 at 4:51 PM, Dan Tenenbaum  wrote:
>>
>>
>> - Original Message -
>>> From: "Henrik Bengtsson" 
>>> To: jmac...@u.washington.edu
>>> Cc: bioc-devel@r-project.org
>>> Sent: Friday, October 3, 2014 6:56:59 AM
>>> Subject: Re: [Bioc-devel] RMarkdown for vignettes
>>>
>>> I think it requires Bioc core to make a statement that pandoc will be
>>> added
>>> to the list of external software that can be assume to exist on the
>>> servers.
>>
>>
>> Pandoc is installed on the build servers. Several packages use it.
>>
>>>
>>> If it is also expected that users should be able to rebuild all
>>> vignettes/documents themselves, then that assumption has to be
>>> extended to
>>> the users as well. BTW, is there such an assumption on
>>> LaTeX-dependent
>>> packages today?
>>>
>>
>> Users only need LaTeX (or pandoc) if they are going to build package 
>> vignettes from svn. Source packages (as well as binary packages of course) 
>> already contain built vignettes.
>>
>> Dan
>>
>>
>>> Installing pandoc is not that hard and lightweight (much smaller than
>>> LaTeX), but it does add one more installation. On the other hand, it
>>> opens
>>> up for doing lots of other neat things.
>>>
>>> Henrik
>>> On Oct 3, 2014 6:40 AM, "James W. MacDonald"  wrote:
>>>
 Hi Gordon,

 Sean Davis has something about this on his blog:


 http://watson.nci.nih.gov/~sdavis/blog/convert_from_sweave_to_r_markdown_vignettes/

 Best,

 Jim



 On Fri, Oct 3, 2014 at 9:06 AM, Gordon Ball 
 wrote:

> Hello
>
> Is it possible to use (RStudio's) rmarkdown package as a vignette
> builder for the upcoming release?
>
> ie, with the (at least locally working) configuration
>
> DESCRIPTION
>
> Suggests: knitr, rmarkdown, BiocStyle
> VignetteBuilder: knitr
>
> vignette/vignette.Rmd
>
> ---
> title: ...
> output: BiocStyle::html_document
> vignette: >
> %% \VignetteEngine{knitr::rmarkdown}
> %% \VignetteIndexEntry{...}
> 
>
> I couldn't find any explicit reference to markdown vs rmarkdown
> in the
> package guidelines. The documentation for [BiocStyle] indicates
> that it
> isn't possible to build package vignettes with the newer
> rmarkdown - is
> that still correct?
>
> I note that the newer [rmarkdown] is now in CRAN, so presumably
> can be
> used by the builders - but do they have the non-R dependency
> (pandoc)
> available?
>
> The rationale for wanting rmarkdown instead markdown is support
> for a
> few extended features, particularly being able to cite from a
> bibtex
> file (which as far as I know isn't possible with the older
> markdown).
>
> Thanks
>
> Gordon Ball
> Computational Medicine Group
> Karolinska Institute
>
>
>
> [BiocStyle]:
>
>
 http://www.bioconductor.org/packages/devel/bioc/vignettes/BiocStyle/inst/doc/HtmlStyle.html
>
> [rmarkdown]: http://cran.r-project.org/web/packages/rmarkdown/
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[Bioc-devel] GOexpress: new package to visualise microarray and RNAseq data using gene ontology annotations

[Kevin Rue-Albrecht]

Dear all,

I would like to introduce a recent addition to Bioconductor.
I hope those of you working with transcriptomics data will find it useful
for their own work.

*GOexpress *is a package taking an *ExpressionSet *object minimally
including *assayData *and *phenoData* corresponding to either microarray or
RNA-Sequencing data, and enables rapid plotting of the expression profile
of any given gene in the different experimental groups. The package also
initially fetches gene ontology annotations from the *Ensembl BioMart* to
display the expression level of genes associated with each ontology in a
heatmap. Consequently, all species and microarray present in the *Ensembl
BioMart* should be supported by *GOexpress* (only a few were tested during
the development of the package).

We included two scoring methods (random-forest and ANOVA) to rank genes and
gene ontologies best clustering predefined groups of samples (e.g.
treatment groups). Note that we do not intend to compete with packages such
as GOstats and topGO for hypothesis testing, but rather to complement such
packages with means of accompanying their result statistics with plots
showing group-wise and sample-wise expression levels.

I have a few more ideas of my own to extend the package when time allows,
but I do also welcome feedback and suggestions from testers that could
benefit the community.

Link: http://bioconductor.org/packages/devel/bioc/html/GOexpress.html

Yours sincerely,
Kevin

-- 
Kévin RUE-ALBRECHT
Wellcome Trust Computational Infection Biology PhD Programme
University College Dublin
Ireland
http://fr.linkedin.com/pub/k%C3%A9vin-rue/28/a45/149/en

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] NAMESPACE question

[Michael Lawrence]

Does that happen with the other methods or just "["? As a last resort, you
could just drop the import (because "[" is a primitive, it should just
work).

On Tue, Oct 7, 2014 at 3:08 AM, Robert Castelo 
wrote:

> hi Martin,
>
> On 10/06/2014 07:24 PM, Martin Morgan wrote:
> [...]
>
>  There are two 'as.vector' generics, one defined in Matrix and one in
>> BiocGenerics (and made available via IRanges). These generics have
>> different methods
>>
>>  > showMethods(Matrix::as.vector)
>> Function: as.vector (package base)
>> x="abIndex", mode="ANY"
>> x="abIndex", mode="character"
>> x="ANY", mode="ANY"
>> x="dgCMatrix", mode="missing"
>> x="dgeMatrix", mode="missing"
>> x="diagonalMatrix", mode="missing"
>> x="dsCMatrix", mode="missing"
>> x="ldenseMatrix", mode="missing"
>> x="Matrix", mode="missing"
>> x="ndenseMatrix", mode="missing"
>> x="sparseVector", mode="character"
>> x="sparseVector", mode="missing"
>>
>>  > showMethods(BiocGenerics::as.vector)
>> Function: as.vector (package BiocGenerics)
>> x="ANY"
>> x="AtomicList"
>> x="Rle"
>> x="XDouble"
>> x="XInteger"
>> x="XRaw"
>> x="XString"
>> x="XStringSet"
>>
>> so it's important that your code clearly distinguish between generics.
>> One possibility is to remove importMethodsFrom(IRanges, as.vector) from
>> the NAMESPACE, and explicitly use IRanges::as.vector(...) in your code.
>>
>
> ok, i've done this as it is the easiest at the moment to meet the release
> schedule. i guess that in the future i should try to avoid using the '::'
> operator by importing exclusively what is needed from each package.
>
>  codetoolsBioC::writeNamespaceImports("qpgraph") might provide you with
>> some guidance (it's not 100% reliable; available via svn at
>> https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC
>> )
>> about what functionality is being imported.
>>
>
> thanks for the heads up about codetoolsBioC, i've tried it out and seen
> that some of the suggested imports are not necessary but some others i was
> really missing them (which makes me wonder how was it possible that he
> package did not break at those points).
>
> one further question related to NAMESPACE. i subset GRanges objects in the
> package via the '[' operator, i've included this into the NAMESPACE file as:
>
> importMethodsFrom(GenomicRanges,
>   c, cbind, rbind,
>   "mcols<-", start, end, strand, sort,
>   "[", "[<-", "[[", "[[<-", "$", "$<-")
>
> however, when the package reaches a subset operation x[i] with x being a
> GRanges object, an entire package loading sequence starts:
>
> Loading required package: GenomicRanges
> Loading required package: BiocGenerics
> Loading required package: parallel
>
> Attaching package: ‘BiocGenerics’
> [... etc ...]
>
> which may look a bit odd to the user. for every other imported method the
> package uses them silently without loading the corresponding package, am i
> importing '[' for GRanges objects from the wrong package? is there a way to
> import '[' so that my package can use it without triggering that package
> loading sequence?
>
>
> thanks again!
> robert.
>
>
> ___
> 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

Re: [Bioc-devel] NAMESPACE question

[Robert Castelo]

hi, it happens only with "[", that's why i'm puzzled.

it behaves as if you load a GRanges object 'x' and try to subset it

x[1]

without loading 'GenomicRanges' first.

robert.

On 10/07/2014 05:05 PM, Michael Lawrence wrote:

Does that happen with the other methods or just "["? As a last resort,
you could just drop the import (because "[" is a primitive, it should
just work).

On Tue, Oct 7, 2014 at 3:08 AM, Robert Castelo mailto:robert.cast...@upf.edu>> wrote:

hi Martin,

On 10/06/2014 07:24 PM, Martin Morgan wrote:
[...]

There are two 'as.vector' generics, one defined in Matrix and one in
BiocGenerics (and made available via IRanges). These generics have
different methods

 > showMethods(Matrix::as.vector)
Function: as.vector (package base)
x="abIndex", mode="ANY"
x="abIndex", mode="character"
x="ANY", mode="ANY"
x="dgCMatrix", mode="missing"
x="dgeMatrix", mode="missing"
x="diagonalMatrix", mode="missing"
x="dsCMatrix", mode="missing"
x="ldenseMatrix", mode="missing"
x="Matrix", mode="missing"
x="ndenseMatrix", mode="missing"
x="sparseVector", mode="character"
x="sparseVector", mode="missing"

 > showMethods(BiocGenerics::as.__vector)
Function: as.vector (package BiocGenerics)
x="ANY"
x="AtomicList"
x="Rle"
x="XDouble"
x="XInteger"
x="XRaw"
x="XString"
x="XStringSet"

so it's important that your code clearly distinguish between
generics.
One possibility is to remove importMethodsFrom(IRanges,
as.vector) from
the NAMESPACE, and explicitly use IRanges::as.vector(...) in
your code.


ok, i've done this as it is the easiest at the moment to meet the
release schedule. i guess that in the future i should try to avoid
using the '::' operator by importing exclusively what is needed from
each package.

codetoolsBioC::__writeNamespaceImports("__qpgraph") might
provide you with
some guidance (it's not 100% reliable; available via svn at

https://hedgehog.fhcrc.org/__bioconductor/trunk/madman/__Rpacks/codetoolsBioC

)
about what functionality is being imported.


thanks for the heads up about codetoolsBioC, i've tried it out and
seen that some of the suggested imports are not necessary but some
others i was really missing them (which makes me wonder how was it
possible that he package did not break at those points).

one further question related to NAMESPACE. i subset GRanges objects
in the package via the '[' operator, i've included this into the
NAMESPACE file as:

importMethodsFrom(__GenomicRanges,
   c, cbind, rbind,
"mcols<-", start, end, strand, sort,
"[", "[<-", "[[", "[[<-", "$", "$<-")

however, when the package reaches a subset operation x[i] with x
being a GRanges object, an entire package loading sequence starts:

Loading required package: GenomicRanges
Loading required package: BiocGenerics
Loading required package: parallel

Attaching package: ‘BiocGenerics’
[... etc ...]

which may look a bit odd to the user. for every other imported
method the package uses them silently without loading the
corresponding package, am i importing '[' for GRanges objects from
the wrong package? is there a way to import '[' so that my package
can use it without triggering that package loading sequence?


thanks again!
robert.


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





--
Robert Castelo, PhD
Associate Professor
Dept. of Experimental and Health Sciences
Universitat Pompeu Fabra (UPF)
Barcelona Biomedical Research Park (PRBB)
Dr Aiguader 88
E-08003 Barcelona, Spain
telf: +34.933.160.514
fax: +34.933.160.550

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

Re: [Bioc-devel] NAMESPACE question

[Martin Morgan]

On 10/07/2014 08:15 AM, Robert Castelo wrote:

hi, it happens only with "[", that's why i'm puzzled.

it behaves as if you load a GRanges object 'x' and try to subset it

x[1]

without loading 'GenomicRanges' first.


Is there a reproducible example? I see in your code there are several places 
where you require() or library() various packages. I think one of these 
Depends: on GenomicRanges, and the messages you see are the effect of moving 
GenomicRanges from 'loaded' to 'attached'. You can see the effect with


  library(qpgraph)
  sessionInfo()   ## GenomicRanges loaded but not attached
  library(GenomicRanges)  ## information about the package being attached

Probably in your code you do not actually want to require() ad hoc packages and 
influence the user search path (and implicitly rely on search path order for 
correct functionality), but rather to requireNamespace("foo"); foo::fun(...) (or 
possibly loadNamespace()).


Complicated!

Martin



robert.

On 10/07/2014 05:05 PM, Michael Lawrence wrote:

Does that happen with the other methods or just "["? As a last resort,
you could just drop the import (because "[" is a primitive, it should
just work).

On Tue, Oct 7, 2014 at 3:08 AM, Robert Castelo mailto:robert.cast...@upf.edu>> wrote:

hi Martin,

On 10/06/2014 07:24 PM, Martin Morgan wrote:
[...]

There are two 'as.vector' generics, one defined in Matrix and one in
BiocGenerics (and made available via IRanges). These generics have
different methods

 > showMethods(Matrix::as.vector)
Function: as.vector (package base)
x="abIndex", mode="ANY"
x="abIndex", mode="character"
x="ANY", mode="ANY"
x="dgCMatrix", mode="missing"
x="dgeMatrix", mode="missing"
x="diagonalMatrix", mode="missing"
x="dsCMatrix", mode="missing"
x="ldenseMatrix", mode="missing"
x="Matrix", mode="missing"
x="ndenseMatrix", mode="missing"
x="sparseVector", mode="character"
x="sparseVector", mode="missing"

 > showMethods(BiocGenerics::as.__vector)
Function: as.vector (package BiocGenerics)
x="ANY"
x="AtomicList"
x="Rle"
x="XDouble"
x="XInteger"
x="XRaw"
x="XString"
x="XStringSet"

so it's important that your code clearly distinguish between
generics.
One possibility is to remove importMethodsFrom(IRanges,
as.vector) from
the NAMESPACE, and explicitly use IRanges::as.vector(...) in
your code.


ok, i've done this as it is the easiest at the moment to meet the
release schedule. i guess that in the future i should try to avoid
using the '::' operator by importing exclusively what is needed from
each package.

codetoolsBioC::__writeNamespaceImports("__qpgraph") might
provide you with
some guidance (it's not 100% reliable; available via svn at

https://hedgehog.fhcrc.org/__bioconductor/trunk/madman/__Rpacks/codetoolsBioC

)
about what functionality is being imported.


thanks for the heads up about codetoolsBioC, i've tried it out and
seen that some of the suggested imports are not necessary but some
others i was really missing them (which makes me wonder how was it
possible that he package did not break at those points).

one further question related to NAMESPACE. i subset GRanges objects
in the package via the '[' operator, i've included this into the
NAMESPACE file as:

importMethodsFrom(__GenomicRanges,
   c, cbind, rbind,
"mcols<-", start, end, strand, sort,
"[", "[<-", "[[", "[[<-", "$", "$<-")

however, when the package reaches a subset operation x[i] with x
being a GRanges object, an entire package loading sequence starts:

Loading required package: GenomicRanges
Loading required package: BiocGenerics
Loading required package: parallel

Attaching package: ‘BiocGenerics’
[... etc ...]

which may look a bit odd to the user. for every other imported
method the package uses them silently without loading the
corresponding package, am i importing '[' for GRanges objects from
the wrong package? is there a way to import '[' so that my package
can use it without triggering that package loading sequence?


thanks again!
robert.


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








--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

___
Bioc-devel@r-project.org mailin

Re: [Bioc-devel] NAMESPACE question

[Michael Lawrence]

On Tue, Oct 7, 2014 at 8:54 AM, Martin Morgan  wrote:

> On 10/07/2014 08:15 AM, Robert Castelo wrote:
>
>> hi, it happens only with "[", that's why i'm puzzled.
>>
>> it behaves as if you load a GRanges object 'x' and try to subset it
>>
>> x[1]
>>
>> without loading 'GenomicRanges' first.
>>
>
> Is there a reproducible example? I see in your code there are several
> places where you require() or library() various packages. I think one of
> these Depends: on GenomicRanges, and the messages you see are the effect of
> moving GenomicRanges from 'loaded' to 'attached'. You can see the effect
> with
>
>   library(qpgraph)
>   sessionInfo()   ## GenomicRanges loaded but not attached
>   library(GenomicRanges)  ## information about the package being attached
>
> Probably in your code you do not actually want to require() ad hoc
> packages and influence the user search path (and implicitly rely on search
> path order for correct functionality), but rather to
> requireNamespace("foo"); foo::fun(...) (or possibly loadNamespace()).
>

This last paragraph should probably be explained in the Bioc coding
standards if it is not already.


>
> Complicated!
>
> Martin
>
>
>
>> robert.
>>
>> On 10/07/2014 05:05 PM, Michael Lawrence wrote:
>>
>>> Does that happen with the other methods or just "["? As a last resort,
>>> you could just drop the import (because "[" is a primitive, it should
>>> just work).
>>>
>>> On Tue, Oct 7, 2014 at 3:08 AM, Robert Castelo >> > wrote:
>>>
>>> hi Martin,
>>>
>>> On 10/06/2014 07:24 PM, Martin Morgan wrote:
>>> [...]
>>>
>>> There are two 'as.vector' generics, one defined in Matrix and
>>> one in
>>> BiocGenerics (and made available via IRanges). These generics
>>> have
>>> different methods
>>>
>>>  > showMethods(Matrix::as.vector)
>>> Function: as.vector (package base)
>>> x="abIndex", mode="ANY"
>>> x="abIndex", mode="character"
>>> x="ANY", mode="ANY"
>>> x="dgCMatrix", mode="missing"
>>> x="dgeMatrix", mode="missing"
>>> x="diagonalMatrix", mode="missing"
>>> x="dsCMatrix", mode="missing"
>>> x="ldenseMatrix", mode="missing"
>>> x="Matrix", mode="missing"
>>> x="ndenseMatrix", mode="missing"
>>> x="sparseVector", mode="character"
>>> x="sparseVector", mode="missing"
>>>
>>>  > showMethods(BiocGenerics::as.__vector)
>>> Function: as.vector (package BiocGenerics)
>>> x="ANY"
>>> x="AtomicList"
>>> x="Rle"
>>> x="XDouble"
>>> x="XInteger"
>>> x="XRaw"
>>> x="XString"
>>> x="XStringSet"
>>>
>>> so it's important that your code clearly distinguish between
>>> generics.
>>> One possibility is to remove importMethodsFrom(IRanges,
>>> as.vector) from
>>> the NAMESPACE, and explicitly use IRanges::as.vector(...) in
>>> your code.
>>>
>>>
>>> ok, i've done this as it is the easiest at the moment to meet the
>>> release schedule. i guess that in the future i should try to avoid
>>> using the '::' operator by importing exclusively what is needed from
>>> each package.
>>>
>>> codetoolsBioC::__writeNamespaceImports("__qpgraph") might
>>> provide you with
>>> some guidance (it's not 100% reliable; available via svn at
>>>
>>> https://hedgehog.fhcrc.org/__bioconductor/trunk/madman/__
>>> Rpacks/codetoolsBioC
>>>
>>> >> Rpacks/codetoolsBioC>)
>>> about what functionality is being imported.
>>>
>>>
>>> thanks for the heads up about codetoolsBioC, i've tried it out and
>>> seen that some of the suggested imports are not necessary but some
>>> others i was really missing them (which makes me wonder how was it
>>> possible that he package did not break at those points).
>>>
>>> one further question related to NAMESPACE. i subset GRanges objects
>>> in the package via the '[' operator, i've included this into the
>>> NAMESPACE file as:
>>>
>>> importMethodsFrom(__GenomicRanges,
>>>c, cbind, rbind,
>>> "mcols<-", start, end, strand, sort,
>>> "[", "[<-", "[[", "[[<-", "$", "$<-")
>>>
>>> however, when the package reaches a subset operation x[i] with x
>>> being a GRanges object, an entire package loading sequence starts:
>>>
>>> Loading required package: GenomicRanges
>>> Loading required package: BiocGenerics
>>> Loading required package: parallel
>>>
>>> Attaching package: ‘BiocGenerics’
>>> [... etc ...]
>>>
>>> which may look a bit odd to the user. for every other imported
>>> method the package uses them silently without loading the
>>> corresponding package, am i importing '[' for GRanges objects from
>>> the wrong package? is there a way to import '[' so that my package
>>> can 

Re: [Bioc-devel] RMarkdown for vignettes (builder issues)

[Dan Tenenbaum]

This is fixed now.

http://bioconductor.org/spb_reports/STATegRa_0.99.4_buildreport_20141007100210.html

Dan


- Original Message -
> From: "Gordon Ball" 
> To: "Andrzej Oleś" , "Dan Tenenbaum" 
> 
> Cc: jmac...@u.washington.edu, bioc-devel@r-project.org, "david Gomez-Cabrero" 
> 
> Sent: Tuesday, October 7, 2014 3:53:40 AM
> Subject: Re: [Bioc-devel] RMarkdown for vignettes (builder issues)
> 
> Sorry to re-open this thread, but it appears that this configuration
> works with some builders but not others. There appear to be two
> different failure modes:
> 
> Works with: oaxaca, perceval (OSX 10.6, 10.9)
> 
> Fails with: moscato1 (windows 2008)
> 
> InvalidUrlException
> "D:%5Cpackagebuilder%5Cjobs%5CSTATegRa_20141007024617%5CR-libs%5CBiocStyle%5Cresources%5Chtml%5Cbioconductor.css"
> "Invalid scheme"
> 
> This appears to be an error in specific pandoc versions where it
> interprets a windows drive letter as a URL scheme - see
> https://github.com/jgm/pandoc/issues/1558
> 
> Fails with: zin1 (linux ubuntu 12.04)
> 
> pandoc: Error running filter pandoc-citeproc
> pandoc-citeproc not found in path
> 
> The filter for processing references doesn't seem to be available. In
> 14.04 this is the package `pandoc-citeproc`, but it doesn't appear to
> be
> available for 12.04. I assume this is only an issue if the Rmd
> document
> includes a `bibliography:` field in the header.
> 
> 
> 
> Are these issues likely to be addressable for this release? If not,
> can
> we get away with shipping a static vignette to avoid these problems?
> 
> (The build log in question is
> http://bioconductor.org/spb_reports/STATegRa_0.99.3_buildreport_20141007025338.html
> )
> 
> Thanks
> 
> Gordon Ball
> 
> 
> On 04/10/14 00:02, Andrzej Oleś wrote:
> > Hi Gordon, James,
> > 
> > thank you for pointing this out! At the time BiocStyle for markdown
> > documents was developed 'rmarkdown' was not yet on CRAN and
> > couldn't
> > be used as a vignette builder engine.
> > As things changed in the meantime, the approach described by Gordon
> > should be just fine. I will update the BiocStyle vignette
> > accordingly.
> > 
> > Best,
> > Andrzej
> > 
> > On Fri, Oct 3, 2014 at 4:51 PM, Dan Tenenbaum 
> > wrote:
> >>
> >>
> >> - Original Message -
> >>> From: "Henrik Bengtsson" 
> >>> To: jmac...@u.washington.edu
> >>> Cc: bioc-devel@r-project.org
> >>> Sent: Friday, October 3, 2014 6:56:59 AM
> >>> Subject: Re: [Bioc-devel] RMarkdown for vignettes
> >>>
> >>> I think it requires Bioc core to make a statement that pandoc
> >>> will be
> >>> added
> >>> to the list of external software that can be assume to exist on
> >>> the
> >>> servers.
> >>
> >>
> >> Pandoc is installed on the build servers. Several packages use it.
> >>
> >>>
> >>> If it is also expected that users should be able to rebuild all
> >>> vignettes/documents themselves, then that assumption has to be
> >>> extended to
> >>> the users as well. BTW, is there such an assumption on
> >>> LaTeX-dependent
> >>> packages today?
> >>>
> >>
> >> Users only need LaTeX (or pandoc) if they are going to build
> >> package vignettes from svn. Source packages (as well as binary
> >> packages of course) already contain built vignettes.
> >>
> >> Dan
> >>
> >>
> >>> Installing pandoc is not that hard and lightweight (much smaller
> >>> than
> >>> LaTeX), but it does add one more installation. On the other hand,
> >>> it
> >>> opens
> >>> up for doing lots of other neat things.
> >>>
> >>> Henrik
> >>> On Oct 3, 2014 6:40 AM, "James W. MacDonald" 
> >>> wrote:
> >>>
>  Hi Gordon,
> 
>  Sean Davis has something about this on his blog:
> 
> 
>  http://watson.nci.nih.gov/~sdavis/blog/convert_from_sweave_to_r_markdown_vignettes/
> 
>  Best,
> 
>  Jim
> 
> 
> 
>  On Fri, Oct 3, 2014 at 9:06 AM, Gordon Ball 
>  wrote:
> 
> > Hello
> >
> > Is it possible to use (RStudio's) rmarkdown package as a
> > vignette
> > builder for the upcoming release?
> >
> > ie, with the (at least locally working) configuration
> >
> > DESCRIPTION
> >
> > Suggests: knitr, rmarkdown, BiocStyle
> > VignetteBuilder: knitr
> >
> > vignette/vignette.Rmd
> >
> > ---
> > title: ...
> > output: BiocStyle::html_document
> > vignette: >
> > %% \VignetteEngine{knitr::rmarkdown}
> > %% \VignetteIndexEntry{...}
> > 
> >
> > I couldn't find any explicit reference to markdown vs rmarkdown
> > in the
> > package guidelines. The documentation for [BiocStyle] indicates
> > that it
> > isn't possible to build package vignettes with the newer
> > rmarkdown - is
> > that still correct?
> >
> > I note that the newer [rmarkdown] is now in CRAN, so presumably
> > can be
> > used by the builders - but do they have the non-R dependency
> > (pandoc)
> > available?
> >

[Bioc-devel] S4Vectors unit tests

[Michael Lawrence]

Looks like we still have to move over the DataFrame, etc tests from IRanges?

Michael

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] S4Vectors unit tests

[Hervé Pagès]

On 10/07/2014 10:35 AM, Michael Lawrence wrote:

Looks like we still have to move over the DataFrame, etc tests from IRanges?


Yes this and other leftovers.

H.



Michael

[[alternative HTML version deleted]]

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



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fhcrc.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

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

Re: [Bioc-devel] droplevels method for DataFrame?

[Michael Lawrence]

Cool. We should consider moving some of the infrastructure pieces to the
github bridge.

I added a droplevels method for List that should take care of things.

On Mon, Oct 6, 2014 at 6:11 PM, Ryan C. Thompson 
wrote:

> Hi,
>
> Yes, if something is on Github (or just any git/hg repo that I can clone)
> then I'm much more likely to try to fix simple bugs that I discover and
> submit patches or pull requests rather than report them as bugs. It doesn't
> hurt that Github provides tools to submit pull requests from the terminal.
> I've never learned cvs or svn because I mostly haven't had the need in the
> past (haven't been working on projects that use cvs/svn).
>
> So in my case, yes, if S4Vectors was on Github I probably would have
> cloned it and tried to fix it before reporting the issue here, and I would
> have either reported it with a patch or explained what I tried and where I
> got stuck.
>
> -Ryan
>
> On Mon 06 Oct 2014 05:55:02 PM PDT, Michael Lawrence wrote:
>
>> Makes sense to me. Just wondering: if S4Vectors were say on github,
>> would this be something that you would be comfortable resolving via a
>> pull request? Would social coding increase external contributions to
>> the infrastructure?
>>
>> On Mon, Oct 6, 2014 at 5:13 PM, Ryan C. Thompson > > wrote:
>>
>> Hi,
>>
>> I've just noticed that DataFrame doesn't have a "droplevels"
>> method, but "data.frame" does. In fact, "droplevels.data.frame"
>> seems to work just fine on DataFrame objects. Could this be added?
>>
>> -Ryan
>>
>>
>> > sessionInfo()
>> R version 3.1.0 (2014-04-10)
>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>
>> locale:
>>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] splines   grDevices datasets  parallel  graphics  stats utils
>> [8] methods   base
>>
>> other attached packages:
>>  [1] DESeq2_1.4.5   RcppArmadillo_0.4.450.1.0
>>  [3] Rcpp_0.11.2cqn_1.10.0
>>  [5] quantreg_5.05  SparseM_1.05
>>  [7] preprocessCore_1.26.1  nor1mix_1.2-0
>>  [9] mclust_4.4 baySeq_1.18.0
>> [11] DESeq_1.16.0   lattice_0.20-29
>> [13] locfit_1.5-9.1 edgeR_3.6.8
>> [15] limma_3.20.9   arrayQualityMetrics_3.20.0
>> [17] partitions_1.9-15  biomaRt_2.20.0
>> [19] functional_0.6 sqldf_0.4-7.1
>> [21] RSQLite.extfuns_0.0.1  RSQLite_0.11.4
>> [23] DBI_0.3.1  gsubfn_0.6-6
>> [25] proto_0.3-10   GenomicFeatures_1.16.2
>> [27] AnnotationDbi_1.26.0   chipseq_1.14.0
>> [29] inline_0.3.13  affy_1.42.3
>> [31] Biobase_2.24.0 ShortRead_1.22.0
>> [33] GenomicAlignments_1.0.6BSgenome_1.32.0
>> [35] BiocParallel_0.6.1 Rsamtools_1.16.1
>> [37] Biostrings_2.32.1  XVector_0.4.0
>> [39] doParallel_1.0.8   iterators_1.0.7
>> [41] rtracklayer_1.24.2 GenomicRanges_1.16.4
>> [43] GenomeInfoDb_1.0.2 Matrix_1.1-4
>> [45] RColorBrewer_1.0-5 foreach_1.4.2
>> [47] plyr_1.8.1 stringr_0.6.2
>> [49] ggplot2_1.0.0  IRanges_1.22.10
>> [51] BiocGenerics_0.10.0BiocInstaller_1.14.2
>>
>> loaded via a namespace (and not attached):
>>  [1] acepack_1.3-3.3  affyio_1.32.0affyPLM_1.40.1
>>  [4] annotate_1.42.1  base64_1.2   base64enc_0.1-2
>>  [7] BatchJobs_1.4BBmisc_1.7   beadarray_2.14.1
>> [10] BeadDataPackR_1.16.0 bitops_1.0-6 brew_1.0-6
>> [13] Cairo_1.5-6  checkmate_1.4chron_2.3-45
>> [16] cluster_1.15.3   codetools_0.2-9  colorspace_1.2-4
>> [19] compiler_3.1.0   digest_0.6.4 fail_1.2
>> [22] foreign_0.8-61   Formula_1.1-2gcrma_2.36.0
>> [25] genefilter_1.46.1geneplotter_1.42.0   gmp_0.5-12
>> [28] grid_3.1.0   gridSVG_1.4-0gtable_0.1.2
>> [31] Hmisc_3.14-5 hwriter_1.3.2illuminaio_0.6.1
>> [34] latticeExtra_0.6-26  MASS_7.3-34  munsell_0.4.2
>> [37] nnet_7.3-8   polynom_1.3-8RCurl_1.96-0
>> [40] reshape2_1.4 RJSONIO_1.2-0.2  rpart_4.1-8
>> [43] scales_0.2.4 sendmailR_1.2-1  setRNG_2013.9-1
>> [46] stats4_3.1.0 survival_2.37-7  SVGAnnotation_0.93-1
>> [49] tools_3.1.0  vsn_3.32.0   XML_3.98-1.1
>> [52] xtable_1.7-4 zlibbioc_1.10.0
>>
>> _
>> Bioc-devel@r-project.org 

[Bioc-devel] Request for Comments on The NIH Software Discovery Index--a system for linking software, publications and users in the research community

[Sean Davis]

On behalf of a number of software developers, end-users, publishers
associated with the scientific analysis community, we would like to invite
all of you to review a document generated as a result of a NIH BD2K
supported meeting that focused on the opportunities and challenges of
developing a software management ecosystem that could be valuable for
finding and linking software, publications and users in the research
community. You may be also be aware of a related project, the Data
Discovery Index, which will be fully integrated with the software system.
The product of this workshop and the subsequent discussion is a document
which details the opportunities and challenges of developing a Software
Discovery Index that would enable researchers to find, cite, and link
software and analysis tools publications and researchers. To ensure that
the opportunities, challenges, and recommendations detailed in the document
reflect the breadth of experience from the community, we are seeking your
input.  In conjunction with related efforts already under way at NIH,
including the development of a Data Discovery Index, the final document
will be used by the NIH Office of the Associate Director (ADDS) to inform a
strategy for the development of a Software Discovery Index and a commons
ecosystem for data, software, and resources.
We need your help to ensure that this critical task is achieved: to guide
the development of a community based system that gives credit and
acknowledgment to the builder and maintainers of the software we all depend
on! We invite all users, software developers, publishers, and software
repository administrators to review our report prior to its submission to
the NIH. Please complete your review and post comments by November 1,
2014. The link to the report is here: http://softwarediscoveryindex.org

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] NAMESPACE question

[Martin Morgan]

On 10/07/2014 09:15 AM, Michael Lawrence wrote:


Probably in your code you do not actually want to require() ad hoc packages
and influence the user search path (and implicitly rely on search path order
for correct functionality), but rather to requireNamespace("foo");
foo::fun(...) (or possibly loadNamespace()).


This last paragraph should probably be explained in the Bioc coding standards if
it is not already.


Thanks for the prompt, it's now mentioned on the coding style and package 
guidelines.


  http://bioconductor.org/developers/package-guidelines/#dependencies
  http://bioconductor.org/developers/how-to/coding-style/

Martin

--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

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

Re: [Bioc-devel] NAMESPACE question

[Dario Strbenac]

The guidelines state :

Depends: is appropriate when a package is used in the example section of a man 
page.

I think such packages should be in Suggests. In the example, the package should 
be loaded by :

if(require(examplePackage))
{
  exampleFunction(data)
}

--
Dario Strbenac
PhD Student
University of Sydney
Camperdown NSW 2050
Australia
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] NAMESPACE question

[Michael Lawrence]

I think the intent there is that if you virtually always need a package to
generate the input or analyze the output of a documented function, it
should be in Depends. If it's a package that is only useful for
demonstration, it should be in Suggests, and one should abide by the same
guidelines (requireNamespace, etc) as Martin contributed.

On Tue, Oct 7, 2014 at 6:00 PM, Dario Strbenac 
wrote:

> The guidelines state :
>
> Depends: is appropriate when a package is used in the example section of a
> man page.
>
> I think such packages should be in Suggests. In the example, the package
> should be loaded by :
>
> if(require(examplePackage))
> {
>   exampleFunction(data)
> }
>
> --
> Dario Strbenac
> PhD Student
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> 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

Re: [Bioc-devel] NAMESPACE question

[Martin Morgan]

On 10/07/2014 07:05 PM, Michael Lawrence wrote:

I think the intent there is that if you virtually always need a package to
generate the input or analyze the output of a documented function, it
should be in Depends. If it's a package that is only useful for
demonstration, it should be in Suggests, and one should abide by the same
guidelines (requireNamespace, etc) as Martin contributed.


I adjusted the wording a bit. I was also quite disturbed to find how similar my 
Suggests illustration is to the advice in Writing R Extensions, 
RShowDoc('R-exts'), section 1.1.3.1.


Martin



On Tue, Oct 7, 2014 at 6:00 PM, Dario Strbenac 
wrote:


The guidelines state :

Depends: is appropriate when a package is used in the example section of a
man page.

I think such packages should be in Suggests. In the example, the package
should be loaded by :

if(require(examplePackage))
{
   exampleFunction(data)
}

--
Dario Strbenac
PhD Student
University of Sydney
Camperdown NSW 2050
Australia
___
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




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

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