Hi Renan,
Most packages affected by these changes are packages that loop on
the individual ranges of a GRanges object. They generally don't
call as.list() directly but use something like lapply(), vapply(),
sapply(), Map(), Reduce(), etc... All these functions indeed call
as.list() internally on
On 02/19/2018 06:43 AM, Michael Lawrence wrote:
On Mon, Feb 19, 2018 at 2:10 AM, Bernat Gel > wrote:
Hi Hervé,
I completely agree with the goal of having the semantics of
list-like operations standardised and documented to avoid surprises,
Hi, I'm trying to understand the rationale for your proposed amount of
splitting and more precisely why that one is THE one.
If I put labels on your example numbers in one of your previous post:
nbrOfElements <- 97
nbrOfWorkers <- 5
With these, there are two extremes in how you can split up
Valerie, thanks. Will try to ask there.
However, after looking through the mailing list it looks like R-devel
builds for OS X aren't trivial and aren't part of CRAN...
--
Alexey
On Mon, Feb 19, 2018 at 9:05 PM, Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:
> Hi,
>
> There has
Hi,
There has been some discussion of the devel Mac binaries on the R-SIG-Mac
mailing list. That list would be the best place to ask this question.
https://stat.ethz.ch/pipermail/r-sig-mac/2018-January/thread.html
Valerie
On 02/19/2018 08:32 AM, Alexey Sergushichev wrote:
Valerie,
Are there
Dear R-Devel List,
I have installed R 3.4.3 with the patch applied on our cluster and ran a
*real-world* job of one of our users to confirm that the patch works to my
satisfaction. Here are the results.
The original was a series of jobs, all essentially doing the same stuff using
bootstrapped
On Mon, Feb 19, 2018 at 11:27 AM, Alexey Sergushichev
wrote:
> Kevin,
>
> > It does not request users to make R-devel a _requirement_ of their
> package.
>
> Sadly it does for new packages. New packages submitted to Bioconductor 3.7
> are _required_ to have R >= 3.5
> > Personally, I haven't found it to be particularly difficult to update R,
> > or to run R-devel in parallel with R 3.4, even without root privileges.
>
> I find it much harder for a normal user to install R-devel (and update
> it properly, because it's a development version) and running
>
Valerie,
Are there any estimates on how often CRAN OS X builds happen? There are
still no builds for rsvg and other packages...
Thanks,
Alexey
On Wed, Feb 7, 2018 at 8:09 PM, Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:
> Hi Kevin,
>
> CRAN binaries for El Capitan in devel
Kevin,
> It does not request users to make R-devel a _requirement_ of their
package.
Sadly it does for new packages. New packages submitted to Bioconductor 3.7
are _required_ to have R >= 3.5 dependency, otherwist BiocCheck will result
in a warning (
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
Thank you for the report and analysis. Now fixed in R-devel.
Tomas
On 02/17/2018 08:24 PM, William Dunlap via R-devel wrote:
I think the problem in R-devel happens when there are non-ASCII characters
in any
of the strings passed to gsub.
txt <- vapply(list(as.raw(c(0x41, 0x6d, 0xc3, 0xa9,
Hi Alexey,
I do agree with you that there is no harm in testing against other version
of R. In a way, that is even good practice, considering that many HPC users
do not always have access to the latest version of R, and that Travis is
making this fairly easy.
Now, with regard to your latest
On Mon, Feb 19, 2018 at 2:10 AM, Bernat Gel wrote:
> Hi Hervé,
>
> I completely agree with the goal of having the semantics of list-like
> operations standardised and documented to avoid surprises, and if to do so,
> the current use of as.list must be changed I'm pefectly ok with
Hello Kevin,
Well, bioc-devel packages are tested against bioc-devel (and R-3.5) in any
case. What I'm saying is that aside from testing the package against
bioc-devel, I can as well test against bioc-release too on my own. If the
package doesn't work with bioc-devel it shouldn't pass bioc-devel
I think it is as Kevin described in an earlier response - the garbled
output is because a UTF-8 encoded string is assumed to be native
encoding (which happens not to be UTF-8 on the platform where this is
observed) and converted again to UTF-8.
I think the documentation is consistent with
Hi Hervé,
I completely agree with the goal of having the semantics of list-like
operations standardised and documented to avoid surprises, and if to do
so, the current use of as.list must be changed I'm pefectly ok with
that. I had not seen the strange behaviour with IRanges, so I was not
Dear Alexey,
The reason is somewhat implicitly given at
https://www.bioconductor.org/developers/how-to/useDevel/ :
"Package authors should develop against the version of *R* that will be
available to users when the *Bioconductor* devel branch becomes the
*Bioconductor* release branch."
In other
Dear Bioconducotr community,
I wonder, what is the reason behind requirement for dependency R >= 3.5
(currently) for new packages?
As a developer I really want an installation of my package to be as easy as
possible and want my package to be easily installed from github. So
currently, when I
19 matches
Mail list logo