Re: [Bioc-devel] strand<- method for 'GPos' doesn't work
Hi Robert, I'm working on this. Best, H. On 07/14/2017 02:31 AM, Robert Castelo wrote: hi, the strand replacement method for 'GPos' objects does not seem to work: library(GenomicRanges) example(GPos) strand(gpos1) <- "-" Error in methods::slot(object, name) : no slot of name "call" for this object of class "GPos" traceback() 10: methods::slot(object, name) 9: getElement(x, "call") 8: getCall.default(object) 7: getCall(object) 6: update.default(x, strand = value, check = FALSE) 5: update(x, strand = value, check = FALSE) 4: update(x, strand = value, check = FALSE) 3: .local(x, ..., value) 2: `strand<-`(`*tmp*`, value = "-") 1: `strand<-`(`*tmp*`, value = "-") this kind of operation works perfectly on 'GRanges' objects, so i guess it should also work also with 'GPos' objects: example(GRanges) gr1 GRanges object with 1 range and 0 metadata columns: seqnamesranges strand [1] chr2 [56, 125] * --- seqinfo: 1 sequence from an unspecified genome; no seqlength strand(gr1) <- "-" gr1 GRanges object with 1 range and 0 metadata columns: seqnamesranges strand [1] chr2 [56, 125] - --- seqinfo: 1 sequence from an unspecified genome; no seqlengths below my session info. thanks! robert. ps: sessionInfo() sessionInfo() R version 3.4.0 (2017-04-21) Platform: x86_64-pc-linux-gnu (64-bit) Running under: CentOS Linux 7 (Core) Matrix products: default BLAS: /opt/R/R-3.4.0/lib64/R/lib/libRblas.so LAPACK: /opt/R/R-3.4.0/lib64/R/lib/libRlapack.so locale: [1] LC_CTYPE=en_US.UTF8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF8LC_COLLATE=en_US.UTF8 [5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8 [7] LC_PAPER=en_US.UTF8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C attached base packages: [1] parallel stats4stats graphics grDevices utils datasets [8] methods base other attached packages: [1] GenomicRanges_1.28.3 GenomeInfoDb_1.12.2 IRanges_2.10.2 [4] S4Vectors_0.14.3 BiocGenerics_0.22.0 colorout_1.1-2 loaded via a namespace (and not attached): [1] zlibbioc_1.22.0 compiler_3.4.0 tools_3.4.0 [4] XVector_0.16.0 GenomeInfoDbData_0.99.0 RCurl_1.95-4.8 [7] bitops_1.0-6 ___ 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=bDabOgHqmutD8tE7VRQOn6ItcvsQOsLTpqQK4P7TwSo=WX_xk1if47kTfxxMZBFJwJtSReb1iLnoFpyPE9M-Diw= -- 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] Issue with GenomeInfoDb
.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=x5iUx04safB-ad_8-p8FGpL1zsRp-htM3JOMBhRQ_dY=z0Q3sGufUP6woYO3PLPA6PtsPugRUyLmCHXXaGwd-Cc= -- 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] Devel nightly build
Hi Hector, Val, The build report for today (Friday Jul 14) is finally here: https://bioconductor.org/checkResults/3.6/bioc-LATEST/ I hope you can see the changes you made to your package reflected here and also that the new version of the package propagated as it should. Let us know if not. I introduced a regression when I made some changes a couple of days ago to the script that generates this report. It's fixed now. Sorry for that. As Val said, we've been testing git-based builds as part of the preparation for the svn->git transition. We're trying as much as we can to avoid having this testing disrupt the normal functioning of the daily builds (which are still svn-based!). Cheers, H. On 07/14/2017 01:46 PM, Obenchain, Valerie wrote: I was wrong about this. Herve has isolated the experimental git-based builds so they don't affect the standard svn-based builds at all. I posted about the problems we're having with the devel builds here: https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_pipermail_bioc-2Ddevel_2017-2DJuly_011203.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kPBp3A8XCX1agWWYNh78uN9p4Db-hjSVrFfdxXDTtkw=PT_7jq29yh7gjT7hpm8w8vhfkSEVHO0s0xruTkW03kE= Sorry for the red herring. Valerie On 07/14/2017 08:00 AM, Obenchain, Valerie wrote: Hi Hector, We are in the beta phase of testing the svn -> git transition so there will be a few hicups in the builds over the next week. We hope to have new devel and release reports today (July 14). Thanks for your patience. Valerie On 07/14/2017 05:27 AM, Hector Corrada Bravo wrote: Hello, I noticed the last SVN snapshot for devel nightly builds was from Monday 7/10. Are builds not being done nightly? We want to submit a new package for review but need an update to a dependency on the build system we pushed this week. Thanks for the info! Hector [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org><mailto:Bioc-devel@r-project.org><mailto: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=kPBp3A8XCX1agWWYNh78uN9p4Db-hjSVrFfdxXDTtkw=BU4aP0HjKSN_URbAn9dWZevcjynO-qZC36Pf65noPCg= 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<mailto: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=kPBp3A8XCX1agWWYNh78uN9p4Db-hjSVrFfdxXDTtkw=BU4aP0HjKSN_URbAn9dWZevcjynO-qZC36Pf65noPCg= 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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kPBp3A8XCX1agWWYNh78uN9p4Db-hjSVrFfdxXDTtkw=BU4aP0HjKSN_URbAn9dWZevcjynO-qZC36Pf65noPCg= -- 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] Bioconductor stats
Hi LLuis, As Sean already said mirrors are not included in the stats. The monthly nb of distinct IPs are reset every month and the yearly nb of distinct IPs are reset every year. Some packages are indeed in two categories. Category assignment is based on the download URL only. For some mysterious reason the Apache logs contain some lines that indicate that AnnotationDbi was downloaded from an URL that points to a data experiment repository. These lines are very rare though (1 or 2 per year) so overall don't have any significant impact on the stats. Anyway that's something we'll need to dig into at some point. Cheers, H. On 06/27/2017 04:34 AM, Lluís Revilla wrote: Hi, I have been looking at the stats of Bioconductor, and I would like to know more about how are they calculated. Do these stats account for the mirror sites? Are there any stats of the usage of mirrors? I found some packages that for the same month they have downloads in two categories. For instance AnnotationDbi has some downloads as experimental data package: https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_packages_stats_data-2Dexperiment_AnnotationDbi_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=psknpX6b5M14sI3qf3U_bWP0s-rn_fEEnRsPoYrD2bw=Vn8nr1PNCdozt0465LZB9CXnGpPGdoEu_QskcQ6ehZA= while most of the downloads are in the software category (The right one). It seems that near 500 packages have downloads in two categories. The "Nb of distinct IPs" if I understand correctly is for each package and month. So if the same IP downloads again the package is listed as a new IP, isn't it? I assume that if mirrors are counted either no one downloads the same packages from different mirrors in the same IP or that these information is shared across mirrors for these stats. Regards, Lluís [[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=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=psknpX6b5M14sI3qf3U_bWP0s-rn_fEEnRsPoYrD2bw=fX6Iawm0pI8-QEOmPe6TjPRFoKmYDYtrW6As8eHJ59o= -- 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] Help understanding an R performance issue
EcHLbOVPcNwdqZ_4=xNWXpfkTzxBoF_c0HoPoyQ0c3v6DA9_xY2WLtwleFlA= > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=J5Gs0N5MH_g9sSCZ6jNoZm_Dkc0EcHLbOVPcNwdqZ_4=xNWXpfkTzxBoF_c0HoPoyQ0c3v6DA9_xY2WLtwleFlA= > ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=J5Gs0N5MH_g9sSCZ6jNoZm_Dkc0EcHLbOVPcNwdqZ_4=4AkjVXY9i8VhAZjQ5gpQD1gtNh2arVzMoNoadhtUUbY= ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=J5Gs0N5MH_g9sSCZ6jNoZm_Dkc0EcHLbOVPcNwdqZ_4=4AkjVXY9i8VhAZjQ5gpQD1gtNh2arVzMoNoadhtUUbY= -- 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: [Rd] sum() returns NA on a long *logical* vector when nb of TRUE values exceeds 2^31
Hi Martin, On 06/07/2017 03:54 AM, Martin Maechler wrote: Martin Maechler <maech...@stat.math.ethz.ch> on Tue, 6 Jun 2017 09:45:44 +0200 writes: Hervé Pagès <hpa...@fredhutch.org> on Fri, 2 Jun 2017 04:05:15 -0700 writes: >> Hi, I have a long numeric vector 'xx' and I want to use >> sum() to count the number of elements that satisfy some >> criteria like non-zero values or values lower than a >> certain threshold etc... >> The problem is: sum() returns an NA (with a warning) if >> the count is greater than 2^31. For example: >>> xx <- runif(3e9) sum(xx < 0.9) >> [1] NA Warning message: In sum(xx < 0.9) : integer >> overflow - use sum(as.numeric(.)) >> This already takes a long time and doing >> sum(as.numeric(.)) would take even longer and require >> allocation of 24Gb of memory just to store an >> intermediate numeric vector made of 0s and 1s. Plus, >> having to do sum(as.numeric(.)) every time I need to >> count things is not convenient and is easy to forget. >> It seems that sum() on a logical vector could be modified >> to return the count as a double when it cannot be >> represented as an integer. Note that length() already >> does this so that wouldn't create a precedent. Also and >> FWIW prod() avoids the problem by always returning a >> double, whatever the type of the input is (except on a >> complex vector). >> I can provide a patch if this change sounds reasonable. > This sounds very reasonable, thank you Hervé, for the > report, and even more for a (small) patch. I was made aware of the fact, that R treats logical and integer very often identically in the C code, and in general we even mention that logicals are treated as 0/1/NA integers in arithmetic. For the present case that would mean that we should also safe-guard against *integer* overflow in sum(.) and that is not something we have done / wanted to do in the past... Speed being one reason. So this ends up being more delicate than I had thought at first, because changing sum() only would mean that sum(LOGI) and sum(as.integer(LOGI)) would start differ for a logical vector LOGI. So, for now this is something that must be approached carefully, and the R Core team may want discuss "in private" first. I'm sorry for having raised possibly unrealistic expectations. No worries. Thanks for taking my proposal into consideration. Note that the isum() function in src/main/summary.c is already using a 64-bit accumulator to accommodate intermediate sums > INT_MAX. So it should be easy to modify the function to make it overflow for much bigger final sums without altering performance. Seems like R_XLEN_T_MAX would be the natural threshold. Cheers, H. Martin > Martin >> Cheers, H. >> -- >> 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 >> __ >> R-devel@r-project.org mailing list >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIDAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=dyRNzyVdDYXzNX0sXIl5sdDqDXSxROm4-uM_XMquX_E=Qq6QdMWvudWgR_WGKdbBVNnVs5JO6s692MxjDo2JR9Y= > __ > R-devel@r-project.org mailing list > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIDAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=dyRNzyVdDYXzNX0sXIl5sdDqDXSxROm4-uM_XMquX_E=Qq6QdMWvudWgR_WGKdbBVNnVs5JO6s692MxjDo2JR9Y= -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprisingly, S4 classes with a "dim" or "dimnames" slot are final (in the Java sense)
Thanks Michael for taking care of this. H.
On 06/06/2017 11:48 AM, Michael Lawrence wrote:
I've fixed this and will commit soon.
Disregard my dim<-() example; that behaves as expected (the class needs
a dim<-() method).
Michael
On Tue, Jun 6, 2017 at 5:16 AM, Michael Lawrence <micha...@gene.com
<mailto:micha...@gene.com>> wrote:
Thanks for the report. The issue is that one cannot set special
attributes like names, dim, dimnames, etc on S4 objects. I was
aready working on this and will have a fix soon.
> a2 <- new("A2")
> dim(a2) <- c(2, 3)
Error in dim(a2) <- c(2, 3) : invalid first argument
On Mon, Jun 5, 2017 at 6:08 PM, Hervé Pagès <hpa...@fredhutch.org
<mailto:hpa...@fredhutch.org>> wrote:
Hi,
It's nice to be able to define S4 classes with slots that correspond
to standard attributes:
setClass("A1", slots=c(names="character"))
setClass("A2", slots=c(dim="integer"))
setClass("A3", slots=c(dimnames="list"))
By doing this, one gets a few methods for free:
a1 <- new("A1", names=letters[1:3])
names(a1) # "a" "b" "c"
a2 <- new("A2", dim=4:3)
nrow(a2) # 4
a3 <- new("A3", dimnames=list(NULL, letters[1:3]))
colnames(a3) # "a" "b" "c"
However, when it comes to subclassing, some of these slots cause
problems. I can extend A1:
setClass("B1", contains="A1")
but trying to extend A2 or A3 produces an error (with a
non-informative
message in the 1st case and a somewhat obscure one in the 2nd):
setClass("B2", contains="A2")
# Error in attr(prototype, slotName) <- attr(pri, slotName) :
# invalid first argument
setClass("B3", contains="A3")
# Error in attr(prototype, slotName) <- attr(pri, slotName) :
# 'dimnames' applied to non-array
So it seems that the presence of a "dim" or "dimnames" slot
prevents a
class from being extended. Is this expected? I couldn't find
anything
in TFM about this. Sorry if I missed it.
Thanks,
H.
--
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 <mailto:hpa...@fredhutch.org>
Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
__
R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
<https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwMFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=7MsydJAWI1B1wsZHDmsO-mpZ_vfvDpTo-YMHgUXrQKQ=dXHseRValxgm4TXgSsjasFRGgqAf46IivoNi4VnRj3o=>
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] surprisingly, S4 classes with a "dim" or "dimnames" slot are final (in the Java sense)
Hi,
It's nice to be able to define S4 classes with slots that correspond
to standard attributes:
setClass("A1", slots=c(names="character"))
setClass("A2", slots=c(dim="integer"))
setClass("A3", slots=c(dimnames="list"))
By doing this, one gets a few methods for free:
a1 <- new("A1", names=letters[1:3])
names(a1) # "a" "b" "c"
a2 <- new("A2", dim=4:3)
nrow(a2) # 4
a3 <- new("A3", dimnames=list(NULL, letters[1:3]))
colnames(a3) # "a" "b" "c"
However, when it comes to subclassing, some of these slots cause
problems. I can extend A1:
setClass("B1", contains="A1")
but trying to extend A2 or A3 produces an error (with a non-informative
message in the 1st case and a somewhat obscure one in the 2nd):
setClass("B2", contains="A2")
# Error in attr(prototype, slotName) <- attr(pri, slotName) :
# invalid first argument
setClass("B3", contains="A3")
# Error in attr(prototype, slotName) <- attr(pri, slotName) :
# 'dimnames' applied to non-array
So it seems that the presence of a "dim" or "dimnames" slot prevents a
class from being extended. Is this expected? I couldn't find anything
in TFM about this. Sorry if I missed it.
Thanks,
H.
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sum() returns NA on a long *logical* vector when nb of TRUE values exceeds 2^31
Hi, I have a long numeric vector 'xx' and I want to use sum() to count the number of elements that satisfy some criteria like non-zero values or values lower than a certain threshold etc... The problem is: sum() returns an NA (with a warning) if the count is greater than 2^31. For example: > xx <- runif(3e9) > sum(xx < 0.9) [1] NA Warning message: In sum(xx < 0.9) : integer overflow - use sum(as.numeric(.)) This already takes a long time and doing sum(as.numeric(.)) would take even longer and require allocation of 24Gb of memory just to store an intermediate numeric vector made of 0s and 1s. Plus, having to do sum(as.numeric(.)) every time I need to count things is not convenient and is easy to forget. It seems that sum() on a logical vector could be modified to return the count as a double when it cannot be represented as an integer. Note that length() already does this so that wouldn't create a precedent. Also and FWIW prod() avoids the problem by always returning a double, whatever the type of the input is (except on a complex vector). I can provide a patch if this change sounds reasonable. Cheers, H. -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Build problem with malbec2
Hi Roel,
It looks like Michael fixed rtracklayer yesterday and that
MutationalPatterns 1.2.1 could finally propagate:
http://bioconductor.org/checkResults/release/bioc-LATEST/MutationalPatterns/malbec2-buildsrc.html
The landing page should get updated soon:
http://bioconductor.org/packages/MutationalPatterns
Cheers,
H.
On 05/19/2017 06:34 AM, Janssen-10, R.R.E. wrote:
Dear Valerie,
Could we maybe do a manual build for the package, so that the bugfixed version
can be propagated to users?
Kind regards,
Roel Janssen
From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Janssen-10,
R.R.E. [r.r.e.janssen...@umcutrecht.nl]
Sent: Monday, May 15, 2017 3:06 PM
To: Michael Lawrence; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Build problem with malbec2
Dear Michael,
Do you have any indication on when we can expect the fix?
This is currently keeping Linux users from getting our latest bugfixed version.
Kind regards,
Roel Janssen
From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of Janssen-10,
R.R.E. [r.r.e.janssen...@umcutrecht.nl]
Sent: Wednesday, May 10, 2017 3:33 PM
To: Obenchain, Valerie; bioc-devel@r-project.org
Cc: Michael Lawrence
Subject: Re: [Bioc-devel] Build problem with malbec2
Dear Valerie,
Ok. And thanks Michael, for working on a fix.
Kind regards,
Roel Janssen
From: Obenchain, Valerie [valerie.obench...@roswellpark.org]
Hi Roel,
Looks like the problem is in rtracklayer (also red on the release build
report). I think Michael is aware of this and a fix will be coming soon.
Valerie
On 05/10/2017 02:23 AM, Janssen-10, R.R.E. wrote:
Dear Bioconductorians,
Is there something wrong with malbec2, or is there something broken in our
package?
See the build report:
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_release_bioc-2DLATEST_MutationalPatterns_malbec2-2Dbuildsrc.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=MyZsFQqdxhaBUOBrVJIhg41VpaZSbAcH1igpYP6eqtk=aZyiKKAhTq_cai7kxgmnhwn_NsQVyH5Zj4r-lFsMngA=
Kind regards,
Roel Janssen
--
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
--
This message may contain confidential information and is...{{dropped:6}}
___
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=MyZsFQqdxhaBUOBrVJIhg41VpaZSbAcH1igpYP6eqtk=f9IAqbtHYuIzQC6mMwh4kAZAYSgDDNUZMxSMSyzDtQs=
--
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: [Rd] stopifnot() does not stop at first non-TRUE argument
On 05/16/2017 09:59 AM, peter dalgaard wrote:
On 16 May 2017, at 18:37 , Suharto Anggono Suharto Anggono via R-devel
<r-devel@r-project.org> wrote:
switch(i, ...)
extracts 'i'-th argument in '...'. It is like
eval(as.name(paste0("..", i))) .
Hey, that's pretty neat!
Indeed! Seems like this topic is even more connected to switch()
than I anticipated...
H.
-pd
Just mentioning other things:
- For 'n',
n <- nargs()
can be used.
- sys.call() can be used in place of match.call() .
---
peter dalgaard
on Mon, 15 May 2017 16:28:42 +0200 writes:
I think Hervé's idea was just that if switch can evaluate arguments
selectively, so can stopifnot(). But switch() is .Primitive, so does it from C.
if he just meant that, then "yes, of course" (but not so interesting).
I think it is almost a no-brainer to implement a sequential stopifnot if
dropping to C code is allowed. In R it gets trickier, but how about this:
Something like this, yes, that's close to what Serguei Sokol had proposed
(and of course I *do* want to keep the current sophistication
of stopifnot(), so this is really too simple)
Stopifnot <- function(...)
{
n <- length(match.call()) - 1
for (i in 1:n)
{
nm <- as.name(paste0("..",i))
if (!eval(nm)) stop("not all true")
}
}
Stopifnot(2+2==4)
Stopifnot(2+2==5, print("Hey!!!") == "Hey!!!")
Stopifnot(2+2==4, print("Hey!!!") == "Hey!!!")
Stopifnot(T,T,T,T,T,T,T,T,T,T,T,T,T,T,T,T,F,T)
On 15 May 2017, at 15:37 , Martin Maechler
wrote:
I'm still curious about Hervé's idea on using switch() for the
issue.
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=mLJLORFCunDiCafHllurGVVVHiMf85ExkM7B5DngfIk=helOsmplADBmY6Ct7r30onNuD8a6GKz6yuSgjPxljeU=
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stopifnot() does not stop at first non-TRUE argument
On 05/15/2017 07:28 AM, peter dalgaard wrote:
I think Hervé's idea was just that if switch can evaluate arguments
selectively, so can stopifnot().
Yep.
Thanks,
H.
But switch() is .Primitive, so does it from C.
I think it is almost a no-brainer to implement a sequential stopifnot if
dropping to C code is allowed. In R it gets trickier, but how about this:
Stopifnot <- function(...)
{
n <- length(match.call()) - 1
for (i in 1:n)
{
nm <- as.name(paste0("..",i))
if (!eval(nm)) stop("not all true")
}
}
Stopifnot(2+2==4)
Stopifnot(2+2==5, print("Hey!!!") == "Hey!!!")
Stopifnot(2+2==4, print("Hey!!!") == "Hey!!!")
Stopifnot(T,T,T,T,T,T,T,T,T,T,T,T,T,T,T,T,F,T)
On 15 May 2017, at 15:37 , Martin Maechler <maech...@stat.math.ethz.ch> wrote:
I'm still curious about Hervé's idea on using switch() for the
issue.
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stopifnot() does not stop at first non-TRUE argument
Hi,
On 05/15/2017 10:41 AM, luke-tier...@uiowa.edu wrote:
This is getting pretty convoluted.
The current behavior is consistent with the description at the top of
the help page -- it does not promise to stop evaluation once the first
non-TRUE is found. That seems OK to me -- if you want sequencing you
can use
stopifnot(A)
stopifnot(B)
or
stopifnot(A && B)
My main use case for using stopifnot() is argument checking. In that
context, I like the conciseness of
stopifnot(
A,
B,
...
)
I think it's a common use case (and a pretty natural thing to do) to
order/organize the expressions in a way such that it only makes sense
to continue evaluating if all was OK so far e.g.
stopifnot(
is.numeric(x),
length(x) == 1,
is.na(x)
)
At least that's how things are organized in the stopifnot() calls that
accumulated in my code over the years. That's because I was convinced
that evaluation would stop at the first non-true expression (as
suggested by the man page). Until recently when I got a warning issued
by an expression located *after* the first non-true expression. This
was pretty unexpected/confusing!
If I can't rely on this "sequencing" feature, I guess I can always
do
stopifnot(A)
stopifnot(B)
...
but I loose the conciseness of calling stopifnot() only once.
I could also use
stopifnot(A && B && ...)
but then I loose the conciseness of the error message i.e. it's going
to be something like
Error: A && B && ... is not TRUE
which can be pretty long/noisy compared to the message that reports
only the 1st error.
Conciseness/readability of the single call to stopifnot() and
conciseness of the error message are the features that made me
adopt stopifnot() in the 1st place. If stopifnot() cannot be revisited
to do "sequencing" then that means I will need to revisit all my calls
to stopifnot().
I could see an argument for a change that in the multiple argumetn
case reports _all_ that fail; that would seem more useful to me than
twisting the code into knots.
Why not. Still better than the current situation. But only if that
semantic seems more useful to people. Would be sad if usefulness
of one semantic or the other was decided based on trickiness of
implementation.
Thanks,
H.
Best,
luke
On Mon, 15 May 2017, Martin Maechler wrote:
Serguei Sokol <so...@insa-toulouse.fr>
on Mon, 15 May 2017 16:32:20 +0200 writes:
> Le 15/05/2017 à 15:37, Martin Maechler a écrit :
>>>>>>> Serguei Sokol <so...@insa-toulouse.fr>
>>>>>>> on Mon, 15 May 2017 13:14:34 +0200 writes:
>> > I see in the archives that the attachment cannot pass.
>> > So, here is the code:
>>
>> [... MM: I needed to reformat etc to match closely to
>> the current source code which is in
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.r-2Dproject.org_R_trunk_src_library_base_R_stop.R=DwIFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=t9fJDOl9YG2zB-GF0wQXrXJTsW2jxTxMHE-qZfLGzHU=KGsvpXrXpHCFTdbLM9ci3sBNO9C3ocsgEqHMvZKvV9I=
>> or its corresponding github mirror
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wch_r-2Dsource_blob_trunk_src_library_base_R_stop.R=DwIFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=t9fJDOl9YG2zB-GF0wQXrXJTsW2jxTxMHE-qZfLGzHU=7Z5bPVWdGPpY2KLnXQP6c-_8s86CpKe0ZYkCfqjfxY0=
>> ]
>>
>> > Best,
>> > Serguei.
>>
>> Yes, something like that seems even simpler than Peter's
>> suggestion...
>>
>> It currently breaks 'make check' in the R sources,
>> specifically in tests/reg-tests-2.R (lines 6574 ff),
>> the new code now gives
>>
>> > ## error messages from (C-level) evalList
>> > tst <- function(y) { stopifnot(is.numeric(y)); y+ 1 }
>> > try(tst())
>> Error in eval(cl.i, pfr) : argument "y" is missing, with no default
>>
>> whereas previously it gave
>>
>> Error in stopifnot(is.numeric(y)) :
>> argument "y" is missing, with no default
>>
>>
>> But I think that change (of call stack in such an error case) is
>> unavoidable and not a big problem.
> It can be avoided but at price of customizing error() and
warning() calls with something like:
> wrn <- function(w) {w$call <- cl.i; warning(w)}
> err <- function(e) {e$call <- cl.i; stop(e)}
> ...
> tryCatch(r <- eval(cl.i, pfr), warning=wrn, error=err)
> Serguei.
Well, a good idea, but the 'warning' case is more complicated
(and the above incorrect): I do want the warning there, but
_not_ return the warning, but rather, the result of eval()
Re: [Bioc-devel] Question about BiocGeneric::order
On 05/11/2017 06:44 PM, Hervé Pagès wrote:
Hi Michael,
On 05/11/2017 03:27 PM, Michael Lawrence wrote:
There is a bug in S4Vectors, but thanks to an R 3.4 bug in the methods
package (recently fixed in devel), the bug is masked. So, we should
fix S4Vectors. The problem is that order,Rle has a default for the
'method' argument that differs from that of the generic. Since R 3.3,
base::order() is smart enough to basically do the same thing as
order,Rle(). I'll go ahead and remove the method.
Note that base::order() is much slower than the method for Rle objects:
Forgot to copy/paste this:
library(S4Vectors)
x <- Rle(sample(25L, 50L, replace=TRUE) - 8L,
sample(13L, 50L, replace=TRUE))
system.time(oo1 <- order(x))
user system elapsed
0.018 0.000 0.018
system.time(oo2 <- base::order(x))
user system elapsed
1.089 0.000 1.103
identical(oo1, oo2)
[1] TRUE
Looks like by default, base::order() does not pick up the fastest
method (radix):
system.time(oo2 <- base::order(x, method="radix"))
user system elapsed
0.020 0.000 0.019
and to provide my sessionInfo():
> sessionInfo()
R version 3.4.0 Patched (2017-04-26 r72630)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS
Matrix products: default
BLAS: /home/hpages/R/R-3.4.r72630/lib/libRblas.so
LAPACK: /home/hpages/R/R-3.4.r72630/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] parallel stats4stats graphics grDevices utils datasets
[8] methods base
other attached packages:
[1] S4Vectors_0.15.2BiocGenerics_0.23.0
loaded via a namespace (and not attached):
[1] compiler_3.4.0 tools_3.4.0
H.
H.
Michael
On Thu, May 11, 2017 at 1:29 PM, Ou, Jianhong
<jianhong...@umassmed.edu> wrote:
Thank you Hervé,
I got that. Good to know that BioC 3.6 require R 3.4.0.
Yours Sincerely,
Jianhong Ou
TEL: 508-856-5379
LRB 608
Bioinformatician of Bioinformatics core at
Department of Molecular, Cell and Cancer Biology
UMASS Medical School
364 Plantation Street Worcester,
MA 01605
Confidentiality Notice:
This e-mail message, including any attachments, is for the sole use
of the intended recipient(s) and may contain confidential,
proprietary and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender immediately and destroy or
permanently delete all copies of the original message.
On 5/11/17, 4:25 PM, "Hervé Pagès" <hpa...@fredhutch.org> wrote:
Hi Jianhong,
I can't reproduce this but I'm using R 3.4.0.
You seem to be using Bioc devel (aka BioC 3.6) with R devel.
This is not supported. Both, BioC 3.5 (current release) and
BioC 3.6 require R 3.4.0.
Cheers,
H.
On 05/11/2017 01:11 PM, Ou, Jianhong wrote:
> I got error when I try order for Rle object by following codes:
>
> library("BiocGenerics")
> library(XVector)
> order(Rle(1))
> ## Error in match.arg(method) : 'arg' must be of length 1
>
>> sessionInfo()
> R Under development (unstable) (2017-05-10 r72667)
> Platform: x86_64-apple-darwin16.5.0 (64-bit)
> Running under: macOS Sierra 10.12.4
>
> Matrix products: default
> BLAS:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
> LAPACK:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
>
> 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] stats4parallel stats graphics grDevices utils
datasets
> [8] methods base
>
> other attached packages:
> [1] XVector_0.17.0 IRanges_2.11.2 S4Vectors_0.15.1
> [4] BiocGenerics_0.23.0
>
> loaded via a namespace (and not attached):
> [1] zlibbioc_1.23.0 compiler_3.5.0
>
> Is this a bug? Or I should always add method argument?
>
> Yours Sincerely,
>
> Jianhong Ou
>
> TEL: 508-856-5379
> LRB 608
> Bioinformatician of Bioinformatics core at
> Department of Molecular, Cell and Cancer Biology
> UMASS Medical School
> 364 Plantation Street Worcester,
> MA 01605
>
> Confidentiality Notice:
> This e-mail message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential,
proprietary and privileged information. Any unauthorized re
Re: [Bioc-devel] Question about BiocGeneric::order
Hi Michael,
On 05/11/2017 03:27 PM, Michael Lawrence wrote:
There is a bug in S4Vectors, but thanks to an R 3.4 bug in the methods
package (recently fixed in devel), the bug is masked. So, we should
fix S4Vectors. The problem is that order,Rle has a default for the
'method' argument that differs from that of the generic. Since R 3.3,
base::order() is smart enough to basically do the same thing as
order,Rle(). I'll go ahead and remove the method.
Note that base::order() is much slower than the method for Rle objects:
> system.time(oo1 <- order(x))
user system elapsed
0.018 0.000 0.018
> system.time(oo2 <- base::order(x))
user system elapsed
1.089 0.000 1.103
> identical(oo1, oo2)
[1] TRUE
Looks like by default, base::order() does not pick up the fastest
method (radix):
> system.time(oo2 <- base::order(x, method="radix"))
user system elapsed
0.020 0.000 0.019
H.
Michael
On Thu, May 11, 2017 at 1:29 PM, Ou, Jianhong <jianhong...@umassmed.edu> wrote:
Thank you Hervé,
I got that. Good to know that BioC 3.6 require R 3.4.0.
Yours Sincerely,
Jianhong Ou
TEL: 508-856-5379
LRB 608
Bioinformatician of Bioinformatics core at
Department of Molecular, Cell and Cancer Biology
UMASS Medical School
364 Plantation Street Worcester,
MA 01605
Confidentiality Notice:
This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential, proprietary and privileged
information. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender
immediately and destroy or permanently delete all copies of the original
message.
On 5/11/17, 4:25 PM, "Hervé Pagès" <hpa...@fredhutch.org> wrote:
Hi Jianhong,
I can't reproduce this but I'm using R 3.4.0.
You seem to be using Bioc devel (aka BioC 3.6) with R devel.
This is not supported. Both, BioC 3.5 (current release) and
BioC 3.6 require R 3.4.0.
Cheers,
H.
On 05/11/2017 01:11 PM, Ou, Jianhong wrote:
> I got error when I try order for Rle object by following codes:
>
> library("BiocGenerics")
> library(XVector)
> order(Rle(1))
> ## Error in match.arg(method) : 'arg' must be of length 1
>
>> sessionInfo()
> R Under development (unstable) (2017-05-10 r72667)
> Platform: x86_64-apple-darwin16.5.0 (64-bit)
> Running under: macOS Sierra 10.12.4
>
> Matrix products: default
> BLAS:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
> LAPACK:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
>
> 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] stats4parallel stats graphics grDevices utils datasets
> [8] methods base
>
> other attached packages:
> [1] XVector_0.17.0 IRanges_2.11.2 S4Vectors_0.15.1
> [4] BiocGenerics_0.23.0
>
> loaded via a namespace (and not attached):
> [1] zlibbioc_1.23.0 compiler_3.5.0
>
> Is this a bug? Or I should always add method argument?
>
> Yours Sincerely,
>
> Jianhong Ou
>
> TEL: 508-856-5379
> LRB 608
> Bioinformatician of Bioinformatics core at
> Department of Molecular, Cell and Cancer Biology
> UMASS Medical School
> 364 Plantation Street Worcester,
> MA 01605
>
> Confidentiality Notice:
> This e-mail message, including any attachments, is for the sole use of
the intended recipient(s) and may contain confidential, proprietary and privileged
information. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender
immediately and destroy or permanently delete all copies of the original message.
>
>
>
> [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FhYaKPjNM3nCK5wrqNrek8IgmU7YlJH8B77AMM77j7U=N1wtJXFb6nsvQncKFe8tgzi_q8NunVLhu-gJoQA_Co8=
>
--
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 ma
Re: [Bioc-devel] Question about BiocGeneric::order
Hi Jianhong,
I can't reproduce this but I'm using R 3.4.0.
You seem to be using Bioc devel (aka BioC 3.6) with R devel.
This is not supported. Both, BioC 3.5 (current release) and
BioC 3.6 require R 3.4.0.
Cheers,
H.
On 05/11/2017 01:11 PM, Ou, Jianhong wrote:
I got error when I try order for Rle object by following codes:
library("BiocGenerics")
library(XVector)
order(Rle(1))
## Error in match.arg(method) : 'arg' must be of length 1
sessionInfo()
R Under development (unstable) (2017-05-10 r72667)
Platform: x86_64-apple-darwin16.5.0 (64-bit)
Running under: macOS Sierra 10.12.4
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib
LAPACK:
/Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
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] stats4parallel stats graphics grDevices utils datasets
[8] methods base
other attached packages:
[1] XVector_0.17.0 IRanges_2.11.2 S4Vectors_0.15.1
[4] BiocGenerics_0.23.0
loaded via a namespace (and not attached):
[1] zlibbioc_1.23.0 compiler_3.5.0
Is this a bug? Or I should always add method argument?
Yours Sincerely,
Jianhong Ou
TEL: 508-856-5379
LRB 608
Bioinformatician of Bioinformatics core at
Department of Molecular, Cell and Cancer Biology
UMASS Medical School
364 Plantation Street Worcester,
MA 01605
Confidentiality Notice:
This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential, proprietary and privileged
information. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender
immediately and destroy or permanently delete all copies of the original
message.
[[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FhYaKPjNM3nCK5wrqNrek8IgmU7YlJH8B77AMM77j7U=N1wtJXFb6nsvQncKFe8tgzi_q8NunVLhu-gJoQA_Co8=
--
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] Error in BUILD report (anamiR)
Hi Ti-Tai, Not much you or we can do about this. Hopefully the RMySQL Windows binary (currently 0.10.11) will soon be fixed on CRAN. Thanks for keeping an eye on the build results for anamiR. Best, H. On 05/04/2017 08:28 AM, 王棣台 wrote: Hi all, It turns out that this error is related to the RMySQL package(CRAN), and only happened in windows operating system. https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rstats-2Ddb_RMySQL_issues_190=DwIGog=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=VSEps9beT-guh1-ZsGnrNtM76EXvC0sLDGAvbHiyf7o=EttA79WmCSlSiTmcSwggrVyANbs5AysI8hyEOfn4MeI= It looks like it can be solved only if we downgraded the RMySQL version now. Can I choose not to import the newest RMySQL version while being tested in the BUILDREPORT? Ti-Tai 從: Obenchain, Valerie [valerie.obench...@roswellpark.org] 寄件日期: 2017年4月16日 上午 10:58 至: 王棣台; bioc-devel@r-project.org 主旨: Re: [Bioc-devel] Error in BUILD report (anamiR) It looks like this has been resolved on today's report: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bioconductor.org_checkResults_devel_bioc-2DLATEST_=DwIGog=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=VSEps9beT-guh1-ZsGnrNtM76EXvC0sLDGAvbHiyf7o=YqN2fHnUtseqzRMY6V06EubUXBY_m568PYWkUh0Zhb8= Valerie On 04/07/2017 02:21 PM, 王棣台 wrote: Hi all, I got en error when it tries to create vignette in BUILD: tokay2 Windows Server 2012 R2 Standard / x64 Error: processing vignette 'IntroductionToanamiR.Rmd' failed with diagnostics: could not run statement: Lost connection to MySQL server during query But for Linux or Mac, it all works. I have no idea how to solve this problem. Many thanks, Ti-Tai [[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=DwIGog=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=VSEps9beT-guh1-ZsGnrNtM76EXvC0sLDGAvbHiyf7o=qn1gkdYoqG_1sfJjLb27oOtHp3x8K4Brjgt_SaWXkIE= 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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGog=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=VSEps9beT-guh1-ZsGnrNtM76EXvC0sLDGAvbHiyf7o=qn1gkdYoqG_1sfJjLb27oOtHp3x8K4Brjgt_SaWXkIE= -- 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: [Rd] stopifnot() does not stop at first non-TRUE argument
On 05/03/2017 12:04 PM, Hervé Pagès wrote:
Not sure why the performance penalty of nonstandard evaluation would
be more of a concern here than for something like switch().
which is actually a primitive. So it seems that there is at least
another way to go than 'dots <- match.call(expand.dots=FALSE)$...'
Thanks,
H.
If that can't/won't be fixed, what about fixing the man page so it's
in sync with the current behavior?
Thanks,
H.
On 05/03/2017 02:26 AM, peter dalgaard wrote:
The first line of stopifnot is
n <- length(ll <- list(...))
which takes ALL arguments and forms a list of them. This implies
evaluation, so explains the effect that you see.
To do it differently, you would have to do something like
dots <- match.call(expand.dots=FALSE)$...
and then explicitly evaluate each argument in turn in the caller
frame. This amount of nonstandard evaluation sounds like it would
incur a performance penalty, which could be undesirable.
If you want to enforce the order of evaluation, there is always
stopifnot(A)
stopifnot(B)
-pd
On 3 May 2017, at 02:50 , Hervé Pagès <hpa...@fredhutch.org> wrote:
Hi,
It's surprising that stopifnot() keeps evaluating its arguments after
it reaches the first one that is not TRUE:
> stopifnot(3 == 5, as.integer(2^32), a <- 12)
Error: 3 == 5 is not TRUE
In addition: Warning message:
In stopifnot(3 == 5, as.integer(2^32), a <- 12) :
NAs introduced by coercion to integer range
> a
[1] 12
The details section in its man page actually suggests that it should
stop at the first non-TRUE argument:
‘stopifnot(A, B)’ is conceptually equivalent to
{ if(any(is.na(A)) || !all(A)) stop(...);
if(any(is.na(B)) || !all(B)) stop(...) }
Best,
H.
--
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
__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=JwgKhKD2k-9Kedeh6pqu-A8x6UEV0INrcxcSGVGo3Tg=f7IKJIhpRNJMC3rZAkuI6-MTdL3GAKSV2wK0boFN5HY=
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stopifnot() does not stop at first non-TRUE argument
Not sure why the performance penalty of nonstandard evaluation would
be more of a concern here than for something like switch().
If that can't/won't be fixed, what about fixing the man page so it's
in sync with the current behavior?
Thanks,
H.
On 05/03/2017 02:26 AM, peter dalgaard wrote:
The first line of stopifnot is
n <- length(ll <- list(...))
which takes ALL arguments and forms a list of them. This implies evaluation, so
explains the effect that you see.
To do it differently, you would have to do something like
dots <- match.call(expand.dots=FALSE)$...
and then explicitly evaluate each argument in turn in the caller frame. This
amount of nonstandard evaluation sounds like it would incur a performance
penalty, which could be undesirable.
If you want to enforce the order of evaluation, there is always
stopifnot(A)
stopifnot(B)
-pd
On 3 May 2017, at 02:50 , Hervé Pagès <hpa...@fredhutch.org> wrote:
Hi,
It's surprising that stopifnot() keeps evaluating its arguments after
it reaches the first one that is not TRUE:
> stopifnot(3 == 5, as.integer(2^32), a <- 12)
Error: 3 == 5 is not TRUE
In addition: Warning message:
In stopifnot(3 == 5, as.integer(2^32), a <- 12) :
NAs introduced by coercion to integer range
> a
[1] 12
The details section in its man page actually suggests that it should
stop at the first non-TRUE argument:
‘stopifnot(A, B)’ is conceptually equivalent to
{ if(any(is.na(A)) || !all(A)) stop(...);
if(any(is.na(B)) || !all(B)) stop(...) }
Best,
H.
--
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
__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=JwgKhKD2k-9Kedeh6pqu-A8x6UEV0INrcxcSGVGo3Tg=f7IKJIhpRNJMC3rZAkuI6-MTdL3GAKSV2wK0boFN5HY=
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stopifnot() does not stop at first non-TRUE argument
Hi,
It's surprising that stopifnot() keeps evaluating its arguments after
it reaches the first one that is not TRUE:
> stopifnot(3 == 5, as.integer(2^32), a <- 12)
Error: 3 == 5 is not TRUE
In addition: Warning message:
In stopifnot(3 == 5, as.integer(2^32), a <- 12) :
NAs introduced by coercion to integer range
> a
[1] 12
The details section in its man page actually suggests that it should
stop at the first non-TRUE argument:
‘stopifnot(A, B)’ is conceptually equivalent to
{ if(any(is.na(A)) || !all(A)) stop(...);
if(any(is.na(B)) || !all(B)) stop(...) }
Best,
H.
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Build error: "Could not fetch a url"
Hi Alper.
I'm not sure what cache that would be. Could the problem be on the
debrowser server side i.e. that the URL pointing to the PNG image
hosted on the debrowser server sometimes cannot be fetched because
the server is not accessible at that particular moment?
Cheers,
H.
On 05/01/2017 09:56 AM, Kucukural, Alper wrote:
Hi,
I got this error in debrowser builds that I shouldn't get. Since, it builds
without any problem most of the time but sometimes, I got this error below. Is
it reading the links from the cache? How can I solve it? It works most of the
time but sometimes I got this error like today.
pandoc.exe: Could not fetch
https://urldefense.proofpoint.com/v2/url?u=https-3A__debrowser.umassmed.edu_imgs_debrowser-5Fpics_figure-5F37.png=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=109-7bzPdWJduzYqsMNKU8xjUs5i9BMXVSxd-eIMpI8=KE89VEv9FF5xVm-izFAZ3ZRWAtMVm4vQVBeiHzp-1sk=
HttpExceptionRequest Request {
host =
"debrowser.umassmed.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__debrowser.umassmed.edu=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=109-7bzPdWJduzYqsMNKU8xjUs5i9BMXVSxd-eIMpI8=VJRx5_F7s5myF9UdP3Hqs23gakiwG75jrzFA9uEvsLU=
>"
port = 443
secure = True
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_release_bioc-2DLATEST_debrowser_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=109-7bzPdWJduzYqsMNKU8xjUs5i9BMXVSxd-eIMpI8=FwZZbUgi-isEODu5QLy0m6MWkZKHVzApqTcFXpH0jFQ=
Thanks,
Alper Kucukural
[[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=109-7bzPdWJduzYqsMNKU8xjUs5i9BMXVSxd-eIMpI8=UYGsX4KQsojfi39glCHpvL-GC5CjSg8LSzjCwn0OGSA=
--
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: [Rd] byte-compiler bug
On 04/26/2017 04:46 PM, luke-tier...@uiowa.edu wrote:
Thanks for the report. Fixed in R_devel with r72631; I'll port to
R-patched later today or tomorrow.
Thanks!
The default setting and how to get the current settings are documented
in the Details section of the enableJIT help page at the end of the
paragraph for enableJIT.
Indeed. Sorry for missing that (I was playing with several versions
of R and probably looked at the enableJIT man page in the wrong R).
H.
Best,
luke
On Wed, 26 Apr 2017, Hervé Pagès wrote:
Hi,
I'm running into a case where byte-compilation changes
the semantic of a function. This is with R 3.4.0:
foo <- function(x) { TRUE && x }
foo(c(a=FALSE))
# [1] FALSE # OK
foo(c(a=TRUE))
# [1] TRUE # OK
foo(c(a=FALSE))
# a #
# FALSE
The 3rd call returned a result that it different from the 1st
call!
After scratching my head for a while, I found out that there
is a lot going on:
1) When calling foo the first 2 times, the function is not
byte-compiled so is behaving as expected.
2) However after the 2nd call, the function gets automatically
compiled. This seems to be a new feature in R 3.4.0 but
you'll have to grep the NEWS file to find out (search for
JIT). The man page for cmpfun/enableJIT nicely explains
the JIT levels but I couldn't find anywhere that the level
is set to 3 by default. I don't even know how one is
supposed to get the current level. Calling enableJIT() to
change the level returns a value, and this value might
look like the previous level, but this is undocumented and
it returns 0 instead of 3 the 1st time I call it anyway.
3) There is some bug in the byte-compiler that seems to make it
treat `&&` like if it were `&` when compiling foo.
Cheers,
H.
> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.2 LTS
Matrix products: default
BLAS: /home/biocbuild/bbs-3.5-bioc/R/lib/libRblas.so
LAPACK: /home/biocbuild/bbs-3.5-bioc/R/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.0
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] byte-compiler bug
On 04/26/2017 01:51 PM, Duncan Murdoch wrote:
On 26/04/2017 4:36 PM, Hervé Pagès wrote:
Hi,
I'm running into a case where byte-compilation changes
the semantic of a function. This is with R 3.4.0:
foo <- function(x) { TRUE && x }
foo(c(a=FALSE))
# [1] FALSE # OK
foo(c(a=TRUE))
# [1] TRUE # OK
foo(c(a=FALSE))
# a #
# FALSE
The 3rd call returned a result that it different from the 1st
call!
That does look like a bug. Please file a bug report.
After scratching my head for a while, I found out that there
is a lot going on:
1) When calling foo the first 2 times, the function is not
byte-compiled so is behaving as expected.
2) However after the 2nd call, the function gets automatically
compiled. This seems to be a new feature in R 3.4.0 but
you'll have to grep the NEWS file to find out (search for
JIT).
The NEWS file is where we usually report news, so this isn't really that
much of a surprise. If you don't want to read it all at once, you can
see it as it changes on the RSS feed at
https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.org_RSSfeeds.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=2Qn1jcR4dORPq3qVhYNnz_O64UneKth6ebbeC4CEtRI=O1JVjaNkaGIrMcR0qo58R2OrzIk0nOMoL89tskLXeK0=
The surprise here is that this feature is not documented in TFM.
If you're trying to understand a feature and you don't know it's a
new feature, NEWS is not necessarily the 1st place you go.
NEWS is not TFM. 'svn log' in not TFM.
H.
The man page for cmpfun/enableJIT nicely explains
the JIT levels but I couldn't find anywhere that the level
is set to 3 by default. I don't even know how one is
supposed to get the current level. Calling enableJIT() to
change the level returns a value, and this value might
look like the previous level, but this is undocumented and
it returns 0 instead of 3 the 1st time I call it anyway.
3) There is some bug in the byte-compiler that seems to make it
treat `&&` like if it were `&` when compiling foo.
It's a bug, but that doesn't describe it completely. TRUE & c(a=TRUE,
b=FALSE) doesn't give the same thing as foo(c(a=TRUE, b=FALSE)).
Duncan Murdoch
Cheers,
H.
> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.2 LTS
Matrix products: default
BLAS: /home/biocbuild/bbs-3.5-bioc/R/lib/libRblas.so
LAPACK: /home/biocbuild/bbs-3.5-bioc/R/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.0
__
R-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=2Qn1jcR4dORPq3qVhYNnz_O64UneKth6ebbeC4CEtRI=pXXxO1dFT00kYhhUuO35VRCEYFiw6n2Sz4nSMb6OdxQ=
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] byte-compiler bug
Hi,
I'm running into a case where byte-compilation changes
the semantic of a function. This is with R 3.4.0:
foo <- function(x) { TRUE && x }
foo(c(a=FALSE))
# [1] FALSE # OK
foo(c(a=TRUE))
# [1] TRUE # OK
foo(c(a=FALSE))
# a #
# FALSE
The 3rd call returned a result that it different from the 1st
call!
After scratching my head for a while, I found out that there
is a lot going on:
1) When calling foo the first 2 times, the function is not
byte-compiled so is behaving as expected.
2) However after the 2nd call, the function gets automatically
compiled. This seems to be a new feature in R 3.4.0 but
you'll have to grep the NEWS file to find out (search for
JIT). The man page for cmpfun/enableJIT nicely explains
the JIT levels but I couldn't find anywhere that the level
is set to 3 by default. I don't even know how one is
supposed to get the current level. Calling enableJIT() to
change the level returns a value, and this value might
look like the previous level, but this is undocumented and
it returns 0 instead of 3 the 1st time I call it anyway.
3) There is some bug in the byte-compiler that seems to make it
treat `&&` like if it were `&` when compiling foo.
Cheers,
H.
> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.2 LTS
Matrix products: default
BLAS: /home/biocbuild/bbs-3.5-bioc/R/lib/libRblas.so
LAPACK: /home/biocbuild/bbs-3.5-bioc/R/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.0
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] error related to kmp_runtime.cpp(6480)
Hi Vlad, veracruz2 uses clang 4.0.0 instead of the compilers shipped with Xcode. See: http://www.bioconductor.org/checkResults/devel/bioc-LATEST/veracruz2-NodeInfo.html About 1 month ago the CRAN folks decided to use El Capitan + clang 4.0.0 for building the R and package binaries distributed on CRAN. So we're just following their lead on this. We installed clang 4.0.0 on veracruz2 by extracting the tarball provided here: http://r.research.att.com/libs/ My understanding is that one of the motivations for them to use clang 4.0.0 is that it has built-in support for OpenMP. I don't know how you are set up on your laptop but if you install packages from source then make sure to use clang 4.0.0 if you want to increase your chances to reproduce this error. In particular, make sure that mzR and MSnbase have been compiled with clang 4.0.0. You also want to make sure that you're using the official CRAN binary for R 3.4: https://cran.r-project.org/bin/macosx/ Thanks for looking into this. Cheers, H. On 04/24/2017 01:43 PM, Vladislav Petyuk wrote: My package passes all the builds except OS X. https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bioconductor.org_checkResults_devel_bioc-2DLATEST_MSnID_veracruz2-2Dbuildsrc.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=OPWgCqsx47iwIB3NpYwWet16UFW8gVYtAhsTwiBNMd0=4_qAn837g-e8T6YpPM_KA6V73MrtoDd0E-NTiisSl8M= Interestingly, the build goes just fine (with the same arguments) on my laptop, which is OS X 10.12.3. Given that kmp_runtime.cpp is from OpenMP and chunk 25 in the vignette indirectly engages `mclapply`, my hunch is that this is something to do with parallel processing. Is multithreading not allowed on this OS X machine? Is simply forcing mc.cores = 1 going to solve the problem? Any other suggestions on what is this error about and how to handle it? Thanks, Vlad [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=OPWgCqsx47iwIB3NpYwWet16UFW8gVYtAhsTwiBNMd0=8uuqR-nZvvgUqZ1Di0WLso-7ap9VByOdbS8gRVZzCTI= -- 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] Vignette update after change in git mirror repo
Nothing strange about this. As I said, all packages are built and checked daily and the build report is updated every day with the new results. But there is a lag between your changes in svn and what you see in the build report. More precisely, yesterday's report didn't reflect your latest changes yet because you made them on Apr 21 after the builds started. The 'Snapshot Date' information on the report tells you when the builds started. Also the 'Last Changed Rev' and 'Last Changed Date' information tells you which revision of your package is showing up in the report. Hope this helps, H. On 04/23/2017 06:29 PM, Maia Smith wrote: Thanks, Hervé. Very strange, when I checked that link earlier today, it appeared to still have errors. All good now! On Sun, Apr 23, 2017 at 4:49 PM, Hervé Pagès <hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>> wrote: Hi Maia, On 04/23/2017 10:09 AM, Maia Smith wrote: Just an update - the checked in code is passing R CMD check on my computer (no errors, 1 warning), and has a version bump from 0.99.9 to 0.99.10, but I still haven't seen a build attempt on bioconductor since I committed the code a few days ago. Not sure where you are looking at or what you mean exactly by "build attempt" but, unless our build system is down, every Bioconductor software package gets built and checked every day. timescape is no exception: https://bioconductor.org/checkResults/3.5/bioc-LATEST/timescape/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_3.5_bioc-2DLATEST_timescape_=DwMFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=au6Kb9Cm9VY8dX1RswkHcmWguNuvc5kctfqMH0i2CXw=8sfhDXEQz-lEhf-yL6sh9-5zs2epIXIHEq5d-v0Y0pg=> Cheers, H. I'm a bit worried because I know the release is occurring tomorrow... On Sat, Apr 22, 2017 at 3:34 PM, Maia Smith <ma...@sfu.ca <mailto:ma...@sfu.ca>> wrote: Thank you, Sean and James! I think this fixed the problem, Sean - will know when the build is finished today. MUCH appreciated. On Fri, Apr 21, 2017 at 4:13 PM, Sean Davis <seand...@gmail.com <mailto:seand...@gmail.com>> wrote: Sorry I lead you astray, earlier, Maia. In general, you do not need to install the package in the vignette. The first code block in the vignette where you did "eval=FALSE" is the way to go. The second code block where you actually do the installation is unnecessary. The package is installed by R in order to build the vignette. Sean [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org <mailto: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=QzqBONt6vp_Oq6FB3KMJerSAAggLgiauNhROOSs0EzM=Qc0PP8DM7D6TVI78OCfBh9S_0CfQMWRvo-5yiuKfCkA= <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=QzqBONt6vp_Oq6FB3KMJerSAAggLgiauNhROOSs0EzM=Qc0PP8DM7D6TVI78OCfBh9S_0CfQMWRvo-5yiuKfCkA=> -- 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 <mailto:hpa...@fredhutch.org> Phone: (206) 667-5791 <tel:%28206%29%20667-5791> Fax:(206) 667-1319 <tel:%28206%29%20667-1319> -- 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] Vignette update after change in git mirror repo
Hi Maia, On 04/23/2017 10:09 AM, Maia Smith wrote: Just an update - the checked in code is passing R CMD check on my computer (no errors, 1 warning), and has a version bump from 0.99.9 to 0.99.10, but I still haven't seen a build attempt on bioconductor since I committed the code a few days ago. Not sure where you are looking at or what you mean exactly by "build attempt" but, unless our build system is down, every Bioconductor software package gets built and checked every day. timescape is no exception: https://bioconductor.org/checkResults/3.5/bioc-LATEST/timescape/ Cheers, H. I'm a bit worried because I know the release is occurring tomorrow... On Sat, Apr 22, 2017 at 3:34 PM, Maia Smith <ma...@sfu.ca> wrote: Thank you, Sean and James! I think this fixed the problem, Sean - will know when the build is finished today. MUCH appreciated. On Fri, Apr 21, 2017 at 4:13 PM, Sean Davis <seand...@gmail.com> wrote: Sorry I lead you astray, earlier, Maia. In general, you do not need to install the package in the vignette. The first code block in the vignette where you did "eval=FALSE" is the way to go. The second code block where you actually do the installation is unnecessary. The package is installed by R in order to build the vignette. Sean [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=QzqBONt6vp_Oq6FB3KMJerSAAggLgiauNhROOSs0EzM=Qc0PP8DM7D6TVI78OCfBh9S_0CfQMWRvo-5yiuKfCkA= -- 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] xps build problem on veracruz2
On 04/23/2017 12:15 PM, cstrato wrote: Dear Herve, I have just seen that the newest build xps_1.3.3: https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_xps_veracruz2-2Dbuildsrc.html=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=mrLGN0PjKvBtL6gLXpX8Q1TVC5RtZNMk4pZamOjQi2o=ZEHBjBTxOazamSZVumdls85OBYuWJInbBU0MEarY2OE= still results in an error. Please understand that the build report is lagging behind your latest activities on the package. Today's report says: Snapshot Date: 2017-04-22 17:18:01 -0400 (Sat, 22 Apr 2017) and your rpath fix is from this morning: hpages@latitude:~/svn/bioconductor/Rpacks/xps$ svn log -r 129056 r129056 | c.stratowa | 2017-04-23 08:07:00 -0700 (Sun, 23 Apr 2017) | 2 lines update to xps-1.35.4 - update rpath H. This is probably due to the fact that it still requires $ROOTSYS. I hope that my current upload xps_1.3.4 has eliminated this dependency (see my mail below). Best regards, Christian On 04/23/17 17:31, cstrato wrote: Dear Herve, Since some users report problems since many years that the libs are found in '/usr/local/root/lib/root', I agree that it is a good idea to set LDFLAGS also to LDFLAGS = ... -rpath $(shell $(ROOTCONFIG) --prefix)/lib/root I have just uploaded version xps_1.3.4 to BioC devel. In this version I have added - LDFLAGS = ... -rpath $(shell $(ROOTCONFIG) --prefix)/lib/root - Furthermore, I have removed the dependency on the variable $ROOTSYS in the case ROOT is installed in fixed location. (see Makefile.arch line 47 and Makefile line 115) - I have also added an INSTALL file (which I need to update). I understand that you have built ROOT using the new build system with 'cmake'. On Yosemite and earlier machines you can (and probably should) use the old build system using 'make', which is described in: https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_build-2Droot-2Dold-2Dmethod=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=mrLGN0PjKvBtL6gLXpX8Q1TVC5RtZNMk4pZamOjQi2o=jpz0-unZsEzxF9QEqOrMLG7y59pLxuv6K_ZqP0gUbmo= Interestingly, there is the statement: Using the fixed location mode, the default "--prefix" path is `/usr/local', which will result in the ROOT files to be installed in `/usr/local/bin', `/usr/local/lib/root', etc. This means probably, that you could use: cmake -DCMAKE_INSTALL_PREFIX=/usr/local but maybe you still end up with libs in /usr/local/root/lib/root. BTW, on Sierra I have just upgraded to the new version R-3.4.0.pkg. I must realize that R-3.4.0 requires El Capitan or higher, which means that people using Yosemite or Mavericks can no longer upgrade to the newest version of R! Is this correct? Best regards, Christian P.S.: I am not sure if the following information is of interest to you, but I was looking at my old mails and I searching the ROOT forum, where users also report problems since the libraries got installed under /usr/local/root/lib/root: 1, One series of mails is from/to Dan with cc to you from 03/17/12 regarding installing ROOT on openSUSE 12.1. He mentioned that the libs were stored in /usr/local/root/lib/root. My response was that he only need to change prefix to "--prefix=/usr/local". However he reported that the problem was lack of read and listing permissions on the /etc/root directory. 2, One user recently (Mar 2016) tried to install ROOT 6 on Ubuntu 14.04.4, see: https://urldefense.proofpoint.com/v2/url?u=https-3A__root-2Dforum.cern.ch_t_rootn-2Dexe-2Dstartup-2Dcrashes-2Don-2Dubuntu-2D14-2D04-2D4_20825_11=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=mrLGN0PjKvBtL6gLXpX8Q1TVC5RtZNMk4pZamOjQi2o=82sayza_dHZujyTaKcKBVovo-64NMD7uZbfE2W5gMu4= and reported, e.g. /usr/local/root/lib/root/libCore.so He then tried: cmake -DCMAKE_INSTALL_PREFIX="/usr/local" /home/johnsont/rootsrc/root-6.06.02 cmake --build . sudo cmake --build . --target install It seems that now the libraries did install correctly (but there were other issues). 3, One user had compilation problems on OS Sierra (Oct 2016), see: https://urldefense.proofpoint.com/v2/url?u=https-3A__root-2Dforum.cern.ch_t_compilation-2Dproblem-2Dwith-2Dos-2Dsierra-2Dxcode-2D8-2Droot-2D6-2D06-2D08_22102_6=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=mrLGN0PjKvBtL6gLXpX8Q1TVC5RtZNMk4pZamOjQi2o=hrIBBK0fqAFQNmW8a8vTIHbmcNOB7IVjsclAMGCjKLY= There was an interesting reply: Better don't use -j4 when using cmake, just when using make. I am not sure whether this is still true, since it seems to work in your case. On 04/23/17 02:32, Hervé Pagès wrote: On 04/22/2017 02:57 PM, cstrato wrote: Dear Herve, Thank you for your efforts to get xps running. I will make the changes in
Re: [Bioc-devel] xps build problem on veracruz2
Hi Christian, Thanks for the update. Glad it works for you. One small thing is that, if CMAKE_INSTALL_PREFIX is specified when configuring ROOT, the ROOT libs get installed under /lib/root, not under /lib. I was surprised by this, but that's what I got when I installed ROOT on veracruz2. I configured with: export CC=/usr/local/clang4/bin/clang export CXX=/usr/local/clang4/bin/clang++ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/root -Dgnuinstall=ON -Dfortran=OFF -Dmysql=OFF -Dsqlite=OFF ../root Then built with: cmake --build . -- -j4 Then installed with: sudo cmake --build . --target install And the libraries got installed under /usr/local/root/lib/root So when trying to install the latest xps, loading xps.so failed for me because the ROOT libraries were not found. The following change to Makefile.arch fixed the problem: $ svn diff Makefile.arch Index: Makefile.arch === --- Makefile.arch (revision 129046) +++ Makefile.arch (working copy) @@ -261,7 +261,7 @@ CXXFLAGS = $(OPT2) -pipe -Wall -W -Woverloaded-virtual LD= $(MACOSXTARGET) g++ #LDFLAGS = $(OPT2) -LDFLAGS = $(OPT2) -rpath $(shell $(ROOTCONFIG) --prefix)/lib +LDFLAGS = $(OPT2) -rpath $(shell $(ROOTCONFIG) --prefix)/lib -rpath $(shell $(ROOTCONFIG) --prefix)/lib/root UNDEFOPT = dynamic_lookup # The SOFLAGS will be used to create the .dylib, # the .so will be created separately Also note that the rpaths specified at linking time get hardcoded in xps.so: veracruz2:src biocbuild$ otool -l xps.so | tail -n 18 Load command 31 cmd LC_RPATH cmdsize 32 path /usr/local/root/lib (offset 12) Load command 32 cmd LC_RPATH cmdsize 40 path /usr/local/root/lib/root (offset 12) Load command 33 cmd LC_FUNCTION_STARTS cmdsize 16 dataoff 4141784 datasize 14336 Load command 34 cmd LC_DATA_IN_CODE cmdsize 16 dataoff 4156120 datasize 904 So the end user will need to have the ROOT libraries at these locations too (unless s/he installs from source of course). This would need to be explained in xps README file (which BTW should preferably be named INSTALL). Thanks, H. On 04/22/2017 05:15 AM, cstrato wrote: Dear Herve, I am glad to inform you that I have just uploaded version xps_1.35.3 to BioC-dev branch. I have followed your suggestion to use -rpath and have eliminated the environment variables DYLD_LIBRARY_PATH and LD_LIBRARY_PATH. I have tested the new version on both Yosemite and on Sierra with csrutil enabled! Thus I assume that it will also run on El Capitan. Best regards, Christian P.S.: Please allow me to comment on your note on [DY]LD_LIBRARY_PATH. As you know xps was uploaded to Bioc 10 years ago (with your kind help) and is available on BioC since 9 years. At that time the environment variables [DY]LD_LIBRARY_PATH were necessary, and for many years required by ROOT. Since xps did run on the Mac on all systems from Leopard till Yosemite w/o problems I had no need to change it. Furthermore, I had not heard that the use of these variables have been discouraged, just like many other developers who only now realize that they have to use rpath or simply disable csrutil (I have realized this when googling around). On 04/21/17 00:29, Hervé Pagès wrote: Also relying on [DY]LD_LIBRARY_PATH is considered bad practice and has been discouraged for years. xps is the only Bioconductor package that relies on these variables for its configure/build process. H. On 04/20/2017 03:24 PM, Dan Tenenbaum wrote: Disabling SIP should not be done anywhere. Every page I've read on this topic strongly discourages doing this. - Original Message - From: "Hervé Pagès" <hpa...@fredhutch.org> To: "cstrato" <cstr...@aon.at>, "Dan Tenenbaum" <dtene...@fredhutch.org> Cc: "bioc-devel" <bioc-devel@r-project.org> Sent: Thursday, April 20, 2017 3:17:23 PM Subject: Re: [Bioc-devel] xps build problem on veracruz2 On 04/20/2017 03:01 PM, cstrato wrote: Dear Herve, Doing 'csrutil disable' does indeed solve the problem, since: 1, in this way I was able to build xps on Mac OS Sierra 2, in this way I could already help one user of xps, see: https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_90056_-2390247=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg=GfzgU1Ibm_scFWO58Mv_ZfxKtn-FSJgkxMW1ZBYK1Vs= This means, that users of xps seem to be willing to disable csrutil. I'm not a statistician but I wouldn't draw conclusions from a sample of size 1. Mac users who cannot install xps on their machine will use something else, or, if they desperately need xps, they will grab a Linux box. Sorry but disabling SIP on our Mac builders is not an option. However, I just realized that there may be an e
Re: [Bioc-devel] xps build problem on veracruz2
Also relying on [DY]LD_LIBRARY_PATH is considered bad practice and has been discouraged for years. xps is the only Bioconductor package that relies on these variables for its configure/build process. H. On 04/20/2017 03:24 PM, Dan Tenenbaum wrote: Disabling SIP should not be done anywhere. Every page I've read on this topic strongly discourages doing this. - Original Message - From: "Hervé Pagès" <hpa...@fredhutch.org> To: "cstrato" <cstr...@aon.at>, "Dan Tenenbaum" <dtene...@fredhutch.org> Cc: "bioc-devel" <bioc-devel@r-project.org> Sent: Thursday, April 20, 2017 3:17:23 PM Subject: Re: [Bioc-devel] xps build problem on veracruz2 On 04/20/2017 03:01 PM, cstrato wrote: Dear Herve, Doing 'csrutil disable' does indeed solve the problem, since: 1, in this way I was able to build xps on Mac OS Sierra 2, in this way I could already help one user of xps, see: https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_90056_-2390247=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg=GfzgU1Ibm_scFWO58Mv_ZfxKtn-FSJgkxMW1ZBYK1Vs= This means, that users of xps seem to be willing to disable csrutil. I'm not a statistician but I wouldn't draw conclusions from a sample of size 1. Mac users who cannot install xps on their machine will use something else, or, if they desperately need xps, they will grab a Linux box. Sorry but disabling SIP on our Mac builders is not an option. However, I just realized that there may be an even greater problem, namely, which version of ROOT should a user install? People can download ROOT binaries built with XCode 7.x from: https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_content_release-2D53436=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg=LByiYPyOfsHnRc9oOqXOs9xMcfltktXgkTQ3sh5hKFc= for OS X 10.10 and 10.11. Thus for El Capitan they can download the following binaries: - root_v5.34.36.macosx64-10.11-clang70.dmg - root_v5.34.36.macosx64-10.11-clang70.tar.gz Did you install one of those binaries or did you compile ROOT from source? As I said earlier, I compiled ROOT 5 from source on veracruz2. With the help of my README file people could compile ROOT from source for XCode 8.x. However, you have mentioned that the CRAN people are using clang 4.0.0 for producing the Mac binaries of R and CRAN packages and thus you are using the same on veracruz2. Yes. Did you compile ROOT with XCode 7 or 8 or did you use clang 4.0.0, which is not officially supported by Apple? With clang 4.0.0. The question is whether xps built with this version of ROOT will work with the ROOT binaries which people can download from ROOT? I guess someone will need to figure this out. Note that if people need to compile their own ROOT anyway in order to be able to use the xps binary we distribute, then they should also be able to install xps from source. So that defeats the purpose of providing a binary in the first place. Cheers, H. Best regards, Christian On 04/20/17 20:00, Hervé Pagès wrote: On 04/20/2017 10:59 AM, Hervé Pagès wrote: Hi Christian, Disabling 'csrutil disable' might help xps on veracruz2 but that ^^ oops, no double negative intended here. I meant, doing 'csrutil disable' might help... etc H. won't help your end users. I'm no expert in developing a package on Mac but other people on this list are. Also R-SIG-Mac might be a good place to seek help for this. Cheers, H. On 04/20/2017 10:53 AM, cstrato wrote: Dear Herve, Thank you for your efforts to try to install xps. I am glad to hear that you could build ROOT 5 from source. It's a pity that Apple does no longer allow the use of DYLD_LIBRARY_PATH. This seems to break the code of a lot of people (when googling around). I will try to change the build process and will see if I succeed. However, at the moment I have a couple of questions: 1, Is there any reason that you do not want to 'csrutil disable'? 2, It is easy to delete the test for DYLD_LIBRARY_PATH in my 'configure.in' file, however, I have also to change the 'Makefile'. Since you say that the problem can be solved by adding the -rpath flag when linking, I assume that I have to change the following line in my 'Makefile': $(LD) -bundle $(LDFLAGS) $^ $(GLIBS) $(MYLIBS) \ $(OutPutOpt) $(subst .$(DllSuf),.so,$@) Since I am not familiar with -rpath can you give me a hint how to change it? 3, There is a Wikipedia explanation for '-rpath', see: https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Rpath=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=ge_d4eBoKDAggNWVQUzMVPAJy250VlZuPTXcPyr20HM= Interestingly, there is the following line: 'Instead
Re: [Bioc-devel] xps build problem on veracruz2
On 04/20/2017 03:01 PM, cstrato wrote: Dear Herve, Doing 'csrutil disable' does indeed solve the problem, since: 1, in this way I was able to build xps on Mac OS Sierra 2, in this way I could already help one user of xps, see: https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_90056_-2390247=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg=GfzgU1Ibm_scFWO58Mv_ZfxKtn-FSJgkxMW1ZBYK1Vs= This means, that users of xps seem to be willing to disable csrutil. I'm not a statistician but I wouldn't draw conclusions from a sample of size 1. Mac users who cannot install xps on their machine will use something else, or, if they desperately need xps, they will grab a Linux box. Sorry but disabling SIP on our Mac builders is not an option. However, I just realized that there may be an even greater problem, namely, which version of ROOT should a user install? People can download ROOT binaries built with XCode 7.x from: https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_content_release-2D53436=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q0hKDI_veZEYmjrYbsK1Xqu--fGdfl_JmfSKLygl_dg=LByiYPyOfsHnRc9oOqXOs9xMcfltktXgkTQ3sh5hKFc= for OS X 10.10 and 10.11. Thus for El Capitan they can download the following binaries: - root_v5.34.36.macosx64-10.11-clang70.dmg - root_v5.34.36.macosx64-10.11-clang70.tar.gz Did you install one of those binaries or did you compile ROOT from source? As I said earlier, I compiled ROOT 5 from source on veracruz2. With the help of my README file people could compile ROOT from source for XCode 8.x. However, you have mentioned that the CRAN people are using clang 4.0.0 for producing the Mac binaries of R and CRAN packages and thus you are using the same on veracruz2. Yes. Did you compile ROOT with XCode 7 or 8 or did you use clang 4.0.0, which is not officially supported by Apple? With clang 4.0.0. The question is whether xps built with this version of ROOT will work with the ROOT binaries which people can download from ROOT? I guess someone will need to figure this out. Note that if people need to compile their own ROOT anyway in order to be able to use the xps binary we distribute, then they should also be able to install xps from source. So that defeats the purpose of providing a binary in the first place. Cheers, H. Best regards, Christian On 04/20/17 20:00, Hervé Pagès wrote: On 04/20/2017 10:59 AM, Hervé Pagès wrote: Hi Christian, Disabling 'csrutil disable' might help xps on veracruz2 but that ^^ oops, no double negative intended here. I meant, doing 'csrutil disable' might help... etc H. won't help your end users. I'm no expert in developing a package on Mac but other people on this list are. Also R-SIG-Mac might be a good place to seek help for this. Cheers, H. On 04/20/2017 10:53 AM, cstrato wrote: Dear Herve, Thank you for your efforts to try to install xps. I am glad to hear that you could build ROOT 5 from source. It's a pity that Apple does no longer allow the use of DYLD_LIBRARY_PATH. This seems to break the code of a lot of people (when googling around). I will try to change the build process and will see if I succeed. However, at the moment I have a couple of questions: 1, Is there any reason that you do not want to 'csrutil disable'? 2, It is easy to delete the test for DYLD_LIBRARY_PATH in my 'configure.in' file, however, I have also to change the 'Makefile'. Since you say that the problem can be solved by adding the -rpath flag when linking, I assume that I have to change the following line in my 'Makefile': $(LD) -bundle $(LDFLAGS) $^ $(GLIBS) $(MYLIBS) \ $(OutPutOpt) $(subst .$(DllSuf),.so,$@) Since I am not familiar with -rpath can you give me a hint how to change it? 3, There is a Wikipedia explanation for '-rpath', see: https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Rpath=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=ge_d4eBoKDAggNWVQUzMVPAJy250VlZuPTXcPyr20HM= Interestingly, there is the following line: 'Instead of specifying the -rpath to the linker, the environment variable LD_RUN_PATH can be set to the same effect.' Do you think that using LD_RUN_PATH would solve the problem? If yes, then how? 4, Googling for the DYLD_LIBRARY_PATH problem I have also found the following discussion: https://urldefense.proofpoint.com/v2/url?u=https-3A__forums.macrumors.com_threads_is-2Dit-2Dok-2Dto-2Duse-2Ddyld-5Flibrary-5Fpath-2Don-2Dmac-2Dos-2Dx-2Dand-2Dwhat-25C2-2592s-2Dthe-2Ddynamic-2Dlibrary-2Dsearch.956258_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=yhLXARIG_RS1LNegc7tbjO1bayLOp7zy5-rzbtjCHIk= There, one answer mentioned: 'Also, rpath is a good idea. Also
Re: [Bioc-devel] Object not found in vignette
Also recently you bumped the version from 1.1.* to 1.2.* then went back to 1.1.* again. As a result the version that is available via biocLite() is 1.2.2, as reflected on the package landing page: https://bioconductor.org/packages/3.5/bioc/html/anamiR.html Any change you do to your package now won't propagate unless you bump the version to > 1.2.2. H. On 04/20/2017 02:52 PM, 王棣台 wrote: it should be in my package since anamiR version 1.1.8 That is weird. Ti-Tai 從: Hervé Pagès [hpa...@fredhutch.org] 寄件日期: 2017年4月21日 上午 05:49 至: 王棣台; bioc-devel@r-project.org 主旨: Re: [Bioc-devel] Object not found in vignette On 04/20/2017 02:45 PM, Hervé Pagès wrote: On 04/20/2017 02:36 PM, 王棣台 wrote: That missing object is a list format data generated by myself, so I don't think it would be about Depends, Imports, or Suggests. Except this one, other generated data can be found. And where did you put this data set so that data(table_pre) can find it? I mean the other generated data sets can be found because they are in your package but I don't see the table_pre data set there. Did you forget to commit it? H. H. Ti-Tai 從: Hervé Pagès [hpa...@fredhutch.org] 寄件日期: 2017年4月21日 上午 05:16 至: 王棣台; bioc-devel@r-project.org 主旨: Re: [Bioc-devel] Object not found in vignette Why don't you give us the name of your package so we can look at it? I suspect something is missing in your Depends, Imports, or Suggests field. Works for you because you have the missing package installed on your machine but not on the build machine because the package is missing there. The build system (and your users) doesn't have this package so the vignette fails there. By adding the package to Depends, Imports, or Suggests, you let the build system know that this package needs to be installed before it tries to build the vignette. H. On 04/20/2017 01:51 PM, 王棣台 wrote: Hi all, I kept getting the same Error from BUILD REPORT: Error: processing vignette 'IntroductionToanamiR.Rmd' failed with diagnostics: object 'table_pre' not found However, I did confirm my package with R CMD BUILD and CHECK before committing, and there was no errors and warnings. I really don't know what is the problem. Does anyone have the same error before? Many Thanks, Ti-Tai Wang [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=TK-8woT9u1jslARFhHX9Y_pg-0Cg9S5vwIyvMX86pHU=3gO7lG40pXAtK-3RkKJ-yhJdwqUw-NZwBORf4PaN7xg= -- 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 -- 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 -- 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] Object not found in vignette
On 04/20/2017 02:50 PM, 王棣台 wrote: I put in the anamiR/data/ Just like other data I used in the vignette. As I said, I don't see it there. According to data(package="anamiR"), the data sets available in your package are: Data sets in package ‘anamiR’: egSymb A table with information of gene symbol and gene ID kegg.gs KEGG pathways with gene set information mirna miRNA expression data about breast cancer mrnamRNA expression data about breast cancer pheno.mirna phenotype data of 'mirna' about breast cancer pheno.mrna phenotype data of 'mrna' about breast cancer So again, did you forget to commit it to svn, or did you add it to the wrong place? H. Ti-Tai ____ 從: Hervé Pagès [hpa...@fredhutch.org] 寄件日期: 2017年4月21日 上午 05:45 至: 王棣台; bioc-devel@r-project.org 主旨: Re: [Bioc-devel] Object not found in vignette On 04/20/2017 02:36 PM, 王棣台 wrote: That missing object is a list format data generated by myself, so I don't think it would be about Depends, Imports, or Suggests. Except this one, other generated data can be found. And where did you put this data set so that data(table_pre) can find it? H. Ti-Tai ____ 從: Hervé Pagès [hpa...@fredhutch.org] 寄件日期: 2017年4月21日 上午 05:16 至: 王棣台; bioc-devel@r-project.org 主旨: Re: [Bioc-devel] Object not found in vignette Why don't you give us the name of your package so we can look at it? I suspect something is missing in your Depends, Imports, or Suggests field. Works for you because you have the missing package installed on your machine but not on the build machine because the package is missing there. The build system (and your users) doesn't have this package so the vignette fails there. By adding the package to Depends, Imports, or Suggests, you let the build system know that this package needs to be installed before it tries to build the vignette. H. On 04/20/2017 01:51 PM, 王棣台 wrote: Hi all, I kept getting the same Error from BUILD REPORT: Error: processing vignette 'IntroductionToanamiR.Rmd' failed with diagnostics: object 'table_pre' not found However, I did confirm my package with R CMD BUILD and CHECK before committing, and there was no errors and warnings. I really don't know what is the problem. Does anyone have the same error before? Many Thanks, Ti-Tai Wang [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=TK-8woT9u1jslARFhHX9Y_pg-0Cg9S5vwIyvMX86pHU=3gO7lG40pXAtK-3RkKJ-yhJdwqUw-NZwBORf4PaN7xg= -- 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 -- 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 -- 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] Object not found in vignette
On 04/20/2017 02:45 PM, Hervé Pagès wrote: On 04/20/2017 02:36 PM, 王棣台 wrote: That missing object is a list format data generated by myself, so I don't think it would be about Depends, Imports, or Suggests. Except this one, other generated data can be found. And where did you put this data set so that data(table_pre) can find it? I mean the other generated data sets can be found because they are in your package but I don't see the table_pre data set there. Did you forget to commit it? H. H. Ti-Tai 從: Hervé Pagès [hpa...@fredhutch.org] 寄件日期: 2017年4月21日 上午 05:16 至: 王棣台; bioc-devel@r-project.org 主旨: Re: [Bioc-devel] Object not found in vignette Why don't you give us the name of your package so we can look at it? I suspect something is missing in your Depends, Imports, or Suggests field. Works for you because you have the missing package installed on your machine but not on the build machine because the package is missing there. The build system (and your users) doesn't have this package so the vignette fails there. By adding the package to Depends, Imports, or Suggests, you let the build system know that this package needs to be installed before it tries to build the vignette. H. On 04/20/2017 01:51 PM, 王棣台 wrote: Hi all, I kept getting the same Error from BUILD REPORT: Error: processing vignette 'IntroductionToanamiR.Rmd' failed with diagnostics: object 'table_pre' not found However, I did confirm my package with R CMD BUILD and CHECK before committing, and there was no errors and warnings. I really don't know what is the problem. Does anyone have the same error before? Many Thanks, Ti-Tai Wang [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=TK-8woT9u1jslARFhHX9Y_pg-0Cg9S5vwIyvMX86pHU=3gO7lG40pXAtK-3RkKJ-yhJdwqUw-NZwBORf4PaN7xg= -- 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 -- 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] Object not found in vignette
On 04/20/2017 02:36 PM, 王棣台 wrote: That missing object is a list format data generated by myself, so I don't think it would be about Depends, Imports, or Suggests. Except this one, other generated data can be found. And where did you put this data set so that data(table_pre) can find it? H. Ti-Tai 從: Hervé Pagès [hpa...@fredhutch.org] 寄件日期: 2017年4月21日 上午 05:16 至: 王棣台; bioc-devel@r-project.org 主旨: Re: [Bioc-devel] Object not found in vignette Why don't you give us the name of your package so we can look at it? I suspect something is missing in your Depends, Imports, or Suggests field. Works for you because you have the missing package installed on your machine but not on the build machine because the package is missing there. The build system (and your users) doesn't have this package so the vignette fails there. By adding the package to Depends, Imports, or Suggests, you let the build system know that this package needs to be installed before it tries to build the vignette. H. On 04/20/2017 01:51 PM, 王棣台 wrote: Hi all, I kept getting the same Error from BUILD REPORT: Error: processing vignette 'IntroductionToanamiR.Rmd' failed with diagnostics: object 'table_pre' not found However, I did confirm my package with R CMD BUILD and CHECK before committing, and there was no errors and warnings. I really don't know what is the problem. Does anyone have the same error before? Many Thanks, Ti-Tai Wang [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=TK-8woT9u1jslARFhHX9Y_pg-0Cg9S5vwIyvMX86pHU=3gO7lG40pXAtK-3RkKJ-yhJdwqUw-NZwBORf4PaN7xg= -- 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 -- 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] Object not found in vignette
Why don't you give us the name of your package so we can look at it? I suspect something is missing in your Depends, Imports, or Suggests field. Works for you because you have the missing package installed on your machine but not on the build machine because the package is missing there. The build system (and your users) doesn't have this package so the vignette fails there. By adding the package to Depends, Imports, or Suggests, you let the build system know that this package needs to be installed before it tries to build the vignette. H. On 04/20/2017 01:51 PM, 王棣台 wrote: Hi all, I kept getting the same Error from BUILD REPORT: Error: processing vignette 'IntroductionToanamiR.Rmd' failed with diagnostics: object 'table_pre' not found However, I did confirm my package with R CMD BUILD and CHECK before committing, and there was no errors and warnings. I really don't know what is the problem. Does anyone have the same error before? Many Thanks, Ti-Tai Wang [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=TK-8woT9u1jslARFhHX9Y_pg-0Cg9S5vwIyvMX86pHU=3gO7lG40pXAtK-3RkKJ-yhJdwqUw-NZwBORf4PaN7xg= -- 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] xps build problem on veracruz2
On 04/20/2017 10:59 AM, Hervé Pagès wrote:
Hi Christian,
Disabling 'csrutil disable' might help xps on veracruz2 but that
^^
oops, no double negative intended here. I meant, doing 'csrutil disable'
might help... etc
H.
won't help your end users.
I'm no expert in developing a package on Mac but other people on
this list are. Also R-SIG-Mac might be a good place to seek help
for this.
Cheers,
H.
On 04/20/2017 10:53 AM, cstrato wrote:
Dear Herve,
Thank you for your efforts to try to install xps. I am glad to hear that
you could build ROOT 5 from source.
It's a pity that Apple does no longer allow the use of
DYLD_LIBRARY_PATH. This seems to break the code of a lot of people (when
googling around).
I will try to change the build process and will see if I succeed.
However, at the moment I have a couple of questions:
1, Is there any reason that you do not want to 'csrutil disable'?
2, It is easy to delete the test for DYLD_LIBRARY_PATH in my
'configure.in' file, however, I have also to change the 'Makefile'.
Since you say that the problem can be solved by adding the -rpath flag
when linking, I assume that I have to change the following line in my
'Makefile':
$(LD) -bundle $(LDFLAGS) $^ $(GLIBS) $(MYLIBS) \
$(OutPutOpt) $(subst .$(DllSuf),.so,$@)
Since I am not familiar with -rpath can you give me a hint how to change
it?
3, There is a Wikipedia explanation for '-rpath', see:
https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Rpath=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=ge_d4eBoKDAggNWVQUzMVPAJy250VlZuPTXcPyr20HM=
Interestingly, there is the following line:
'Instead of specifying the -rpath to the linker, the environment
variable LD_RUN_PATH can be set to the same effect.'
Do you think that using LD_RUN_PATH would solve the problem?
If yes, then how?
4, Googling for the DYLD_LIBRARY_PATH problem I have also found the
following discussion:
https://urldefense.proofpoint.com/v2/url?u=https-3A__forums.macrumors.com_threads_is-2Dit-2Dok-2Dto-2Duse-2Ddyld-5Flibrary-5Fpath-2Don-2Dmac-2Dos-2Dx-2Dand-2Dwhat-25C2-2592s-2Dthe-2Ddynamic-2Dlibrary-2Dsearch.956258_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=yhLXARIG_RS1LNegc7tbjO1bayLOp7zy5-rzbtjCHIk=
There, one answer mentioned:
'Also, rpath is a good idea. Also see install_name_tool, which can
change the load paths of libraries.'
Doing a search for 'install_name_tool' I found:
https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_questions_2985315_using-2Dinstall-2Dname-2Dtool-2Dwhats-2Dgoing-2Dwrong=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=r5LiHlxkGAeJAcciwteD2XD6ffNtWLiknvcIj9EJL8E=
There, one answer mentioned (see also $man install_name_tool):
'Having experimented more: install_name_tool -id newname file will do
the trick.'
See also:
https://urldefense.proofpoint.com/v2/url?u=http-3A__qin.laya.com_tech-5Fcoding-5Fhelp_dylib-5Flinking.html=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=FL17xv1uuzR6UF59mgJstMQ-1seE1UeKDQVVXQgXnUo=
Do you think that either using the environment variable LD_RUN_PATH or
using 'install_name_tool' could solve the problem without having to use
'-rpath'?
Thank you in advance.
Best regards,
Christian
On 04/19/17 22:51, Hervé Pagès wrote:
Hi Christian,
So I installed ROOT 5 from source on veracruz2. It's in
/usr/local/root.
However, Apple's SIP (System Integrity Protection, new and
enabled by default on El Capitan) is getting in the way when
trying to install xps. That's because xps configure and build
process relies on DYLD_LIBRARY_PATH. Problem is that this
environment variable (and any other variables that control
dynamic loading) is not inherited by child processes when SIP
is on:
veracruz2:~ biocbuild$ if test "${DYLD_LIBRARY_PATH}"; then echo 'yep!';
else echo 'nope!'; fi
yep!
veracruz2:~ biocbuild$ sh
sh-3.2$ if test "${DYLD_LIBRARY_PATH}"; then echo 'yep!'; else echo
'nope!'; fi
nope!
That breaks xps configure script:
veracruz2:~ biocbuild$ export LD_LIBRARY_PATH=$DYLD_LIBRARY_PATH
veracruz2:~ biocbuild$ echo $LD_LIBRARY_PATH
/usr/local/mysql/lib:/usr/local/root/lib/root:/ImageMagick-7.0.5/lib:/usr/local/ensembl-vep/htslib
veracruz2:~ biocbuild$ R CMD INSTALL xps
* installing to library
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library’
* installing *source* package ‘xps’ ...
checking for gcc... clang
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C comp
Re: [Bioc-devel] xps build problem on veracruz2
Hi Christian,
Disabling 'csrutil disable' might help xps on veracruz2 but that
won't help your end users.
I'm no expert in developing a package on Mac but other people on
this list are. Also R-SIG-Mac might be a good place to seek help
for this.
Cheers,
H.
On 04/20/2017 10:53 AM, cstrato wrote:
Dear Herve,
Thank you for your efforts to try to install xps. I am glad to hear that
you could build ROOT 5 from source.
It's a pity that Apple does no longer allow the use of
DYLD_LIBRARY_PATH. This seems to break the code of a lot of people (when
googling around).
I will try to change the build process and will see if I succeed.
However, at the moment I have a couple of questions:
1, Is there any reason that you do not want to 'csrutil disable'?
2, It is easy to delete the test for DYLD_LIBRARY_PATH in my
'configure.in' file, however, I have also to change the 'Makefile'.
Since you say that the problem can be solved by adding the -rpath flag
when linking, I assume that I have to change the following line in my
'Makefile':
$(LD) -bundle $(LDFLAGS) $^ $(GLIBS) $(MYLIBS) \
$(OutPutOpt) $(subst .$(DllSuf),.so,$@)
Since I am not familiar with -rpath can you give me a hint how to change
it?
3, There is a Wikipedia explanation for '-rpath', see:
https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Rpath=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=ge_d4eBoKDAggNWVQUzMVPAJy250VlZuPTXcPyr20HM=
Interestingly, there is the following line:
'Instead of specifying the -rpath to the linker, the environment
variable LD_RUN_PATH can be set to the same effect.'
Do you think that using LD_RUN_PATH would solve the problem?
If yes, then how?
4, Googling for the DYLD_LIBRARY_PATH problem I have also found the
following discussion:
https://urldefense.proofpoint.com/v2/url?u=https-3A__forums.macrumors.com_threads_is-2Dit-2Dok-2Dto-2Duse-2Ddyld-5Flibrary-5Fpath-2Don-2Dmac-2Dos-2Dx-2Dand-2Dwhat-25C2-2592s-2Dthe-2Ddynamic-2Dlibrary-2Dsearch.956258_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=yhLXARIG_RS1LNegc7tbjO1bayLOp7zy5-rzbtjCHIk=
There, one answer mentioned:
'Also, rpath is a good idea. Also see install_name_tool, which can
change the load paths of libraries.'
Doing a search for 'install_name_tool' I found:
https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_questions_2985315_using-2Dinstall-2Dname-2Dtool-2Dwhats-2Dgoing-2Dwrong=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=r5LiHlxkGAeJAcciwteD2XD6ffNtWLiknvcIj9EJL8E=
There, one answer mentioned (see also $man install_name_tool):
'Having experimented more: install_name_tool -id newname file will do
the trick.'
See also:
https://urldefense.proofpoint.com/v2/url?u=http-3A__qin.laya.com_tech-5Fcoding-5Fhelp_dylib-5Flinking.html=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=kxgD4oa4CZeT4T7uLq2m3iVTvgvFB_RKN1Rf1KcxPk0=FL17xv1uuzR6UF59mgJstMQ-1seE1UeKDQVVXQgXnUo=
Do you think that either using the environment variable LD_RUN_PATH or
using 'install_name_tool' could solve the problem without having to use
'-rpath'?
Thank you in advance.
Best regards,
Christian
On 04/19/17 22:51, Hervé Pagès wrote:
Hi Christian,
So I installed ROOT 5 from source on veracruz2. It's in
/usr/local/root.
However, Apple's SIP (System Integrity Protection, new and
enabled by default on El Capitan) is getting in the way when
trying to install xps. That's because xps configure and build
process relies on DYLD_LIBRARY_PATH. Problem is that this
environment variable (and any other variables that control
dynamic loading) is not inherited by child processes when SIP
is on:
veracruz2:~ biocbuild$ if test "${DYLD_LIBRARY_PATH}"; then echo 'yep!';
else echo 'nope!'; fi
yep!
veracruz2:~ biocbuild$ sh
sh-3.2$ if test "${DYLD_LIBRARY_PATH}"; then echo 'yep!'; else echo
'nope!'; fi
nope!
That breaks xps configure script:
veracruz2:~ biocbuild$ export LD_LIBRARY_PATH=$DYLD_LIBRARY_PATH
veracruz2:~ biocbuild$ echo $LD_LIBRARY_PATH
/usr/local/mysql/lib:/usr/local/root/lib/root:/ImageMagick-7.0.5/lib:/usr/local/ensembl-vep/htslib
veracruz2:~ biocbuild$ R CMD INSTALL xps
* installing to library
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library’
* installing *source* package ‘xps’ ...
checking for gcc... clang
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang accepts -g... yes
checking for clang option to accept ANSI C... none needed
checking how to run the C preprocessor... clang -E
checking for g
Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta
On 04/19/2017 02:45 AM, Michael Stadler wrote:
Dear BioC core,
Thanks for the report, Herve. If I understand correctly, there is
nothing I can do at this point to make QuasR green on windows, correct?
Nothing you can do in QuasR itself. Sorry that I don't have time to do
this but someone would need to take a close look at this problem though.
And report his/her findings to the R folks. We're running short of time!
(will be a bummer to have R 3.4 released with such a nasty bug in it)
Cheers,
H.
I have another question regarding QuasR not building on veracruz2: The
vignette does not build currently, reporting:
Error on veracruz2.bioconductor.org processing sample
/tmp/RtmpJBWrjI/chip_1_1.fq.bz2df0b6901ff33.fastq : 'asBam' internal:
samtools invoked 'abort' ...
Though it seems to build fine on other platforms, and there were no
recent changes to the vignette. What would you or other suggest to do
about that?
Any suggestions are appreciated,
Michael
On 17.04.2017 02:08, Hervé Pagès wrote:
FWIW here are all the packages that are victim of this
installed.packages bug in today's build report:
alpine
fCI
GenomicFeatures
QuasR
We only see this error on tokay2 (Windows).
H.
On 04/11/2017 04:21 PM, Gordon K Smyth wrote:
I restarted my PC this morning and the problem disappeared.
I probably should have tried that last night, but it was late ...
Thanks
Gordon
-Original Message-
From: Martin Morgan [mailto:martin.mor...@roswellpark.org]
Sent: Tuesday, 11 April 2017 7:20 PM
To: Gordon K Smyth <sm...@wehi.edu.au>; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta
On 04/11/2017 05:01 AM, Gordon K Smyth wrote:
The problem appears to be with installed.packages(). If I start a
fresh R
3.4.0beta session, then I can run installed.packages() once with
correct results,
but running it a second time gives the error message:
installed.packages()
Error in if (file.exists(dest) && file.mtime(dest) > file.mtime(lib)
&& :
missing value where TRUE/FALSE needed
The test is in this code chunk, from utils/R/packages.R
for(lib in lib.loc) {
if(noCache) {
ret0 <- .readPkgDesc(lib, fields)
if(length(ret0)) retval <- rbind(retval, ret0)
} else {
## Previously used URLencode for e.g. Windows paths with
drives
## This version works for very long file names.
base <- paste(c(lib, fields), collapse = ",")
## add length and 64-bit CRC in hex (in theory, seems
## it is actually 32-bit on some systems)
enc <- sprintf("%d_%s", nchar(base), .Call(C_crc64, base))
dest <- file.path(tempdir(), paste0("libloc_", enc,
".rds"))
if(file.exists(dest) &&
file.mtime(dest) > file.mtime(lib) &&
(val <- readRDS(dest))$base == base)
## use the cache file
retval <- rbind(retval, val$value)
else {
ret0 <- .readPkgDesc(lib, fields)
if(length(ret0)) {
retval <- rbind(retval, ret0)
## save the cache file
saveRDS(list(base = base, value = ret0), dest)
}
}
}
where 'lib' is one of .libPaths(), 'dest' is one of
dir(tempdir(), pattern="libloc_", full=TRUE)
and 'base' should be a character(1)
I think the code chunk has tried to cache the packages installed in each
directory of .libPaths() (the saveRDS() line), and these are somehow
corrupted on the second time through (I guess evaluating the
readRDS()??).
For instance I have two paths in .libPaths() and after the first
install.packages() I have
> str(readRDS(dir(tempdir(), full=TRUE)[1]))
List of 2
$ base : chr
"/home/mtmorgan/bin/R-3-4-
branch/library,Version,Priority,Depends,Imports,LinkingTo,Suggests,Enhances,Li
cense,Li"|
__truncated__
$ value: chr [1:29, 1:17] "base" "boot" "class" "cluster" ...
> str(readRDS(dir(tempdir(), full=TRUE)[2]))
List of 2
$ base : chr
"/home/mtmorgan/R/x86_64-pc-linux-gnu-library/3.4-Bioc-
3.5,Version,Priority,Depends,Imports,LinkingTo,Suggests,E"|
__truncated__
$ value: chr [1:513, 1:17] "abind" "acepack" "aCGH" "ADaCGH2" ...
I'm guessing that one of these files is corrupted somehow, but it's not
obvious how. Can you use options(error=recover) and find the values that
cause the conditional to fail?
Martin
-Original Message-
From: Gordon K Smyth
Sent: Tuesday, 11 April 2017 6:26 PM
To: bioc-devel@r-project.org
Subject: Using BiocInstaller with R 3.4.0 beta
I thought I would test out R 3.4.0 beta (for Windows) but now I
can't use the
BiocInstaller package. Attempts to use biocLite()
Re: [Bioc-devel] Using BiocInstaller with R 3.4.0 beta
Hi Michael, On 04/17/2017 12:31 PM, Michael Love wrote: alpine, which had this error as of Sunday, is now cleared (I didn't make any changes to the code) https://urldefense.proofpoint.com/v2/url?u=http-3A__master.bioconductor.org_checkResults_devel_bioc-2DLATEST_alpine_=DwIBaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FslFDEAm_2UTMu0mMv7oNRUhFjxa9R6r2QKfY7_-ZZ8=NeikP8-8_2PSFQMJ7jiSmXUW4SWzjK-XZXnXqRAf3_U= The problem seems intermittent. All the packages that make direct or indirect calls to installed.packages() are not necessarily affected every day. Today the victims are: cobindR debrowser fCI GenomicFeatures GGBase QuasR So more victims than 3 days ago. Tomorrow we might see something different. H. ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] xps build problem on veracruz2
revisit xps configure and build process? Make sure you test it on a machine where SIP is enabled. Thanks, H. On 03/24/2017 12:14 PM, cstrato wrote: On 03/24/17 19:55, Hervé Pagès wrote: On 03/24/2017 11:37 AM, cstrato wrote: On 03/24/17 19:23, Hervé Pagès wrote: On 03/24/2017 11:10 AM, cstrato wrote: On 03/24/17 18:02, Hervé Pagès wrote: On 03/24/2017 06:52 AM, cstrato wrote: R/Bioc is still building on Mavericks, Not for R devel (3.4). The R folks have switched to El Capitan a few days ago: You are right, I did not check R devel. https://urldefense.proofpoint.com/v2/url?u=https-3A__r.research.att.com_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=aV7U6Qu8HkkL9dhD7thXz2c2geZd1KmfWnoZkiyu6hs=EDYb8eN2bAg_TtTfDURARDLiz4AoKggk2QLfABIdxTA= and before was built on Snow Leopard (which many people are sill using). Personally I think that it does not make much difference whether Mavericks or El Capitan (or Yosemite) is used to build R/Bioc. How much experience you have with setting a Mavericks or El Capitan build machine to build and distribute thousands of package binaries for hundreds ot thousands of users? You probably misunderstood what I wanted to say. It is clear to me that you are doing a great job distributing thousands of package binaries. No one does know it better than me with the special problems you have to build binaries for xps. I really appreciate that during all these years you and Dan (and others) managed to support xps like all other BioC packages. I meant that from the user standpoint it probably does not matter much which of these three systems are used to build BioC, in contrast to Sierra. Of course it matters. If you use an older OS than the one we use to produce the binaries then some binaries won't work for you. You keep missing the whole point. H. Sorry, but I do understand this point. Users who are still using e.g. Snow Leopard (because they think this was the best system) will have problems. For that reason I thought that maybe it is best to use the system which is currently used by most users. That would be the thing to do if we didn't have neither forward- nor backward- compatibility. But we *do* have forward-compatibility. So there is no reason to use the system which is currently used by most users. It's enough to make sure that we use a system that is *compatible* with what most users have. And also not too old because it's hard to find powerful hardware that runs old OS X versions and because many software components needed for the builds are not available or not maintained anymore for old OS X versions. Like Dan said, it's a tradeoff. H. You are right, using a system which is compatible with what most users have, is the best choice. Christian Christian But as you said below backward-compatibility is always lost, so the question which system to use to build R/BioC is always tricky. Maybe, the best (?) decision would be to use the system which most Mac users are currently using, but I don't know. Best regards, Christian However, Sierra is different, and when the CRAN people are experimenting with clang 4.0.0 for producing the Mac binaries, as Herve has mentioned, then backwards-compatibility would probably be lost anyhow. I think you misunderstood what Dan said. Backward-compatibility is always lost i.e. binaries built on a given OS X versions are not guaranteed to be backward compatible with older OS X versions. That's why building them on the latest OS X version is a bad idea. But I understand that this is a decision the CRAN people have to make. You're welcome to discuss this choice on the R-SIG-Mac mailing list. Cheers, H. Best regards, Christian On 03/24/17 01:10, Dan Tenenbaum wrote: - Original Message - From: "Hervé Pagès" <hpa...@fredhutch.org> To: "cstrato" <cstr...@aon.at>, "bioc-devel" <bioc-devel@r-project.org> Sent: Thursday, March 23, 2017 12:14:38 PM Subject: Re: [Bioc-devel] xps build problem on veracruz2 On 03/23/2017 11:09 AM, cstrato wrote: Dear Herve, Thank you for your explanation. The reason that xps does not work with ROOT 6 is that I have tried it but there seem to be so many changes, that I did not succeed. Since for xps there is no advantage using ROOT 6 vs ROOT 5, and ROOT 5 was still supported, I have decided to stay with ROOT 5. OK BTW, I have also one question: Why did you decide to set up a new Mac with El Capitan instead of using the newest OS Sierra? (I have the impression that most Mac users are either happy to stay with their old OS or they upgrade to the newest one.) Same reason as for the choice of compilers: that's what the R folks decided to use for producing the Mac binaries of R and CRAN packages. We're just following their lead on that. Also, it's always good not to require users to upgrade if they don't have to. Building on El Capitan means users will not have to u
Re: [Bioc-devel] R CMD check without WARNING: g++ and STL issue for xcms and mzR
dGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=kUGjYuMkhD3e-WsuG6IAuE_MTjPtNkrZw9B4I-9xpwM= LATEST/malbec2-NodeInfo.html is using "CFLAGS=-g -O2 -Wall" but only "CXXFLAGS=-Wall" while e.g. tokay2 uses "CXXFLAGS=-O2 -Wall -mtune=core2" The -O2 optimisation is getting rid of the abort() symbol, as shown in https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sneumann_xcms_issues_150-23=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=Bzp4j1sYGGHCblnhv2xferniQzw1BPE-wmoHi0zWSLM= issuecomment-293545521 => Is there a way to get -O2 back on the BioC build machines ? This should fix our WARNING. Bonus: will fix the same issue in mzR :-) Yours, Steffen On So, 2017-04-02 at 10:01 -0400, Martin Morgan wrote: On 04/02/2017 06:52 AM, Neumann, Steffen wrote: [...] in preparation for the release, we are hunting down WARNINGS "Found ‘abort’, possibly from ‘abort’ (C)" in xcms/mzR. The abort() call is not coming from XCMS, but rather from the C++ code in the STL, and we have no idea [...] We are tracking this in: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sneumann_xcms_issues_150=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=RJrwRqEKnRJOw5M0FS7za46JPhrG2vKflu80XCWzxVI= [...] I don't think Bioconductor can help with this; maybe the Rcpp or R- devel mailing lists? -- 3rd Leibniz Plant Biochemistry Symposium, 22.-23. of June 2017 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ipb-2Dhalle.de_en_public-2Drelations_3rd-2Dleibniz-2Dplant=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=JV-QoY63QkPHNGmis61NuX2JS_4rxBN6c7oFCQFGvm8= -bio chemis try-symposium/ -- IPB HalleAG Massenspektrometrie & Bioinformatik Dr. Steffen Neumann https://urldefense.proofpoint.com/v2/url?u=http-3A__www.IPB-2DHalle.DE=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=tW4jM8Um0HwJ4_bkERUrB4C0DfUfjiz0ikU8_6I5Dho= Weinberg 3 Tel. +49 (0) 345 5582 - 1470 06120 Halle +49 (0) 345 5582 - 0 sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 -- 3rd Leibniz Plant Biochemistry Symposium, 22.-23. of June 2017 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ipb-2Dhalle.de_en_public-2Drelations_3rd-2Dleibniz-2Dplant=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=JV-QoY63QkPHNGmis61NuX2JS_4rxBN6c7oFCQFGvm8= -bio chemis try-symposium/ -- IPB HalleAG Massenspektrometrie & Bioinformatik Dr. Steffen Neumann https://urldefense.proofpoint.com/v2/url?u=http-3A__www.IPB-2DHalle.DE=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=tW4jM8Um0HwJ4_bkERUrB4C0DfUfjiz0ikU8_6I5Dho= Weinberg 3 Tel. +49 (0) 345 5582 - 1470 06120 Halle +49 (0) 345 5582 - 0 sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=CNs9kBVIrKVKelvygElbAF3zSbSxXKqGJCyporqYmF8= [[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=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YE8GxLGaWhq-2Zt3n3yIFSqX3K1hSlEQgyUpXjLaYPg=CNs9kBVIrKVKelvygElbAF3zSbSxXKqGJCyporqYmF8= 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. -- 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] Using BiocInstaller with R 3.4.0 beta
1ZQMStpDs5hOqJaHLGXLTycSugE=6ODigHgwIN79ejt5MJf2kpj1UREzVRkiKBpOWsY_J-I= ") trying URL 'https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_3.5_bioc_bin_windows_contrib_3.4_BiocInst=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=qQj20RkrlTIRAItC1ZQMStpDs5hOqJaHLGXLTycSugE=n0cklbnoQ9a2xy8zQvs0mMdS3tP5gk2NbVWsALYoXOk= aller_1.25.3.zip' Content type 'application/zip' length 127489 bytes (124 KB) downloaded 124 KB package 'BiocInstaller' successfully unpacked and MD5 sums checked The downloaded binary packages are in C:\Users\smyth\AppData\Local\Temp\RtmpOUhCbB\downloaded_packages Bioconductor version 3.5 (BiocInstaller 1.25.3), ?biocLite for help BiocInstaller::biocValid() Error in if (file.exists(dest) && file.mtime(dest) > file.mtime(lib) && : missing value where TRUE/FALSE needed - Professor Gordon K Smyth, Head, Bioinformatics Division, Walter and Eliza Hall Institute of Medical Research, https://urldefense.proofpoint.com/v2/url?u=http-3A__www.statsci.org_smyth=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=qQj20RkrlTIRAItC1ZQMStpDs5hOqJaHLGXLTycSugE=N8BZ6_dazp5kboftdMZCE4ip8G9ORI9zTd8TVRI4eB0= ___ 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=qQj20RkrlTIRAItC1ZQMStpDs5hOqJaHLGXLTycSugE=f74EDfuo7C_LCPCfcGAREY8dqBJwwjc5DqM7YF7Tvg4= 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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=qQj20RkrlTIRAItC1ZQMStpDs5hOqJaHLGXLTycSugE=f74EDfuo7C_LCPCfcGAREY8dqBJwwjc5DqM7YF7Tvg4= -- 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] Error in tokay2
but not GenomicFeatures, which is another victim of this install.packages bug: https://bioconductor.org/checkResults/3.5/bioc-LATEST/GenomicFeatures/tokay2-checksrc.html AFAICS we've been seeing this problem on tokay2 (Windows) almost every day for the last few weeks. I guess it started after we updated R to a more recent R 3.4 on this machine. So I suspect a change in R somehow triggered this. H. On 04/15/2017 08:02 PM, Obenchain, Valerie wrote: EventPointer 0.99.36 built clean today: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bioconductor.org_checkResults_devel_bioc-2DLATEST_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=auvr-W1IWGGZ6bEm2_E4MMb1dYZxyOJiJEHxw8ffrPk=ZxAUJxS48UK2FAs1mcQeAC2XXy0-eiv9SW4OyyOUZDs= Valerie On 04/14/2017 09:16 AM, Obenchain, Valerie wrote: Hi Juan Pablo, We think this is a problem related to installed.packages(), see discussion here: https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_pipermail_bioc-2Ddevel_2017-2DApril_010819.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=auvr-W1IWGGZ6bEm2_E4MMb1dYZxyOJiJEHxw8ffrPk=bSGL5D0ea0jkhT_HDTBTWVccTXfXi-E7uYm4ZCy4VuY= You can ignore this for now. Thanks for keeping an eye on the build report. Valerie On 04/14/2017 12:41 AM, Romero, Juan Pablo wrote: Hello all, I know that today is the deadline for passing R CMD build and R CMD check without errors and warnings, and my package EventPointer has been working perfectly for the last weeks. Today the build report in tokay2 shows an error in one of the examples: ** running examples for arch 'x64' ... ERROR Make the TxDb object ... Error in if (file.exists(dest) && file.mtime(dest) > file.mtime(lib) && : missing value where TRUE/FALSE needed The error is coming from the function makeTxDbFromGFF and the error does not come from functions from my package. Is anybody having a similar error? I will appreciate any help on this to avoid problems related with adding the package to the new release. Thanks! Best regards, Juan Pablo [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=auvr-W1IWGGZ6bEm2_E4MMb1dYZxyOJiJEHxw8ffrPk=Yt38wCbX1caDF2fSTSl4ZafJNM1hanoCXbVbqkFax5M= 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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=auvr-W1IWGGZ6bEm2_E4MMb1dYZxyOJiJEHxw8ffrPk=Yt38wCbX1caDF2fSTSl4ZafJNM1hanoCXbVbqkFax5M= 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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=auvr-W1IWGGZ6bEm2_E4MMb1dYZxyOJiJEHxw8ffrPk=Yt38wCbX1caDF2fSTSl4ZafJNM1hanoCXbVbqkFax5M= -- 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] package 'msa' not building on veracruz2, but on toluca2 and other Mac OS systems
dlO8wvE3KmoPwjRiq-bV_UKHWdKLLP4=q0lYA_4-5lp09oKeciuTpv2FDm4ZddBJHxUO8yw2Tys=jeKQlveT4DG2tLfM8ykFwfCXpfvgOHoAQDuZ_1hjVVY=
This email message may contain legally privileged and/or...{{dropped:2}}
___
Bioc-devel@r-project.org<mailto: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=HjFin7ZZwuYWdlO8wvE3KmoPwjRiq-bV_UKHWdKLLP4=q0lYA_4-5lp09oKeciuTpv2FDm4ZddBJHxUO8yw2Tys=jeKQlveT4DG2tLfM8ykFwfCXpfvgOHoAQDuZ_1hjVVY=
[[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=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=jnChabNsv9hAlCjUWK2OZaz9ASgV9yIlOrr4v73R5_Y=oDD2_encverkZOMDMsj6H8TdvzaHmyOMuqf638eCsxE=
--
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] segfault when building in veracruz2 for BioC 3.5
Q=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=67SOhhQ_xN5IxOZP7n-Vuvtn1Da8u3G6YqpEVI4fTsw=dKDLFLGuh3UsqQmwuRnxOE58wNasCBVVtNJ4cGPPxk4= 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. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es https://urldefense.proofpoint.com/v2/url?u=http-3A__ligarto.org_rdiaz=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=67SOhhQ_xN5IxOZP7n-Vuvtn1Da8u3G6YqpEVI4fTsw=dKDLFLGuh3UsqQmwuRnxOE58wNasCBVVtNJ4cGPPxk4= ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=67SOhhQ_xN5IxOZP7n-Vuvtn1Da8u3G6YqpEVI4fTsw=xYLVWcIVzsv6htRUVAnOuzcx1AWoyBEih7NAQKyljmg= -- 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] R CMD check without WARNING: g++ and STL issue for xcms and mzR
Hi Steffen, On 04/12/2017 04:22 AM, Neumann, Steffen wrote: Hi Martin and malbec2 admin(s): Some more digging revealed that malbec2 https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_malbec2-2DNodeInfo.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=V9yGIrMq8w3mmdQPS2JnioJSKNG6iGCu1hurilsGY0I=l35mMJgBfX96wHZ0WjtJoTIFGDvA-IOLXMDy9TVtz6U= is using "CFLAGS=-g -O2 -Wall" but only "CXXFLAGS=-Wall" while e.g. tokay2 uses "CXXFLAGS=-O2 -Wall -mtune=core2" The -O2 optimisation is getting rid of the abort() symbol, as shown in https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sneumann_xcms_issues_150-23issuecomment-2D293545521=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=V9yGIrMq8w3mmdQPS2JnioJSKNG6iGCu1hurilsGY0I=zvwRbtsHJd07tnGbqG5Cnj6SPzEQcadvufl5s_ir9sM= => Is there a way to get -O2 back on the BioC build machines ? This should fix our WARNING. Bonus: will fix the same issue in mzR :-) This is apparently the new default for R 3.4 beta. Don't know if that was an intended change (someone might want to bring this up on R-devel), but, if it was, then let's assume they had a good reason for it. So I'm not too keen on touching this on the build machines. Might get rid of the mzR and xcms warnings, but might also introduce other problems. Why not control the compilation flags at the package level? Thanks, H. Yours, Steffen On So, 2017-04-02 at 10:01 -0400, Martin Morgan wrote: On 04/02/2017 06:52 AM, Neumann, Steffen wrote: [...] in preparation for the release, we are hunting down WARNINGS "Found ‘abort’, possibly from ‘abort’ (C)" in xcms/mzR. The abort() call is not coming from XCMS, but rather from the C++ code in the STL, and we have no idea [...] We are tracking this in: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sneumann_xcms_issues_150=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=V9yGIrMq8w3mmdQPS2JnioJSKNG6iGCu1hurilsGY0I=PgXl6YzkPCHh3_1B8D2N15A6-Aftsbr8Wx3bcMTwIQk= [...] I don't think Bioconductor can help with this; maybe the Rcpp or R- devel mailing lists? -- 3rd Leibniz Plant Biochemistry Symposium, 22.-23. of June 2017 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ipb-2Dhalle.de_en_public-2Drelations_3rd-2Dleibniz-2Dplant-2Dbiochemis=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=V9yGIrMq8w3mmdQPS2JnioJSKNG6iGCu1hurilsGY0I=Za8ehpMewAbtvAcr0J0bV8O2S-SsaOwFzIQBfOF80n4= try-symposium/ -- IPB HalleAG Massenspektrometrie & Bioinformatik Dr. Steffen Neumann https://urldefense.proofpoint.com/v2/url?u=http-3A__www.IPB-2DHalle.DE=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=V9yGIrMq8w3mmdQPS2JnioJSKNG6iGCu1hurilsGY0I=NiMolENKs_yTD3KviDw4AQR5KE4-Zo0wVy34JEO5r7k= Weinberg 3 Tel. +49 (0) 345 5582 - 1470 06120 Halle +49 (0) 345 5582 - 0 sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409 -- 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] disable windows build for EiR development
Hi Kevin, Just did that. For the record, it's easy to do this yourself: simply add a .BBSoptions file in the top-level folder of the package with the following line in it: UnsupportedPlatforms: win If you change your mind, just remove that file. Cheers, H. On 04/12/2017 01:30 PM, Kevin Horan wrote: Can you please disable the windows build for eiR in the development branch? Thanks. Kevin Horan ___ 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=S7c-bRLdmKQv4KaedK4ncZ8qnH00h8_MS5rZ3MRrU9U=YYhm5fLgkjYQIl4q-Sa0o2WcfZXi0WYwvkX8O88b-NY= -- 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] PROTECT errors in Bioconductor packages
On 04/08/2017 06:50 AM, Martin Morgan wrote:
On 04/08/2017 08:16 AM, Aaron Lun wrote:
On 07/04/17 20:46, luke-tier...@uiowa.edu wrote:
On Fri, 7 Apr 2017, Hervé Pagès wrote:
On 04/07/2017 05:37 AM, luke-tier...@uiowa.edu wrote:
On Fri, 7 Apr 2017, Hervé Pagès wrote:
On 04/06/2017 03:29 AM, Michael Lawrence wrote:
On Thu, Apr 6, 2017 at 2:59 AM, Martin Morgan
<martin.mor...@roswellpark.org> wrote:
On 04/06/2017 05:33 AM, Aaron Lun wrote:
The tool is not perfect, so assess each report
carefully.
I get a lot of warnings because the tool seems to consider that
extracting an attribute (with getAttrib(x, ...)) or extracting the
slot of an S4 object (with GET_SLOT(x, ...) or R_do_slot(x, ...))
returns an SEXP that needs protection. I always assumed that it
didn't because my understanding is that the returned SEXP is
pointing
to a part of a pre-existing object ('x') and not to a newly created
one. So I decided I could treat it like the SEXP returned by
VECTOR_ELT(), which, AFAIK, doesn't need protection.
So I suspect these warnings are false positives but I'm not 100%
sure.
If you are not 100% sure then you should protect :-)
There are some cases, in particular related to compact row names on
data frames, where getAttrib will allocate.
Seriously? So setAttrib(x, ..., getAttrib) is not going to be a no-op
anymore? Should I worry that VECTOR_ELT() will also expand some sort
of compact list element? Why not keep these things low-level
getters/setters that return whatever the real thing is and use
higher-level accessors for returning the expanded version of the thing?
Seriously: it'sbeen that way since r37807 in 2006.
If you want to read about some related future directions you can look at
https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.r-2Dproject.org_R_branches_ALTREP_ALTREP.html=DwIF-g=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ECmvCrpSP99jd6o3J4LkX4nL1PKJiNM1Ky6_-c7ob5k=S-eq87dmcXe7_GR61c5ZPGzqT9V2booIH5P7G_Jch18=
.
luke
I was curious about this so I checked out what R-exts had to say
involving set/getAttrib. Funnily enough, the example it gives in Section
5.9.4 seems to be incorrect in its UNPROTECTing.
#include
#include
SEXP out(SEXP x, SEXP y)
{
int nx = length(x), ny = length(y);
SEXP ans = PROTECT(allocMatrix(REALSXP, nx, ny));
double *rx = REAL(x), *ry = REAL(y), *rans = REAL(ans);
for(int i = 0; i < nx; i++) {
double tmp = rx[i];
for(int j = 0; j < ny; j++)
rans[i + nx*j] = tmp * ry[j];
}
SEXP dimnames = PROTECT(allocVector(VECSXP, 2));
SET_VECTOR_ELT(dimnames, 0, getAttrib(x, R_NamesSymbol));
SET_VECTOR_ELT(dimnames, 1, getAttrib(y, R_NamesSymbol));
setAttrib(ans, R_DimNamesSymbol, dimnames);
UNPROTECT(3);
return ans;
}
There are two PROTECT calls but an UNPROTECT(3), which triggers a stack
imbalance warning upon trying to run .Call("out", ...) in R.
Yes, that should be UNPROTECT(2). svn blame says the error was
introduced when allocMatrix() was introduced; prior to that the code had
allocVector(), then set dim and dimnames.
As for whether to PROTECT or not, my analysis would be...
SET_VECTOR_ELT does not (currently) allocate (except on error) so there
is no opportunity for the garbage collector to run, hence no need to
PROTECT.
Further, getAttrib() (currently) allocates only if (1) the attribute is
R_RowNamesSymbol and the row names are stored in compact format
c(NA_integer_, nrow); or (2) the first argument is a classic pairlist or
language SEXP. None of these conditions apply, so the return value of
getAttrib() is PROTECTed anyway.
Luke's analysis would be more straight-forward: if in doubt, PROTECT.
I think Herve, Gabe, and perhaps Michael would take Luke's advice, and
maybe also note that my advice, in addition to being an analysis of some
surprisingly complicated code by a practitioner of dubious credibility,
involves the current state of affairs, and you never know (and
apparently ALTREP makes it less certain) what the future will hold. So
they'd probably say PROTECT.
One might be tempted to write
SET_VECTOR_ELT(dimnames, 0, PROTECT(getAttrib(x, R_NamesSymbol)));
but I'm not sure whether C guarantees that function arguments are fully
evaluated, maybe it's legal for a compiler to evaluate getAttrib(), then
do some more work with other arguments, then evaluate PROTECT(), so long
as the overall logic is not disrupted. So the 'if in doubt' argument
would make me write
SEXP nms = PROTECT(getAttrib(x, R_NamesSymbol));
SET_VECTOR_ELT(dimnames, 0, nms);
I think , in C is called a 'sequence point'. Google takes me to
https://urldefense.proofpoint.com/v2/url?u=https-3A__msdn.microsoft.com_en-2Dus_library_azk8zbxd.aspx=DwIF-g=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ECmvCrpSP99jd6o3J4LkX4nL1PKJiNM1Ky6_-c7ob5k=ekY5D7Za0NSpYmZxnR3ONu7u8f_qyDme47VeHsBWp6w
Re: [Bioc-devel] PROTECT errors in Bioconductor packages
On 04/07/2017 05:37 AM, luke-tier...@uiowa.edu wrote:
On Fri, 7 Apr 2017, Hervé Pagès wrote:
On 04/06/2017 03:29 AM, Michael Lawrence wrote:
On Thu, Apr 6, 2017 at 2:59 AM, Martin Morgan
<martin.mor...@roswellpark.org> wrote:
On 04/06/2017 05:33 AM, Aaron Lun wrote:
The tool is not perfect, so assess each report carefully.
I get a lot of warnings because the tool seems to consider that
extracting an attribute (with getAttrib(x, ...)) or extracting the
slot of an S4 object (with GET_SLOT(x, ...) or R_do_slot(x, ...))
returns an SEXP that needs protection. I always assumed that it
didn't because my understanding is that the returned SEXP is pointing
to a part of a pre-existing object ('x') and not to a newly created
one. So I decided I could treat it like the SEXP returned by
VECTOR_ELT(), which, AFAIK, doesn't need protection.
So I suspect these warnings are false positives but I'm not 100% sure.
If you are not 100% sure then you should protect :-)
There are some cases, in particular related to compact row names on
data frames, where getAttrib will allocate.
Seriously? So setAttrib(x, ..., getAttrib) is not going to be a no-op
anymore? Should I worry that VECTOR_ELT() will also expand some sort
of compact list element? Why not keep these things low-level
getters/setters that return whatever the real thing is and use
higher-level accessors for returning the expanded version of the thing?
Thanks,
H.
Best,
luke
I also get a warning on almost every C++ function I've written,
because
I use the following code to handle exceptions:
SEXP output=PROTECT(allocVector(...));
try {
// do something that might raise an exception
} catch (std::exception& e) {
UNPROTECT(1);
throw; // break out of this part of the function
}
UNPROTECT(1);
return output;
Presumably the check doesn't account for transfer of control to the
catch block. I find that R itself is pretty good at complaining about
stack imbalances during execution of tests, examples, etc.
'My' packages
(Rsamtools, DirichletMultinomial) had several false positives (all
associated with use of an attribute of a protected SEXP), one subtle
problem (a symbol from a PROTECT'ed package name space; the symbol
could
in theory be an active binding and the value obtained not
PROTECTed by
the name space), and a genuine bug
tag = NEW_CHARACTER(n);
for (int j = 0; j < n; ++j)
SET_STRING_ELT(tag, j, NA_STRING);
if ('A' == aux[0]) {
buf_A = R_alloc(2, sizeof(char)); # <<- bug
buf_A[1] = '\0';
}
...
SET_VECTOR_ELT(tags, i, tag); # PROTECT tag, too
late!
I assume the bug refers to the un-PROTECT'd NEW_CHARACTER here - the
R_alloc call looks okay to me...
yes, tag needs protection.
I attributed the bug to R_alloc because I failed to reason that R_alloc
(obviously) allocates and hence can trigger a garbage collection.
Somehow it reflects my approach to PROTECTion, probably not shared by
everyone. I like to PROTECT only when necessary, rather than
indiscriminately. Probably this has no practical consequence in
terms of
performance, making the code a little easier to read at the expense of
exposing me to bugs like this.
I guess it's a tradeoff between syntactic complexity and logical
complexity. You have to think pretty hard to minimize use of the
protect stack.
I prefer to call it logical obscurity ;-)
The hard thinking consists in assessing whether or not the code between
the line where a new SEXP is allocated (line X) and the line where
it's put in a safe place (line Y) can trigger garbage collection.
Hard to figure out in general indeed, but not impossible! Problem
is that the result of this assessment is valid at a certain point
in time but might change in the future, even if your code has not
changed.
So a dangerous game for virtually zero benefits.
One recommendation might be to UNPROTECT() as soon as the pointer on
the top is unneeded, rather than trying to figure out the number to
pop just before returning to R.
If you PROTECT() in a loop, you definitely want to do that. Otherwise,
does it make a big difference?
One thing that got me is that the order in which C evaluates function
call arguments is undefined. I did a lot of R_setAttrib(x,
install("foo"), allocBar()), thinking that the symbol would be
automatically protected, and allocBar() would not need protection,
since it happened last. Unfortunately, it might be evaluated first.
I got hit by this too long time ago but with defineVar() instead of
R_setAttrib():
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_pipermail_r-2Ddevel_2008-2DJanuary_048040.html=DwID-g=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FscW1HcPCwUqtMwKVFDfd1NyW0oHh0tJOPdFb3C1IWk=O3CcB-Z_OkVKaC1aV0aIc5SCDNqGQrkvGSmPf0
Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5
quot;, "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1, axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
4: do.call(funname, c(list(mf[[i]], y, ylab = yl, xlab = xl), dots))
It seems that what triggers the problem is an innocuous plot.default
followed by dev.hold? (none of which I call explicitly in my code)
I was able to reproduce this with
$ cat segfault-test.R
xx <- parallel::mclapply(1:2, function(i) {
Cairo::CairoPNG(filename = paste("plt", i, ".png", sep=''))
dev.hold()
})
$ R -f segfault-test.R
The El-Capitain builds are still in a great deal of flux, and in
particular the Cairo package requires a binary installation that is not
yet available (the Cairo package is used is actually from Mavericks).
The best strategy is probably to wait until binaries become available.
Martin
At least another package, arrayQualityMetrics seems to experience a
somewhat similar problem:
https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_arrayQualityMetrics_veracruz2-2Dbuildsrc.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LUd6DHmjoVArzVDFUEtSRfMSN_AiOXqmmqFV_4As46k=s7ZpqOndpOhYWVbIGj-Ih8XraT1i9EyvtPExPWojz6M=
where, again, an apparently innocuous plot.default followed by dev.hold
triggers a segfault (and there is no mclapply here)
Traceback:
1: dev.hold()
2: plot.default(-2, -1, pch = "", xlim = range(-1, (dim(mns)[2])), ylim = range(min(as.vector(mns))
- 1, max(as.vector(mns)) + 1), xlab = "5' <-> 3'\n Probe Number ", ylab = ylab,
axes = FALSE, main = "RNA degradation plot", ...)
3: plot(-2, -1, pch = "", xlim = range(-1, (dim(mns)[2])), ylim = range(min(as.vector(mns)) - 1,
max(as.vector(mns)) + 1), xlab = "5' <-> 3'\n Probe Number ", ylab = ylab, axes = FALSE,
main = "RNA degradation plot", ...)
4: plotAffyRNAdeg(AffyRNAdeg(expressionset, log.it = TRUE), lwd = 1, cols
= x$arrayColors)
I am not sure how to proceed here. Any suggestions?
Thanks,
R.
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
https://urldefense.proofpoint.com/v2/url?u=http-3A__ligarto.org_rdiaz=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LUd6DHmjoVArzVDFUEtSRfMSN_AiOXqmmqFV_4As46k=2xbtlQH33eoT53i8vluEoB_10V59Wi3_ePQC0uzrQ_Q=
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LUd6DHmjoVArzVDFUEtSRfMSN_AiOXqmmqFV_4As46k=hNVkbl1RyrBo2RW_tbZQNZbyiwDK_Xf3J1gGnmS8AQU=
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.
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
https://urldefense.proofpoint.com/v2/url?u=http-3A__ligarto.org_rdiaz=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LUd6DHmjoVArzVDFUEtSRfMSN_AiOXqmmqFV_4As46k=2xbtlQH33eoT53i8vluEoB_10V59Wi3_ePQC0uzrQ_Q=
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LUd6DHmjoVArzVDFUEtSRfMSN_AiOXqmmqFV_4As46k=hNVkbl1RyrBo2RW_tbZQNZbyiwDK_Xf3J1gGnmS8AQU=
--
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] PROTECT errors in Bioconductor packages
GbWY_wJYbW0WYiZvSXAJJKaaPhzWA=su20YzStywMa_pdWblzF0RnK8ATRw-t61lOIOsi0xTU=JhBOw1ac5wXfV1BSjFuidxFiBTx43J7iEvZG4G0_0uU= ___ 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=su20YzStywMa_pdWblzF0RnK8ATRw-t61lOIOsi0xTU=JhBOw1ac5wXfV1BSjFuidxFiBTx43J7iEvZG4G0_0uU= -- 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] Filter classes moved from ensembldb to AnnotationFilter
Hi Johannes, Thanks for contacting the developers of the packages affected by this change. FWIW Pbase is also affected (didn't see it in your list): https://bioconductor.org/checkResults/3.5/bioc-LATEST/Pbase/malbec2-buildsrc.html H. On 04/06/2017 01:07 PM, Rainer Johannes wrote: @Florian: nothing you have to change. I checked all packages and 70 of them have problems related to the relocation of the filters. For 63 of them everything should be fine once the updated versions of biovizBase and ggbio are built. This fixes also Gviz and most of the packages with them. For the remaining packages I either provided patches, pull requests or am in contact with the developers. I checked these packages and there is not very much more to do than importing filters from AnnotationFilter instead of ensembldb. Fingers crossed - tomorrow everything could be OK again - and sorry again for all the havoc cheers, jo On 6 Apr 2017, at 21:27, Obenchain, Valerie <valerie.obench...@roswellpark.org<mailto:valerie.obench...@roswellpark.org>> wrote: We've updated the release schedule and moved the deadline for errors to next Friday, April 14. Valerie On 04/06/2017 10:29 AM, Stian Lågstad wrote: How does the error deadline tomorrow (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bioconductor.org_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=jLQ9KUUm3u9dA66MERqNGNYccQtXR7ieDcLKZZMrSII=mdDgNHoW4wRbQFZFJ4a7r2gUE_n6XQspfZvlgjQ94c8= developers/release-schedule/) affect packages that are still red because of this change? I don't know what else to do other than to wait for changes in Gviz (which my package is dependent on). Thanks. On Tue, Apr 4, 2017 at 10:05 PM, Michael Lawrence <lawrence.mich...@gene.com<mailto:lawrence.mich...@gene.com> wrote: Sorry I have been traveling. Will get to it soon. On Apr 4, 2017 12:58 PM, "Rainer Johannes" <johannes.rai...@eurac.edu<mailto:johannes.rai...@eurac.edu>> wrote: Hi Herve, sorry for all the reds - actually I provided the patches to biovizBase and ggbio, but it did not work out that smoothly that I hoped. For the other packages that depend on ensembldb there's no problem or only small changes required (did contact the developers). Fingers crossed that Michael can patch biovizBase and ggbio soon. cheers, jo On 4 Apr 2017, at 21:34, Hervé Pagès <hpa...@fredhutch.org<mailto:hpa...@fredhutch.org>> wrote: Hi Johannes, This move is generating a lot of red today on the build report. Hopefully biovizBase and ggbio can be fixed quickly. Note that maybe a smoother path would have been to notify the maintainers of these packages first and wait that they make the required changes (i.e. to import the filters from AnnotationFilter) before modifying ensembldb. Maybe for next time ;-) Cheers, H. On 04/04/2017 04:02 AM, Rainer Johannes wrote: On 4 Apr 2017, at 10:59, Stian Lågstad <stianlags...@gmail.com<mailto:stianlags...@gmail.com>mailto:stianlags...@gmail.com>>> wrote: Hi, Thanks again for notifying me about the changes needed in chimeraviz. Right now I'm having problems installing Gviz - I get these errors: """ No methods found in "GenomicAlignments" for requests: pmapFromTranscripts Error : object 'GRangesFilter' is not exported by 'namespace:ensembldb' ERROR: lazy loading failed for package 'Gviz' """ Are these errors caused by the change in ensembldb? If so: Do you know how I can keep developing without having to wait for Gviz? These come from biovizBase which Gviz imports. I've sent Micheal the fixes for biovizBase and ggbio that should fix this. We need to wait for the changes to be propagated, since also for ensembldb I get today still version 1.99.12 but not the new 1.99.13. On Mon, Apr 3, 2017 at 8:59 AM, Rainer Johannes < johannes.rai...@eurac.edu<mailto:johannes.rai...@eurac.edu><mailto:johannes.rai...@eurac.edu>> wrote: Dear all, I've just committed a change in ensembldb (version 1.99.13) that removes all filter classes from it and imports them from the AnnotationFilter package. This change will break biovizBase and ggbio (and all packages downstream of them, e.g. Gviz). I've already sent Michael Lawrence patches to fix both packages, but there might still be some problems in the upcoming build reports I guess. I've also contacted the developers of the TVTB and chimeraviz packages and made them aware of the change. Could be that there are other packages out there possibly affected by the change. If so, let me know and I'll assist fixing the problems (if needed). cheers, jo ___ Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org><mailto:Bioc-devel@r-project.org> mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat. ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAf qt84VtBcfhQ= BK7q3XeAvimeWdGbWY_wJY
Re: [Bioc-devel] conflict rowRanges SummarizedExperiment/matrixStats
1] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] parallel stats4stats graphics grDevices utils datasets [8] methods base other attached packages: [1] SummarizedExperiment_1.5.7 DelayedArray_0.1.7 [3] matrixStats_0.51.0 Biobase_2.35.1 [5] GenomicRanges_1.27.23 GenomeInfoDb_1.11.10 [7] IRanges_2.9.19 S4Vectors_0.13.15 [9] BiocGenerics_0.21.3 loaded via a namespace (and not attached): [1] lattice_0.20-34 bitops_1.0-6grid_3.4.0 [4] zlibbioc_1.21.0 XVector_0.15.2 Matrix_1.2-8 [7] RCurl_1.95-4.8 GenomeInfoDbData_0.99.0 [[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=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=bBlLwXlJ4Cst2nHAHB8kAuTS_AWz1pR3o1IU1AAx0VA=dRF1ozBM8vw7I37Ki98duGs7d33ewviTTJaXYdkTNYc= [[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=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=bBlLwXlJ4Cst2nHAHB8kAuTS_AWz1pR3o1IU1AAx0VA=dRF1ozBM8vw7I37Ki98duGs7d33ewviTTJaXYdkTNYc= -- 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] Iterating over BSgenomeViews returns DNAString instead of BSgenomeViews
graphics grDevices utils datasets [8] methods base other attached packages: [1] BSgenome.Hsapiens.UCSC.hg19_1.4.0 BSgenome_1.43.7 [3] rtracklayer_1.35.10 Biostrings_2.43.7 [5] XVector_0.15.2GenomicRanges_1.27.23 [7] GenomeInfoDb_1.11.10 IRanges_2.9.19 [9] S4Vectors_0.13.15 BiocGenerics_0.21.3 loaded via a namespace (and not attached): [1] zlibbioc_1.21.0GenomicAlignments_1.11.12 [3] BiocParallel_1.9.5 lattice_0.20-35 [5] tools_3.5.0SummarizedExperiment_1.5.7 [7] grid_3.5.0 Biobase_2.35.1 [9] matrixStats_0.52.1 Matrix_1.2-9 [11] GenomeInfoDbData_0.99.0bitops_1.0-6 [13] RCurl_1.95-4.8 DelayedArray_0.1.7 [15] compiler_3.5.0 Rsamtools_1.27.15 [17] XML_3.98-1.6 BiocInstaller::biocValid() [1] TRUE --- Pariksheet Nanda PhD Candidate in Genetics and Genomics System Administrator, Storrs HPC Cluster University of Connecticut [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=4f5sS-9Z9WKeGLCHw3KM82mea8ioHJa_FrqleAw5Otc=urNRGmIvz9AzopqsBNZqNtWkPlNZnm5w3mZ_QML6aes= -- 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] Filter classes moved from ensembldb to AnnotationFilter
Hi Johannes, This move is generating a lot of red today on the build report. Hopefully biovizBase and ggbio can be fixed quickly. Note that maybe a smoother path would have been to notify the maintainers of these packages first and wait that they make the required changes (i.e. to import the filters from AnnotationFilter) before modifying ensembldb. Maybe for next time ;-) Cheers, H. On 04/04/2017 04:02 AM, Rainer Johannes wrote: On 4 Apr 2017, at 10:59, Stian Lågstad <stianlags...@gmail.com<mailto:stianlags...@gmail.com>> wrote: Hi, Thanks again for notifying me about the changes needed in chimeraviz. Right now I'm having problems installing Gviz - I get these errors: """ No methods found in "GenomicAlignments" for requests: pmapFromTranscripts Error : object 'GRangesFilter' is not exported by 'namespace:ensembldb' ERROR: lazy loading failed for package 'Gviz' """ Are these errors caused by the change in ensembldb? If so: Do you know how I can keep developing without having to wait for Gviz? These come from biovizBase which Gviz imports. I've sent Micheal the fixes for biovizBase and ggbio that should fix this. We need to wait for the changes to be propagated, since also for ensembldb I get today still version 1.99.12 but not the new 1.99.13. On Mon, Apr 3, 2017 at 8:59 AM, Rainer Johannes <johannes.rai...@eurac.edu<mailto:johannes.rai...@eurac.edu>> wrote: Dear all, I've just committed a change in ensembldb (version 1.99.13) that removes all filter classes from it and imports them from the AnnotationFilter package. This change will break biovizBase and ggbio (and all packages downstream of them, e.g. Gviz). I've already sent Michael Lawrence patches to fix both packages, but there might still be some problems in the upcoming build reports I guess. I've also contacted the developers of the TVTB and chimeraviz packages and made them aware of the change. Could be that there are other packages out there possibly affected by the change. If so, let me know and I'll assist fixing the problems (if needed). cheers, jo ___ Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=iJ2N4NzAka_Lu8P0_h6XWIy-PpkQJQ6twQd8-on8IrI=TXnXWMXgtHzzTK32JJ1rJ7ayI3US5B9DHGXheFpNXEY= -- Stian Lågstad +47 41 80 80 25 [[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=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=iJ2N4NzAka_Lu8P0_h6XWIy-PpkQJQ6twQd8-on8IrI=TXnXWMXgtHzzTK32JJ1rJ7ayI3US5B9DHGXheFpNXEY= -- 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] cbind SummarizedExperiments containing a DNAStringSet not working
u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uvrEDLijSOFICTEXtDWEcJQxpbdIH_JLue85P1KkRSk=CiJ40v8p658EEANnkQUiSwzWFnU_9gbt3urmC3CXn5g= -- 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: [Rd] mean(x) != mean(rev(x)) different with x <- c(NA, NaN) for some builds
On 03/31/2017 10:14 PM, Prof Brian Ripley wrote: From ?NA Numerical computations using ‘NA’ will normally result in ‘NA’: a possible exception is where ‘NaN’ is also involved, in which case either might result. and ?NaN Computations involving ‘NaN’ will return ‘NaN’ or perhaps ‘NA’: which of those two is not guaranteed and may depend on the R platform (since compilers may re-order computations). fortunes::fortune(14) applies (yet again). The problem is that TFM often contradicts itself e.g. in ?prod: If ‘na.rm’ is ‘FALSE’ an ‘NA’ value in any of the arguments will cause a value of ‘NA’ to be returned, otherwise ‘NA’ values are ignored. which is clearly not the case (at least for me): > x <- c(NaN, NA) > prod(x) [1] NaN H. On 01/04/2017 04:50, Henrik Bengtsson wrote: In R 3.3.3, I observe the following on Ubuntu 16.04 (when building from source as well as for the sudo apt r-base build): x <- c(NA, NaN) mean(x) [1] NA mean(rev(x)) [1] NaN rowMeans(matrix(x, nrow = 1, ncol = 2)) [1] NA rowMeans(matrix(rev(x), nrow = 1, ncol = 2)) [1] NaN .rowMeans(x, m = 1, n = 2) [1] NA .rowMeans(rev(x), m = 1, n = 2) [1] NaN .rowSums(x, m = 1, n = 2) [1] NA .rowSums(rev(x), m = 1, n = 2) [1] NaN rowSums(matrix(x, nrow = 1, ncol = 2)) [1] NA rowSums(matrix(rev(x), nrow = 1, ncol = 2)) [1] NaN I'd expect NA to trump NaN in all cases (with na.rm = FALSE). sum() does not have this problem and returns NA in both cases (*). For the same R version build from source on RHEL 6.6 system (completely different architecture), I get the expected result (= NA) for all of the above cases, e.g. x <- c(NA, NaN) mean(x) [1] NA mean(rev(x)) [1] NA [...] Before going insane trying to troubleshoot this, I have a vague memory that this, or something related to this, has been discussed previously, but I cannot locate it. Is the above a bug in R, a FAQ, a build error, overzealous compiler optimization, and / or ...? Thanks, Henrik -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-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 '$<-'
On 03/27/2017 09:43 AM, Michael Lawrence wrote:
I committed a fix into R trunk with a regression test.
Thanks Michael. Any chance you can port the fix to the 3.4 branch?
H.
On Mon, Mar 27, 2017 at 8:41 AM, Michael Lawrence <micha...@gene.com> wrote:
My bad guys, I'll fix when I get to work.
On Mon, Mar 27, 2017 at 3:59 AM, Martin Morgan
<martin.mor...@roswellpark.org> wrote:
On 03/22/2017 01:12 PM, Hervé Pagès wrote:
Hi Martin,
On 03/22/2017 03:17 AM, Martin Maechler wrote:
Andrzej Oleś <andrzej.o...@gmail.com>
on Wed, 22 Mar 2017 10:29:57 +0100 writes:
> Just for the record, on R-3.3.2 Herve's code fails with the
following error:
> Error in x[TRUE] <- new("A") :
> incompatible types (from S4 to logical) in subassignment type fix
yes, (of course) and I would be interested in a small
reproducible example which uses _valid_ code.
Looks like before performing the subassignment itself, [<- first tries
to coerce the RHS to the "mode" of the LHS by calling as.vector() on the
former. So if we define an as.vector S3 method for A objects:
setClass("A", representation(stuff="numeric"))
as.vector.A <- function (x, mode="any") x@stuff
a <- new("A", stuff=c(3.5, 0.1))
x <- numeric(10)
x[3:4] <- a
The relevant stack trace is
* frame #0: 0x00010dded77a libR.dylib`R_has_methods(op=)
+ 74 at objects.c:1415
frame #1: 0x00010ddaabf4
libR.dylib`Rf_DispatchOrEval(call=0x7fcea36f68a8, op=0x7fcea201a178,
generic=0x00010df0a185, args=, rho=0x7fcea2053318,
ans=0x7fff51f60c48, dropmissing=, argsevald=1) + 404 at
eval.c:3150
frame #2: 0x00010de4e658 libR.dylib`SubassignTypeFix [inlined]
dispatch_asvector(x=, call=0x7fcea36f68a8,
rho=0x7fcea2053318) + 295 at subassign.c:283
The segfault is at objects.c:1415
offset = PRIMOFFSET(op);
if(offset > curMaxOffset || prim_methods[offset] == NO_METHODS
|| prim_methods[offset] == SUPPRESSED)
where offset is negative and prim_methods[offset] fails.
(lldb) p *op
(SEXPREC) $8 = {
sxpinfo = (type = 0, obj = 0, named = 2, gp = 0, mark = 1, debug = 0,
trace = 0, spare = 0, gcgen = 1, gccls = 0)
attrib = 0x7fcea201a178
gengc_next_node = 0x7fcea21874e8
gengc_prev_node = 0x7fcea2019ff0
u = {
primsxp = (offset = -1576951432)
symsxp = {
'op' is assigned from subassign.c:287, op = R_Primitive("as.vector")
static Rboolean dispatch_asvector(SEXP *x, SEXP call, SEXP rho) {
static SEXP op = NULL;
SEXP args;
Rboolean ans;
if (op == NULL)
op = R_Primitive("as.vector");
PROTECT(args = list2(*x, mkString("any")));
ans = DispatchOrEval(call, op, "as.vector", args, rho, x, 0, 1);
UNPROTECT(1);
return ans;
}
But as.vector is not a primitive, so gets R_NilValue. This is passed to
DispatchOrEval, and then to R_has_methods.
It seems like dispatch_asvector() was introduced by
$ svn log -c69747
r69747 | lawrence | 2015-12-09 09:04:56 -0500 (Wed, 09 Dec 2015) | 3 lines
subassignment of an S4 value into an atomic vector coerces the value
with as.vector
So maybe Michael can tell us about his thinking here.
Also, should R_has_methods be robust to R_NilValue? And R_NilValue
explicitly zero it's data?
Martin
then the code is now valid and we still get the segfault on Mac.
I didn't define as.vector.A in my original minimalist reproducible
code in order to keep it as simple as possible.
H.
We have seen such examples with something (more complicated
than, but basically like)
df <- data.frame(x=1:5, y=5:1, m=matrix(-pi*1:30, 5,6))
M <- Matrix::Matrix(exp(0:3),2)
df[1:2,1:2] <- M
which actually calls `[<-`, and then `[<-.data.frame` and
always works for me but does seg.fault (in the CRAN checks of
package FastImputation (on 3 of the dozen platforms,
https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_web_checks_check-5Fresults-5FFastImputation.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ILfV0tHrE_BxAkWYlvUUwWcBdBdtVD7BlEljGiO3WbY=zUahQYlBHRwNf6lPnSA1515Rm-iL5ffQI7hUcDW-JkE=
one of them is
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.r-2Dproject.org_nosvn_R.check_r-2Ddevel-2Dmacos-2Dx86-5F64-2Dclang_FastImputation-2D00check.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ILfV0tHrE_BxAkWYlvUUwWcBdBdtVD7BlEljGiO3WbY=Z7LkVlUzmdmhqxGNFl4LuMVxYwQQGHSV7KdpKCJu12k=
I strongly suspect this is the same bug as yours, but for a case
where the correct behavior is *not* giving an error.
I have also written and shown Herve's example to the R-core team.
Unfortunately, I have no platform where I can trigger th
Re: [Bioc-devel] Problem for Biostrings?
Hi Hai, Looks you added CRAN ggforce recently (in February) to the Suggests field of Pi. ggforce depends on CRAN package udunits2, which itself requires system library libudunits2 in order to compile on Linux, which itself can be installed with sudo apt-get install libudunits2-dev on Debian/Ubuntu. We didn't have libudunits2-dev on malbec2 yet so I just installed it. The fact that we didn't have it indicates that Pi is the first Bioconductor package to (indirectly) require it. If everything goes as expected, Pi should turn all green on Friday. Cheers, H. On 03/29/2017 09:08 PM, hfang.shanghai wrote: Thanks for the clarification. Now everything is ok except the check in Linux (https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_Pi_malbec2-2Dchecksrc.html=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q6QK4JMsHgaqD9x6avyUhERn3LtF6NIbMxmXc_omuXE=0Y-86XDQL67bMUlLmRJOg3cEWekH9GHDJNrc5ZEStPg= ). The package 'ggforce' is not preinstalled in Linux (others seem fine). Best, Hai Sent from my iPhone On 29 Mar 2017, at 17:17, Michael Lawrence <lawrence.mich...@gene.com> wrote: It's actually an error in rtracklayer. On Wed, Mar 29, 2017 at 8:28 AM, Shepherd, Lori <lori.sheph...@roswellpark.org> wrote: That is correct. When the Biostrings package is corrected this ERROR in your package should resolve automatically. Lori Shepherd Bioconductor Core Team Roswell Park Cancer Institute Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 From: Bioc-devel <bioc-devel-boun...@r-project.org> on behalf of Hai Fang <hf...@well.ox.ac.uk> Sent: Wednesday, March 29, 2017 10:28:39 AM To: bioc-devel@r-project.org Subject: [Bioc-devel] Problem for Biostrings? Hi, I got the error ��object ��inverted�� is not exported by 'namespace:Biostrings�� at https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_Pi_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q6QK4JMsHgaqD9x6avyUhERn3LtF6NIbMxmXc_omuXE=2bhT9aV6mJhSUF8Iq3BZHB_Y2EVt0wNFx6ZcylnnUaE= . It seems due to the package ��Biostrings�� which failed to pass the check (https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_Biostrings_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q6QK4JMsHgaqD9x6avyUhERn3LtF6NIbMxmXc_omuXE=COIN8OGj-Nd6NzWJEoBq6sXBbJLSqHoZpwPKuGe8DH8= ). Is it right or something else? Thanks, Hai [[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=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q6QK4JMsHgaqD9x6avyUhERn3LtF6NIbMxmXc_omuXE=mA0gVnx-5AftDivwP-G_hbeYRiXwDTZj1PW75JbUyeA= 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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q6QK4JMsHgaqD9x6avyUhERn3LtF6NIbMxmXc_omuXE=mA0gVnx-5AftDivwP-G_hbeYRiXwDTZj1PW75JbUyeA= ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q6QK4JMsHgaqD9x6avyUhERn3LtF6NIbMxmXc_omuXE=mA0gVnx-5AftDivwP-G_hbeYRiXwDTZj1PW75JbUyeA= [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q6QK4JMsHgaqD9x6avyUhERn3LtF6NIbMxmXc_omuXE=mA0gVnx-5AftDivwP-G_hbeYRiXwDTZj1PW75JbUyeA= -- 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@
Re: [Bioc-devel] pc algorithm library missing on linux builder
Hi Martin, Not sure what happened during automatic installation of CRAN package pcalg by the build system on malbec2 but it seems that the installed package ended up being in a broken state. I just went on malbec2 and re-installed the package by hand so normally epiNEM should look all green on Friday and finally get its first landing page! Cheers, H. On 03/29/2017 05:21 AM, Pirkl Martin wrote: Hi, our package epiNEM produces an error on the linux builder, due to some missing pcalg library. This seems to be an error on the builder’s end, because the packages ddgraph and miRLAB suffer the same error, also exclusively for the linux builder. Does that problem go hand in hand with the fact that epiNEM, as a new package, does not have a bioconductor page, yet? https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_epiNEM_=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=IQ80f2gw2TiMG5P5VdfItKwCWqUWiqsOAFV9iOTcnWE=Kgt1MtgBzuNYGNwW_1TeM75NsCC6MLapIqNLhO5jVXA= Best, Martin ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=IQ80f2gw2TiMG5P5VdfItKwCWqUWiqsOAFV9iOTcnWE=ux8SUf3VJNpBqcDPbSXsaXU__k6OBYclyuQraBKZ8qM= -- 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] condition tests on vectors with length greater than 1
nameSeqlevels(txdb, sub("chr", "CH", seqlevels(txdb)))
Error in if (mode == -2L) { : the condition has length > 1
Calls: renameSeqlevels -> seqlevels<- -> seqlevels<-
Execution halted
I then could get a relatively simple reproducible example in R with
$ _R_CHECK_LENGTH_1_CONDITION_=TRUE R --vanilla
suppressPackageStartupMessages(library(GenomeInfoDb))
example("seqlevels-wrappers")
After installing the updated GenomicFeatures package, the error did not
occur. Likewise, running GenomeInfoDb-Ex.R did not generate any errors.
Martin
This email message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee
or agent responsible for the delivery of this message to the intended
recipient(s), you are hereby notified that any disclosure, copying,
distribution, or use of this email message is prohibited. If you have
received this message in error, please notify the sender immediately by
e-mail and delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=RZzoWcMLUW_D96-oXJ1AMgVIohSuF9eeLh4WSmEmjFg=2xVPo2OzTo1DpMueTH6ICx5doNmuJ8O7iwJC4ZVGTE0=
--
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: [Rd] Transferring ownership of R-managed buffer
On 03/29/2017 11:04 AM, Hervé Pagès wrote: Hi Tim, On 03/29/2017 08:24 AM, Tim Keitt wrote: I have a use case where I would like to create an SEXP around an existing buffer that is managed by R, thus avoiding a copy operation. What to you mean exactly by "an existing buffer managed by R"? If I have something like: void *p = (void*) RAW(PROTECT(Rf_allocVector(RAWSXP, n))); ... additional maniupulation ... SEXP x = somefunc(SXPTYPE, n, p); // Is there a "placement" constructor available? What's a "placement" constructor? (I have arranged for the corresponding UNPROTECT.) I've looked at and experimented with R_allocator and allocVector3, but can't quite get it right. I know this is odd, but it makes sense for my use case. Not sure I follow what you are trying to do. Note that an SEXP is a pointer to a C struct called SEXPREC. I think that trying to point an SEXPREC struct to data pointed to by an existing SEXPREC struct is very likely to lead to a disaster. Note that if the existing buffer managed by R is an SEXP (e.g. b) and your code has access to this SEXP then you don't need to create another SEXP around its data. Since SEXPs are pointers doing SEXP x = b; is fine and doesn't generate any copy. And if your code only has access to a "naked" pointer to the buffer managed by R (e.g. to RAW(b) is the buffer is actually in an SEXP) ^^ if sorry H. then why would you need to wrap it inside an SEXP? H. Thanks for any pointers. THK https://urldefense.proofpoint.com/v2/url?u=http-3A__www.keittlab.org_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Ceu5dLU_mdGwmpIk_iUqE0dPNjqwy8wiRy6hS_lWF9k=h04DJujKDfqzbLz4FmP3_fZ5bYS3t7UEjSwpLrW5mL0= [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Ceu5dLU_mdGwmpIk_iUqE0dPNjqwy8wiRy6hS_lWF9k=WpLxtWWwjoZ7TjW6oW-vxE6s3LY5kZCG1H5h0xb0Bbs= -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Transferring ownership of R-managed buffer
Hi Tim, On 03/29/2017 08:24 AM, Tim Keitt wrote: I have a use case where I would like to create an SEXP around an existing buffer that is managed by R, thus avoiding a copy operation. What to you mean exactly by "an existing buffer managed by R"? If I have something like: void *p = (void*) RAW(PROTECT(Rf_allocVector(RAWSXP, n))); ... additional maniupulation ... SEXP x = somefunc(SXPTYPE, n, p); // Is there a "placement" constructor available? What's a "placement" constructor? (I have arranged for the corresponding UNPROTECT.) I've looked at and experimented with R_allocator and allocVector3, but can't quite get it right. I know this is odd, but it makes sense for my use case. Not sure I follow what you are trying to do. Note that an SEXP is a pointer to a C struct called SEXPREC. I think that trying to point an SEXPREC struct to data pointed to by an existing SEXPREC struct is very likely to lead to a disaster. Note that if the existing buffer managed by R is an SEXP (e.g. b) and your code has access to this SEXP then you don't need to create another SEXP around its data. Since SEXPs are pointers doing SEXP x = b; is fine and doesn't generate any copy. And if your code only has access to a "naked" pointer to the buffer managed by R (e.g. to RAW(b) is the buffer is actually in an SEXP) then why would you need to wrap it inside an SEXP? H. Thanks for any pointers. THK https://urldefense.proofpoint.com/v2/url?u=http-3A__www.keittlab.org_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Ceu5dLU_mdGwmpIk_iUqE0dPNjqwy8wiRy6hS_lWF9k=h04DJujKDfqzbLz4FmP3_fZ5bYS3t7UEjSwpLrW5mL0= [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Ceu5dLU_mdGwmpIk_iUqE0dPNjqwy8wiRy6hS_lWF9k=WpLxtWWwjoZ7TjW6oW-vxE6s3LY5kZCG1H5h0xb0Bbs= -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] xps build problem on veracruz2
On 03/24/2017 11:37 AM, cstrato wrote: On 03/24/17 19:23, Hervé Pagès wrote: On 03/24/2017 11:10 AM, cstrato wrote: On 03/24/17 18:02, Hervé Pagès wrote: On 03/24/2017 06:52 AM, cstrato wrote: R/Bioc is still building on Mavericks, Not for R devel (3.4). The R folks have switched to El Capitan a few days ago: You are right, I did not check R devel. https://urldefense.proofpoint.com/v2/url?u=https-3A__r.research.att.com_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=aV7U6Qu8HkkL9dhD7thXz2c2geZd1KmfWnoZkiyu6hs=EDYb8eN2bAg_TtTfDURARDLiz4AoKggk2QLfABIdxTA= and before was built on Snow Leopard (which many people are sill using). Personally I think that it does not make much difference whether Mavericks or El Capitan (or Yosemite) is used to build R/Bioc. How much experience you have with setting a Mavericks or El Capitan build machine to build and distribute thousands of package binaries for hundreds ot thousands of users? You probably misunderstood what I wanted to say. It is clear to me that you are doing a great job distributing thousands of package binaries. No one does know it better than me with the special problems you have to build binaries for xps. I really appreciate that during all these years you and Dan (and others) managed to support xps like all other BioC packages. I meant that from the user standpoint it probably does not matter much which of these three systems are used to build BioC, in contrast to Sierra. Of course it matters. If you use an older OS than the one we use to produce the binaries then some binaries won't work for you. You keep missing the whole point. H. Sorry, but I do understand this point. Users who are still using e.g. Snow Leopard (because they think this was the best system) will have problems. For that reason I thought that maybe it is best to use the system which is currently used by most users. That would be the thing to do if we didn't have neither forward- nor backward- compatibility. But we *do* have forward-compatibility. So there is no reason to use the system which is currently used by most users. It's enough to make sure that we use a system that is *compatible* with what most users have. And also not too old because it's hard to find powerful hardware that runs old OS X versions and because many software components needed for the builds are not available or not maintained anymore for old OS X versions. Like Dan said, it's a tradeoff. H. Christian But as you said below backward-compatibility is always lost, so the question which system to use to build R/BioC is always tricky. Maybe, the best (?) decision would be to use the system which most Mac users are currently using, but I don't know. Best regards, Christian However, Sierra is different, and when the CRAN people are experimenting with clang 4.0.0 for producing the Mac binaries, as Herve has mentioned, then backwards-compatibility would probably be lost anyhow. I think you misunderstood what Dan said. Backward-compatibility is always lost i.e. binaries built on a given OS X versions are not guaranteed to be backward compatible with older OS X versions. That's why building them on the latest OS X version is a bad idea. But I understand that this is a decision the CRAN people have to make. You're welcome to discuss this choice on the R-SIG-Mac mailing list. Cheers, H. Best regards, Christian On 03/24/17 01:10, Dan Tenenbaum wrote: - Original Message - From: "Hervé Pagès" <hpa...@fredhutch.org> To: "cstrato" <cstr...@aon.at>, "bioc-devel" <bioc-devel@r-project.org> Sent: Thursday, March 23, 2017 12:14:38 PM Subject: Re: [Bioc-devel] xps build problem on veracruz2 On 03/23/2017 11:09 AM, cstrato wrote: Dear Herve, Thank you for your explanation. The reason that xps does not work with ROOT 6 is that I have tried it but there seem to be so many changes, that I did not succeed. Since for xps there is no advantage using ROOT 6 vs ROOT 5, and ROOT 5 was still supported, I have decided to stay with ROOT 5. OK BTW, I have also one question: Why did you decide to set up a new Mac with El Capitan instead of using the newest OS Sierra? (I have the impression that most Mac users are either happy to stay with their old OS or they upgrade to the newest one.) Same reason as for the choice of compilers: that's what the R folks decided to use for producing the Mac binaries of R and CRAN packages. We're just following their lead on that. Also, it's always good not to require users to upgrade if they don't have to. Building on El Capitan means users will not have to upgrade to macOS Sierra if they don't want to. Building on Sierra would mean R and packages would not be backwards-compatible with El Capitan. But it's a tradeoff that also involves the difficulty of maintaining build machines with old OSes, and wanting to take advantage of newer compiler tech
Re: [Bioc-devel] xps build problem on veracruz2
On 03/24/2017 11:10 AM, cstrato wrote: On 03/24/17 18:02, Hervé Pagès wrote: On 03/24/2017 06:52 AM, cstrato wrote: R/Bioc is still building on Mavericks, Not for R devel (3.4). The R folks have switched to El Capitan a few days ago: You are right, I did not check R devel. https://urldefense.proofpoint.com/v2/url?u=https-3A__r.research.att.com_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=aV7U6Qu8HkkL9dhD7thXz2c2geZd1KmfWnoZkiyu6hs=EDYb8eN2bAg_TtTfDURARDLiz4AoKggk2QLfABIdxTA= and before was built on Snow Leopard (which many people are sill using). Personally I think that it does not make much difference whether Mavericks or El Capitan (or Yosemite) is used to build R/Bioc. How much experience you have with setting a Mavericks or El Capitan build machine to build and distribute thousands of package binaries for hundreds ot thousands of users? You probably misunderstood what I wanted to say. It is clear to me that you are doing a great job distributing thousands of package binaries. No one does know it better than me with the special problems you have to build binaries for xps. I really appreciate that during all these years you and Dan (and others) managed to support xps like all other BioC packages. I meant that from the user standpoint it probably does not matter much which of these three systems are used to build BioC, in contrast to Sierra. Of course it matters. If you use an older OS than the one we use to produce the binaries then some binaries won't work for you. You keep missing the whole point. H. But as you said below backward-compatibility is always lost, so the question which system to use to build R/BioC is always tricky. Maybe, the best (?) decision would be to use the system which most Mac users are currently using, but I don't know. Best regards, Christian However, Sierra is different, and when the CRAN people are experimenting with clang 4.0.0 for producing the Mac binaries, as Herve has mentioned, then backwards-compatibility would probably be lost anyhow. I think you misunderstood what Dan said. Backward-compatibility is always lost i.e. binaries built on a given OS X versions are not guaranteed to be backward compatible with older OS X versions. That's why building them on the latest OS X version is a bad idea. But I understand that this is a decision the CRAN people have to make. You're welcome to discuss this choice on the R-SIG-Mac mailing list. Cheers, H. Best regards, Christian On 03/24/17 01:10, Dan Tenenbaum wrote: - Original Message - From: "Hervé Pagès" <hpa...@fredhutch.org> To: "cstrato" <cstr...@aon.at>, "bioc-devel" <bioc-devel@r-project.org> Sent: Thursday, March 23, 2017 12:14:38 PM Subject: Re: [Bioc-devel] xps build problem on veracruz2 On 03/23/2017 11:09 AM, cstrato wrote: Dear Herve, Thank you for your explanation. The reason that xps does not work with ROOT 6 is that I have tried it but there seem to be so many changes, that I did not succeed. Since for xps there is no advantage using ROOT 6 vs ROOT 5, and ROOT 5 was still supported, I have decided to stay with ROOT 5. OK BTW, I have also one question: Why did you decide to set up a new Mac with El Capitan instead of using the newest OS Sierra? (I have the impression that most Mac users are either happy to stay with their old OS or they upgrade to the newest one.) Same reason as for the choice of compilers: that's what the R folks decided to use for producing the Mac binaries of R and CRAN packages. We're just following their lead on that. Also, it's always good not to require users to upgrade if they don't have to. Building on El Capitan means users will not have to upgrade to macOS Sierra if they don't want to. Building on Sierra would mean R and packages would not be backwards-compatible with El Capitan. But it's a tradeoff that also involves the difficulty of maintaining build machines with old OSes, and wanting to take advantage of newer compiler technology. Otherwise R/Bioc would still be building on Mavericks, or Snow Leopard... Dan Cheers, H. Best regards, Christian On 03/23/17 17:47, Hervé Pagès wrote: Hi Christian, The CRAN folks are currently experimenting with clang 4.0.0 for producing the Mac binaries of R and CRAN packages so we are using the same on veracruz2. This is a version of clang that is ahead of what's in XCode 8.x or XCode 7.x. So I guess that means we'll have to compile ROOT from source on veracruz2. BTW any reason not to make xps work with ROOT 6? Cheers, H. On 03/23/2017 07:28 AM, cstrato wrote: Dear Valerie, I have seen that you have set up a new Mac server, veracruz2, running El Capitan. Although the development version of xps does even run on Mac OS Sierra, one issue still remains the same: You need to install the latest ROOT version 5, since xps does not run with ROOT 6! So you need to install on veracruz2 the same
Re: [Bioc-devel] xps build problem on veracruz2
On 03/24/2017 06:52 AM, cstrato wrote: R/Bioc is still building on Mavericks, Not for R devel (3.4). The R folks have switched to El Capitan a few days ago: https://r.research.att.com/ and before was built on Snow Leopard (which many people are sill using). Personally I think that it does not make much difference whether Mavericks or El Capitan (or Yosemite) is used to build R/Bioc. How much experience you have with setting a Mavericks or El Capitan build machine to build and distribute thousands of package binaries for hundreds ot thousands of users? However, Sierra is different, and when the CRAN people are experimenting with clang 4.0.0 for producing the Mac binaries, as Herve has mentioned, then backwards-compatibility would probably be lost anyhow. I think you misunderstood what Dan said. Backward-compatibility is always lost i.e. binaries built on a given OS X versions are not guaranteed to be backward compatible with older OS X versions. That's why building them on the latest OS X version is a bad idea. But I understand that this is a decision the CRAN people have to make. You're welcome to discuss this choice on the R-SIG-Mac mailing list. Cheers, H. Best regards, Christian On 03/24/17 01:10, Dan Tenenbaum wrote: - Original Message - From: "Hervé Pagès" <hpa...@fredhutch.org> To: "cstrato" <cstr...@aon.at>, "bioc-devel" <bioc-devel@r-project.org> Sent: Thursday, March 23, 2017 12:14:38 PM Subject: Re: [Bioc-devel] xps build problem on veracruz2 On 03/23/2017 11:09 AM, cstrato wrote: Dear Herve, Thank you for your explanation. The reason that xps does not work with ROOT 6 is that I have tried it but there seem to be so many changes, that I did not succeed. Since for xps there is no advantage using ROOT 6 vs ROOT 5, and ROOT 5 was still supported, I have decided to stay with ROOT 5. OK BTW, I have also one question: Why did you decide to set up a new Mac with El Capitan instead of using the newest OS Sierra? (I have the impression that most Mac users are either happy to stay with their old OS or they upgrade to the newest one.) Same reason as for the choice of compilers: that's what the R folks decided to use for producing the Mac binaries of R and CRAN packages. We're just following their lead on that. Also, it's always good not to require users to upgrade if they don't have to. Building on El Capitan means users will not have to upgrade to macOS Sierra if they don't want to. Building on Sierra would mean R and packages would not be backwards-compatible with El Capitan. But it's a tradeoff that also involves the difficulty of maintaining build machines with old OSes, and wanting to take advantage of newer compiler technology. Otherwise R/Bioc would still be building on Mavericks, or Snow Leopard... Dan Cheers, H. Best regards, Christian On 03/23/17 17:47, Hervé Pagès wrote: Hi Christian, The CRAN folks are currently experimenting with clang 4.0.0 for producing the Mac binaries of R and CRAN packages so we are using the same on veracruz2. This is a version of clang that is ahead of what's in XCode 8.x or XCode 7.x. So I guess that means we'll have to compile ROOT from source on veracruz2. BTW any reason not to make xps work with ROOT 6? Cheers, H. On 03/23/2017 07:28 AM, cstrato wrote: Dear Valerie, I have seen that you have set up a new Mac server, veracruz2, running El Capitan. Although the development version of xps does even run on Mac OS Sierra, one issue still remains the same: You need to install the latest ROOT version 5, since xps does not run with ROOT 6! So you need to install on veracruz2 the same root version that you have installed on toluca2 running Maverics, i.e. root_v5.34.36.macosx64-10.11-clang70.dmg However, if you have installed on El Capitan XCode 8.x instead of XCode 7.x, then you need to compile ROOT from source, i.e.: https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_download_root-5Fv5.34.36.source.tar.gz=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q9mk6yIytaNZlSdiLX_dFwchX8Tb7ra6x3WBBNIcs2o=Lz7YkqZ3XwjRsYIXVTbSvbDvTM-jTyoWvoVSa1PdBDw= The README file of xps does explain how to compile ROOT for Sierra. This should also be valid for El Capitan running XCode 8.x. Thank you in advance. Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ ___ 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=q9mk6yIytaNZlSdiLX_dFwchX8Tb7ra6x3WBBNIcs2o=0bNMm-aoHuwWs9yBRjyGHTxT0y3UceNADHgMjtosTWU= -- Hervé Pagès Program in Computational Biology Division of Public
Re: [Bioc-devel] Incorrect order of installing dependencies on OS X in bioc-devel in travis
Hi Alexey, Based on the Travis build report, it looks like Travis used install.packages() to install reactome.db. What makes you think it used biocLite()? The problem seems to be related to the fact that reactome.db deps are divided in 2 groups: binary packages on one side and source packages on the other side. The installation procedure seems to treat each group separately and independently: binary packages first, and then source packages. This is flawed design to me, even if the "testing if installed package can be loaded" step is skipped when installing a binary package, which seems like an ostrich strategy to ignore possibly missing deps during the process. What's also puzzling with this Travis build report is that it looks like the binary packages were downloaded but not installed! This would explain why installation of reactome.db (source package) fails later (AnnotationDbi binary was downloaded but not installed). Flawed design "binaries first, then source packages" should actually work as long as (1) there is no attempt to load binary packages immediately after their installation and (2) the source packages are installed in topological order after all the binary packages have been installed. Cheers, H. On 03/23/2017 02:14 PM, Alexey Sergushichev wrote: Hello all, I'm using travis for checking my project build and found something that looks like a bug in how biocLite installs package dependencies. It appears that at some point biocLite started to install them in an alphabet order, not topological, and specifically on OS X. I've made a small dummy package to illustrate this: see https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_assaron_travis-2Dtest=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ECGVqk534I_zBnZd1EBIrNR6efOzyEjt8YnPElhR1DU=aNFQogh-gU_9sSF80iI9ROXy70ayZvLrkPoKYiqGPQE= and corresponding travis build https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_assaron_travis-2Dtest=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ECGVqk534I_zBnZd1EBIrNR6efOzyEjt8YnPElhR1DU=Pf3mEHAtHZHCN4WlB3cb37Y2Wf_p2v_7mT2oBQGSIow= . There reactome.db package should be installed but fails on osx platform in bioc-devel version. What happens there is reactome.db is installed before RSQLite, while reactome.db dependes on RSQLite via AnnotationDbi ( https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_assaron_travis-2Dtest_jobs_214404313-23L630=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ECGVqk534I_zBnZd1EBIrNR6efOzyEjt8YnPElhR1DU=369SlWBQZQV3iA3lfRmQ2DuAuMOuMtdbMzZaB9o9LV0= ). Compare it with bioc-release version: https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_assaron_travis-2Dtest_jobs_214404316-23L543=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ECGVqk534I_zBnZd1EBIrNR6efOzyEjt8YnPElhR1DU=chGtEiWkCYtswsgsZLMArKK67TI_MiX6sTgzLsc-v_c= or bioc-devel but on linux: https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_assaron_travis-2Dtest_jobs_214389446-23L928=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ECGVqk534I_zBnZd1EBIrNR6efOzyEjt8YnPElhR1DU=6REbwOP9lyEopleeq2Em9yxahQF6vA7iVVCkGw73Ick= Can anyone reproduce this behavior at their OS X machine? Is this bug in biocLite or Travis? Best, Alexey [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=ECGVqk534I_zBnZd1EBIrNR6efOzyEjt8YnPElhR1DU=HC5qJ-IF0Lmc4QobgJA8rfOpOHR9bWaF4MtFchvQma0= -- 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] Unit Tests & Test Coverage
Hi Juan Pablo, Thanks for adding unit tests to your package. We really encourage developers to do this. I'm sorry that this is not reflected on EventPointer's landing page. I investigated this a bit (I'm not familiar with how the coverage badges are generated on the package landing pages) and here is what I found so far. One possible reason for this is that some packages on Bioconductor-mirror are lagging behind their latest svn revision. This is actually the case right now for EventPointer. Latest svn commit is 127626: https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/EventPointer but the package is still at commit 127616 on Bioconductor-mirror: https://github.com/Bioconductor-mirror/EventPointer This is a known issue. We'll try to remedy this ASAP. This can be a reason why coverage is not updated on a package landing page. That's because the script we use for computing the coverage interacts with our svn repo (on hedgehog.fhcrc.org) in order to get the latest revision of the package, but also with the Bioconductor-mirror account on github (https://github.com/Bioconductor-mirror/) in order to map the latest svn revision of a package to the corresponding git commit on Bioconductor-mirror. This seems to be needed in order to upload the coverage results to codecov.io where the coverage history is kept e.g. https://codecov.io/github/Bioconductor-mirror/VariantAnnotation/branch/master The coverage information displayed on a package landing page is coming from there. When a package is lagging behind on Bioconductor-mirror, the mapping between last svn revision and git commit fails and so uploading the coverage results to codecov.io also fails. However, in the case of EventPointer, there seems to be already 1 point in the coverage history at codecov.io: https://codecov.io/github/Bioconductor-mirror/EventPointer/branch/master It shows a coverage of about 30%. For some reason, this doesn't show up on EventPointer's landing page. I'll investigate more and will let you know. H. On 03/23/2017 04:58 AM, Romero, Juan Pablo wrote: Hi, I'm currently doing the last updates to my package EventPointer before the deadline for next BioC release. I've added unit tests according to the guide lines in https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_developers_unitTesting-2Dguidelines_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=4xEe7s13qw8OtBMzGMqJ0vk6PIoU68FR0RJ88otY0yg=47DUypCrCnkcv9C1Mlybb0QHi3RLMZh57Q35XoIXkBU= and the package build report shows no problems for both build and check in all systems. However, the test coverage tab at top of the package page still displays "unknown" and im not sure if there is any problem with the tests or how to find possible errors. Here is what the build report shows in all OS: * checking examples ... OK * checking for unstated dependencies in �tests� ... OK * checking tests ... Running �runTests.R� OK * checking for unstated dependencies in vignettes ... OK * checking package vignettes in �inst/doc� ... OK Thanks! Best regards, Juan Pablo Romero [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=4xEe7s13qw8OtBMzGMqJ0vk6PIoU68FR0RJ88otY0yg=cT2EjT9BIxY3Q8Nmikk0rGfWteNuwuaDEpwNFwpjL2g= -- 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] xps build problem on veracruz2
On 03/23/2017 11:09 AM, cstrato wrote: Dear Herve, Thank you for your explanation. The reason that xps does not work with ROOT 6 is that I have tried it but there seem to be so many changes, that I did not succeed. Since for xps there is no advantage using ROOT 6 vs ROOT 5, and ROOT 5 was still supported, I have decided to stay with ROOT 5. OK BTW, I have also one question: Why did you decide to set up a new Mac with El Capitan instead of using the newest OS Sierra? (I have the impression that most Mac users are either happy to stay with their old OS or they upgrade to the newest one.) Same reason as for the choice of compilers: that's what the R folks decided to use for producing the Mac binaries of R and CRAN packages. We're just following their lead on that. Cheers, H. Best regards, Christian On 03/23/17 17:47, Hervé Pagès wrote: Hi Christian, The CRAN folks are currently experimenting with clang 4.0.0 for producing the Mac binaries of R and CRAN packages so we are using the same on veracruz2. This is a version of clang that is ahead of what's in XCode 8.x or XCode 7.x. So I guess that means we'll have to compile ROOT from source on veracruz2. BTW any reason not to make xps work with ROOT 6? Cheers, H. On 03/23/2017 07:28 AM, cstrato wrote: Dear Valerie, I have seen that you have set up a new Mac server, veracruz2, running El Capitan. Although the development version of xps does even run on Mac OS Sierra, one issue still remains the same: You need to install the latest ROOT version 5, since xps does not run with ROOT 6! So you need to install on veracruz2 the same root version that you have installed on toluca2 running Maverics, i.e. root_v5.34.36.macosx64-10.11-clang70.dmg However, if you have installed on El Capitan XCode 8.x instead of XCode 7.x, then you need to compile ROOT from source, i.e.: https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_download_root-5Fv5.34.36.source.tar.gz=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q9mk6yIytaNZlSdiLX_dFwchX8Tb7ra6x3WBBNIcs2o=Lz7YkqZ3XwjRsYIXVTbSvbDvTM-jTyoWvoVSa1PdBDw= The README file of xps does explain how to compile ROOT for Sierra. This should also be valid for El Capitan running XCode 8.x. Thank you in advance. Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ ___ 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=q9mk6yIytaNZlSdiLX_dFwchX8Tb7ra6x3WBBNIcs2o=0bNMm-aoHuwWs9yBRjyGHTxT0y3UceNADHgMjtosTWU= -- 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] xps build problem on veracruz2
Hi Christian, The CRAN folks are currently experimenting with clang 4.0.0 for producing the Mac binaries of R and CRAN packages so we are using the same on veracruz2. This is a version of clang that is ahead of what's in XCode 8.x or XCode 7.x. So I guess that means we'll have to compile ROOT from source on veracruz2. BTW any reason not to make xps work with ROOT 6? Cheers, H. On 03/23/2017 07:28 AM, cstrato wrote: Dear Valerie, I have seen that you have set up a new Mac server, veracruz2, running El Capitan. Although the development version of xps does even run on Mac OS Sierra, one issue still remains the same: You need to install the latest ROOT version 5, since xps does not run with ROOT 6! So you need to install on veracruz2 the same root version that you have installed on toluca2 running Maverics, i.e. root_v5.34.36.macosx64-10.11-clang70.dmg However, if you have installed on El Capitan XCode 8.x instead of XCode 7.x, then you need to compile ROOT from source, i.e.: https://urldefense.proofpoint.com/v2/url?u=https-3A__root.cern.ch_download_root-5Fv5.34.36.source.tar.gz=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=q9mk6yIytaNZlSdiLX_dFwchX8Tb7ra6x3WBBNIcs2o=Lz7YkqZ3XwjRsYIXVTbSvbDvTM-jTyoWvoVSa1PdBDw= The README file of xps does explain how to compile ROOT for Sierra. This should also be valid for El Capitan running XCode 8.x. Thank you in advance. Best regards, Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ ___ 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=q9mk6yIytaNZlSdiLX_dFwchX8Tb7ra6x3WBBNIcs2o=0bNMm-aoHuwWs9yBRjyGHTxT0y3UceNADHgMjtosTWU= -- 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] The story of tracing a derfinder bug on OSX that sometimes popped up, sometimes it didn't. Related to IRanges/S4Vectors '$<-'
On 03/21/2017 05:28 PM, Martin Morgan wrote:
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?
That's a little bit complicated for me at the moment. I was
actually running this code on build machines toluca2 and (upcoming)
veracruz2 and we don't have valgrind there for now. I don't have
access to other Macs so hopefully someone else will be able to help
with this.
H.
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 <-
locfi
Re: [Bioc-devel] The story of tracing a derfinder bug on OSX that sometimes popped up, sometimes it didn't. Related to IRanges/S4Vectors '$<-'
1.43.7 2017-02-24 Bioconductor bumphunter * 1.15.0 2016-10-23 Bioconductor checkmate 1.8.22016-11-02 CRAN (R 3.4.0) cluster2.0.62017-03-16 CRAN (R 3.4.0) codetools 0.2-15 2016-10-05 CRAN (R 3.4.0) colorout * 1.1-22016-11-15 Github (jalvesaq/colorout@6d84420) colorspace 1.3-22016-12-14 CRAN (R 3.4.0) crayon 1.3.22016-06-28 CRAN (R 3.4.0) data.table 1.10.4 2017-02-01 CRAN (R 3.4.0) DBI0.6 2017-03-09 CRAN (R 3.4.0) DelayedArray 0.1.72017-02-17 Bioconductor derfinder* 1.9.10 2017-03-17 cran (@1.9.10) derfinderHelper1.9.42017-03-07 Bioconductor devtools 1.12.0 2016-12-05 CRAN (R 3.4.0) digest 0.6.12 2017-01-27 CRAN (R 3.4.0) doRNG 1.6 2014-03-07 CRAN (R 3.4.0) foreach * 1.4.32015-10-13 CRAN (R 3.4.0) foreign0.8-67 2016-09-13 CRAN (R 3.4.0) Formula1.2-12015-04-07 CRAN (R 3.4.0) GenomeInfoDb * 1.11.9 2017-02-08 Bioconductor GenomeInfoDbData 0.99.0 2017-02-14 Bioconductor GenomicAlignments 1.11.12 2017-03-16 cran (@1.11.12) GenomicFeatures1.27.10 2017-03-16 cran (@1.27.10) GenomicFiles 1.11.4 2017-03-10 Bioconductor GenomicRanges* 1.27.23 2017-02-25 Bioconductor ggplot22.2.12016-12-30 CRAN (R 3.4.0) gridExtra 2.2.12016-02-29 CRAN (R 3.4.0) gtable 0.2.02016-02-26 CRAN (R 3.4.0) Hmisc 4.0-22016-12-31 CRAN (R 3.4.0) htmlTable 1.9 2017-01-26 CRAN (R 3.4.0) htmltools 0.3.52016-03-21 CRAN (R 3.4.0) htmlwidgets0.8 2016-11-09 CRAN (R 3.4.0) IRanges * 2.9.19 2017-03-15 cran (@2.9.19) iterators* 1.0.82015-10-13 CRAN (R 3.4.0) knitr 1.15.1 2016-11-22 CRAN (R 3.4.0) lattice0.20-34 2016-09-06 CRAN (R 3.4.0) latticeExtra 0.6-28 2016-02-09 CRAN (R 3.4.0) lazyeval 0.2.02016-06-12 CRAN (R 3.4.0) locfit * 1.5-9.1 2013-04-20 CRAN (R 3.4.0) magrittr 1.5 2014-11-22 CRAN (R 3.4.0) Matrix 1.2-82017-01-20 CRAN (R 3.4.0) matrixStats0.51.0 2016-10-09 CRAN (R 3.4.0) memoise1.0.02016-01-29 CRAN (R 3.4.0) munsell0.4.32016-02-13 CRAN (R 3.4.0) nnet 7.3-12 2016-02-02 CRAN (R 3.4.0) pkgmaker 0.22 2014-05-14 CRAN (R 3.4.0) plyr 1.8.42016-06-08 CRAN (R 3.4.0) qvalue 2.7.02016-10-23 Bioconductor R6 2.2.02016-10-05 CRAN (R 3.4.0) RColorBrewer 1.1-22014-12-07 CRAN (R 3.4.0) Rcpp 0.12.10 2017-03-19 CRAN (R 3.4.0) RCurl 1.95-4.8 2016-03-01 CRAN (R 3.4.0) registry 0.3 2015-07-08 CRAN (R 3.4.0) reshape2 1.4.22016-10-22 CRAN (R 3.4.0) rngtools 1.2.42014-03-06 CRAN (R 3.4.0) rpart 4.1-10 2015-06-29 CRAN (R 3.4.0) Rsamtools 1.27.13 2017-03-14 cran (@1.27.13) RSQLite1.1-22017-01-08 CRAN (R 3.4.0) rtracklayer1.35.9 2017-03-19 cran (@1.35.9) S4Vectors* 0.13.15 2017-02-14 cran (@0.13.15) scales 0.4.12016-11-09 CRAN (R 3.4.0) stringi1.1.22016-10-01 CRAN (R 3.4.0) stringr1.2.02017-02-18 CRAN (R 3.4.0) SummarizedExperiment 1.5.72017-02-23 Bioconductor survival 2.41-2 2017-03-16 CRAN (R 3.4.0) testthat * 1.0.22016-04-23 CRAN (R 3.4.0) tibble 1.2 2016-08-26 CRAN (R 3.4.0) VariantAnnotation 1.21.17 2017-02-12 Bioconductor withr 1.0.22016-06-20 CRAN (R 3.4.0) XML3.98-1.5 2016-11-10 CRAN (R 3.4.0) xtable 1.8-22016-02-05 CRAN (R 3.4.0) XVector 0.15.2 2017-02-02 Bioconductor zlibbioc 1.21.0 2016-10-23 Bioconductor ___ Bioc-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Bw-1Kqy-M_t4kmpYWTpYkt5bvj_eTpxriUM3UvtOIzQ=hEBTd8bPfLVp6HoN3XSBk6ppmeRZhdLoB8VseYM_Byk= -- 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] Package not being built on Windows or Mac
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" <jmac...@uw.edu> To: "Robert M. Flight" <rfligh...@gmail.com> Cc: "bioc-devel" <bioc-devel@r-project.org> 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 <rfligh...@gmail.com> 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
Re: [Bioc-devel] Question on the build and biocheck of the package
Hi Ar,
On 03/15/2017 12:57 AM, Aayush Raman wrote:
Hello Everyone,
I have developed a Bioconductor package and submit the issue to build and
check. I have some questions regarding on the build and BioCheck of the
package. Here are the questions:
1. It has passed the build and check on Mac OS and Windows. However, when I
am checking it on linux, I am getting the following error:
"ERROR: dependencies ‘NMF’, ‘cvxclustr’ are not available for package
‘DASC’"
Although, I know the NMF and cvxclustr are not present in the linux
machine, I would like to know if it possible to build the package by
installing other packages that my package depends on ? I am already
mentioned it on DESCRIPTION file. Do I need to do anything else before
submitting my package ?
You have these packages listed in your Imports field so they will be
automatically installed by the Single Package Builder on the 3 build
machines if they are not already present.
2. After successfully building (using R CMD build) and checking (R CMD
check), I did a BiocCheck on my package. I got 2 warnings:
a. WARNING: Use FALSE instead of F (found in 1 files)
I am using a function called norm (from base package) where I need to
specify the type. The type I would like to use is Frobenius norm which is
specified by "F/f". How can I remove this warning ? or infom bioconductor
about this warning prior to their checks ?
I don't see this when I run Rbiocdev CMD BiocCheck DASC_0.1.1.tar.gz.
Have you addressed this already? Please note that the way to specify
the type in base::norm() is with a 1-letter *string* ("O", "I", "F",
"M", or "2"). This has nothing to do with the use of F (unquoted) for
specifying the single logical value FALSE.
b. WARNING: Add non-empty \value sections to the following man pages:
data.Rd:
data.Rd is a dataset that I will be uploading with our package. I would
like to know how can I remove this error ?
Man pages for data sets need a \format section instead of a \value
section. If you have one, and R CMD BiocCheck still complains about
the lack of a \value section, please ignore the warning.
Hope this helps,
H.
Any help or advice would be much appreciated.
Thanks,
-Ar
[[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=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YiZGNUYd-khI-yvgitdzYaCkX0YYV4RafW040QHUJRo=-ddB-ch5A6i-pe7QzHb6mH7ARR6Rap0LnufSyE_Qjvg=
--
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] GRangesList Conversion Fails For Unstranded Sequencing Data
Hi, On 03/13/2017 11:00 PM, Dario Strbenac wrote: Good day, countOverlaps doesn't work for a GAlignmentPairs object with strandMode set to 0. This is because of an oversight in the grglist function. It has an if statement that checks whether the strand mode is 1 or 2. Then, it tries to subset the variable 'x_unlisted'. However, if strand mode is 0, neither of the conditional sections of code are executed and Error in .local(x, use.names, use.mcols, ...) : object 'x_unlisted' not found happens because the 'x_unlisted' variable has not been created. Thanks for catching and reporting this. Should be fixed in GenomicAlignments 1.11.12. It's a surprise no one else has encountered this bug before. Maybe because few people know they can set the strandMode to 0. I think most people with unstranded protocol just use the default strandMode (i.e. 1) and specify ignore.strand=TRUE when calling countOverlaps() or summarizeOverlaps(). H. -- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia ___ 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=aXT77JwOk3MNlFamCwIVSAOe8rwwHpiEOXsNfNFXtBI=K-Uwhnqzwhw5myIbOiykznBlzKmVP2WAGor-9sYkl6M= -- 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] Bioconductor and R 3.3.3: Error in c(x, values) : could not find symbol "recursive" in environment of the generic function
Hi Henrik,
See here for similar problems reported earlier on our support site:
https://support.bioconductor.org/p/93347/#93373
https://support.bioconductor.org/p/93590/#93595
I think you need to reinstall your packages after updating to R 3.3.
API compatibility across minor R releases is a myth :-/
H.
On 03/09/2017 05:38 PM, Henrik Bengtsson wrote:
Hi. FYI / Is anyone else experiencing:
Error in c(x, values) :
could not find symbol "recursive" in environment of the generic function
errors for some Bioconductor packages when running under R 3.3.3 while
they don't occur with R 3.3.2? This seems realted to the following R
3.3.3 NEWS entry:
c()'s argument use.names is documented now, as belonging to the (C
internal) default method. In “parallel”, argument recursive is also
moved from the generic to the default method, such that the formal
argument list of base generic c() is just (...).
One quick example is:
$ R --vanilla
example("callLOH", package = "PureCN")
[...]
head(callLOH(purecn.example.output))
Error in c(x, values) :
could not find symbol "recursive" in environment of the generic function
traceback()
24: c(x, values)
23: append(mcols(gr), slot(x, "fixed"))
22: append(mcols(gr), slot(x, "fixed"))
21: .local(x, ...)
20: rowRanges(x)
19: rowRanges(x)
18: (function (x, ...)
standardGeneric("start"))(x = rowRanges(x), ... = ...)
17: do.call(start, list(x = rowRanges(x), ... = ...))
16: do.call(start, list(x = rowRanges(x), ... = ...))
15: start(res$input$vcf)
14: start(res$input$vcf)
13: split(start(res$input$vcf), as.character(seqnames(res$input$vcf)))
12: vapply(split(start(res$input$vcf), as.character(seqnames(res$input$vcf))),
function(x) c(min(x), max(x)), c(min = double(1), max = double(1)))
11: t(vapply(split(start(res$input$vcf), as.character(seqnames(res$input$vcf))),
function(x) c(min(x), max(x)), c(min = double(1), max = double(1
10: withCallingHandlers(expr, warning = function(w)
invokeRestart("muffleWarning"))
9: suppressWarnings(t(vapply(split(start(res$input$vcf),
as.character(seqnames(res$input$vcf))),
function(x) c(min(x), max(x)), c(min = double(1), max = double(1)
8: .getArmLocations(res)
7: callLOH(purecn.example.output)
6: head(callLOH(purecn.example.output)) at Rex657e3e41cba7#8
5: eval(expr, envir, enclos)
4: eval(ei, envir)
3: withVisible(eval(ei, envir))
2: source(tf, local, echo = echo, prompt.echo = paste0(prompt.prefix,
getOption("prompt")), continue.echo = paste0(prompt.prefix,
getOption("continue")), verbose = verbose, max.deparse.length = Inf,
encoding = "UTF-8", skip.echo = skips, keep.source = TRUE)
1: example("callLOH", package = "PureCN")
sessionInfo()
R version 3.3.3 (2017-03-06)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.2 LTS
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats4parallel stats graphics grDevices utils datasets
[8] methods base
other attached packages:
[1] PureCN_1.2.3 VariantAnnotation_1.20.2
[3] Rsamtools_1.26.1 Biostrings_2.42.1
[5] XVector_0.14.0 SummarizedExperiment_1.4.0
[7] Biobase_2.34.0 GenomicRanges_1.26.3
[9] GenomeInfoDb_1.10.3IRanges_2.8.1
[11] S4Vectors_0.12.1 BiocGenerics_0.20.0
[13] DNAcopy_1.48.0
loaded via a namespace (and not attached):
[1] Rcpp_0.12.9 AnnotationDbi_1.36.2 GenomicAlignments_1.10.0
[4] zlibbioc_1.20.0 BiocParallel_1.8.1 BSgenome_1.42.0
[7] lattice_0.20-34 tools_3.3.3 grid_3.3.3
[10] data.table_1.10.4DBI_0.6 digest_0.6.12
[13] Matrix_1.2-8 RColorBrewer_1.1-2 rtracklayer_1.34.2
[16] bitops_1.0-6 biomaRt_2.30.0 RCurl_1.95-4.8
[19] memoise_1.0.0RSQLite_1.1-2GenomicFeatures_1.26.3
[22] XML_3.98-1.5
Exact same call works with:
sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
I see this type of error message running R CMD check on:
* PureCN_1.2.3.tar.gz
* Repitools_1.20.0.tar.gz
I probably have installed most of the dep packages on R 3.3.2 and then
upgraded to R 3.3.3.
Over and out,
Henrik
___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=j-wrwOYdw3tV8MRxh1bTywbrHtZp5MQWTT-07aOoyoE=uX9jH2vmSV2vAA029bdUq70SuPUT3jSUd3-cKnR-RA4=
Re: [Bioc-devel] phloseq error: invalid class “sample_data” object: superclass "vectorORfactor" not defined in the environment of the object's class
Hi Levi, At installation time, class definitions are cached somewhere in the package installation folder. So when you installed phyloseq the definition of the sample_data class got cached on your machine. Note that sample_data was extending vectorORfactor and it seems that this information gets cached somehow. When vectorORfactor got renamed vector_OR_factor, the information in the cache got out-of-sync which is why phyloseq needed to be re-installed. Re-installing the phyloseq binary doesn't help because binary packages contain their own cache of class definitions, Since the current binary (1.19.1) was made before the renaming of vectorORfactor (which happened in S4Vectors), the information contained in its cache of class definitions is also out-of-sync. I just bumped phyloseq version so new Windows and Mac binaries will be made and they'll have up-to-date class definitions in their cache. H. On 02/22/2017 11:20 AM, Levi Waldron wrote: On Feb 22, 2017 1:42 PM, "Vincent Carey" <st...@channing.harvard.edu> wrote: might there have been an object that references the obsolete class around? There were no objects in the environment, ie being loaded from an .RData, if that's what you mean. [[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=nZTeI-UIuD5hMTuROA6wkN5-wZTBYoKcKKKGr905TS8=F3gPX_Ud6Ah60K-UvTEUA1DibZSnKDoeswqryjQlt0c= -- 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] phloseq error: invalid class “sample_data” object: superclass "vectorORfactor" not defined in the environment of the object's class
Hi Levi,
Were you able to sort this out? I think we should emphasize the
importance of re-installing packages *from source* (i.e. with
biocLite(..., type="source")). This is because some of the package
binaries we distribute seem to be affected by this problem too.
We're planning to fix these binaries over the next couple of days.
Sorry for the inconvenience,
H.
On 02/19/2017 07:58 AM, Levi Waldron wrote:
On Sun, Feb 19, 2017 at 2:54 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:
It is a variant of
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_pipermail_bioc-2Ddevel_2017-2DFebruary_010463.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=k6jN8WWwQDF4CDePzuCCjMH2qw1xQUbfc9cy6-FO48g=wuuIMKp7aAeTktf4VoEuYw4D22AFWWGGov1aDCNPloQ=
and requires re-installation of one or more of your Bioconductor
packages that depend directly or indirectly on S4Vectors; it's easy to
should have been 'not easy'
Thanks, Martin. I reinstalled both the "installme" and "mydep" packages
below using biocLite(installme), then when that didn't work, I also tried
biocLite(mydep$phyloseq). I guess a full Bioconductor reinstall would be a
heavy-handed but effective fix?
db = available.packages(repos=BiocInstaller::biocinstallRepos()[1])
revdeps = tools::package_dependencies("S4Vectors", db, recursive=TRUE,
reverse=TRUE)
mydep = tools::package_dependencies("phyloseq", db, recursive=TRUE)
installme = mydep$phyloseq[mydep$phyloseq %in% revdeps$S4Vectors]
mydep
$phyloseq
[1] "BiocGenerics" "ade4" "ape" "biomformat"
"Biostrings"
[6] "cluster" "data.table" "foreach" "ggplot2" "igraph"
[11] "methods" "multtest" "plyr" "reshape2" "scales"
[16] "vegan""Biobase" "utils""graphics" "stats"
[21] "parallel" "jsonlite" "Matrix" "rhdf5"
"S4Vectors"
[26] "IRanges" "XVector" "survival" "MASS" "stats4"
[31] "zlibbioc"
installme
[1] "Biostrings" "IRanges""XVector"
[[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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=k6jN8WWwQDF4CDePzuCCjMH2qw1xQUbfc9cy6-FO48g=_1qWPE04468_CKJGFZqI4MhpwJ_frDUjNpXyUjqwDRs=
--
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] Problem on malbec2 server
Hi Juan Pablo, We just updated R on malbec2 a couple of hours ago and kintr has not been re-installed yet. Please make sure that your package suggests knitr otherwise the Single Package Builder has no way to know that knitr needs to be installed before trying to run 'R CMD build' or 'R CMD check' on your package. Thanks, H. On 02/14/2017 01:01 PM, Romero, Juan Pablo wrote: Hi everyone, I did a minor update to the package I'm currently developing and the build report shows an error on malbec2 server: * checking for file EventPointer/DESCRIPTION ... OK * preparing EventPointer: * checking DESCRIPTION meta-information ... OK Error in loadVignetteBuilder(pkgdir, TRUE) : vignette builder 'knitr' not found Execution halted Could this be related with a problem in the server? A few hours ago I did a build and it completed without errors and warnings so, I doubt that the version bump (Updated a link on the package vignette) caused this problem. Thank you. Juan Pablo [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@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: [Rd] R 'base' returning 0 as sum of NAs
On 01/11/2017 02:33 AM, Alex Ivan Howard wrote: There is nothing to sum over, so it shouldn't actually be able to return a concrete numeric value? How much did you spend at the grocery store if you didn't buy anything? H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Changes S4Vectors etc.
Hi Leonard, mmh... I can't reproduce this and it doesn't show up on the build report either. But I got another strange error when I tried to *install* SGSeq: something about TxFeatures not being able to extend GenomicRanges because of incompatible type for the elementMetadata slot. I got rid of it by re-installing GenomicRanges from svn. I guess I had some stalled class definition somewhere in a cache. Looks like maybe you also have a stalled class definition somewhere in a cache for one of SGFeatureCounts's parent classes. Not sure which one though :-/ Maybe I forgot to bump a package version somewhere after I renamed characterORNULL -> character_OR_NULL? Re-installing S4Vectors, IRanges, GenomicRanges, and SummarizedExperiment directly from svn might help. Cheers, H. On 02/08/2017 04:18 PM, Leonard Goldstein wrote: Hi Hervé, It looks like there have been some changes in bioc-devel (S4Vectors etc.) that break the SGSeq package (see below). I'm not sure whether this is something that needs to be addressed in SGSeq or its dependencies. I'd be grateful for any pointers. Thanks for your help. Leonard -- example(makeSGFeatureCounts, "SGSeq") mkSGFC> sgfc <- makeSGFeatureCounts(sgf_pred, si, mkSGFC+ matrix(0L, length(sgf_pred), nrow(si))) Error in checkSlotAssignment(object, name, value) : assignment of an object of class "NULL" is not valid for slot 'NAMES' in an object of class "SGFeatureCounts"; is(value, "characterORNULL") is not TRUE sessionInfo() R Under development (unstable) (2017-02-06 r72129) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X El Capitan 10.11.6 locale: [1] C attached base packages: [1] stats4parallel stats graphics grDevices utils datasets [8] methods base other attached packages: [1] SGSeq_1.9.1SummarizedExperiment_1.5.5 [3] DelayedArray_0.1.4 Biobase_2.35.0 [5] Rsamtools_1.27.12 Biostrings_2.43.4 [7] XVector_0.15.2 GenomicRanges_1.27.22 [9] GenomeInfoDb_1.11.9IRanges_2.9.18 [11] S4Vectors_0.13.13 BiocGenerics_0.21.3 loaded via a namespace (and not attached): [1] igraph_1.0.1 Rcpp_0.12.9 AnnotationDbi_1.37.2 [4] magrittr_1.5 zlibbioc_1.21.0 GenomicAlignments_1.11.9 [7] BiocParallel_1.9.5 lattice_0.20-34 tools_3.4.0 [10] grid_3.4.0 DBI_0.5-1digest_0.6.12 [13] Matrix_1.2-8 GenomeInfoDbData_0.99.0 rtracklayer_1.35.5 [16] bitops_1.0-6 RUnit_0.4.31 biomaRt_2.31.4 [19] RCurl_1.95-4.8 memoise_1.0.0RSQLite_1.1-2 [22] compiler_3.4.0 GenomicFeatures_1.27.6 XML_3.98-1.5 [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@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] GenomeInfoDb::Seqinfo() failing with 404 error
Hi Raymond, This should be fixed now in GenomeInfoDb 1.10.3 (release) and 1.11.8 (devel). Both packages should become available via biocLite() in the next 24 hours or so. Thanks again for reporting the issue and for your patience. Cheers, H. On 02/01/2017 12:32 PM, Hervé Pagès wrote: Hi Raymond, On 02/01/2017 04:39 AM, Raymond Cavalcante wrote: Hello, I was wondering if any progress has been made on fixing this? I looked through recent commits for GenomeInfoDb, but there didn't seem to be anything related to this problem. Not yet. Please expect a couple more days before this is resolved. Thanks for your patience, H. Thanks, Raymond On Jan 25, 2017, at 23:01, Obenchain, Valerie <valerie.obench...@roswellpark.org> wrote: Thanks for the report. It looks like the directory structure has changed. I'll work on this tomorrow and will post back when it's fixed. Valerie On 01/25/2017 06:29 PM, Raymond Cavalcante wrote: Hello, I'm suddenly encountering errors with GenomeInfoDb::Seqinfo(): GenomeInfoDb::Seqinfo(genome='hg19') Error in file(file, "rt") : cannot open connection In addition: Warning message: In file(file, "rt") : URL 'https://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_01405.13.assembly.txt': status was '404 Not Found' I'm not sure how to fix this issue, as it seems to be more of an NCBI problem. Any help would be greatly appreciated. Thanks, Raymond Cavalcante ___ 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 -- 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] GenomeInfoDb::Seqinfo() failing with 404 error
Hi Raymond, On 02/01/2017 04:39 AM, Raymond Cavalcante wrote: Hello, I was wondering if any progress has been made on fixing this? I looked through recent commits for GenomeInfoDb, but there didn't seem to be anything related to this problem. Not yet. Please expect a couple more days before this is resolved. Thanks for your patience, H. Thanks, Raymond On Jan 25, 2017, at 23:01, Obenchain, Valerie <valerie.obench...@roswellpark.org> wrote: Thanks for the report. It looks like the directory structure has changed. I'll work on this tomorrow and will post back when it's fixed. Valerie On 01/25/2017 06:29 PM, Raymond Cavalcante wrote: Hello, I'm suddenly encountering errors with GenomeInfoDb::Seqinfo(): GenomeInfoDb::Seqinfo(genome='hg19') Error in file(file, "rt") : cannot open connection In addition: Warning message: In file(file, "rt") : URL 'https://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_01405.13.assembly.txt': status was '404 Not Found' I'm not sure how to fix this issue, as it seems to be more of an NCBI problem. Any help would be greatly appreciated. Thanks, Raymond Cavalcante ___ 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 -- 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] GenomicFeatures::makeTxDbFromGFF leads to a S4Vectors error
nal_tx_id options(width = 120) session_info() Session info --- setting value version R version 3.3.2 RC (2016-10-26 r71594) system x86_64, darwin13.4.0 ui X11 language (EN) collate en_US.UTF-8 tz America/New_York date 2017-01-30 Packages --- package * version date source AnnotationDbi* 1.36.1 2017-01-13 Bioconductor Biobase * 2.34.0 2016-10-18 Bioconductor BiocGenerics * 0.20.0 2016-10-18 Bioconductor BiocParallel 1.8.12016-10-30 Bioconductor biomaRt2.30.0 2016-10-18 Bioconductor Biostrings 2.42.1 2016-12-01 Bioconductor bitops 1.0-62013-08-17 cran (@1.0-6) colorout * 1.1-22016-10-19 Github (jalvesaq/colorout@6d84420) DBI0.5-12016-09-10 cran (@0.5-1) devtools * 1.12.0 2016-06-24 CRAN (R 3.3.0) digest 0.6.12 2017-01-27 CRAN (R 3.3.2) GenomeInfoDb * 1.10.2 2016-12-29 Bioconductor GenomicAlignments 1.10.0 2016-10-18 Bioconductor GenomicFeatures * 1.26.2 2016-12-17 Bioconductor GenomicRanges* 1.26.2 2017-01-02 Bioconductor IRanges * 2.8.12016-11-08 Bioconductor lattice0.20-34 2016-09-06 CRAN (R 3.3.2) Matrix 1.2-82017-01-20 CRAN (R 3.3.2) memoise1.0.02016-01-29 CRAN (R 3.3.0) Rcpp 0.12.9 2017-01-14 CRAN (R 3.3.2) RCurl 1.95-4.8 2016-03-01 cran (@1.95-4.) Rsamtools 1.26.1 2016-10-22 Bioconductor RSQLite1.1-22017-01-08 CRAN (R 3.3.2) rtracklayer1.34.1 2016-11-02 Bioconductor S4Vectors* 0.12.1 2016-12-01 Bioconductor SummarizedExperiment 1.4.02016-10-18 Bioconductor withr 1.0.22016-06-20 CRAN (R 3.3.0) XML3.98-1.5 2016-11-10 CRAN (R 3.3.2) XVector0.14.0 2016-10-18 Bioconductor zlibbioc 1.20.0 2016-10-18 Bioconductor ___ 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] readGAlignments Lacks strandMode
On 01/13/2017 12:36 PM, Hervé Pagès wrote:
Hi,
No ifelse() statement needed. Just use invertStrand() on your
GAlignments object to invert its strand.
strandMode is specific to paired-end reads and the supported modes
reflect what other software do with paired-end reads (e.g. TopHat,
Rsubread, etc..). These modes don't make sense for single-end reads.
Furthermore note that the mode only affects the way the strand() getter
for GAlignmentPairs objects combines the strands from the first and last
end to return a single value for each pair. It does NOT modify the
strand of each end:
library(GenomicAlignments)
bamfile <- system.file("extdata", "ex1.bam", package="Rsamtools")
## strandMode 1
galp <- readGAlignmentPairs(bamfile, strandMode=1)[c(1:3, 1572)]
as.character(strand(first(galp)))
# [1] "+" "+" "+" "-"
as.character(strand(last(galp)))
# [1] "-" "-" "-" "+"
as.character(strand(galp))
# [1] "+" "+" "+" "-"
## strandMode 2
galp <- readGAlignmentPairs(bamfile, strandMode=2)[c(1:3, 1572)]
as.character(strand(first(galp))) # same as with strandMode 1
# [1] "+" "+" "+" "-"
as.character(strand(last(galp))) # same as with strandMode 2
I meant . . . . . . . . . . . . . . # same as with strandMode 1
H.
# [1] "-" "-" "-" "+"
as.character(strand(galp))
# [1] "-" "-" "-" "+"
As you can see, in both case the strand of the first and last end is
what's in the BAM file.
I'm a big fan of consistency but generally speaking I don't think
consistency means that every import function should provide the exact
same interface, whatever the data to import is. That's why we have
different functions for different data in the 1st place.
H.
On 01/05/2017 11:00 PM, Dario Strbenac wrote:
Good day,
readGAlignmentPairs has strandMode but readGAlignments doesn't, which
means that single-end strand-specific RNA-seq that generates sequences
on the opposite strand to the gene needs a subsequent ifelse
statement. The API could be more consistent by providing a strandMode
option for readGAlignments and other similar functions in
GenomicAlignments.
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
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] GAlignments Sorting Causes C Stack Error
Hi,
No ordering was defined until now for GAlignments. Starting with
GAlignments 1.11.7, the elements of a GAlignments object 'x' are
ordered based on the order of the elements in 'granges(x)', that
is, by chromosome, then by strand, then by start, then by end.
Note that I chose a simple ordering definition for GAlignments objects
but it has the following important caveat: == does NOT look at the
cigar. That means that 2 elements in a GAlignments object are considered
equal even if their cigars are different:
> gal <- GAlignments(Rle(factor("chr1"), 2), c(5L, 5L), c("10M",
"5M2I5M"), Rle(strand("+"), 2))
> gal
GAlignments object with 2 alignments and 0 metadata columns:
seqnames strand cigarqwidth start end width
[1] chr1 + 10M10 51410
[2] chr1 + 5M2I5M12 51410
njunc
[1] 0
[2] 0
---
seqinfo: 1 sequence from an unspecified genome; no seqlengths
> gal[1] == gal
[1] TRUE TRUE
Another ordering definition would be an ordering that looks at
chromosome/strand/start/end/cigar instead of just
chromosome/strand/start/end (i.e. the cigar is used to break ties when
looking at
chromosome/strand/start/end only leads to a tie). That would address
the above caveat but it feels weird to use lexicographic ordering of
the cigars in order to break ties. So I'm kind of hesitant to do this.
Anyway now <=, <, ==, !=, pcompare(), order(), sort(), rank(), etc...
work.
Still no match(), selfmatch(), duplicated(), or unique() for GAlignments
objects. Note that these things should adhere to the same notion of
equality as == so they would also ignore the cigar right now if we
wanted to have them. Maybe that's another argument in favor of an
ordering based on chromosome/strand/start/end/cigar.
H.
On 01/08/2017 05:00 PM, Dario Strbenac wrote:
Good day,
When sort is used on a GAlignments object, a stack error is shown, no matter
how small the object is.
testAlignments
GAlignments object with 3 alignments and 0 metadata columns:
seqnames strand cigarqwidth
start end width njunc
700666F:126:C8768ANXX:3:2204:3175:99484chr14 + 71S27M98
18386040 1838606627 0
700666F:126:C8768ANXX:1:1107:8115:31928chr14 + 40S60M 100
18915005 1891506460 0
700666F:126:C8768ANXX:1:2206:7564:34686chr14 + 40S50M90
18915005 1891505450 0
---
seqinfo: 23 sequences from an unspecified genome
sort(testAlignments)
Error: C stack usage 7970544 is too close to the limit
I use up-to-date packages.
sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)
locale:
[1] LC_CTYPE=C.UTF-8 LC_NUMERIC=C LC_TIME=C.UTF-8
LC_COLLATE=C.UTF-8 LC_MONETARY=C.UTF-8
[6] LC_MESSAGES=C.UTF-8LC_PAPER=C.UTF-8 LC_NAME=C
LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=C.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats4parallel stats graphics grDevices utils datasets
methods base
other attached packages:
[1] GenomicAlignments_1.10.0 Rsamtools_1.26.1 Biostrings_2.42.1
XVector_0.14.0
[5] SummarizedExperiment_1.4.0 Biobase_2.34.0 GenomicRanges_1.26.2
GenomeInfoDb_1.10.1
[9] IRanges_2.8.1 S4Vectors_0.12.1 BiocGenerics_0.20.0
loaded via a namespace (and not attached):
[1] lattice_0.20-34bitops_1.0-6 grid_3.3.2 zlibbioc_1.20.0
Matrix_1.2-7.1 BiocParallel_1.8.1
[7] tools_3.3.2
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
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] IRanges findOverlaps and queryHits
A couple more things about this: The Hits class is defined in the S4Vectors package. The changes to the internals of the class happened in BioC 3.3, almost 1 year ago. The NEWS file in S4Vectors has an entry under "CHANGES IN VERSION 0.10.0" that describes these changes: o Many changes to the Hits class: - Replace the old Hits class (where the hits had to be sorted by query) with the SortedByQueryHits class. - A new Hits class where the hits can be in any order is re-introduced as the parent of the SortedByQueryHits class. - The Hits() constructor gets the new 'sort.by.query' argument that is FALSE by default. When 'sort.by.query' is set to TRUE, the constructor returns a SortedByQueryHits instance instead of a Hits instance. - Bidirectional coercion is supported between Hits and SortedByQueryHits. When going from Hits to SortedByQueryHits, the hits are sorted by query. - Add "c" method for Hits objects. - Rename Hits slots: queryHits -> from subjectHits -> to queryLength -> nLnode (nb of left nodes) subjectLength -> nRnode (nb of right nodes) - Add updateObject() method to update serialized Hits objects from old (queryHits/subjectHits) to new (from/to) internal representation. - The "show" method for Hits objects now labels columns with from/to by default and switches to queryHits/subjectHits labels only when the object is a SortedByQueryHits object. - New accessors are provided that match the new slot names: from(), to(), nLnode(), nRnode(). The old accessors (queryHits(), subjectHits(), queryLength(), and subjectLength()) are just aliases for the new accessors. Also countQueryHits() and countSubjectHits() are now aliases for new countLnodeHits() and countRnodeHits(). Hope this helps, H. On 12/20/2016 12:43 PM, Michael Lawrence wrote: Hi Nathan, Direct slot access is strongly discouraged, for this very reason. Please stick to using the accessor. And yes, Hits was redefined in terms of a graph model last devel cycle. Michael On Tue, Dec 20, 2016 at 12:16 PM, Nathan Sheffield <nat...@code.databio.org> wrote: Did the findOverlaps return object get a @queryHits slot removed recently? I recently got this error running some of my code: Error: no slot of name "queryHits" for this object of class "SortedByQueryHits" My workflow is basically, fo = findOverlaps(...) fo@queryHits Using queryHits(fo) works, and using fo@queryHits to access it via slot has always worked for me as well -- until this time. I couldn't find anything in a changelog describing any changes into IRanges slots. Thought someone here might be able to shed some light on that for me... does anyone know what happened to the ability to access with @queryHits? Some relevant sessionInfo(): sessionInfo() R version 3.3.0 (2016-05-03) Platform: x86_64-pc-linux-gnu (64-bit) Running under: CentOS release 6.8 (Final) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] parallel stats4stats graphics grDevices utils datasets methods base other attached packages: [1] RGenomeUtils_0.01 BSgenome.Hsapiens.UCSC.hg19.masked_1.3.99 BSgenome.Hsapiens.UCSC.hg19_1.4.0 [4] BSgenome_1.42.0 rtracklayer_1.34.1 Biostrings_2.42.0 [7] XVector_0.14.0 LOLA_1.4.0 GenomicRanges_1.26.1 [10] GenomeInfoDb_1.10.1 IRanges_2.8.1 S4Vectors_0.12.0 [13] BiocGenerics_0.20.0 ggplot2_2.1.0 simpleCache_0.0.1 [16] extrafont_0.17 data.table_1.9.6 devtools_1.12.0 [19] project.init_0.0.1 loaded via a namespace (and not attached): [1] Rcpp_0.12.7plyr_1.8.4 bitops_1.0-6 tools_3.3.0 [5] zlibbioc_1.20.0testthat_1.0.2 digest_0.6.10 lattice_0.20-33 [9] memoise_1.0.0 gtable_0.2.0 Matrix_1.2-6 yaml_2.1.13 [13] Rttf2pt1_1.3.4 withr_1.0.2 stringr_1.1.0 roxygen2_5.0.1 [17] grid_3.3.0 Biobase_2.34.0 R6_2.2.0 BiocParallel_1.8.1 [21] XML_3.98-1.4 reshape2_1.4.2 extrafontdb_1.0 magrittr_1.5 [25] GenomicAlignments_1.10.0 Rsamtools_1.26.1 scales_0.4.1 SummarizedExperiment_1.4.0 [29] colorspace_1.3-0 stringi_1.1.2 RCurl_1.95-4.8 munsell_0.4.3 [33] chron_2.3-47 crayon_1.3.2 -Nathan ___ 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 -- Hervé Pagès Prog
Re: [Rd] syntax difference clusterExport in parallel and snow
On 12/13/2016 09:33 AM, Prof Brian Ripley wrote:
On 13/12/2016 17:05, Paul Johnson wrote:
We got some errors and eventually figured out that
parallel::clusterExport second argument is "varlist" while in
snow::clusterExport it is "list".
The user had loaded parallel first, but did something else which
inadvertently loaded snow, then clusterExport failed because we had
"varlist" and not "list".
Are these different on purpose?
Yes.
('list' is an unhelpful name for an argument that is not a list.)
Yes 'list' is a misleading name for a character vector. OTOH I guess
snow::clusterExport() was just following the lead of base::save() and
base::remove() on this.
I don't see 'varlist' as being much less confusing though: it still
suggests that the thing is a list and parallel::clusterExport() is
now inconsistent with snow::clusterExport(). So it doesn't really
address the 1st problem and introduces a new one. Sounds like using
a plural form instead of the "list" prefix would be less confusing
e.g. 'vars', 'varnames', 'objnames' or something like that.
H.
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Stackoverflow Bounty: pkgdown R package build_site function causes dependent packages unable to be loaded
Hi Marcin, You posted this 7 months ago, it has been viewed 100 times, and nobody commented or tried to answer. I don't know if a bounty is going to help though. To me, a much more effective way to get people help you is by providing enough information so that people can easily reproduce the problem. Honestly, right now, I don't see how people could easily reproduce this. I guess most people have never heard of pkgdown, or don't know where to find it, or don't know how to install it, or don't know which version you used. They don't know which version of R or RTCGA you used either, or what you did before calling pkgdown::build_site(), or what platform you are on. So if you manage to provide code that people can just copy/paste in a fresh session in order to see the problem, that will greatly help. Your code should show how to install pkgdown (don't assume people have it installed already). After your code has loaded all the required packages, show the output of your sessionInfo(). This is general advice for any bug report. I don't know if you found a bug but it could be (hard to tell without being able to reproduce). Also did you try to contact the pkgdown folks? This is probably a more efficient way to report a bug than using stackoverflow. Cheers, H. On 12/15/2016 07:21 AM, Marcin Kosiński wrote: I am trying to build a pkgdown documentation for Bioconductor package. I have wrote about it on the stackoverflow http://stackoverflow.com/questions/36874972/pkgdown-r-package-build-site-function-causes-dependent-packages-unable-to-be-loa but the question didn't receivew the expected attention. I have started a bounty, looking to give 50 points of my reputation for the best answer. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@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] Quick question about landing page
Hi Boyu, sparseDOSSA was added yesterday to svn and to the build system: hpages@latitude:~/svn/bioconductor/Rpacks$ svn log bioc_3.5.manifest -r 125047 r125047 | mtmor...@fhcrc.org | 2016-12-12 14:17:22 -0800 (Mon, 12 Dec 2016) | 2 lines Adding chimeraviz, RnaSeqGeneEdgeRQL, gcapc, BUMHMM, sparseDOSSA, clusterSeq, ramwas This was at 22h17 UTC. It was actually about 2 min after the builds start. See the Snapshot Date at the top of today's build report: https://bioconductor.org/checkResults/3.5/bioc-LATEST/ That's why it's not part of the build report today. It will show up in tomorrow's report if everything goes as expected. Then the landing page will get automatically generated. Cheers, H. On 12/13/2016 01:50 PM, Boyu Ren wrote: Dear Bioconductor Team, I received the email yesterday that confirmed my package sparseDOSSA is added to Bioconductor. However, when I tried to check the landing page, the page cannot be found and also there is no building history for sparseDOSSA in the devel brand build report. I am just wondering if I just need to wait a bit more or there is some issues with the packaging building. Thank you so much for your help! Best regards, Boyu ___ 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] Advice on build error related to webshot, and possibly related to rmarkdown?
Let's keep the discussion on the mailing list. On 12/07/2016 10:58 PM, Stian Lågstad wrote: I tried doing that now and got another error: "cannot open the connection". I don't know how to investigate that further. Link to new build report: http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161208015500.html At least the webshot issue is gone. Yes adding it to the Suggests field is of course a dirty hack. The hope being that it would help you quickly work around the build failure on oaxaca. Do you think the issue could be caused by the warning below? Since I'm only seeing that on oaxaca. "Warning in engine$weave(file, quiet = quiet, encoding = enc) : Pandoc (>= 1.12.3) and/or pandoc-citeproc not available. Falling back to R Markdown v1." Both pandoc and pandoc-citeproc are on oaxaca: oaxaca:~ biocbuild$ which pandoc /usr/local/bin/pandoc oaxaca:~ biocbuild$ which pandoc-citeproc /usr/local/bin/pandoc-citeproc And pandoc version is >= 1.12.3: oaxaca:~ biocbuild$ pandoc -v | head -n 2 pandoc 1.17.0.2 Compiled with texmath 0.8.5, highlighting-kate 0.6.2. Also we don't see that warning on the daily builds even though many packages use pandoc/pandoc-citeproc for their vignettes. So again, I'm not sure what's going on, sorry. Likely a problem on our side. I suggest you ignore this build error on oaxaca for now. Cheers, H. Thank you. On Thu, Dec 8, 2016 at 1:07 AM, Hervé Pagès <hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>> wrote: Not clear to me what's going on, I'm not a knitr/rmarkdown expert. What I see is that knitr suggests webshot probably because it needs it in some situations. That must be a rare situation though because webshot is not installed on our build machines, which means that none of the 1298 software packages currently in BioC devel needs it. So I'm not sure why it would need it for building your vignette, and why it would need it only on oaxaca. Anyway maybe it would help to add webshot to your Suggests field. That will trigger installation of webshot by the SPB before it tries to build/check your package. Don't forget to bump again the package version in order to trigger a new build by the SPB. H. On 12/07/2016 12:31 PM, Stian Lågstad wrote: Thank you both. Could you also advice me on the error I'm receiving on oaxaca? "there is no package called 'webshot'" New build report: http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161207152203.html <http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161207152203.html> <http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161207152203.html <http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161207152203.html>> On Wed, Dec 7, 2016 at 7:42 PM, Hervé Pagès <hpa...@fredhutch.org <mailto:hpa...@fredhutch.org> <mailto:hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>>> wrote: Hi Stian, The build machines used by the SPB are the same as the machines used for the daily builds and they already have the latest BiocStyle installed (BiocStyle 2.3.23). You can see this by going on the daily build report for devel and clicking on any of the link in the "Installed pkgs" column in the top table: https://bioconductor.org/checkResults/3.5/bioc-LATEST/ <https://bioconductor.org/checkResults/3.5/bioc-LATEST/> <https://bioconductor.org/checkResults/3.5/bioc-LATEST/ <https://bioconductor.org/checkResults/3.5/bioc-LATEST/>> However, the SPB report for your package is from Nov 30 so it could be that it predates the fix in BiocStyle. You can trigger a new build of your package by just bumping its version on github. Hope this helps, H. On 12/07/2016 07:17 AM, Leonardo Collado Torres wrote: Hi Stian, Install BiocStyle 2.3.20 or newer and that error will go away. See https://github.com/Bioconductor/BiocStyle/issues/20 <https://github.com/Bioconductor/BiocStyle/issues/20> <https://github.com/Bioconductor/BiocStyle/issues/20 <https://github.com/Bioconductor/BiocStyle/issues/20>> for details. Best, Leo On Wed, Dec 7, 2016 at 7:44 AM, Stian Lågstad <stianlags...@gmail.com <mailto:stianlags...@gmail.com> <mailto:stianlags...@gmail.com <mailto:stianlags...@gmail.com>>> wrote: Hi, Could someone please advice me on the errors I'm getting
Re: [Bioc-devel] Advice on build error related to webshot, and possibly related to rmarkdown?
Not clear to me what's going on, I'm not a knitr/rmarkdown expert. What I see is that knitr suggests webshot probably because it needs it in some situations. That must be a rare situation though because webshot is not installed on our build machines, which means that none of the 1298 software packages currently in BioC devel needs it. So I'm not sure why it would need it for building your vignette, and why it would need it only on oaxaca. Anyway maybe it would help to add webshot to your Suggests field. That will trigger installation of webshot by the SPB before it tries to build/check your package. Don't forget to bump again the package version in order to trigger a new build by the SPB. H. On 12/07/2016 12:31 PM, Stian Lågstad wrote: Thank you both. Could you also advice me on the error I'm receiving on oaxaca? "there is no package called 'webshot'" New build report: http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161207152203.html <http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161207152203.html> On Wed, Dec 7, 2016 at 7:42 PM, Hervé Pagès <hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>> wrote: Hi Stian, The build machines used by the SPB are the same as the machines used for the daily builds and they already have the latest BiocStyle installed (BiocStyle 2.3.23). You can see this by going on the daily build report for devel and clicking on any of the link in the "Installed pkgs" column in the top table: https://bioconductor.org/checkResults/3.5/bioc-LATEST/ <https://bioconductor.org/checkResults/3.5/bioc-LATEST/> However, the SPB report for your package is from Nov 30 so it could be that it predates the fix in BiocStyle. You can trigger a new build of your package by just bumping its version on github. Hope this helps, H. On 12/07/2016 07:17 AM, Leonardo Collado Torres wrote: Hi Stian, Install BiocStyle 2.3.20 or newer and that error will go away. See https://github.com/Bioconductor/BiocStyle/issues/20 <https://github.com/Bioconductor/BiocStyle/issues/20> for details. Best, Leo On Wed, Dec 7, 2016 at 7:44 AM, Stian Lågstad <stianlags...@gmail.com <mailto:stianlags...@gmail.com>> wrote: Hi, Could someone please advice me on the errors I'm getting building my package? I'm unable to reproduce them locally. Link to build report: http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161130173413.html <http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161130173413.html> Link to bioconductor submission issue: https://github.com/Bioconductor/Contributions/issues/206 <https://github.com/Bioconductor/Contributions/issues/206> I'm getting an error on creating my vignette: `argumemt is not a character vector` I also get this: `there is no package called 'webshot'` I believe these could be related to this warning: `Warning in engine$weave(file, quiet = quiet, encoding = enc) : Pandoc (>= 1.12.3) and/or pandoc-citeproc not available. Falling back to R Markdown v1.` I use rmarkdown_1.2 locally without problems. Can someone here assist me? Thank you. -- Stian Lågstad +47 41 80 80 25 <tel:%2B47%2041%2080%2080%2025> [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel <https://stat.ethz.ch/mailman/listinfo/bioc-devel> ___ Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel <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 <mailto:hpa...@fredhutch.org> Phone: (206) 667-5791 <tel:%28206%29%20667-5791> Fax:(206) 667-1319 <tel:%28206%29%20667-1319> -- Stian Lågstad +47 41 80 80 25 -- 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] Advice on build error related to webshot, and possibly related to rmarkdown?
Hi Stian, The build machines used by the SPB are the same as the machines used for the daily builds and they already have the latest BiocStyle installed (BiocStyle 2.3.23). You can see this by going on the daily build report for devel and clicking on any of the link in the "Installed pkgs" column in the top table: https://bioconductor.org/checkResults/3.5/bioc-LATEST/ However, the SPB report for your package is from Nov 30 so it could be that it predates the fix in BiocStyle. You can trigger a new build of your package by just bumping its version on github. Hope this helps, H. On 12/07/2016 07:17 AM, Leonardo Collado Torres wrote: Hi Stian, Install BiocStyle 2.3.20 or newer and that error will go away. See https://github.com/Bioconductor/BiocStyle/issues/20 for details. Best, Leo On Wed, Dec 7, 2016 at 7:44 AM, Stian Lågstad <stianlags...@gmail.com> wrote: Hi, Could someone please advice me on the errors I'm getting building my package? I'm unable to reproduce them locally. Link to build report: http://bioconductor.org/spb_reports/chimeraviz_buildreport_20161130173413.html Link to bioconductor submission issue: https://github.com/Bioconductor/Contributions/issues/206 I'm getting an error on creating my vignette: `argumemt is not a character vector` I also get this: `there is no package called 'webshot'` I believe these could be related to this warning: `Warning in engine$weave(file, quiet = quiet, encoding = enc) : Pandoc (>= 1.12.3) and/or pandoc-citeproc not available. Falling back to R Markdown v1.` I use rmarkdown_1.2 locally without problems. Can someone here assist me? Thank you. -- Stian Lågstad +47 41 80 80 25 [[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 -- 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] download stats
Hi Antonio,
Because of some ssh key issues the script that generates the stats was
not able to retrieve the HTTP log files for the last 2-3 weeks. The
problem is fixed now and the stats for November look really good :-)
https://bioconductor.org/packages/stats/bioc/
Cheers,
H.
On 11/29/2016 02:21 PM, Hervé Pagès wrote:
Hi Antonio,
Yes the stats for November look low compared to the previous months.
Looks like we'll hardly hit the 3 distinct IPs for the whole
Bioconductor software repository. Could be genuine though. I'll check
what's going on.
Thanks for bringing this to our attention,
H.
On 11/29/2016 01:51 PM, Antonio Colaprico wrote:
Dear all,
Dear Hervè,
I noted something strange with the download stats in November if you
consider even default Bioconductor packages (*BiocInstaller* (26209)
<http://bioconductor.org/packages/stats/bioc/BiocInstaller/>,
*BiocGenerics* (18864)
<http://bioconductor.org/packages/stats/bioc/BiocGenerics/>, *IRanges*
(18129)
<http://bioconductor.org/packages/stats/bioc/IRanges/> etc
they are showing about 50% of the download stats compared to other
months of the year.
I know my post is similar to one posted by Kasper indeed I had the same
sensation maybe because there is Christmas atmosphere around.
Therefore if I'm not mistaken or I lost some news about the stats how
Kasper did know already about this issue 3 weeks ago? ;-)
@Hervè please when you have time can you check them?
Thank you in advance.
Best,
Antonio
2016-11-08 19:04 GMT+01:00 Kasper Daniel Hansen
<kasperdanielhan...@gmail.com <mailto:kasperdanielhan...@gmail.com>>:
This is a bit embarrassing. Somehow I was convinced it was
December. All
looks fine.("... you have gained a level in Distracted
Professorship").
Kasper
On Tue, Nov 8, 2016 at 11:50 AM, Hervé Pagès <hpa...@fredhutch.org
<mailto:hpa...@fredhutch.org>> wrote:
> Hi Kasper,
>
> The download stats just got updated:
>
> http://bioconductor.org/packages/stats/
<http://bioconductor.org/packages/stats/>
>
> They are updated twice a week, on Tuesday and Friday between 8
> and 9 AM PST. Note that because of how the download log files are
> generated and propagated to the machine where the stats are
computed,
> and because of the time it takes to generate the stats reports for
> all the packages, the current stats don't take into account the
> downloads that happened during the last 24 hours (more or less).
>
> Cheers,
> H.
>
>
> On 11/08/2016 07:50 AM, Kasper Daniel Hansen wrote:
>
>> It was pointed out to me that the (sub) heading on the page tells
me that
>> the script for counting downloads was last run Nov 4th,
explaining the
>> discrepancy.
>>
>> On Tue, Nov 8, 2016 at 9:24 AM, Kasper Daniel Hansen <
>> kasperdanielhan...@gmail.com
<mailto:kasperdanielhan...@gmail.com>> wrote:
>>
>> Is there something wrong with the download stats in November.
All the
>>> packages I look at have lost about 85-90% compared to other
months of the
>>> year:
>>> http://bioconductor.org/packages/stats/bioc/GenomicRanges/
<http://bioconductor.org/packages/stats/bioc/GenomicRanges/>
>>>
>>> Best,
>>> Kasper
>>>
>>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org>
mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
<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 <mailto:hpa...@fredhutch.org>
> Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
> Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
>
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing
list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
<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: [Rd] unlist strips date class
On 12/05/2016 01:05 AM, peter dalgaard wrote: On 02 Dec 2016, at 23:13 , Hervé Pagès <hpa...@fredhutch.org> wrote: More generally one might reasonably expect 'unlist(x)' to be equivalent to 'do.call(c, x)' on a list 'x' where all the list elements are atomic vectors: Well, both are generic, and e.g. there is no "Date" method for unlist(), but there is for c(). It is not clear that the two should be kept in lockstep and there is certainly no mechanism to enforce that. If unlist() was based on c(), or c() was based on unlist(), or unlist() and c() were sharing more code internally, then they would naturally be kept in lockstep and you wouldn't need any mechanism to enforce that. Note that the arguments of the default S3 method for c() are: c(..., recursive = FALSE, use.names = TRUE) i.e. exactly the same as unlist() (except for the default value). This suggests that implementing one on top of the other is kind of a natural thing to do. H. -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Dependency update propagation (rcdk on morelia)
Hi Nan, Zach, Val, On 12/05/2016 01:45 PM, Obenchain, Valerie wrote: Hi, We need to make several updates to the mac machines. These are the last 2 builders that still need to move from the Hutch to RPCI. Because they are still at the Hutch, access to them is limited. We will get to these updates as soon as we can. Yes, we'll do this soon. However please note that rcdk also fails to pass check on the Mac builder on CRAN because the builder doesn't have Java >= 7 either: https://www.r-project.org/nosvn/R.check/r-release-osx-x86_64-mavericks/rcdk-00check.html As a consequence the version of the Mac binary for rcdk is lagging behind the source package: http://cran.fhcrc.org/web/packages/rcdk/index.html Source package version: 3.3.8 Mac binary version: 3.3.2 Most of the BioC users that are on Mac are not set to install packages from source and need to be able to install binary packages. So even if we update Java on our Mac builders, most Mac users still won't be able to install the latest rcdk and Rcpi. Cheers, H. Valerie On 12/05/2016 01:27 PM, Dan Tenenbaum wrote: Actually it looks like the version of java installed on morelia is 1.6. So it appears that 1.7 (or higher) needs to be installed. Dan - Original Message - From: "Zach Charlop-Powers" <zach.charlop.pow...@gmail.com> To: "Nan Xiao" <road2s...@gmail.com> Cc: "bioc-devel" <bioc-devel@r-project.org> Sent: Monday, December 5, 2016 1:02:52 PM Subject: Re: [Bioc-devel] Dependency update propagation (rcdk on morelia) Hi Nan, rCDK 3.3.6 requires Java8 and will throw error if the Java environment is incorrect. BioC Build only has Java7 hence the error. The new version of rCDK requires Java7. Once rcdk 3.3.8 makes it onto the BioC builds (its on CRAN), these errors should clear up. Please keep me posted if they don't. zach cp On Mon, Dec 5, 2016 at 3:43 PM, Nan Xiao <road2s...@gmail.com> wrote: Hey guys, - it seems this problem is also affecting the other two Bioc packages depending on rcdk, i.e. RMassBank and rcellminer (release + devel). Any ideas why? Thanks, -Nan On Fri, Dec 2, 2016 at 2:29 PM, Nan Xiao <road2s...@gmail.com> wrote: Hi Bioc, - the Rcpi package depends on rcdk, and the rcdk package was updated last week from 3.3.6 to 3.3.8 on CRAN thanks to Zach's (cc'd) work, which removed the Java > 1.8 requirement (previously discussed in https://stat.ethz.ch/pipermail/bioc-devel/2016-October/009881.html ). I've updated the Rcpi package and specified the rcdk version to be >= 3.3.8, while the most recent Mac build gives the error: ( http://bioconductor.org/checkResults/release/bioc-LATEST/ Rcpi/morelia-buildsrc.html ) namespace 'rcdk' 3.3.6 is being loaded, but >= 3.3.8 is required. So it seems morelia is still using rcdk 3.3.6, while this >= 3.3.8 version requirement is fulfilled by Linux and Windows builds (if I understand correctly). Is there anything I could do to solve this issue? Thanks a lot, -Nan -- http://nanx.me -- http://nanx.me [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. -- 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] biconductor build error and warning
Hi Bhakti,
Please see my post from October here
https://stat.ethz.ch/pipermail/bioc-devel/2016-October/009997.html
for why Rmpfr (and thus HH) fails to install on oaxaca.
We're still hoping that the CRAN folks will start providing Mac
binary packages for r-devel soon.
In the meantime please ignore that error on oaxaca.
Cheers,
H.
On 12/04/2016 04:37 PM, Dwivedi, Bhakti wrote:
Thank you so much Dan!!
From: Dan Tenenbaum <dtene...@fredhutch.org>
Sent: Sunday, December 4, 2016 1:41:59 PM
To: Dwivedi, Bhakti
Cc: bioc-devel
Subject: Re: [Bioc-devel] biconductor build error and warning
- Original Message -
From: "Bhakti Dwivedi" <bhakti.dwiv...@emory.edu>
To: "bioc-devel" <bioc-devel@r-project.org>
Sent: Sunday, December 4, 2016 6:29:22 AM
Subject: [Bioc-devel] biconductor build error and warning
Could anyone please help me with the below two bioconductor build error and
warnings?
I am getting the below ERROR Bioconductor build msg on Mac OS X
(https://github.com/Bioconductor/Contributions/issues/202)
installing the package to build vignettes
ERROR: dependency HH is not available for package GISPA
This is because HH depends on Rmpfr which has some system dependencies that are
not yet installed on that machine; I'm sure a member of the Bioconductor team
will get to this soon.
removing
/private/var/folders/_l/1jpyvgt17qzgj1yz7f0z4np8gr/T/Rtmp939MXS/Rinst16ad7608b810a/GISPA
ERROR: package installation failed
I do not get this ERROR messages when I build, check or install on my Mac OS X.
Additionally, I am getting the below warning message:
WARNING: Update R version dependency from 3.3.2 to 3.4.
This is because your DESCRIPTION file says
Depends: R (>= 3.3.2)
But since you are submitting to the devel branch of Bioconductor, which will
only work with R-3.4, you should update this to
Depends: R (>= 3.4)
Dan
Appreciate your help and any suggestions to fix them.
Thank you.
This e-mail message (including any attachments) is for...{{dropped:22}}
___
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: [Rd] unlist strips date class
Hi,
On 12/02/2016 10:45 AM, Kenny Bell wrote:
Is this a bug?
unlist(list(as.Date("2015-01-01")))
[1] 16436
Good question.
More generally one might reasonably expect 'unlist(x)' to be equivalent
to 'do.call(c, x)' on a list 'x' where all the list elements are atomic
vectors:
x <- list(1:3, letters[1:2])
unlist(x)
# [1] "1" "2" "3" "a" "b"
do.call(c, x)
# [1] "1" "2" "3" "a" "b"
However, if the list contains dates:
x <- list(as.Date("2015-01-01") + 0:2, as.Date("2016-12-02"))
unlist(x)
# [1] 16436 16437 16438 17137
do.call(c, x)
# [1] "2015-01-01" "2015-01-02" "2015-01-03" "2016-12-02"
then 'unlist(x)' drops the attributes and 'do.call(c, x)' does not.
And if the list contains factors:
x <- list(factor("Z"), factor(c("a", "Z", "b")))
unlist(x)
# [1] Z a Z b
# Levels: Z a b
do.call(c, x)
# [1] 1 1 3 2
then it's the other way around. Also note that the fact that the first
2 numbers in the result of 'do.call(c, x)' are the same is
confusing/misleading. Hard to see how this result could be useful
to anybody.
These inconsistencies might well be documented but hopefully they can
be addressed.
Cheers,
H.
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] package vignette error : external data can't be captured when compiling package vignette
nette Dear Dan : Really appreciated for your quick respond. Instead, I am using R CMD check on my packages, I have an error. Here is whole session detail : Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. C:\Users\jvrat>cd C:\Program Files\R\R-devel\bin\x64 C:\Program Files\R\R-devel\bin\x64>R CMD INSTALL "C:\Users\jvrat\Documents\MSPC" * installing to library 'C:/Users/jvrat/Documents/R/win-library/3.4' * installing *source* package 'MSPC' ... ** R ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** installing vignettes ** testing if installed package can be loaded * DONE (MSPC) C:\Program Files\R\R-devel\bin\x64>R CMD check "C:\Users\jvrat\Documents\MSPC" Warning in dir.create(pkgoutdir, mode = "0755") : cannot create dir 'C:\Program Files\R\R-devel\bin\x64\MSPC.Rcheck', reason 'Permission denied' ERROR: cannot create check dir 'C:/Program Files/R/R-devel/bin/x64/MSPC.Rcheck' You need to run R CMD check in a directory where you have write permissions. C:\Program Files\R\R-devel\bin\x64>R CMD build "C:\Users\jvrat\Documents\MSPC" * checking for file 'C:\Users\jvrat\Documents\MSPC/DESCRIPTION' ... OK * preparing 'MSPC': * checking DESCRIPTION meta-information ... OK * installing the package to build vignettes * creating vignettes ...Warning: running command '"C:/PROGRA~1/R/R-devel/bin/x64/Rscript" --vanilla --default-packages= -e "tools::buildVignettes(dir = '.', tangle = TRUE)"' had status 1 ERROR Warning in engine$weave(file, quiet = quiet, encoding = enc) : Pandoc (>= 1.12.3) and/or pandoc-citeproc not available. Falling back to R Markdown v1. Quitting from lines 62-66 (vignette.Rmd) Error: processing vignette 'vignette.Rmd' failed with diagnostics: object 'inputData' not found Execution halted Line 61 of the vignette (as it is in Github; it's apparently different on yur machine based on the error message) is: total.ERs <- denoise_ERs(peakGRs = inputData, tau.w = 1.0E-04, .fileName = "noiseER", outDir = "", verbose = FALSE) As you can see, the peakGRs argument is set to inputData, but inputData is not defined anywhere. Dan C:\Program Files\R\R-devel\bin\x64> How can I fix this R CMD check error ? Instead people in stackoverflow remind me that using devtools packages is not stable some times, so I go for old fashion : use CMD. Plus, still my external data can't available for vignette data, and vignette compilation is failed again. I used system.file() to do this, but not working. Any idea please ? How can I overcome this problem? Thanks a lot to Bioconductor project team. Best regards : Jurat On Fri, Dec 2, 2016 at 5:20 PM, Dan Tenenbaum <dtene...@fredhutch.org> wrote: If your package is in github at https://github.com/julaiti/MSPC , it looks like there is no inst or extdata folder in that repository. Maybe it has not yet been added/committed/pushed to git? Note that everything _under_ inst gets installed when you install the package, but the inst directory itself goes away. If in your package source you have the following structure: inst/extdata/ inst/foo.txt In the installed package you end up with: extdata/ foo.txt HTH Dan - Original Message - From: "Jurat Shayidin" <juratb...@gmail.com> To: "Hervé Pagès" <hpa...@fredhutch.org>, "bioc-devel" < bioc-devel@r-project.org> Sent: Friday, December 2, 2016 5:36:28 AM Subject: Re: [Bioc-devel] package vignette error : external data can't be captured when compiling package vignette Dear Hervé : Thanks again for your response on my issue. I've read your message very carefully and did all you suggested to me, still can't fix the vignette compilation error. I have developed my package on windows machine under devel version of R and Bioc, all unit test works fine to me. I don't understand why inst/ directory was not created when I build and install my packages, external data can't be read during vignette compilation. However, my objective is, to build my package vignette with no error in the first place, then continue to edit the context until getting final version of vignette file. When I install packages using devtools::install(), I got this : devtools::install() Installing MSPC "C:/PROGRA~1/R/R-devel/bin/x64/R" \ --no-site-file --no-environ --no-save \ --no-restore --quiet CMD INSTALL \ "C:/Users/jvrat/Documents/MSPC" \ --library="C:/Users/jvrat/Documents/R/win-library/3.4" \ --install-tests * installing *source* package 'MSPC' ... ** R ** tests ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** installing vignettes ** testing if installed package can be loaded * DONE (MSPC) Reloading installed MSPC I believe doing this is right in vign
