The all.equal was a side issue for me; I don't have strong opinions one way or
the other.
You are welcome to leave me out of the loop on that. (Or leave me on the cc,
whatever is
easiest).
I will update the survival package once the [.terms issues are addressed.
One debatable issues is
Please also note there are two MAC builders currently listed in the daily build
reports for Bioc devel 3.9.
Please ignore merida2.
Merida2 is a legacy build machine that will be taken offline shortly. Please
satisfy all install/build/check for the active build machines
Active build machines:
merida2 is a legacy build machine that will be taken offline shortly. Please
satisfy celaya2.
Lori Shepherd
Bioconductor Core Team
Roswell Park Cancer Institute
Department of Biostatistics & Bioinformatics
Elm & Carlton Streets
Buffalo, New York 14263
Dear Bioconductor,
With your very helpful assistance, for which we are extremely grateful,
we have succeeded in removing the errors from the devel branch of our
bumphunter package. More or less, anyway.
We are passing on celaya2 and failing on merida2. The reason is that
celaya2 is running
On 05/04/2019 11:33 a.m., Martin Maechler wrote:
Duncan Murdoch
on Fri, 5 Apr 2019 11:12:48 -0400 writes:
> On 05/04/2019 10:46 a.m., Therneau, Terry M., Ph.D. wrote:
>>
>>
>> On 4/5/19 9:39 AM, Duncan Murdoch wrote:
>>> On 05/04/2019 10:19 a.m., Therneau, Terry
> Martin Maechler
> on Fri, 5 Apr 2019 17:33:54 +0200 writes:
> Duncan Murdoch
> on Fri, 5 Apr 2019 11:12:48 -0400 writes:
>> On 05/04/2019 10:46 a.m., Therneau, Terry M., Ph.D. wrote:
>>>
>>>
>>> On 4/5/19 9:39 AM, Duncan Murdoch wrote:
On
> Duncan Murdoch
> on Fri, 5 Apr 2019 11:12:48 -0400 writes:
> On 05/04/2019 10:46 a.m., Therneau, Terry M., Ph.D. wrote:
>>
>>
>> On 4/5/19 9:39 AM, Duncan Murdoch wrote:
>>> On 05/04/2019 10:19 a.m., Therneau, Terry M., Ph.D. wrote:
Duncan,
On 05/04/2019 10:46 a.m., Therneau, Terry M., Ph.D. wrote:
On 4/5/19 9:39 AM, Duncan Murdoch wrote:
On 05/04/2019 10:19 a.m., Therneau, Terry M., Ph.D. wrote:
Duncan,
I should have included it in my original note, but
all.equal(unclass(t0x), unclass(t1x))
returns TRUE as well.
Thanks Lori :)
I've already written to my reviewer (Qian Liu) asking if it's possible to
proceed with the review in the current situation.
The code in the package is quite fast (and simple) but I'll take a look at that
link to see if I can get a few more seconds out.
Bernat
El 4/5/19
On 4/5/19 9:39 AM, Duncan Murdoch wrote:
On 05/04/2019 10:19 a.m., Therneau, Terry M., Ph.D. wrote:
Duncan,
I should have included it in my original note, but
all.equal(unclass(t0x), unclass(t1x))
returns TRUE as well. I had tried that as well. But a further look at
Also, the reviewer might be able to glance at the code and help try to make it
run more efficiently. See points on
http://bioconductor.org/developers/how-to/efficient-code/ for things like
vectorization and pre-allocation.
Lori Shepherd
Bioconductor Core Team
Roswell Park Cancer
On 05/04/2019 10:19 a.m., Therneau, Terry M., Ph.D. wrote:
Duncan,
I should have included it in my original note, but
all.equal(unclass(t0x), unclass(t1x))
returns TRUE as well. I had tried that as well. But a further look at
all.equal.default shows the following line right near
If the check time is passing on the other platforms, and the windows check
isn't incredibly over the time limit, you should be okay. Talk with your
reviewer but in general we would make an exception for this warning.
Most of the time subsets of data can be used for examples and vignettes
Hi all,
I've submitted a new package (CopyNumberPlots, issue 1076) and I have a
problem. It keeps giving me a warning because on windows it takes more
than 5 minutes to check (in Lunix it works with no problems). I've
reduced the examples, removed part of the vignette... and in my machine
Duncan,
I should have included it in my original note, but
all.equal(unclass(t0x), unclass(t1x))
returns TRUE as well. I had tried that as well. But a further look at
all.equal.default
shows the following line right near the top:
if (is.language(target) || is.function(target))
On 05/04/2019 9:03 a.m., Therneau, Terry M., Ph.D. via R-devel wrote:
This arose in testing [.terms and has me confused.
data(esoph) # use a standard data set
t0x <- terms(model.frame( ~ tobgp, data=esoph))
t1 <- terms(model.frame(ncases ~ agegp + tobgp, data=esoph))
t1x <-
As footnote, the error in survival:::untangle.specials is that it assumed that
if
attr(myterms, 'specials')[['strata']] was = to 4, then one could use
myterms[-4] to remove
the strata term. Not so. In the model y ~ x1 + x2 + strata(x3) the
attritube will
be 4 -- the response counts
It depends on the specific case but attempting to check with the previous
maintainer/author looks like a courteous first step
before taking over.
Georgi Boshnakov
-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf
Of Dirk Eddelbuettel
This arose in testing [.terms and has me confused.
data(esoph) # use a standard data set
t0x <- terms(model.frame( ~ tobgp, data=esoph))
t1 <- terms(model.frame(ncases ~ agegp + tobgp, data=esoph))
t1x <- (delete.response(t1))[-1]
> all.equal(t0x, t1x)
[1] TRUE
# the above is wrong,
The final day to submit new packages to the Bioconductor contributions tracker
to have a shot at being included in the upcoming 3.9 release is TODAY!
Please note: submission by this date does not guarantee it will be included -
the package must undergo an official review and be accepted by
In addition you can also try to use a PSOCK cluster (see makeCluster,
parLapply) to avoid the problem - it should help if the problem is
somehow related to forking in mclapply().
The problem you are seeing may be in base R, in data.table, or in
interaction between the two (mclapply() from
On 5 April 2019 at 13:30, peter dalgaard wrote:
| For most packages[*], I assume that you can just take on the role as
maintainer, bump the version number and resubmit. If you don't actually
maintain it, then of course it might fall of CRAN again after a while.
|
| -pd
|
| [*] Actually, I
On 5 April 2019 at 11:29, Jose V. Die wrote:
| I am working on my first package and I released a new version (1.0.11). The
CRAN checks link shows the last updated for today although the check details
section refers to version 1.0.1.
|
| So, I’m confused about it. Are those check results from
For most packages[*], I assume that you can just take on the role as
maintainer, bump the version number and resubmit. If you don't actually
maintain it, then of course it might fall of CRAN again after a while.
-pd
[*] Actually, I expect that CRAN policy implies "all" here; I just can't be
On 4 April 2019 at 17:28, ivo welch wrote:
| The following program is whittled down from a much larger program that
| always works on Intel, and always works on AMD's threadripper with
| lapply but not mclappy. With mclapply on AMD, all processes go into
| "suspend" mode and the program then
Hi,
I am working on my first package and I released a new version (1.0.11). The
CRAN checks link shows the last updated for today although the check details
section refers to version 1.0.1.
So, I’m confused about it. Are those check results from my old version or the
current version just
Hi,
I've been searching for some procedures to try an get an old package back
into CRAN.
It's package that has the re exclamation mark on cran github and is not
available via install.packages() for modern version of R.
However some small changes to the source were enough to get it installed
via
The following program is whittled down from a much larger program that
always works on Intel, and always works on AMD's threadripper with
lapply but not mclappy. With mclapply on AMD, all processes go into
"suspend" mode and the program then hangs. This bug is replicable on an
AMD Ryzen
Hello!
This is my first post here. I came across the very same problem.
It can be reproduced within modified tests/Embedding/RParseEval.c
Actually this example has another issue, namely it doesn't wrap
everything in R_ToplevelExec . This is a major show stopper for
newcomers as that function is
Dear Terry,
> Therneau, Terry M , Ph D via R-devel
> on Thu, 4 Apr 2019 22:48:49 -0400 writes:
> Someone sent me a bug report for survival2.44.1-1 that involves a model
with both cluster
> and offset. It turns out to be a 3 part issue with [.terms and my own
> Ben Bolker
> on Thu, 4 Apr 2019 12:46:37 -0400 writes:
> Proposed patch
Thank you Ben!
[the rest is technical nit-picking .. but hopefully interesting
to the smart R-devel reader base:]
There was a very subtle thinko in your patch which is not easily
diagnosed from R's
31 matches
Mail list logo
