Re: [Rd] issue with model.frame()

2018-05-01 Thread Therneau, Terry M., Ph.D. via R-devel
I want to add that the priority for this is rather low, since we have a couple of work arounds for the user/data set in question. I have some ideas about changing the way in which ridge() works, which might make the problem moot. The important short-term result was finding that it wasn't an er

Re: [Rd] issue with model.frame()

2018-05-01 Thread Berry, Charles
> On May 1, 2018, at 1:15 PM, Martin Maechler > wrote: > > What version of R is that ? Sorry. It was 3.4.2. But it doesn't matter, because my diagnosis was wrong even there. I think (based on my reading of my outdated version) the problem is a bit upstream in terms() as I noted in a follow

Re: [Rd] issue with model.frame()

2018-05-01 Thread Martin Maechler
> Berry, Charles > on Tue, 1 May 2018 16:43:18 + writes: >> On May 1, 2018, at 6:11 AM, Therneau, Terry M., Ph.D. via R-devel wrote: >> >> A user sent me an example where coxph fails, and the root of the failure is a case where names(mf) is not equal to the term.la

Re: [Rd] source(echo = TRUE) with a iso-8859-1 encoded file gives an error

2018-05-01 Thread Ista Zahn
Hi Scott, This question is appropriate for the r-help mailing list, but probably off-topic here on r-devel. Best, Ista On Tue, May 1, 2018 at 2:57 PM, Scott Kostyshak wrote: > I have very little knowledge about file encodings and would like to > learn more. > > I've read the following pages to

[Rd] source(echo = TRUE) with a iso-8859-1 encoded file gives an error

2018-05-01 Thread Scott Kostyshak
I have very little knowledge about file encodings and would like to learn more. I've read the following pages to learn more: https://urldefense.proofpoint.com/v2/url?u=http-3A__stat.ethz.ch_R-2Dmanual_R-2Ddevel_library_base_html_Encoding.html&d=DwIDAw&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpW

Re: [Rd] [EXTERNAL] Re: issue with model.frame()

2018-05-01 Thread Berry, Charles
Unfortunately, I spoke too soon. model.frame calls formula <- terms(formula, data = data) if formula does not inherit from class "terms" as in your case. And that is where the bad terms.labels attribute comes from. So, the fix I suggested won't work. But maybe you can just supply a terms objec

Re: [Rd] issue with model.frame()

2018-05-01 Thread William Dunlap via R-devel
You run into the same problem when using 'non-syntactical' names: > mfB <- model.frame(y ~ `Temp(C)` + `Pres(mb)`, data=data.frame(check.names=FALSE, y=1:10, `Temp(C)`=21:30, `Pres(mb)`=991:1000)) > match(attr(terms(mfB), "term.labels"), names(mfB)) # gives NA's [1] NA NA > attr(terms(mfB), "ter

Re: [Rd] [EXTERNAL] Re: issue with model.frame()

2018-05-01 Thread Therneau, Terry M., Ph.D. via R-devel
Great catch. I'm very reluctant to use my own model.frame, since that locks me into tracking all the base R changes, potentially breaking survival in a bad way if I miss one. But, this shows me clearly what the issue is and will allow me to think about it. Another solution for the user is to

Re: [Rd] debugonce() functions are not considered as debugged

2018-05-01 Thread Gabe Becker
Gabor, Others can speak to the origins of this more directly, but from what I recall this has been true at least since I was working in this space on the debugcall stuff a couple years ago. I imagine the reasoning is what you would expect: a single bit of course can't tell R both that a function

Re: [Rd] possible internal (un)tar bug

2018-05-01 Thread Martin Maechler
TLDR: Use gzfile(), not file() .. and you have no problems. > Martin Maechler > on Tue, 1 May 2018 16:39:57 +0200 writes: > Martin Maechler > on Tue, 1 May 2018 16:14:43 +0200 writes: > Gábor Csárdi > on Tue, 1 May 2018 12:05:32 + writes: >>> Th

Re: [Rd] issue with model.frame()

2018-05-01 Thread Berry, Charles
> On May 1, 2018, at 6:11 AM, Therneau, Terry M., Ph.D. via R-devel > wrote: > > A user sent me an example where coxph fails, and the root of the failure is a > case where names(mf) is not equal to the term.labels attribute of the formula > -- the latter has an extraneous newline. Here is an

Re: [Rd] possible internal (un)tar bug

2018-05-01 Thread Martin Maechler
> Martin Maechler > on Tue, 1 May 2018 16:14:43 +0200 writes: > Gábor Csárdi > on Tue, 1 May 2018 12:05:32 + writes: >> This is a not too old R-devel on Linux, it already fails >> in R 3.4.4, and on macOS as well. > and fails in considerably older R vers

Re: [Rd] possible internal (un)tar bug

2018-05-01 Thread Martin Maechler
> Gábor Csárdi > on Tue, 1 May 2018 12:05:32 + writes: > This is a not too old R-devel on Linux, it already fails > in R 3.4.4, and on macOS as well. and fails in considerably older R versions, too. Basically untar() seems to fail on a connection, but works fine on a pl

[Rd] issue with model.frame()

2018-05-01 Thread Therneau, Terry M., Ph.D. via R-devel
A user sent me an example where coxph fails, and the root of the failure is a case where names(mf) is not equal to the term.labels attribute of the formula -- the latter has an extraneous newline. Here is an example that does not use the survival library. # first create a data set with many lon

[Rd] possible internal (un)tar bug

2018-05-01 Thread Gábor Csárdi
This is a not too old R-devel on Linux, it already fails in R 3.4.4, and on macOS as well. The tar file seems valid, external tar can untar it, so maybe an untar() bug. setwd(tempdir()) dir.create("pkg") cat("foobar\n", file = file.path("pkg", "NAMESPACE")) cat("this: that\n", file = file.path("