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

[Jason.Ross]

Thanks Hervé and Henrik, I have also been experiencing the same issues. I 
innocently typed "sudo apt-get upgrade" in Ubuntu and this broke my 
Bioconductor install.

Regards,
Jason

-Original Message-
From: Bioc-devel [mailto:bioc-devel-boun...@r-project.org] On Behalf Of Henrik 
Bengtsson
Sent: Friday, 10 March 2017 5:09 PM
To: Hervé Pagès 
Cc: bioC-devel 
Subject: 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

Thanks Hervé.  I can confirm that reinstalling packages from R 3.3.2 to R 3.3.3 
solved the problem:

https://github.com/HenrikBengtsson/globals/commit/f9ff3a092d1712258aab2d01277665abec7dfa32

/Henrik

On Thu, Mar 9, 2017 at 5:52 PM, Hervé Pagès  wrote:
> 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] 

[R-pkg-devel] Extending an S3 method, but putting the package in Suggests?

[David Hugh-Jones]

Hi,

Cross-posted from SO:
http://stackoverflow.com/questions/42776058/extending-an-s3-generic-from-an-optional-package

I have a package which provides an as.FlexTable method for its objects,
extending the S3 generic from the ReporteRs package. So, my NAMESPACE file,
generated by roxygen, has lines:

importFrom(ReporteRs,as.FlexTable)
...
S3method(as.FlexTable,huxtable)
...
export(as.FlexTable)

I don't much want to put ReporteRs in Imports: in the DESCRIPTION file,
because it involves a big external dependency on Java. But, when I put it
into Suggests:, R CMD check gives me errors like "Namespace dependency not
required".

Is there anyway I can extend the generic without making a hard dependency?

Cheers,
David

[[alternative HTML version deleted]]

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

[Bioc-devel] devel builds: oaxaca phase out

[Obenchain, Valerie]

oaxaca has been removed from the build report and toluca2 is now the
official Mac devel builder. Herve has applied all system updates to
toluca2 and is smoothing out the final kinks. Lori is finalizing the
transition of the Single Package Builder from oaxaca to toluca2 and once
that's done oaxaca will be shut down.

Thanks for your patience while we dealt with the failing oaxaca and
worked through setting up the new machine.

Valerie



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

[Rd] simplify2array(higher=TRUE, listOfSingleRowDataframes)

[William Dunlap via R-devel]

I noticed that simplify2array acted oddly when given a list of
data.frames of various sizes.  If the data.frames have one row, it
makes a new first dimension with the dimname equal to
rownames(firstDataframe).  That dimension does not appear for
data.frames with other numbers of rows.

> str(dimnames(sapply(345:346, function(i)data.frame(X=101, Y=201, 
> row.names=paste0("Row",1)), simplify="array")))
List of 3
 $ : chr "Row1"
 $ : chr [1:2] "X" "Y"
 $ : NULL
> str(dimnames(sapply(345:346, function(i)data.frame(X=numeric(), Y=numeric(0), 
> row.names=character()), simplify="array")))
List of 2
 $ : chr [1:2] "X" "Y"
 $ : NULL
> str(dimnames(sapply(345:346, function(i)data.frame(X=101:102, Y=201:202, 
> row.names=paste0("Row",1:2)), simplify="array")))
List of 2
 $ : chr [1:2] "X" "Y"
 $ : NULL

The extra dimension does not appear if I convert those data.frames to lists.

It does appear if I convert those data.frames to matrices and the
number of rows is not zero (in which case there are no dims or
dimnames).

Is this pattern of behavior intended?

Bill Dunlap
TIBCO Software
wdunlap tibco.com

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

[R-pkg-devel] Creating a new package dependent on Igraph

[Annu Joshi]

Hello all,

We have created a new package called dgraph which contains all the igraph
codebase along with our graph decomposition functions.
We have overwritten the Namespace and exported only our functions.So, the
user will not be able to access the functions of igraph through our package
dgraph.
The prototype of our functions follow this skeleton:
dgraph_our-function-name
Hence our package contain both Igraph and Dgraph code.

The package was working fine when the functions were only returning a
vector of numbers i.e. the truss value of the edges of the graph. But it
seems to be broken when we return a vector of igraph graph objects. We have
traced the problem to be in R_Igraph_To_SEXP .

But this functionality was working when imlemented in our local igraph
package.

Can you advise where we are going wrong. We can share the package if you
want to have a look.

Thanks

[[alternative HTML version deleted]]

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

Re: [Rd] strptime("1","%m") returns NA

[frederik]

Hi Martyn,

Thanks for finding that stuff in the documentation, and apologies for
not reading the whole thing carefully. I guess when I got to the
minutiae about printing years before '999', I started to skim.

My vote is for more sensible / standard behavior, but I guess this has
probably been this way for a long time.

Frederick

On Tue, Jan 17, 2017 at 01:35:35PM +, Martyn Plummer wrote:
> Hi Frederik,
> 
> On Mon, 2017-01-16 at 18:20 -0800, frede...@ofb.net wrote:
> > Hi R Devel,
> > 
> > I wrote some code which depends on 'strptime' being able to parse an
> > incomplete date, like this:
> > 
> > > 
> > > base::strptime("2016","%Y")
> > [1] "2016-01-14 PST"
> > 
> > The above works - although it's odd that it gives the month and day
> > for Sys.time(). I might expect it to set them both to zero as the GNU
> > libc strptime does on my system, or to use January 1 which would also
> > be reasonable.
> 
> From the help page for strptime:
> 
> "For ‘strptime’ the input string need not specify the date completely:
> it is assumed that unspecified seconds, minutes or hours are zero, and
> an unspecified year, month or day is the current one."
>  
> > When I specify the month, however, I get NA:
> > 
> > > 
> > > base::strptime("2016-12","%Y-%m")
> > [1] NA
> > > 
> > > base::strptime("1", "%m")
> > [1] NA
> > 
> > Any reason for this to be the case?
> 
> Also from the help page:
> 
> "(However, if a month is specified, the day of that month has to be
> specified by ‘%d’ or ‘%e’ since the current day of the month need not
> be valid for the specified month.)"
> 
> If strptime("2016-2", "%Y-%m") just filled in the current day then it
> would give valid output when called on the 1st to the 28th of each
> month, but would give either invalid output or fail when called on the
> 29th to the 31st of any month. This would be a nightmare to debug. The
> current behaviour lets you know there is a logical problem with your
> input.
> 
> > I reported a bug here:
> > 
> > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17212
> > 
> > but I don't think I'm getting emails from Bugzilla so maybe best to
> > ping me if anyone replies there instead.
> 
> See the general guidance on submitting bug reports:
> 
> "Code doing something unexpected is not necessarily a bug - make sure to 
> carefully review the documentation for the function you are calling to see if 
> the behaviour it exhibits is what it was designed to do, even if it’s not 
> what you want."
> 
> https://www.r-project.org/bugs.html
> 
> 
> Martyn
> 
> > I've just written a simple reimplementation of 'strptime' for my own
> > use; I hope this bug report may be useful to others.
> > 
> > Thank you,
> > 
> > Frederick
> > 
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] named arguments in formula and terms

[Achim Zeileis]

Martin, thanks for the follow-up!

On Mon, 13 Mar 2017, Martin Maechler wrote:


Dear Achim,


Achim Zeileis 
on Fri, 10 Mar 2017 15:02:38 +0100 writes:


   > Hi, we came across the following unexpected (for us)
   > behavior in terms.formula: When determining whether a term
   > is duplicated, only the order of the arguments in function
   > calls seems to be checked but not their names. Thus the
   > terms f(x, a = z) and f(x, b = z) are deemed to be
   > duplicated and one of the terms is thus dropped.

   R> attr(terms(y ~ f(x, a = z) + f(x, b = z)), "term.labels")
   > [1] "f(x, a = z)"

   > However, changing the arguments or the order of arguments
   > keeps both terms:

   R> attr(terms(y ~ f(x, a = z) + f(x, b = zz)), "term.labels")
   > [1] "f(x, a = z)" "f(x, b = zz)"
   R> attr(terms(y ~ f(x, a = z) + f(b = z, x)), "term.labels")
   > [1] "f(x, a = z)" "f(b = z, x)"

   > Is this intended behavior or needed for certain terms?

   > We came across this problem when setting up certain smooth
   > regressors with different kinds of patterns. As a trivial
   > simplified example we can generate the same kind of
   > problem with rep(). Consider the two dummy variables rep(x
   > = 0:1, each = 4) and rep(x = 0:1, times = 4). With the
   > response y = 1:8 I get:

   R> lm((1:8) ~ rep(x = 0:1, each = 4) + rep(x = 0:1, times = 4))

   > Call: lm(formula = (1:8) ~ rep(x = 0:1, each = 4) + rep(x
   > = 0:1, times = 4))

   > Coefficients: (Intercept) rep(x = 0:1, each = 4) 2.5 4.0

   > So while the model is identified because the two
   > regressors are not the same, terms.fomula does not
   > recognize this and drops the second regressor.  What I
   > would have wanted can be obtained by switching the
   > arguments:

   R> lm((1:8) ~ rep(each = 4, x = 0:1) + rep(x = 0:1, times =4))

   > Call: lm(formula = (1:8) ~ rep(each = 4, x = 0:1) + rep(x
   > = 0:1, times = 4))

   > Coefficients: (Intercept) rep(each = 4, x = 0:1) rep(x =
   > 0:1, times = 4) 2 4 1

   > Of course, here I could avoid the problem by setting up
   > proper factors etc. But to me this looks a potential bug
   > in terms.formula...

I agree that there is a bug.


OK, good. I just wasn't sure whether I had missed some documentation 
somewhere that this is intended behavior.



According to https://www.r-project.org/bugs.html
I have generated an R bugzilla account for you so you can report
it there (for "book keeping", posteriority, etc).


Thanks, I had already looked at that but waited for feedback on this list 
first.



   > Thanks in advance for any insights, Z

and thank *you* (and Nikolaus ?) for the report!


No problem. Niki found the problem and I came up with the simplified 
example. In any case, I just posted a slightly modified version of my 
e-mail as #17235 on Bugzilla:


https://bugs.R-project.org/bugzilla/show_bug.cgi?id=17235

Thanks & best wishes,
Z



Best regards,
Martin




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

Re: [Bioc-devel] Chromosome order in GRangesForUCSCGenome

[Michael Lawrence]

Looks like UCSC has started sorting the chromosomes by size.  I made 1.35.9
use sortSeqlevels() to normalize the order of them.

On Mon, Mar 13, 2017 at 3:05 AM, Bernat Gel  wrote:

> I'm downloading genome information from UCSC using the
> GRangesForUCSCGenome from rtracklayer and it seems that the chromosome
> order is incorrect (or at least non-canonical).
>
> > seqlevels(GRangesForUCSCGenome(genome="hg19"))
>
> [1] "chr1"  "chr2" "chr3"  "chr4" "chr5"
> [6] "chr6"  "chr7" "chrX"  "chr8" "chr9"
> [11] "chr10" "chr11" "chr12" "chr13"
> "chr14"
> [16] "chr15" "chr16" "chr17" "chr18"
> "chr20"
> [21] "chrY"  "chr19" "chr22" "chr21"
> "chr6_ssto_hap7"
> [26] ...
>
> With chrX before chr8  and Y before chr19.
>
> And the same happens with SeqinfoForUCSCGenome(genome="hg19")
>
> I know I could reorder them manually, but I'm downloading this from
> various genomes to cache them in a package (karyoploteR) and I'd rather not
> rely on manual sorting for that.
>
> I'm quite sure it used to return them in the canonical order. Is there
> anything I'm missing or is it a bug somewhere?
>
>
> Thanks a lot
>
> Bernat
>
>
>
>
> sessionInfo()
> R Under development (unstable) (2016-11-07 r71637)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Debian GNU/Linux 8 (jessie)
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8  LC_NUMERIC=C LC_TIME=C
>  LC_COLLATE=en_US.utf8 LC_MONETARY=en_US.utf8
>  [6] LC_MESSAGES=en_US.utf8LC_PAPER=es_ES.UTF-8 LC_NAME=C
>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
> methods   base
>
> other attached packages:
>  [1] testthat_1.0.2karyoploteR_0.99.8 biovizBase_1.23.2
>  regioneR_1.7.1BSgenome_1.43.2 rtracklayer_1.35.1
>  [7] Biostrings_2.43.2 XVector_0.15.0 GenomicRanges_1.27.18
> GenomeInfoDb_1.11.6   IRanges_2.9.14 S4Vectors_0.13.5
> [13] BiocGenerics_0.21.1   memoise_1.0.0
>
> loaded via a namespace (and not attached):
>  [1] Rcpp_0.12.8   lattice_0.20-34 Rsamtools_1.27.11
>assertthat_0.1
>  [5] digest_0.6.11 mime_0.5 R6_2.2.0
> plyr_1.8.4
>  [9] backports_1.0.4   acepack_1.4.1 RSQLite_1.1-2
>  httr_1.2.1
> [13] ggplot2_2.2.1 BiocInstaller_1.25.3 zlibbioc_1.21.0
>GenomicFeatures_1.27.6
> [17] lazyeval_0.2.0data.table_1.10.0 rpart_4.1-10
> Matrix_1.2-7.1
> [21] checkmate_1.8.2   splines_3.4.0 BiocParallel_1.9.4
> AnnotationHub_2.7.9
> [25] stringr_1.1.0 foreign_0.8-67 ProtGenerics_1.7.0
>   RCurl_1.95-4.8
> [29] biomaRt_2.31.3munsell_0.4.3 shiny_0.14.2
> httpuv_1.3.3
> [33] base64enc_0.1-3   htmltools_0.3.5 nnet_7.3-12
>SummarizedExperiment_1.5.3
> [37] tibble_1.2gridExtra_2.2.1 htmlTable_1.8
>interactiveDisplayBase_1.13.0
> [41] Hmisc_4.0-2   XML_3.98-1.5 crayon_1.3.2
> GenomicAlignments_1.11.6
> [45] bitops_1.0-6  grid_3.4.0 xtable_1.8-2
>   gtable_0.2.0
> [49] DBI_0.5-1 magrittr_1.5 scales_0.4.1
> stringi_1.1.2
> [53] latticeExtra_0.6-28   Formula_1.2-1 RColorBrewer_1.1-2
> ensembldb_1.99.10
> [57] tools_3.4.0   dichromat_2.0-0 Biobase_2.35.0
>   survival_2.40-1
> [61] yaml_2.1.14   AnnotationDbi_1.37.0 colorspace_1.3-2
> cluster_2.0.5
> [65] VariantAnnotation_1.21.14 knitr_1.15.1
>
>
> --
>
> *Bernat Gel Moreno*
> Bioinformatician
>
> Hereditary Cancer Program
> Program of Predictive and Personalized Medicine of Cancer (PMPPC)
> Germans Trias i Pujol Research Institute (IGTP)
>
> Campus Can Ruti
> Carretera de Can Ruti, Camí de les Escoles s/n
> 08916 Badalona, Barcelona, Spain
>
> Tel: (+34) 93 554 3068
> Fax: (+34) 93 497 8654
> 08916 Badalona, Barcelona, Spain
> b...@igtp.cat 
> www.germanstrias.org 
>
> 
>
>
>
>
>
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] question on package build

[Shepherd, Lori]

I can investigate this and see what was going on however, you deleted the first 
comment when submitting packages that included the link to your github 
repository.  Until you add the section agreeing to the Bioconductor terms of 
package review and include the link to your github repository we can not help 
you.  I made this comment on your issues page as well.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of  
<2573552...@qq.com>
Sent: Monday, March 13, 2017 8:46:19 AM
To: Bioc-devel
Subject: [Bioc-devel] question on package build

Hi

I have develop a Bioconductor package and submit the issue to build and check. 
It has passed the build and check on Windows and Mac OS. But I don't know why 
build takes less than 1 minute on Windows and Mac OS but more than 10 minutes 
on your  Linux machine? The report of build and check is on the below:
http://bioconductor.org/spb_reports/Trumpet_buildreport_20170313003039.html
Teng Zhang

Thank you for your help
[[alternative HTML version deleted]]

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


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

[Bioc-devel] question on package build

[????]

Hi

I have develop a Bioconductor package and submit the issue to build and check. 
It has passed the build and check on Windows and Mac OS. But I don't know why 
build takes less than 1 minute on Windows and Mac OS but more than 10 minutes 
on your  Linux machine? The report of build and check is on the below:
http://bioconductor.org/spb_reports/Trumpet_buildreport_20170313003039.html 

 
Teng Zhang
   
Thank you for your help
[[alternative HTML version deleted]]

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

[Bioc-devel] Chromosome order in GRangesForUCSCGenome

[Bernat Gel]

I'm downloading genome information from UCSC using the 
GRangesForUCSCGenome from rtracklayer and it seems that the chromosome 
order is incorrect (or at least non-canonical).


> seqlevels(GRangesForUCSCGenome(genome="hg19"))

[1] "chr1"  "chr2" "chr3"  "chr4" "chr5"
[6] "chr6"  "chr7" "chrX"  "chr8" "chr9"
[11] "chr10" "chr11" "chr12" "chr13" 
"chr14"
[16] "chr15" "chr16" "chr17" "chr18" 
"chr20"
[21] "chrY"  "chr19" "chr22" "chr21" 
"chr6_ssto_hap7"

[26] ...

With chrX before chr8  and Y before chr19.

And the same happens with SeqinfoForUCSCGenome(genome="hg19")

I know I could reorder them manually, but I'm downloading this from 
various genomes to cache them in a package (karyoploteR) and I'd rather 
not rely on manual sorting for that.


I'm quite sure it used to return them in the canonical order. Is there 
anything I'm missing or is it a bug somewhere?



Thanks a lot

Bernat




sessionInfo()
R Under development (unstable) (2016-11-07 r71637)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)

locale:
 [1] LC_CTYPE=en_US.UTF-8  LC_NUMERIC=C LC_TIME=C 
LC_COLLATE=en_US.utf8 LC_MONETARY=en_US.utf8
 [6] LC_MESSAGES=en_US.utf8LC_PAPER=es_ES.UTF-8 
LC_NAME=C 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  
methods   base


other attached packages:
 [1] testthat_1.0.2karyoploteR_0.99.8 biovizBase_1.23.2 
regioneR_1.7.1BSgenome_1.43.2 rtracklayer_1.35.1
 [7] Biostrings_2.43.2 XVector_0.15.0 GenomicRanges_1.27.18 
GenomeInfoDb_1.11.6   IRanges_2.9.14 S4Vectors_0.13.5

[13] BiocGenerics_0.21.1   memoise_1.0.0

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.8   lattice_0.20-34 
Rsamtools_1.27.11 assertthat_0.1
 [5] digest_0.6.11 mime_0.5 
R6_2.2.0  plyr_1.8.4
 [9] backports_1.0.4   acepack_1.4.1 
RSQLite_1.1-2 httr_1.2.1
[13] ggplot2_2.2.1 BiocInstaller_1.25.3 
zlibbioc_1.21.0   GenomicFeatures_1.27.6
[17] lazyeval_0.2.0data.table_1.10.0 
rpart_4.1-10  Matrix_1.2-7.1
[21] checkmate_1.8.2   splines_3.4.0 
BiocParallel_1.9.4AnnotationHub_2.7.9
[25] stringr_1.1.0 foreign_0.8-67 
ProtGenerics_1.7.0RCurl_1.95-4.8
[29] biomaRt_2.31.3munsell_0.4.3 
shiny_0.14.2  httpuv_1.3.3
[33] base64enc_0.1-3   htmltools_0.3.5 
nnet_7.3-12   SummarizedExperiment_1.5.3
[37] tibble_1.2gridExtra_2.2.1 
htmlTable_1.8 interactiveDisplayBase_1.13.0
[41] Hmisc_4.0-2   XML_3.98-1.5 
crayon_1.3.2  GenomicAlignments_1.11.6
[45] bitops_1.0-6  grid_3.4.0 
xtable_1.8-2  gtable_0.2.0
[49] DBI_0.5-1 magrittr_1.5 
scales_0.4.1  stringi_1.1.2
[53] latticeExtra_0.6-28   Formula_1.2-1 
RColorBrewer_1.1-2ensembldb_1.99.10
[57] tools_3.4.0   dichromat_2.0-0 
Biobase_2.35.0survival_2.40-1
[61] yaml_2.1.14   AnnotationDbi_1.37.0 
colorspace_1.3-2  cluster_2.0.5

[65] VariantAnnotation_1.21.14 knitr_1.15.1


--

*Bernat Gel Moreno*
Bioinformatician

Hereditary Cancer Program
Program of Predictive and Personalized Medicine of Cancer (PMPPC)
Germans Trias i Pujol Research Institute (IGTP)

Campus Can Ruti
Carretera de Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona, Spain

Tel: (+34) 93 554 3068
Fax: (+34) 93 497 8654
08916 Badalona, Barcelona, Spain
b...@igtp.cat 
www.germanstrias.org 









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

Re: [Rd] named arguments in formula and terms

[Martin Maechler]

Dear Achim,

> Achim Zeileis 
> on Fri, 10 Mar 2017 15:02:38 +0100 writes:

> Hi, we came across the following unexpected (for us)
> behavior in terms.formula: When determining whether a term
> is duplicated, only the order of the arguments in function
> calls seems to be checked but not their names. Thus the
> terms f(x, a = z) and f(x, b = z) are deemed to be
> duplicated and one of the terms is thus dropped.

R> attr(terms(y ~ f(x, a = z) + f(x, b = z)), "term.labels")
> [1] "f(x, a = z)"

> However, changing the arguments or the order of arguments
> keeps both terms:

R> attr(terms(y ~ f(x, a = z) + f(x, b = zz)), "term.labels")
> [1] "f(x, a = z)" "f(x, b = zz)"
R> attr(terms(y ~ f(x, a = z) + f(b = z, x)), "term.labels")
> [1] "f(x, a = z)" "f(b = z, x)"

> Is this intended behavior or needed for certain terms?

> We came across this problem when setting up certain smooth
> regressors with different kinds of patterns. As a trivial
> simplified example we can generate the same kind of
> problem with rep(). Consider the two dummy variables rep(x
> = 0:1, each = 4) and rep(x = 0:1, times = 4). With the
> response y = 1:8 I get:

R> lm((1:8) ~ rep(x = 0:1, each = 4) + rep(x = 0:1, times = 4))

> Call: lm(formula = (1:8) ~ rep(x = 0:1, each = 4) + rep(x
> = 0:1, times = 4))

> Coefficients: (Intercept) rep(x = 0:1, each = 4) 2.5 4.0

> So while the model is identified because the two
> regressors are not the same, terms.fomula does not
> recognize this and drops the second regressor.  What I
> would have wanted can be obtained by switching the
> arguments:

R> lm((1:8) ~ rep(each = 4, x = 0:1) + rep(x = 0:1, times =4))

> Call: lm(formula = (1:8) ~ rep(each = 4, x = 0:1) + rep(x
> = 0:1, times = 4))

> Coefficients: (Intercept) rep(each = 4, x = 0:1) rep(x =
> 0:1, times = 4) 2 4 1

> Of course, here I could avoid the problem by setting up
> proper factors etc. But to me this looks a potential bug
> in terms.formula...

I agree that there is a bug.
According to https://www.r-project.org/bugs.html
I have generated an R bugzilla account for you so you can report
it there (for "book keeping", posteriority, etc).

> Thanks in advance for any insights, Z

and thank *you* (and Nikolaus ?) for the report!

Best regards,
Martin

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