[prev in list] [next in list] [prev in thread] [next in thread]
List: bioc-devel
Subject: Re: [Bioc-devel] Controlling vignette compilation order
From: Aaron Lun <infinite.monkeys.with.keyboards () gmail ! com>
Date: 2019-01-08 1:36:12
Message-ID: CFFA88AF-9F8E-4FCC-A4B1-B6A28C2FBF8D () gmail ! com
[Download RAW message or body]
Agreed. And the BioC build system doesn't even CHECK workflow packages, so r75944 \
actually wouldn't have an effect at all.
P.S. simpleSingleCell has successfully built on the BioC-devel with my custom \
inter-vignette compilation set-up, so that's a relief.
> On 7 Jan 2019, at 20:13, Pages, Herve <hpages@fredhutch.org> wrote:
>
> This changes the default for _R_CHECK_BUILD_VIGNETTES_SEPARATELY_ from
> false to true so only affects the re-built of the vignettes during 'R
> CMD check'. While this is a step in the right direction, it would be
> good if 'R CMD build' was modified accordingly i.e. to also build
> vignettes in separate processes. With the current inconsistency, there
> will be situations where 'R CMD check' will fail to re-build vignettes
> that were just built by 'R CMD build'. Also, even though 'R CMD check'
> now avoids the MAX_DLL problem, it is not that useful if 'R CMD build'
> still has the problem and fails to build the package in the 1st place.
>
> H.
>
> On 1/2/19 17:01, Martin Morgan wrote:
> > r75944 | ripley | 2019-01-02 03:37:21 -0500 (Wed, 02 Jan 2019) | 1 line
> >
> > making re-building vignettes 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" \
> > <bioc-devel-bounces@r-project.org on behalf of \
> > infinite.monkeys.with.keyboards@gmail.com> wrote:
> > A working example of knitr caching across workflows is now available at \
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LTLA_BiocWorkCache \
> > &d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m \
> > =tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=V9MlctgPkBOJTskConkT6RZN0e90QCM0HaLDnWYFCT4&e= \
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LTLA_BiocWorkCach \
> > e&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA& \
> > m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=V9MlctgPkBOJTskConkT6RZN0e90QCM0HaLDnWYFCT4&e=>.
> >
> > It uses "~/chipseq.log" as a log to demonstrate that the code in the \
> > most-upstream workflow ("test1.Rmd") is indeed only executed once during the \
> > BUILD.
> > Note that the compilation of upstream vignettes involves a system call out to a \
> > separate R session. This avoids some difficult issues with caching when a Rmd \
> > file is compiled from within another Rmd file - trying to use rmarkdown::render() \
> > on the upstream vignette within a downstream 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 <infinite.monkeys.with.keyboards@gmail.com> \
> > > wrote:
> > > Yes, I had noticed the vignettes.rds as well, and I figured that would be a \
> > > problem.
> > > I just tried setting set cache=TRUE in my vignettes, implemented such that \
> > > BUILDing each downstream vignette will also run all upstream vignettes on which \
> > > it depends (that haven't already been compiled). If an upstream vignette is run \
> > > in this manner, it caches the results of each code chunk to avoid repeated work \
> > > when it gets compiled "for real" by R CMD BUILD.
> > > This seems to work on initial inspection (the caches are produced for the \
> > > upstream vignettes upon running one downstream vignette). I'll have to check \
> > > whether this plays nice with R CMD BUILD. I will probably have to write a \
> > > function to isolate the scope of the execution of each upstream vignette, to \
> > > avoid polluting the namespace and cache of each downstream vignette.
> > > -A
> > >
> > > > On 22 Dec 2018, at 19:22, Henrik Bengtsson <henrik.bengtsson@gmail.com \
> > > > <mailto:henrik.bengtsson@gmail.com>> wrote:
> > > > On Sat, Dec 22, 2018 at 10:56 AM Michael Lawrence
> > > > <lawrence.michael@gene.com <mailto:lawrence.michael@gene.com>> wrote:
> > > > >
> > > > > Anything that eventually lands in inst/doc is a vignette, I think, so
> > > > > there might be a hack around that.
> > > >
> > > > Just so this is not misread - it's *not* possible to just hack your
> > > > vignette "product" files (PDF or HTML) into inst/doc and thinking
> > > > you're good. R keeps track of package vignettes in a "vignette
> > > > index", e.g.
> > > >
> > > > > readRDS(system.file(package = "utils", "Meta", "vignette.rds"))
> > > > File Title PDF R Depends Keywords
> > > > 1 Sweave.Rnw Sweave User Manual Sweave.pdf Sweave.R tools
> > > >
> > > > which is created during 'R CMD build' by parsing and compiling the
> > > > vignettes (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wch \
> > > > _r-2Dsource_blob_tags_R-2D3-2D5-2D2_src_library_tools_R_build.R-23L283-2DL393& \
> > > > d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzW \
> > > > A&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=pGRkfgITPNQtVlkZ0EZOvUzipheqrkKGgwld3Z-GB7Q&e= \
> > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wch_r-2Dsourc \
> > > > e_blob_tags_R-2D3-2D5-2D2_src_library_tools_R_build.R-23L283-2DL393&d=DwIGaQ&c \
> > > > =eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz \
> > > > 75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=pGRkfgITPNQtVlkZ0EZOvUzipheqrkKGgwld3Z-GB7Q&e=>).
> > > > This vignette index is used to find package vignettes (e.g.
> > > > utils::vignette()) and build the HTML vignette index.
> > > >
> > > > Also, one vignette source (e.g. Rnw, Rmd, ...) can only produce one
> > > > vignette product (PDF or HTML) in the vignette index. You can output
> > > > other files (e.g. image files) in a relative folder that the vignette
> > > > references, which is why for instance non-self-contained HTML files
> > > > work. Thus, one ad-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), while still reusing intermediate
> > > > results/calculations produced by earlier vignettes.
> > > >
> > > > /Henrik
> > > >
> > > > >
> > > > > On Fri, Dec 21, 2018 at 11:26 PM Aaron Lun
> > > > > <infinite.monkeys.with.keyboards@gmail.com \
> > > > > <mailto:infinite.monkeys.with.keyboards@gmail.com>> wrote:
> > > > > >
> > > > > > I gave it a shot:
> > > > > >
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LTLA_Drake \
> > > > > > Test&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXA \
> > > > > > JJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=t8yGzyETagAjWm0eTqZSWYQIeUY8aARqRvwCQheuwdk&e= \
> > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LTLA_Drak \
> > > > > > eTest&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSX \
> > > > > > AJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=t8yGzyETagAjWm0eTqZSWYQIeUY8aARqRvwCQheuwdk&e=> \
> > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LTLA_Drak \
> > > > > > eTest&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSX \
> > > > > > AJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=t8yGzyETagAjWm0eTqZSWYQIeUY8aARqRvwCQheuwdk&e= \
> > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LTLA_Drak \
> > > > > > eTest&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSX \
> > > > > > AJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=t8yGzyETagAjWm0eTqZSWYQIeUY8aARqRvwCQheuwdk&e=>>
> > > > > >
> > > > > > This uses a single "controller" Rmd file to trigger Drake::make. Running \
> > > > > > this file will instruct Drake to compile all of the other vignettes \
> > > > > > following the desired dependency structure.
> > > > > > The current sticking point is that I need to move the Drake-controlled \
> > > > > > Rmd files out of "vignettes/", otherwise they'll just be compiled as \
> > > > > > usual without consideration of their dependencies. This causes problems \
> > > > > > as R CMD BUILD only recognizes the controller Rmd file as the sole \
> > > > > > vignette, and doesn't retain or index the HTML files produced from the \
> > > > > > other Rmd files as side-effects of running the controller.
> > > > > > Are there any better ways to subvert the vignette building procedure to \
> > > > > > get the desired effect of running drake::make() and recognition of the \
> > > > > > resulting HTMLs as vignettes?
> > > > > > -A
> > > > > >
> > > > > > > On 18 Dec 2018, at 17:41, Michael Lawrence <lawrence.michael@gene.com \
> > > > > > > <mailto:lawrence.michael@gene.com>> wrote:
> > > > > > > Sounds like a use case for drake...
> > > > > > >
> > > > > > > On Tue, Dec 18, 2018 at 6:58 AM Aaron Lun \
> > > > > > > <infinite.monkeys.with.keyboards@gmail.com \
> > > > > > > <mailto:infinite.monkeys.with.keyboards@gmail.com> \
> > > > > > > <mailto:infinite.monkeys.with.keyboards@gmail.com \
> > > > > > > <mailto:infinite.monkeys.with.keyboards@gmail.com>>> wrote: @Michael In \
> > > > > > > this case, the resource produced by vignette X is a \
> > > > > > > SingleCellExperiment object containing the results of various \
> > > > > > > processing steps (normalization, clustering, etc.) described in that \
> > > > > > > vignette.
> > > > > > > I can imagine a lazy evaluation model for this, but it wouldn't be \
> > > > > > > pretty. If I had another vignette Y that depended on the SCE produced \
> > > > > > > by vignette X, I would need Y to execute all of the steps in X if X \
> > > > > > > hadn't already been run before Y. This gets us into the territory of \
> > > > > > > Makefile-like dependencies, which seems even more complicated than \
> > > > > > > simply specifying a compilation order.
> > > > > > > You might ask why X and Y are split into two separate vignettes. The \
> > > > > > > use of different vignettes is motivated by the complexity of the \
> > > > > > > workflows:
> > > > > > > - Vignette 1 demonstrates core processing steps for one read-based \
> > > > > > > single-cell RNAseq dataset.
> > > > > > > - Vignette 2 demonstrates (slightly different) core steps for a \
> > > > > > > UMI-based dataset.
> > > > > > > - … so on for a bunch of other core steps for different types of \
> > > > > > > data.
> > > > > > > - Vignette 6 demonstrates extra optional steps for the two SCEs \
> > > > > > > produced by vignettes 1 & 3.
> > > > > > > - … and so on for a bunch of other optional steps.
> > > > > > >
> > > > > > > The separation between core and optional steps into separate documents \
> > > > > > > is desirable. From a pedagogical perspective, I would very much like to \
> > > > > > > get the reader through all the core steps before even considering the \
> > > > > > > extra steps, which would just be confusing if presented so early on. \
> > > > > > > Previously, everything was in a single document, which was difficult to \
> > > > > > > read (for users) and to debug (for me), especially because I had to use \
> > > > > > > contrived variable names to avoid clashes between different sections of \
> > > > > > > the workflow that did similar things.
> > > > > > > @Martin I've been using BiocFileCache for all of the online resources \
> > > > > > > that are used in the workflow. However, this is only for my (and the \
> > > > > > > reader's) convenience. I use a local cache rather than the system \
> > > > > > > default, to ensure that the downloaded files are removed after package \
> > > > > > > build. This is intentional as it forces the package builder to try to \
> > > > > > > re-download resources when compiling the vignette, thus ensuring the \
> > > > > > > validity of the URLs. For a similar reason, I would prefer not to cache \
> > > > > > > the result objects for use in different R sessions. I could imagine \
> > > > > > > caching the result objects for use by a different vignette in the same \
> > > > > > > build session, but this gets back to the problem of ensuring that the \
> > > > > > > result object is generated by one vignette before it is needed by \
> > > > > > > another vignette.
> > > > > > > -A
> > > > > > >
> > > > > > > > On 18 Dec 2018, at 14:14, Martin Morgan <mtmorgan.bioc@gmail.com \
> > > > > > > > <mailto:mtmorgan.bioc@gmail.com> <mailto:mtmorgan.bioc@gmail.com \
> > > > > > > > <mailto:mtmorgan.bioc@gmail.com>>> wrote:
> > > > > > > > Also perhaps using BiocFileCache so that the result object is only \
> > > > > > > > generated once, then cached for future (different session) use.
> > > > > > > > On 12/18/18, 8:35 AM, "Bioc-devel on behalf of Michael Lawrence" \
> > > > > > > > <bioc-devel-bounces@r-project.org \
> > > > > > > > <mailto:bioc-devel-bounces@r-project.org> \
> > > > > > > > <mailto:bioc-devel-bounces@r-project.org \
> > > > > > > > <mailto:bioc-devel-bounces@r-project.org>> on behalf of \
> > > > > > > > lawrence.michael@gene.com <mailto:lawrence.michael@gene.com> \
> > > > > > > > <mailto:lawrence.michael@gene.com \
> > > > > > > > <mailto:lawrence.michael@gene.com>>> wrote:
> > > > > > > > I would recommend against dependencies across vignettes. Ideally \
> > > > > > > > someone can pick up a vignette and execute the code independently of \
> > > > > > > > any other documentation. Perhaps you could move 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.
> > > > > > > > Michael
> > > > > > > >
> > > > > > > > On Tue, Dec 18, 2018 at 5:22 AM Aaron Lun <
> > > > > > > > infinite.monkeys.with.keyboards@gmail.com \
> > > > > > > > <mailto:infinite.monkeys.with.keyboards@gmail.com> \
> > > > > > > > <mailto:infinite.monkeys.with.keyboards@gmail.com \
> > > > > > > > <mailto:infinite.monkeys.with.keyboards@gmail.com>>> wrote:
> > > > > > > > > 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 their file names. As such, I give my vignettes fairly \
> > > > > > > > > structured names, e.g., "work-1-reads.Rmd", "work-2-umi.Rmd" and so \
> > > > > > > > > on.
> > > > > > > > > However, it becomes rather annoying when I want to add a new \
> > > > > > > > > vignette in the middle somewhere. This results in some unnatural \
> > > > > > > > > numberings, e.g., "work-0", "3b", which are ugly and unintuitive. \
> > > > > > > > > This is relevant as BiocStyle::Biocpkg() links between vignettes \
> > > > > > > > > require you to use the destination vignette's file name; so \
> > > > > > > > > difficult names complicate linking, especially if the names \
> > > > > > > > > continually change to reflect new orderings.
> > > > > > > > > Is there an easier way to control vignette compilation order? WRE \
> > > > > > > > > provides no (obvious) guidance, so I would like to know what \
> > > > > > > > > non-standard hacks are known to work on the build machines. I can \
> > > > > > > > > imagine something dirty whereby one "reference" vignette contains \
> > > > > > > > > code to "rmarkdown::render" all other vignettes in the specified \
> > > > > > > > > order… ugh.
> > > > > > > > > -A
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> \
> > > > > > > > > <mailto:Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org>> \
> > > > > > > > > mailing list \
> > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_ma \
> > > > > > > > > ilman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q \
> > > > > > > > > 3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e= \
> > > > > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_m \
> > > > > > > > > ailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7 \
> > > > > > > > > q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=> \
> > > > > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_m \
> > > > > > > > > ailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7 \
> > > > > > > > > q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e= \
> > > > > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_m \
> > > > > > > > > ailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7 \
> > > > > > > > > q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=>>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > [[alternative HTML version deleted]]
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> \
> > > > > > > > <mailto:Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org>> \
> > > > > > > > mailing list \
> > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mail \
> > > > > > > > man_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeA \
> > > > > > > > vimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e= \
> > > > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mai \
> > > > > > > > lman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3Xe \
> > > > > > > > AvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=> \
> > > > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mai \
> > > > > > > > lman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3Xe \
> > > > > > > > AvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e= \
> > > > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mai \
> > > > > > > > lman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3Xe \
> > > > > > > > AvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=>>
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> \
> > > > > > > <mailto:Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org>> \
> > > > > > > mailing list \
> > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma \
> > > > > > > n_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvime \
> > > > > > > WdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e= \
> > > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailm \
> > > > > > > an_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvim \
> > > > > > > eWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=> \
> > > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailm \
> > > > > > > an_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvim \
> > > > > > > eWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e= \
> > > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailm \
> > > > > > > an_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvim \
> > > > > > > eWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=>>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > [[alternative HTML version deleted]]
> > > > > >
> > > > > > _______________________________________________
> > > > > > Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing list
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_ \
> > > > > > listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGb \
> > > > > > WY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e= \
> > > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman \
> > > > > > _listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdG \
> > > > > > bWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=>
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org> mailing list
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_li \
> > > > > stinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_w \
> > > > > JYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e= \
> > > > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_l \
> > > > > istinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_ \
> > > > > wJYbW0WYiZvSXAJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=>
> > > > >
> >
> >
> > [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > Bioc-devel@r-project.org mailing list
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo \
> > _bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSX \
> > AJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=
> >
> > _______________________________________________
> > Bioc-devel@r-project.org mailing list
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo \
> > _bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSX \
> > AJJKaaPhzWA&m=tSDkKz75WP0ADoqwKXKiWY8bkIqaLES4qv1wlk5eWZg&s=qUSR-5_f4Kyf5BgYZOhNtvava-PURPgFnQQhppzpgmY&e=
> >
>
> --
> 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: hpages@fredhutch.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
>
>
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic