Hi Vince,
On 04/17/2014 04:19 AM, Vincent Carey wrote:
On Thu, Apr 17, 2014 at 2:37 AM, Hervé Pagès mailto:hpa...@fhcrc.org>> wrote:
Hi Vince,
On 04/10/2014 08:16 AM, Vincent Carey wrote:
seems like something we should use more routinely, and it was not
straightfor
Thank you Dan.
I should have looked at the time of my commit.
Best,
davide
On Tue, Apr 22, 2014 at 12:15 PM, Dan Tenenbaum wrote:
> Hi Davide,
>
> - Original Message -
>> From: "davide risso"
>> To: bioc-devel@r-project.org
>> Sent: Tuesday, April 22, 2014 12:06:09 PM
>> Subject: [Bioc
ks is required by the code copied from feature package, which has been
moved to flowStats. And 'norm2Filter' is not using it.
Sio with the removal of curv*Filters, flowCore should not depend on ks
anymore.
Mike
On 04/22/2014 12:14 PM, Kieran O'Neill wrote:
> Thanks all for this work. It definite
Hi Davide,
- Original Message -
> From: "davide risso"
> To: bioc-devel@r-project.org
> Sent: Tuesday, April 22, 2014 12:06:09 PM
> Subject: [Bioc-devel] Package vignette and knitr
>
> Dear list,
>
> I've modified the vignette of my EDASeq package to work with knitr.
>
> Following the
Thanks all for this work. It definitely makes the most sense to factor out
this functionality.
One thing, though: Josef Spidlen pointed out to me the other day that,
despite Kevin's fix, there is still a dependency on the ks package, which
in turn depends on rgl, which also creates an X11 dependen
Dear list,
I've modified the vignette of my EDASeq package to work with knitr.
Following the guidelines in the BiocStyle vignette, I've added
Suggests: BiocStyle, knitr
VignetteBuilder: knitr
to the DESCRIPTION file and
%\VignetteEngine{knitr::knitr}
to the top of the .Rnw file.
The package
I think we should have a CRAN snapshot (or a subset of CRAN used in Bioc)
inside each Bioc release; I don't know how hard that is to manage from a
technical point of view.
Best,
Kasper
On Tue, Apr 22, 2014 at 6:06 PM, Julian Gehring wrote:
> Hi,
>
> For most problems discussed here, it seems th
Hi,
For most problems discussed here, it seems that having a fixed version
of package is sufficient rather than a specific version. If the idea of
a snapshot with each bioc release would work (which still means one
version per package), so would requiring that version within the package
(one
Hi Julian
what if two Bioc packages require different version of the ‘same’ CRAN package?
AfaIu, the infrastructure is not designed to deal with multiple versions of a
package.
Nor would I as a user expect to have less-than-the-most recent versions of CRAN
packages in my library just because so
Dear Herve,
We are hitting a 'memory not mapped' problem when using trimLRpatterns
as detailed below. I did not manage to reproduce it with few sequences,
so I have to refer to a publicly available sequence file with many
reads. Even then, it occasionally runs through without problems.
Also, our
Hi Martin,
Thank you for your response. I checked the header and it says that it is
coordinate sorted, so that shouldn’t be the problem. Here are the results of
the code you provided:
> r3 = applyPileups(PileupFiles(c(fl1, fl2)), function(x) x, param=testparam)
> any(duplicated(r3[[1]][["pos"]]
Hi,
For a "more general solution" one could think of specifying the version
of critical packages in the 'description' file and having a 'biocLite'
function that installs the specific version from CRAN. See e.g. the
'devtools::install_version' function for installing older packages from
the C
Hi Andrej,
Yes, that would help, that would be also a solution for my case,
installing an old version of the cran package (stamod in my case)
However, I don't know if this could be a "general solution for all
users" since when installing a package via
biocLite, the latest version of the cran
Dear Kasper,
regarding your issue with R-2.15: I was wondering whether using an
older version of Rcpp from
http://cran.r-project.org/src/contrib/Archive/Rcpp/ would help?
Cheers,
Andrzej
On Tue, Apr 22, 2014 at 2:46 PM, Kasper Daniel Hansen
wrote:
> This is because commits to this branch of Bio
On 04/22/2014 05:55 AM, Julian Gehring wrote:
Related to this, running 'biocLite("BiocUpgrade")' with an bioc-3.0 triggers an
upgrade to bioc-3.1 which is non-existing.
This will be addressed, sorry for not responding sooner. Martin
Best wishes
Julian
On 22.04.2014 14:38, Julian Gehring wr
Related to this, running 'biocLite("BiocUpgrade")' with an bioc-3.0
triggers an upgrade to bioc-3.1 which is non-existing.
Best wishes
Julian
On 22.04.2014 14:38, Julian Gehring wrote:
Hi,
Alejandro and I digged deeper into this:
The bug I described before as caused by 'BiocInstaller:::.onL
This is because commits to this branch of Bioconductor has been disabled
and it is intentional.
But it raises the larger question, recently touched upon in a lengthy
thread on R-devel, on whether this is a good state of affairs for
Bioconductor. Specifically the issue has to do with dependency of
Hi,
Alejandro and I digged deeper into this:
The bug I described before as caused by 'BiocInstaller:::.onLoad' which
sets 'BiocInstaller:::IS_UPGRADEABLE' to TRUE for every bioc release
with an even minor (e.g. 2.12, 2.14). Within the load function,
(BIOC_VERSION$minor %% 2L) == 0L
check
Dear Dan, Dear developers list,
Due a recent change in one cran package, DEXSeq 1.8.0 (for the R version
3.0.*) stop working. I fixed this conflict in the release branch of
bioconductor and tried to commit my changes. But I don't seem to have
write access, e.g:
$ svn ci --username a.reyes -m
19 matches
Mail list logo
