On 10/30/20 10:48, luke-tier...@uiowa.edu wrote:
> On Fri, 30 Oct 2020, Pages, Herve wrote:
>
>>
>> On 10/29/20 23:08, Pages, Herve wrote:
>> ...
>>>
>>> I can think of 2 ways to move forward:
>>>
>>> 1. Keep I()'s current implement
On 10/29/20 23:08, Pages, Herve wrote:
...
>
> I can think of 2 ways to move forward:
>
> 1. Keep I()'s current implementation but suppress the warning. We'll
> make the necessary adjustments to DataFrame() to repair columns supplied
> as I() objects. Note t
Hi Martin,
On 10/26/20 04:52, Martin Maechler wrote:
>>
>> Hi there,
>> Is that change in R-devel intentional?
>>
>> library(Matrix)
>> m <- as(matrix(c(0, 1)), "sparseMatrix")
>>
>> isS4(m)
>> # [1] TRUE
>>
>> x <- I(m)
>> # Warning message:
>> # In `class<-`(x,
Hi Damian,
Looks like today the problem went away and that STRINGdb 2.2.0 is now
available on all platforms. We should still keep an eye on this for a
few more days though so we get an idea of whether this is intermittent
or gone for good.
Cheers,
H.
On 10/28/20 23:45, Pages, Herve wrote
Hi Damian,
stringdb-static.org resolves to 185.111.60.15 on malbec1 like on
nebbiolo1 and merida1.
Also the following code runs with no problem in an interactive session
on malbec1:
> tmp <- tempfile()
>
us further insight on the meaning of this warning? We are
> not able to reproduce it.
>
> Also will our package be released for bioconductor 3.12?
>
> Thank you
>
> Il 21/10/2020 19:08, Pages, Herve ha scritto:
>> Hi Giulia,
>>
>> Today's report is av
Hi there,
Is that change in R-devel intentional?
library(Matrix)
m <- as(matrix(c(0, 1)), "sparseMatrix")
isS4(m)
# [1] TRUE
x <- I(m)
# Warning message:
# In `class<-`(x, unique.default(c("AsIs", oldClass(x :
# Setting class(x) to multiple strings ("AsIs",
Hi,
There are 2 bugs here. The proposed fix to Summary.data.frame() is fine
but it doesn't address the other problem reported by the OP that
as.matrix() on a zero-row data.frame doesn't respect the type of its
columns, like other column-combining operations do:
df <-
Hi Giulia,
Today's report is available. Unfortunately ISAnalytics tests are still
failing on Windows:
https://bioconductor.org/checkResults/devel/bioc-LATEST/ISAnalytics/tokay1-checksrc.html
Note that you have this warning at the beginning of the tests:
> test_check("ISAnalytics")
Hi developers,
Sorry that we didn't have an updated report yesterday (Tuesday October
20) for the BioC 3.12 builds. The new report for today is out:
https://bioconductor.org/checkResults/3.12/bioc-LATEST/
Please address any remaining issue with your packages as soon as
possible. Only two
Hi Laurent,
I think the current implementation was just an expedient to have
something that works (in most cases). I don't know if a proper
implementation that doesn't go thru data.frame is on the TODO list. Michael?
I suggest you open an issue on GitHub under S4Vectors.
Cheers,
H.
PS: Note
ke this has anything to do with the code being executed
inside a knitting context.
Hope this helps.
Cheers,
H.
>
> Best wishes,
>
> Lara
>
>
>
>> On 13 Oct 2020, at 22:49, Pages, Herve > <mailto:hpa...@fredhutch.org>> wrote:
>>
>>
>
Hi Lara,
Thanks for trying hard to address this problem. I can reproduce the
error by running 'R CMD build ncRNAtools' interactively on nebbiolo1.
Yes it seems that the timeout is related to the SSL issue on Ubuntu
20.04. Are you running Ubuntu 20.04 on a Docker image? I've read
somewhere
Hello list,
In ?Reduce:
init: an R object of the same kind as the elements of ‘x’.
Seems like "the same kind" is an unnecessary and artificial restriction.
Furthermore, there is no notion of "same kind" for heterogeneous lists:
x <- list(letters, c(TRUE, FALSE))
Hi Charles, Vince,
Yes, a PairwiseAlignments object will contain the sequences of the 2
genomes being aligned so will be big. Could be mitigated by using one
object per chromosome instead of trying to represent the full genome
alignment in a single object, but then you loose the ability to
oops, sorry for letting this slip off my radar.
see below...
On 9/3/20 05:22, Robert Castelo wrote:
> Hi Hervé,
>
> On 02/09/2020 21:44, Pages, Herve wrote:
>> Hi Robert,
>>
>>
>>
>> On 9/2/20 11:12, Robert Castelo wrote:
>>> hi,
>>>
ike this can be achieved with:
> if (length(rid)>1) {
> x <- rid_rec$last_modified
>
> On Fri, Sep 11, 2020 at 1:22 PM Pages, Herve <mailto:hpa...@fredhutch.org>> wrote:
>
> Hi Shraddha,
>
> Seems to be a BiocFile
Hi Shraddha,
Seems to be a BiocFileCache issue.
On my laptop the following code (taken from your
Predict_CaseControl_from_CNV.Rnw vignette):
require(BiocFileCache)
geneURL <- paste("http://download.baderlab.org/netDx/;,
"supporting_data/refGene.hg18.bed",sep="")
cache <-
xporting data only for
> mac users?
>
> Best regards,
>
> Arman
>
> *From: *Arman Shahrisa <mailto:shahrisa.ar...@hotmail.com>
> *Sent: *Thursday, September 3, 2020 10:59
> *To: *Pages, Herve <mailto:hpa...@fredhutch.org>; bioc-devel
> <mailto:bioc-devel@
Hi Arman,
You already asked about this in May:
https://stat.ethz.ch/pipermail/bioc-devel/2020-May/016788.html
Have you followed up with the xlsx maintainers as suggested by Lluís?
Cheers,
H.
On 8/29/20 11:12, Arman Shahrisa wrote:
> Hi to all,
>
> I�m maintainer of the package �cbaf�. I have
Hi Robert,
On 9/2/20 11:12, Robert Castelo wrote:
> hi,
>
> i've found the following glitches with 'releaseName()' and
> 'seqlevelsStyle()', i guess due to recent changes in BSgenome and
> GenomeInfoDb, which is why i'm cc'ing Hervé ;)
>
> ===BioC release 3.11 everything
On 1/30/20 13:17, Michael Lawrence wrote:
> That sucks. It was broken since it was added in 2017... now fixed.
Unfortunately these things tend to happen to stuff that doesn't have
examples or unit tests.
Thanks for the fix!
H.
___
On 1/30/20 11:10, Hervé Pagès wrote:
> Yes poverlaps() is a good option, as mentioned earlier.
Well actually not. Looks like it's broken:
> poverlaps(GRanges("chr1:11-15"), GRanges("chr1:16-20"))
Error in isSingleNumber(minoverlap) : object 'minoverlaps' not found
H.
ened to just poverlaps()?
>
> On Thu, Jan 30, 2020 at 10:34 AM Pages, Herve wrote:
>>
>> On 1/29/20 23:31, web working wrote:
>>> Hi Herve,
>>>
>>> Thank you for your answer. pcompare works fine for me. Here my solution:
>>>
>>> q
PhzWA=VZ2-jg7W_Ctrav2BpPVUPpvJlyISX3QVwFAzTnDnNTs=Jdmp3dD6ubzPdE8KjFJ3urOav62YTOmxYcYZ4000MY8=>.
>
> Best,
>
> Tobias
>
> Am 29.01.20 um 18:02 schrieb Pages, Herve:
>> Yes poverlaps().
>>
>> Or pcompare(), which should be even faster. But only if you are not
>
l fail if 'subject'
contains ranges that cover less than 2 positions
Not an unlikely situation e.g. if 'subject' contains TSS!
I just feel that distance() is not really appropriate to detect overlaps.
H.
>
>
> On 1/29/20, 12:40 PM, "Pages, Herve" wrote:
>
>
On 1/27/20 23:51, Martin Maechler wrote:
>>>>>> Pages, Herve
>>>>>> on Tue, 21 Jan 2020 17:33:01 + writes:
>
> > Dear Martin,
> > What's the ETA for _R_CLASS_MATRIX_ARRAY_=TRUE to become the new
> > unconditional b
On 1/29/20 08:04, Jianhong Ou, Ph.D. wrote:
> Try
> dist=distance(query, subject)
> dist==0
> ?
Please be aware that dist==0 does NOT mean that 2 ranges overlap. It
means that they overlap OR are **adjacent**:
> distance(GRanges("chr1:1-20"), GRanges("chr1:21-25"))
[1] 0
H.
>
> On 1/29/20,
Yes poverlaps().
Or pcompare(), which should be even faster. But only if you are not
afraid to go low-level. See ?rangeComparisonCodeToLetter for the meaning
of the codes returned by pcompare().
H.
On 1/29/20 08:01, Michael Lawrence via Bioc-devel wrote:
> poverlaps()?
>
> On Wed, Jan 29,
ssay(se, "normalized") <- normalized_data
or wrap it in its own new SE:
normalized <- SummarizedExperiment(list(normalized=normalized_data))
H.
On 1/29/20 08:29, Pages, Herve wrote:
> On 1/28/20 01:37, Laurent Gatto wrote:
>> Dear all,
>>
>> Assume we have a
On 1/28/20 01:37, Laurent Gatto wrote:
> Dear all,
>
> Assume we have a SummarizedExperiment object `se` that contains raw count
> data, and a method `doProcess` that processes the data to produce a matrix of
> identical dimensions (for example log-transformation, normalisation,
> imputation,
hat
> error since the phate Python module cannot be installed on python2
> (which is the version of Python used by malbec1) but as Kayla pointed
> out, it seems this error should not be occurring on the tokay1 builder.
>
>
>
>
> ᐧ
>
> On Sat, Dec 28, 2019 at 1:26
On 1/25/20 12:55, Gábor Csárdi wrote:
> R CMD build does not actually run any R code,
**unless** the package contains dynamic vignettes and/or dynamic man
pages (e.g. man pages that include \Sexpr macros), in which case 'R CMD
build' first installs the package in order to evaluate the dynamic
Hi Lucas,
In order to compile an Rhtslib client package on Windows you need a
setup that mimics closely what we have on our Windows builders. In
particular you need to install a bunch of external libraries in
C:\extsoft and edit R\etc\i386\Makeconf and R\etc\x64\Makeconf to let R
know about
re not
providing enough information for us to be able to tell. What does the
warning say? How can we reproduce the warning? Ideally we would need to
see a transcript of your session and links to your packages.
Thanks,
H.
>
> Best,
>
> Tobias
>
> Am 09.01.20 um 17:59 schrieb
On 1/9/20 06:56, Stepan wrote:
> On 09. 01. 20 15:41, lille stor wrote:
>
>> I believe this could be done without creating side effects (e.g.
>> crash) as we are just talking about changing values.
A crash would certainly be an annoying "side effect" ;-)
As Stepan explained, data.frame objects
Hi Tobias,
If the original data is in BED files, there should be no need to
serialize the objects obtained by importing the files. It is **much**
better to provide a small helper function that creates an object from a
BED file and to use that function each time you need to load an object.
rit seems to be commit ef5e4c21d:
hpages@spectre:~/Rsubread$ git log ef5e4c21d -n 1
commit ef5e4c21d5a6d633aec0b2922dd9f230fed23463
Author: Yang Liao
Date: Mon Dec 9 13:42:08 2019 +1100
Updated Ambient-RNA detection algorithm
Hope this helps,
H.
On 1/8/20 10:30, Pages, Herve wr
Hi Zhe,
The code in the vignette seems to rely a lot on the Rsubread package to
perform some very computationally intensive operations. Could it be that
some recent changes to the Rsubread package are somehow related to the
sudden slowdown of these operations? That's something I suggest you
Hi Fernando,
This is a warning only and is on our side (i.e. it's an issue with how
our Mac builders are set up). It can safely be ignored.
Cheers,
H.
On 1/7/20 23:58, Fernando Pérez Sanz wrote:
> Dear Bioc-devel
>
> I have obtained the following warning by building binaries in celaya2 OS
>
On 1/7/20 06:13, brodie gaslam via R-devel wrote:
...
> Happy new decade.
*** caught segfault ***
conflicting decade boundaries
Traceback:
1: new_decade <- 2020:2029
2: previous_decade <- 2011:2020
3: previous_previous_decade <- 2001:2010
4: current_millenium <- 2001:3000
5:
Hi,
On 1/7/20 10:47, Karl Stamm wrote:
> I was notified recently my package has build errors going in to bioc 3.11.
> So begins the biannual saga of updating everything to see what's new.
> My package has quite a few dependencies, so it's normal for someone to
> change their API and break my
Hi Jose,
evaluomeR 1.3.4 (master branch) is in BioC 3.11 (current BioC devel) so
make sure that you use R 4.0 (current R devel) to develop/test the
master branch of your package. This is what the build system uses to
build/check all the packages in BioC 3.11. Also make sure that all your
Happy New Year everybody!
The name (is.nana) doesn't make much sense to me. Can you explain it?
One alternative would be to add an extra argument (e.g. 'strict') to
is.na(). FALSE by default, and ignored (with or w/o a warning) when the
type of 'x' is not "numeric".
H.
On 12/31/19 22:16,
helps,
H.
On 12/26/19 17:49, William Chen wrote:
> Thanks for looking into this and confirming! Would appreciate any
> suggestions on how to correctly import the python module on malbec1.
>
> Best
> Will
> ᐧ
>
> On Mon, Dec 23, 2019 at 8:41 PM Pages, Herve <mailto:hpa...@f
Hi William,
I can confirm that the phate module is installed for Python 3 on malbec1:
biocbuild@malbec1:~$ python3
Python 3.6.9 (default, Nov 7 2019, 10:44:02)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import phate
>>> phate.__version__
The fact that strsplit() doesn't say anything about 'split' being longer
than 'x' adds to the confusion:
> strsplit(c("xAy", "xxByB", "xCyCCz"), split=c("A", "B", "C", "D"))
[[1]]
[1] "x" "y"
[[2]]
[1] "xx" "y"
[[3]]
[1] "x" "y" "" "z"
A warning (or error) would go a
Hi Vince,
I opened an issue on GitHub for this:
https://github.com/Bioconductor/BiocStyle/issues/68
H.
On 12/15/19 14:31, Vincent Carey wrote:
> On my mac and linux systems I am seeing a new
>
> error. With the latest checkout of BiocStyle
>
>
>
Hi Philipp,
I've updated python3 (from 3.6 to 3.7) and jupyter on merida1. Now we have:
merida1:~ biocbuild$ python3 --version
Python 3.7.3
merida1:~ biocbuild$ which jupyter
/usr/local/bin/jupyter
merida1:~ biocbuild$ jupyter --version
jupyter core : 4.6.1
Hi Vince, Robert,
Looks like Vince wants the RefSeq accession e.g. NC_17.11 for chrom
17 in the GRCh38.
@Robert: Is this what you're also interested in?
The problem is that the RefSeq accessions are specific to a particular
assembly (e.g. NC_17.11 for chrom 17 in GRCh38 but
All the "VerbBar" LaTeX errors have cleared up in release and devel.
Thanks again Andrzej!
Cheers,
H.
On 12/6/19 12:17, Hervé Pagès wrote:
> Great news Andrzej! We'll keep a close eye on the build reports in the
> next few days. Fingers crossed. Thanks!
>
> H.
>
>
> On 12/6/19 03:46,
Great news Andrzej! We'll keep a close eye on the build reports in the
next few days. Fingers crossed. Thanks!
H.
On 12/6/19 03:46, Andrzej Oleś wrote:
> Dear Package Developers,
>
> An updated version of BiocStyle has been deployed to both the development
> and the release branch. The fix
his feature out to the maintainers directly? I don't know how
> tight for time the build process currently is.
Not on my TODO list for now but definitely something to consider when we
start becoming tight in resources for the daily builds.
Cheers,
H.
>
> Cheers,
> Mike
>
> On Thu, 5 Dec 2
On 12/4/19 17:39, Vincent Carey wrote:
> The RangedData objects are still viable with the software you are using,
> but trying
> to set colnames will trigger an error. In Bioc 3.11 you won't even be able
> to use
> the RangedData class at all. So an intervention is needed now.
>
> The
Hello developers,
These builds were announced on this list in Nov. 2017 (see
https://stat.ethz.ch/pipermail/bioc-devel/2017-November/012326.html).
The purpose of the "Long Tests builds" is to run tests that are too long
to run in the 40 min. allowed by the daily builds. With the Long Tests
Hi Henrik,
On 12/3/19 09:13, Henrik Bengtsson wrote:
> I'm interested in finding out what customization Bioconductor servers
> do to R CMD check, e.g. _R_CHECK_***_ settings. I think someone
> pointed me to some location in the past, but I cannot locate it.
The settings on the Linux/Mac
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.
On 11/12/19 14:03, Abby Spurdle wrote:
>> You can have your own rant about "user-defined binary operators being
>> over-used within the R community" without suggesting that my rant was
>> rude.
>
> I wasn't suggesting that you were rude.
> I was questioning a trend.
ok, well, I must ave
On 11/12/19 12:21, Abby Spurdle wrote:
>
>
>> x %inherits% "data.frame"
>
> IMHO, I think that user-defined binary operators are being over-used
> within the R community.
>
> I don't think that they're "cute" or stylish.
> I think their use should be limited to cases, where they
On 11/11/19 01:40, Martin Maechler wrote:
>> Duncan Murdoch
>> on Sun, 10 Nov 2019 11:48:26 -0500 writes:
>
> > On 10/11/2019 9:17 a.m., Bryan Hanson wrote:
> >>
> >>
> >>> On Nov 10, 2019, at 3:36 AM, Martin Maechler
> wrote:
> >>>
>
Hi Leonardo,
The download stats are temporarily unavailable and should be back
tomorrow (as discussed last week on the community-bioc Slack, #general
channel).
Thanks for your patience,
H.
On 11/11/19 10:23, Leonardo Collado Torres wrote:
> Hi,
>
> The tabular files with the Bioconductor
mosomes in smaller pieces.
H.
>
> Cheers,
> -Eric
>
>
>
>
> Date: Fri, 8 Nov 2019 18:19:27 +
> From: "Pages, Herve"
> To: "Bhagwat, Aditya" ,
> "bioc-devel@r-project.org"
> Subject: Re
all.packages() internally, and so on.
>
> /Henrik
>
> PS. Although the idea of having update.packages() install missing
> packages is not bad, I don't think I'm a not a fan for the sole
> purpose of risking installation instructions starting using
> update.packages() instead, which will
Actually there is one gotcha here: even if a package has not changed
(i.e. same exact hash), there are situations where you want to reinstall
it because one package it depends on has changed. This is because some
of the stuff that gets cached at installation time (e.g. method table)
can become
Hi Gabe,
Keeping track of where a package was installed from would be a nice
feature. However it wouldn't be as reliable as comparing hashes to
decide whether a package needs re-installation or not.
H.
On 11/8/19 12:37, Gabriel Becker wrote:
> Hi Josh,
>
> There are a few issues I can think
Since we are on this topic, another area of improvement is when
install.packages() downloads hundreds of packages only to realize later
that many of them actually fail to install because one of the packages
they depend on (directly or indirectly) failed to install.
Cheers,
H.
On 11/8/19
I guess you would just use force=TRUE
H.
On 11/8/19 12:06, William Dunlap via R-devel wrote:
> While developing a package, I often run install.packages() on it many times
> in a session without updating its version number. How would your proposed
> change affect this workflow?
> Bill Dunlap
>
Hi Aditya,
Should not be too hard to parallelize. With some gotchas: using one
worker per chromosome (which is the easy way to go) wouldn't be optimal
because of the size differences between the chromosomes. So a better
approach is to try to give each worker the same amount of work by
On 11/4/19 13:54, Duncan Murdoch wrote:
> On 04/11/2019 4:40 p.m., Pages, Herve wrote:
>> Hi Rolf,
>>
>> On 11/4/19 12:28, Rolf Turner wrote:
>>>
>>> On 5/11/19 3:41 AM, Hadley Wickham wrote:
>>>
>>>> For what it's worth, I don't t
Hi Rolf,
On 11/4/19 12:28, Rolf Turner wrote:
>
> On 5/11/19 3:41 AM, Hadley Wickham wrote:
>
>> For what it's worth, I don't think this strategy can work in general,
>> because a class might have attributes that depend on its data/contents
>> (e.g.
>>
Dear Bioconductor developers,
Some issue with the software builds prevents us from having a build
report today for BioC 3.10. Things should get back to normal tomorrow.
Sorry for the inconvenience.
Cheers,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
On 10/30/19 04:29, Martin Maechler wrote:
>> Gabriel Becker
>> on Tue, 29 Oct 2019 12:43:15 -0700 writes:
>
> > Hi all,
> > So I've started working on this and I ran into something that I didn't
> > know, namely that for x a multi-dimensional (2+) array, head(x) and
>
, Pages, Herve wrote:
> Hi Ting,
>
> We don't roll back anything. We just take whatever is in
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.bioconductor.org_packages_MSstatsTMT=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvS
Hi Ting,
We don't roll back anything. We just take whatever is in
https://git.bioconductor.org/packages/MSstatsTMT and build that.
I don't see any commit from August in the RELEASE_3_10 branch there:
hpages@spectre:~/sandbox/MSstatsTMT$ git status
On branch master
Your branch is up-to-date with
Hi Jakob,
I suggest that you contact the mixOmics's maintainers about this.
Best,
H.
On 10/28/19 13:09, Jakob Theorell wrote:
> Dear all,
> I am the developer for DepecheR. Unfortunately, I was tonight notified of an
> check-error on Malbec1, apparently relating to some linux-specific change
Great badge by the way! :-)
H.
On 10/28/19 02:52, Anand MT wrote:
> Dear mods,
>
> Recently our package `methrix`
>
Hi Panagiotis,
Avoiding code repetition is always a good idea. An alternative to the
creation of a 3rd package would be to have one of the 2 packages depend
on the other. If that is not a good option (and there might be some
valid reasons for that) then yes, factorizing out the repeated stuff
Hi Stefan,
It looks like a connectivity issue, likely a transient one. I would just
wait and see if it goes away in the next days.
Thanks for keeping a close eye on the build results for your package.
Best,
H.
On 10/23/19 11:20, Graw, Stefan H wrote:
> Dear devel team,
>
> My package
Hi Kevin,
Running this particular code (e.g. the code in the test-sparsematrix.R
file) also works for me on our Windows builders. However, trying to run
the **full suite** of tests does trigger the error. So it seems to be a
situation where some code in some other tests is altering the state
Hi Qiang,
Any reason why you use:
UnsupportedPlatforms: win64, win32
and not just:
UnsupportedPlatforms: win
in your .BBSoptions file?
Also make sure to have a line terminator:
hpages@spectre:~/RcwlPipelines$ file .BBSoptions
.BBSoptions: ASCII text, with no line terminators
this.
H.
On 10/16/19 22:10, Pages, Herve wrote:
> Hi David,
>
> Thanks for bringing this to our attention. We'll be looking into it.
>
> H.
>
>
> On 10/16/19 08:21, Robertson, David wrote:
>> Dear Bioc-devel,
>>
>> I updated the development version of
Hi David,
Thanks for bringing this to our attention. We'll be looking into it.
H.
On 10/16/19 08:21, Robertson, David wrote:
> Dear Bioc-devel,
>
> I updated the development version of the onlineFDR package almost a month
> ago, but have noticed that the citation information displayed on the
Hi Toth,
Not clear to me what's going on but I kind of suspect this might have
something to do with the use of data.table.
A few things to keep in mind:
- 'R CMD check' runs all the example in the same R session. This means
that the outcome of the examples of a given man page can be affected
Has someone looked into the image processing area for this? That sounds
a little bit too high-level for base R to me (and I would be surprised
if any mainstream programming language had this kind of functionality
built-in).
H.
On 10/11/19 03:44, Morgan Morgan wrote:
> Hi All,
>
> I was
Hi,
It looks like the error occurs in the Heatmap() function from the
ComplexHeatmap package. What happens is that the devel version of the
ComplexHeatmap package went thru some important changes back in July and
August but its version never got bumped so these changes never
propagated. As a
Hi Michael,
tx_by_gene <- transcriptsBy(txdb, by='gene') returns a named list (or
more precisely, a named GRangesList object) where the names are the gene
ids. The show() method for these objects actually gives a clue that the
list carries names:
> tx_by_gene
GRangesList object of length
Hi Stian,
The 3.10 builds use BioC 3.10 which is the current **devel** version of
BioC so make sure you also use this if you want to reproduce a 3.10
build failure.
Here is how to quickly reproduce the error:
library(chimeraviz)
defuse833ke <- system.file(
"extdata",
Hi Jelena,
The .Rproj.user/ folder and the .git/ folder are 2 different things. Not
sure exactly which one is causing you problem but they shouldn't.
The .Rproj.user/ folder is an RStudio thing that should not be added to
git so make sure it's listed in your .gitignore file.
The .git folder
______
> From: Bioc-devel on behalf of Pages, Herve
>
> Sent: 27 September 2019 00:14
> To: Martin Maechler; Martin Morgan
> Cc: bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Reference manual as HTML
>
> and let's not forget the rdrr site that provides
and let's not forget the rdrr site that provides HTML versions of all R
package man pages in the known world:
https://rdrr.io/bioc/DESeq2/man/DESeq.html
Unfortunately the links across man pages are not clickable :-/
H.
On 9/26/19 06:19, Martin Maechler wrote:
>> Martin Morgan
>>
Thanks Ashish for the quick fix.
For the record the change to tidyr::gather() in the latest version of
tidyr (v 1.0.0) also breaks the CNPBayes and SummarizedBenchmark packages:
https://bioconductor.org/checkResults/3.9/bioc-LATEST/CNPBayes/malbec2-buildsrc.html
we have Xvfb (X11 virtual frame
buffer) run as a service in the background so firefox is able to connect
to that. I'm not sure.
Hope this helps,
H.
On 9/17/19 05:54, Paul Shannon wrote:
> On Sep 12, 2019, at 3:13 PM, Pages, Herve wrote:
>>
>> AFAIK the build machines have web b
Hi,
Alternatively, how about a new glance() generic that would do something
like this:
> library(DelayedArray)
> glance <- DelayedArray:::show_compact_array
> M <- matrix(rnorm(1e6), nrow = 1000L, ncol = 2000L)
> glance(M)
<1000 x 2000> matrix object of type "double":
[,1]
Hi Tiago,
On 9/16/19 06:35, Tiago Lubiana Alves wrote:
> Hello Mike,
>
> Thank you for the detailed explanation.
>
> You are right, for the vignette, I can download it from the ExperimentHub
> subset the pbmc3k dataset in the first few lines. The main point of having
> a new dataset was to use
Hi,
On 9/13/19 06:38, Morgan, Martin wrote:
> Putting bioc-devel back in the loop.
>
> I think that the straight-forward answer to your original query is 'no, git
> modules are not supported'.
>
> I think we'd carry on and say 'packages should be self-contained and conform
> to the
Hi Charles,
Cryptic (but short) answer: the methods package **automatically**
creates a coercion method from CTSS to GRanges for you. Unfortunately
this method is broken.
Decryption:
Warning, this will take us to the very dark side of the S4 coercion system!
First this automatic method
On 9/12/19 15:13, Pages, Herve wrote:
> Hi Paul,
>
> On 9/12/19 11:47, Paul Shannon wrote:
>> My package igvR requires a web browser. Unit tests, examples, vignette all
>> will all fail if one is not available.
>>
>> Since the bioc build system, for go
Hi Paul,
On 9/12/19 11:47, Paul Shannon wrote:
> My package igvR requires a web browser. Unit tests, examples, vignette all
> will all fail if one is not available.
>
> Since the bioc build system, for good reason, does not provide a web browser,
> I’d like to condition all browser-related
Hi Ulrich,
On 9/11/19 07:38, Ulrich Bodenhofer wrote:
> Dear colleagues,
>
> I have two issues with the Windows BUILD BIN of our 'msa' package. (to
> my horror, I figured out that the first problem has existed for quite a
> while; I am deeply sorry for that!)
>
> The main problem can be seen
eah, does this imply that the render operation uses (or tries to use)
> ImageMagick? That's news to me, but I am not following this closely.
>
> On Wed, Sep 11, 2019 at 5:21 AM Pages, Herve <mailto:hpa...@fredhutch.org>> wrote:
>
> On 9/11/19 00:50, Vincent C
1 - 100 of 218 matches
Mail list logo
