Re: [Bioc-devel] how can I declare that a package doesn't/can't fully support Windows

[Morgan, Martin]

There is .BBSoptions, which can be placed in the root of your package, 
but this is insidious, as evidenced by your own use case -- gmapR 
doesn't support windows, so your package doesn't support windows, so any 
package that Depends: or Imports: your package doesn't support windows, 
so actually 1/2 of our users can't reliably use packages we provide.


I would argue for a much more carefully defined package with specific, 
cross-platform functionality. This will be easier to maintain AND more 
useful. Generally, I think we are really seeing an explosion of 
dependencies, and that this is very bad for long-term utility of 
contributed packages -- the maintainer will either spend all their time 
responding to changes in dozens of dependent packages rather than 
innovating in new areas, or will give up and leave the users with 
software that no longer works.


Martin

On 10/10/18 10:46 AM, Tim Triche, Jr. wrote:

it looks like gmapR does not support Windows, and as a result, my MTseeker
package cannot build on tokay1, so the Data package which requires it also
cannot build on tokay1.  Are there platform-specific dontrun capabilities?

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

Short of somehow forcing gmapR to build on Windows, which I believe is
beyond my control, is there a way to declare that parts of the MTseeker
package are unsupported/unsupportable on Windows?

I suppose I could cleave off the variant-recalling portions but that seems
a little ridiculous. The original goal was to take the non-NuMT reads from
a given alignment, realign (only) those to rCRS/RSRS, and call against
that, for better mitochondrial haplogroup inference. We're still working
towards the full version, but even just calling variants against rCRS with
indels is hugely useful, and the ability to screen out haplogroup-specific
variants while retaining indels, SNVs, etc. turns out to be VERY handy.
More generally, there isn't any equivalent (AFAIK) in BioC, at all.

--t

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

Re: [Bioc-devel] Files in the 'vignettes' directory but no files in 'inst/doc'

[Morgan, Martin]

Just to emphasize that the 'right' solution from the Bioc perspective is 
to make sure that the vignette is evaluated


  https://stackoverflow.com/a/44094582/547331

rather than to add a pdf to inst/doc -- no sense in providing the user 
with a 'picture of code' when there are no guarantees that the picture 
actually works in the current release.


Martin

On 10/10/18 5:28 PM, Bohdan Khomtchouk wrote:

Hi --

I recently diagnosed a WARNING that kept popping up in my package's build
by following the advice of: https://stackoverflow.com/a/42673584/3878253

Since I wasn't the only one who benefited from this answer, I thought I'd
share with the broader Bioconductor community my experience with it (to
raise awareness of the issue).  Perhaps some changes are needed in the
build system to avoid this issue moving forward.

All the best,
Bohdan



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

Re: [Bioc-devel] Why bioconductor?

[Morgan, Martin]

I think pull requests on


https://github.com/Bioconductor/bioconductor.org/blob/master/content/developers/package-submission.md

would be welcome.

Martin

On 10/10/18 11:51 AM, Ludwig Geistlinger wrote:

While this might be obvious to most of us, it seems to be less clear to others.

In particular, those who worked out their first package and wonder what's the 
difference between having a package available on Github, CRAN, or Bioconductor.


I wonder whether it would be helpful for the Bioc webpage to pick up on the 
benefits of submitting to CRAN by Hadley


http://r-pkgs.had.co.nz/release.html


and several considerations with respect to Bioconductor


https://bioinformatics.stackexchange.com/questions/639/why-bioconductor


(Maybe FAQ?)


  Just a thought.


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

Re: [Bioc-devel] Custom build of packages

[Morgan, Martin]

I guess asking on the devel mailing list rather than sending mail to a 
particular individual means that you get the benefit of whatever global wisdom 
is available.

All packages are built nightly, in both release and devel, and across three 
architectures. The build system is more complicated than building individual 
packages -- reverse dependencies need to be built, too, and successful builds 
synchronized with public repositories -- so the nightly builds will not change 
in the near future.

The problem is likely that your local configuration is using the current 
version of R and Bioconductor, whereas as a developer you should be using the 
version of R and Bioconductor used in the 'devel' branch. The version of R in 
use on the build machines is given at the top of the build page

  http://bioconductor.org/checkResults/3.3/bioc-LATEST/index.html

so R-3.3.0-beta, available from cran.r-project.org. Once you have the correct 
version of R installed, then

 source("https://bioconductor.org/biocLite.R;)
 BiocInstaller::useDevel()

sets you up to install bioc devel packages (the second step is not always 
necessary, depending on the version of R and Bioconductor; it is not necessary 
in the current 'devel', so the error -- 'devel' version already in use -- can 
be ignored). See a variant of these instructions at 
http://bioconductor.org/developers/how-to/useDevel/. The specific commands used 
for building are given in each section of the build report, so the specific 
build command (editing paths, of course) can also be invoked.

I guess you are talking about MultiDataSet, with the build report at

  
http://bioconductor.org/checkResults/3.3/bioc-LATEST/MultiDataSet/zin2-buildsrc.html

The error
  
** R
** preparing package for lazy loading
Error : object ‘rowRanges’ is not exported by 'namespace:GenomicRanges'
ERROR: lazy loading failed for package ‘MultiDataSet’
* removing ‘/tmp/RtmpzWv6vq/Rinst36c3606d6b5a/MultiDataSet’

is because in bioc devel rowRanges is now in the SummarizedExperiment package. 
I see from SVN that you have discovered this, too.

The warning

* installing *source* package 'MultiDataSet' ...
Warning in .write_description(db, file.path(outDir, "DESCRIPTION")) :
  Unknown encoding with non-ASCII data: converting to ASCII

is probably complaining that the DESCRIPTION file does not declare a particular 
encoding (so defaults to ASCII) but contains non-ASCII characters. These can be 
spotted with

> tools::showNonASCIIfile("DESCRIPTION")
8:   person("Juan R.", "Gonzlez", ,"jrgonza...@creal.cat", role = 
"aut"))

and you could either forgo the accents or declare the encoding, probably by 
adding the tag

Encoding: UTF-8

to the DESCRIPTION file.

People will also point to travis for use with github, but for me this 
introduces two tools that play only sort-of ok with the Bioconductor build 
infrastructure (trying to bridge git via github with svn in particular seems to 
cause problems that can be very tedious and time consuming to solve).

Martin

From: Bioc-devel  on behalf of Ruiz Arenas, 
Carlos 
Sent: Friday, April 22, 2016 6:06 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Custom build of packages

Hi Bioconductor community,

I am a recent Bioc developer. I uploaded a package just before the deadline of 
this BioC 3.3. During the admission process, the build machine was run with my 
packages almost every two hours which allowed me to improve the package more 
efficiently. However, now that I am in the devel trunk, the build machine is 
only run nightly. I am experiencing some problems due to some changes and I 
have to wait until the following day to check that the changes had worked. One 
of the people of Bioc tried to help me running the machine with my package. 
However, he is in Seatle while I am in Barcelona, so when I receive the mail he 
is not working anymore and the other way round.

I am wondering if it could be possible for developers to generate a build 
report for our package. Otherwise, I think it could be interesting that the 
build machine was run more often during the last days of Bioc release, at least 
for packages with changes.

Are any of these options feasible?

Thanks,

Carlos Ruiz

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

Re: [Bioc-devel] Package reference manuals in html

[Morgan, Martin]

One thing about accessing the html versions locally (e.g., via ? with 
options(help_type="html")] or help.start() or Rstudio) is that you get the 
version relevant to your R / Bioconductor, rather than whatever is at the top 
of google; I guess the same applies to the pdf versions, and the reason that 
there isn't more current confusion is because the online pdf versions are not 
as useful as the off-line help system.

I think Laurent was interested in an integration of help pages across packages 
(which is the appeal of rdocumentation.org?), not just rendering the help pages 
in html rather than pdf? An integration of help pages would definitely be a big 
job with substantial development and maintenance; we will not be undertaking 
this ourselves.

For the more limited case of adding a (directory of) html files for the the 
manual, it's not impossible that we could find the resources to do this in the 
next 6 months.

One intermediate and helpful step for those willing to help would be to develop 
the code to process help pages into a style consistent with the bioconductor 
web site. One place where this could be implemented would be the BiocStyle 
package (https://github.com/Bioconductor-mirror/BiocStyle but hmm, seems like 
there's a slightly out of sync version at 
https://github.com/Bioconductor/BiocStyle that would be more convenient...). 
Perhaps this really means only developing a css style sheet and R's 
tools::Rd2HTML() (I'm very reluctant to introduce dependencies into the build 
system, and am very conservative about inclusion of fancy features in the html 
-- these become significant maintenance burdens moving forward).

The web site is generated by https://github.com/Bioconductor/bioconductor.org, 
with the style sheet at 
https://github.com/Bioconductor/bioconductor.org/blob/master/assets/style/bioconductor.css.
 The package landing pages are templated using 
layouts/_bioc_views_package_detail.html. The idea would be to end up with 
layouts/_bioc_man_index.html and _bioc_man_body.html that wrapped output from 
BiocStyle in the overall bioc page.

The implementation suggestions above are just a sketch and could be quite 
misguided. If there's interest then probably we should set up a hangout to 
discuss in a little more detail.

Martin


From: Bioc-devel  on behalf of Hartley, 
Stephen (NIH/NHGRI) [F] 
Sent: Wednesday, March 2, 2016 11:46 AM
To: Laurent Gatto; bioc-devel
Subject: Re: [Bioc-devel] Package reference manuals in html

I'd like to second this. Currently Bioconductor hosts the pdf reference 
manuals, but those are often sub-ideal. The page breaks make it harder to read, 
the fixed width basically makes it either too small or too big depending on 
your display, you can't navigate cross-package links, and in general using 
paper-formatted software documentation is just poor form.

Yihui, the creator of knitr, has a blog post where he shows how to do this. 
There are a lot of ways to do this, and it's generally pretty straightforward.
http://yihui.name/en/2012/10/build-static-html-help/

You can also use a function in knitr, knit_rd(), which builds the examples as 
well and inserts the output right onto the page. That's what I used to make the 
docs for QoRTs (http://hartleys.github.io/QoRTs/Rhtml/index.html) and 
JunctionSeq (http://hartleys.github.io/JunctionSeq/Rhtml/index.html).

Or you can use the staticdocs package, which does the same basic thing but 
prettier (see ggplot2's docs: http://docs.ggplot2.org/current/)

The nuclear option, of course, is to do what CRAN does and rebuild R on (one 
of) the servers using the --enable-prebuilt-html configure option. That might 
affect other things, though, and might not be ideal.

Does any of this seem like a viable option for Bioconductor? I think it could 
be an incredibly valuable resource for the community. Are there any technical 
issues that haven't been considered in the above?

Regards,
Steve Hartley

-Original Message-
From: Laurent Gatto [mailto:lg...@cam.ac.uk]
Sent: Tuesday, March 01, 2016 6:42 AM
To: bioc-devel
Subject: [Bioc-devel] Package reference manuals in html


Dear all,

I find the http://www.rdocumentation.org/ site very useful to refer to nicely 
formatted online man pages individually. Unfortunately, this resource is 
terribly outdated and not maintained anymore.

I was wondering if Bioconductor had any interest in serving an html version of 
individual reference manuals in addition to the pdf that are already available 
on the package landing pages.

Is there anything I or any other members of the community could help with to 
get this up and running?

Best wishes,

Laurent

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

___
Bioc-devel@r-project.org mailing list

Re: [Bioc-devel] Imports, depends and warnings

[Morgan, Martin]

Your description is not clear enough. See the github repository branch

https://github.com/mtmorgan/PkgA/tree/import-conflict

which imports NMF and ggplot2 without any warning during

R CMD build PkgA
R CMD check PkgA_0.0.1.tar.gz

with

$ R --version|head -n3
R Under development (unstable) (2016-02-27 r70232) -- "Unsuffered Consequences"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)



From: Federico Marini <mari...@uni-mainz.de>
Sent: Thursday, March 3, 2016 3:44 AM
To: Morgan, Martin; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Imports, depends and warnings

With the minimal working example, alone the importing of NMF raises the
warning, so I guess this is due to that particular package.

Should I contact the author of that in hope he adapts its NAMESPACE to
have some nicer behavior? (or would be *just that* warning "fine" for
the Bioc ecosystem?)


Cheers,
Federico


On 02.03.16 20:41, Morgan, Martin wrote:
> I think the only unavoidable case is when the package you import 'does it 
> wrong'. If that's not the case, then please provide an (easy-to-reproduce -- 
> start with a simple package.skeleton() and add a couple of Imports: and 
> import() statements, rather than providing your current package).
>
> Martin
>
> 
> From: Bioc-devel <bioc-devel-boun...@r-project.org> on behalf of Federico 
> Marini <mari...@uni-mainz.de>
> Sent: Wednesday, March 2, 2016 10:53 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] Imports, depends and warnings
>
> Hi Bioconductors,
>
> I'm on a good way to finalize the pcaExplorer package I presented at the
> recent Bioc Developers Meeting.
>
> Trying to keep check and BiocCheck always in the background of my head,
> as well as trying to be a good 'package neighbour', I am dealing with
> the issue of some "Warning: replacing previous import by..." messages,
> when building/loading/checking.
>
>   From my understanding, there might be some cases where this can not be
> fixed, probably because an imported package in turn imports itself
> another one entirely, making my own import redundant (e.g., ggplot2 for
> plotting and NMF for aheatmap give this part:
>
> Warnung: replacing previous import by ‘ggplot2::unit’ when loading ‘NMF’
> Warnung: replacing previous import by ‘ggplot2::arrow’ when loading ‘NMF’
>
> This happens even if I specifically just use importFrom in the NAMESPACE.
>
> I'm kind of puzzled on this, so I thought I'd better ask out for some
> expert advice on the ML. If required, I could put the package in a
> GitHub repository.
>
> Thank you in advance for any help you can provide!
>
> Federico
>
> --
> Federico Marini, M.Sc.
> Institute of Medical Biostatistics, Epidemiology and Informatics (IMBEI)
> Division Biostatistics and Bioinformatics
> University Medical Center of the Johannes Gutenberg University Mainz
> Postal address: 55101 Mainz
> Office and delivery address: Obere Zahlbacher Str. 69, 55131 Mainz
>
> Phone: +49 (0) 6131 17-8108
> Fax: +49 (0) 6131 17-2968
> Web: www.imbei.uni-mainz.de
> E-Mail: mari...@uni-mainz.de
>
> ___
> 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.

--
Federico Marini, M.Sc.
Institute of Medical Biostatistics, Epidemiology and Informatics (IMBEI)
Division Biostatistics and Bioinformatics
University Medical Center of the Johannes Gutenberg University Mainz
Postal address: 55101 Mainz
Office and delivery address: Obere Zahlbacher Str. 69, 55131 Mainz

Phone: +49 (0) 6131 17-8108
Fax: +49 (0) 6131 17-2968
Web: www.imbei.uni-mainz.de
E-Mail: mari...@uni-mainz.de


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

Re: [Bioc-devel] Imports, depends and warnings

[Morgan, Martin]

I think the only unavoidable case is when the package you import 'does it 
wrong'. If that's not the case, then please provide an (easy-to-reproduce -- 
start with a simple package.skeleton() and add a couple of Imports: and 
import() statements, rather than providing your current package).

Martin


From: Bioc-devel  on behalf of Federico 
Marini 
Sent: Wednesday, March 2, 2016 10:53 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Imports, depends and warnings

Hi Bioconductors,

I'm on a good way to finalize the pcaExplorer package I presented at the
recent Bioc Developers Meeting.

Trying to keep check and BiocCheck always in the background of my head,
as well as trying to be a good 'package neighbour', I am dealing with
the issue of some "Warning: replacing previous import by..." messages,
when building/loading/checking.

 From my understanding, there might be some cases where this can not be
fixed, probably because an imported package in turn imports itself
another one entirely, making my own import redundant (e.g., ggplot2 for
plotting and NMF for aheatmap give this part:

Warnung: replacing previous import by ‘ggplot2::unit’ when loading ‘NMF’
Warnung: replacing previous import by ‘ggplot2::arrow’ when loading ‘NMF’

This happens even if I specifically just use importFrom in the NAMESPACE.

I'm kind of puzzled on this, so I thought I'd better ask out for some
expert advice on the ML. If required, I could put the package in a
GitHub repository.

Thank you in advance for any help you can provide!

Federico

--
Federico Marini, M.Sc.
Institute of Medical Biostatistics, Epidemiology and Informatics (IMBEI)
Division Biostatistics and Bioinformatics
University Medical Center of the Johannes Gutenberg University Mainz
Postal address: 55101 Mainz
Office and delivery address: Obere Zahlbacher Str. 69, 55131 Mainz

Phone: +49 (0) 6131 17-8108
Fax: +49 (0) 6131 17-2968
Web: www.imbei.uni-mainz.de
E-Mail: mari...@uni-mainz.de

___
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] Deadline for new package submissions for this release

[Morgan, Martin]

Bioc developers!

This is a reminder that, according to the release schedule

  http://bioconductor.org/developers/release-schedule/

new packages need to be submitted by March 25 in order to be previewed and made 
available in the next release, scheduled for April 15.

Package and submission guidelines are available

  http://bioconductor.org/developers/package-guidelines/
  http://bioconductor.org/developers/package-submission/

Remember that an Updated Bioconductor Package Submission Policy will take 
effect after the next release; look for additional detail shortly.

  https://support.bioconductor.org/p/76472/

Martin Morgan
Bioconductor

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] bnlearn method / generic definition (was Re: R CMD check problems)

[Morgan, Martin]

This reproduces the problem

> loadNamespace('graph')

> loadNamespace('bnlearn')
Error: .onLoad failed in loadNamespace() for 'bnlearn', details:
  call: setMethod("nodes", cl, function(object) .nodes(object))
  error: no existing definition for function 'nodes'


and it's because of the way bnlearn loads itself


  if ("graph" %!in% loadedNamespaces()) {

setGeneric("nodes", function(object, ...) standardGeneric("nodes"))
setGeneric("nodes<-", function(object, value) standardGeneric("nodes<-"))
setGeneric("degree", function(object, Nodes, ...) standardGeneric("degree"))

  }#THEN

  # add the methods.
  for (cl in bnlearn.classes) {

setMethod("nodes", cl, function(object) .nodes(object))
setMethod("nodes<-", cl, function(object, value) .relabel(object, value))
setMethod("degree", cl, function(object, Nodes) .degree(object, Nodes))

  }#FOR

graph is loaded but not attached, so the generic that it defines is not visible 
to bnlearn.

I'm ccing the bnlearn maintainer


From: Bioc-devel  on behalf of Vincent Carey 

Sent: Thursday, February 25, 2016 10:23 AM
To: Luca De Sano; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] R CMD check problems

I am evidently not expert in this topic.  However I was able to get past
the warning/halt you identified by moving the importFrom(bnlearn,...)
statements to the top of the NAMESPACE.  I cannot see in the WRE manual how
the order of namespace imports/exports should be controlled.  Other minds
will be needed to set this straight.

On Thu, Feb 25, 2016 at 6:06 AM, Luca De Sano 
wrote:

> This is my sessionInfo(), I've the current stable release of bnlearn (3.9).
>
> > sessionInfo()
> R version 3.2.3 (2015-12-10)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.3 LTS
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=it_IT.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=it_IT.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=it_IT.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=it_IT.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] parallel  stats graphics  grDevices utils datasets  methods
> [8] base
>
> other attached packages:
> [1] TRONCO_2.4.0  bnlearn_3.9   doParallel_1.0.10 iterators_1.0.8
> [5] foreach_1.4.3 devtools_1.10.0
>
> loaded via a namespace (and not attached):
>  [1] igraph_1.0.1graph_1.44.1Rcpp_0.12.3
>  [4] magrittr_1.5roxygen2_5.0.1  BiocGenerics_0.12.1
>  [7] munsell_0.4.3   xtable_1.8-2colorspace_1.2-6
> [10] stringr_1.0.0   plyr_1.8.3  tools_3.2.3
> [13] grid_3.2.3  gtable_0.1.2R.oo_1.20.0
> [16] withr_1.0.1 digest_0.6.9gridExtra_2.0.0
> [19] RColorBrewer_1.1-2  Rgraphviz_2.10.0reshape2_1.4.1
> [22] ggplot2_2.0.0   cgdsr_1.2.5 codetools_0.2-14
> [25] memoise_1.0.0   stringi_1.0-1   R.methodsS3_1.7.1
> [28] scales_0.3.0stats4_3.2.3
>
>
> --
> Luca De Sano
> tel: +393337177338
> email: l.des...@campus.unimib.it
> PEC: luca.des...@pec.it
>
> On 25 February 2016 at 12:03, Vincent Carey 
> wrote:
>
>> sessionInfo might help.  my guess is that you have an outofdate bnlearn
>> installed?
>>
>> On Thu, Feb 25, 2016 at 5:57 AM, Luca De Sano 
>> wrote:
>>
>>> Hi all,
>>> I'm working on a package named TRONCO (
>>> http://bioconductor.org/packages/devel/bioc/html/TRONCO.html ) which was
>>> released last year on bioconductor. Everytime I run R CMD check I get
>>> these
>>> two warnings:
>>>
>>> * checking whether the namespace can be loaded with stated dependencies
>>> ...
>>> WARNING
>>> Error: .onLoad failed in loadNamespace() for 'bnlearn', details:
>>>   call: setMethod("nodes", cl, function(object) .nodes(object))
>>>   error: no existing definition for function ‘nodes’
>>> Execution halted
>>>
>>> * checking whether the namespace can be unloaded cleanly ... WARNING
>>> Error: .onLoad failed in loadNamespace() for 'bnlearn', details:
>>>   call: setMethod("nodes", cl, function(object) .nodes(object))
>>>   error: no existing definition for function ‘nodes’
>>> Execution halted
>>>
>>> I've searched informations about these errors and I've only found some
>>> old
>>> posts on StackOverflow which suggested to change the order of the import.
>>> I've tried to do it with no result. At the moment I can't figure out what
>>> those warnings mean!
>>>
>>> Any suggestions?
>>>
>>> Warnings can be reproduced with the code listed below:
>>>
>>> git clone https://github.com/BIMIB-DISCo/TRONCO.git
>>> R CMD build TRONCO
>>> R CMD check TRONCO_2.3.0.tar.gz
>>>
>>> Thank you
>>>
>>> --
>>> Luca De Sano
>>> tel: +393337177338
>>> email: l.des...@campus.unimib.it
>>> PEC: luca.des...@pec.it
>>>
>>> [[alternative 

[Bioc-devel] Course: Statistics and Computing in Genome Data Science, July 10-15, 2016

[Morgan, Martin]

Registration is now open for the popular week-long R / Bioconductor course 
"Statistics and Computing in Genome Data Science", held annually in Bressanone 
- Brixen, Italy. Please see http://www.huber.embl.de/csama2016/ for more 
details.

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

Re: [Bioc-devel] topGO and cat() and print() statements in program code

[Morgan, Martin]

I followed your lead and updated topGO in Bioc devel branch to version 2.23.3, 
replacing cat() with message() directly rather a wrapper .cat2message(). I did 
not change use of cat() in print() and show() methods, where output to stdout 
is appropriate.

Generally, using message() simplified code, replacing multiple calls to cat() 
and nested paste() statements with a single call to message().

Martin


From: Bioc-devel  on behalf of Witold E 
Wolski 
Sent: Friday, February 5, 2016 5:50 AM
To: Dan Tenenbaum; henrik.bengts...@gmail.com
Cc: bioc-devel; James W. MacDonald
Subject: Re: [Bioc-devel] topGO and cat() and print() statements in program 
code

I did replace the call to cat in topGO with with a call to a package
private .cat2message function (which makes some adjustments to the
passed arguments so that the messages look as before). The patched
package is available from here.
https://github.com/wolski/topGO
Upstream commits made on 3 February by h.bengtsson are merged.
AFAIK all is working OK (checks pass and my code using topGO is still working)


Witold






On 4 February 2016 at 11:56, Witold E Wolski  wrote:
> Hi Dan,
>
> Excellent suggestion. This is very similar to how I am plan to do the
> refactoring. Write a function cat2message which has a signature like
> cat but uses message in the implementation and than replace all calls
> to cat in the topGO package.
>
> best
>
> On 4 February 2016 at 00:56, Dan Tenenbaum  wrote:
>> Another dirty hack is to redefine cat() in your own code to do nothing:
>>
>> cat <- function() {}
>>
>> Dan
>>
>>
>> - Original Message -
>>> From: "James W. MacDonald" 
>>> To: "Witold E Wolski" 
>>> Cc: "bioc-devel" 
>>> Sent: Tuesday, February 2, 2016 6:50:21 AM
>>> Subject: Re: [Bioc-devel] topGO and cat() and print() statements in program 
>>>   code
>>
>>> I can't speak to the issue of changing somebody else's code without forking
>>> (which you are free to do), or getting their OK. But do note that there are
>>> usually ways around this. First, you can use include = FALSE in your chunk
>>> options statement, which will run all the code, but silence everything.
>>> This isn't a good use case if you need to print, but that can usually be
>>> split out. Something like
>>>
>>> ```r{noisypart, include = FALSE}
>>>
>>> noisy code goes here
>>>
>>> ```
>>>
>>> ```r{quietpart, echo = FALSE, fig.cap = ""}
>>>
>>> plots go here
>>>
>>> ```
>>>
>>> An alternative is to use GOstats, which may be less noisy, but which still
>>> has 18 calls to cat() (vs 121 for topGO) and 2 calls to print() (vs 29 for
>>> topGO).
>>>
>>> Best,
>>>
>>> Jim
>>>
>>>
>>>
>>> On Tue, Feb 2, 2016 at 5:19 AM, Witold E Wolski  wrote:
>>>
 Hi,

 I am using the very usefull package topGO to generate a report (R
 markdown). There is not much to complain about topGO (on the contrary)
 except that the package uses cat instead of message to display
 progress information. which ruins the report.

 Also the bioconductor package guidelines state:
 cat() or print() are used only when displaying an object to the user,
 e.g., in a show method.

 This makes it difficult to integrate topGO.

 I did contact the maintainer asking to update topGO. However I did not
 get an reply. It seems that the maintainer is occupied with other
 problems. I did offer to replace the cat with message for these
 functions I am using myself. No reply.

 So what I am wondering is... If I do the corrections, and would like
 to commit the code... Sure I could create a branch but since I do not
 have write access to svn no chance to push (commit) it for review.
 And who is going to review it if the maintainer does not have time?

 best
 Witold





 --
 Witold Eryk Wolski

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

>>>
>>>
>>>
>>> --
>>> James W. MacDonald, M.S.
>>> Biostatistician
>>> University of Washington
>>> Environmental and Occupational Health Sciences
>>> 4225 Roosevelt Way NE, # 100
>>> Seattle WA 98105-6099
>>>
>>>   [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
> --
> Witold Eryk Wolski



--
Witold Eryk Wolski

___
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 

Re: [Bioc-devel] topGO and cat() and print() statements in program code

[Morgan, Martin]

Hi Witold -- if you'd like to submit a patch, I will apply this to the package 
and notify the maintainer. I suggest you either use svn to check out the 
'devel' version of the package, make your changes, and forward to me 
(martin.morgan at roswellpark.org) the output of svn diff (basic instructions 
here http://bioconductor.org/developers/how-to/source-control/), or do similar 
against the Bioconductor github mirror 
https://github.com/Bioconductor-mirror/topGO; for the latter you cannot submit 
a 'pull' request to the mirror, but you could point me to your repository.

Martin


From: Bioc-devel  on behalf of Witold E 
Wolski 
Sent: Tuesday, February 2, 2016 5:19 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] topGO and cat() and print() statements in program code

Hi,

I am using the very usefull package topGO to generate a report (R
markdown). There is not much to complain about topGO (on the contrary)
except that the package uses cat instead of message to display
progress information. which ruins the report.

Also the bioconductor package guidelines state:
cat() or print() are used only when displaying an object to the user,
e.g., in a show method.

This makes it difficult to integrate topGO.

I did contact the maintainer asking to update topGO. However I did not
get an reply. It seems that the maintainer is occupied with other
problems. I did offer to replace the cat with message for these
functions I am using myself. No reply.

So what I am wondering is... If I do the corrections, and would like
to commit the code... Sure I could create a branch but since I do not
have write access to svn no chance to push (commit) it for review.
And who is going to review it if the maintainer does not have time?

best
Witold





--
Witold Eryk Wolski

___
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

Re: [Bioc-devel] TIMEOUTs on Morelia

[Morgan, Martin]

I don't see an error, but on linux under valgrind and current R-devel / bioc 
packages and especially

> packageVersion("S4Vectors")
[1] '0.9.26'


I see

> rse[1:2,] # hangs
==23105== Invalid read of size 4
==23105==at 0xD0B8D4D: int_bsearch (Rle_class.c:606)
==23105==by 0xD0B8C45: find_window_runs2 (Rle_class.c:654)
==23105==by 0xD0B868B: find_runs_of_ranges2 (Rle_class.c:719)
==23105==by 0xD0B6F5A: find_runs_of_ranges (Rle_class.c:837)
==23105==by 0xD0B75CA: _subset_Rle_by_ranges (Rle_class.c:996)
==23105==by 0xD0B7A42: Rle_extract_ranges (Rle_class.c:1018)
==23105==by 0x4F24411: R_doDotCall (dotcode.c:582)
==23105==by 0x4F31621: do_dotcall (dotcode.c:1251)
==23105==by 0x4F6FA8A: Rf_eval (eval.c:713)
==23105==by 0x4F88101: do_begin (eval.c:1806)
==23105==by 0x4F6F8B7: Rf_eval (eval.c:685)
==23105==by 0x4F85303: Rf_applyClosure (eval.c:1134)
==23105==  Address 0x80f1760 is 0 bytes after a block of size 0 alloc'd
==23105==at 0x4C2AB80: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23105==by 0xD0B8549: find_runs_of_ranges2 (Rle_class.c:704)
==23105==by 0xD0B6F5A: find_runs_of_ranges (Rle_class.c:837)
==23105==by 0xD0B75CA: _subset_Rle_by_ranges (Rle_class.c:996)
==23105==by 0xD0B7A42: Rle_extract_ranges (Rle_class.c:1018)
==23105==by 0x4F24411: R_doDotCall (dotcode.c:582)
==23105==by 0x4F31621: do_dotcall (dotcode.c:1251)
==23105==by 0x4F6FA8A: Rf_eval (eval.c:713)
==23105==by 0x4F88101: do_begin (eval.c:1806)
==23105==by 0x4F6F8B7: Rf_eval (eval.c:685)
==23105==by 0x4F85303: Rf_applyClosure (eval.c:1134)
==23105==by 0x4F6FB9C: Rf_eval (eval.c:732)
==23105== 
==23105== Invalid read of size 4
==23105==at 0xD0B8D7D: int_bsearch (Rle_class.c:612)
==23105==by 0xD0B8C45: find_window_runs2 (Rle_class.c:654)
==23105==by 0xD0B868B: find_runs_of_ranges2 (Rle_class.c:719)
==23105==by 0xD0B6F5A: find_runs_of_ranges (Rle_class.c:837)
==23105==by 0xD0B75CA: _subset_Rle_by_ranges (Rle_class.c:996)
==23105==by 0xD0B7A42: Rle_extract_ranges (Rle_class.c:1018)
==23105==by 0x4F24411: R_doDotCall (dotcode.c:582)
==23105==by 0x4F31621: do_dotcall (dotcode.c:1251)
==23105==by 0x4F6FA8A: Rf_eval (eval.c:713)
==23105==by 0x4F88101: do_begin (eval.c:1806)
==23105==by 0x4F6F8B7: Rf_eval (eval.c:685)
==23105==by 0x4F85303: Rf_applyClosure (eval.c:1134)
==23105==  Address 0x8ba088c is 4 bytes before a block of size 0 alloc'd
==23105==at 0x4C2AB80: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23105==by 0xD0B8549: find_runs_of_ranges2 (Rle_class.c:704)
==23105==by 0xD0B6F5A: find_runs_of_ranges (Rle_class.c:837)
==23105==by 0xD0B75CA: _subset_Rle_by_ranges (Rle_class.c:996)
==23105==by 0xD0B7A42: Rle_extract_ranges (Rle_class.c:1018)
==23105==by 0x4F24411: R_doDotCall (dotcode.c:582)
==23105==by 0x4F31621: do_dotcall (dotcode.c:1251)
==23105==by 0x4F6FA8A: Rf_eval (eval.c:713)
==23105==by 0x4F88101: do_begin (eval.c:1806)
==23105==by 0x4F6F8B7: Rf_eval (eval.c:685)
==23105==by 0x4F85303: Rf_applyClosure (eval.c:1134)
==23105==by 0x4F6FB9C: Rf_eval (eval.c:732)
==23105== 




From: Bioc-devel  on behalf of Michael Love 

Sent: Monday, February 1, 2016 3:35 PM
To: Dan Tenenbaum
Cc: bioc-devel; Hervé Pagès
Subject: Re: [Bioc-devel] TIMEOUTs on Morelia

I was able to construct a minimal example where it seems the bug originates
from SummarizedExperiment:

library(SummarizedExperiment)
se <- SummarizedExperiment(matrix(1:6,ncol=2))
rse <- as(se, "RangedSummarizedExperiment")
rse[1:2,] # hangs


On Mon, Feb 1, 2016 at 2:57 PM, Michael Love 
wrote:

> ​Thanks Stephen and Dan, sorry I haven't chased this down recently.
>
> I have access to a Mac and will look into it now.
>
> -Mike​
>
> On Mon, Feb 1, 2016 at 1:45 PM, Dan Tenenbaum 
> wrote:
>
>> Actually, it does seem like there is a more complicated issue going on. I
>> will investigate and report back here.
>>
>> Thanks,
>> Dan
>>
>>
>> - Original Message -
>> > From: "Dan Tenenbaum" 
>> > To: "Hartley, Stephen (NIH/NHGRI) [F]" 
>> > Cc: "bioc-devel" 
>> > Sent: Monday, February 1, 2016 10:11:54 AM
>> > Subject: Re: [Bioc-devel] TIMEOUTs on Morelia
>>
>> > I think the morelia server was overloaded, so it was restarted
>> yesterday around
>> > 11PM Seattle time, so I hope we will see fewer TIMEOUTs in today's build
>> > report.
>> > Dan
>> >
>> >
>> > - Original Message -
>> >> From: "Hartley, Stephen (NIH/NHGRI) [F]" 
>> >> To: "bioc-devel" 
>> >> Sent: Monday, February 1, 2016 10:06:11 AM
>> >> Subject: [Bioc-devel] TIMEOUTs on Morelia
>> >
>> >> The current devel 

Re: [Bioc-devel] Vignette building fails

[Morgan, Martin]

I tried to build your vignettes on my own computer, but they are taking too 
long. From

  http://bioconductor.org/developers/package-guidelines/#correctness

the time limit for checking a package (which includes running the vignette 
code, though not building the vignette) is 5 minutes. Do your vignettes take a 
lot of time to build?

If so, you should first identify the slow portion of your code and attempt to 
vectorize it; ask here for help if needed.

You should then construct examples for use in your vignette that are 
sufficiently realistic to shine a favorable light on the full richness of your 
software, but easily computed within the available time.

Martin


From: Bioc-devel  on behalf of Fan, Jean 

Sent: Thursday, January 28, 2016 8:37 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Vignette building fails

Hello,

I recently updated my bioconductor package via svn. The package was built 
successfully on my computer via R CMD build scde and passed R CMD check scde 
and R CMD BiocCheck scde. But the build report on Bioconductor ran into the 
following errors when building the vignettes:

* checking for file ‘scde/DESCRIPTION’ ... OK
* preparing ‘scde’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... ERROR
Loading required package: flexmix
Loading required package: lattice
Error: processing vignette 'diffexp.Rmd' failed with diagnostics:
Failed to locate the ‘weave’ output file (by engine ‘knitr::rmarkdown’) for 
vignette with name ‘diffexp’. The following files exist in directory ‘.’: 
‘diffexp.R’, ‘diffexp.Rmd’, ‘diffexp.md’, ‘pagoda.Rmd’
Execution halted

I was able to build the vignettes locally using R CMD Sweave so I’m not sure 
what’s wrong. I haven’t been able to find any solutions by Googling around. Has 
anyone else encountered this error before?

Thanks,
Jean

Jean Fan
PhD Candidate
NSF GRFP
Kharchenko Lab
Harvard University
10 Shattuck St #3, Countway 336B
Boston, MA 02115

[[alternative HTML version deleted]]

___
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

Re: [Bioc-devel] bplapply Processes Sometimes Stall

[Morgan, Martin]

The change I had my eye on was not ported to patched, so (a) it could have been 
a more general R issue or (b) you got lucky. It would be great to get something 
(easily) reproducible in 3.2.3.

Martin


From: Bioc-devel  on behalf of Dario Strbenac 

Sent: Friday, January 22, 2016 6:00 AM
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] bplapply Processes Sometimes Stall

Good day,

I was skeptical that using R Under Development would make a difference to this 
problem, but I installed it, ran the cross-validation loop overnight, and it 
completed successfully. It also works with R 3.2.3 Patched, but not R 3.2.3, 
suggesting that a recent modification to R solves the problem. Now I need to 
convince the server administrator (who relies on the availability of Debian 
packages and apt-get) to install R from source on the servers!

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


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] Conference: BioC 2016: Where Software and Biology Connect, Stanford, 24-26 June

[Morgan, Martin]

Bioconductors!

Please plan to attend BioC2016: Where Software and Biology Connect, June 24 
(Developer Day) - 26, Stanford University, Stanford, CA. See

http://bioconductor.org/help/course-materials/2016/BioC2016/

for additional information.

DEVELOPERS: Please consider offering a user-oriented workshop during the main 
conference. This is a great opportunity to get the word out about your packages 
and workflows, and to connect with your users. Submit a proposal by following 
the link on the conference page!

This is our annual conference, with a 'developer day' (June 24; attend if you 
develop or are interested in developing Bioconductor packages) followed by the 
main conference (June 25, 26) of morning invited talks and afternoon workshops.

Afternoon Workshop Proposals are now being accepted.

Registration and additional logistic information is being established; early 
registration opens February 15. Participants are responsible for their own 
travel and accommodation.

The conference is immediately before useR! 2016, the annual R user conference.

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

Re: [Bioc-devel] bplapply Processes Sometimes Stall

[Morgan, Martin]

Please ensure that your Debian system is running R-devel and using the current 
BiocParallel by providing the output of sessionInfo().

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Dario Strbenac 
[dstr7...@uni.sydney.edu.au]
Sent: Sunday, January 17, 2016 7:00 PM
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] bplapply Processes Sometimes Stall

Hello,

Running the code serially works and running it on an Ubuntu 15.10 server also 
works. The problem has only been found with Debian 8.2.

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


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

Re: [Bioc-devel] IRanges - PartitioningByEnd not found when package method runs.

[Morgan, Martin]

Hi Ben --

R has a 'y' release in x.y.z every year, but Bioconductor has a .y release 
(where current devel becomes release) every 6 months.

Obviously we want to 'devel' bioc packages so that they can be released to 
users of what will be the release version of R at the time of release.

When the next (typically mid-April, but no date set yet) .y releases of R and 
Bioc coincide, Bioc-devel is based on R-devel.

When the next (typically mid-October) .y release of Bioc corresponds to no 
change in R's y, Bioc-devel is based on release R.

So yes, now you should be using R-devel. After mid-April, you'd use R-release 
for bioc devel. Then after mid-October, it would be back to R-devel.

That's not quite correct, because R has a release branch where bug fixes and 
minor '.z' changes come from. So from mid-April to mid-October, technically 
devel is against the R-x-y-branch of R svn repository.

This information has been added to the web site (I'm pretty sure it's already 
there, but I can't find it!) at

http://bioconductor.org/developers/how-to/useDevel/

The update will propagate in the next 20 minutes or so.

Martin
 

From: Ben Ward (TGAC) [ben.w...@tgac.ac.uk]
Sent: Thursday, January 14, 2016 4:20 AM
To: Hervé Pagès; Morgan, Martin; bioc-devel@r-project.org
Subject: RE: [Bioc-devel] IRanges - PartitioningByEnd not found when package 
method runs.

Hi, Herve, Martin,

Thanks! I've changed the function to use IntegerList instead of list in the 
branch, although at the moment it still fails at the same place.

Should I switch entirely to a devel R and bioc whilst I work on my package? You 
said 'during the current release cycle that means using the devel version on 
R', does this mean it switches and sometimes release R should be used?

Many thanks,
Ben.

From: Hervé Pagès [hpa...@fredhutch.org]
Sent: 14 January 2016 03:28
To: Morgan, Martin; Ben Ward (TGAC); bioc-devel@r-project.org
Subject: Re: [Bioc-devel] IRanges - PartitioningByEnd not found when package 
method runs.

Hi Ben, Martin,

On 01/13/2016 08:19 AM, Morgan, Martin wrote:
> Hi Ben -- nice to see you over here ;)
>
> You're using the release version of R (R-3.2.3) and presumably release 
> versions of packages (my advice on placing sessionInfo() was a little too 
> clever; you want your package loaded, so the versions of it's dependencies 
> are apparent, so in a separate R maybe library(testRpkg); sessionInfo(); I'll 
> update my support site post...).
>
> At least for Bioconductor packages, you want to be using the 'devel' version 
> of Bioconductor, and during the current release cycle that means the devel 
> version of R.
>
> Nonetheless, I started R-release, loaded the test package, ran the function, 
> and looked at traceback()
>
>> library(testRpkg)
>> doit()
> Error in end(PartitioningByEnd(x)) :
>error in evaluating the argument 'x' in selecting a method for function 
> 'end': Error: could not find function "PartitioningByEnd"
>> traceback()
> 9: end(PartitioningByEnd(x))
> 8: .unlist_NL_subscript(i, x)
> 7: fast_path_FUN(x, i)
> 6: subset_List_by_List(x, i)
> 5: object[index]
> 4: object[index]
> 3: subsetSites(dna, 1:50)
> 2: subsetSites(dna, 1:50)
> 1: doit()
>
> The suspect looks like .unlist_NL_subscript, so I went looking for it
>
>> getAnywhere(.unlist_NL_subscript)
> A single object matching '.unlist_NL_subscript' was found
> It was found in the following places
>namespace:S4Vectors
> with value
>
> function (i, x)
> {
>  offsets <- c(0L, end(PartitioningByEnd(x))[-length(x)])
>  i <- i + offsets
>  unlist(i, use.names = FALSE)
> }
> 
>
> So S4Vectors wants to use PartitioningByEnd. I looked at it's NAMESPACE 
> imports (actually I looked in the SVN repository...) for the packages it 
> imports from...
>
>> names(getNamespaceImports("S4Vectors"))
> [1] "base" "methods"  "utils""stats""stats4"
> [6] "BiocGenerics"
>
> and find that it does not import IRanges. So the problem is a bug in 
> S4Vectors.
>
> I don't see the problem in bioc-devel, and to see why I had to be a bit 
> clever -- there is no error, so no opportunity to use traceback(). Instead, I 
> used the advanced-but-flexible 'trace' function to set a tracer on 
> PartioningByEnd, where the tracer is the 'recover' function...
>
>> trace(IRanges::PartitioningByEnd, tracer=recover)
>
> So when PartioningByEnd is evalutated, R will get me the 'recover' prompt...
>> doit()
> Tracing IRanges::PartitioningByEnd(x) on entry
>
> Enter a frame number, or 0 to exit
>
>   1: doit()
>   2: subsetSites(dna, 1:50)
>  

[Bioc-devel] R / Bioconductor job opportunity: Senior Programmer / Analyst

[Morgan, Martin]

The Bioconductor team has an opening available for a Senior Progammer / 
Analyst, see


https://www.roswellpark.org/careers/administrative/senior-programmeranalyst-4301

for details. Bioconductor is an exciting and reward work environment.

Please contact me (martin.morgan at roswellpark.org) with any questions.

Best Wishes,

Martin Morgan
Bioconductor

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

Re: [Bioc-devel] Use of EnsDb in the AnnotationDbi framework

[Morgan, Martin]

Thanks Johannes, this is a valuable contribution and I've added it to the 
'official' vignette.

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Rainer 
Johannes [johannes.rai...@eurac.edu]
Sent: Thursday, January 07, 2016 9:10 AM
To: Bioc-devel
Subject: [Bioc-devel] Use of EnsDb in the AnnotationDbi framework

Dear all,

thanks to Vince’s suggestion I have now implemented the central AnnotationDbi 
methods “columns”, “keys”, “keytypes” and “select” for EnsDb objects in my 
ensembldb package version 1.3.11 (EnsDb are TxDb like annotation 
packages/objects tailored to Ensembl based annotations). Thus, EnsDb based 
annotation packages can now be used in the AnnotationDbi framework. The methods 
support in addition also the filter framework of the ensembldb package to 
provide some more fine grained querying and data retrieval.
I have forked the AnnotationDbi package and added a section to its 
“IntroToAnnotationPackages.Rnw” vignette describing how to use EnsDb objects 
along with the above mentioned methods 
(https://github.com/jotsetung/AnnotationDbi). Eventually this could also be 
inserted to the “official” AnnotationDbi package.

best, jo
___
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

Re: [Bioc-devel] Problem with seqnames of TwoBitFile from AnnotationHub

[Morgan, Martin]

We switched to TwoBitFile with a recent ensembl release, thinking that it had 
better performance and other characteristics compared to the previous FaFile.

The 'recipe' used to create the FaFiles did not explicitly trim the label; that 
appears to be something done by Rsamtools::indexFa and hence (a now quite 
dated) version of samtools.

I'm not precisely sure where we stand on correcting this. The original approach 
just takes what we're given and makes a 2bit file. At least provisionally we 
had decided (after Thurs / Fri exchanges) to make the seqlevels sensible on the 
way in to annotation hub; this is against Sean's advice and I'm not really a 
big fan of this. 

I like the idea of being able to dynamically remap the seqlevels when the 2bit 
file is loaded by AnnotationHub, which would require Herve's suggestion of 
settable seqlevels on TwoBitFile.

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Rainer 
Johannes [johannes.rai...@eurac.edu]
Sent: Saturday, January 09, 2016 11:01 AM
To: Hervé Pagès
Cc: Michael Lawrence; Martin Morgan
Subject: Re: [Bioc-devel] Problem with seqnames of TwoBitFile from AnnotationHub

Yes, using BSGenome would help in this case.
In the long run I think it might be important to have this fixed, not 
necessarily for human, but for other species/genome builds for which there 
might not be an BSGenome package available; through AnnotationHub all GTF files 
and fasta files would be available. Note also that the FaFiles from Ensembl do 
have the “correct” chromosome names although I assume they were built from the 
same Ensembl fasta files than the TwoBitFiles.

jo

> On 08 Jan 2016, at 22:49, Hervé Pagès  wrote:
>
> On 01/08/2016 01:09 PM, Michael Lawrence wrote:
>> That is one solution. But everyone using that genome would need to
>> reset the seqlevels to the "standard" ones. In this specific case, is
>> there any reason not to just use the BSgenome for GRCh38?
>
> I agree. Maybe we don't need seqlevels<-,TwoBitFile for that particular
> use case. Just wanted to mention that the ability to rename the
> sequences in a TwoBitFile, FastaFile, or other file-based object that
> supports seqinfo() would be useful in general.
>
> H.
>
>>
>> On Fri, Jan 8, 2016 at 11:04 AM, Hervé Pagès  wrote:
>>> Hi Jo, Michael,
>>>
>>> What about implementing a seqlevels() setter for TwoBitFile objects? All
>>> you need for this is an extra slot for storing the user-supplied
>>> seqlevels. Note that in general the seqlevels() setter allows more than
>>> renaming the seqlevels. It also allows dropping, adding, and shuffling
>>> them. But you don't need to support all that. Supporting renaming would
>>> already go a long way. See selectMethod("seqlevels<-", "TxDb") in
>>> GenomicFeatures for an example of a restricted "seqlevels<-" method.
>>>
>>> H.
>>>
>>>
>>> On 01/08/2016 09:50 AM, Rainer Johannes wrote:

 I agree, I would not modify the file content. At present it is however not
 possible to use e.g. getSeq on these TwoBitFiles, since the chromosome 
 names
 in the submitted GRanges (e.g. 1) do not match the seqnames/seqinfo of the
 TwoBitFile. I don’t know if a seqnames or seqinfo method stripping of all
 but the first name-part would help here...

 jo

> On 08 Jan 2016, at 15:18, Sean Davis  wrote:
>
> I will make the small editorial comment to guard against modifying file
> content on transit into the hub object. On the client side (after getting
> such an object) I think a “fix” would be to have a quick seqnames method 
> to
> strip off all but the first whitespace delimited piece.
>
> Sean
>
>> On Jan 8, 2016, at 8:40 AM, Michael Lawrence 
>> wrote:
>>
>> This is perhaps something that could be handled when population the
>> hub, but I'm not sure how rtracklayer could automatically derive the
>> chromosome names.
>>
>> On Fri, Jan 8, 2016 at 2:37 AM, Rainer Johannes
>>  wrote:
>>>
>>> dear all,
>>>
>>> I just run into a problem with a TwoBitFile I fetched from
>>> AnnotationHub. I was fetching a TwoBitFile with the genomic DNA 
>>> sequence, as
>>> provided by Ensembl:
>>>
 library(AnnotationHub)
 ah <- AnnotationHub()
 tbf <- ah[["AH50068”]]
>>>
>>>
 head(seqnames(seqinfo(tbf)))
>>>
>>> [1] "1 dna:chromosome chromosome:GRCh38:1:1:248956422:1 REF"
>>> [2] "10 dna:chromosome chromosome:GRCh38:10:1:133797422:1 REF"
>>> [3] "11 dna:chromosome chromosome:GRCh38:11:1:135086622:1 REF"
>>> [4] "12 dna:chromosome chromosome:GRCh38:12:1:133275309:1 REF"
>>> [5] "13 dna:chromosome chromosome:GRCh38:13:1:114364328:1 REF"
>>> [6] "14 dna:chromosome chromosome:GRCh38:14:1:107043718:1 REF"
>>>
>>> 

[Bioc-devel] Bioconductor GSOC sponsorship?

[Morgan, Martin]

Hi -- 

Bioconductor has sometimes participated in Google Summer of Code 
(https://developers.google.com/open-source/gsoc/timeline?hl=en , 
https://developers.google.com/open-source/gsoc/faq#how_does_a_mentoring_organization_apply).
 If there is interest in the community to sponsor participation (facilitate 
Bioconductor as a 'Mentoring Organization'; i.e., we're not looking for a 
participants or even mentors yet!) this year, please let me know.

Martin

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

Re: [Bioc-devel] mapIds methods for ExpressionSet and SummarizedExperiment

[Morgan, Martin]

Thanks Ludwig I'll have a look. Martin


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Ludwig 
Geistlinger [ludwig.geistlin...@bio.ifi.lmu.de]
Sent: Wednesday, January 06, 2016 12:07 PM
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] mapIds methods for ExpressionSet and 
SummarizedExperiment

Dear Martin,

I finally found the time to make the code available via GitHub:

https://github.com/lgeistlinger/MapIds

and added you as a collaborator.
This is currently just a quick put-together for you to get an impression.
NA and duplicated mappings currently need to be removed to ensure
uniqueness of featureNames and rownames, respectively (via na.rm=TRUE and
dupl.rm=TRUE).

But there are, of course, other/better ways to summarize over
NA's/Duplicates, e.g. by appropriately passing that on to the 'multiVals'
Argument of AnnotationDbi::mapIds().

Just let me know in case you find that of any use or you find things that
could be improved/extended.

Best,
Ludwig



---

Dear Martin,

Ok, I am tyding that up and provide that via GitHub for you.
BTW, these ranges to Ids and vice versa sounds very cool!


> The original intention of the annotation() slot in ExpressionSet was to
> include the microarray chip identifier, so that one references this when
> translating from probeset to gene identifiers.

One question to that, as I often find my functions to ask for the organism
uder study (which I believe is actually most typically known when
investigating an expression dataset). While there are convenient ways to
ask microarray annotation packages for the organism under study (and thus
infer it from annotation(eset)), I wonder whether there is a similar slot
for SummarizedExperiment, eg an 'organism' slot? Or are there specific
reasons arguing against that?

Best,
Ludwig


> Hi Ludwig --
>
> It would be really great to see what you've put together; can you make
> your code available somewhere, maybe via github?
>
> I think the facilities already in Bioconductor include:
>
> - select() and the OrganismDb (e.g., Homo.sapiens) packages
>
> - (Recently introduced, in bioc-devel) GenomicFeatures::mapIds()
>
> - GSEABase mapIdentifiers()
>
> - The AnnotationFuncs package (some of this functionality might be
> redundant with select() / mapIds(); maybe your idea is a more refined
> version of this?
>
> - biomaRt, including the relatively under-known use of select() with mart
> objects.
>
> I think a particularly valuable development (initial implementation in
> GenomicFeatures::mapIds()) is transparent mapping to / from genomic
> ranges.
>
> The original intention of the annotation() slot in ExpressionSet was to
> include the microarray chip identifier, so that one references this when
> translating from probeset to gene identifiers.
>
> Martin
> 
> From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Ludwig
> Geistlinger [ludwig.geistlin...@bio.ifi.lmu.de]
> Sent: Thursday, December 17, 2015 5:05 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] mapIds methods for ExpressionSet and
> SummarizedExperiment
>
> Dear Bioc Team,
>
> I have implemented mapIds methods mapping featureNames (ExpressionSet) and
> rownames (SummarizedExperiment) between major gene ID types such as
> ENSEMBL and ENTREZ by passing that on AnnotationDbi::mapIds.
>
> Given an ExpressionSet/SummarizedExperiment and an organism under
> investigation such as 'Homo sapiens', the methods are checking whether the
> corresponding org.db package is available, otherwise the package is
> automatically installed and loaded.
> Subsequently, the featureNames/rownames are mapped from the specified
> from.id.type to the desired to.id.type, corresponding to keytypes of the
> org.db package.
> Options to deal with NA and duplicate mappings are also provided in order
> to ensure that featureNames/rownames are unique after the mapping.
>
> Advantage is that end users do not require knowledge of the Bioc
> annotation infrastructure, but rather just need to provide the organism
> under investigation in a convenient format also for non-Biocs.
>
> I have not found something similar in existing packages and I am wondering
> whether this could be something of general interest.
>
> Best,
> Ludwig
>
> --
> Dipl.-Bioinf. Ludwig Geistlinger
>
> Lehr- und Forschungseinheit für Bioinformatik
> Institut für Informatik
> Ludwig-Maximilians-Universität München
> Amalienstrasse 17, 2. Stock, Büro A201
> 80333 München
>
> Tel.: 089-2180-4067
> eMail: ludwig.geistlin...@bio.ifi.lmu.de
>
> ___
> 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 

[Bioc-devel] Updated package submission policies

[Morgan, Martin]

Bioconductors -- we intend to change the way new packages are submitted and 
reviewed before being added to the Bioconductor repository. Please see 
additional detail on the support site at 
https://support.bioconductor.org/p/76472/.

Best wishes,

Martin

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

Re: [Bioc-devel] bplapply Processes Sometimes Stall

[Morgan, Martin]

Hi Dario -- the most likely explanation, without a reproducible example, is 
that the code used on workers sometimes puts R into a state that it cannot 
recover from.

The first approach to debug this is to run the code serially, e.g., using 
SerialParam and perhaps register(SerialParam()) (to make serial evaluation the 
default in a bplapply() invoked without a BPPARAM argument).

BiocParallel 1.5.12 is from the 'devel' branch of Bioconductor, which is 
supposed to be used (currently) on R-devel; please always use the appropriate 
version of R, with packages installed using biocLIte() when reporting problems.

Probably this belongs on support.bioconductor.org, where others may more easily 
benefit from your experience.

There are a couple of things that have come up while looking in to your problem 
and how R can get into the situation where several processes share a socket 
connection in the CLOSE_WAIT state; I'm still exploring solutions but it is not 
obvious that these would address whatever your underlying issue might be; R 
might be more helpful in saying that something has gone wrong, without being 
able to say exactly what.

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Dario Strbenac 
[dstr7...@uni.sydney.edu.au]
Sent: Friday, January 01, 2016 9:00 PM
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] bplapply Processes Sometimes Stall

Good day,

I haven't been able to make a small and reproducible example, but I am using 
bpstart and bpstop to run a loop with 25 workers multiple times on a large 
bioinformatics dataset. After a few times of running the loop successfully, a 
small number of the R workers use 100% CPU endlessly :

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
 3300 dario 20   0 1190832 837212  17988 R 100.0  0.2   3848:00 R
 5014 dario 20   0 1194528 829084   8224 R  99.8  0.2   3843:44 R
 5015 dario 20   0 1194532 829088   8224 R  99.8  0.2   3843:44 R

There are also three connections belonging to the R processes waiting to close :

~$ lsof -i | grep CLOSE
R  3300 dario 1025u  IPv4 160778259  0t0  TCP 
localhost:11881->localhost:49379 (CLOSE_WAIT)
R  5014 dario 1025u  IPv4 160778259  0t0  TCP 
localhost:11881->localhost:49379 (CLOSE_WAIT)
R  5015 dario 1025u  IPv4 160778259  0t0  TCP 
localhost:11881->localhost:49379 (CLOSE_WAIT)

~$ lsof -i | grep -c R
256

I use :

R version 3.2.3 (2015-12-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)

with BiocParallel 1.5.12

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


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

Re: [Bioc-devel] Progress Message Order in bplapply

[Morgan, Martin]

Hi Dario -- it was this commit


r111519 | mtmor...@fhcrc.org | 2015-12-15 14:34:18 -0500 (Tue, 15 Dec 2015) | 2 
lines

port: r111463, bugfix: workers=1, tasks=0 assigns all X to one chunk



in response to this report

https://support.bioconductor.org/p/75945/

Previously, the behavior when the number of 'tasks' was unspecified (default 
value 0) was to split X (in your example, the vector 1:100) into 100 individual 
tasks 1, 2, 3, ..., and to process each in a completely independent parallel 
process -- there would be a total of 100 processes started and stopped. The 
change mentioned above instead behaves as documented, splitting the 100 
elements approximately evenly between the specified number of workers (25), and 
sending several elements to each worker for processing. This saves the cost of 
communicating the object to and from the worker. You can get the old behavior 
by specifying tasks = length(X), for your example tasks=100. 

The 'split' of elements into tasks can be seen by calling the internal function 
.splitX()

> head(BiocParallel:::.splitX(1:100, 25, 100))  # 1 task per job
[[1]]
[1] 1

[[2]]
[1] 2

[[3]]
[1] 3

[[4]]
[1] 4

[[5]]
[1] 5

[[6]]
[1] 6

> head(BiocParallel:::.splitX(1:100, 25, 0))  # 4 tasks per job
[[1]]
[1] 1 2 3 4

[[2]]
[1] 5 6 7 8

[[3]]
[1]  9 10 11 12

[[4]]
[1] 13 14 15 16

[[5]]
[1] 17 18 19 20

[[6]]
[1] 21 22 23 24


Each element of the call to splitX is assigned in order, but the precise 
schedule is somewhat indeterminate -- task 1 might be assigned before task 2, 
but perhaps the process handling task 1 runs the garbage collector before 
sleeping so task 2 finishes ahead of task 1. Under the original scheme I guess 
you were relying on the average execution time of ten processes between each 
message, whereas in the correct scheme you are relying on the average execution 
time of just three processes so greater variability. Either way, though, the 
order of execution is not guaranteed.

Messages are reported at the end of each task; there are 100 opportunities for 
messages when the number of tasks is 100, but only 25 opportunities 
(corresponding approximately to each processor handling 4 elements) otherwise.

Other than being different from previously, is there an underlying problem?

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Dario Strbenac 
[dstr7...@uni.sydney.edu.au]
Sent: Sunday, December 27, 2015 7:00 PM
To: bioc-devel list
Subject: [Bioc-devel] Progress Message Order in bplapply

Hello,

I am experiencing some new and unexpected behaviour of mclapply.

Previously, progress messages were displayed in almost the expected order. Now, 
they are unlike the original order. My test case is :

bplapply(1:100, function(x) {if(x %% 10 == 0) message(x); Sys.sleep(30)}, 
BPPARAM = MulticoreParam(workers = 25))

The resulting progress message aren't displayed until the end of the process, 
whereas before they appeared immediately. I would expect 10 and 20 to appear 
before 30 did.

30
40
50
10
20
60
70
80
90
100

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

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

Re: [Bioc-devel] bplapply Processes Sometimes Stall

[Morgan, Martin]

Hi Dario -- This didn't cause problems for me. One thing you might do is to 
re-use the MulticoreParam() like this

param = bpstart(MulticoreParam(25))
lapply(1:20, function(variety) bplapply(1:100, function() {}, BPPARAM = 
param))
bpstop(param)

Also there have been a number of changes in devel and if possible it would be 
good to know whether the problem still appears there.

It might be interesting to see the number of connections open when the process 
hangs, from the command line while R is still running

   ~$ lsof -i |grep -c R

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Dario Strbenac 
[dstr7...@uni.sydney.edu.au]
Sent: Sunday, December 27, 2015 8:00 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] bplapply Processes Sometimes Stall

Good day,

I have a minimal example of bplapply stalling.

results <- lapply(1:20, function(variety)
{
  message("Variety", variety)
  bplapply(1:100, function(index) {res <- list(sample(2), 
sample(c("Healthy", "Disease"), 2, replace = TRUE)); res}, BPPARAM = 
MulticoreParam(workers = 25))
})

It sometimes stalls on no particular iteration, but other times it runs all 20 
iterations and returns to the R command prompt. It's not reproducible when the 
stall happens. I am trying to find the cause of a cross-validation loop that 
progresses for a few hours, then stalls. When the stall happens, two or three 
of the R processes appear to be using 100% CPU whereas the others are finished, 
according to the output of top. The server was previously running R 3.1.2 and 
Debian 7 and this didn't ever happen. The server has 48 processors.

If I set workers to 5, it always completes the loop and returns to the prompt. 
Using mclapply with mc.cores set to 25 also always works, so the problem is 
with bplapply.

R version 3.2.3 (2015-12-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)

locale:
 [1] LC_CTYPE=C.UTF-8   LC_NUMERIC=C   LC_TIME=C.UTF-8
LC_COLLATE=C.UTF-8
 [5] LC_MONETARY=C.UTF-8LC_MESSAGES=C.UTF-8LC_PAPER=C.UTF-8   
LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C LC_MEASUREMENT=C.UTF-8 
LC_IDENTIFICATION=C

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

other attached packages:
[1] BiocParallel_1.4.3

loaded via a namespace (and not attached):
[1] futile.logger_1.4.1  lambda.r_1.1.7   futile.options_1.0.0

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


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

Re: [Bioc-devel] Warning: no visible global function definition for ‘seqlevels<-’

[Morgan, Martin]

Yes, that's right, either 

  import(GenomeInfoDb)

or

  importFrom(GenomeInfoDb, "seqlevels<-")

Martin


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Venkat Malladi 
[venkat.mall...@utsouthwestern.edu]
Sent: Tuesday, December 22, 2015 3:19 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Warning: no visible global function definition for   
‘seqlevels<-’

Hi,

I have the recently got this warning in my package

combineTranscripts: no visible global function definition for �seqlevels<-�

How would I fix this warning, when building my package. One of my packages 
calls the function seqlevels. I think if I explicilty import GenomeInfoDb in my 
NAMESPACE file it should fix this issue right?

Thanks for the help.

Venkat




UT Southwestern


Medical Center



The future of medicine, today.


[[alternative HTML version deleted]]



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

Re: [Bioc-devel] Rsamtools/AnnotationHub Error for FaFile - multiple methods tables found for ‘relistToClass’

[Morgan, Martin]

Hi Sonali --

relistToClass was originally in IRanges

Packages such as Biostrings that Depend: or Import: IRanges and then create a 
'relistToClass' method created a methods table on INSTALLATION, noting that the 
generic is in IRanges.

The 'relistToClass' generic was moved from IRanges to S4Vectors, with 
appropriate version bumps for these packages.

Loading the 'old' version of Biostrings (library(Biostrings)) now sees a new 
generic in S4Vectors, but has the old methods table that thinks the methods are 
being added to the IRanges generic.

This results in the warning "multiple methods tables found for ‘relistToClass’".

The end-user solution is to re-install the Biostrings package 
(biocLite("Biostrings")). This will use the correct methods table.

Any package that defines a method on relistToClass requires updating; there are 
similar problems with 'space' and 'unlist'. I believe the 'core' packages 
requiring updating (defining methods, but svn revision older than r111605) 
include c("GenomicRanges", "rtracklayer", "GenomicAlignments", "Biostrings", 
"BSgenome", "VariantAnnotation").

Please let me know if the problem continues after re-installing these packages.

I have bumped the versions of each of these packages, so that biocLite() after 
tomorrow-ish should force these to be re-installed.

Usually 'multiple methods tables' is a warning; AnnotationHub:::.require 
promotes the warning to an error.

Martin


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Sonali B Arora 
[sar...@fredhutch.org]
Sent: Monday, December 21, 2015 3:08 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Rsamtools/AnnotationHub Error for FaFile - multiple 
methods tables found for ‘relistToClass’

Hi everyone,

I am trying to get a FaFile from AnnotationHub - It fails with the
following error

library(AnnotationHub)
ah =AnnotationHub()
ah = query(ah , c("Homo sapiens", "org", "GRCH37", "FASTA","75"))
hg37_rna = ah[["AH10879"]]

 > hg37_rna = ah[["AH10879"]]
require(“Rsamtools”)
Error: failed to load 'AnnotationHub' resource
   name: AH10879
   title: Homo_sapiens.GRCh37.75.ncrna.fa
   reason: require(“Rsamtools”) failed: multiple methods tables found
for ‘relistToClass’


 > sessionInfo()
R Under development (unstable) (2015-10-15 r69519)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.2 LTS

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] stats4parallel  stats graphics  grDevices utils datasets
[8] methods   base

other attached packages:
[1] GenomeInfoDb_1.7.3  IRanges_2.5.18  S4Vectors_0.9.15
[4] AnnotationHub_2.3.6 BiocGenerics_0.17.2

loaded via a namespace (and not attached):
  [1] Rcpp_0.12.2  AnnotationDbi_1.33.3
  [3] magrittr_1.5 zlibbioc_1.17.0
  [5] xtable_1.8-0 R6_2.1.1
  [7] stringr_1.0.0httr_1.0.0
  [9] tools_3.3.0  Biobase_2.31.3
[11] DBI_0.3.1htmltools_0.2.6
[13] digest_0.6.8 interactiveDisplayBase_1.9.0
[15] shiny_0.12.2 curl_0.9.4
[17] RSQLite_1.0.0mime_0.4
[19] stringi_1.0-1BiocInstaller_1.21.2
[21] httpuv_1.3.3


--
Thanks and Regards,
Sonali
Office: C2-169
http://tinyurl.com/sonali-hb-calendar

___
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

Re: [Bioc-devel] Rsamtools/AnnotationHub Error for FaFile - multiple methods tables found for ‘relistToClass’

[Morgan, Martin]

Great! Just re-installing the packages via biocLite() would have been 
sufficient. Martin

From: Sonali B Arora [sar...@fredhutch.org]
Sent: Monday, December 21, 2015 4:56 PM
To: Morgan, Martin; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Rsamtools/AnnotationHub Error for FaFile - multiple 
methods tables found for ‘relistToClass’

Hi Martin,

Thanks for the quick explanation. I got the latest version of the
packages mentioned below from svn - and installed them using Herve's
HTS core package stack
(http://www.bioconductor.org/help/newsletters/2015_October/#hts-core-package-stack)
and I don't see the problem any more.

 > library(AnnotationHub)
 > ah =AnnotationHub()
snapshotDate(): 2015-11-19
 > ah = query(ah , c("Homo sapiens", "org", "GRCH37", "FASTA","75"))
 > hg37_rrna = ah[["AH10879"]]
require(“Rsamtools”)
downloading from ‘https://annotationhub.bioconductor.org/fetch/10879’
 ‘https://annotationhub.bioconductor.org/fetch/14665’
retrieving 2 resources
|==|
100%
|==|
100%
There were 50 or more warnings (use warnings() to see the first 50)


Val, thanks for adding the stack to the newsletter !
FYI - I dont see it here -
http://www.bioconductor.org/packages/devel/bioc/html/S4Vectors.html
under the documentation section.

Thanks and Regards,
Sonali.


On 12/21/2015 1:33 PM, Morgan, Martin wrote:
> Hi Sonali --
>
> relistToClass was originally in IRanges
>
> Packages such as Biostrings that Depend: or Import: IRanges and then create a 
> 'relistToClass' method created a methods table on INSTALLATION, noting that 
> the generic is in IRanges.
>
> The 'relistToClass' generic was moved from IRanges to S4Vectors, with 
> appropriate version bumps for these packages.
>
> Loading the 'old' version of Biostrings (library(Biostrings)) now sees a new 
> generic in S4Vectors, but has the old methods table that thinks the methods 
> are being added to the IRanges generic.
>
> This results in the warning "multiple methods tables found for 
> ‘relistToClass’".
>
> The end-user solution is to re-install the Biostrings package 
> (biocLite("Biostrings")). This will use the correct methods table.
>
> Any package that defines a method on relistToClass requires updating; there 
> are similar problems with 'space' and 'unlist'. I believe the 'core' packages 
> requiring updating (defining methods, but svn revision older than r111605) 
> include c("GenomicRanges", "rtracklayer", "GenomicAlignments", "Biostrings", 
> "BSgenome", "VariantAnnotation").
>
> Please let me know if the problem continues after re-installing these 
> packages.
>
> I have bumped the versions of each of these packages, so that biocLite() 
> after tomorrow-ish should force these to be re-installed.
>
> Usually 'multiple methods tables' is a warning; AnnotationHub:::.require 
> promotes the warning to an error.
>
> Martin
>
> 
> From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Sonali B 
> Arora [sar...@fredhutch.org]
> Sent: Monday, December 21, 2015 3:08 PM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] Rsamtools/AnnotationHub Error for FaFile - multiple 
> methods tables found for ‘relistToClass’
>
> Hi everyone,
>
> I am trying to get a FaFile from AnnotationHub - It fails with the
> following error
>
> library(AnnotationHub)
> ah =AnnotationHub()
> ah = query(ah , c("Homo sapiens", "org", "GRCH37", "FASTA","75"))
> hg37_rna = ah[["AH10879"]]
>
>   > hg37_rna = ah[["AH10879"]]
> require(“Rsamtools”)
> Error: failed to load 'AnnotationHub' resource
> name: AH10879
> title: Homo_sapiens.GRCh37.75.ncrna.fa
> reason: require(“Rsamtools”) failed: multiple methods tables found
> for ‘relistToClass’
>
>
>   > sessionInfo()
> R Under development (unstable) (2015-10-15 r69519)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.2 LTS
>
> 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] stats4parallel  stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages

Re: [Bioc-devel] as.table not available for HitsList anymore?

[Morgan, Martin]

Hi Nico -- Hervé is on vacation until early January. My minimal example 
'works', so I wonder if this is a conflict with another package (does 
S4Vectors::as.table(ovl) work?) or a unique feature of your HitsList? 
traceback() output after the error might help. Martin

> library(S4Vectors)
> as.table(split(Hits(1:2, 1:2, 2, 2), 1:2))
range
1 2 3 4 
1 0 0 1 
> methods(as.table)
[1] as.table,ANY-method  as.table.default as.table.ftable*
[4] as.table,HitsList-method as.table,Hits-method
see '?methods' for accessing help and source code
> sessionInfo()
R Under development (unstable) (2015-12-19 r69790)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.3 LTS

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] parallel  stats4stats graphics  grDevices utils datasets 
[8] methods   base 

other attached packages:
[1] S4Vectors_0.9.15 BiocGenerics_0.17.2  BiocInstaller_1.21.2

loaded via a namespace (and not attached):
[1] IRanges_2.5.18 tools_3.3.0   



From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Nicolas 
Delhomme [nicolas.delho...@umu.se]
Sent: Sunday, December 20, 2015 3:10 AM
To: Bioc-devel@r-project.org
Subject: [Bioc-devel] as.table not available for HitsList anymore?

Hej Hervé (I guess that ones for you :-)!

In R dev / Bioc 3.3; calling as.table on an HitsList stopped working:

Browse[2]> ovl
HitsList of length 6
names(6): chr2L chr2R chr3L chr3R chr4 chrX
Browse[2]> as.table(ovl)
Error during wrapup: cannot coerce to a table

I suppose this may have to do with the refactoring of the IRanges/S4Vectors 
packages? Will the functionality be re-instated, or should I switch my code to 
using as.matrix instead?

My session info:

R Under development (unstable) (2015-12-15 r69777)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.11.2 (El Capitan)

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

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

other attached packages:
[1] RnaSeqTutorial_0.9.0 easyRNASeq_2.7.2

loaded via a namespace (and not attached):
 [1] RColorBrewer_1.1-2  futile.logger_1.4.1
 [3] GenomeInfoDb_1.7.3  XVector_0.11.1
 [5] futile.options_1.0.0bitops_1.0-6
 [7] tools_3.3.0 zlibbioc_1.17.0
 [9] biomaRt_2.27.2  annotate_1.49.0
[11] RSQLite_1.0.0   lattice_0.20-33
[13] DBI_0.3.1   parallel_3.3.0
[15] DESeq_1.23.0genefilter_1.53.0
[17] hwriter_1.3.2   Biostrings_2.39.3
[19] S4Vectors_0.9.15IRanges_2.5.18
[21] locfit_1.5-9.1  stats4_3.3.0
[23] grid_3.3.0  LSD_3.0
[25] Biobase_2.31.3  AnnotationDbi_1.33.3
[27] XML_3.98-1.3survival_2.38-3
[29] BiocParallel_1.5.1  limma_3.27.6
[31] latticeExtra_0.6-26 geneplotter_1.49.0
[33] lambda.r_1.1.7  edgeR_3.13.4
[35] intervals_0.15.1Rsamtools_1.23.1
[37] genomeIntervals_1.27.0  splines_3.3.0
[39] BiocGenerics_0.17.2 GenomicAlignments_1.7.3
[41] GenomicRanges_1.23.7ShortRead_1.29.1
[43] SummarizedExperiment_1.1.11 xtable_1.8-0
[45] RCurl_1.95-4.7

Thanks!

Nico

PS Have a good Christmas time!

---
Nicolas Delhomme, PhD

Acting Manager
UPSC bioinformatics core facility
Umeå Plant Science Center,
Swedish University for Agricultural
Sciences (SLU) and Umeå University

Tel: +46 90 786 5478
Email: nicolas.delho...@umu.se
SLU - Umeå universitet
Umeå S-901 87 Sweden
---

___
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

Re: [Bioc-devel] ggplot2 2.0.0 export Position now, conflict with BiocGeneric::Position?

[Morgan, Martin]

You are right that BiocGenerics creates and exports a generic Position.

I think you are right that the warning is coming from DESeq2, which 
imports(BiocGenerics) and imports(ggplot2).

The solution is for the DESeq2 author to do as you did, importFrom() 
selectively, or continue to declare Imports: in the DESCRIPTION file but use 
ggplot2::Position, etc., in the R code.

I am confident that this will be cleaned up by the DESeq2 author in the near 
future; there are a number of other problems likely to be introduced by ggplot2 
changes in other Bioconductor packages.

Martin


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Lo 
[lorena.pant...@gmail.com]
Sent: Saturday, December 19, 2015 12:35 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] ggplot2 2.0.0 export Position now, conflict with 
BiocGeneric::Position?

Hi all,

maybe this is so stupid, I just updated to R 3.3 and all packages,
including gglot2 (2.0.0, two days ago).

I noticed ggplot2 now export Positions, and I think BiocGenerics as well
has that?

Now I having problems with my package that is under review in the
package builder with this warning:

Warning: replacing previous import by ‘ggplot2::Position’ when loading
‘DESeq2’

I import DESeq2 and DESeq2 import ggplot2. I was importing as well
ggplot2, so I was seeing this warning twice. I had to use importFrom to
fix it. Now I only see the warnings once.

Could someone try to replicate?

I just updated ggplot2 to 2.0.0 in R3.3 and installed devel version of
DESeq2, and I get the warning. I guess any package importing ggplot2
should do the same.

I just want to know if it is some stupid thing I am doing, or this will
start happening always n the future?

sorry if it was stupid.

thanks

___
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

Re: [Bioc-devel] ggplot2 2.0.0 export Position now, conflict with BiocGeneric::Position?

[Morgan, Martin]

Also for what it's worth the most recent R-devel reports more informatively:

4: replacing previous import 'BiocGenerics::Position' by 'ggplot2::Position' 
when loading 'DESeq2' 

Thanks to this commit:

~/src/R-devel$ svn log -r69783

r69783 | ripley | 2015-12-19 03:24:12 -0500 (Sat, 19 Dec 2015) | 1 line

do not report identical re-imports otherwise report where they are from


Martin


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Morgan, Martin 
[martin.mor...@roswellpark.org]
Sent: Saturday, December 19, 2015 2:02 PM
To: Lo; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] ggplot2 2.0.0 export Position now, conflict with 
BiocGeneric::Position?

You are right that BiocGenerics creates and exports a generic Position.

I think you are right that the warning is coming from DESeq2, which 
imports(BiocGenerics) and imports(ggplot2).

The solution is for the DESeq2 author to do as you did, importFrom() 
selectively, or continue to declare Imports: in the DESCRIPTION file but use 
ggplot2::Position, etc., in the R code.

I am confident that this will be cleaned up by the DESeq2 author in the near 
future; there are a number of other problems likely to be introduced by ggplot2 
changes in other Bioconductor packages.

Martin


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Lo 
[lorena.pant...@gmail.com]
Sent: Saturday, December 19, 2015 12:35 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] ggplot2 2.0.0 export Position now, conflict with 
BiocGeneric::Position?

Hi all,

maybe this is so stupid, I just updated to R 3.3 and all packages,
including gglot2 (2.0.0, two days ago).

I noticed ggplot2 now export Positions, and I think BiocGenerics as well
has that?

Now I having problems with my package that is under review in the
package builder with this warning:

Warning: replacing previous import by ‘ggplot2::Position’ when loading
‘DESeq2’

I import DESeq2 and DESeq2 import ggplot2. I was importing as well
ggplot2, so I was seeing this warning twice. I had to use importFrom to
fix it. Now I only see the warnings once.

Could someone try to replicate?

I just updated ggplot2 to 2.0.0 in R3.3 and installed devel version of
DESeq2, and I get the warning. I guess any package importing ggplot2
should do the same.

I just want to know if it is some stupid thing I am doing, or this will
start happening always n the future?

sorry if it was stupid.

thanks

___
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

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

Re: [Bioc-devel] mapIds methods for ExpressionSet and SummarizedExperiment

[Morgan, Martin]

Hi Ludwig --

It would be really great to see what you've put together; can you make your 
code available somewhere, maybe via github?

I think the facilities already in Bioconductor include:

- select() and the OrganismDb (e.g., Homo.sapiens) packages

- (Recently introduced, in bioc-devel) GenomicFeatures::mapIds()

- GSEABase mapIdentifiers()

- The AnnotationFuncs package (some of this functionality might be redundant 
with select() / mapIds(); maybe your idea is a more refined version of this?

- biomaRt, including the relatively under-known use of select() with mart 
objects.

I think a particularly valuable development (initial implementation in 
GenomicFeatures::mapIds()) is transparent mapping to / from genomic ranges.

The original intention of the annotation() slot in ExpressionSet was to include 
the microarray chip identifier, so that one references this when translating 
from probeset to gene identifiers.

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Ludwig 
Geistlinger [ludwig.geistlin...@bio.ifi.lmu.de]
Sent: Thursday, December 17, 2015 5:05 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] mapIds methods for ExpressionSet and  
SummarizedExperiment

Dear Bioc Team,

I have implemented mapIds methods mapping featureNames (ExpressionSet) and
rownames (SummarizedExperiment) between major gene ID types such as
ENSEMBL and ENTREZ by passing that on AnnotationDbi::mapIds.

Given an ExpressionSet/SummarizedExperiment and an organism under
investigation such as 'Homo sapiens', the methods are checking whether the
corresponding org.db package is available, otherwise the package is
automatically installed and loaded.
Subsequently, the featureNames/rownames are mapped from the specified
from.id.type to the desired to.id.type, corresponding to keytypes of the
org.db package.
Options to deal with NA and duplicate mappings are also provided in order
to ensure that featureNames/rownames are unique after the mapping.

Advantage is that end users do not require knowledge of the Bioc
annotation infrastructure, but rather just need to provide the organism
under investigation in a convenient format also for non-Biocs.

I have not found something similar in existing packages and I am wondering
whether this could be something of general interest.

Best,
Ludwig

--
Dipl.-Bioinf. Ludwig Geistlinger

Lehr- und Forschungseinheit für Bioinformatik
Institut für Informatik
Ludwig-Maximilians-Universität München
Amalienstrasse 17, 2. Stock, Büro A201
80333 München

Tel.: 089-2180-4067
eMail: ludwig.geistlin...@bio.ifi.lmu.de

___
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

Re: [Bioc-devel] mapIds methods for ExpressionSet and SummarizedExperiment

[Morgan, Martin]

Oops, those newly added functions in GenomicFeatures are

GenomicFeatures::mapRangesToIds
GenomicFeatures::mapIdsToRanges

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Morgan, Martin 
[martin.mor...@roswellpark.org]
Sent: Friday, December 18, 2015 1:15 PM
To: Ludwig Geistlinger; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] mapIds methods for ExpressionSet  and 
SummarizedExperiment

Hi Ludwig --

It would be really great to see what you've put together; can you make your 
code available somewhere, maybe via github?

I think the facilities already in Bioconductor include:

- select() and the OrganismDb (e.g., Homo.sapiens) packages

- (Recently introduced, in bioc-devel) GenomicFeatures::mapIds()

- GSEABase mapIdentifiers()

- The AnnotationFuncs package (some of this functionality might be redundant 
with select() / mapIds(); maybe your idea is a more refined version of this?

- biomaRt, including the relatively under-known use of select() with mart 
objects.

I think a particularly valuable development (initial implementation in 
GenomicFeatures::mapIds()) is transparent mapping to / from genomic ranges.

The original intention of the annotation() slot in ExpressionSet was to include 
the microarray chip identifier, so that one references this when translating 
from probeset to gene identifiers.

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Ludwig 
Geistlinger [ludwig.geistlin...@bio.ifi.lmu.de]
Sent: Thursday, December 17, 2015 5:05 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] mapIds methods for ExpressionSet and  
SummarizedExperiment

Dear Bioc Team,

I have implemented mapIds methods mapping featureNames (ExpressionSet) and
rownames (SummarizedExperiment) between major gene ID types such as
ENSEMBL and ENTREZ by passing that on AnnotationDbi::mapIds.

Given an ExpressionSet/SummarizedExperiment and an organism under
investigation such as 'Homo sapiens', the methods are checking whether the
corresponding org.db package is available, otherwise the package is
automatically installed and loaded.
Subsequently, the featureNames/rownames are mapped from the specified
from.id.type to the desired to.id.type, corresponding to keytypes of the
org.db package.
Options to deal with NA and duplicate mappings are also provided in order
to ensure that featureNames/rownames are unique after the mapping.

Advantage is that end users do not require knowledge of the Bioc
annotation infrastructure, but rather just need to provide the organism
under investigation in a convenient format also for non-Biocs.

I have not found something similar in existing packages and I am wondering
whether this could be something of general interest.

Best,
Ludwig

--
Dipl.-Bioinf. Ludwig Geistlinger

Lehr- und Forschungseinheit für Bioinformatik
Institut für Informatik
Ludwig-Maximilians-Universität München
Amalienstrasse 17, 2. Stock, Büro A201
80333 München

Tel.: 089-2180-4067
eMail: ludwig.geistlin...@bio.ifi.lmu.de

___
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


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

Re: [Bioc-devel] R CMD SHLIB throwing error on zin1 (linux) BioC nightly build

[Morgan, Martin]

At least for the R package side of things, I think the question of how to 
invoke R CMD in a Makefile is moot for AnalysisPageServer -- remove the 
Makefile, and the shared object is created automatically when the package is 
built with R CMD build AnalysisPageServer.

But for the record the format for referring to R in Writing R Extensions in a 
Makefile is

"${R_HOME}/bin/R" ...

${R_HOME} is an environment variable, quotes allow for spaces in the path. A 
more cross-platform version is  I think

"${R_HOME}/bin${R_ARCH_BIN}/R"

where on single-architecture platforms ${R_ARCH_BIN} is undefined hence 
harmless.

Somewhat circularly, R_HOME is set by R CMD

$ env|grep R_HOME
$ R CMD env|grep R_HOME
R_HOME=/home/mtmorgan/bin/R-devel
$ Rrel CMD env|grep R_HOME
R_HOME=/home/mtmorgan/bin/R-3-2-branch


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Dan Tenenbaum 
[dtene...@fredhutch.org]
Sent: Monday, December 14, 2015 4:06 PM
To: Brad Friedman
Cc: bioc-devel
Subject: Re: [Bioc-devel] R CMD SHLIB throwing error on zin1 (linux)BioC
nightly build

- Original Message -
> From: "Brad Friedman" 
> To: "bioc-devel" 
> Sent: Monday, December 14, 2015 1:01:24 PM
> Subject: [Bioc-devel] R CMD SHLIB throwing error on zin1 (linux) BioC nightly 
> build

> I’m getting an error that R cannot be found on the nightly build server.
> Obviously it can be found at some point, since R CMD build started, but at
> the moment of calling R CMD SHLIB it can’t be found again.
>
> I was wondering if anything had changed on the server, or maybe I’m doing
> my Makefile wrong.


Probably both. We made a change, removing R from the PATH on the linux and 
windows machines (on Mac R is in /usr/bin so it's a bad idea to remove that 
directory from the PATH) because we realized that there are packages that fail 
when R is not in the PATH, and one can't assume that R will always be in the 
path, so we wanted to make sure those packages failed so that we'd find the 
problems. That seems to be what is happening in your case.

I'm not sure what the exact syntax is, but your makefile should reference R as 
$R_HOME/bin/R.

Dan


> The error only happens on the linux server: mac (oaxaca)
> and windows (moscato1) build fine. And I can’t reproduce this on my local
> linux server with a fresh checkout.
>
> Nightly build
> 
> results:
>
> ##
> ##
> ###
> ### Running command:
> ###
> ###   /home/biocbuild/bbs-3.2-bioc/R/bin/R CMD build --keep-empty-dirs
> --no-resave-data AnalysisPageServer
> ###
> ##
> ##
>
> * checking for file ‘AnalysisPageServer/DESCRIPTION’ ... OK
> * preparing ‘AnalysisPageServer’:
> * checking DESCRIPTION meta-information ... OK
> * cleaning src
> * installing the package to build vignettes
>  ---
> * installing *source* package ‘AnalysisPageServer’ ...
> ** libs
> ** arch -
> R CMD SHLIB AnalysisPageSVG.cpp tinyxml2.cpp cor.cpp catch.c
> SearchReplace2.cpp R_init_AnalysisPageServer.cpp -o
> AnalysisPageServer.so
> /bin/bash: R: command not found
> make: *** [AnalysisPageServer] Error 127
> ERROR: compilation failed for package ‘AnalysisPageServer’
> * removing ‘/tmp/RtmpREgK1P/Rinst3e5828c9cd0f/AnalysisPageServer’
>  ---
> ERROR: package installation failed
>
> and the contents of src/Makefile:
>
> AnalysisPageServer: AnalysisPageSVG.cpp tinyxml2.cpp cor.cpp
> AnalysisPageSVG.h tinyxml2.h cor.h catch.c SearchReplace2.cpp
> SearchReplace2.h catch.h
>R CMD SHLIB AnalysisPageSVG.cpp tinyxml2.cpp cor.cpp catch.c
> SearchReplace2.cpp R_init_AnalysisPageServer.cpp -o
> AnalysisPageServer.so
> clean:
>rm *.o *.so
>
>
>
>   [[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

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.

Re: [Bioc-devel] [Rd] For integer vectors, `as(x, "numeric")` has no effect.

[Morgan, Martin]

>From the Bioconductor side of things, the general feeling is that this is a 
>step in the right direction and worth the broken packages. Martin Morgan

From: R-devel [r-devel-boun...@r-project.org] on behalf of Martin Maechler 
[maech...@stat.math.ethz.ch]
Sent: Friday, December 11, 2015 4:25 AM
To: John Chambers; r-de...@r-project.org; bioc-devel list; Benjamin Tyner
Cc: Martin Maechler
Subject: Re: [Rd] For integer vectors, `as(x, "numeric")` has no effect.

> Martin Maechler 
> on Tue, 8 Dec 2015 15:25:21 +0100 writes:

> John Chambers 
> on Mon, 7 Dec 2015 16:05:59 -0800 writes:

>> We do need an explicit method here, I think.
>> The issue is that as() uses methods for the generic function coerce() 
but cannot use inheritance in the usual way (if it did, you would be 
immediately back with no change, since "integer" inherits from "numeric").

>> Copying in the general method for coercing to "numeric" as an explicit 
method for "integer" gives the expected result:

>>> setMethod("coerce", c("integer", "numeric"), getMethod("coerce", 
c("ANY", "numeric")))
>> [1] "coerce"
>>> typeof(as(1L, "numeric"))
>> [1] "double"

>> Seems like a reasonable addition to the code, unless someone sees a 
problem.
>> John

> I guess that that some package checks (in CRAN + Bioc + ... -
> land) will break,
> but I still think we should add such a coercion to R.

> Martin

Hmm...  I've tried to add the above to R
and do notice that there are consequences that may be larger than
anticipated:

Here is example code:

   myN   <- setClass("myN",   contains="numeric")
   myNid <- setClass("myNid", contains="numeric", 
representation(id="character"))
   NN <-setClass("NN", representation(x="numeric"))

   (m1 <- myN  (1:3))
   (m2 <- myNid(1:3, id = "i3"))
   tools::assertError(NN (1:3))# in all R versions

   ## # current R  |  new R
   ## # ---|--
   class(getDataPart(m1)) # integer|  numeric
   class(getDataPart(m2)) # integer|  numeric


In other words, with the above setting, the traditional
gentleperson's agreement in S and R,

  __ "numeric" sometimes conveniently means "integer" or "double"  __

will be slightly less often used ... which of course may be a
very good thing.

However, it breaks strict back compatibility also in cases where
the previous behavior may have been preferable:
After all integer vectors need only have the space of doubles.

Shall we still go ahead and do apply this change to R-devel
and then all package others will be willing to update where necessary?

As this may affect the many hundreds of bioconductor packages
using S4 classes, I am -- exceptionally -- cross posting to the
bioc-devel list.

Martin Maechler


>> On Dec 7, 2015, at 3:37 PM, Benjamin Tyner  wrote:

>>> Perhaps it is not that surprising, given that
>>>
>>> > mode(1L)
>>> [1] "numeric"
>>>
>>> and
>>>
>>> > is.numeric(1L)
>>> [1] TRUE
>>>
>>> On the other hand, this is curious, to say the least:
>>>
>>> > is.double(as(1L, "double"))
>>> [1] FALSE
>>>
 Here's the surprising behavior:

 x <- 1L
 xx <- as(x, "numeric")
 class(xx)
 ## [1] "integer"

 It occurs because the call to `as(x, "numeric")` dispatches the coerce
 S4 method for the signature `c("integer", "numeric")`, whose body is
 copied in below.

 function (from, to = "numeric", strict = TRUE)
 if (strict) {
 class(from) <- "numeric"
 from
 } else from

 This in turn does nothing, even when strict=TRUE, because that
 assignment to class "numeric" has no effect:

 x <- 10L
 class(x) <- "numeric"
 class(x)
 [1] "integer"

 Is this the desired behavior for `as(x, "numeric")`?
>>>
>>> __
>>> r-de...@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel

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

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

__
r-de...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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 

Re: [Bioc-devel] include .DollarNames.ExpressionSet in Biobase?

[Morgan, Martin]

Oops, I forgot to mention that I implemented this in devel, version 2.31.1. 
It's in SVN now and all being well via biocLite() on Saturday afternoon Eastern 
time.

From: Morgan, Martin
Sent: Friday, December 04, 2015 9:22 AM
To: Philipp Angerer; Bioc-devel
Subject: RE: [Bioc-devel] include .DollarNames.ExpressionSet in Biobase?

Hi Phillip --

es$foo accesses phenoData(es)$foo, so I implemented .DollarNames.eSet for this.

An ExpressionSet is rectangular and has two-dimensional subsettings, the core 
data is a matrix, and generally ExperessionSet behaves like a matrix. So rather 
than names() try colnames().

Thanks for the suggestion.

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Philipp 
Angerer [philipp.ange...@helmholtz-muenchen.de]
Sent: Friday, December 04, 2015 7:34 AM
To: Bioc-devel
Subject: [Bioc-devel] include .DollarNames.ExpressionSet in Biobase?

Hi,

the S3 generic .DollarNames is used to create tab completions in the R command
line and RStudio.

since you can access featureData(es)$feature via es$feature, it would be
useful to either implement .DollarNames.ExpressionSet or simply
names.ExpressionSet

I couldn’t find a bug tracker for BioConductor, so i posted this here.

Best, Philipp
Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

___
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

Re: [Bioc-devel] include .DollarNames.ExpressionSet in Biobase?

[Morgan, Martin]

Hi Phillip --

es$foo accesses phenoData(es)$foo, so I implemented .DollarNames.eSet for this.

An ExpressionSet is rectangular and has two-dimensional subsettings, the core 
data is a matrix, and generally ExperessionSet behaves like a matrix. So rather 
than names() try colnames().

Thanks for the suggestion.

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Philipp 
Angerer [philipp.ange...@helmholtz-muenchen.de]
Sent: Friday, December 04, 2015 7:34 AM
To: Bioc-devel
Subject: [Bioc-devel] include .DollarNames.ExpressionSet in Biobase?

Hi,

the S3 generic .DollarNames is used to create tab completions in the R command
line and RStudio.

since you can access featureData(es)$feature via es$feature, it would be
useful to either implement .DollarNames.ExpressionSet or simply
names.ExpressionSet

I couldn’t find a bug tracker for BioConductor, so i posted this here.

Best, Philipp
Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

___
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

Re: [Bioc-devel] Bioc twitter bot is on repeat

[Morgan, Martin]

I'm not saying that every one of us follow Bioc on twitter... ;)

From: Robert M. Flight [rfligh...@gmail.com]
Sent: Tuesday, November 24, 2015 6:51 PM
To: Morgan, Martin; Jim Hester; Michael Love
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Bioc twitter bot is on repeat

"Why wasnt fixed earlier" was one question, and those are perfectly good 
explanations, and also curiosity as to awareness that there was a problem. I 
apologize Martin if my question came across as judgemental as to why it wasn't 
fixed earlier, that was not my intent. The sheer amount of infrastructure the 
Bioconductor team keeps functioning is incredible, and I am very thankful for 
the work that goes into it.

Robert

On Tue, Nov 24, 2015, 6:43 PM Morgan, Martin 
<martin.mor...@roswellpark.org<mailto:martin.mor...@roswellpark.org>> wrote:
yes.

If the underlying question is 'why wasn't this fixed before' the answer is 
because no one had complained / there are more pressing things on the agenda / 
the pro from Dover able to fix this in their sleep (as opposed to working 
through unfamiliar code, thanks Jim!) is on vacation.

Martin

From: Bioc-devel 
[bioc-devel-boun...@r-project.org<mailto:bioc-devel-boun...@r-project.org>] on 
behalf of Robert M. Flight [rfligh...@gmail.com<mailto:rfligh...@gmail.com>]
Sent: Tuesday, November 24, 2015 6:39 PM
To: Jim Hester; Michael Love
Cc: bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>
Subject: Re: [Bioc-devel] Bioc twitter bot is on repeat

Curious, do any of the Bioconductor devs follow the Bioconductor twitter
account?

Robert

On Tue, Nov 24, 2015, 5:42 PM Jim Hester 
<james.f.hes...@gmail.com<mailto:james.f.hes...@gmail.com>> wrote:

> Thank you for bringing this to our attention.
>
> This should be fixed going forward and we apologize for the spam.
>
> Jim
>
> On Tue, Nov 24, 2015 at 4:13 PM, Michael Love 
> <michaelisaiahl...@gmail.com<mailto:michaelisaiahl...@gmail.com>
> >
> wrote:
>
> > best said by James Eddy:
> >
> > "Could someone please put out a new @Bioconductor package so
> @Bioconductor
> > stops tweeting about the same 3 every day?"
> >
> > https://twitter.com/jamesaeddy/status/668911442007949313
> >
> > https://twitter.com/Bioconductor
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org<mailto: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.


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

Re: [Bioc-devel] Behavior of select function in AnnotationDbi

[Morgan, Martin]

I would rather mapIds() continue to operate on a single column, return a named 
character vector, and by default provide a 1:1 relationship between input and 
output. multiVals=CharacterList does actually return a 1:many mapping in a way 
that retains parallel structure (I guess, maybe module limitations noted below 
and others).

Personally, I do not favor the message() associated with select(); select() is 
behaving as documented. A warning seems unnecessary -- "warning! I'm doing what 
I'm supposed to do!". If there is a message of some sort, I'd rather it was 
consistently presenting information. I also like message() _because_ it's 
presented when the issue arises, rather than out of context, maybe for the same 
reasons I find top-posting in email responses [sic] so irritating. If the 
documented behavior of select() is fundamentally unsatisfactory, then yes we 
should change the documented behavior rather than emitting warnings.

select() could be updated to accept the equivalent of the multiVals argument. 
select() could also be updated to always return a DataFrame or to return a 
DataFrame when multiVals is specified, though one does like a function to 
return a consistent data type. The original choice to use data.frame was from 
informal observation that the classes enabled by DataFrame (e.g., 
CharacterList) pose problems for less-experienced [by this I mean a broad swath 
of Bioc] users, and the annotation resources should be as accessible as 
possible.

I see no benefit in NOT ordering the return values in the same order as the 
input keys. Likewise, I see no value in dropping support for duplicate or NA 
keys.

I view both of the following treatments of NA in mapIds() as bugs; they should 
return named character vectors mapping  to NA.

> mapIds(org.Hs.eg.db, c("BRCA1", NA), "ENTREZID", "SYMBOL")
'select()' returned 1:1 mapping between keys and columns
$BRCA1
[1] "672"

$
NULL
> mapIds(org.Hs.eg.db, NA_character_, "ENTREZID", "SYMBOL")
Error in .testForValidKeys(x, keys, keytype, fks) : 
  None of the keys entered are valid keys for 'SYMBOL'. Please use the keys 
method to see a listing of valid arguments.

Reporting mapping when mapIds() is invoked, with or without the multiVals= 
argument, also seems unnecessary.

> mapIds(org.Hs.eg.db, "BRCA1", "GO", "SYMBOL", multiVals="first")
'select()' returned 1:many mapping between keys and columns
   BRCA1 
"GO:151" 

Martin


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of James W. 
MacDonald [jmac...@uw.edu]
Sent: Monday, November 23, 2015 11:16 AM
To: Hervé Pagès
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Behavior of select function in AnnotationDbi

Hi Hervé,

Hmmm. Persuasive arguments. I like it!

I'm pretty close to thinking you are right about this. However there is one
small stumbling block. While select() allows for the look up of multiple
columns simultaneously, mapIds() does not. But I do like your idea of
having a function that guarantees parallelism, so let's consider this.

It wouldn't take much to convert mapIds() to accept multiple columns, and
it would be reasonable to keep the default of using the first of duplicate
returned values. This makes more sense for some annotations (RefSeq), than
others (GO), but whatever. In that case it would return a data.frame, just
like select() does now, but with a guarantee of parallelism with the input.
That's easy enough to do. It would often not be a good idea for an end user
to do that, but again we have to let people fail if they refuse to even
consider what they are doing.

But this brings up a pretty interesting option, for those who don't want to
get rid of the ambiguity inherent in getting multiple mappings returned, or
who really should be getting those multiple things back (e.g., GO). It
might be a smarter play to change the default returned object from a
vector, where we have naively taken the first item returned, and instead
return a CharacterList. For multiple input columns, we would then return a
DataFrame. We still have 1:1 mapping of inputs to rows of the output, but
now we allow multiple values per column. There are lots of things people
can do with that while within R, so that by itself is pretty useful, plus
we haven't done anything that might be unwise.

Does that seem reasonable? It's sort of a big change to the output for both
select() and mapIds(), so it might be a good idea (as you suggested) to
have some sort of warning for the next release, telling end users that
things have changed, and they should take note.

Jim



On Sun, Nov 22, 2015 at 7:07 AM, Hervé Pagès  wrote:

> Hi Jim,
>
> I understand the convenience of having an output that is parallel to
> the input, especially in the context of the primary use case which is
> mapping/cbinding ids to a rectangular object. However for that use
> case, "as close to parallel as possible" is not good enough. IMO the
> user needs 

Re: [Bioc-devel] Is there a way to change the name of R package that is already published on bioconductor?

[Morgan, Martin]

Marcin -- I join with Herve in strongly discouraging you from this approach. 
Because you wish only to change upper versus lower case of your package name, 
and because some operating systems ignore case, your package will go through a 
release where it is not available under either upper- or lower-case variant. 
This will confuse and alienate your users, even more than changing the package 
name to something completely different. There are a number of packages, 
including some of our own, where the name could have been chosen more 
carefully, but we have learned to live with our changes of mind. After all, you 
can still claim to be consistent with the naming convention of the 
RTCGA.clinical and RTCGA.mutations package ;)

I guess Dario was referring to

  library(AnnotationHub)
  hub = AnnotationHub()
  eset = query(hub, "GSE62944")[[1]]

with

> eset
ExpressionSet (storageMode: lockedEnvironment)
assayData: 23368 features, 7706 samples 
  element names: exprs 
protocolData: none
phenoData
  sampleNames: TCGA-02-0047-01A-01R-1849-01
TCGA-02-0055-01A-01R-1849-01 ... TCGA-ZG-A8QZ-01A-11R-A37L-07 (7706
total)
  varLabels: bcr_patient_barcode bcr_patient_uuid ... CancerType (421
total)
  varMetadata: labelDescription
featureData: none
experimentData: use 'experimentData(object)'
Annotation:  
> table(eset$CancerType)

BLCA BRCA COAD  GBM HNSC KICH KIRC KIRP LAML  LGG LIHC LUAD LUSC   OV PRAD READ 
 273 1082  468  170  481   66  540  226  164  528  212  514  490  344  423  164 
SKCM STAD THCA UCEC 
 373  146  506  536 
> print(object.size(eset), units="auto")
264.5 Mb
> ov = eset[, eset$CancerType == "OV"]   ## ovarian samples

The data are Rsubread summarized counts from before the May update. In the near 
term, we are actively expanding offerings derived from that GSE to include the 
May update; this is in conjunction with efforts to develop an 'ExperimentHub' 
analog of AnnotationHub, for more experiment-centric, heavily curated resources.

It is a little unclear whether the AnnotationHub and your data are redundant or 
complementary, and whether they can be combined into a single offering. One 
philosophical difference is the use of semantically rich and integrated 
ExpressionSet versus basic data structures (data.frame, in your case). We also 
differ in when we separate data into cancer types; we opted for the entire data 
set because it is not impossibly large. And our data are AnnotationHub-based 
rather than package-based. Obviously, avoiding redundant access to the same 
data is beneficial. One possibility is to collaboratively curate the data into 
AnnotationHub / ExperimentHub resources, and to tailor access via packages that 
reference the resource (e.g., one can retrieve the GRASP2 data base through 
AnnotationHub as resource AH21414, or via grasp2db::GRASP2(); the latter comes 
with documentation for manipulating the resource).

It seems like there are similar opportunities for collaboration and reduced 
redundancy between the RTCGA, RTCGAToolbox, and TCGAbiolinks packages.

Martin Morgan
Bioconductor


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Marcin 
Kosiński [m.p.kosin...@gmail.com]
Sent: Sunday, November 22, 2015 11:37 AM
To: Dario Strbenac
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Is there a way to change the name of R package that 
is already published on bioconductor?

Hi Herve,

I think I would like to proceed with such technical possibility.
I'd like to keep consistency with the RTCGA.miRNASeq package that I am
uploading to bioconductor with issue 1335.
Can we schedule such operation?

Best,
Marcin



Hi Dario,

Do you want to tell me that there is a possibility to load RNASeq datasets
for all available 38 cancer types/cohorts from the last release date
(21-08-2015) of datasets from The Cancer Genome Atlas with the use of
AnnotationHub?

Is it as simple as:

library(AnnotationHub)
BRCA.RNASeq -> x

?

Best,
Marcin

2015-11-17 0:00 GMT+01:00 Dario Strbenac :

> Hello,
>
> How does your package differ to importing GSE62944 into R with
> AnnotationHub
> http://bioinformatics.oxfordjournals.org/content/31/22/3666.long ? It
> seems like unnecessary duplication.
>
> --
> 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


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 

Re: [Bioc-devel] PANTHER.db GOSLIM_ID hosed?

[Morgan, Martin]

>From the head of 

> PANTHER.db:::.keys
function (x, keytype) 
{
t2t <- .type2table(x)
t2c <- .type2col(x)
 
I wonder if many of the columns / keytypes are mislabeled, e.g.,

> PANTHER.db:::.type2col(PANTHER.db)
 CLASS_IDCLASS_TERM  COMPONENT_IDCOMPONENT_TERM 
  "family_id"   "goslim_id""ontology"  "uniprot_id" 
  CONFIDENCE_CODEENTREZ  EVIDENCE EVIDENCE_TYPE 
"species" "family_term"  "subfamily_term""class_id" 
FAMILY_ID   FAMILY_TERM GOSLIM_ID   GOSLIM_TERM 
 "class_term"   "go_id" "go_term" "component_go_id" 
   PATHWAY_ID  PATHWAY_TERM   SPECIESSUBFAMILY_TERM 
 "component_term""evidence"   "evidence_type" "confidence_code" 
  UNIPROT 
  "entrez_id" 

probably because columns() is used in .type2* but was changed at some point to 
return sorted values

> showMethods(PANTHER.db:::.type2col, includeDefs=TRUE)
Function: .type2col (package PANTHER.db)
x="PANTHER.db"
function (x) 
{
cls <- c("family_id", "goslim_id", "ontology", "uniprot_id", 
"species", "family_term", "subfamily_term", "class_id", 
"class_term", "go_id", "go_term", "component_go_id", 
"component_term", "evidence", "evidence_type", "confidence_code", 
"entrez_id")
names(cls) <- columns(x)
cls
}

> columns
nonstandardGenericFunction for "columns" defined from package "AnnotationDbi"

function (x) 
{
value <- standardGeneric("columns")
sort(value)
}

> selectMethod("columns", "PANTHER.db")
Method Definition:

function (x) 
{
c("FAMILY_ID", "GOSLIM_ID", "GOSLIM_TERM", "UNIPROT", "SPECIES", 
"FAMILY_TERM", "SUBFAMILY_TERM", "CLASS_ID", "CLASS_TERM", 
"PATHWAY_ID", "PATHWAY_TERM", "COMPONENT_ID", "COMPONENT_TERM", 
"EVIDENCE", "EVIDENCE_TYPE", "CONFIDENCE_CODE", "ENTREZ")
}

Probably a better design is to define a package-global constant

.TYPE2COLUMN = c(FAMILY_ID="family_id", GOSLIM_ID="goslim_id", ...)

and implement columns,PANTHER.db-method as names(.TYPE2COLUMN)

Martin Morgan

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Steve 
Lianoglou [lianoglou.st...@gene.com]
Sent: Friday, November 20, 2015 4:24 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] PANTHER.db GOSLIM_ID hosed?

Hi all,

I'm running the latest Bioc + PANTHER.db

I think we've got the GOSLIM_TERM where the GOSLIM_ID should be:

In the vignette, we have this:

R> go_ids <- head(keys(PANTHER.db,keytype="GOSLIM_ID"))
R> go_ids

## [1] "GO:003" "GO:165" "GO:166" "GO:228"
"GO:375" "GO:398"

But what we really get is:

R> head(keys(PANTHER.db,keytype="GOSLIM_ID"))

[1] "2-arachidonoylglycerol biosynthesis"
[2] "5-Hydroxytryptamine biosynthesis"
[3] "5-Hydroxytryptamine degredation"
[4] "5HT1 type receptor mediated signaling pathway"

R> packageVersion('PANTHER.db')
[1] '1.0.2'

Thanks,
-steve

___
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

Re: [Bioc-devel] Behavior of select function in AnnotationDbi

[Morgan, Martin]

I think the answer to 1 should be yes, duplicate keys are allowed. For 
instance, a vector of ids and a factor that groups the ids somehow (e.g., by 
experiment), with ids unique in each group.

So I'm for step #2.

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of James W. 
MacDonald [jmac...@uw.edu]
Sent: Friday, November 20, 2015 5:30 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Behavior of select function in AnnotationDbi

There is an inconsistency in how select() works in AnnotationDbi when a
user passes in duplicated keys to be mapped, depending on if the mapping is
1:1 or 1:many. It's easiest to show using an example.

> select(org.Hs.eg.db, rep("1", 3), "SYMBOL")
'select()' returned many:1 mapping between keys and columns
  ENTREZID SYMBOL
11   A1BG
21   A1BG
31   A1BG

> select(org.Hs.eg.db, rep("1", 3), "GO")
'select()' returned many:many mapping between keys and columns
  ENTREZID GO EVIDENCE ONTOLOGY
11 GO:0003674   ND   MF
21 GO:0003674   ND   MF
31 GO:0003674   ND   MF

This is obviously a bug. A single query for that ID results in this:

> select(org.Hs.eg.db, "1", "GO")
'select()' returned 1:many mapping between keys and columns
  ENTREZID GO EVIDENCE ONTOLOGY
11 GO:0003674   ND   MF
21 GO:0005576  IDA   CC
31 GO:0005615  IDA   CC
41 GO:0008150   ND   BP
51 GO:0070062  IDA   CC
61 GO:0072562  IDA   CC

So the returned results are completely borked.

However, the question I have is what should be returned? To be consistent
with the first example, it should be the output expected for a single key,
repeated three times, which I have patched AnnotationDbi to do:

> select(org.Hs.eg.db, rep("1", 3), "GO")
'select()' returned many:many mapping between keys and columns
   ENTREZID GO EVIDENCE ONTOLOGY
1 1 GO:0003674   ND   MF
2 1 GO:0005576  IDA   CC
3 1 GO:0005615  IDA   CC
4 1 GO:0008150   ND   BP
5 1 GO:0070062  IDA   CC
6 1 GO:0072562  IDA   CC
7 1 GO:0003674   ND   MF
8 1 GO:0005576  IDA   CC
9 1 GO:0005615  IDA   CC
101 GO:0008150   ND   BP
111 GO:0070062  IDA   CC
121 GO:0072562  IDA   CC
131 GO:0003674   ND   MF
141 GO:0005576  IDA   CC
151 GO:0005615  IDA   CC
161 GO:0008150   ND   BP
171 GO:0070062  IDA   CC
181 GO:0072562  IDA   CC

So, two questions.


   1. Should duplicate keys be allowed, or should duplicates be removed
   before querying the database, preferably with a message saying that dups
   were removed?
   2. If the answer to #1 is yes, then to be consistent, I will just commit
   the patch I have made to both devel and release.

Best,

Jim



--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099

[[alternative HTML version deleted]]

___
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

Re: [Bioc-devel] Troubles using R/Bioc-devel with Mac OS X El Capitan 10.11.1

[Morgan, Martin]

TARY=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] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] BiocInstaller_1.21.1

loaded via a namespace (and not attached):
[1] tools_3.3.0










> Dear Ludwig,
>
> I tried to install that package and it compiled nicely on my system with
>> sessionInfo()
> R Under development (unstable) (2015-10-20 r69547)
> Platform: x86_64-apple-darwin15.0.0/x86_64 (64-bit)
> Running under: OS X 10.11.2 (El Capitan)
>
> 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
>
> other attached packages:
> [1] BiocInstaller_1.21.1
>
> loaded via a namespace (and not attached):
> [1] tools_3.3.0
>
>
> I’m installing the fortran through homebrew, actually, fortran is part of
> the gcc “bottle” there, thus I installed
> brew install gcc
>
> and I’m building and compiling R always from source with:
>
> /configure SHELL='/bin/bash' \
>   --prefix=$PREFIX \
>   r_arch=x86_64 \
>   --x-includes=/usr/X11/include/ \
>   --x-libraries=/usr/X11/lib/ \
>   CC="clang" \
>   CXX="clang++" \
>   OBJC="clang" \
>   F77="gfortran -arch x86_64" \
>   FC="gfortran -arch x86_64" \
>   --with-system-zlib \
>   --with-blas='-framework Accelerate' \
>   --with-lapack \
>   CPPFLAGS="-D__ACCELERATE__  \
>   --enable-R-framework=no \
>   --enable-memory-profiling \
>   --enable-R-shlib
>
>
> I never had any problems anymore with missing fortran compilers on OS X
>
> Hope that helps,
>
> cheers, jo
>
>> On 18 Nov 2015, at 12:12, Morgan, Martin <martin.mor...@roswellpark.org>
>> wrote:
>>
>> Probably the definitive answer will be the R-SIG-Mac mailing list
>>
>>  https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>> perhaps specifically this thread
>>
>>  https://stat.ethz.ch/pipermail/r-sig-mac/2015-October/011641.html
>>
>> which points to the R-admin manual and especially
>>
>>  https://cran.r-project.org/doc/manuals/r-release/R-admin.html#OS-X
>>
>> From the discussion (especially the posts by Brian Ripley) it seems like
>> it should be possible to use gfortran-5.2 via editing the
>> R_HOME/etc/Makeconf or ~/.R/Makevars.
>>
>> Martin
>>
>>
>> 
>> From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Ludwig
>> Geistlinger [ludwig.geistlin...@bio.ifi.lmu.de]
>> Sent: Wednesday, November 18, 2015 5:53 AM
>> To: bioc-devel@r-project.org
>> Subject: [Bioc-devel] Troubles using R/Bioc-devel with Mac OS X El
>> Capitan  10.11.1
>>
>> Hi,
>>
>> I am experiencing troubles installing "Hmisc", especially its dependency
>> "acepack", via
>>
>>> biocLite("acepack")
>>
>> in R-devel installed from the "R-devel-mavericks-signed.pkg" downloaded
>> from https://r.research.att.com/.
>>
>> The error reads:
>>
>>
>> BioC_mirror: https://bioconductor.org
>> Using Bioconductor 3.3 (BiocInstaller 1.21.1), R Under development
>> (unstable)
>>  (2015-11-16 r69640).
>> Installing package(s) ‘acepack’
>> Paket, das nur als Quelltext vorliegt und eventuell Übersetzung von
>>  C/C++/Fortran benötigt.: ‘acepack’
>> Do you want to attempt to install these from sources?
>> y/n: y
>> installing the source package ‘acepack’
>>
>> versuche URL
>> 'https://cran.rstudio.com/src/contrib/acepack_1.3-3.3.tar.gz'
>> Content type 'application/x-gzip' length 33590 bytes (32 KB)
>> ==
>> downloaded 32 KB
>>
>> * installing *source* package ‘acepack’ ...
>> ** Paket ‘acepack’ erfolgreich entpackt und MD5 Summen überprüft
>> ** libs
>> gfortran-4.8   -fPIC  -g -O2  -c ace.f -o ace.o
>> make: gfortran-4.8: No such file or directory
>> make: *** [ace.o] Error 1
>> ERROR: compilation failed for package ‘acepack’
>> * removing
>> ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/acepack’
>>
>>
>> which indicates that "gfortran-4.8" is missing.
>> I have however installed the recommended "

Re: [Bioc-devel] Gviz: implementing support for FaFiles from AnnotationHub

[Morgan, Martin]

For what it's worth and from an earlier comment in this thread, one way to use 
git (for Johanne's benefit) within the context of svn (for Florian's benefit) 
is to svn co Gviz, then on top of svn create a new git repository branch and 
update at will, then merge changes to master and provide florian with svn diff. 
Something like

svn co https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/Gviz
cd Gviz/
git init 
git add .
git commit -a -m "initial commit"
git checkout -b my_mods
## amazing changes
git commit -a -m "my amazing changes"
git checkout master 
svn st# no changes
git merge my_mods 
svn st # my amazing changes
svn diff > Gviz.diff # ... as a diff for Florian


From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Rainer 
Johannes [johannes.rai...@eurac.edu]
Sent: Monday, November 09, 2015 10:08 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Gviz: implementing support for FaFiles from   
AnnotationHub

Dear All, dear Florian,

I’m currently working on a Gviz-hack that would enable to use the FaFiles 
provided from AnnotationHub directly as SequenceTracks in Gviz. I think that 
might be a nice addition, since that way both Ensembl based annotations (e.g. 
as EnsDbs) and Ensembl genome fasta files (provided by AnnotationHub) could be 
used.

So, Florian, eventually I’m going to send you some more files.

cheers, jo

___
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

Re: [Bioc-devel] Base class for interaction data - expressions of interest

[Morgan, Martin]

Just to say that this is a great idea. If this starts as a github package (or 
in svn, we can create a location for you if you'd like) I and others would I am 
sure be happy to try to provide any guidance / insight. The main design 
principles are probably to reuse as much as possible from existing classes, 
especially the S4Vectors / GRanges world, and to integrate metadata as 
appropriate (like SummarizedExepriment, for instance).

Martin

From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Aaron Lun 
[a...@wehi.edu.au]
Sent: Thursday, November 05, 2015 12:27 PM
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Base class for interaction data - expressions of  
interest

There's a growing number of Bioconductor packages dealing with
interaction data; diffHic, GenomicInteractions, HiTC, to name a few (and
probably more in the future). Each of these packages defines its own
class to store interaction data - DIList for diffHic,
GenomicInteractions for GenomicInteractions, and HTClist for HiTC.

These classes seem to share a lot of features, which suggests that they
can be (easily?) replaced with a common class. This would have two
advantages - one, developers of new and existing packages don't have to
continually write and maintain new classes; and two, it provides users
with a consistent user experience across the relevant packages.

My question is, does anybody have anything in the pipeline with respect
to a base package for an interaction class? If not, I'm planning to put
something together for the next BioC release. To this end, I'd welcome
any ideas/input/code; the aim is to make a drop-in replacement (insofar
as that's possible) for the existing classes in each package.

Cheers,

Aaron

___
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

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

Re: [Bioc-devel] upgrading

[Morgan, Martin]

Technically, prior to the release we were using R-3.2 for both release and 
devel. Only after the release did we 'support' R-devel, implying a new 
installation of BiocInstaller.

I guess you were using R-devel prior to the release and had an unsupported 
installation of BiocInstaller. Alternatively, you updated R over an existing 
library. Apparently at least one of these scenarios (probably the former) is 
somehow common amongst Bioc developers. I guess in general our approach has 
been to realize that there are many incorrect ways to skin a cat, and we cannot 
possibly anticipate all of them, so we will only support the approved way. 

Sorry for the frustration.

Martin

> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Kasper Daniel Hansen
> Sent: Tuesday, October 20, 2015 10:55 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] upgrading
> 
> So I have an R-devel where I have a previous (pre-bioc-3.2) installed version
> of BiocInstaller.
> 
> 1) I re-compile R-devel today.
> 2) I run
>   source("http://www.bioconductor.org/biocLite.R;)
> which gives me BiocInstaller 1.20.0.  However, the current one for Bioc-devel
> is 1.21.1.
> 
> When I try to push to a higher level version, by doing
>   library(BiocInstaller)
>   useDevel(TRUE)
> I get
> 
> > useDevel(TRUE)
> Error: 'devel' version requires a more recent R
> 
> If I now try to upgrade I get
> > biocLite("BiocUpgrade")
> Error: Bioconductor version 3.2 cannot be upgraded with R version 3.3.0
> 
> This all looks problematic.  How to I upgrade to Bioc-devel using R-devel?
> Btw. there are no instructions anymore at
>   https://www.bioconductor.org/developers/how-to/useDevel/
> 
> Best,
> Kasper
> 
>   [[alternative HTML version deleted]]
> 
> ___
> 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

Re: [Bioc-devel] readGAlignmentPairs with discordant strand

[Morgan, Martin]

Val and I discussed this a bit, with the resolution that calling the 
GAlignmentPairs() constructor on the first and the second element of the 
GAlignmentsList was the 'easiest' way to go.

  ga = unlist(gal[mcols(gal)$mate_status == "mated"])
  GAlignmentPairs(ga[c(TRUE, FALSE)], ga[c(FALSE, TRUE)])

(completely speculative code). If I understand correctly, there's a check in 
for discordant pairs in readGAlignmentPairs, but not in GAlignmentPairs itself; 
could be mistaken though...

Martin

From: Michael Lawrence [lawrence.mich...@gene.com]
Sent: Saturday, October 17, 2015 9:48 AM
To: Hervé Pagès
Cc: Michael Lawrence; Morgan, Martin; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] readGAlignmentPairs with discordant strand

This might have been lost in this thread. If there is an easy way to coerce a 
GAlignmentsList where all(lengths(x) == 2) to a GAlignmentPairs, please let me 
know. Otherwise, I'll add a coerce method. Debating whether it should discard 
elements of length != 2, or if it should fail.

On Fri, Oct 16, 2015 at 9:58 AM, Michael Lawrence 
<micha...@gene.com<mailto:micha...@gene.com>> wrote:
Sure, "*" makes more sense for strand, given the precedent.

On Fri, Oct 16, 2015 at 9:55 AM, Hervé Pagès 
<hpa...@fredhutch.org<mailto:hpa...@fredhutch.org>> wrote:
> On 10/16/2015 09:28 AM, Michael Lawrence wrote:
>>
>> I kind of wish it would return NA for things like seqnames and strand,
>> but yes that would be very useful.
>
>
> Could do this for seqnames() but I'm hesitant to do this for strand().
> If you look at ?strand in BiocGenerics, ‘*’ is used when the exact
> strand of the location is unknown, or irrelevant, or when the "feature"
> at that location belongs to both strands. A pair with discordant strand
> belongs to both strands. Also there is a lot of code around that
> assumes strand() never returns NAs.
>
>
> H.
>
>>
>> On Fri, Oct 16, 2015 at 9:15 AM, Hervé Pagès 
>> <hpa...@fredhutch.org<mailto:hpa...@fredhutch.org>> wrote:
>>>
>>> Hi Michael, Martin,
>>>
>>> On 10/16/2015 06:48 AM, Michael Lawrence wrote:
>>>>
>>>>
>>>> It does seem like starting with the more general data structure is the
>>>> better approach, but I couldn't find an easy way to move the paired
>>>> subset
>>>> of GAlignmentsList to GAlignmentPairs. You mention a coercion, but it's
>>>> not
>>>> obvious to me, unfortunately.
>>>>
>>>> Another approach would be a GAlignmentPairs where the unpaired reads
>>>> have
>>>> "missing" mates. I know GAlignments has no concept of missing, but it
>>>> would
>>>> get everything into a single data structure that is convenient for
>>>> computing on pairs.
>>>
>>>
>>>
>>> I could modify readGAlignmentPairs() to have the discordant and/or
>>> ambiguous pairs end up in th GAlignmentPairs. The ambiguous pairs
>>> could be marked as such thru a metadata col of the object or thru
>>> a proper slot. The seqnames() and strand() accessors will return
>>> * on discordant pairs. Does that sound reasonable?
>>>
>>> H.
>>>
>>>
>>>>
>>>> On Fri, Oct 16, 2015 at 5:21 AM, Morgan, Martin <
>>>> martin.mor...@roswellpark.org<mailto:martin.mor...@roswellpark.org>> wrote:
>>>>
>>>>>
>>>>>
>>>>>> -Original Message-
>>>>>> From: Bioc-devel 
>>>>>> [mailto:bioc-devel-boun...@r-project.org<mailto:bioc-devel-boun...@r-project.org>]
>>>>>>  On Behalf
>>>>>> Of
>>>>>> Michael Lawrence
>>>>>> Sent: Friday, October 16, 2015 7:41 AM
>>>>>> To: bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>
>>>>>> Subject: [Bioc-devel] readGAlignmentPairs with discordant strand
>>>>>>
>>>>>> Now that GAlignmentPairs supports discordant strand between mates, how
>>>>>> hard would it be to relax that restriction on readGAlignmentPairs()?
>>>>>>
>>>>>> Also, would be nice if getDumpedAlignments() returned those dumped by
>>>>>> readGAlignmentPairs(). Right now, I'm reading a GAlignments (with the
>>>>>
>>>>>
>>>>> extra
>>>>>>
>>>>>>
>>>>>> mcols) and calling makeGAlignmentPairs(). Not so convenient.
>>>>>
>>>>

Re: [Bioc-devel] ideas for ScanBamParam filters

[Morgan, Martin]

> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Michael Lawrence
> Sent: Friday, October 16, 2015 7:56 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] ideas for ScanBamParam filters
> 
> Maybe I just missed these, but these are a couple of things we could filter
> by, in addition to what's there already:
> 
> - Minimum MAPQ
> - Read group

see tagFilter and mapqFilter args to ScanBamParam. I don't know how heavily 
used these are so bugs welcome.

Martin

> 
> The first is mostly for convenience, but the second should also benefit
> performance.
> 
> I can help implement this, but wanted to make sure this is a reasonable
> approach.
> 
> Michael
> 
>   [[alternative HTML version deleted]]
> 
> ___
> 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

Re: [Bioc-devel] readGAlignmentPairs with discordant strand

[Morgan, Martin]

> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Michael Lawrence
> Sent: Friday, October 16, 2015 7:41 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] readGAlignmentPairs with discordant strand
> 
> Now that GAlignmentPairs supports discordant strand between mates, how
> hard would it be to relax that restriction on readGAlignmentPairs()?
> 
> Also, would be nice if getDumpedAlignments() returned those dumped by
> readGAlignmentPairs(). Right now, I'm reading a GAlignments (with the extra
> mcols) and calling makeGAlignmentPairs(). Not so convenient.

I'm not sure whether this is relevant to your use case but readGAlignmentsList 
returns a list of paired mates, and if appropriate (based on ScanBamParam) list 
elements with solo travelers. The paired portion of the list can be coerced to 
GAlignmentPairs if the additional structure of that class is required.

Martin

>   
> Michael
> 
>   [[alternative HTML version deleted]]
> 
> ___
> 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

Re: [Bioc-devel] SV4Vectors installation problem

[Morgan, Martin]

> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Marcin Cieslik
> Sent: Thursday, October 15, 2015 7:46 AM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] SV4Vectors installation problem
> 
> Dear Bioconductors,
> 
> Somewhere in August S4Vectors stopped installing correctly resulting in a:
> 
> Creating a generic function for ‘nchar’ from package ‘base’ in package
> ‘S4Vectors’
> 
> message (that cannot be suppressed) each time the package is loaded. The
> issue is not fixed by a fresh reinstall of bioconductor. The first hint of the

you're right that this is a message and that it cannot be suppressed, but the 
package still functions correctly, right?

The problem was introduced by a change in R. The above is a work-around. The 
permanent solution is now to use the current version of R (3.2.2) and Bioc 
(3.2). The specific commit was


r106498 | mtmor...@fhcrc.org | 2015-07-16 15:10:40 -0400 (Thu, 16 Jul 2015) | 5 
lines

define nchar,Rle-method in .onLoad

- work-around consequences of changed base::nchar signature for
  3.2.1 binary builds used in 3.2.0



some related / belated discussion is at

https://stat.ethz.ch/pipermail/r-devel/2015-October/071841.html

Martin


> problem appears during installation
> 
> http://pastebin.com/UpKdeNTH
> 
> It appears I am not the only one affected a search reveals many instances:
> 
> e.g.
> https://rpubs.com/Pazz/advanced_annotation
> http://bioc.ism.ac.jp/packages/checkResults/3.1/bioc-
> LATEST/S4Vectors/petty-install.html
> http://biocluster.ucr.edu/~rkaundal/R_sep2015/Rrnaseq/RNAseq.html
> 
> Thanks a lot for your work! If needed I can provide  a Docker image that
> reproduces the problem.
> 
> Yours,
> Marcin
> 
>   [[alternative HTML version deleted]]
> 
> ___
> 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

Re: [Bioc-devel] A method for combining SummarizedExperiment objects

[Morgan, Martin]

Hi Pete -- looks like a good idea. 

I think the generic could be adjusted to pass named (not x, y) args to methods, 
rather than trying (incorrectly) to combine them. I don't think the 
inefficiency of recursion is a particular concern, because it is not like 
hundreds (or even tens) of objects are typically being combined.

combine() takes the approach of implementing methods for each component -- so I 
guess DataFrame, GRanges, GRangesList, SimpleList (for the assays, which are 
matrix, which are already combine()-able). 

Any interest in re-implementing your code along these lines (as methods on the 
building blocks)? Some guidance might come from selectMethod("combine", 
c("data.frame", "data.frame")).

FWIW -- 

stop(paste0()) is just stop(), which accepts multiple arguments and pastes them 
together without a separator. 

x@NAMES is names(), as in names(GRanges("chr1", IRanges(1, 10, names="A")))

?elementMetadata says "Alternatives to 'mcols' functions. Their [i.e., 
elementMetadata] use is discouraged."


> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Peter Hickey
> Sent: Wednesday, October 14, 2015 9:52 PM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] A method for combining SummarizedExperiment
> objects
> 
> I often find myself with multiple `SE` objects (I'm using `SE` as a shorthand 
> for
> the `SummarizedExperiment0` and `RangedSummarizedExeriment` classes),
> each with different samples but possibly non-overlapping features/ranges.
> Currently, it is difficult to combine these objects;  `rbind()` can only 
> combine
> objects with the same samples but different features/ranges and `cbind()`
> can only combine objects with the same features/ranges but different
> samples. I think it would be useful to have a "combine" method for `SE`
> objects that handles the situation where each object has different samples
> but with possibly non-overlapping features/ranges.
> 
> I've written a first pass at a method to do this at
> https://gist.github.com/PeteHaitch/8993b096cfa7ccd08c13.
> Is this a method other people find themselves in need of and, if so, might we
> add something like this to the SummarizedExperiment package? As noted in
> the gist, there's a few things I'd like to address to make it more robust and
> complete (probably some optimisations too).
> 
> Cheers,
> Pete
> 
>   [[alternative HTML version deleted]]
> 
> ___
> 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

Re: [Bioc-devel] error in stable AnnotationHub

[Morgan, Martin]

> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Kasper Daniel Hansen
> Sent: Saturday, October 10, 2015 11:04 PM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] error in stable AnnotationHub
> 
> Using Bioconductor 3.1 and the following code
> 
> library(AnnotationHub)
> ah <- AnnotationHub()
> ah[["AH28868"]]
> 
> I get an error like

It seems like the record is expecting additional columns in the bed file, but 
it contains only ranges and score; spot checking on the hotspot.broad.bed files 
suggests that they all have this format. Will address, but in the mean time a 
workaround is

  rtracklayer::import(cache(ah["AH28868"]), format="bed", genome="hg19")

Martin

> 
> retrieving 1 resources
> 
> |=
> =|
> 100%
> Error in value[[3L]](cond) :
>   failed to load hub resource ‘E003-DNase.hotspot.broad.bed.gz’ of class
> EpigenomeRoadmapFile; reason: length of 'chrom' greater than length
> of 'ranges'
> In addition: There were 50 or more warnings (use warnings() to see the first
> 50)
> 
> Best,
> Kasper
> 
>   [[alternative HTML version deleted]]
> 
> ___
> 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

Re: [Bioc-devel] Shouldn't we distinguish between package-specific and dependency errors?]

[Morgan, Martin]

> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Michael Lawrence
> Sent: Thursday, September 24, 2015 2:51 PM
> To: Ludwig Geistlinger
> Cc: bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Shouldn't we distinguish between package-specific
> and dependency errors?]
> 
> The important question is whether the package actually works, as
> distributed. if not, it's a user matter. If a build is failing because there 
> is a
> problem with the "next" version of the package, or something specific to the
> build machine, it's a developer/admin matter. I'm guessing we don't
> routinely test packages without version bumps, but perhaps we should, at
> least when their deps change. Maybe certain packages that depend on
> external resources could be tested on a regular but less frequent basis,
> regardless.

Packages are built and checked nightly, regardless of version bump. Only 
version bumps (and successful build / check) trigger a push to the public bioc 
repository. The build errors that Ludwig is concerned about typically are the 
result of these nightly builds catching incompatible changes in other packages.

In these cases the bioc packages that _are_ available via biocLite() (because 
they built before the incompatible change) are no longer valid; it seems it is 
particularly important to alert the user, including users who have already 
installed the bioc package, that there are problems. It is not possible to 
'role back' the Bioc package (because there is no guarantee that the older 
version worked, and because R installs newer versions, not older versions). In 
terms of our hypothetical reviewer, the shield accurately conveys the situation 
they would experience if they were to install the software.

It might be helpful to remember that the shields on the release and devel pages 
are independent of one another -- the carnage of a bad check-in of a new 
feature (in devel, of course!) is not reflected on the release landing pages.

Roughly, I view the top line of shields as particularly useful to users; the 
second line is more developer oriented but still conveying relevant information 
to our more ardent users. In both cases I think the shields do a good job of 
making problems more apparent to the community in general, and hence contribute 
to better overall software.

There are 'best practices' that package developers can follow to mitigate the 
consequences of API changes in their package, especially following a strict 
deprecation cycle; the separation of 'release' and 'devel' versions of 
Bioconductor facilitate this. Likewise, package developers have a 
responsibility to their users to convey problems 'upstream' to be fixed at the 
source.

Bioconductor does have a more dense dependency graph than CRAN. Generally I 
think this is good, reflecting valuable software re-use rather than 
re-invention; the release / devel split also makes this approach viable when 
the dependencies are within Bioconductor. It is unfortunate when a domain 
specific package offers some functionality that is more generally useful, 
introducing a cascade of more-or-less irrelevant dependencies. In these cases 
it may well be worth-while to re-factor or identify the generally useful 
functionality into a new or different package, e.g., implementing or using 
rtracklayer::import(). If there are candidates for such re-factoring then the 
Bioc-devel mailing list is an appropriate venue for discussion.

Martin

> 
> 
> On Thu, Sep 24, 2015 at 11:19 AM, Ludwig Geistlinger <
> ludwig.geistlin...@bio.ifi.lmu.de> wrote:
> 
> > Dan, thanks for clarifying.
> > With 'we can hardly do much about it', I meant that we cannot prevent
> > that for external dependencies in the way we can prevent it for
> > dependendencies within Bioc.
> >
> > Question remains whether the landing page for the USER of the package
> > is the right place to alert the DEVELOPER of the package.
> >
> > Best,
> > Ludwig
> >
> >
> > - Original Message -
> > > From: "Ludwig Geistlinger" 
> > > To: "Dan Tenenbaum" 
> > > Sent: Thursday, September 24, 2015 10:52:29 AM
> > > Subject: Re: [Bioc-devel] Shouldn't we distinguish between
> > package-specific and dependency errors?
> > >
> > >
> > > Well, I guess, Dan, that basically means that breaking cannot happen
> > > within Bioc (as broken packages do not propagate to the repository)
> > > and such cases are exclusively due to breaking of external
> > > dependencies such as observed with KEGGREST and KEGG (where we
> can
> > > hardly do much about it).
> > >
> > >
> > > Thus, it remains to clarify on the purpose of the ‚build‘ shield
> > > as Wolfgang pointed out.
> > > While it is surely helpful for the developer to grasp what is going
> > > on at a glance, this might be misleading for users and reviewers as
> > > described earlier.
> > >
> > >
> >
> > The purpose of the build shield is to 

Re: [Bioc-devel] AnnotationHub: cleanup

[Morgan, Martin]

Hi Kasper -- we'll try to act on these, but some comments / looking for 
clarification...

> -Original Message-
> From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of
> Kasper Daniel Hansen
> Sent: Monday, September 14, 2015 10:45 PM
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] AnnotationHub: cleanup
> 
> I currently have the `pleasure` of dealing with students who have problems
> with installing AnnotationHub and/or downloading resources.  Here are some
> comments including some possible bug reports.

I hope this is on the whole a positive experience, and we'll do what we can to 
make it better.

> 
> 1) I think it is extremely dangerous that `cache(ahub)` starts by asking to
> download all resources!  May I suggest this only happens with a specific
> setting like `cache(ahub, download=TRUE)` or something similar.

> 
> 2) `cache(ahub)` deletes all cached information, except the sqlite database.
> Could we get a way to remove everything?
> 
> 3) While I can understand the difference between cache and hubCache, I
> would suggest that hubCache(ahub) = NULL removes all cached material
> included the sqlite database.

For each of the above the envisioned use case was that  'hub' is a subset, eg.,

  subhub = query(hub, c("homo", "ensembl", "81"))

and the user wanted to manipulate all records in the sub-hub. cache(subhub) 
asks about the 'really download" if the size of the (sub)hub is greater than 
hubOption("MAX_DOWNLOADS"), which by default is 10; it seems like asking is the 
same as requiring an argument? fileName(subhub) may be closer to what you're 
looking for...? the path to the file name, or NA if It is not in the cache.

For cache(subhub) = NULL it wouldn't make sense to delete 5 resources AND the 
sqlite file for the entire hub.

The sqlite file can be discovered with dbfile(hub) / dbfile(subhub), and 
removed with file.remove(dbfile(subhub))). In some ways it wasn't envisioned 
that this manual manipulation would be a common use case (!).

> 
> 4) It seems that AnnotationHub in the release version of Bioconductor
> defaults to using https://.  Wasn't full support for https:// introduced in R
> 3.2.2; if so, it seems to be a critical bug that it is using https://

AnnotationHub uses httr::GET and ultimately curl::curl_fetch_disk rather than 
native R support, so what R does is not directly relevant. From ?curl

 Drop-in replacement for base 'url' that supports https, ftps,
 gzip, deflate, etc. Default behavior is identical to 'url', but
 request can be fully configured by passing a custom 'handle'.

So I wonder what the actual problem is?

> 5) Perhaps it should be considered that the default hubCache path is
> versioned, perhaps with Bioc version, perhaps with something else.  This
> might cause problems for people running multiple versions of R.

The data base is supposed to handle versioning, so if you've populated the 
cache with Bioc 3.2 and are now accessing the cache with Bioc 3.1, only the 3.1 
resources are visible. The hope was to avoid multiple copies of these possibly 
large resources.

> 6) I strongly suggest that the output printed when retrieving an
> AnnotationHub resource includes the download url.

Ok something that's easy to do! Sometimes this will be cryptic (when the 
resource is cached in the AnnotationHub server, rather than being retrieved 
from the original source)

> 7) If you run AnnotationHub without having GenomicRanges / rtracklayer
> installed, it downloads the resource and then pangs out with an error.  To me
> it seems more natural to pang out with an error immediately, especially since
> when it works, it appears from message printing that loading the library
> happens prior to download.

I guess by 'run AnnotationHub' you mean retrieve a specific resource?

The import recipes generally start by require()ing the necessary libraries. I 
spotted a couple of recipes that didn't follow this convention (for 2bit and 
chain file resources from rtracklayer; none that involved GenomicRanges). Are 
there specific examples?

Martin

> 
> Best,
> Kasper
> 
>   [[alternative HTML version deleted]]
> 
> ___
> 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