Also, the code for DNAStringSetList is too low-level. There should just be
an nchar,XStringSetList that does the same thing as
nchar,CompressedCharacterList. Then restrictToSNV or whatever just does
any(nchar(x) == 1L) for any List.
Michael
On Wed, Mar 19, 2014 at 1:00 PM, Michael Lawrence
On Wed, Mar 19, 2014 at 4:00 PM, Michael Lawrence lawrence.mich...@gene.com
wrote:
It would be nice to have functions like isSNV, isIndel, isDeletion, etc
that at least provide precise definitions of the terminology. I've added
these, but they're designed only for VRanges. Should work for
You can apparently use 1D extraction for VCF, which is a little surprising;
I learned it from restrictToSNV.
On Wed, Mar 19, 2014 at 1:07 PM, Vincent Carey
st...@channing.harvard.eduwrote:
On Wed, Mar 19, 2014 at 4:00 PM, Michael Lawrence
lawrence.mich...@gene.com wrote:
It would be
Thanks Sean. Probably also need an isSubstitution for any substitution,
either SNV or complex.
On Wed, Mar 19, 2014 at 3:20 PM, Sean Davis sdav...@mail.nih.gov wrote:
On Wed, Mar 19, 2014 at 4:26 PM, Valerie Obenchain voben...@fhcrc.orgwrote:
Thanks for the feedback.
I'll look into nchar
To me it boils down to one simple question: is an update to a package on
CRAN more likely to (1) fix a bug, (2) introduce a bug or downward
incompatibility, or (3) add a new feature or fix a compatibility problem
without introducing a bug? I think the probability of (1) | (3) is much
greater
On Tue, Mar 18, 2014 at 3:24 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:
snip
## Summary
Extending the r-release cycle to CRAN seems like a solution that would
be easy to implement. Package updates simply only get pushed to the
r-devel branches of cran, rather than r-release and
I don't see why CRAN needs to be involved in this effort at all. A
third party could take snapshots of CRAN at R release dates, and make
those available to package users in a separate repository. It is not
hard to set a different repository than CRAN as the default location
from which to
Our experience in Bioconductor is that this is a pretty hard problem.
What the OP presumably wants is some guarantee that all packages on CRAN
work well together. A good example is when Rcpp was updated, it broke
other packages (quick note: The Rcpp developers do a incredible amount of
work to
Piling on:
On 19 March 2014 at 07:52, Joshua Ulrich wrote:
| There is nothing preventing you (or anyone else) from creating
| repositories that do what you suggest. Create a CRAN mirror (or more
| than one) that only include the package versions you think they
| should. Then have your
What would be more useful in terms of reproducibility is the capability of
installing a specific version of a package from a repository using
install.packages(), which would require archiving older versions in a
coordinated fashion. I know CRAN archives old versions, but I am not aware
if we
using the identical version of each CRAN package. The bioconductor
project uses similar policies.
While I agree that this can be an issue, I don't think it is fair to
compare CRAN to BioC. Unless things have changed, the latter has a more
rigorous barrier to entry which includes buy in of
What about having this purpose met with something like an
expansion of R-Forge? We could have packages submitted to R-Forge
rather than CRAN, and people who wanted the latest could get it from
R-Forge. If changes I make on R-Forge break a reverse dependency,
emails explaining the
On Wed, Mar 19, 2014 at 12:59 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:
On Wed, Mar 19, 2014 at 5:52 AM, Duncan Murdoch
murdoch.dun...@gmail.comwrote:
I don't see why CRAN needs to be involved in this effort at all. A third
party could take snapshots of CRAN at R release dates, and
Dear list,
I'm curious what people would think of a more modest proposal at this time:
State the version of the dependencies used by the package authors when the
package was built.
Eventually CRAN could enforce such a statement be present in the
description. We encourage users to declare the
On Wed, Mar 19, 2014 at 7:00 AM, Kasper Daniel Hansen
kasperdanielhan...@gmail.com wrote:
Our experience in Bioconductor is that this is a pretty hard problem.
What the OP presumably wants is some guarantee that all packages on CRAN work
well together.
Obviously we can not guarantee that all
Hi,
On 03/19/2014 07:00 AM, Kasper Daniel Hansen wrote:
Our experience in Bioconductor is that this is a pretty hard problem.
What's hard and requires a substantial amount of human resources is to
run our build system (set up the build machines, keep up with changes
in R, babysit the builds,
On Wed, Mar 19, 2014 at 11:50 AM, Joshua Ulrich josh.m.ulr...@gmail.com
wrote:
The suggested solution is not described in the referenced article. It
was not suggested that it be the operating system's responsibility to
distribute snapshots, nor was it suggested to create binary
repositories
Hi the list,
One of my package has a memory issue that I do not manage to understand. The
Memtest notes is here:
http://www.stats.ox.ac.uk/pub/bdr/memtests/valgrind/kml-Ex.Rout
Here is the message that I get from Memtest
--- 8
~ Fast KmL ~
==27283== Invalid read of size 4
On Wed, Mar 19, 2014 at 4:28 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:
On Wed, Mar 19, 2014 at 11:50 AM, Joshua Ulrich josh.m.ulr...@gmail.com
wrote:
The suggested solution is not described in the referenced article. It
was not suggested that it be the operating system's
- Original Message -
From: Joshua Ulrich josh.m.ulr...@gmail.com
To: Jeroen Ooms jeroen.o...@stat.ucla.edu
Cc: r-devel r-devel@r-project.org
Sent: Wednesday, March 19, 2014 2:59:53 PM
Subject: Re: [Rd] [RFC] A case for freezing CRAN
On Wed, Mar 19, 2014 at 4:28 PM, Jeroen Ooms
On Wed, Mar 19, 2014 at 2:59 PM, Joshua Ulrich josh.m.ulr...@gmail.com wrote:
So implementation isn't a problem. The problem is that you need a way
to force people not to be able to use different package versions than
what existed at the time of each R release. I said this in my
previous
On 19 Mar 2014, at 22:58 , Christophe Genolini cgeno...@u-paris10.fr wrote:
Hi the list,
One of my package has a memory issue that I do not manage to understand. The
Memtest notes is here:
http://www.stats.ox.ac.uk/pub/bdr/memtests/valgrind/kml-Ex.Rout
Here is the message that I get
On Wed, Mar 19, 2014 at 5:16 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:
On Wed, Mar 19, 2014 at 2:59 PM, Joshua Ulrich josh.m.ulr...@gmail.com
wrote:
So implementation isn't a problem. The problem is that you need a way
to force people not to be able to use different package versions
On 03/19/2014 02:59 PM, Joshua Ulrich wrote:
On Wed, Mar 19, 2014 at 4:28 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:
On Wed, Mar 19, 2014 at 11:50 AM, Joshua Ulrich josh.m.ulr...@gmail.com
wrote:
The suggested solution is not described in the referenced article. It
was not suggested
Weighting in. FWIW, I find the proposal conceptually quite interesting.
For package developers, it does not have to be a frustration to have to wait a
new version of R to release their code. Anticipated frustration was my initial
reaction. Thinking about this more, I think this could be
the details section of ?image says:
If useRaster is not specified, raster images are used when the
getOption(preferRaster) is true, the grid is regular and either
dev.capabilities(raster) is yes or it is non-missing and there
are no missing values.
but in my experience this is never the
What am I overlooking?
That this is already available and possible in R today, but perhaps
not widely used. Developers do tend to only include a lower bound if
they include any bounds at all on package dependencies.
As I mentioned elsewhere, R packages often aren't built against
other R packages
Given that R is (has) moved to a 12 month release cycle, I don't want
to either i) wait a year to get new packages (or allow users to use
new versions of my packages), or ii) have to run R-devel just to use
new packages. (or be on R-testing for that matter).
People then will start finding ways
On Mar 19, 2014, at 18:42, Joshua Ulrich josh.m.ulr...@gmail.com wrote:
On Wed, Mar 19, 2014 at 5:16 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu
wrote:
On Wed, Mar 19, 2014 at 2:59 PM, Joshua Ulrich josh.m.ulr...@gmail.com
wrote:
So implementation isn't a problem. The problem is that
Michael,
I think the issue is that Jeroen wants to take that responsibility out
of the hands of the person trying to reproduce a work. If it used R
3.0.x and packages A, B and C then it would be trivial to to install
that version of R and then pull down the stable versions of A B and C
for that
I've tweaked Rmpi and want to have some variables that hold data in the
package. One of the R files starts
mpi.isend.obj - vector(list, 500) #mpi.request.maxsize())
mpi.isend.inuse - rep(FALSE, 500) #mpi.request.maxsize())
On Mar 19, 2014, at 22:17, Gavin Simpson ucfa...@gmail.com wrote:
Michael,
I think the issue is that Jeroen wants to take that responsibility out
of the hands of the person trying to reproduce a work. If it used R
3.0.x and packages A, B and C then it would be trivial to to install
that
On Wed, Mar 19, 2014 at 6:55 PM, Michael Weylandt
michael.weyla...@gmail.com wrote:
Reading this thread again, is it a fair summary of your position to say
reproducibility by default is more important than giving users access to the
newest bug fixes and features by default? It's certainly
On Mar 19, 2014, at 22:45, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:
On Wed, Mar 19, 2014 at 6:55 PM, Michael Weylandt
michael.weyla...@gmail.com wrote:
Reading this thread again, is it a fair summary of your position to say
reproducibility by default is more important than giving users
I think what you really want here is the ability to easily identify
and sync to CRAN snapshots.
The easy way to do this is setup a CRAN mirror, but back it up with
version control, so that it's easy to reproduce the exact state of
CRAN at any given point in time. CRAN's not particularly large
35 matches
Mail list logo
