Re: [Bioc-devel] BiocManager not installing latest release version of DepecheR
I would assume that "BiocManager::install()" won't update an existing set of BioC packages unless explicitly prompted. If that's the case, shouldn't the instructions at http://bioconductor.org/install/ specify "BiocManager::install(version='3.10')"? On Wed, Nov 13, 2019 at 1:04 PM Shepherd, Lori wrote: > > BiocManager should recognize versions automatically for the version of R. I > believe we had a message that would be displayed in this case where there was > a more recent version available > Something along the lines of: > Bioconductor version '3.9' is out-of-date; the current release version '3.10' > is available with R version '3.6'; see https://bioconductor.org/install > > It is broken in this latest version of BiocManager but will be correct > shortly. > > > > Lori Shepherd > > Bioconductor Core Team > > Roswell Park Comprehensive Cancer Center > > Department of Biostatistics & Bioinformatics > > Elm & Carlton Streets > > Buffalo, New York 14263 > > > From: Jakob Theorell > Sent: Wednesday, November 13, 2019 3:59 PM > To: Aaron Lun ; Shepherd, Lori > > Cc: bioc-devel@r-project.org > Subject: Re: [Bioc-devel] BiocManager not installing latest release version > of DepecheR > > Yes, this sounds like a very good solution. Thank you all for your input, and > I hope this silly mistake of mine might have some positive consequence. > Best > Jakob > > From: Bioc-devel on behalf of Aaron Lun > > Sent: 13 November 2019 18:56 > To: Shepherd, Lori > Cc: bioc-devel@r-project.org > Subject: Re: [Bioc-devel] BiocManager not installing latest release version > of DepecheR > > Perhaps the installation instructions on each package's landing page > should explicitly specify 'version=3.10' (or whatever happens to be > the latest release) in the install() call. This avoids ambiguities > with using the latest version when the current and previous releases > are on the same version of R. > > -A > > On Wed, Nov 13, 2019 at 8:25 AM Shepherd, Lori > wrote: > > > > It looks like you are still installing release 3.9 versions of packages. > > The latest version is release 3.10. > > > > If you do > > BiocManager::version() > > Does it show "3.9" or "3.10"? > > > > I'm betting "3.9" > > > > You can do > > > > BiocManager::install(version="3.10") > > BiocManager::install() > > > > > > To update all packages to 3.10 versions > > > > > > Cheers, > > > > > > Lori Shepherd > > > > Bioconductor Core Team > > > > Roswell Park Comprehensive Cancer Center > > > > Department of Biostatistics & Bioinformatics > > > > Elm & Carlton Streets > > > > Buffalo, New York 14263 > > > > > > From: Bioc-devel on behalf of Jakob > > Theorell > > Sent: Wednesday, November 13, 2019 11:06 AM > > To: bioc-devel@r-project.org > > Subject: [Bioc-devel] BiocManager not installing latest release version of > > DepecheR > > > > Dear all, > > This is probably a mistake on my side, but I just now tried to install the > > last release version of DepecheR (for which I am the maintainer), and > > although the source package on BioConductor is 1.2, this is the text I get > > from BiocManager when installing: > > > > Bioconductor version 3.9 (BiocManager 1.30.9), R 3.6.1 (2019-07-05) > > Installing package(s) 'DepecheR' > > trying URL > > 'https://bioconductor.org/packages/3.9/bioc/bin/macosx/el-capitan/contrib/3.6/DepecheR_1.0.3.tgz' > > > > This is clearly the old version, that does not contain all the updates that > > the source package contains. Have I missed something I should have done to > > prevent this and what can I in that case do now? > > Best regards > > Jakob Theorell, MD/PhD > > Autoimmune Neurology Group > > Nuffield Department of Clinical Neurosciences > > University of Oxford > > > > > > [[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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > This email message may contain legally privileged and/or confidential >
[Bioc-devel] R CMD build error for new package.
Hello, I am trying to submit a new package to Bioconductor and received the automated R CMD check report and it seems to have failed. For reference the R CMD build error is from the creating vignette step. Quitting from lines 56-61 (CSSQ.Rmd) Error: processing vignette 'CSSQ.Rmd' failed with diagnostics: incorrect number of dimensions --- failed re-building CSSQ.Rmd I am not able to recreate the issue as all checks work fine on my computer. The main difference is maybe that I am not using the devel version as I have some issues with Rtools version mismatch and am not able to build packages under that environment. Any advice on how do I go about dealing with this would be appreciated. Thanks, Ashwath [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
On 11/14/19 05:47, Hadley Wickham wrote:
> On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler
> wrote:
>>
>>> Gabriel Becker
>>> on Sat, 2 Nov 2019 12:37:08 -0700 writes:
>>
>> > I agree that we can be careful and narrow and still see a
>> > nice improvement in behavior. While Herve's point is valid
>> > and I understand his frustration, I think staying within
>> > the matrix vs c(matrix, array) space is the right scope
>> > for this work in terms of fiddling with inheritance.
>>
>> [.]
>>
>>
Also, we seem to have a rule that inherits(x, c) iff c %in% class(x),
>>>
>>> good point, and that's why my usage of inherits(.,.) was not
>>> quite to the point. [OTOH, it was to the point, as indeed from
>>>the ?class / ?inherits docu, S3 method dispatch and inherits
>>>must be consistent ]
>>>
>>> > which would break -- unless we change class(x) to return the whole
>>> set of inherited classes, which I sense that we'd rather not do
>>
>>[]
>>
>>> Note again that both "matrix" and "array" are special [see ?class] as
>>> being of __implicit class__ and I am considering that this
>>> implicit class behavior for these two should be slightly
>>> changed
>>>
>>> And indeed I think you are right on spot and this would mean
>>> that indeed the implicit class
>>> "matrix" should rather become c("matrix", "array").
>>
>> I've made up my mind (and not been contradicted by my fellow R
>> corers) to try go there for R 4.0.0 next April.
>
> I can't seem to find the previous thread, so would you mind being a
> bit more explicit here? Do you mean adding "array" to the implicit
> class?
It's late in Europe ;-)
That's my understanding. I think the plan is to have class(matrix())
return c("matrix", "array"). No class attributes added to matrix or
array objects.
It's all what is needed to have inherits(matrix(), "array") return TRUE
(instead of FALSE at the moment) and S3 dispatch pick up the foo.array
method when foo(matrix()) is called and there is no foo.matrix method.
> Or adding it to the explicit class? Or adding it to inherits?
> i.e. which of the following results are you proposing to change?
>
> is_array <- function(x) UseMethod("is_array")
> is_array.array <- function(x) TRUE
> is_array.default <- function(x) FALSE
>
> x <- matrix()
> is_array(x)
> #> [1] FALSE
> x <- matrix()
> inherits(x, "array")
> #> [1] FALSE
> class(x)
> #> [1] "matrix"
>
> It would be nice to make sure this is consistent with the behaviour of
> integers, which have an implicit parent class of numeric:
I agree but I don't know if Martin wants to go that far for R 4.0.
Hopefully that's the longer term plan though (maybe for R 4.1?).
Note that there are other situations that could follow e.g.
data.frame/list and probably more...
H.
>
> is_numeric <- function(x) UseMethod("is_numeric")
> is_numeric.numeric <- function(x) TRUE
> is_numeric.default <- function(x) FALSE
>
> x <- 1L
> is_numeric(x)
> #> [1] TRUE
> inherits(x, "numeric")
> #> [1] FALSE
> class(x)
> #> [1] "integer"
>
> Hadley
>
--
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: [R-pkg-devel] Using FORTRAN libraries and compiler options
On 14 November 2019 at 16:42, Rampal S. Etienne wrote: | I couldn't find a call to dgemm in the mvtnorm package. Do you have | other suggestions for packages that may be calling this? The mirror of CRAN at GitHub allows convenient search. Looking for 'user:cran dgemm' give 620+ code hits; the page allows you to click on Fortran to further strict leading to this URL for i) user:cran ii) dgemm iii) type=code and iv) l=Fortran: https://github.com/search?l=Fortran=user%3Acran+dgemm=Code Hth, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler
wrote:
>
> > Gabriel Becker
> > on Sat, 2 Nov 2019 12:37:08 -0700 writes:
>
> > I agree that we can be careful and narrow and still see a
> > nice improvement in behavior. While Herve's point is valid
> > and I understand his frustration, I think staying within
> > the matrix vs c(matrix, array) space is the right scope
> > for this work in terms of fiddling with inheritance.
>
> [.]
>
>
> > > Also, we seem to have a rule that inherits(x, c) iff c %in% class(x),
> >
> > good point, and that's why my usage of inherits(.,.) was not
> > quite to the point. [OTOH, it was to the point, as indeed from
> > the ?class / ?inherits docu, S3 method dispatch and inherits
> > must be consistent ]
> >
> > > which would break -- unless we change class(x) to return the whole
> > set of inherited classes, which I sense that we'd rather not do
>
> []
>
> > Note again that both "matrix" and "array" are special [see ?class] as
> > being of __implicit class__ and I am considering that this
> > implicit class behavior for these two should be slightly
> > changed
> >
> > And indeed I think you are right on spot and this would mean
> > that indeed the implicit class
> > "matrix" should rather become c("matrix", "array").
>
> I've made up my mind (and not been contradicted by my fellow R
> corers) to try go there for R 4.0.0 next April.
I can't seem to find the previous thread, so would you mind being a
bit more explicit here? Do you mean adding "array" to the implicit
class? Or adding it to the explicit class? Or adding it to inherits?
i.e. which of the following results are you proposing to change?
is_array <- function(x) UseMethod("is_array")
is_array.array <- function(x) TRUE
is_array.default <- function(x) FALSE
x <- matrix()
is_array(x)
#> [1] FALSE
x <- matrix()
inherits(x, "array")
#> [1] FALSE
class(x)
#> [1] "matrix"
It would be nice to make sure this is consistent with the behaviour of
integers, which have an implicit parent class of numeric:
is_numeric <- function(x) UseMethod("is_numeric")
is_numeric.numeric <- function(x) TRUE
is_numeric.default <- function(x) FALSE
x <- 1L
is_numeric(x)
#> [1] TRUE
inherits(x, "numeric")
#> [1] FALSE
class(x)
#> [1] "integer"
Hadley
--
http://hadley.nz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] Python Z trees to hclust
Hi Peter, Thanks for the advice and pointers to the relevant files. After reading the Fortran code and thinking about it I ended up coding from scratch my own pure R function to set the plotting order of an hclust object. It might not be as fast as the Fortran implementation, but it works pretty well and as far as I can tell the resulting order is exactly the same to the original hclust code. If anyone is interested it's available at the CopyNumberPlots package at https://github.com/bernatgel/CopyNumberPlots/blob/5b9a1efea53e424a32616b7d82560d81c9ba4a10/R/utils.R#L933 Bernat El 8/3/19 a las 8:41 PM, Peter Langfelder escribió: > Hi Bernat, > > my advice may not be that useful, but it may be better than the > silence so far... > > Regarding the ordering of objects in hclust, if you're willing to do a > bit of hacking, have a look at the stats::hclust function; you will > see that the ordering is computed by a call to Fortran function > hcass2. That function could be used or perhaps adapted (it uses an > additional step that you will probably need to skip) to give you the > ordering. If you're good at understanding Fortran code, you may even > be able to re-write it directly in R. > > Peter > > On Tue, Jul 30, 2019 at 12:39 AM Bernat Gel Moreno wrote: >> Hi, >> >> For one of our packages (CopyNumberPlots) we'll need to read 10X CNV >> data in H5 format. I've read in everything I need except for the cell >> clustering tree. It's in a format called Z format produced by SciPy >> hierarchical clustering. The format itself is relatively easy to parse >> and not so different from hclust return objects so it would be possible >> to create a small function to translate the Z notation into an hclust >> object, if needed, but I'll need to figure out the "order" vector, since >> it's not present in Z. >> >> - Is the Z to hclust function available in any other package? Or >> something equivalent to that? >> - If I end up transforming it by hand in a custom function, Is there >> a function somewhere to compute the order vector in an hclust object? >> >> Thanks >> >> Bernat >> >> >> ___ >> 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
