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 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
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/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
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
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
>
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
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__
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
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
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
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
, 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
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 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
methods::setAs( "BSgenome",
>> "GRanges",
>> function(from) from %>%
>> GenomeInfoDb::seqinfo() %>%
>> as('GRanges'))
>>
>&g
CSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
>>> #' as('GRanges')
>>> #' @importClassesFrom BSgenome BSgenome
>>> #' @export
>>> methods::setAs( "BSgenome",
>>> "GRanges",
>>>
Afqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=nBHdQoTrd1Mfu4VTMgtkPyUQ0Ju2NLeX-0X1Ny3fSeg=>)
>
> Cheers,
>
> Aditya
>
>
>
>
>
> From: Pages, Herve [hpa...@fredhutch
On 9/11/19 00:50, Vincent Carey wrote:
> I seem to be running into a similar problem with BiocOncoTK on windows
>
> The build report for tokay1 shows:
>
> Loading required package: ontologyIndex
> Invalid Parameter - /figure-html
> Warning in shell(paste(c(cmd, args), collapse = " ")) :
>
Hi Aditya,
It feels that a coercion method from BSgenome to GRanges should rather
be defined in the BSgenome package itself. Patch/PR welcome on GitHub.
More generally speaking, coercion methods should be defined in a place
that is "as close as possible" to the "from" or "to" classes rather
On 9/4/19 14:10, Venu Thatikonda wrote:
> @Lori, sure. I will open the issue with an example.
>
> @Daniel, I didn't understand, I thought this suggestion is for Lori (?).
>
> Do I need to run `R CMD check --force-multiarch` on a windows 32bit system
> from my side? If that's the case, It won't
Also note that since the error is specific to 32-bit Windows, you need
to run 'R CMD check --force-multiarch' on your package source tarball in
order to reproduce the error. Without the --force-multiarch flag, 'R CMD
check' only runs the examples and unit tests for the default arch,
which, for
Hi Simon,
On 9/3/19 09:11, Simon Dirmeier wrote:
...
Do you think it would be possible to install TensorFlow and
TensorFlow-Probability on the builders? I'd assume that many would
profit from that.
As Lori mentioned at the end of her email (see below), we can't make the
tensorflow Python
Hi Marcel, Charles,
Looks like S4Vectors:::coerceToSimpleList() is being to zealous here.
I've tweaked the function a little (in S4Vectors 0.23.21) so that
elements in the supplied list get coerced only when the 2nd argument
(element.type) is specified. This fixes both Marcel's and Charles'
Hi,
On 8/23/19 14:38, Venu Thatikonda wrote:
> Hi,
>
> During one of my R packages bioc review, I see the following 2 errors,
>
> one:
>
> Error in library.dynam(dynlib, pkg, lib) :
>DLL 'rgl' not found: maybe not installed for this architecture?
> Error: .onLoad failed in loadNamespace()
Hi Lambda,
Yes TENxBUSData was accepted but we only build data-experiment packages
on Sundays, Tuesdays, and Thursdays so you might need to wait a couple
extra days before you see TENxBUSData show up on the website and become
available via BiocManager::install().
Thanks for your patience,
H.
Hi Aditya,
I've added the 'load.only' argument to getBSgenome(). This is in
BSgenome 1.53.2. See
https://github.com/Bioconductor/BSgenome/commit/0eeddb5c0f57c69a0db31874b7b031ba06720bee
This change will propagate to BioC devel in the next couple of days.
Cheers,
H.
On 8/28/19 02:18, Bhagwat,
Hi developers,
Short story: these changes shouldn't affect you but I recommend you read
the long story just in case.
Long story:
Some of you maybe already noticed that I was making changes to the
DataFrame class. The idea is to "make room" for other data-frame-like
containers by having
Hi Jonathon,
Have you considered depending on Rhtslib? See
https://bioconductor.org/packages/Rhtslib
Rsamtools itself is implemented on top of Rhtslib. Note that other
Bioconductor packages (e.g. DiffBind, deepSNV, BitSeq, qrqc, QuasR,
seqbias, TransView, etc...) use Rhtslib internally to
bW0WYiZvSXAJJKaaPhzWA=dujEzslWeMIvlTaSOpEXKPSBhHSgfjJdT-5vXztzjNc=o36ekG8m2LTVHqFWfa1uu-vxfFxjblw1UE8I7Nm5fpc=
>>
>> Obviously not ideal, and really a workaround for limitations on the
>> Bioconductor side of the fence, but it would not result in two permanent
>> github repositor
.
>
> Zhezhen
> --------
> *From:* Pages, Herve
> *Sent:* Wednesday, August 21, 2019 7:47 PM
> *To:* Zhezhen Wang ; Martin Morgan
> ; Vincent Carey
> *Cc:* bioc-devel@r-project.org
> *Subject:* Re: [Bioc-d
Note that the name of the package (BioTIP) differs from the name of the
GitHub repo (NPS). They will need to match if you intend to submit to
Bioconductor. Thanks!
H.
On 8/20/19 09:20, Zhezhen Wang wrote:
> I see, thank you Martin!
> Zhezhen
>
> From: Martin
On 8/14/19 10:19, Kasper Daniel Hansen wrote:
...
>
> Pro-tip: In general, you will be well served not to get too attached to
> version numbers. Bump it frequently even without new functionality or bug
> fixes and just live with the frequent bumping.
+1 for Best Advice Of The Week.
--
Hervé
Hi Claudio,
As you can see on our build/check report, what is broken is 'R CMD
INSTALL Mulcom'. The problem is easy to reproduce:
hpages@spectre:~$ git clone
https://git.bioconductor.org/packages/MulcomCloning into 'Mulcom'...
remote: Enumerating objects: 570, done.
remote: Counting
This is a really important point.
Finding and updating serialized S4 instances that are lying around
as they evolve can be painful and very time-consuming.
We should definitely avoid storing serialized S4 objects on the Hub.
I don't know about ExperimentHub but at least for AnnotationHub I
Hi Simo,
Glad you were able to switch from install-time to run-time compilation.
The C++14 compiler box for tokay1 shows that this compiler is not
available on this machine. What you see below the box under "Compiler
version" is produced by some code that tries to detect the version
of the
Also please note that data experiment packages are on a different
report (and SBGNview.data is in it):
https://bioconductor.org/checkResults/3.10/data-experiment-LATEST/
As Lori said it can take a few build cycles before SBGNview.data gets
installed on all the build machines.
H.
On 6/25/19
Hi Jianhong,
We found that another software package has code in its examples that
is reinstalling org.Hs.eg.db, BSgenome.Hsapiens.UCSC.hg18, and
TxDb.Hsapiens.UCSC.hg18.knownGene. This causes problems in the context
of the nightly builds were many packages are checked simultaneously.
After a
Hi Paul,
After a long hunt, the software package causing these daily
reinstallations of BSgenome.Hsapiens.UCSC.hg38 has been
identified and his maintainer contacted.
Sorry for the inconvenience this has caused so far.
H.
On 6/24/19 12:31, Paul Shannon wrote:
> Warning in
ion data set, read those in.
>
> Thanks, will do that before next push to master.
>
> Best S
>
>
> On Fri, Jun 14, 2019 at 7:37 PM Pages, Herve <mailto:hpa...@fredhutch.org>> wrote:
>
> On 6/14/19 15:58, Shraddha Pai wrote:
> > Hi,
> &g
le by putting in line
> breaks in the "description" field, which caused the build to fail. My bad.
>
> Thank you for the feedback, I'm running the build on my machine to make
> sure there are no more trivial errors.
>
> Regards
> Shraddha
>
> On Fri, Jun 14,
1 - 100 of 174 matches
Mail list logo
