Re: [Rd] all.equal failure and [.terms

[Therneau, Terry M., Ph.D. via R-devel]

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 the choice of change vs document for the offset() 
issue.  With 
my proposed fix or without it, offsets are completely ignored by [.terms and 
dropterms.  
So with a formula of

    z <- terms(y~ x1 + offset(x2) + x3)

the 2 in drop.terms(z, 2) or z[-2] refers to x3, and the result will drop both 
the offset 
and x3.  For the use cases that I can think of the two functions are used at 
the 'build 
the X matrix' stage, offsets have already been accounted for, and the present 
behavior is 
fine.  My vote would be to document it with a few lines in the help file since 
that is the 
easiest.  Offsets don't count as a 'term' in the assign attribute either so the 
current 
behavior is consistent in that respect.

Terry T.


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Deadline for devel branch 3.9 to pass R CMD build and R CMD check

[Shepherd, Lori]

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:
malbec2 (linux)
tokay2 (windows)
celaya2 (mac)



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Shepherd, Lori 

Sent: Monday, April 1, 2019 8:00:40 AM
To: bioc-devel
Subject: [Bioc-devel] Deadline for devel branch 3.9 to pass R CMD build and R 
CMD check

The deadline for all packages (software, data experiment, workflows) to pass R 
CMD build and R CMD check without TIMEOUT, ERROR, or WARNING is Friday April 
26th. The devel branch will temporarily be frozen on Sunday April 28th to 
branch for the April 30th release. Any changes after the freeze will have to be 
updated to the release 3.9 and devel 3.10 branch. If your package has been 
failing to pass build or check for an extended period of time it will be marked 
for immediate deprecation in the next development cycle (devel 3.10) until it 
is fixed.

See full release schedule here:
http://bioconductor.org/developers/release-schedule/
Bioconductor - Release: 
Schedule
bioconductor.org
Bioconductor 3.9 Release Schedule. This release will use R-3.6.0 (�Planting of 
a Tree�). The official release date is schedule for Tuesday April 30th.




Thank you



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] celaya2 and merida2 are running different versions of R

[Shepherd, Lori]

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


From: Bioc-devel  on behalf of Samuela 
Pollack 
Sent: Friday, April 5, 2019 12:54:42 PM
To: Bioc-devel; r...@jimmy.harvard.edu
Subject: [Bioc-devel] celaya2 and merida2 are running different versions of R

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 R-devel r76245 and merida2 is running R-devel r75683.
The random number generator changed between r75683 and r76245. This is a
problem because our unit tests compare the output of bumphunter to a
stashed .rda file. So there is no way the .rda file can make both r75683
and r76245 happy.

Will this cause any problems for the package's continuation in
Bioconductor 3.9?

It seems probable but not guaranteed that R 3.6 will ultimately use the
new RNG.

thanks,

- Sam

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] celaya2 and merida2 are running different versions of R

[Samuela Pollack]

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 R-devel r76245 and merida2 is running R-devel r75683. 
The random number generator changed between r75683 and r76245. This is a 
problem because our unit tests compare the output of bumphunter to a 
stashed .rda file. So there is no way the .rda file can make both r75683 
and r76245 happy.


Will this cause any problems for the package's continuation in 
Bioconductor 3.9?


It seems probable but not guaranteed that R 3.6 will ultimately use the 
new RNG.


thanks,

- Sam

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] [EXTERNAL] Re: Re: all.equal failure

[Duncan Murdoch]

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 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 the top:
   if (is.language(target) || is.function(target))
   return(all.equal.language(target, current, ...))
 
  and that path explicitly ignores attributes.
 >>>
 >>> Which R version are you using?  I see deparse(target) and 
deparse(current) in
 >>> all.equal.language(), and those should not be ignoring attributes 
according to the
 >>> documentation.

But the problem is that indeed  "of course"  all.equal.formula()
and not all.equal.language() is called for the terms since as
you yourself remarked, their class is  c("terms", "formula"),

and so what Terry reported is indeed correct *and* a bug
and in "all versions" of R (I did not look far back, but these things
haven't changed much).

The cleanest would probably be to define an  all.equal.terms()
method, as I think there may be more code relying on the
behavior of  all.equal.formula() to only look at the formulas
themselves and not their attributes...
but you (Duncan) and others may have a different opinion.


I don't know if that would be easy -- it seems to me there is a bug in 
deparse(), which won't show attributes on language objects even if you 
ask it to:


# This is fine:
deparse(structure(1, attrib=2))
# [1] "structure(1, attrib = 2)"

# This doesn't show the attributes
deparse(structure(quote(f(1)), attrib=2))
# [1] "f(1)"

But as you mention, if this isn't a new bug fixing it will likely cause 
problems for people who assume it is intentional...


Duncan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [EXTERNAL] Re: Re: all.equal failure

[Martin Maechler]

> 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 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 the top:
>  if (is.language(target) || is.function(target))
>  return(all.equal.language(target, current, ...))
> 
> and that path explicitly ignores attributes.
 
 Which R version are you using?  I see deparse(target) and 
deparse(current) in
 all.equal.language(), and those should not be ignoring attributes 
according to the
 documentation.

> But the problem is that indeed  "of course"  all.equal.formula()
> and not all.equal.language() is called for the terms since as
> you yourself remarked, their class is  c("terms", "formula"),

> and so what Terry reported is indeed correct *and* a bug
> and in "all versions" of R (I did not look far back, but these things
> haven't changed much).

> The cleanest would probably be to define an  all.equal.terms()
> method, as I think there may be more code relying on the
> behavior of  all.equal.formula() to only look at the formulas
> themselves and not their attributes...
> but you (Duncan) and others may have a different opinion.

and I do agree with Duncan even more now that indeed it's very
unsatisfactory that deparse() {and dput(), dump() ..} of a terms
object would only reproduce the formula and nothing else;
and yes that's all in the C code:
 --> src/main/deparse.c
--> in function deparse2buff()
   -->  inside the (350 lines large)  'case LANGSXP'.

Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [EXTERNAL] Re: Re: all.equal failure

[Martin Maechler]

> 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,
    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))
  return(all.equal.language(target, current, ...))
 
 and that path explicitly ignores attributes.
>>> 
>>> Which R version are you using?  I see deparse(target) and 
deparse(current) in
>>> all.equal.language(), and those should not be ignoring attributes 
according to the
>>> documentation.

But the problem is that indeed  "of course"  all.equal.formula()
and not all.equal.language() is called for the terms since as
you yourself remarked, their class is  c("terms", "formula"),

and so what Terry reported is indeed correct *and* a bug
and in "all versions" of R (I did not look far back, but these things
haven't changed much).

The cleanest would probably be to define an  all.equal.terms()
method, as I think there may be more code relying on the
behavior of  all.equal.formula() to only look at the formulas
themselves and not their attributes...
but you (Duncan) and others may have a different opinion.

Martin Maechler
ETH Zurich and R Core Team

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [EXTERNAL] Re: Re: all.equal failure

[Duncan Murdoch]

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.  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))
  return(all.equal.language(target, current, ...))

and that path explicitly ignores attributes.


Which R version are you using?  I see deparse(target) and deparse(current) in
all.equal.language(), and those should not be ignoring attributes according to 
the
documentation.


I'm using today's version of R-devel on Ubuntu.  (svn up this AM)
But I agree, both target and current appear.


That's not what I said.  I said that the attributes should not be 
ignored in that function.  I don't see anything in the R-devel version 
of it that ignores attributes:


> all.equal.language
function (target, current, ...)
{
mt <- mode(target)
mc <- mode(current)
if (mt == "expression" && mc == "expression")
return(all.equal.list(target, current, ...))
ttxt <- paste(deparse(target), collapse = "\n")
ctxt <- paste(deparse(current), collapse = "\n")
msg <- c(if (mt != mc) paste0("Modes of target, current: ",
mt, ", ", mc), if (ttxt != ctxt) {
if (pmatch(ttxt, ctxt, 0L)) "target is a subset of current" 
else if (pmatch(ctxt,
ttxt, 0L)) "current is a subset of target" else "target, 
current do not match when deparsed"

})
if (is.null(msg))
TRUE
else msg
}




Duncan Murdoch






Duncan Murdoch



I'll change my original original title to "all.equal was not a good tool for 
testing
certain code issues".

Thanks for the pointer,

Terry



On 4/5/19 9:00 AM, Duncan Murdoch wrote:

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 <- (delete.response(t1))[-1]

   > all.equal(t0x, t1x)
[1] TRUE

# the above is wrong, because they actually are not the same

   > all.equal(attr(t0x, 'dataClasses'), attr(t1x, 'dataClasses'))
[1] "Names: 1 string mismatch"
[2] "Lengths (1, 2) differ (string compare on first 1)"


As documented, all.equal() is generic, with methods for different classes.  The
classes of both t0x and t1x are

  c("terms","formula")

with no all.equal.terms method, so all.equal.formula is called. That method 
isn't
specifically documented, but you can see its definition as

function (target, current, ...)
{
     if (length(target) != length(current))
     return(paste0("target, current differ in having response: ",
     length(target) == 3L, ", ", length(current) == 3L))
     if (!identical(deparse(target), deparse(current)))
     "formulas differ in contents"
     else TRUE
}

So the issue is that deparse(t0x) and deparse(t1x) give the same strings with no
attributes shown, even though "showAttributes" is set by default.   I haven't 
traced
through the C code to see where things are going wrong.

Duncan Murdoch



   > sessionInfo()
R Under development (unstable) (2019-04-05 r76323)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS:   /usr/local/src/R-devel/lib/libRblas.so
LAPACK: /usr/local/src/R-devel/lib/libRlapack.so

locale:
    [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
    [3] LC_TIME=en_US.UTF-8    LC_COLLATE=C
    [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
    [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
    [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets methods base

loaded via a namespace (and not attached):
[1] compiler_3.7.0 tools_3.7.0


 [[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel











__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Timeout in check for a new submission

[Bernat Gel Moreno]

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 a las 4:43 PM, Shepherd, Lori escribi�:

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 Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
 on 
behalf of Shepherd, Lori 

Sent: Friday, April 5, 2019 10:40:07 AM
To: Bernat Gel Moreno; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Timeout in check for a new submission

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 which 
also help to reduce the check time but still retain usefulness of an 
application, without knowing your data just an example  instead of running over 
all chromosomes,  limit to one smaller chromosome, etc...   If this has already 
been done then you should be able to proceed through the submission process 
despite this warning.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel 
 on 
behalf of Bernat Gel Moreno 
Sent: Friday, April 5, 2019 10:27:21 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Timeout in check for a new submission


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
it take 3min 20seconds to check, of which only 30seconds are spent in
the examples and vignette and the other 2min 50 seconds are spent in all
other checks.

Other than reducing the vignette and examples I don't know how to reduce
the cheking time. Any pointers?

Thanks a lot

Bernat

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

This email message may contain legally privileged and/or confidential 
information. If you are not the intended recipient(s), or the employee or agent 
responsible for the delivery of this message to the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or use of this 
email message is prohibited. If you have received this message in error, please 
notify the sender immediately by e-mail and delete this email message from your 
computer. Thank you.


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] [EXTERNAL] Re: Re: all.equal failure

[Therneau, Terry M., Ph.D. via R-devel]

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 
all.equal.default shows the following line right near the top:

 if (is.language(target) || is.function(target))
 return(all.equal.language(target, current, ...))

and that path explicitly ignores attributes.


Which R version are you using?  I see deparse(target) and deparse(current) in 
all.equal.language(), and those should not be ignoring attributes according to the 
documentation.



I'm using today's version of R-devel on Ubuntu.  (svn up this AM)
But I agree, both target and current appear.


Duncan Murdoch



I'll change my original original title to "all.equal was not a good tool for testing 
certain code issues".


Thanks for the pointer,

Terry



On 4/5/19 9:00 AM, Duncan Murdoch wrote:

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 <- (delete.response(t1))[-1]

  > all.equal(t0x, t1x)
[1] TRUE

# the above is wrong, because they actually are not the same

  > all.equal(attr(t0x, 'dataClasses'), attr(t1x, 'dataClasses'))
[1] "Names: 1 string mismatch"
[2] "Lengths (1, 2) differ (string compare on first 1)"


As documented, all.equal() is generic, with methods for different classes.  The 
classes of both t0x and t1x are


 c("terms","formula")

with no all.equal.terms method, so all.equal.formula is called. That method isn't 
specifically documented, but you can see its definition as


function (target, current, ...)
{
    if (length(target) != length(current))
    return(paste0("target, current differ in having response: ",
    length(target) == 3L, ", ", length(current) == 3L))
    if (!identical(deparse(target), deparse(current)))
    "formulas differ in contents"
    else TRUE
}

So the issue is that deparse(t0x) and deparse(t1x) give the same strings with no 
attributes shown, even though "showAttributes" is set by default.   I haven't traced 
through the C code to see where things are going wrong.


Duncan Murdoch



  > sessionInfo()
R Under development (unstable) (2019-04-05 r76323)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS:   /usr/local/src/R-devel/lib/libRblas.so
LAPACK: /usr/local/src/R-devel/lib/libRlapack.so

locale:
   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
   [3] LC_TIME=en_US.UTF-8    LC_COLLATE=C
   [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
   [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets methods base

loaded via a namespace (and not attached):
[1] compiler_3.7.0 tools_3.7.0


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel









__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Timeout in check for a new submission

[Shepherd, Lori]

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 Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Shepherd, Lori 

Sent: Friday, April 5, 2019 10:40:07 AM
To: Bernat Gel Moreno; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Timeout in check for a new submission

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 which 
also help to reduce the check time but still retain usefulness of an 
application, without knowing your data just an example  instead of running over 
all chromosomes,  limit to one smaller chromosome, etc...   If this has already 
been done then you should be able to proceed through the submission process 
despite this warning.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Bernat Gel 
Moreno 
Sent: Friday, April 5, 2019 10:27:21 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Timeout in check for a new submission


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
it take 3min 20seconds to check, of which only 30seconds are spent in
the examples and vignette and the other 2min 50 seconds are spent in all
other checks.

Other than reducing the vignette and examples I don't know how to reduce
the cheking time. Any pointers?

Thanks a lot

Bernat

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] [EXTERNAL] Re: all.equal failure

[Duncan Murdoch]

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 the top:

     if (is.language(target) || is.function(target))
     return(all.equal.language(target, current, ...))

and that path explicitly ignores attributes.


Which R version are you using?  I see deparse(target) and 
deparse(current) in all.equal.language(), and those should not be 
ignoring attributes according to the documentation.


Duncan Murdoch



I'll change my original original title to "all.equal was not a good tool 
for testing certain code issues".


Thanks for the pointer,

Terry



On 4/5/19 9:00 AM, Duncan Murdoch wrote:

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 <- (delete.response(t1))[-1]

  > all.equal(t0x, t1x)
[1] TRUE

# the above is wrong, because they actually are not the same

  > all.equal(attr(t0x, 'dataClasses'), attr(t1x, 'dataClasses'))
[1] "Names: 1 string mismatch"
[2] "Lengths (1, 2) differ (string compare on first 1)"


As documented, all.equal() is generic, with methods for different 
classes.  The classes of both t0x and t1x are


 c("terms","formula")

with no all.equal.terms method, so all.equal.formula is called. That 
method isn't specifically documented, but you can see its definition as


function (target, current, ...)
{
    if (length(target) != length(current))
    return(paste0("target, current differ in having response: ",
    length(target) == 3L, ", ", length(current) == 3L))
    if (!identical(deparse(target), deparse(current)))
    "formulas differ in contents"
    else TRUE
}

So the issue is that deparse(t0x) and deparse(t1x) give the same 
strings with no attributes shown, even though "showAttributes" is set 
by default.   I haven't traced through the C code to see where things 
are going wrong.


Duncan Murdoch



  > sessionInfo()
R Under development (unstable) (2019-04-05 r76323)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS:   /usr/local/src/R-devel/lib/libRblas.so
LAPACK: /usr/local/src/R-devel/lib/libRlapack.so

locale:
   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
   [3] LC_TIME=en_US.UTF-8    LC_COLLATE=C
   [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
   [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods base

loaded via a namespace (and not attached):
[1] compiler_3.7.0 tools_3.7.0


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel







__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] Timeout in check for a new submission

[Shepherd, Lori]

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 which 
also help to reduce the check time but still retain usefulness of an 
application, without knowing your data just an example  instead of running over 
all chromosomes,  limit to one smaller chromosome, etc...   If this has already 
been done then you should be able to proceed through the submission process 
despite this warning.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Bernat Gel 
Moreno 
Sent: Friday, April 5, 2019 10:27:21 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Timeout in check for a new submission


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
it take 3min 20seconds to check, of which only 30seconds are spent in
the examples and vignette and the other 2min 50 seconds are spent in all
other checks.

Other than reducing the vignette and examples I don't know how to reduce
the cheking time. Any pointers?

Thanks a lot

Bernat

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Timeout in check for a new submission

[Bernat Gel Moreno]

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 
it take 3min 20seconds to check, of which only 30seconds are spent in 
the examples and vignette and the other 2min 50 seconds are spent in all 
other checks.

Other than reducing the vignette and examples I don't know how to reduce 
the cheking time. Any pointers?

Thanks a lot

Bernat

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] [EXTERNAL] Re: all.equal failure

[Therneau, Terry M., Ph.D. via R-devel]

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))
     return(all.equal.language(target, current, ...))

and that path explicitly ignores attributes.

I'll change my original original title to "all.equal was not a good tool for 
testing 
certain code issues".

Thanks for the pointer,

Terry



On 4/5/19 9:00 AM, Duncan Murdoch wrote:
> 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 <- (delete.response(t1))[-1]
>>
>>   > all.equal(t0x, t1x)
>> [1] TRUE
>>
>> # the above is wrong, because they actually are not the same
>>
>>   > all.equal(attr(t0x, 'dataClasses'), attr(t1x, 'dataClasses'))
>> [1] "Names: 1 string mismatch"
>> [2] "Lengths (1, 2) differ (string compare on first 1)"
>
> As documented, all.equal() is generic, with methods for different classes.  
> The classes 
> of both t0x and t1x are
>
>  c("terms","formula")
>
> with no all.equal.terms method, so all.equal.formula is called. That method 
> isn't 
> specifically documented, but you can see its definition as
>
> function (target, current, ...)
> {
>     if (length(target) != length(current))
>     return(paste0("target, current differ in having response: ",
>     length(target) == 3L, ", ", length(current) == 3L))
>     if (!identical(deparse(target), deparse(current)))
>     "formulas differ in contents"
>     else TRUE
> }
>
> So the issue is that deparse(t0x) and deparse(t1x) give the same strings with 
> no 
> attributes shown, even though "showAttributes" is set by default.   I haven't 
> traced 
> through the C code to see where things are going wrong.
>
> Duncan Murdoch
>
>>
>>   > sessionInfo()
>> R Under development (unstable) (2019-04-05 r76323)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 18.04.2 LTS
>>
>> Matrix products: default
>> BLAS:   /usr/local/src/R-devel/lib/libRblas.so
>> LAPACK: /usr/local/src/R-devel/lib/libRlapack.so
>>
>> locale:
>>    [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>>    [3] LC_TIME=en_US.UTF-8    LC_COLLATE=C
>>    [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>>    [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>>    [9] LC_ADDRESS=C   LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.7.0 tools_3.7.0
>>
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] all.equal failure

[Duncan Murdoch]

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 <- (delete.response(t1))[-1]

  > all.equal(t0x, t1x)
[1] TRUE

# the above is wrong, because they actually are not the same

  > all.equal(attr(t0x, 'dataClasses'), attr(t1x, 'dataClasses'))
[1] "Names: 1 string mismatch"
[2] "Lengths (1, 2) differ (string compare on first 1)"


As documented, all.equal() is generic, with methods for different 
classes.  The classes of both t0x and t1x are


 c("terms","formula")

with no all.equal.terms method, so all.equal.formula is called.  That 
method isn't specifically documented, but you can see its definition as


function (target, current, ...)
{
if (length(target) != length(current))
return(paste0("target, current differ in having response: ",
length(target) == 3L, ", ", length(current) == 3L))
if (!identical(deparse(target), deparse(current)))
"formulas differ in contents"
else TRUE
}

So the issue is that deparse(t0x) and deparse(t1x) give the same strings 
with no attributes shown, even though "showAttributes" is set by 
default.   I haven't traced through the C code to see where things are 
going wrong.


Duncan Murdoch



  > sessionInfo()
R Under development (unstable) (2019-04-05 r76323)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS:   /usr/local/src/R-devel/lib/libRblas.so
LAPACK: /usr/local/src/R-devel/lib/libRlapack.so

locale:
   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
   [3] LC_TIME=en_US.UTF-8    LC_COLLATE=C
   [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
   [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods base

loaded via a namespace (and not attached):
[1] compiler_3.7.0 tools_3.7.0


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] [.terms issue

[Therneau, Terry M., Ph.D. via R-devel]

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 --- but to remove it I need to use [-3] since the 
response 
does not count in [.terms or drop.terms.

Is this an inconsistency that should be documented and/or repaired?   What 
would break if 
we did?    I don't know.  By chance, all the usages in the survival package 
happened after 
a call to delete.response so it would be immune to such a change.

Terry T.


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] attempt to re-insert old removed package

[Georgi Boshnakov]

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
Sent: 05 April 2019 12:53
To: peter dalgaard
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] attempt to re-insert old removed package


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 expect that CRAN policy implies "all" here; I just can't be 
bothered to check...

One important aspect, though, is that 

| > However some small changes to the source were enough to get it installed
| > via R CMD INSTALL, so I thought I might how difficult it would be to get it

may not be enough.  Re-admitting a dead package is closer to admitting a new
package so it is expected to be free and clear of WARNING, NOTE and ERROR too.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[Rd] all.equal failure

[Therneau, Terry M., Ph.D. via R-devel]

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, because they actually are not the same

 > all.equal(attr(t0x, 'dataClasses'), attr(t1x, 'dataClasses'))
[1] "Names: 1 string mismatch"
[2] "Lengths (1, 2) differ (string compare on first 1)"

 > sessionInfo()
R Under development (unstable) (2019-04-05 r76323)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

Matrix products: default
BLAS:   /usr/local/src/R-devel/lib/libRblas.so
LAPACK: /usr/local/src/R-devel/lib/libRlapack.so

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8    LC_COLLATE=C
  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods base

loaded via a namespace (and not attached):
[1] compiler_3.7.0 tools_3.7.0


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Bioc-devel] Package Submission Deadline is TODAY

[Shepherd, Lori]

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 Wednesday April 
24th.

Submit new packages here:  https://github.com/Bioconductor/Contributions

Package submitted after this date or that are submitted but do not pass the 
review process in time can still be accepted to Bioconductor but will be only 
available in the development version until the Fall release.



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Deep Replicable Bug With AMD Threadripper MultiCore

[Tomas Kalibera]

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 base R uses forking 
directly, data.table uses OpenMP). If you think the bug is in base R, it 
would be much better if you could find a reproducible example that would 
only use packages shipped directly with R, otherwise it might be best to 
contact the maintainer of data.table.


Please also make sure to use the latest version of R 3.5 (or R-devel). 
The implementation of forking in parallel packages, and hence also in 
mclapply, has been rewritten since R 3.4.


Best
Tomas

On 4/5/19 1:28 PM, Dirk Eddelbuettel wrote:

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 hangs.  This bug is replicable on an
| AMD Ryzen Threadripper 2950X 16-Core Processor (128GB RAM), running
| latest ubuntu 18.04.  The R version 3.5.3 (2019-03-11) -- "Great Truth" ,
| invoked with --vanilla.  I hope this helps...it took quite a while to get
| it to this stage.  I sure hope that I am not reporting an old bug...
|
| options("mc.cores"=4)
| library(data.table)
| library(parallel)

Just how you set mc.cores to 4 for parallel::mclapply I would try throttling
data.table which in its current version goes for all cores. So do, say,

   setDTthreads(4)

and see if that helps. Try lower and lower values to see if you get by.
While there may well be a different race condition in mclapply, it may help
to not overschedule.

(FWIW, the next version of data.table, in queue at CRAN, is less aggressive
and has additional options for fine tuning.)

Dirk

| if (!file.exists("bugsample.csv")) {
| NR <- 6480
| notused <- data.frame(v1=1:NR, v2=1:NR, v3=1:NR, x1=log(1:NR),
| x2=log(1:NR))
| fwrite(notused, file="bugsample.csv")
| stop("you can quit now and restart the program")
| }
|
| if (!exists("notused")) notused <- fread("bugsample.csv", nrows= Inf)  ##
| needed!  Inf cannot be replaced by actual NR
|
|
| sample <- data.frame( groupidentifier=c( rep(1,2000), rep(2, 4500 )
| ) )
| sample$yvar <- sin(1:nrow(sample))
| sample$xvar <- 1:nrow(sample)
|
|
| testfun <- function(dl) {
| with(dl, message("Working: ", first(groupidentifier), " with ",
| nrow(dl)))
|
| lapply( 1:nrow(dl), FUN=function(onedayindex) {
| if ((onedayindex %% 500) != 0) return(NULL)
| with(dl[1:onedayindex,],
|  c( tryCatch( coef(lm( yvar ~ xvar, data=dl[1:onedayindex,]
| ))[2], error = function(e) NA ) ) )
| })
| }
|
|
| message("starting --- replicable hang with mclapply, but not lapply")
|
| o <- mclapply(split( 1:nrow(sample), sample$groupidentifier ),
|   FUN=function(.index) testfun( sample[.index, , drop=FALSE] ))
|
| message("never gets here with mclapply")
|
| print( do.call("c", o[[1]]) )
| print( do.call("c", o[[2]]) )
|
|
|
| --
| Ivo Welch (ivo.we...@ucla.edu)
|
|   [[alternative HTML version deleted]]
|
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] attempt to re-insert old removed package

[Dirk Eddelbuettel]

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 expect that CRAN policy implies "all" here; I just can't be 
bothered to check...

One important aspect, though, is that 

| > However some small changes to the source were enough to get it installed
| > via R CMD INSTALL, so I thought I might how difficult it would be to get it

may not be enough.  Re-admitting a dead package is closer to admitting a new
package so it is expected to be free and clear of WARNING, NOTE and ERROR too.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] What version does "CRAN check list" refer to ?

[Dirk Eddelbuettel]

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 my old version or the 
current version just released? 
| 
| 
| Package : https://cran.r-project.org/web/packages/geneHummus/index.html 
| CRAN checks : 
https://cran.r-project.org/web/checks/check_results_geneHummus.html

If you look at the package page you see that
 - your new version is the current one _in source form_
 - the binary builds provided are currently _all behind at the previous version_
 - the results page has a version column and is currently mixed

It simply takes 24 to 48 hours for the builds jobs to catch up.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] attempt to re-insert old removed package

[peter dalgaard]

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 
bothered to check...


> On 5 Apr 2019, at 10:24 , Ramón Fallon  wrote:
> 
> 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 R CMD INSTALL, so I thought I might how difficult it would be to get it
> back into the CRAN repo, but I have been able to find procedures for that
> process.
> 
> Any body who has managed this already? Helpful links appreciated, many
> thanks.
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] Deep Replicable Bug With AMD Threadripper MultiCore

[Dirk Eddelbuettel]

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 hangs.  This bug is replicable on an
| AMD Ryzen Threadripper 2950X 16-Core Processor (128GB RAM), running
| latest ubuntu 18.04.  The R version 3.5.3 (2019-03-11) -- "Great Truth" ,
| invoked with --vanilla.  I hope this helps...it took quite a while to get
| it to this stage.  I sure hope that I am not reporting an old bug...
| 
| options("mc.cores"=4)
| library(data.table)
| library(parallel)

Just how you set mc.cores to 4 for parallel::mclapply I would try throttling
data.table which in its current version goes for all cores. So do, say,

  setDTthreads(4)

and see if that helps. Try lower and lower values to see if you get by.
While there may well be a different race condition in mclapply, it may help
to not overschedule.

(FWIW, the next version of data.table, in queue at CRAN, is less aggressive
and has additional options for fine tuning.)

Dirk

| if (!file.exists("bugsample.csv")) {
| NR <- 6480
| notused <- data.frame(v1=1:NR, v2=1:NR, v3=1:NR, x1=log(1:NR),
| x2=log(1:NR))
| fwrite(notused, file="bugsample.csv")
| stop("you can quit now and restart the program")
| }
| 
| if (!exists("notused")) notused <- fread("bugsample.csv", nrows= Inf)  ##
| needed!  Inf cannot be replaced by actual NR
| 
| 
| sample <- data.frame( groupidentifier=c( rep(1,2000), rep(2, 4500 )
| ) )
| sample$yvar <- sin(1:nrow(sample))
| sample$xvar <- 1:nrow(sample)
| 
| 
| testfun <- function(dl) {
| with(dl, message("Working: ", first(groupidentifier), " with ",
| nrow(dl)))
| 
| lapply( 1:nrow(dl), FUN=function(onedayindex) {
| if ((onedayindex %% 500) != 0) return(NULL)
| with(dl[1:onedayindex,],
|  c( tryCatch( coef(lm( yvar ~ xvar, data=dl[1:onedayindex,]
| ))[2], error = function(e) NA ) ) )
| })
| }
| 
| 
| message("starting --- replicable hang with mclapply, but not lapply")
| 
| o <- mclapply(split( 1:nrow(sample), sample$groupidentifier ),
|   FUN=function(.index) testfun( sample[.index, , drop=FALSE] ))
| 
| message("never gets here with mclapply")
| 
| print( do.call("c", o[[1]]) )
| print( do.call("c", o[[2]]) )
| 
| 
| 
| --
| Ivo Welch (ivo.we...@ucla.edu)
| 
|   [[alternative HTML version deleted]]
| 
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[R-pkg-devel] What version does "CRAN check list" refer to ?

[Jose V. Die]

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 released? 


Package : https://cran.r-project.org/web/packages/geneHummus/index.html 
CRAN checks : 
https://cran.r-project.org/web/checks/check_results_geneHummus.html

Best, 
Jose




Jose V. Die, Ph.D.

Departamento de Genética
Escuela Técnica Superior de Ingenieros Agrónomos
Campus de Rabanales
Universidad de Córdoba 

https://jdieramon.github.io

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] attempt to re-insert old removed package

[Ramón Fallon]

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 R CMD INSTALL, so I thought I might how difficult it would be to get it
back into the CRAN repo, but I have been able to find procedures for that
process.

Any body who has managed this already? Helpful links appreciated, many
thanks.

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[Rd] Deep Replicable Bug With AMD Threadripper MultiCore

[ivo welch]

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 Threadripper 2950X 16-Core Processor (128GB RAM), running
latest ubuntu 18.04.  The R version 3.5.3 (2019-03-11) -- "Great Truth" ,
invoked with --vanilla.  I hope this helps...it took quite a while to get
it to this stage.  I sure hope that I am not reporting an old bug...

options("mc.cores"=4)
library(data.table)
library(parallel)

if (!file.exists("bugsample.csv")) {
NR <- 6480
notused <- data.frame(v1=1:NR, v2=1:NR, v3=1:NR, x1=log(1:NR),
x2=log(1:NR))
fwrite(notused, file="bugsample.csv")
stop("you can quit now and restart the program")
}

if (!exists("notused")) notused <- fread("bugsample.csv", nrows= Inf)  ##
needed!  Inf cannot be replaced by actual NR


sample <- data.frame( groupidentifier=c( rep(1,2000), rep(2, 4500 )
) )
sample$yvar <- sin(1:nrow(sample))
sample$xvar <- 1:nrow(sample)


testfun <- function(dl) {
with(dl, message("Working: ", first(groupidentifier), " with ",
nrow(dl)))

lapply( 1:nrow(dl), FUN=function(onedayindex) {
if ((onedayindex %% 500) != 0) return(NULL)
with(dl[1:onedayindex,],
 c( tryCatch( coef(lm( yvar ~ xvar, data=dl[1:onedayindex,]
))[2], error = function(e) NA ) ) )
})
}


message("starting --- replicable hang with mclapply, but not lapply")

o <- mclapply(split( 1:nrow(sample), sample$groupidentifier ),
  FUN=function(.index) testfun( sample[.index, , drop=FALSE] ))

message("never gets here with mclapply")

print( do.call("c", o[[1]]) )
print( do.call("c", o[[2]]) )



--
Ivo Welch (ivo.we...@ucla.edu)

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Parsing code with newlines

[Mikhail Titov]

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 barely mentioned anywhere and longjmp into
terminated setuploop function followed by R_suicide look like a mystery.

Error: bad value
Fatal error: unable to initialize the JIT


That aside, here is the code with newlines that fails to parse. I hope
it will paste alright here.


#include "embeddedRCall.h"
#include 

int
main(int argc, char *argv[])
{
SEXP e, tmp;
int hadError;
ParseStatus status;

init_R(argc, argv);

PROTECT(tmp = mkString("\n\r ls()"));
PROTECT(e = R_ParseVector(tmp, 1, , R_NilValue));
if (status != PARSE_OK)
{
printf("boo boo\n");
}
else
{
PrintValue(e);
R_tryEval(VECTOR_ELT(e,0), R_GlobalEnv, );
}
UNPROTECT(2);

end_R();
return(0);
}


--
Mikhail

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] subscripting a terms object

[Martin Maechler]

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 
untangle.specials 
> routine.   I've spent an evening sorting out the details.



>   1. The delete.response() function doesn't remove the response from the 
dataClasses 
> attribute, which leads to a later failure in [.terms for no-response 
models.  Is there a 
> reason for this, or can I make my patch include this oversight as well?

>  2. [.terms messes up predvars and dataClasses if the model has an offset 
term in it.  
> (In select cases 1 and 2 can cancel out and give the correct dataClasses 
attribute.)

The above two seem interesting and relevant to R itself.
As we've recently just fixed a buglet in  reformulate() --
probably unrelated to your problem --  I'd really be interested to see a
repr.ex. (reproducible example) for the above two statements.

... and if you want also a proposal on how to address the
problem in  delete.response()  and/or  `[.terms`()

Martin

>  3. The survival::untangle.specials routine assumed that you can use the 
same 
> subscripting for the terms of a model and the term() object itself, which 
turns out to be 
> almost always true, but only almost.

>   The failure turns out to have probably been there since the Splus days, 
which tells one 
> just how often such a model is used. (One of two edge case bugs sent to 
me in the first 
> days after I pushed it to CRAN: a new release seems to attact them.)   
I'm willing to put 
> together a patch, but given the rarity of these would folks prefer to 
wait until after the 
> April release?   I'm fine with that.  I need the answer to 1 though.

> Terry T.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Bug in the "reformulate" function in stats package

[Martin Maechler]

> 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 parse_Rd():

Error in 
parse_Rd("/u/maechler/R/D/r-devel/R/src/library/stats/man/delete.response.Rd",  
: 
  Unexpected end of input (in " quoted string opened at 
delete.response.Rd:78:63)
In addition: Warning message:
In 
parse_Rd("/u/maechler/R/D/r-devel/R/src/library/stats/man/delete.response.Rd",  
:
  newline within quoted string at delete.response.Rd:74

and even I needed more than a minute to find out that the
culprit was that

  reformulate(sprintf("`%s`", x))

is not ok in *.Rd  and must be

  reformulate(sprintf("`\%s`", x))

-

  > (I think .txt files work OK as attachments to the list?)   

yes, typically -- what really counts is if your e-mail program
marks them with MIME-type 'text/plain'
and most E-mail programs are very "silly" / "safe" nowadays and
don't expect to have smart users  and hence mark (and sometimes
encode) everything unknown as non-text. 

Using very old flexible e-mail interfaces such as Emacs VM allow
you to specify the MIME-type in addition to the file *and* it
also proposes smart defaults, I think by using something like
unix 'file' to determine that your 'foo.diff' file is plain text.
{{ .. and we all know that Windows is sillily using file extensions
   to determine file type and only knows  Windows-extensions plus
   those added explicitly by software installed; so nowadays *.rda
   is marked as an Rstudio file ... [argh].
}}

Martin

> On 2019-04-04 2:21 a.m., Martin Maechler wrote:
>>> Ben Bolker 
>>> on Fri, 29 Mar 2019 12:34:50 -0400 writes:
>> 
>> > I suspect that the issue is addressed (obliquely) in the examples,
>> > which shows that variables with spaces in them (or otherwise
>> > 'non-syntactic', i.e. not satisfying the constraints of legal R 
symbols)
>> > can be handled by protecting them with backticks  (``)
>> 
>> > ## using non-syntactic names:
>> > reformulate(c("`P/E`", "`% Growth`"), response = as.name("+-"))
>> 
>> > It seems to me there could be room for a *documentation* patch (stating
>> > explicitly that if termlabels has length > 1 its elements are
>> > concatenated with "+", and explicitly stating that non-syntactic names
>> > must be protected with back-ticks).  (There is a little bit of 
obscurity
>> > in the fact that the elements of termlabels don't have to be
>> > syntactically valid names: many will be included in formulas if they 
can
>> > be interpreted as *parseable* expressions, e.g. reformulate("x<2"))
>> 
>> > I would be happy to give it a shot if the consensus is that it would
>> > be worthwhile.
>> 
>> I think it would be worthwhile to add to the docs a bit.
>> 
>> [With currently just your and my vote, we have a 100% consensus
>> ;-)]
>> 
>> Martin
>> 
>> > One workaround to the OP's problem is below (may be worth including
>> > as an example in docs)
>> 
>> >> z <- c("a variable","another variable")
>> >> reformulate(z)
>> > Error in parse(text = termtext, keep.source = FALSE) :
>> > :1:6: unexpected symbol
>> > 1:  ~ a variable
>> > ^
>> >> reformulate(sprintf("`%s`",z))
>> > ~`a variable` + `another variable`
>> 
>> 
>> 
>> 
>> > On 2019-03-29 11:54 a.m., J C Nash wrote:
>> >> The main thing is to post the "small reproducible example".
>> >> 
>> >> My (rather long term experience) can be written
>> >> 
>> >> if (exists("reproducible example") ) {
>> >> DeveloperFixHappens()
>> >> } else {
>> >> NULL
>> >> }
>> >> 
>> >> JN
>> >> 
>> >> On 2019-03-29 11:38 a.m., Saren Tasciyan wrote:
>> >>> Well, first I can't sign in bugzilla myself, that is why I wrote 
here first. Also, I don't know if I have the time at
>> >>> the moment to provide tests, multiple examples or more. If that is 
not ok or welcomed, that is fine, I can come back,
>> >>> whenever I have more time to properly report the bug.
>> >>> 
>> >>> I didn't find the existing bug report, sorry for that.
>> >>> 
>> >>> Yes, it is related. My problem was that I have column names with 
spaces and current solution doesn't solve it. I have a
>> >>> solution, which works for me and maybe also for others.
>> >>> 
>> >>> Either, someone can register me to bugzilla or I can post it here, 
which could give some direction to developers. I
>> >>> don't mind whichever is preferred here.
>> >>> 
>> >>> Best,
>> >>> 
>> >>> Saren
>> >>> 
>> >>> 
>> >>> On 29.03.19 09:29, Martin Maechler wrote:
>> > Saren Tasciyan
>> >  on Thu, 28 Mar 2019 17:02:10