date:20160921

Re: [Bioc-devel] Updating author/maintainer info

2016-09-21 Thread Hervé Pagès


Hi Kylie,

It seems that we somehow forgot to grant you write access to your
CardinalWorkflows package. This should work now. Please try again.

Sorry for the inconvenience,
H.

On 09/21/2016 07:16 PM, Kyle Dwayne Bemis wrote:

Hello,

My personal information has changed and I need to update my author/maintainer 
name and email address on my packages.

For Cardinal, this is easy, but CardinalWorkflows is a data package, so I 
cannot update it myself. How can I update the data package info?

Besides subscribing to the mailing list on my new institution's email address, 
is there anything else I need to do?

Thank you,
Kylie

~~~
Kylie Ariel Bemis
Future Faculty Fellow
College of Computer and Information Science
Northeastern University

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



--
Hervé Pagès

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

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

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

Re: [Bioc-devel] Updating author/maintainer info

2016-09-21 Thread Monther Alhamdoosh

Did you add --username xxx --password  to the svn co command?

On Thu, Sep 22, 2016 at 1:42 PM, Bemis, Kylie 
wrote:

> Thanks, but when I follow the directions, it doesn’t work:
>
> svn: E175013: Commit failed (details follow):
> svn: E175013: Unable to connect to a repository at URL '
> https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/
> pkgs/CardinalWorkflows'
> svn: E175013: Access to 'https://hedgehog.fhcrc.org/
> bioc-data/trunk/experiment/pkgs/CardinalWorkflows' forbidden
>
> Kylie
>
> ~~~
> Kylie Ariel Bemis
> Future Faculty Fellow
> College of Computer and Information Science
> Northeastern University
>
>
>
>
>
> On Sep 21, 2016, at 10:37 PM, Monther Alhamdoosh  > wrote:
>
> Hi Kyle,
>
> See the Experiment Data Packages section here
>
> https://bioconductor.org/developers/how-to/source-control/
>
> Cheers,
> Monther
>
>
> On Thu, Sep 22, 2016 at 12:16 PM, Kyle Dwayne Bemis  > wrote:
> Hello,
>
> My personal information has changed and I need to update my
> author/maintainer name and email address on my packages.
>
> For Cardinal, this is easy, but CardinalWorkflows is a data package, so I
> cannot update it myself. How can I update the data package info?
>
> Besides subscribing to the mailing list on my new institution's email
> address, is there anything else I need to do?
>
> Thank you,
> Kylie
>
> ~~~
> Kylie Ariel Bemis
> Future Faculty Fellow
> College of Computer and Information Science
> Northeastern University
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Updating author/maintainer info

2016-09-21 Thread Bemis, Kylie

Thanks, but when I follow the directions, it doesn’t work:

svn: E175013: Commit failed (details follow):
svn: E175013: Unable to connect to a repository at URL 
'https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/CardinalWorkflows'
svn: E175013: Access to 
'https://hedgehog.fhcrc.org/bioc-data/trunk/experiment/pkgs/CardinalWorkflows' 
forbidden

Kylie

~~~
Kylie Ariel Bemis
Future Faculty Fellow
College of Computer and Information Science
Northeastern University





On Sep 21, 2016, at 10:37 PM, Monther Alhamdoosh 
> wrote:

Hi Kyle,

See the Experiment Data Packages section here

https://bioconductor.org/developers/how-to/source-control/

Cheers,
Monther


On Thu, Sep 22, 2016 at 12:16 PM, Kyle Dwayne Bemis 
> wrote:
Hello,

My personal information has changed and I need to update my author/maintainer 
name and email address on my packages.

For Cardinal, this is easy, but CardinalWorkflows is a data package, so I 
cannot update it myself. How can I update the data package info?

Besides subscribing to the mailing list on my new institution's email address, 
is there anything else I need to do?

Thank you,
Kylie

~~~
Kylie Ariel Bemis
Future Faculty Fellow
College of Computer and Information Science
Northeastern University

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



[[alternative HTML version deleted]]

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

[Bioc-devel] Updating author/maintainer info

2016-09-21 Thread Kyle Dwayne Bemis

Hello,

My personal information has changed and I need to update my author/maintainer 
name and email address on my packages.

For Cardinal, this is easy, but CardinalWorkflows is a data package, so I 
cannot update it myself. How can I update the data package info?

Besides subscribing to the mailing list on my new institution's email address, 
is there anything else I need to do?

Thank you,
Kylie

~~~
Kylie Ariel Bemis
Future Faculty Fellow
College of Computer and Information Science
Northeastern University

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

Re: [Bioc-devel] New package deadline for this release: 26 September

2016-09-21 Thread Chen Hao

Dear Martin and core members,

We have a package named uSORT submitted to Bioconductor through GitHub half a 
month ago, FYI


 *   Github Link: 
 *   Bioconductor submission track: 


Now the checking report shows one warning, which is caused by the no DISPLAY 
variable so Tk is not available on the linux platform. Our package includes a 
GUI which is built on tcltk. Can you help that how I can get around this 
warning?

Thanks a lot.

Best Regards,
Chen Hao

On 17 Sep 2016, at 3:14 AM, Martin Morgan 
> wrote:

Developers!

If you would like your new package to be included in the next release,
you must open an issue at

  https://github.com/Bioconductor/Contributions/

by 26 September. The full release schedule is at

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

Best wishes,

Martin Morgan
Bioconductor


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

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


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] lpsymphony - BiocParallel crash

2016-09-21 Thread Martin Morgan


On 09/21/2016 10:42 AM, Christian Arnold wrote:

Dear Bioconductor developers,


I am having a somewhat mysterious and challenging problem which we
believe is a bug in either (1) BiocParallel or (2) the lpsymphony
library from either Bioconductor or the SYMPHONY backend.


Thank you for the clear report

I think the problem is that lpsymphony is compiled by default to use 
openmp, and this parallelization environment interferes with the fork 
processes that BiocParallel::MulticoreParam() uses.


I was lead to this conclusion by using the 'gdb' debugger and 
interrupting R when it hung -- there were a number of openmp threads 
persisting, as in the abbreviated session below


$ Rdev -d gdb
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


...
(gdb) r
...
> source("lp.R", echo=T, max=Inf)## your script
> library(BiocParallel)
> library(lpsymphony)
> lpsymphonyTest <- function(x) {
+ ## Example from the R help of lpsymphony_solve_LP
+ obj <- c(2, 4, 3)
+ mat <- matrix(c(3, 2, 1, 4, 1, 3, 2, 2, 2), nrow = 3)
+ dir <- c("<=", "<=", "<=")
+ rhs <- c(60, 40, 80)
+ max <- TRUE
+ test = lpsymphony_solve_LP(obj, mat, dir, rhs, max = max)
+ Sys.sleep(1)
+ return(1)
+ }

> nIterationsAndCores = 2
> register(MulticoreParam(workers = nIterationsAndCores))
> ## register(bpstart(MulticoreParam(workers = nIterationsAndCores)))
>
> # First run: Two iterations, should run in parallel
> commonGenes <- bplapply(X = seq(2), FUN = lpsymphonyTest)
> # Second run: One iteration, should run on only one core
> commonGenes <- bplapply(X = seq(1), FUN = lpsymphonyTest)
[New Thread 0x7fffeb483700 (LWP 29894)]
[New Thread 0x7fffeac82700 (LWP 29895)]
[New Thread 0x7fffea481700 (LWP 29896)]
[New Thread 0x7fffe9c80700 (LWP 29897)]
[New Thread 0x7fffe947f700 (LWP 29898)]
[New Thread 0x7fffe8c7e700 (LWP 29899)]
[New Thread 0x7fffe847d700 (LWP 29900)]

> # Third run: Two iterations again, should run in parallel but crashed 
and never finishes

> commonGenes <- bplapply(X = seq(2), FUN = lpsymphonyTest)
^C
...
(gdb) info threads
  Id   Target Id Frame
* 1Thread 0x77fc97c0 (LWP 29865) "R" 0x75a91d13 in 
select () at ../sysdeps/unix/syscall-template.S:84
  2Thread 0x7fffeb483700 (LWP 29894) "R" 0x75f8cb4f in ?? 
() from /usr/lib/x86_64-linux-gnu/libgomp.so.1
  3Thread 0x7fffeac82700 (LWP 29895) "R" 0x75f8cb4f in ?? 
() from /usr/lib/x86_64-linux-gnu/libgomp.so.1
  4Thread 0x7fffea481700 (LWP 29896) "R" 0x75f8cb4f in ?? 
() from /usr/lib/x86_64-linux-gnu/libgomp.so.1
  5Thread 0x7fffe9c80700 (LWP 29897) "R" 0x75f8cb4f in ?? 
() from /usr/lib/x86_64-linux-gnu/libgomp.so.1
  6Thread 0x7fffe947f700 (LWP 29898) "R" 0x75f8cb4f in ?? 
() from /usr/lib/x86_64-linux-gnu/libgomp.so.1
  7Thread 0x7fffe8c7e700 (LWP 29899) "R" 0x75f8cb4f in ?? 
() from /usr/lib/x86_64-linux-gnu/libgomp.so.1
  8Thread 0x7fffe847d700 (LWP 29900) "R" 0x75f8cb4f in ?? 
() from /usr/lib/x86_64-linux-gnu/libgomp.so.1



I compiled lpsymphony without openmp by changing the top-level 
lpsymphony/configure file to explicitly exclude openmp


$ svn diff lpsymphony/configure
Index: lpsymphony/configure
===
--- lpsymphony/configure(revision 121222)
+++ lpsymphony/configure(working copy)
@@ -123,6 +123,7 @@
 else
(cd src/SYMPHONY && \
./configure \
+   --enable-openmp=no \
--enable-static --disable-shared --with-pic \
--with-application=no --disable-dependency-tracking \
--disable-zlib --disable-bzlib \

and then installing with R CMD INSTALL lpsymphony. Your test script then 
succeeded; providing weak verification that openmp was the problem.


There are several things.

1. since SYMPHONY is already using openmp, and it is a sophisticated 
piece of software, probably there is little value to using BiocParallel 
on top of it?


2. It seems that one can use SnowParam() effectively; this requires 
modifying lpsymphonyTest() to require(lpsymphony)


lpsymphonyTest <- function(x) {
## Example from the R help of lpsymphony_solve_LP
require(lpsymphony)
...

The cost of starting the independent processes can be amortized across a 
session by starting them manually at the beginning (and stopping them at 
the end)


param = bpstart(SnowParam(workers = nIterationsAndCores))
register(param)
...
bpstop(param)

3. It would be good if the maintainer of lpsymphony exposed the 
enable-openmp (and other?) flags so that one could R CMD INSTALL 
--configure-args="--enable-openmp=no" lpsymphony


4. I'll work to come up with a simpler example and see if I can make 
BiocParallel robust to use of openmp; this might be challenging for me.


Hope that

[Bioc-devel] Package pages: Link to NEWS gone?

2016-09-21 Thread Henrik Bengtsson

I've noticed this for a while and thought it was a temporary glitch,
or maybe I missed some announcement about it, but it appears that NEWS
files are no longed listed on the Bioc package pages, e.g.
https://bioconductor.org/packages/devel/bioc/html/Biobase.html.  A
mistake?

/Henrik

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

Re: [Bioc-devel] msPurity build fail on Mac OS X (morelia)

2016-09-21 Thread Kasper Daniel Hansen

So this seems like a bug in mzR which is the main backend / parser for
proteomics and metabolomics data.  Someone should try to fix this.

Unfortunately, mzR depends on several pieces of software which are written
by other people, but bundled with the package.  Martin's traceback suggests
that some of these files are (partially?) encrypted.  This might be hard to
address.

Best,
Kasper

On Wed, Sep 21, 2016 at 12:43 PM, Dan Tenenbaum 
wrote:

> One thing I notice is that the crash does not happen every time. I have
> successfully built the package on morelia by hand with "R CMD build".
>
> Similarly I can source the stangled vignette without a crash sometimes.
> But when it does crash, this is what I see:
>
> > source("msPurity-vignette.R", echo=TRUE, max=Inf)
>
> > ## 
> 
> > library(msPurity)
> Loading required package: Rcpp
>
> > msmsPths <- list.files(system.file("extdata", "lcms", "mzML",
> package="msPurityData"), full.names = TRUE, pattern = "MSMS")
>
> > msPths <- list.files(system.file("extdata", "lcms", "mzML",
> package="msPurityData"), full.names = TRUE, pattern = "LCMS_")
>
> > ## 
> 
> > pa <- purityA(msmsPths)
>
>  *** caught segfault ***
> address 0x2980297, cause 'memory not mapped'
>
> Traceback:
>  1: .External(list(name = "CppMethod__invoke_notvoid", address =  0x7fb56861cb10>, dll = list(name = "Rcpp", path =
> "/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/libs/Rcpp.so",
>dynamicLookup = TRUE, handle = ,
>  info = ), numParameters = -1L),  0x7fb5686ae9c0>, , .pointer, ...)
>  2: object@backend$getPeakList(x)
>  3: FUN(X[[i]], ...)
>  4: lapply(X = X, FUN = FUN, ...)
>  5: sapply(scans, function(x) object@backend$getPeakList(x)$peaks,
>  simplify = FALSE)
>  6: sapply(scans, function(x) object@backend$getPeakList(x)$peaks,
>  simplify = FALSE)
>  7: .local(object, ...)
>  8: mzR::peaks(mr)
>  9: mzR::peaks(mr)
> 10: getscans(filepth)
> 11: assessPuritySingle(filepth = pa@fileList[[i]], mostIntense =
> mostIntense, nearest = nearest, offsets = offsets, plotP = plotP,
> plotdir = plotdir, interpol = interpol, iwNorm = iwNorm, iwNormFun =
> iwNormFun, ilim = ilim)
> 12: eval(expr, envir, enclos)
> 13: eval(xpr, envir = envir)
> 14: doTryCatch(return(expr), name, parentenv, handler)
> 15: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 16: tryCatchList(expr, classes, parentenv, handlers)
> 17: tryCatch(eval(xpr, envir = envir), error = function(e) e)
> 18: doTryCatch(return(expr), name, parentenv, handler)
> 19: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 20: tryCatchList(expr, classes, parentenv, handlers)
> 21: tryCatch({repeat {args <- nextElem(it)if
> (obj$verbose) {cat(sprintf("evaluation # %d:\n", i))
> print(args)}for (a in names(args)) assign(a, args[[a]], pos
> = envir, inherits = FALSE)r <- tryCatch(eval(xpr, envir
> = envir), error = function(e) e)if (obj$verbose) {
> cat("result of evaluating expression:\n")print(r)}
>   tryCatch(accumulator(list(r), i), error = function(e) {
> cat("error calling combine function:\n")print(e)
> NULL})i <- i + 1}}, error = function(e) {if
> (!identical(conditionMessage(e), "StopIteration"))
>  stop(simpleError(conditionMessage(e), expr))})
> 22: e$fun(obj, substitute(ex), parent.frame(), e$data)
> 23: operator(foreach::foreach(i = 1:length(pa@fileList), .packages =
> "mzR"), assessPuritySingle(filepth = pa@fileList[[i]], mostIntense =
> mostIntense, nearest = nearest, offsets = offsets, plotP = plotP,
>plotdir = plotdir, interpol = interpol, iwNorm = iwNorm,
>  iwNormFun = iwNormFun, ilim = ilim))
> 24: purityA(msmsPths)
> 25: eval(expr, envir, enclos)
> 26: eval(ei, envir)
> 27: withVisible(eval(ei, envir))
> 28: source("msPurity-vignette.R", echo = TRUE, max = Inf)
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> Selection:
>
> > sessionInfo()
> R version 3.3.1 (2016-06-21)
> Platform: x86_64-apple-darwin13.4.0 (64-bit)
> Running under: OS X 10.9.5 (Mavericks)
>
> 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] parallel  stats graphics  grDevices utils datasets  methods
> [8] base
>
> other attached packages:
> [1] xcms_1.49.6 Biobase_2.33.3  ProtGenerics_1.5.1
> [4] BiocGenerics_0.19.2 mzR_2.7.4   msPurity_0.99.6
> [7] Rcpp_0.12.7
>
> loaded via a namespace (and not attached):
>  [1] sapa_2.0-2 magrittr_1.5   ifultools_2.0-4
>  [4] MASS_7.3-45splines_3.3.1  BiocParallel_1.7.8
>  [7] lattice_0.20-34foreach_1.4.3

Re: [Bioc-devel] msPurity build fail on Mac OS X (morelia)

2016-09-21 Thread Dan Tenenbaum

One thing I notice is that the crash does not happen every time. I have 
successfully built the package on morelia by hand with "R CMD build".

Similarly I can source the stangled vignette without a crash sometimes. But 
when it does crash, this is what I see:

> source("msPurity-vignette.R", echo=TRUE, max=Inf)

> ## 
> library(msPurity)
Loading required package: Rcpp

> msmsPths <- list.files(system.file("extdata", "lcms", "mzML", 
> package="msPurityData"), full.names = TRUE, pattern = "MSMS")

> msPths <- list.files(system.file("extdata", "lcms", "mzML", 
> package="msPurityData"), full.names = TRUE, pattern = "LCMS_")

> ## 
> pa <- purityA(msmsPths)

 *** caught segfault ***
address 0x2980297, cause 'memory not mapped'

Traceback:
 1: .External(list(name = "CppMethod__invoke_notvoid", address = , dll = list(name = "Rcpp", path = 
"/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/libs/Rcpp.so",
 dynamicLookup = TRUE, handle = , info 
= ), numParameters = -1L), , 
, .pointer, ...)
 2: object@backend$getPeakList(x)
 3: FUN(X[[i]], ...)
 4: lapply(X = X, FUN = FUN, ...)
 5: sapply(scans, function(x) object@backend$getPeakList(x)$peaks, simplify 
= FALSE)
 6: sapply(scans, function(x) object@backend$getPeakList(x)$peaks, simplify 
= FALSE)
 7: .local(object, ...)
 8: mzR::peaks(mr)
 9: mzR::peaks(mr)
10: getscans(filepth)
11: assessPuritySingle(filepth = pa@fileList[[i]], mostIntense = mostIntense,   
  nearest = nearest, offsets = offsets, plotP = plotP, plotdir = plotdir, 
interpol = interpol, iwNorm = iwNorm, iwNormFun = iwNormFun, ilim = ilim)
12: eval(expr, envir, enclos)
13: eval(xpr, envir = envir)
14: doTryCatch(return(expr), name, parentenv, handler)
15: tryCatchOne(expr, names, parentenv, handlers[[1L]])
16: tryCatchList(expr, classes, parentenv, handlers)
17: tryCatch(eval(xpr, envir = envir), error = function(e) e)
18: doTryCatch(return(expr), name, parentenv, handler)
19: tryCatchOne(expr, names, parentenv, handlers[[1L]])
20: tryCatchList(expr, classes, parentenv, handlers)
21: tryCatch({repeat {args <- nextElem(it)if (obj$verbose) 
{cat(sprintf("evaluation # %d:\n", i))print(args)   
 }for (a in names(args)) assign(a, args[[a]], pos = envir, 
inherits = FALSE)r <- tryCatch(eval(xpr, envir = envir), error = 
function(e) e)if (obj$verbose) {cat("result of evaluating 
expression:\n")print(r)}
tryCatch(accumulator(list(r), i), error = function(e) {cat("error 
calling combine function:\n")print(e)NULL}) 
   i <- i + 1}}, error = function(e) {if 
(!identical(conditionMessage(e), "StopIteration")) 
stop(simpleError(conditionMessage(e), expr))})
22: e$fun(obj, substitute(ex), parent.frame(), e$data)
23: operator(foreach::foreach(i = 1:length(pa@fileList), .packages = "mzR"),
 assessPuritySingle(filepth = pa@fileList[[i]], mostIntense = mostIntense,  
   nearest = nearest, offsets = offsets, plotP = plotP, plotdir = 
plotdir, interpol = interpol, iwNorm = iwNorm, iwNormFun = iwNormFun, 
ilim = ilim))
24: purityA(msmsPths)
25: eval(expr, envir, enclos)
26: eval(ei, envir)
27: withVisible(eval(ei, envir))
28: source("msPurity-vignette.R", echo = TRUE, max = Inf)

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 

> sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.9.5 (Mavericks)

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

other attached packages:
[1] xcms_1.49.6 Biobase_2.33.3  ProtGenerics_1.5.1
[4] BiocGenerics_0.19.2 mzR_2.7.4   msPurity_0.99.6
[7] Rcpp_0.12.7

loaded via a namespace (and not attached):
 [1] sapa_2.0-2 magrittr_1.5   ifultools_2.0-4
 [4] MASS_7.3-45splines_3.3.1  BiocParallel_1.7.8
 [7] lattice_0.20-34foreach_1.4.3  splus2R_1.2-2
[10] stringr_1.1.0  fastcluster_1.1.21 plyr_1.8.4
[13] tools_3.3.1grid_3.3.1 snow_0.4-1
[16] iterators_1.0.8survival_2.39-5multtest_2.29.0
[19] doSNOW_1.0.14  Matrix_1.2-7.1 RColorBrewer_1.1-2
[22] reshape2_1.4.1 S4Vectors_0.11.16  codetools_0.2-14
[25] MassSpecWavelet_1.39.0 stringi_1.1.1  compiler_3.3.1
[28] stats4_3.3.1   RANN_2.5

- Original Message -
> From: "Thomas Lawson" 
> To: "Martin Morgan" 
> Cc:

Re: [Bioc-devel] msPurity build fail on Mac OS X (morelia)

2016-09-21 Thread Thomas Lawson

Thanks for reply. Some of those errors are a bit cryptic for me also.

I have not heard of the valgrind functionality before in R. I will test a
few things out with valgrind and hopefully I can pinpoint the error a bit
more.

Thanks again.

Tom

On Wed, Sep 21, 2016 at 12:50 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 09/20/2016 05:18 AM, Thomas Lawson wrote:
>
>> Hi BioConductor community,
>>
>> My package (msPurity) is passing the build on the Linux (*zin1*) and
>> Windows servers (*moscato1*) but failing on the Mac OS X server
>> (*morelia*).
>> Also I cannot seem to replicate the failure either on a local installation
>> of Mac OS X (el captain) or with Travis CI.
>>
>> I should probably note that for Travis CI I did have to install the
>> msPurityData dependency directly (without Bioconductor). See line 10
>> https://raw.githubusercontent.com/Viant-Metabolomics/msPurit
>> y/master/.travis.yml
>>
>> The error I think is coming from a function I have that uses the
>> mzR::peaks() function but I am struggling to see why I am getting the
>> error.
>>
>> Any help or suggestions would be really appreciated.
>>
>
> Hi Tom --
>
> This might be fun!
>
> You can see from
>
>
> http://bioconductor.org/checkResults/3.4/bioc-LATEST/morelia
> -R-instpkgs.html
>
> (linked from http://bioconductor.org/checkResults/3.4/bioc-LATEST/index.
> html '1633' installed packages) that in fact msPurityData is installed.
> Also, segfaults are rarely the result of missing packages. Instead, it is
> likely due to errors in C code of one sort or another. On my linux, I made
> sure I was using the 'devel' version of Bioconductor, and that all of my
> packages were up-to-date via biocLite(). I then checked out msPurity from
> svn, changed into the msPurity directory and installed it
>
> R CMD INSTALL .
>
> then I changed to the vignettes directory, Stangled the source code
>
>cd vignettes
>R CMD Stangle msPurity-vignette.Rmd
>
> (by the way, the products of build the package / vignette,
> msPurity-vignette.R should not be in svn).
>
> I then ran the vignette under valgrind
>
> msPurity/vignettes$ R -d valgrind -f msPurity-vignette.R
>
> leading to
>
> > pa <- purityA(msmsPths)
> ==19611== Mismatched free() / delete / delete []
> ==19611==at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_me
> mcheck-amd64-linux.so)
> ==19611==by 0x11296DA5: cRamp::cRamp(char const*, bool) (cramp.cpp:98)
> ==19611==by 0x1129FC87: RcppRamp::open(char const*, bool)
> (RcppRamp.cpp:23)
> ==19611==by 0x112B49C4: Rcpp::CppMethod2 bool>::operator()(RcppRamp*, SEXPREC**) (Module_generated_CppMethod.h:215)
> ==19611==by 0x112B0FBF: Rcpp::class_::invoke_void(SEXPREC*,
> SEXPREC*, SEXPREC**, int) (class.h:212)
> ==19611==by 0xED73CA0: CppMethod__invoke_void(SEXPREC*)
> (Module.cpp:200)
> ==19611==by 0x4F0DFD0: do_External (dotcode.c:548)
> ==19611==by 0x4F47F9E: Rf_eval (eval.c:713)
> ==19611==by 0x4F4A6B7: do_begin (eval.c:1807)
> ==19611==by 0x4F47D90: Rf_eval (eval.c:685)
> ==19611==by 0x4F4964C: Rf_applyClosure (eval.c:1135)
> ==19611==by 0x4F47B6C: Rf_eval (eval.c:732)
> ==19611==  Address 0x1b8a4220 is 0 bytes inside a block of size 400 alloc'd
> ==19611==at 0x4C2E0EF: operator new(unsigned long) (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==19611==by 0x11296949: cRamp::do_ramp(long, eWhatToRead)
> (cramp.cpp:215)
> ==19611==by 0x11296D9D: cRamp::cRamp(char const*, bool) (cramp.cpp:97)
> ==19611==by 0x1129FC87: RcppRamp::open(char const*, bool)
> (RcppRamp.cpp:23)
> ==19611==by 0x112B49C4: Rcpp::CppMethod2 bool>::operator()(RcppRamp*, SEXPREC**) (Module_generated_CppMethod.h:215)
> ==19611==by 0x112B0FBF: Rcpp::class_::invoke_void(SEXPREC*,
> SEXPREC*, SEXPREC**, int) (class.h:212)
> ==19611==by 0xED73CA0: CppMethod__invoke_void(SEXPREC*)
> (Module.cpp:200)
> ==19611==by 0x4F0DFD0: do_External (dotcode.c:548)
> ==19611==by 0x4F47F9E: Rf_eval (eval.c:713)
> ==19611==by 0x4F4A6B7: do_begin (eval.c:1807)
> ==19611==by 0x4F47D90: Rf_eval (eval.c:685)
> ==19611==by 0x4F4964C: Rf_applyClosure (eval.c:1135)
> ==19611==
>
> which from http://valgrind.org/docs/manual/mc-manual.html#mc-manual.rudefn
> means that memory allocated with new[] is being deallocated with free
> (rather than delete / delete[]
>
> Remarkably, this change to mzR removes this particular valgind problem
>
> Index: src/cramp.cpp
> ===
> --- src/cramp.cpp   (revision 121179)
> +++ src/cramp.cpp   (working copy)
> @@ -95,7 +95,7 @@
>  //  if (m_runInfo->m_data.scanCount < 0) { // undeclared scan
> count
>  // this will provoke reading of index, which sets scan count
>  rampScanInfo* tmp = getScanHeaderInfo ( 1 );
> -free(tmp);
> +delete(tmp);
>  // }
>  //

[Bioc-devel] lpsymphony - BiocParallel crash

2016-09-21 Thread Christian Arnold

Dear Bioconductor developers,


I am having a somewhat mysterious and challenging problem which we 
believe is a bug in either (1) BiocParallel or (2) the lpsymphony 
library from either Bioconductor or the SYMPHONY backend.

The problem is, in a nutshell, that R silently crashes or, to be more 
precise, never finishes the calculation when using the only function 
from lpsymphony in combination with BiocParallel.

We updated the latest version of lpsymphony last week, did not help. 
This can be reproduced with two different configurations, using 
different library versions of both BiocParallel and lpsymphony, 
respectively. We also tested this on two different machines (one of 
which runs R in the devel version, one does not; see the two 
sessionInfo() at the end of this message)


The following code can reproduce the problem:


/library(BiocParallel)/

/library(lpsymphony)/


/lpsymphonyTest <- function(x){/

/# Example from the R help of lpsymphony_solve_LP/

/obj <- c(2, 4, 3)/

/mat <- matrix(c(3, 2, 1, 4, 1, 3, 2, 2, 2), nrow = 3)/

/dir <- c("<=", "<=", "<=")/

/rhs <- c(60, 40, 80)/

/max <- TRUE/

/test = lpsymphony_solve_LP(obj, mat, dir, rhs, max = max)/

/Sys.sleep(1)/

/return(1)/

/}/


/# First run: Two iterations, should run in parallel/

/nIterationsAndCores = 2/

/register(MulticoreParam(workers = nIterationsAndCores))/

/commonGenes <- bplapply(X = seq(2), FUN = lpsymphonyTest) /


/# Second run: One iteration, should run on only one core/

/commonGenes <- bplapply(X = seq(1), FUN = lpsymphonyTest) /


/# Third run: Two iterations again, should run in parallel but crashed 
and never finishes/

/commonGenes <- bplapply(X = seq(2), FUN = lpsymphonyTest) /


What happens in our case is that the third run never finishes. The two R 
processes are in state “SLEEP” rather than running. Once you execute the 
bplapply loop for only one iteration, everything after with number of 
iterations > 1 crashes. It works fine for any number of iterations > 1 
despite of the order, but again, executing only a single iteration 
causes the problems afterwards. Note that using registering again for 
the second and third run does not help and yields the same behavior.



In fact, we have another issue, namely that the parallelization with 
BiocParallel in combination with the IHW package (which calls lpsymphony 
in the background) does not yield running times as expected but instead 
much, much longer ones. However, let's focus on this one first, because 
we think they might be related.


Thanks for your help,


Best

Christian




These are the two configurations where this problem can be reproduced:


(1)

/R Under development (unstable) (2016-06-30 r70858)/

//

/Platform: x86_64-pc-linux-gnu (64-bit)/

//

/Running under: Ubuntu 16.04.1 LTS/

//

/
/

//

/locale:/

//

/[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=de_DE.UTF-8 
LC_COLLATE=en_US.UTF-8 /

//

/[5] LC_MONETARY=de_DE.UTF-8 LC_MESSAGES=en_US.UTF-8 
LC_PAPER=de_DE.UTF-8 LC_NAME=C /

//

/[9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=de_DE.UTF-8 
LC_IDENTIFICATION=C /

//

/attached base packages:/

//

/[1] stats graphics grDevices utils datasets methods base /

//

/other attached packages:/

//

/[1] lpsymphony_1.1.2 BiocParallel_1.7.8/

//

/loaded via a namespace (and not attached):/

//

/[1] parallel_3.4.0 tools_3.4.0 /



(2)

/R version 3.3.1 (2016-06-21)/

//

/Platform: x86_64-pc-linux-gnu (64-bit)/

//

/Running under: CentOS release 6.5 (Final)/

//

/
//locale:/

//

/[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8 /

//

/[4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 
LC_MESSAGES=en_US.UTF-8 /

//

/[7] LC_PAPER=en_US.UTF-8 LC_NAME=C LC_ADDRESS=C /

//

/[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C /

//

/
//attached base packages:/

//

/[1] stats graphics grDevices utils datasets methods base /

//

/
//other attached packages:/

//

/[1] lpsymphony_1.0.2 BiocParallel_1.6.6/

//

/
//loaded via a namespace (and not attached):/

//

/[1] parallel_3.3.1 tools_3.3.1 /


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] github mirror and svn out of sync

2016-09-21 Thread Rainer Johannes

thanks Martin!

Now everything is in sync again. You're right, the git commits were commited as 
separate svn commits; an alternative would be to use `git-merge --squash`, but 
I didn't try that one; so far I used `git cherry-pick` to merge a selected 
range of git commits into the devel branch (which is in sync with BioC svn) as 
I did have nasty merge conflicts doing a `git merge master`.

jo


> On 21 Sep 2016, at 13:38, Martin Morgan  wrote:
> 
> On 09/21/2016 12:01 AM, Rainer Johannes wrote:
>> Dear all,
>> 
>> I recently observed that the svn and the github mirror of `ensembldb` is out 
>> of sync. Is this something specific to `ensembldb` or is this a general 
>> problem? Is there anything I could do to fix this?
>> 
> 
> I think it is up-to-date now? I think the problem is when several svn commits 
> occur in quick succession, and the second tries to sync the git repository 
> while the first is still working. I guess the common case is when you're 
> working on a git repo and merge it to svn in a way that retains the discrete 
> git commits as svn commits.
> 
> Each commit triggers this script
> 
>  https://github.com/Bioconductor/mirror/blob/master/update_git.py
> 
> and these lines (usually the second?) fail
> 
>  https://github.com/Bioconductor/mirror/blob/master/update_git.py#L87
>  https://github.com/Bioconductor/mirror/blob/master/update_git.py#L90
>  https://github.com/Bioconductor/mirror/blob/master/update_git.py#L93
> 
> leaving the local git repository in a condition that requires manual clean-up.
> 
> I guess this requires a more sophisticated implementation, where the svn 
> commit adds a task to a time-ordered queue, and the queue waits until each 
> previous step has been complete.
> 
> Martin
> 
>> thanks, 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] msPurity build fail on Mac OS X (morelia)

2016-09-21 Thread Martin Morgan

On 09/20/2016 05:18 AM, Thomas Lawson wrote:

Hi BioConductor community,

My package (msPurity) is passing the build on the Linux (*zin1*) and
Windows servers (*moscato1*) but failing on the Mac OS X server (*morelia*).
Also I cannot seem to replicate the failure either on a local installation
of Mac OS X (el captain) or with Travis CI.

I should probably note that for Travis CI I did have to install the
msPurityData dependency directly (without Bioconductor). See line 10
https://raw.githubusercontent.com/Viant-Metabolomics/msPurity/master/.travis.yml

The error I think is coming from a function I have that uses the
mzR::peaks() function but I am struggling to see why I am getting the error.

Any help or suggestions would be really appreciated.

Hi Tom --

This might be fun!

You can see from

http://bioconductor.org/checkResults/3.4/bioc-LATEST/morelia-R-instpkgs.html

(linked from 
http://bioconductor.org/checkResults/3.4/bioc-LATEST/index.html '1633' 
installed packages) that in fact msPurityData is installed. Also, 
segfaults are rarely the result of missing packages. Instead, it is 
likely due to errors in C code of one sort or another. On my linux, I 
made sure I was using the 'devel' version of Bioconductor, and that all 
of my packages were up-to-date via biocLite(). I then checked out 
msPurity from svn, changed into the msPurity directory and installed it

R CMD INSTALL .

then I changed to the vignettes directory, Stangled the source code

   cd vignettes
   R CMD Stangle msPurity-vignette.Rmd

(by the way, the products of build the package / vignette, 
msPurity-vignette.R should not be in svn).

I then ran the vignette under valgrind

msPurity/vignettes$ R -d valgrind -f msPurity-vignette.R

leading to

> pa <- purityA(msmsPths)
==19611== Mismatched free() / delete / delete []
==19611==at 0x4C2EDEB: free (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

==19611==by 0x11296DA5: cRamp::cRamp(char const*, bool) (cramp.cpp:98)
==19611==by 0x1129FC87: RcppRamp::open(char const*, bool) 
(RcppRamp.cpp:23)
==19611==by 0x112B49C4: Rcpp::CppMethod2::operator()(RcppRamp*, SEXPREC**) 
(Module_generated_CppMethod.h:215)
==19611==by 0x112B0FBF: 
Rcpp::class_::invoke_void(SEXPREC*, SEXPREC*, SEXPREC**, int) 
(class.h:212)

==19611==by 0xED73CA0: CppMethod__invoke_void(SEXPREC*) (Module.cpp:200)
==19611==by 0x4F0DFD0: do_External (dotcode.c:548)
==19611==by 0x4F47F9E: Rf_eval (eval.c:713)
==19611==by 0x4F4A6B7: do_begin (eval.c:1807)
==19611==by 0x4F47D90: Rf_eval (eval.c:685)
==19611==by 0x4F4964C: Rf_applyClosure (eval.c:1135)
==19611==by 0x4F47B6C: Rf_eval (eval.c:732)
==19611==  Address 0x1b8a4220 is 0 bytes inside a block of size 400 alloc'd
==19611==at 0x4C2E0EF: operator new(unsigned long) (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19611==by 0x11296949: cRamp::do_ramp(long, eWhatToRead) 
(cramp.cpp:215)

==19611==by 0x11296D9D: cRamp::cRamp(char const*, bool) (cramp.cpp:97)
==19611==by 0x1129FC87: RcppRamp::open(char const*, bool) 
(RcppRamp.cpp:23)
==19611==by 0x112B49C4: Rcpp::CppMethod2::operator()(RcppRamp*, SEXPREC**) 
(Module_generated_CppMethod.h:215)
==19611==by 0x112B0FBF: 
Rcpp::class_::invoke_void(SEXPREC*, SEXPREC*, SEXPREC**, int) 
(class.h:212)

==19611==by 0xED73CA0: CppMethod__invoke_void(SEXPREC*) (Module.cpp:200)
==19611==by 0x4F0DFD0: do_External (dotcode.c:548)
==19611==by 0x4F47F9E: Rf_eval (eval.c:713)
==19611==by 0x4F4A6B7: do_begin (eval.c:1807)
==19611==by 0x4F47D90: Rf_eval (eval.c:685)
==19611==by 0x4F4964C: Rf_applyClosure (eval.c:1135)
==19611==

which from 
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.rudefn means 
that memory allocated with new[] is being deallocated with free (rather 
than delete / delete[]

Remarkably, this change to mzR removes this particular valgind problem

Index: src/cramp.cpp
===
--- src/cramp.cpp   (revision 121179)
+++ src/cramp.cpp   (working copy)
@@ -95,7 +95,7 @@
 //  if (m_runInfo->m_data.scanCount < 0) { // undeclared 
scan count

 // this will provoke reading of index, which sets scan count
 rampScanInfo* tmp = getScanHeaderInfo ( 1 );
-free(tmp);
+delete(tmp);
 // }
 // END HENRY
 }

but doesn't get us out of the woods -- valgrind now complains

>
> xset <- xcms::xcmsSet(msmsPths)

vex: the `impossible' happened:
   isZeroU
vex storage: T total 3029292920 bytes allocated
vex storage: P total 640 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==20822==at 0x38083F48: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==20822==by 0x38084064: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
...
sched status:
  running_tid=1

Thread

[Bioc-devel] new biocView

2016-09-21 Thread Shepherd, Lori

A new biocView has been added to the list of terms:  SingleCell


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


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

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

Re: [Bioc-devel] github mirror and svn out of sync

2016-09-21 Thread Martin Morgan


On 09/21/2016 12:01 AM, Rainer Johannes wrote:

Dear all,

I recently observed that the svn and the github mirror of `ensembldb` is out of 
sync. Is this something specific to `ensembldb` or is this a general problem? 
Is there anything I could do to fix this?



I think it is up-to-date now? I think the problem is when several svn 
commits occur in quick succession, and the second tries to sync the git 
repository while the first is still working. I guess the common case is 
when you're working on a git repo and merge it to svn in a way that 
retains the discrete git commits as svn commits.


Each commit triggers this script

  https://github.com/Bioconductor/mirror/blob/master/update_git.py

and these lines (usually the second?) fail

  https://github.com/Bioconductor/mirror/blob/master/update_git.py#L87
  https://github.com/Bioconductor/mirror/blob/master/update_git.py#L90
  https://github.com/Bioconductor/mirror/blob/master/update_git.py#L93

leaving the local git repository in a condition that requires manual 
clean-up.


I guess this requires a more sophisticated implementation, where the svn 
commit adds a task to a time-ordered queue, and the queue waits until 
each previous step has been complete.


Martin


thanks, 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...{{dropped:2}}

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

Re: [Bioc-devel] there is no package called 'zlibbioc' on WINDOWS

2016-09-21 Thread Martin Morgan


On 09/21/2016 06:06 AM, Moritz Gerstung wrote:

Hi Dan

Has this problem problem resurrected?

I see many packages depending on zlibbioc fail, including gage, Rhtslib and 
deepSNV.

http://bioconductor.org/checkResults/devel/bioc-LATEST/gage/moscato1-install.html


The situation has improved but is not fixed across the board. Once 
zlibbioc (or another package at the root of a large hierarchy) fails, 
then the build on windows looks terrible.


Martin



Cheers

Moritz



On 1 Jun 2016, at 20:40, Dan Tenenbaum  wrote:

It's a problem on the server itself. It will not be present in today's build 
report which should be up in half an hour or so.

This is an intermittent problem, not a continuous one.

Dan


- Original Message -

From: "Hartley, Stephen (NIH/NHGRI) [F]" 
To: "Dan Tenenbaum" , "Monther Alhamdoosh" 
, "bioc-devel"

Sent: Wednesday, June 1, 2016 12:11:27 PM
Subject: RE: [Bioc-devel] there is no package called 'zlibbioc' on WINDOWS



It looks like the zlibbioc package still won't load on moscato2. This is causing
something a ton of packages to fail at build (almost half?).

Does anyone have any idea what the issue is? Is it a problem with a patch to the
zlibbioc package, or a problem on the server itself?

-Steve

-Original Message-
From: Dan Tenenbaum [mailto:dtene...@fredhutch.org]
Sent: Thursday, May 26, 2016 9:03 PM
To: Monther Alhamdoosh; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] there is no package called 'zlibbioc' on WINDOWS

It's an as yet unknown problem with the build system. It's very likely that it
will resolve itself in tonight's builds.

Dan


On May 26, 2016 5:04:43 PM PDT, Monther Alhamdoosh  wrote:

Hi developers,

Our package named EGSEA seems to fail to be built on Windows as it
depends on "gage" which depends on zlibbioc. The problem appears in the
release branch and not in the devel branch.

Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck =
vI[[i]])
:

there is no package called 'zlibbioc'

ERROR: lazy loading failed for package 'gage'

Cheers,
Monther

[[alternative HTML version deleted]]

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


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org 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...{{dropped:2}}

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

Re: [Bioc-devel] there is no package called 'zlibbioc' on WINDOWS

2016-09-21 Thread Moritz Gerstung

Hi Dan

Has this problem problem resurrected?

I see many packages depending on zlibbioc fail, including gage, Rhtslib and 
deepSNV.

http://bioconductor.org/checkResults/devel/bioc-LATEST/gage/moscato1-install.html

Cheers

Moritz


> On 1 Jun 2016, at 20:40, Dan Tenenbaum  wrote:
> 
> It's a problem on the server itself. It will not be present in today's build 
> report which should be up in half an hour or so.
> 
> This is an intermittent problem, not a continuous one.
> 
> Dan
> 
> 
> - Original Message -
>> From: "Hartley, Stephen (NIH/NHGRI) [F]" 
>> To: "Dan Tenenbaum" , "Monther Alhamdoosh" 
>> , "bioc-devel"
>> 
>> Sent: Wednesday, June 1, 2016 12:11:27 PM
>> Subject: RE: [Bioc-devel] there is no package called 'zlibbioc' on WINDOWS
> 
>> It looks like the zlibbioc package still won't load on moscato2. This is 
>> causing
>> something a ton of packages to fail at build (almost half?).
>> 
>> Does anyone have any idea what the issue is? Is it a problem with a patch to 
>> the
>> zlibbioc package, or a problem on the server itself?
>> 
>> -Steve
>> 
>> -Original Message-
>> From: Dan Tenenbaum [mailto:dtene...@fredhutch.org]
>> Sent: Thursday, May 26, 2016 9:03 PM
>> To: Monther Alhamdoosh; bioc-devel@r-project.org
>> Subject: Re: [Bioc-devel] there is no package called 'zlibbioc' on WINDOWS
>> 
>> It's an as yet unknown problem with the build system. It's very likely that 
>> it
>> will resolve itself in tonight's builds.
>> 
>> Dan
>> 
>> 
>> On May 26, 2016 5:04:43 PM PDT, Monther Alhamdoosh  
>> wrote:
>>> Hi developers,
>>> 
>>> Our package named EGSEA seems to fail to be built on Windows as it
>>> depends on "gage" which depends on zlibbioc. The problem appears in the
>>> release branch and not in the devel branch.
>>> 
>>> Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck =
>>> vI[[i]])
>>> :
>>> 
>>> there is no package called 'zlibbioc'
>>> 
>>> ERROR: lazy loading failed for package 'gage'
>>> 
>>> Cheers,
>>> Monther
>>> 
>>> [[alternative HTML version deleted]]
>>> 
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> 
>>  [[alternative HTML version deleted]]
>> 
>> ___
>> Bioc-devel@r-project.org 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



-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.

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

Re: [Bioc-devel] Updating author/maintainer info

Re: [Bioc-devel] Updating author/maintainer info

Re: [Bioc-devel] Updating author/maintainer info

[Bioc-devel] Updating author/maintainer info

Re: [Bioc-devel] New package deadline for this release: 26 September

Re: [Bioc-devel] lpsymphony - BiocParallel crash

[Bioc-devel] Package pages: Link to NEWS gone?

Re: [Bioc-devel] msPurity build fail on Mac OS X (morelia)

Re: [Bioc-devel] msPurity build fail on Mac OS X (morelia)

Re: [Bioc-devel] msPurity build fail on Mac OS X (morelia)

[Bioc-devel] lpsymphony - BiocParallel crash

Re: [Bioc-devel] github mirror and svn out of sync

Re: [Bioc-devel] msPurity build fail on Mac OS X (morelia)

[Bioc-devel] new biocView

Re: [Bioc-devel] github mirror and svn out of sync

Re: [Bioc-devel] there is no package called 'zlibbioc' on WINDOWS

Re: [Bioc-devel] there is no package called 'zlibbioc' on WINDOWS

17 matches

Site Navigation

Mail list logo

Footer information