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

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

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

> 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

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

> 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

[Bioc-devel] Bioconductor 3.7 is released

Thanks to all the developers for contributing to the project! Full release announcement here: http://bioconductor.org/news/bioc_3_7_release/ The Bioconductor Team This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s),

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

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

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

I have very little knowledge about file encodings and would like to learn more. I've read the following pages to learn more:

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

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

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

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),

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

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

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: [Bioc-devel] The following bioconductor packages have duplicate commits

actually I think I solved it... > On May 1, 2018, at 12:47 PM, Justin Silverman wrote: > > Hi all, > Trying to resolve duplicate commits. Sorry, I feel like I have ignored > a recent email with the same problem as I am about to mention (but I can't > find it)... I

Re: [Bioc-devel] The following bioconductor packages have duplicate commits

Hi all, Trying to resolve duplicate commits. Sorry, I feel like I have ignored a recent email with the same problem as I am about to mention (but I can't find it)... I am having trouble synchronizing with bioconductor remote server. I keep getting permission errorL

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

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

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

> 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

Re: [R-pkg-devel] checksums change after publication on CRAN?

Dear all, 1. CRAN indeed adds the checksum, as CRAN re-packages a package as it changes at least the DESCRIPTION file and maybe cleans up some line endings and permissions etc. 2. For recommdended packages, we publish in the contrib repository, but also for the release tarballs in subdirs

Re: [Bioc-devel] The following bioconductor packages have duplicate commits

Hi, Your package is not cleaned up. According to the link you sent me, it still has duplicate commits. https://github.com/cafletezbrant/flowClean/commits/master Look at commits from oct 7,2016 and earlier. Please take a look at the instructions I sent out along with the initial email and

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

> 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

Re: [Bioc-devel] The following bioconductor packages have duplicate commits

Hello Maintainers, Once you have resolved your package, please let me know both your package name, and GitHub link where your package commit history has been cleaned. Best, Nitesh > On May 1, 2018, at 9:55 AM, Kipper Fletez-Brant > wrote: > > Thanks Nitesh. > >

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

> 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

Re: [Bioc-devel] push access to adaptest

Great — thank you for helping us out with this. Best, Nima On Tue, May 1, 2018 at 5:35 AM Obenchain, Valerie < valerie.obench...@roswellpark.org> wrote: > Nima has been added to adaptest. > > Valerie > > > On 04/30/2018 02:05 PM, WILSON CAI wrote: > > i approve > > On Mon, Apr 30, 2018 at 11:13

Re: [Bioc-devel] Web App for SSH keys

On 04/19/2018 06:29 PM, Leonardo Collado Torres wrote: Hi Valerie, Thanks for the reply and the doc changes ^^. I added a few short replies below. Best, Leo On Thu, Apr 19, 2018 at 4:49 PM, Obenchain, Valerie wrote:

[Rd] issue with model.frame()

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

Re: [Bioc-devel] push access to adaptest

Nima has been added to adaptest. Valerie On 04/30/2018 02:05 PM, WILSON CAI wrote: i approve On Mon, Apr 30, 2018 at 11:13 AM Nima Hejazi wrote: Hello BioC team --- Wilson Cai (cc'd) and I are co-developers / co-authors of the adaptest

[Rd] possible internal (un)tar bug

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 =

Re: [Bioc-devel] Need some help to submit a R package.

The status of your package is unchanged from before; wait for the reviewer to comment further on your package. Martin On 05/01/2018 01:30 AM, Pijush Das wrote: Dear Sir, Please inform me the current status of the package named "sigFeature". The package link is given below.

Re: [Bioc-devel] Suggested edits to support site posting guide

Thanks Leo for the link to April Wensel's blog. I wonder if she is 100% serious with her rant about the Grandma thing but I found it pretty funny! H. On 04/30/2018 01:16 PM, Michael Love wrote: hi Leo, We currently have "Rudeness and ad hominem comments are not acceptable" in the section on

Re: [R-pkg-devel] Byte-compilation problem for R-package ddalpha after update to R 3.5.0

Dear Joris, indeed, the the data sets saved as R-files constituted the issue. As suggested by you, saving them as *.rda helped. Enormous thanks for your prompt and useful advice. The new version of the R-package ddalpha (1.3.3, on CRAN now) causes no problems during the byte-compilation