Re: [Bioc-devel] tximport fails to build on Windows

[Obenchain, Valerie]

Hi Mike,

Here is a more informative error from Stangling and sourcing the
vignette on the Windows builder:

...

reading in files with read_tsv
1 Error in file(con, "r") : cannot open the connection
In addition: Warning message:
In file(con, "r") :
  cannot open file
'C:/Users/vobencha/Documents/R/win-library/3.4/tximportData/extdata/sailfish/ERR188297/aux/meta_info.
json': No such file or directory
...

The issue lies in readInfRepFish() at this line where file.exists() is
called:

  auxPath <- file.path(fish_dir, aux_dir)
  if (!file.exists(auxPath)) {
return(NULL)
  }

'auxPath' is
"C:/Users/vobencha/Documents/R/win-library/3.4/tximportData/extdata/sailfish/ERR188297/aux"
which tests TRUE even though no such directory exists. I can reproduce
this weirdness with a simple example. No aux directory or aux file
exists in my home, yet it tests true when there is no trailing slash.
(The trailing slash is not valid in windows and therefore evaluates to
FALSE.)

file.exists("C:/Users/vobencha/aux")
] TRUE
file.exists("C:/Users/vobencha/aux/")
] FALSE

Believe it or not, you simply choose a bad directory name for Windows.
Section 1.1. 'Package Structure' of this link lists aux as a disallowed
file (directory) name:

  https://cran.r-project.org/doc/manuals/r-devel/R-exts.html

You can reproduce this problem with any of the disallowed files names in
that section (disallowed because they are DOS device names). Examples
for the salmon files worked because you named the directory aux_info. If
you rename aux to something else (not listed in Section 1.1!) the
package should build successfully.

Val



On 03/20/2017 01:38 PM, Michael Love wrote:
> Anyone have any ideas for how to debug this?
>
> I get an error from the tximport vignette on tokay2, but I can't
> figure out what could be the issue:
>
> ...
> 1 Quitting from lines 185-189 (tximport.Rmd)
> Error: processing vignette 'tximport.Rmd' failed with diagnostics:
> cannot open the connection
> Execution halted
>
> http://master.bioconductor.org/checkResults/devel/bioc-LATEST/tximport/tokay2-buildsrc.html
>
> Those lines look innocuous to me, and work fine on Linux and Mac:
>
> 184 ```{r}
> 185 files <- file.path(dir,"sailfish", samples$run, "quant.sf")
> 186 names(files) <- paste0("sample",1:6)
> 187 txi.sailfish <- tximport(files, type="sailfish", tx2gene=tx2gene)
> 188 head(txi.sailfish$counts)
> 189 ```
>
> I tried bumping the version and I still get the error from tokay2.
>
> ___
> 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] segfault in csaw native code

[Ryan Thompson]

Hi Aaron,

I'm making a ChIP-Seq analyisis pipeline using csaw, and I'm running into
an inconsistent error/segfault. I've reduced it to a test case which you
can find here:
https://www.dropbox.com/sh/2a2vpb5ek4413fx/AAAXwCaTzsAmfyPefwAbFg8Na?dl=0

The test case consists of my R workspace saved with save.image right before
the code that causes the segfault along with a script that loads the
workspace and then runs the offending code. The code consists of running
combineOverlaps on each of a list of topTags tables. Seemingly at random,
some but not all of the calls to combineOverlaps will fail and error, and
occasionally R will segfault. Since the bug is random, I've also included a
transcript of me running the script until it crashes, as well as a text
file with the traceback in it.

Can you help me debug the issue here?

Thanks,

-Ryan

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] The story of tracing a derfinder bug on OSX that sometimes popped up, sometimes it didn't. Related to IRanges/S4Vectors '$<-'

[Martin Morgan]

On 03/21/2017 08:21 PM, Hervé Pagès wrote:

Hi Leonardo,

Thanks for hunting down and isolating that bug! I tried to simplify
your code even more and was able to get a segfault with just:

  setClass("A", representation(stuff="numeric"))
  x <- logical(10)
  x[TRUE] <- new("A")

I get the segfault about 50% of the time on a fresh R session on Mac.
I tried this with R 3.3.3 on Mavericks, and with R devel (r72372)
on El Capitan. I get the segfault on both.

So it looks like a bug in the `[<-` primitive to me (subassignment).


Any insight from

  R -d valgrind -f herve.R

where herve.R contains the code above?

Martin



Cheers,
H.

On 03/21/2017 03:06 PM, Leonardo Collado Torres wrote:

Hi bioc-devel,

This is a story about a bug that took me a long time to trace. The
behaviour was really weird, so I'm sharing the story in case this
helps others in the future. I was originally writing it to request
help, but then I was able to find the issue ^^. The story ends right
now with code that will reproduce the problem with '$<-' from
IRanges/S4Vectors.




During this Bioc cycle, frequently my package derfinder has failed to
pass R CMD check in OSX. The error is always the same when it appears
and sometimes it shows up in release, but not devel and viceversa.
Right now (3/21/2017) it's visible in both
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_release_bioc-2DLATEST_derfinder_morelia-2Dchecksrc.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Bw-1Kqy-M_t4kmpYWTpYkt5bvj_eTpxriUM3UvtOIzQ=RS-lsygPtDdgWKAhjA2BcSLkVy9RxxshXWAJaBZa_Yc=

and
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_derfinder_toluca2-2Dchecksrc.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Bw-1Kqy-M_t4kmpYWTpYkt5bvj_eTpxriUM3UvtOIzQ=a_K-yK7w2LEV72lpHrpp0UoKRru_7Aad74T5Uk0R-Fo=
.
The end of "test-all.Rout.fail" looks like this:

Loading required package: foreach
Loading required package: iterators
Loading required package: locfit
locfit 1.5-9.1 2013-03-22
getSegments: segmenting
getSegments: splitting
2017-03-20 02:36:52 findRegions: smoothing
2017-03-20 02:36:52 findRegions: identifying potential segments
2017-03-20 02:36:52 findRegions: segmenting information
2017-03-20 02:36:52 .getSegmentsRle: segmenting with cutoff(s)
16.3681899295041
2017-03-20 02:36:52 findRegions: identifying candidate regions
2017-03-20 02:36:52 findRegions: identifying region clusters
2017-03-20 02:36:52 findRegions: smoothing
2017-03-20 02:36:52 findRegions: identifying potential segments
2017-03-20 02:36:52 findRegions: segmenting information
2017-03-20 02:36:52 .getSegmentsRle: segmenting with cutoff(s)
19.7936614060235
2017-03-20 02:36:52 findRegions: identifying candidate regions
2017-03-20 02:36:52 findRegions: identifying region clusters
2017-03-20 02:36:52 findRegions: smoothing

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

Traceback:
 1: (function (y, x, cluster, weights, smoothFun, ...) {
hostPackage <- environmentName(environment(smoothFun))
requireNamespace(hostPackage)smoothed <- .runFunFormal(smoothFun,
y = y, x = x, cluster = cluster, weights = weights, ...)if
(any(!smoothed$smoothed)) {smoothed$fitted[!smoothed$smoothed]
<- y[!smoothed$smoothed]}res <- Rle(smoothed$fitted)
return(res)})(dots[[1L]][[1L]], dots[[2L]][[1L]], dots[[3L]][[1L]],
dots[[4L]][[1L]], smoothFun = function (y, x = NULL, cluster,
weights = NULL, minNum = 7, bpSpan = 1000, minInSpan = 0,
verbose = TRUE) {if (is.null(dim(y))) y <-
matrix(y, ncol = 1)if (!is.null(weights) &&
is.null(dim(weights))) weights <- matrix(weights, ncol =
1)if (is.null(x)) x <- seq(along = y)if
(is.null(weights)) weights <- matrix(1, nrow = nrow(y),
ncol = ncol(y))Indexes <- split(seq(along = cluster), cluster)
   clusterL <- sapply(Indexes, length)smoothed <-
rep(TRUE, nrow(y))for (i in seq(along = Indexes)) {
if (verbose) if (i%%1 == 0)
cat(".")Index <- Indexes[[i]]if (clusterL[i]

= minNum & sum(rowSums(is.na(y[Index, , drop =

FALSE])) == 0) >= minNum) {nn <-
minInSpan/length(Index)for (j in 1:ncol(y)) {
sdata <- data.frame(pos = x[Index], y = y[Index,
  j], weights = weights[Index, j])  fit <-
locfit(y ˜ lp(pos, nn = nn, h = bpSpan), data =
sdata, weights = weights, family = "gaussian",
maxk = 1)  pp <- preplot(fit, where = "data", band
= "local", newdata = data.frame(pos = x[Index]))
   y[Index, j] <- pp$trans(pp$fit)}
}else {y[Index, ] <- NA
smoothed[Index] <- FALSE}}
return(list(fitted = y, smoothed = smoothed, 

Re: [Bioc-devel] The story of tracing a derfinder bug on OSX that sometimes popped up, sometimes it didn't. Related to IRanges/S4Vectors '$<-'

[Hervé Pagès]

Hi Leonardo,

Thanks for hunting down and isolating that bug! I tried to simplify
your code even more and was able to get a segfault with just:

  setClass("A", representation(stuff="numeric"))
  x <- logical(10)
  x[TRUE] <- new("A")

I get the segfault about 50% of the time on a fresh R session on Mac.
I tried this with R 3.3.3 on Mavericks, and with R devel (r72372)
on El Capitan. I get the segfault on both.

So it looks like a bug in the `[<-` primitive to me (subassignment).

Cheers,
H.

On 03/21/2017 03:06 PM, Leonardo Collado Torres wrote:

Hi bioc-devel,

This is a story about a bug that took me a long time to trace. The
behaviour was really weird, so I'm sharing the story in case this
helps others in the future. I was originally writing it to request
help, but then I was able to find the issue ^^. The story ends right
now with code that will reproduce the problem with '$<-' from
IRanges/S4Vectors.




During this Bioc cycle, frequently my package derfinder has failed to
pass R CMD check in OSX. The error is always the same when it appears
and sometimes it shows up in release, but not devel and viceversa.
Right now (3/21/2017) it's visible in both
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_release_bioc-2DLATEST_derfinder_morelia-2Dchecksrc.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Bw-1Kqy-M_t4kmpYWTpYkt5bvj_eTpxriUM3UvtOIzQ=RS-lsygPtDdgWKAhjA2BcSLkVy9RxxshXWAJaBZa_Yc=
and 
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_derfinder_toluca2-2Dchecksrc.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Bw-1Kqy-M_t4kmpYWTpYkt5bvj_eTpxriUM3UvtOIzQ=a_K-yK7w2LEV72lpHrpp0UoKRru_7Aad74T5Uk0R-Fo=
 .
The end of "test-all.Rout.fail" looks like this:

Loading required package: foreach
Loading required package: iterators
Loading required package: locfit
locfit 1.5-9.1 2013-03-22
getSegments: segmenting
getSegments: splitting
2017-03-20 02:36:52 findRegions: smoothing
2017-03-20 02:36:52 findRegions: identifying potential segments
2017-03-20 02:36:52 findRegions: segmenting information
2017-03-20 02:36:52 .getSegmentsRle: segmenting with cutoff(s) 16.3681899295041
2017-03-20 02:36:52 findRegions: identifying candidate regions
2017-03-20 02:36:52 findRegions: identifying region clusters
2017-03-20 02:36:52 findRegions: smoothing
2017-03-20 02:36:52 findRegions: identifying potential segments
2017-03-20 02:36:52 findRegions: segmenting information
2017-03-20 02:36:52 .getSegmentsRle: segmenting with cutoff(s) 19.7936614060235
2017-03-20 02:36:52 findRegions: identifying candidate regions
2017-03-20 02:36:52 findRegions: identifying region clusters
2017-03-20 02:36:52 findRegions: smoothing

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

Traceback:
 1: (function (y, x, cluster, weights, smoothFun, ...) {
hostPackage <- environmentName(environment(smoothFun))
requireNamespace(hostPackage)smoothed <- .runFunFormal(smoothFun,
y = y, x = x, cluster = cluster, weights = weights, ...)if
(any(!smoothed$smoothed)) {smoothed$fitted[!smoothed$smoothed]
<- y[!smoothed$smoothed]}res <- Rle(smoothed$fitted)
return(res)})(dots[[1L]][[1L]], dots[[2L]][[1L]], dots[[3L]][[1L]],
dots[[4L]][[1L]], smoothFun = function (y, x = NULL, cluster,
weights = NULL, minNum = 7, bpSpan = 1000, minInSpan = 0,
verbose = TRUE) {if (is.null(dim(y))) y <-
matrix(y, ncol = 1)if (!is.null(weights) &&
is.null(dim(weights))) weights <- matrix(weights, ncol =
1)if (is.null(x)) x <- seq(along = y)if
(is.null(weights)) weights <- matrix(1, nrow = nrow(y),
ncol = ncol(y))Indexes <- split(seq(along = cluster), cluster)
   clusterL <- sapply(Indexes, length)smoothed <-
rep(TRUE, nrow(y))for (i in seq(along = Indexes)) {
if (verbose) if (i%%1 == 0)
cat(".")Index <- Indexes[[i]]if (clusterL[i]

= minNum & sum(rowSums(is.na(y[Index, , drop =

FALSE])) == 0) >= minNum) {nn <-
minInSpan/length(Index)for (j in 1:ncol(y)) {
sdata <- data.frame(pos = x[Index], y = y[Index,
  j], weights = weights[Index, j])  fit <-
locfit(y ˜ lp(pos, nn = nn, h = bpSpan), data =
sdata, weights = weights, family = "gaussian",
maxk = 1)  pp <- preplot(fit, where = "data", band
= "local", newdata = data.frame(pos = x[Index]))
   y[Index, j] <- pp$trans(pp$fit)}
}else {y[Index, ] <- NA
smoothed[Index] <- FALSE}}
return(list(fitted = y, smoothed = smoothed, smoother = "locfit"))
}, verbose = TRUE, minNum = 1435)
 2: .mapply(.FUN, dots, .MoreArgs)
 3: FUN(...)
 4: doTryCatch(return(expr), name, 

Re: [Bioc-devel] Citation of an accompanying paper

[Monther Alhamdoosh]

Hi Alina,

I think you need to add a file named CITATION in your package (usually
under the inst folder) and use bibentry as follows

bibentry(bibtype = "Article",

 title = "Combining multiple tools outperforms individual methods
in gene set enrichment analyses",

 author = c(person("Monther", "Alhamdoosh"),

person("Milica", "Ng"),

person("Nicholas", "Wilson"),

person("Julie", "Sheridan"),

person("Huy", "Huynh"),

person("Michael", "Wilson"),

person("Matthew", "Ritchie")),

 journal = "Bioinformatics",

 page = "414-424",

 volume = 33,

 number = 3,

 year = 2017,

 doi = "10.1093/bioinformatics/btw623")



Cheers,

Monther

On Wed, Mar 22, 2017 at 8:11 AM, Alina Selega 
wrote:

> Hi,
>
> My methods paper (doi:10.1038/nmeth.4068) associated with my package BUMHMM
> was accepted before I submitted the package for revision at Bioconductor. I
> would like the package page to also hold the citation to the paper. What is
> the best way to add this paper citation? (I cite it in the vignette, but it
> would be nice to also have it on the main page.)
>
> Thank you,
> Alina Selega
>
> [[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] The story of tracing a derfinder bug on OSX that sometimes popped up, sometimes it didn't. Related to IRanges/S4Vectors '$<-'

[Leonardo Collado Torres]

Hi bioc-devel,

This is a story about a bug that took me a long time to trace. The
behaviour was really weird, so I'm sharing the story in case this
helps others in the future. I was originally writing it to request
help, but then I was able to find the issue ^^. The story ends right
now with code that will reproduce the problem with '$<-' from
IRanges/S4Vectors.




During this Bioc cycle, frequently my package derfinder has failed to
pass R CMD check in OSX. The error is always the same when it appears
and sometimes it shows up in release, but not devel and viceversa.
Right now (3/21/2017) it's visible in both
http://bioconductor.org/checkResults/release/bioc-LATEST/derfinder/morelia-checksrc.html
and 
http://bioconductor.org/checkResults/devel/bioc-LATEST/derfinder/toluca2-checksrc.html.
The end of "test-all.Rout.fail" looks like this:

Loading required package: foreach
Loading required package: iterators
Loading required package: locfit
locfit 1.5-9.1 2013-03-22
getSegments: segmenting
getSegments: splitting
2017-03-20 02:36:52 findRegions: smoothing
2017-03-20 02:36:52 findRegions: identifying potential segments
2017-03-20 02:36:52 findRegions: segmenting information
2017-03-20 02:36:52 .getSegmentsRle: segmenting with cutoff(s) 16.3681899295041
2017-03-20 02:36:52 findRegions: identifying candidate regions
2017-03-20 02:36:52 findRegions: identifying region clusters
2017-03-20 02:36:52 findRegions: smoothing
2017-03-20 02:36:52 findRegions: identifying potential segments
2017-03-20 02:36:52 findRegions: segmenting information
2017-03-20 02:36:52 .getSegmentsRle: segmenting with cutoff(s) 19.7936614060235
2017-03-20 02:36:52 findRegions: identifying candidate regions
2017-03-20 02:36:52 findRegions: identifying region clusters
2017-03-20 02:36:52 findRegions: smoothing

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

Traceback:
 1: (function (y, x, cluster, weights, smoothFun, ...) {
hostPackage <- environmentName(environment(smoothFun))
requireNamespace(hostPackage)smoothed <- .runFunFormal(smoothFun,
y = y, x = x, cluster = cluster, weights = weights, ...)if
(any(!smoothed$smoothed)) {smoothed$fitted[!smoothed$smoothed]
<- y[!smoothed$smoothed]}res <- Rle(smoothed$fitted)
return(res)})(dots[[1L]][[1L]], dots[[2L]][[1L]], dots[[3L]][[1L]],
dots[[4L]][[1L]], smoothFun = function (y, x = NULL, cluster,
weights = NULL, minNum = 7, bpSpan = 1000, minInSpan = 0,
verbose = TRUE) {if (is.null(dim(y))) y <-
matrix(y, ncol = 1)if (!is.null(weights) &&
is.null(dim(weights))) weights <- matrix(weights, ncol =
1)if (is.null(x)) x <- seq(along = y)if
(is.null(weights)) weights <- matrix(1, nrow = nrow(y),
ncol = ncol(y))Indexes <- split(seq(along = cluster), cluster)
   clusterL <- sapply(Indexes, length)smoothed <-
rep(TRUE, nrow(y))for (i in seq(along = Indexes)) {
if (verbose) if (i%%1 == 0)
cat(".")Index <- Indexes[[i]]if (clusterL[i]
>= minNum & sum(rowSums(is.na(y[Index, , drop =
FALSE])) == 0) >= minNum) {nn <-
minInSpan/length(Index)for (j in 1:ncol(y)) {
sdata <- data.frame(pos = x[Index], y = y[Index,
  j], weights = weights[Index, j])  fit <-
locfit(y ˜ lp(pos, nn = nn, h = bpSpan), data =
sdata, weights = weights, family = "gaussian",
maxk = 1)  pp <- preplot(fit, where = "data", band
= "local", newdata = data.frame(pos = x[Index]))
   y[Index, j] <- pp$trans(pp$fit)}
}else {y[Index, ] <- NA
smoothed[Index] <- FALSE}}
return(list(fitted = y, smoothed = smoothed, smoother = "locfit"))
}, verbose = TRUE, minNum = 1435)
 2: .mapply(.FUN, dots, .MoreArgs)
 3: FUN(...)
 4: doTryCatch(return(expr), name, parentenv, handler)
 5: tryCatchOne(expr, names, parentenv, handlers[[1L]])
 6: tryCatchList(expr, classes, parentenv, handlers)
 7: tryCatch({FUN(...)}, error = handle_error)
 8: withCallingHandlers({tryCatch({FUN(...)}, error =
handle_error)}, warning = handle_warning)
 9: FUN(X[[i]], ...)
10: lapply(X, FUN, ...)
11: bplapply(X = seq_along(ddd[[1L]]), wrap, .FUN = FUN, .ddd = ddd,
  .MoreArgs = MoreArgs, BPREDO = BPREDO, BPPARAM = BPPARAM)
12: bplapply(X = seq_along(ddd[[1L]]), wrap, .FUN = FUN, .ddd = ddd,
  .MoreArgs = MoreArgs, BPREDO = BPREDO, BPPARAM = BPPARAM)
13: bpmapply(.smoothFstatsFun, fstatsChunks, posChunks, clusterChunks,
weightChunks, MoreArgs = list(smoothFun = smoothFunction,
...), BPPARAM = BPPARAM)
14: bpmapply(.smoothFstatsFun, fstatsChunks, posChunks, clusterChunks,
weightChunks, MoreArgs = list(smoothFun = smoothFunction,
...), BPPARAM = BPPARAM)
15: .smootherFstats(fstats = fstats, position = position, weights =

Re: [Rd] Incompatible change in R-devel

[Dirk Eddelbuettel]

On 21 March 2017 at 17:18, Prof Brian Ripley wrote:
| On 21/03/2017 16:38, Dirk Eddelbuettel wrote:
| > On 21 March 2017 at 07:29, Prof Brian Ripley wrote:
| > | As of today's commit r72375 all packages with native-routine
| > | registration of C or Fortran routines need to be reinstalled in R-devel
| > | (and that include some of the recommended packages in R itself which
| > | will not be reinstalled via make dependencies, so we advise a clean
| > | rebuild of R).
| >
| > I am confused by this.
| >
| > So in order to test this, I just triggered rebuild of the smaller drd 
("daily
| > r-devel") and r-devel Docker images for R.
| >
| > Using drd, I used R 3.3.3 to install digest and anytime (also installing 
Rcpp
| > and BH). I then launch the R-devel build freshly created, and reported as
| >
| >  root@b00daf469882:/# RD --version
| >  R Under development (unstable) (2017-03-21 r72380) -- "Unsuffered 
Consequences"
| >
| > yet both digest and anytime loaded fine by R-devel. Despite the fact that
| > they were installed by R 3.3.3.
| 
| None register C/Fortran routines for .C or .Fortran.

Thanks for the prompt follow-up. Between your email and corresponding entry
in NEWS tagged over at the 'daily r-devel changes' RSS feed, I was also
thinking this might be limited to .C and .Fortran, but _not_ the .Call so
much more common in my world.
 
| My belief is that packages which register more than one .C or more than 
| one .Fortran native routine are affected, but that may not be exhaustive 
| (and might depend on the compiler).

Ok, thanks for the clarification.
 
| > As I understand your email, that should not have worked.  So I must be
| > missing something -- can you help set me straight?
| 
| All packages should load ... the issue is finding (all of the) 
| registered symbols.  Here's an example of what can go wrong, x86_64 Linux;
| 
|  > library(mgcv, lib = "/usr/local/lib64/R/library") # R 3.3.3
| Loading required package: nlme
| This is mgcv 1.8-17. For overview type 'help("mgcv-package")'.
|  > mgcv:::in.out
| ...
|  um <- .C(C_in_out, bx = as.double(bnd[, 1]), by = as.double(bnd[,
| ...
|  > mgcv:::C_in_out
| Error in get(name, envir = asNamespace(pkg), inherits = FALSE) :
|object 'C_in_out' not found
| 
| (the last message being found in testing a package which called mgcv).

Thanks also for the illustration.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Error "Warning in read_symbols_from_dll(so, rarch): this requires 'objdump.exe' to be on the PATH

[Prof Brian Ripley]

On 21/03/2017 17:12, Uwe Ligges wrote:



On 19.03.2017 23:50, Christophe Genolini wrote:

Hi all,

I try to compile my package kml and I get the message


[That will not be 'compiling': it may be from R CMD check, e.g. from 
wuth --as-cran in R-devel.]



Warning in read_symbols_from_dll(so,rarch):
this requires 'objdump.exe' to be on the PATH

I check 'Writing R Extensions' but I did not find any reference to this
error. Does someone know how to fix that?


Yes: Put objdump.exe on the PATH, that executable is part of gcc and in
its bin directoy.


Not quite: it is part of GNU Bintools, hence bundled with gcc in Rtools. 
 So is 'nm', which may appear in a similar message (and on Windows 
means 'nm.exe').


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [Rd] Incompatible change in R-devel

[Prof Brian Ripley]

On 21/03/2017 16:38, Dirk Eddelbuettel wrote:


Hi Brian,

On 21 March 2017 at 07:29, Prof Brian Ripley wrote:
| As of today's commit r72375 all packages with native-routine
| registration of C or Fortran routines need to be reinstalled in R-devel
| (and that include some of the recommended packages in R itself which
| will not be reinstalled via make dependencies, so we advise a clean
| rebuild of R).

I am confused by this.

So in order to test this, I just triggered rebuild of the smaller drd ("daily
r-devel") and r-devel Docker images for R.

Using drd, I used R 3.3.3 to install digest and anytime (also installing Rcpp
and BH). I then launch the R-devel build freshly created, and reported as

 root@b00daf469882:/# RD --version
 R Under development (unstable) (2017-03-21 r72380) -- "Unsuffered Consequences"

yet both digest and anytime loaded fine by R-devel. Despite the fact that
they were installed by R 3.3.3.


None register C/Fortran routines for .C or .Fortran.

My belief is that packages which register more than one .C or more than 
one .Fortran native routine are affected, but that may not be exhaustive 
(and might depend on the compiler).



As I understand your email, that should not have worked.  So I must be
missing something -- can you help set me straight?


All packages should load ... the issue is finding (all of the) 
registered symbols.  Here's an example of what can go wrong, x86_64 Linux;


> library(mgcv, lib = "/usr/local/lib64/R/library") # R 3.3.3
Loading required package: nlme
This is mgcv 1.8-17. For overview type 'help("mgcv-package")'.
> mgcv:::in.out
...
um <- .C(C_in_out, bx = as.double(bnd[, 1]), by = as.double(bnd[,
...
> mgcv:::C_in_out
Error in get(name, envir = asNamespace(pkg), inherits = FALSE) :
  object 'C_in_out' not found

(the last message being found in testing a package which called mgcv).

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [Rd] Error "Warning in read_symbols_from_dll(so, rarch): this requires 'objdump.exe' to be on the PATH

[Uwe Ligges]

On 19.03.2017 23:50, Christophe Genolini wrote:

Hi all,

I try to compile my package kml and I get the message

Warning in read_symbols_from_dll(so,rarch):
this requires 'objdump.exe' to be on the PATH

I check 'Writing R Extensions' but I did not find any reference to this
error. Does someone know how to fix that?


Yes: Put objdump.exe on the PATH, that executable is part of gcc and in 
its bin directoy.


Best,
Uwe Ligges




Thank you very much for your help.
Christophe

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


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

Re: [Rd] Hyperbolic tangent different results on Windows and Mac

[Uwe Ligges]

On 21.03.2017 10:54, Martin Maechler wrote:

Rodrigo Zepeda 
on Fri, 17 Mar 2017 12:56:06 -0600 writes:


> Dear all,
> We seem to have found a "strange" behaviour in the hyperbolic tangent
> function tanh on Windows.
> When running tanh(356 + 0i) the Windows result is NaN + 0.i while on Mac
> the result is 1 + 0i. It doesn't seem to be a floating point error because
> on Mac it is possible to run arbitrarily large numbers (say tanh(
> 
99677873648767519238192348124812341234182374817239847812738481234871823+0i)
> ) and still get 1 + 0i as result. This seems to be related to the 
imaginary
> part as tanh(356) returns 1 in both Windows and Mac.

> We have obtained those results in:
> 1) Mac with El Capitan v 10.11.6 *processor: 2.7 GHz Intel Core i5*
> - 2) Mac with Sierra v 10.12.3 *processor: 3.2 GHz Intel Core i5*
> - 3) Windows 10 Home v 1607 *processor: Intel Core m3-SY30 CPU@ 0.90 GHz
> 1.51 GHz*
> - 4) Windows 7 Home Premium Service Pack 1 *processor: Intel Core i5-2410M
> CPU @2.30 GHz 2.30GHz.*

(The hardware should not matter).

Yes, there is a bug here on Windows only, (several Linux
versions work correctly too).

> ​In all cases we are using R version 3.3.3 (64 bits)​


> - *Does anybody have a clue on why is this happening?*

> ​PS: We have previously posted this issue in Stack Overflow (
> 
http://stackoverflow.com/questions/42847414/hyperbolic-tangent-in-r-throws-nan-in-windows-but-not-in-mac).
> A comment suggests it is related to a glibc bug.

Yes, that would have been my guess too... as indeed, R on
Windows which should work for quite old versions of Windows has
been using a relatively old (gcc / libc) toolchain.

The upcoming version of R 3.4.0 uses a considerably newer
toolchain *BUT* I've just checked the latest "R-devel" binary
and the bug is still present there.

Here's a slight extension of the answer I wrote to the
above SO question here:  http://stackoverflow.com/a/42923289/161921

... Windows uses somewhat old C libraries, and here it is the
"mathlib" part of glibc.

More specifically, according to the CRAN download page for R-devel for Windows
https://cran.r-project.org/bin/windows/base/rdevel.html ,
the R 3.3.z series uses the gcc 4.6.3 (March 2012) toolchain, whereas
"R-devel", the upcoming (not yet released!) R 3.4.z series uses
the gcc 4.9.3 (June 2015) toolchain.



Actually the R-3.3.z series already uses gcc-4.9.3.


Best,
Uwe Ligges



According to Ben Bolker's comment on SO, the bug in glibc should have
been fixed in 2012 -- and so the change from 4.6.3 to 4.9.3
should have helped,
**however* I've just checked (installed the R-devel binary from CRAN on our 
Windows server virtual machine) and I see that the problem is still present 
there: In yesterday's version of R-devel, tanh(500+0i) still returns NaN+0i.

I now think a better solution would be to use R's internal
substitute (in R's src/main/complex.c): There, we have

#ifndef HAVE_CTANH
#define ctanh R_ctanh
static double complex ctanh(double complex z)
{
return -I * ctan(z * I); /* A 4.5.9 */
}
#endif

and we should use it (by "#undef HAVE_CTAN" (or better by a
  configure check, using  ctanh("500 + 0i"),
as I see that on Windows,
   R> -1i * tan((500+0i)*1i)
gives
   [1] 1+0i
as it should for tanh(500+0i) --- but does not on Windows.

Martin Maechler
ETH Zurich and R Core

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



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

Re: [Rd] Incompatible change in R-devel

[Dirk Eddelbuettel]

Hi Brian,

On 21 March 2017 at 07:29, Prof Brian Ripley wrote:
| As of today's commit r72375 all packages with native-routine 
| registration of C or Fortran routines need to be reinstalled in R-devel 
| (and that include some of the recommended packages in R itself which 
| will not be reinstalled via make dependencies, so we advise a clean 
| rebuild of R).

I am confused by this.

So in order to test this, I just triggered rebuild of the smaller drd ("daily
r-devel") and r-devel Docker images for R.  

Using drd, I used R 3.3.3 to install digest and anytime (also installing Rcpp
and BH). I then launch the R-devel build freshly created, and reported as 

 root@b00daf469882:/# RD --version
 R Under development (unstable) (2017-03-21 r72380) -- "Unsuffered Consequences"

yet both digest and anytime loaded fine by R-devel. Despite the fact that
they were installed by R 3.3.3.

As I understand your email, that should not have worked.  So I must be
missing something -- can you help set me straight?

Thanks, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Bioc-devel] Package not being built on Windows or Mac

[Robert M. Flight]

Thank you all for the explanations, and the assurance that Windows and Mac
users should still be able to install it.

Robert

On Tue, Mar 21, 2017, 2:56 AM Hervé Pagès  wrote:

> On 03/20/2017 02:31 PM, Dan Tenenbaum wrote:
> > As I recall, there were issues building RCytoscape (and packages that
> depend on it) on Mac and Windows. Mostly because this requires a running
> instance of Cytoscape for each platform (and double that for release +
> devel). That used too much infrastructure so we disabled building on those
> platforms. However, since RCytoscape contains no native (C/C++/Fortran)
> code, it will still be available on all platforms and should install just
> fine.
> >
> > As long as the same is true of categoryCompare then Mac/Windows users
> should be able to use it.
>
> Exactly. Thanks Dan & Jim!
>
> FWIW, supported platforms are controlled via the .BBSoptions file.
> I added this file in August last year:
>
>hpages@latitude:~/svn/bioconductor/Rpacks/categoryCompare$ svn log -v
> -r120632
>
>r120632 | hpa...@fhcrc.org | 2016-08-31 17:13:55 -0700 (Wed, 31 Aug
> 2016) | 1 line
>Changed paths:
>   A /trunk/madman/Rpacks/categoryCompare/.BBSoptions
>
>mark as unsupported on non-linux like RCytoscape which
> categoryCompare depends on
>
>
> Cheers,
> H.
>
> >
> > Dan
> >
> >
> > - Original Message -
> >> From: "James W. MacDonald" 
> >> To: "Robert M. Flight" 
> >> Cc: "bioc-devel" 
> >> Sent: Monday, March 20, 2017 2:22:36 PM
> >> Subject: Re: [Bioc-devel] Package not being built on Windows or Mac
> >
> >> It's probably because you depend on RCytoscape, which isn't supported on
> >> Windows or MacOS. And maybe this has something to do with XMLRPC?
> >>
> >> Jim
> >>
> >>
> >>
> >> On Mon, Mar 20, 2017 at 4:59 PM, Robert M. Flight 
> >> wrote:
> >>
> >>> As per the exhortation to check the build status on Devel prior to next
> >>> version of Bioconductor release, I just noticed that my package
> >>> categoryCompare has a "not supported" on Windows and Mac.
> >>>
> >>> Looking at release history, this seems to  I have changed at Bioc v
> 3.4,
> >>> and I'm curious why that would be the case.
> >>>
> >>> Regards,
> >>>
> >>> Robert
> >>>
> >>> Robert M Flight, PhD
> >>> Bioinformatics Research Associate
> >>> Puller of Rabbits from Hats
> >>> Resource Center for Stable Isotope Resolved Metabolomics
> >>> Manager, Systems Biology and Omics Integration Journal Club
> >>> Markey Cancer Center
> >>> CC434 Roach Building
> >>> University of Kentucky
> >>> Lexington, KY
> >>>
> >>> Twitter: @rmflight
> >>> Web: rmflight.github.io
> >>> ORCID:
> >>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__orcid.org_-2D0001-2D8141-2D7788=DwICAg=eRAMFD45gAfqt84VtBcfhQ=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo=KPLsJPHGh_SklfKfn_epC0AQwKR8K6yNDv7cVLAJ1FQ=n-q_ynuSgrWSRqpLP4_jtAcjUUkBkQS47cGcISvMTH8=
> >>> EM rfligh...@gmail.com
> >>> PH 502-509-1827
> >>>
> >>> To call in the statistician after the experiment is done may be no more
> >>> than asking him to perform a post-mortem examination: he may be able
> to say
> >>> what the experiment died of. - Ronald Fisher
> >>>
> >>> [[alternative HTML version deleted]]
> >>>
> >>> ___
> >>> Bioc-devel@r-project.org mailing list
> >>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo=KPLsJPHGh_SklfKfn_epC0AQwKR8K6yNDv7cVLAJ1FQ=s4b92CENsDvGb5LJKA-xyg2pTKm6kJHUNfyOrk_ySY4=
> >>>
> >>
> >>
> >>
> >> --
> >> 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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo=KPLsJPHGh_SklfKfn_epC0AQwKR8K6yNDv7cVLAJ1FQ=s4b92CENsDvGb5LJKA-xyg2pTKm6kJHUNfyOrk_ySY4=
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=X94AHNTkq0h6XD9LVupSKDvSbZ-yegrFoOHwhcXwiB4=9fgZqQcbQ5xqueIgNnEKDX1EUULjRuQw67kYshlARkY=
> >
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, 

Re: [Rd] Hyperbolic tangent different results on Windows and Mac

[Martin Maechler]

> Rodrigo Zepeda 
> on Fri, 17 Mar 2017 12:56:06 -0600 writes:

> Dear all,
> We seem to have found a "strange" behaviour in the hyperbolic tangent
> function tanh on Windows.
> When running tanh(356 + 0i) the Windows result is NaN + 0.i while on Mac
> the result is 1 + 0i. It doesn't seem to be a floating point error because
> on Mac it is possible to run arbitrarily large numbers (say tanh(
> 
99677873648767519238192348124812341234182374817239847812738481234871823+0i)
> ) and still get 1 + 0i as result. This seems to be related to the 
imaginary
> part as tanh(356) returns 1 in both Windows and Mac.

> We have obtained those results in:
> 1) Mac with El Capitan v 10.11.6 *processor: 2.7 GHz Intel Core i5*
> - 2) Mac with Sierra v 10.12.3 *processor: 3.2 GHz Intel Core i5*
> - 3) Windows 10 Home v 1607 *processor: Intel Core m3-SY30 CPU@ 0.90 GHz
> 1.51 GHz*
> - 4) Windows 7 Home Premium Service Pack 1 *processor: Intel Core i5-2410M
> CPU @2.30 GHz 2.30GHz.*

(The hardware should not matter).

Yes, there is a bug here on Windows only, (several Linux
versions work correctly too).

> ​In all cases we are using R version 3.3.3 (64 bits)​


> - *Does anybody have a clue on why is this happening?*

> ​PS: We have previously posted this issue in Stack Overflow (
> 
http://stackoverflow.com/questions/42847414/hyperbolic-tangent-in-r-throws-nan-in-windows-but-not-in-mac).
> A comment suggests it is related to a glibc bug.

Yes, that would have been my guess too... as indeed, R on
Windows which should work for quite old versions of Windows has
been using a relatively old (gcc / libc) toolchain.

The upcoming version of R 3.4.0 uses a considerably newer
toolchain *BUT* I've just checked the latest "R-devel" binary
and the bug is still present there.

Here's a slight extension of the answer I wrote to the
above SO question here:  http://stackoverflow.com/a/42923289/161921

... Windows uses somewhat old C libraries, and here it is the
"mathlib" part of glibc. 

More specifically, according to the CRAN download page for R-devel for Windows
https://cran.r-project.org/bin/windows/base/rdevel.html ,
the R 3.3.z series uses the gcc 4.6.3 (March 2012) toolchain, whereas
"R-devel", the upcoming (not yet released!) R 3.4.z series uses
the gcc 4.9.3 (June 2015) toolchain.

According to Ben Bolker's comment on SO, the bug in glibc should have
been fixed in 2012 -- and so the change from 4.6.3 to 4.9.3
should have helped,
**however* I've just checked (installed the R-devel binary from CRAN on our 
Windows server virtual machine) and I see that the problem is still present 
there: In yesterday's version of R-devel, tanh(500+0i) still returns NaN+0i.

I now think a better solution would be to use R's internal
substitute (in R's src/main/complex.c): There, we have

#ifndef HAVE_CTANH
#define ctanh R_ctanh
static double complex ctanh(double complex z)
{
return -I * ctan(z * I); /* A 4.5.9 */
}
#endif

and we should use it (by "#undef HAVE_CTAN" (or better by a
  configure check, using  ctanh("500 + 0i"),
as I see that on Windows,
   R> -1i * tan((500+0i)*1i)
gives
   [1] 1+0i
as it should for tanh(500+0i) --- but does not on Windows.

Martin Maechler
ETH Zurich and R Core

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

Re: [Rd] outer not applying a constant function

[Martin Maechler]

> William Dunlap 
> on Mon, 20 Mar 2017 10:20:11 -0700 writes:

>> Or is this a bad idea?
> I don't like the proposal.  I have seen code like the following (in
> fact, I have written such code, where I had forgotten a function was
> not vectorized) where the error would have been discovered much later
> if outer() didn't catch it.

>> outer(1:3, 11:13, sum)
>  Error in outer(1:3, 11:13, sum) :
>dims [product 9] do not match the length of object [1]

> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com

You are right, thank you!
Such a "convenience change" would not be a good idea.

Martin Maechler
ETH Zurich




> On Mon, Mar 20, 2017 at 6:36 AM, Martin Maechler
>  wrote:
>>> Gebhardt, Albrecht 
>>> on Sun, 19 Mar 2017 09:14:56 + writes:
>> 
>> > Hi,
>> > the function outer can not apply a constant function as in the last 
line of the following example:
>> 
>> >> xg <- 1:4
>> >> yg <- 1:4
>> >> fxyg <- outer(xg, yg, function(x,y) x*y)
>> >> fconstg <- outer(xg, yg, function(x,y) 1.0)
>> > Error in outer(xg, yg, function(x, y) 1) :
>> > dims [product 16] do not match the length of object [1]
>> 
>> > Of course there are simpler ways to construct a constant matrix, that 
is not my point.
>> 
>> > It happens for me in the context of generating matrices of partial 
derivatives, and if on of these partial derivatives happens to be constant it 
fails.
>> 
>> > So e.g this works:
>> 
>> > library(Deriv)
>> > f <- function(x,y) (x-1.5)*(y-1)*(x-1.8)+(y-1.9)^2*(x-1.1)^3
>> > fx <- Deriv(f,"x")
>> > fy <- Deriv(f,"y")
>> > fxy <- Deriv(Deriv(f,"y"),"x")
>> > fxx <- Deriv(Deriv(f,"x"),"x")
>> > fyy <- Deriv(Deriv(f,"y"),"y")
>> 
>> > fg   <- outer(xg,yg,f)
>> > fxg  <- outer(xg,yg,fx)
>> > fyg  <- outer(xg,yg,fy)
>> > fxyg <- outer(xg,yg,fxy)
>> > fxxg <- outer(xg,yg,fxx)
>> > fyyg <- outer(xg,yg,fyy)
>> 
>> > And with
>> 
>> > f <- function(x,y) x+y
>> 
>> > it stops working. Of course I can manually fix this for that special 
case, but thats not my point. I simply thought "outer" should be able to handle 
constant functions.
>> 
>> ?outer   clearly states that  FUN  needs to be vectorized
>> 
>> but  function(x,y) 1is not.
>> 
>> It is easy to solve by wrapping the function in Vectorize(.):
>> 
>>> x <- 1:3; y <- 1:4
>> 
>>> outer(x,y, function(x,y) 1)
>> Error in dim(robj) <- c(dX, dY) :
>> dims [product 12] do not match the length of object [1]
>> 
>>> outer(x,y, Vectorize(function(x,y) 1))
>> [,1] [,2] [,3] [,4]
>> [1,]1111
>> [2,]1111
>> [3,]1111
>> 
>> 
>> 
>> So, your "should"  above must be read in the sense
>> 
>> "It really would be convenient here and
>> correspond to other "recycling" behavior of R"
>> 
>> and I agree with that, having experienced the same inconvenience
>> as you several times in the past.
>> 
>> outer() being a nice R-level function (i.e., no C speed up)
>> makes it easy to improve:
>> 
>> Adding something like the line
>> 
>> if(length(robj) == 1L) robj <- rep.int(robj, dX*dY)
>> 
>> beforedim(robj) <- c(dX, dY)   [which gave the error]
>> 
>> would solve the issue and not cost much (in the cases it is unneeded).
>> 
>> Or is this a bad idea?
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Bioc-devel] developing R package for new release

[Nicholas Clark]

Thanks for taking the time to reply, James.


I was confused by the fact that R 3.3.3 was released a few weeks ago and I was 
thinking that was previously the R-devel… meaning the R version you’re supposed 
to develop against would have just changed a few weeks ago. I re-read the 
sentence “R has a ‘.y’ release in x.y.z every year” and now it makes sense. The 
confusing was due to my misreading.


Thanks for the clarification of how the git/subversion branches work as well.


Best,
Nick
Nicholas Clark
Graduate Research Assistant
Laboratory for Statistical Genomics and Systems Biology
University of Cincinnati



> On Mar 20, 2017, at 10:58 AM, James W. MacDonald  wrote:
> 
> 
> 
> 
> On Fri, Mar 17, 2017 at 3:45 PM, Nicholas Clark >wrote:
>> I’m planning on adding some new features to my package (GRmetrics) before 
>> this upcoming release and I have a few development questions.
>> 
>> 
>> 1) Which version of R should I be using? I looked at this page 
>> (http://bioconductor.org/developers/how-to/useDevel/
>> 
>> 
>> ), but I was still confused as to whether I should use the recently released 
>> R 3.3.3 or the R-devel 3.4.0 at http://r.research.att.com/
>> 
> 
> For the spring release you should use R-devel. For the fall release you 
> should use the most current version of R. This is because we release twice a 
> year, but R is only released in spring.
> 
> 
> Looking at the useDevel page I see that I am simply repeating (almost 
> verbatim) what is written there. Is there something unclear about this that 
> we should address? It seems clear enough to me, but I've been doing this a 
> long time.
>  
> 
>> 
>> .
>> 
>> 
>> 2) What is the best/easiest way to work with github? Should I fork the 
>> repository from the read-only Bioconductor repo and work on that or maintain 
>> a separate repo? Or does it not matter?
>> 
> 
> I believe you should fork the repo from the Bioconductor mirror and use that. 
> There is some info here 
> (http://bioconductor.org/developers/how-to/git-mirrors/
> ). But there are some considerations to be made. Right now, we are using 
> subversion for version control, and anything you do in github has to be 
> 'subversionized' in order for your commits to be checked into the main 
> version control repository. It's far easier IMO to just use subversion to do 
> all your version control, because you don't have to worry about getting git 
> to talk to subversion. 
> 
> 
> That said, after the April release we are transitioning to git, so we will be 
> using git soon enough. But for now I am still using SVN because it's a direct 
> commit to the main repo. My advice is to use whatever the main repo is based 
> on, because mixing and matching adds an extra level of complexity that 
> doesn't appear to have much to offer in return.
> 
> 
>> 
>> 
>> 3) Should I make a “release-3.5” branch and commit changes there, or should 
>> it be “devel”, or just the “master” branch? 
>> http://bioconductor.org/developers/how-to/git-mirrors/
>> 
>> 
>> 
>>  talks about this, but again, it’s not clear to me.
>> 
> 
> You never make your own branches. That's controlled by BioC core. Unless you 
> are fixing a bug in the release version of your package you should be using 
> the master branch (or if you use SVN, you should just be checking out of the 
> trunk, https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/GRmetrics
> ).
> 
> 
>> 
>> 
>> 4) It looks like my package is failing the Windows build because it requires 
>> “SummarizedExperiment”, which is failing the Windows build. Is there 
>> anything I can do to fix this? Apologies if this has already been addressed. 
>> The error is: ERROR: dependency ‘SummarizedExperiment’ is not available for 
>> package ‘GRmetrics' 
>> (http://bioconductor.org/checkResults/release/bioc-LATEST/GRmetrics/tokay1-buildsrc.html
>> 
>> 
>> 
>> 
>> )
>> 
>> 
> 
> If one of your dependencies is failing, and in particular if the dependency 
> is maintained by Bioc core, then the best thing to do is wait. If you are 
> relying on somebody else's package and they are consistently failing you 
> might contact them and find out if you can help.
> 
> 
> Jim
> 
> 
> 
> 
>> 
>> 
>> Best,
>> Nick Clark
>> 
>> 
>> 
>>         [[alternative HTML version deleted]]
>> 
>> ___
>> 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

[Rd] Incompatible change in R-devel

[Prof Brian Ripley]

As of today's commit r72375 all packages with native-routine 
registration of C or Fortran routines need to be reinstalled in R-devel 
(and that include some of the recommended packages in R itself which 
will not be reinstalled via make dependencies, so we advise a clean 
rebuild of R).


We try to avoid such things, but now is a least bad time (before binary 
packages for pre-3.4.0 are built in earnest, although CRAN Windows ones 
have been available for a while and will be rebuilt now).


Packages aster2 used undocumented/defunct fields and is overdue for 
update: AFIAWK all other CRAN/BioC packages can be reinstalled.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [Bioc-devel] Package not being built on Windows or Mac

[Hervé Pagès]

On 03/20/2017 02:31 PM, Dan Tenenbaum wrote:

As I recall, there were issues building RCytoscape (and packages that depend on 
it) on Mac and Windows. Mostly because this requires a running instance of 
Cytoscape for each platform (and double that for release + devel). That used 
too much infrastructure so we disabled building on those platforms. However, 
since RCytoscape contains no native (C/C++/Fortran) code, it will still be 
available on all platforms and should install just fine.

As long as the same is true of categoryCompare then Mac/Windows users should be 
able to use it.


Exactly. Thanks Dan & Jim!

FWIW, supported platforms are controlled via the .BBSoptions file.
I added this file in August last year:

  hpages@latitude:~/svn/bioconductor/Rpacks/categoryCompare$ svn log -v 
-r120632

  
  r120632 | hpa...@fhcrc.org | 2016-08-31 17:13:55 -0700 (Wed, 31 Aug 
2016) | 1 line

  Changed paths:
 A /trunk/madman/Rpacks/categoryCompare/.BBSoptions

  mark as unsupported on non-linux like RCytoscape which 
categoryCompare depends on

  

Cheers,
H.



Dan


- Original Message -

From: "James W. MacDonald" 
To: "Robert M. Flight" 
Cc: "bioc-devel" 
Sent: Monday, March 20, 2017 2:22:36 PM
Subject: Re: [Bioc-devel] Package not being built on Windows or Mac



It's probably because you depend on RCytoscape, which isn't supported on
Windows or MacOS. And maybe this has something to do with XMLRPC?

Jim



On Mon, Mar 20, 2017 at 4:59 PM, Robert M. Flight 
wrote:


As per the exhortation to check the build status on Devel prior to next
version of Bioconductor release, I just noticed that my package
categoryCompare has a "not supported" on Windows and Mac.

Looking at release history, this seems to  I have changed at Bioc v 3.4,
and I'm curious why that would be the case.

Regards,

Robert

Robert M Flight, PhD
Bioinformatics Research Associate
Puller of Rabbits from Hats
Resource Center for Stable Isotope Resolved Metabolomics
Manager, Systems Biology and Omics Integration Journal Club
Markey Cancer Center
CC434 Roach Building
University of Kentucky
Lexington, KY

Twitter: @rmflight
Web: rmflight.github.io
ORCID:
https://urldefense.proofpoint.com/v2/url?u=http-3A__orcid.org_-2D0001-2D8141-2D7788=DwICAg=eRAMFD45gAfqt84VtBcfhQ=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo=KPLsJPHGh_SklfKfn_epC0AQwKR8K6yNDv7cVLAJ1FQ=n-q_ynuSgrWSRqpLP4_jtAcjUUkBkQS47cGcISvMTH8=
EM rfligh...@gmail.com
PH 502-509-1827

To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. - Ronald Fisher

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo=KPLsJPHGh_SklfKfn_epC0AQwKR8K6yNDv7cVLAJ1FQ=s4b92CENsDvGb5LJKA-xyg2pTKm6kJHUNfyOrk_ySY4=





--
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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=TF6f93hjWmgMzjqP9F3thRifibmFvfjc5Ae-bzNwDGo=KPLsJPHGh_SklfKfn_epC0AQwKR8K6yNDv7cVLAJ1FQ=s4b92CENsDvGb5LJKA-xyg2pTKm6kJHUNfyOrk_ySY4=


___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=X94AHNTkq0h6XD9LVupSKDvSbZ-yegrFoOHwhcXwiB4=9fgZqQcbQ5xqueIgNnEKDX1EUULjRuQw67kYshlARkY=



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