[Bioc-devel] Request to add maintainers for diffHic

Could Hannah and Gordon (in cc) be given push access to Bioc's diffHic repository? Note, this is in addition to my current push access, as I will be responsible for the large body of C++ code still in the package. Thanks, -A ___

Re: [Bioc-devel] Python module "tensorflow_probability" not found

Not hard to have OS-specific environments, see for example: https://github.com/alanocallaghan/snifter/blob/devel/R/basilisk.R -A On 7/6/23 20:23, Kasper Daniel Hansen wrote: This sounds excellent Kim! Here you can get 2.10 for Windows: https://anaconda.org/anaconda/tensorflow although my

[Bioc-devel] Updates to basilisk on BioC-devel

basilisk 1.9.6 on BioC-devel now uses an updated version of the Miniconda installer, in order to support the new Arm-based Macs. The update of the conda version is accompanied by a change in the default Python version, which is now 3.8 as opposed to 3.7. For developers of basilisk client

Re: [Bioc-devel] C++ parallel computing

Incidentally, I was reflecting on this topic the other day and was wondering whether BiocParallel could have something like OpenMPParam() that sets the number of threads to some non-zero value via omp_set_num_threads(). This would provide a consistent framework through which users could

Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and ExperimentHub

as long as I don't get an error. -A > ________ > From: Aaron Lun > Sent: Wednesday, April 7, 2021 11:41 AM > To: Kern, Lori > Cc: bioc-devel@r-project.org > Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and > ExperimentHub >

Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and ExperimentHub

prehensive Cancer Center > > Department of Biostatistics & Bioinformatics > > Elm & Carlton Streets > > Buffalo, New York 14263 > > ____ > From: Bioc-devel on behalf of Aaron Lun > > Sent: Wednesday, April 7, 2021 4:10 AM >

Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and ExperimentHub

rebook and basilisk are also currently using rappdirs. I would be interested in the motivation behind the switch for the Hubs and whether that is applicable to those two packages as well. -A On 4/5/21 6:41 AM, Kern, Lori wrote: We are in process of making some major updates to the caching in

[Rd] Feature request: adding a log.p= option to stats::p.adjust?

Dear list, Is there any interest in adding a log.p= option to p.adjust() so that it can accept log-transformed p-values and return log-transformed adjusted p-values? I have some functions that, on occasion, return very low p-values. To avoid underflow in such cases, I allow my users to set

[Bioc-devel] maintainer access to scater

For record-keeping purposes: We are transitioning maintainership of scater from myself to Alan O'Callaghan. Can Alan be given access to the scater BioC git repo? -A ___ Bioc-devel@r-project.org mailing list

[Bioc-devel] Migration of many scater utilities to scuttle

Dear list, scater's functions have now been split into two packages: the plotting functions stay in scater while many of the non-plotting utilities (QC, normalization, aggregation) move into the new scuttle package. This has been done to prune the dependency tree by removing

Re: [Bioc-devel] Reducing dependencies

We have recently extended our Bioconductor package tradeSeq to allow different input formats and accommodate extended downstream analyses, by building on other R/Bioconductor packages. I would guess that the problem starts

Re: [Bioc-devel] RcppAnnoy changed in CRAN from 0.0.14 to 0.0.15, and might have broken some packages

This is a minor RcppAnnoy issue that should be fixed soon, hopefully. Incidentally, this little episode has highlighted the advantages of Bioconductor's release/devel configuration. If the upstream dependency was a Bioc package, its updates are unlikely to break downstream packages in

Re: [Bioc-devel] Updates to SingleCellExperiment class structure - no action required

not written about it in your email. On Sun, Feb 16, 2020 at 3:51 AM Aaron Lun <mailto:infinite.monkeys.with.keyboa...@gmail.com>> wrote: Dear list, As of version 1.9.2, the SingleCellExperiment class structure has been updated so that "sizeFactors()<-" will store v

Re: [Bioc-devel] BiocManager not installing latest release version of DepecheR

ore 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

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

Re: [Bioc-devel] Is magrittr "%>%" acceptable in bioc packages?

Vince's answer gives the official position, to which I'll add my personal opinions for my little corner of the world. Every previous release, I had routine rounds of "depiping" where I go through any package that I'm heavily involved in and strip out any %>% calls. I think I've gotten the

Re: [Bioc-devel] Build error - C stack usage is too close to the limit

here. The S4 objects that land on the user space are > generally assembled on the user side from raw files downloaded from > the Hub. > > H. > > > On 8/2/19 02:58, Vincent Carey wrote: > > On Thu, Aug 1, 2019 at 10:36 PM Aaron Lun < > > infinite.monkeys.with.keyb

Re: [Bioc-devel] Build error - C stack usage is too close to the limit

One possibility is that this is due to a regression in SingleCellExperiment, caused by the altexp updates and other refactoring. This should be fixed in 1.7.3, you can check this for yourself by installing drisso/SingleCellExperiment off GitHub. The other moral of the story is to not use

[Bioc-devel] SingleCellExperiment refactoring

Dear list, We are planning to modify the SingleCellExperiment class to better accommodate alternative feature sets from CITE-seq and Perturb-seq experiments. A new "altExps" concept has been added to store experimental data for alternative feature sets as nested SummarizedExperiment

Re: [Bioc-devel] package test failing due to CSAW

This behavior has been deprecated since May 18 2018, looking at the Git logs here: https://github.com/LTLA/csaw/commits/master/R/scaledAverage.R I eventually got around to removing it last month, so the deprecation warning would have existed for 2 release cycles. That's fair game to me. The

[Bioc-devel] scRNAseq upgrade: give us your single-cell data!

We have recently repurposed the scRNAseq package to serve as a general location for any publicly available single-cell count data. The aim of this package is to provide convenient functions that directly yield nicely formatted SingleCellExperiment objects containing count matrices and relevant

Re: [Bioc-devel] InteractionSet for structural variants

answer that there's no such functionality implemented. Not to my knowledge... but if you're planning on writing some relevant functions, I'm sure we could find a home for it somewhere. -A El 5/18/19 a las 4:47 AM, Aaron Lun escribió: I would say that it depends on what operations you intend

Re: [Bioc-devel] InteractionSet for structural variants

I would say that it depends on what operations you intend to perform on them. You can _store_ things any way you like, but the trick is to ensure that operations and manipulations on those things are consistent and meaningful. It is not obvious that there are meaningful common operations that

Re: [Bioc-devel] SummarizedExperiments not equal after serialisation

I would say it's much worse than mismatching class definitions. https://github.com/Bioconductor/SummarizedExperiment/issues/16 -A On 5/11/19 5:07 AM, Martin Morgan wrote: I think it has to do with the use of reference classes in the assay slot, which have different environments se =

Re: [Bioc-devel] Weird monkey identifiers in org.Hs.eg.db

; this issue. > -- > *From:* Bioc-devel on behalf of Pages, > Herve > *Sent:* Thursday, April 25, 2019 9:19:35 PM > *To:* Aaron Lun; Vincent Carey > *Cc:* Bioc-devel; jmac...@u.washington.edu > *Subject:* Re: [Bioc-devel] Weird monkey identifiers in org.Hs.eg.db > >

[Bioc-devel] Weird monkey identifiers in org.Hs.eg.db

Playing around with org.Hs.eg.db 3.8.0. What on earth is ENSPTRG...? > library(org.Hs.eg.db) > mapIds(org.Hs.eg.db, key="GCG", keytype="SYMBOL", column="ENSEMBL") 'select()' returned 1:many mapping between keys and columns GCG "ENSPTRG777" Well, at least it still

Re: [Bioc-devel] Problem with non-portable compiler flags on package test

To contribute another data point on the use of architecture-specific compilation settings, see the discussion at: https://www.mail-archive.com/bioc-devel@r-project.org/msg10525.html This discrepancy took two months to track down. Two months! During my holidays! And it wasn't even my fault!

Re: [Bioc-devel] Call for collaborators/advice

ing method could also conceivably go here. https://github.com/ComputationalRegulatoryGenomicsICL/GenomicInteractions/issues/37 All of this is open for discussion, if people are interested and willing to volunteer. These changes will not make the next release anyway. What he said. -A On 22/03/2019 19:54, Aaron Lun wrote: Hi

Re: [Bioc-devel] package RBGL requires CRAN dependency on devel branch

considering. For example, it would be pretty cool to just supply a date and BiocManager could figure out the last successful release versions of all CRAN/BioC packages at that time. -A On Tue, Mar 26, 2019 at 12:45 AM Aaron Lun <mailto:infinite.monkeys.with.keyboa...@gmail.com>> wrote:

Re: [Bioc-devel] package RBGL requires CRAN dependency on devel branch

My 2 cents - API-breaking changes to BH are no more of an issue than breaking changes to any other CRAN package. We just hope that it doesn't happen too often and we deal with it when the time comes; that's the whole point of getting frequent release builds to check for these cases. If we

Re: [Bioc-devel] Call for collaborators/advice

hods for specialized data analysis would need to go into another package for (4). I don't have a good definition of what is specialized; but if there's statistical inference, it shouldn't be in (2). All of this is open for discussion, if people are interested and willing to volunteer. These chang

Re: [Bioc-devel] Call for collaborators/advice

Hi Luke, Do you mean bins or bin pairs? If you want to just bin the coverage in terms of the linear genome, there should be ways to do that outside of InteractionSet or GenomicInteractions. This is just dealing with standard genomic interval data; extract the anchor coordinates and plug it

Re: [Bioc-devel] set.seed and BiocParallel

I think Kylie is saying that she wants to use the same seed for each feature across different runs, but the seed can be different across features - which would make more sense. Multi-worker reproducibility is an issue that we discussed before (the link goes into the middle of the thread):

Re: [Bioc-devel] Merging GInteraction/GenomicInteractions ranges

step of the recursion, you pass the identity of the parent interaction and record it for each new child interaction that is generated. -A > On Feb 13, 2019, at 3:34 AM, Aaron Lun > a...@gmail.com> wrote: > > > > Note that your visual won't show up for many (all?) of us. > &g

Re: [Bioc-devel] Merging GInteraction/GenomicInteractions ranges

Note that your visual won't show up for many (all?) of us. Nonetheless, I think I know what you want to do. Your task does not lend itself to vectorization, which makes it difficult to write efficient R code. It's not impossible, but it would be quite hard to read and debug, and your maintenance

Re: [Bioc-devel] Pushing towards a better home for matrix generics

, signature="x") >> >> > >  >> setGeneric("colMeans", signature="x") > >  >> >> >> > >  >> >> >> The only reason for having these definitions in >> > >  >>

[Bioc-devel] Pushing towards a better home for matrix generics

This is a resurrection of some old threads: https://stat.ethz.ch/pipermail/bioc-devel/2017-November/012273.html https://github.com/Bioconductor/MatrixGenerics/issues For those who are unfamiliar with this, the basic issue is that various Matrix and BiocGenerics functions mask each other. This

Re: [Bioc-devel] Plans for multi-feature SingleCellExperiment?

For 10X experiments, the Bioc-devel version of DropletUtils will read in the additional features as extra rows in the count matrix. This reflects how they are stored in the 10X output format. The row metadata will record the nature of the feature. In some cases it may be desirable to keep all the

Re: [Bioc-devel] What is good convention for package-local BiocParallel param?

icoreParam(stop.on.error=FALSE)) > > data %>% > apply_methods(method_list1) %>% > apply_methods(method_list2) %>% > apply_methods(method_list3) > > Which I guess is the point of this mail chain. Is there a reason why I > shouldn’t? Can’t hurt to have fewer global

Re: [Bioc-devel] What is good convention for package-local BiocParallel param?

My current set-up in a variety of packages is that every parallelizable function has a BPPARAM= argument. This makes it explicit about which steps are being parallelized. Requiring users to respecify BPPARAM= in each function isn’t as annoying as you’d think, because not many steps are actually

Re: [Bioc-devel] Using SerialParam() as the registered back-end for all platforms

> time. I believe there's room for automating this in one way or the >> other. For instance, having a way to declare a function being >> dependent on RNG or not could help. Static code inspection could also >> do it, e.g. when an R package is built and it could be part of

Re: [Bioc-devel] Controlling vignette compilation order

in separate processes the default >> >> from R-devel suggests that stand-alone vignettes are now necessary. >> >> Martin >> >> On 12/24/18, 3:02 AM, "Bioc-devel on behalf of Aaron Lun" >> > infinite.monkeys.with.keyboa...@gmail.com> wrote:

Re: [Bioc-devel] Using SerialParam() as the registered back-end for all platforms

be re-used? > > On Mon, Jan 7, 2019 at 9:37 AM Aaron Lun > <mailto:infinite.monkeys.with.keyboa...@gmail.com>> wrote: > > I hope for 1. to have a 'local socket' (i.e., not using ports) > > implementation shortly. > > Yes, that would be helpful. > &g

Re: [Bioc-devel] Using SerialParam() as the registered back-end for all platforms

of my parallelized functions, though I don’t know how much this will solve the time problem. Perhaps I should just do it and see. -A > On 1/6/19, 11:16 PM, "Bioc-devel on behalf of Aaron Lun" > infinite.monkeys.with.keyboa...@gmail.com> wrote: > >As we know, the

[Bioc-devel] Using SerialParam() as the registered back-end for all platforms

As we know, the default BiocParallel backends are currently set to MulticoreParam (Linux/Mac) or SnowParam (Windows). I can understand this to some extent because a new user running, say, bplapply() without additional arguments or set-up would expect some kind of parallelization. However, from

Re: [Bioc-devel] Controlling vignette compilation order

arate processes the default > > from R-devel suggests that stand-alone vignettes are now necessary. > > Martin > > On 12/24/18, 3:02 AM, "Bioc-devel on behalf of Aaron Lun" > infinite.monkeys.with.keyboa...@gmail.com> wrote: > >A working example of knit

Re: [Bioc-devel] how to achieve reproducibility with BiocParallel regardless of number of threads and OS (set.seed is disallowed)

I’ll also back-track a bit from my advice in the original support site posting, as it turns out C++11’s is not guaranteed to be reproducible across platforms. That is to say, the RNG engines are portably defined across implementations, but the distribution classes (that convert the random

Re: [Bioc-devel] Controlling vignette compilation order

stream vignette does not generate a cache that is recognized when BUILD goes onto compile the upstream vignette. -A > On 23 Dec 2018, at 01:24, Aaron Lun > wrote: > > Yes, I had noticed the vignettes.rds as well, and I figured that would be a > problem. > > I just t

Re: [Bioc-devel] Controlling vignette compilation order

-hoc, not-so-nice hack that OP could do is to have > a single main vignette that produces and links to all child vignettes. > However, personally, I'd aim for using memoization/caching (to file) > such that each vignette can be compiled independently of the others > (and in any order), whi

Re: [Bioc-devel] Controlling vignette compilation order

uot;Bioc-devel on behalf of Michael Lawrence" > > wrote: > >Anything that eventually lands in inst/doc is a vignette, I think, so >there might be a hack around that. > >On Fri, Dec 21, 2018 at 11:26 PM Aaron Lun > wrote: >> >> I gave i

Re: [Bioc-devel] Compilation flags, CHECK errors and BiocNeighbors

why the Makeconf is not being respected on tokay2. I can >> confirm the inconsistency in an R session - >> >> tokay2: >> >> PS C:\Users\biocbuild\bbs-3.9-bioc\R> ./bin/R CMD config CXX11FLAGS >> -O3 -march=native -mtune=native >> >> to

Re: [Bioc-devel] New ExperimentHub resource and some related questions

I presume your package is not actually called “SingleCell” (in point 1). This would be pretty confusing wjem compared to the simpleSingleCell package, the SingleCellExperiment package, and the SingleCell biocViews term itself. It would probably make more sense to call it BUStoolsR or some other

Re: [Bioc-devel] Controlling vignette compilation order

ve the code generating those shared >resources to the package. They could behave lazily, only generating the >resource if necessary, otherwise reusing it. That would also make it easy >for people to write their own documents using those resources. >

[Bioc-devel] Controlling vignette compilation order

In a number of my workflow packages (e.g., simpleSingleCell), I rely on a specific compilation order for my vignettes. This is because some vignettes set up resources or objects that are to be used by later vignettes. >From what I understand, vignettes are compiled in alphanumeric ordering of

Re: [Bioc-devel] Compilation flags, CHECK errors and BiocNeighbors

ocNeighbors. We don't use 'native' on the builders for build/check or > for creating binaries. > > Herve might have more insight on this. > > Val > > > > > > > > On 12/15/18 10:56 PM, Aaron Lun wrote: >> Sometime between 6-18 November, BiocNeighbors� BioC-dev

[Bioc-devel] Compilation flags, CHECK errors and BiocNeighbors

Sometime between 6-18 November, BiocNeighbors’ BioC-devel builds began failing on Windows 64-bit, and have continued to fail since: http://bioconductor.org/checkResults/devel/bioc-LATEST/BiocNeighbors/ The most interesting

Re: [Bioc-devel] BiocInstaller: next generation

This all sounds pretty reasonable to me. The ability to choose the version in install() is nice, especially if we can easily flip between versions in different install locations. I presume that version="release" will be the default? As for the names - BiocManager seems the most sober of the lot.

Re: [Bioc-devel] problem with class definitions between S4Vectors and RNeXML in using Summarized Experiment

Well, it's not really SingleCellExperiment's problem, either. library(S4Vectors) DataFrame(1:5) # Silent, okay. library(RNeXML) DataFrame(1:5) # Prints out the message ## Found more than one class "Annotated" in cache; using the first,  from namespace 'S4Vectors' ## Also defined by ‘RNeXML’

Re: [Bioc-devel] Workflows are now in git (and other Important workflow-related changes)

nformatics > Elm & Carlton Streets > Buffalo, New York 14263 > From: Bioc-devel <bioc-devel-boun...@r-project.org> on behalf of > Aaron Lun <a...@wehi.edu.au> > Sent: Sunday, April 1, 2018 2:17:09 PM > To: Hervé Pagès; bioc-devel@r-project.org > Subject: Re:

Re: [Bioc-devel] Workflows are now in git (and other Important workflow-related changes)

Thanks everybody, this is much appreciated. On that note, will the compiled workflows shown at: https://www.bioconductor.org/help/workflows/ ... be updated to reflect changes in the git repositories for the workflows?  Or will the workflow page just directly link to the landing page for each

Re: [Bioc-devel] R version check in BiocChech

biocLite() ensure that the user is doing things properly; and if they follow the rules, any bugs are therefore the fault of my package. If the users don't follow the rules, they're on their own - but at least they know what the rules are, because it's pretty inconvenient to break them. Cheers, Aaron

Re: [Bioc-devel] R version check in BiocChech

I'll just throw in my two cents here. I think many people underappreciate the benefits of moving to the latest version of R. If you inspect the R-devel NEWS file, there's a couple of nice fixes/features that a developer might want to take advantage of: - sum() doesn't give NAs upon integer

[Bioc-devel] Alpha release of the iSEE visualization tool

Dear list, At the European Bioconductor Meeting in December 2017, a group of us decided to develop a common interface for interactive visualization of single-cell ‘omics data. Two months (and over 500 commits) later, we are proud to present the alpha release of iSEE, a package for interactive

Re: [Bioc-devel] Changes to rhdf5

Great work Mike; looking forward to it on BioC-devel. When are persistently open file handles generated? All the time, or on specific uses of the upper-case H5 functions? I ask because I recall that the HDF5 library permits multiple open file handles, but it throws an error if the access flags

Re: [Bioc-devel] workflow page reorganization

ement (which just went online). I've also > included an index at the beginning of the page. > > Any refinements are of course welcome, e.g. via PR to > https://github.com/Bioconductor/bioconductor.org > > Cheers, > Andrzej > > > On Fri, Dec 15, 2017 at 2:08 P

Re: [Bioc-devel] workflow page reorganization

My proposed categories reflect my vested interests, but here goes: - Gene expression: - rnaseqGene - RNAseq123 - ExpressionNormalizationWorkflow - RnaSeqGeneEdgeRQL - Epigenomics: (not quite sure what to call this) - chipseqDB - methylationArrayAnalysis -

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

e, Dec 12, 2017 at 9:49 PM, Aaron Lun <a...@wehi.edu.au > <mailto:a...@wehi.edu.au>> wrote: > > Thanks Andrzej. > > > Thank you. I've edited the workflow index page by introducing a separate > > "Single-cell Workflows" section, and by sub

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

be a bit lonely for a while (I am planning to split that into two workflows later). Cheers, Aaron > On Tue, Dec 12, 2017 at 7:19 PM, Aaron Lun <aaron@cruk.cam.ac.uk> wrote: > >> The split-up workflows seem to have built successfully: >> >> http://docbuilder.bioconduc

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

inally, could we get a separate "single-cell workflows" section? The current "Basic/Advanced" partition is pretty crude, and I can see opportunities for more detailed stratification, e.g., by ChIP-seq, RNA-seq, single-cell RNA-seq, proteomics (including mass cytometry). Cheer

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

etty crude, and I can see opportunities for more detailed stratification, e.g., by ChIP-seq, RNA-seq, single-cell RNA-seq, proteomics (including mass cytometry). Cheers, Aaron On 11/12/17 20:24, Aaron Lun wrote: > Thanks Val: > > Obenchain, Valerie wrote: >> Hi, >> >&g

Re: [Bioc-devel] splitting simpleSingleCell into self-contained vignettes

Thanks Val: Obenchain, Valerie wrote: > Hi, > > On 12/11/2017 08:49 AM, Aaron Lun wrote: >> Following up on our earlier discussion: >> >> https://stat.ethz.ch/pipermail/bioc-devel/2017-October/011949.html >> >> I have split the simpleSingleCell workfl

[Bioc-devel] splitting simpleSingleCell into self-contained vignettes

Following up on our earlier discussion: https://stat.ethz.ch/pipermail/bioc-devel/2017-October/011949.html I have split the simpleSingleCell workflow into three (four, if you include the introductory overview) self-contained Rmarkdown files. I am preparing them for submission to BioC's

Re: [Bioc-devel] possible bug in Rhtslib::pkgconfig

ds for "in re" in Latin. I guess I learn something new every day. Martin Morgan wrote: > Thanks Aaron I'll follow up on the support site. > > Can you clarify where the 'Re:' came from in the title? I can't find a > previous post with similar title. > > Martin >

Re: [Bioc-devel] clarification of the BiocParallel vignette for SnowParam() usage

Dear list; Currently the vignette for the BiocParallel package states that the functions to be executed should contain the necessary library() calls if bplapply is used with SnowParam(). Now, I use bplapply in several of my packages with internal helper/wrapper functions, and that piece of

Re: [Bioc-devel] library() calls removed in simpleSingleCell workflow

<valerie.obench...@roswellpark.org> Sent: Friday, 6 October 2017 6:36:44 AM To: Aaron Lun; Wolfgang Huber; bioc-devel@r-project.org Subject: Re: [Bioc-devel] library() calls removed in simpleSingleCell workflow Glad this sparked some interesting dialogue! Regardless of what's decided, this change

Re: [Bioc-devel] library() calls removed in simpleSingleCell workflow

could call it "1-start.Rmd", "2-next.Rmd", "3-final.Rmd" and so on. -Aaron From: Wolfgang Huber <wolfgang.hu...@embl.de> Sent: Friday, 6 October 2017 5:22:44 AM To: Aaron Lun; Laurent Gatto Cc: bioc-devel@r-project.org Subje

Re: [Bioc-devel] library() calls removed in simpleSingleCell workflow

they be directed to execute in a specific order, and would output files from one vignette persist during the execution of another? -Aaron From: Wolfgang Huber <wolfgang.hu...@embl.de> Sent: Thursday, 5 October 2017 6:23:47 PM To: Laurent Gatto; Aaron Lun Cc

Re: [Bioc-devel] library() calls removed in simpleSingleCell workflow

ng software, experimental data and workflows and resources >> aren't unlimited. When that time comes we'll update the workflow guidelines >> and contact maintainers. >> >> Thanks. >> Valerie >> >> >> >> On 10/04/2017 12:27 PM, Kasper Daniel Hanse

Re: [Bioc-devel] library() calls removed in simpleSingleCell workflow

Dear Nitesh, list; The library() calls in the simpleSingleCell workflow have been removed. Why is this? I find explicit library() calls to be quite useful for readers of the compiled vignette, because it makes it easier for them to determine the packages that are required to adapt parts of

Re: [Bioc-devel] [Untrusted Server]Re: [Untrusted Server]Re: strange error in Jenkins build forsingleCellWorkflow

Thanks Martin. Looks like it's building happily now, which gives us some breathing space. -Aaron From: Martin Morgan <martin.mor...@roswellpark.org> Sent: Tuesday, 26 September 2017 6:05:22 PM To: Aaron Lun; Herv� Pag�s; bioc-devel@r-project.org Subje

Re: [Bioc-devel] [Untrusted Server]Re: [Untrusted Server]Re: strange error in Jenkins build forsingleCellWorkflow

? -Aaron From: Herv� Pag�s <hpa...@fredhutch.org> Sent: Thursday, 21 September 2017 3:06:18 PM To: Aaron Lun; Martin Morgan; bioc-devel@r-project.org Subject: Re: [Bioc-devel] [Untrusted Server]Re: [Untrusted Server]Re: strange error in Jenkins

Re: [Bioc-devel] assay dimnames in SingleCellExperiment / SummarizedExperiment

something else. -Aaron From: Herv� Pag�s <hpa...@fredhutch.org> Sent: Saturday, 23 September 2017 8:47:14 AM To: Kevin RUE; Aaron Lun Cc: bioc-devel; da...@ebi.ac.uk; risso.dav...@gmail.com; Maintainer Subject: Re: assay dimnames in SingleCellExperiment

Re: [Bioc-devel] [Untrusted Server]Re: [Untrusted Server]Re: strange error in Jenkins build forsingleCellWorkflow

gt; Martin >> >>> Better yet would anyone know of code that would allow unused DLL to >>> be identified and unloaded? I suspect not as it would require keeping >>> track of the dependency tree of your current environment but I�m >>> hopeful

Re: [Bioc-devel] [Untrusted Server]Re: [Untrusted Server]Re: strange error in Jenkins build forsingleCellWorkflow

d maybe more) should not be unloaded, as they can't be properly loaded again in the same session. -Aaron From: Shian Su Sent: Tuesday, 19 September 2017 12:42:47 PM To: Aaron Lun Cc: Vincent Carey; bioc-devel@r-project.org Subject: Re: [Untrusted Server]Re: [Bioc-devel

Re: [Bioc-devel] [Untrusted Server]Re: strange error in Jenkins build forsingleCellWorkflow

to modules that can be independently installed. -Aaron From: Vincent Carey <st...@channing.harvard.edu> Sent: Saturday, 16 September 2017 10:08:13 PM To: Aaron Lun Cc: Martin Morgan; bioc-devel@r-project.org Subject: Re: [Bioc-devel] [Untrusted Server]R

Re: [Bioc-devel] [Untrusted Server]Re: strange error in Jenkins build forsingleCellWorkflow

tember 2017 8:18:09 PM To: Aaron Lun; bioc-devel@r-project.org Subject: Re: [Bioc-devel] [Untrusted Server]Re: strange error in Jenkins build forsingleCellWorkflow On 09/16/2017 01:53 AM, Aaron Lun wrote: > Bumping this rather old thread. To re-iterate, I'm updating my > simpleSingleCell work

Re: [Bioc-devel] [Untrusted Server]Re: strange error in Jenkins build forsingleCellWorkflow

behalf of Aaron Lun <a...@wehi.edu.au> Sent: Wednesday, 21 June 2017 12:09:13 AM To: bioc-devel@r-project.org Subject: [Untrusted Server]Re: [Bioc-devel] strange error in Jenkins build forsingleCellWorkflow Hi all, I'm getting a curious error in the Jenkins log when I

Re: [Bioc-devel] assay dimnames in SingleCellExperiment / SummarizedExperiment

ng genomic features.) -Aaron From: Kevin RUE <kevinru...@gmail.com> Sent: Thursday, 14 September 2017 10:57:39 PM To: bioc-devel Cc: da...@ebi.ac.uk; risso.dav...@gmail.com; Aaron Lun; Maintainer Subject: assay dimnames in SingleCellExperiment / SummarizedExperiment Dear al

Re: [Bioc-devel] BiocStyle not acknowledging fig.wide=TRUE in knitr

;style-knitr, eval=TRUE, echo=FALSE, results="asis">>= BiocStyle::latex() @ \bioctitle[Test]{Testing} %% also: \bioctitle{Title used for both header and title page} %% or... \title{Title used for both header and title page} \author{Aaron Lun} \begin{document} \maketi

Re: [Bioc-devel] cbind for DataFrame no longer behaving as expected

Thanks Michael. Also for the Github tip. -Aaron From: Michael Lawrence <lawrence.mich...@gene.com> Sent: Saturday, 9 September 2017 1:41:24 AM To: Aaron Lun Cc: bioc-devel@r-project.org Subject: Re: [Bioc-devel] cbind for DataFrame no longer behaving as ex

Re: [Bioc-devel] cbind for DataFrame no longer behaving as expected

Dear list, It seems that an alteration to the cbind method for DataFrame objects in S4Vectors (probably d595a19b19df9b9c9aaef71e9c1cd1bdc681bfb1) has led to some strange behaviour. In particular, if I run this code with S4Vectors 0.15.7, I get the following output: require(S4Vectors)

Re: [Bioc-devel] transitioning scater/scran to SingleCellExperiment

> I guess this would be a question for the > SummarizedExperiment developers, though personally, I never liked > ExpressionSet's inclination to slap names on everything. > > Too bad we’re bound to SummarizedExperiment’s “rows” and “cols”. Since > they always refer to features and

Re: [Bioc-devel] transitioning scater/scran to SingleCellExperiment

and methods, best to keep them separate rather than stuffing them into the SCE object. Our vision for the SCE class is to coordinate inputs into many packages across a long, long workflow. A little detour into destiny's classes for a small portion of the workflow doesn't pose much trouble, as

Re: [Bioc-devel] improving navigation within workflows

ri, Aug 4, 2017 at 5:01 PM, Vincent Carey > <st...@channing.harvard.edu <mailto:st...@channing.harvard.edu>> wrote: > > interesting. is the floating toc not an option for this? also, > IMHO the "about this document" should go at the end. one wants > t

Re: [Bioc-devel] improving navigation within workflows

e devel mailing list. > > Cheers, > Andrzej > > > On Mon, Jul 17, 2017 at 10:15 AM, Aaron Lun <a...@wehi.edu.au > <mailto:a...@wehi.edu.au>> wrote: > > Hi Andrzej, > > Interesting. I also didn't realize that we could get figure referencing > vi

Re: [Bioc-devel] transitioning scater/scran to SingleCellExperiment

Dear developers, Both scater and scran will be migrating to the SingleCellExperiment class (https://bioconductor.org/packages/SingleCellExperiment) in the next BioC release. This is based on a SummarizedExperiment and provides a more modern user interface, as well as supporting different matrix

Re: [Bioc-devel] improving navigation within workflows

vely easily inserted automatically after each section. Static > CRAN-like solution as you mentioned it would probably require some more > work. > > Cheers, > Andrzej > > On Sun, Jul 16, 2017 at 9:36 PM, Aaron Lun <a...@wehi.edu.au > <mailto:a...@wehi.edu.au>

Re: [Bioc-devel] improving navigation within workflows

ike this? > > http://bioconductor.org/packages/release/bioc/vignettes/BiocStyle/inst/doc/AuthoringRmdVignettes.html > > On Sun, Jul 16, 2017 at 11:53 AM, Aaron Lun <a...@wehi.edu.au > <mailto:a...@wehi.edu.au>> wrote: > > Hello all, > > I was wondering if t

Re: [Bioc-devel] improving navigation within workflows

Hello all, I was wondering if there's any plans to improve the navigation for the BioC workflows. I was looking at my simpleSingleCell workflow: https://www.bioconductor.org/help/workflows/simpleSingleCell/ ... and I've realized that it's gotten pretty long. It's a pain to keep on scrolling

Re: [Bioc-devel] strange error in Jenkins build for singleCellWorkflow

Hi all, I'm getting a curious error in the Jenkins log when I try to build the singleCellWorkflow: http://docbuilder.bioconductor.org:8080/job/simpleSingleCell/48/label=master/console The key part is at the bottom: Error: package or namespace load failed for 'GenomicFeatures' in

  1   2   >