search for: backquotes

Full_Name: Gabor Grothendieck Version: R version 1.9.1, 2004-08-03 OS: Windows XP Submission from: (NULL) (207.35.143.52) The following gives an error: > `a(b)` <- 1:4 > `c(d)` <- (1:4)^2 > lm(`a(b)` ~ `c(d)`) Error in model.matrix.default(mt, mf, contrasts) : model frame and formula mismatch in model.matrix() To fix it replace this line in model.matrix.default:

Hi Folks, Can someone satisfy my curiosity (well, at least about the following query!) Reading the draft proofs of an article I've been asked to look through, I find the typesetter has set what would normally be entered as source("xyz.R") or source('xyz.R') as source(`xyz.R') i.e. it has come out with an opening backquote, then xyz.R, then a closing forward

Thanks to Bill Dunlap for the clarification. On follow-up it turns out that this will be an issue for many if not most of the routines in the survival package: a lot of them look at the terms structure and make use of the dimnames of attr(terms, 'factors'), which also keeps the unneeded backquotes. Others use the term.labels attribute. To dodge this I will need to create a fixterms() routine which I call at the top of every single routine in the library. Is there a chance for a fix at a higher level? Terry T. On 03/05/2018 03:55 PM, William Dunlap wrote: > I believe this has to d...

...e6708ec8a9 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Thu, 15 Mar 2018 18:27:30 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] parser: Fix backquote support in here-document EOF mark Currently using backquotes in a here-document EOF mark is broken because dash tries to do command substitution on it. This patch fixes it by checking whether we're looking for an EOF mark during tokenisation. Reported-by: Harald van Dijk <harald at gigawatt.nl> Signed-off-by: Herbert Xu <herbert at gondor.apan...

...g.au> AuthorDate: Thu, 15 Mar 2018 18:27:30 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:54 +0000 [klibc] dash: parser: Fix backquote support in here-document EOF mark [ dash commit c166b718b496da63c4df7a0972df2fc6cd38256b ] Currently using backquotes in a here-document EOF mark is broken because dash tries to do command substitution on it. This patch fixes it by checking whether we're looking for an EOF mark during tokenisation. Reported-by: Harald van Dijk <harald at gigawatt.nl> Signed-off-by: Herbert Xu <herbert at gondor.apan...

Commit-ID: 42c84c0c2ed8f5b9a81bd70582edfa9d7ead08be Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=42c84c0c2ed8f5b9a81bd70582edfa9d7ead08be Author: Nikolai Merinov <n.merinov at inango-systems.com> AuthorDate: Mon, 29 Apr 2019 19:13:37 +0500 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: expand:

I believe this has to do terms() making "term.labels" (hence the dimnames of "factors") with deparse(), so that the backquotes are included for non-syntactic names. The backquotes are not in the column names of the input data.frame (nor model frame) so you get a mismatch when subscripting the data.frame or model.frame with elements of terms()$term.labels. I think you can avoid the problem by adding right after ll &lt...

I''m trying to stub(!) the Kernel.` (backquote) method and I''m having confusing (to me) results. Here''s the method I''m spec''ing: class Barcode ... def raw_barcodes self.make_temporary_copy `OcrBarcode #{self.temp_file_path}` end ... end And this is my (newbish) attempt at the spec: describe "Calling @barcode.raw_barcodes" do

A user reported a problem with the survdiff function and the use of variables that contain a space.? Here is a simple example.? The same issue occurs in survfit for the same reason. lung2 <- lung names(lung2)[1] <- "in st"?? # old name is inst survdiff(Surv(time, status) ~ `in st`, data=lung2) Error in `[.data.frame`(m, ll) : undefined columns selected In the body of the code

...;>> that >>> this will be an issue for many if not most of the routines in the >>> survival >>> package: a lot of them look at the terms structure and make use of the >>> dimnames of attr(terms, 'factors'), which also keeps the unneeded >>> backquotes. Others use the term.labels attribute. To dodge this I will >>> need to create a fixterms() routine which I call at the top of every >>> single >>> routine in the library. >>> >>> Is there a chance for a fix at a higher level? >>> >>>...

...will be an issue for many if not most of the routines in the >>>> survival >>>> package: a lot of them look at the terms structure and make use of the >>>> dimnames of attr(terms, 'factors'), which also keeps the unneeded >>>> backquotes. Others use the term.labels attribute. To dodge this I will >>>> need to create a fixterms() routine which I call at the top of every >>>> single >>>> routine in the library. >>>> >>>> Is there a chance for a fix at...

That's more or less right. We wrote a terms.merMod method, which accesses the terms component of the @frame slot, which we have modified upstream ... Do you mean term.labels rather than term.names? BTW ?terms.object says (under the "term.labels" element): Non-syntactic names will be quoted by backticks: this makes it easier to re-construct the formula from the term

I''ve done tons of searching on this so I apologize if this is one of those common knowledge things. I am relying on Kernel#` and Kernel#system to run some command line utilities in my Rails app. This worked great until I moved to Apache (win32). When running FCGI, neither of these methods work (both return nil). When running CGI, system seems to work, but ` doesn''t. I have

...rification. On follow-up it turns out that >> this will be an issue for many if not most of the routines in the survival >> package: a lot of them look at the terms structure and make use of the >> dimnames of attr(terms, 'factors'), which also keeps the unneeded >> backquotes. Others use the term.labels attribute. To dodge this I will >> need to create a fixterms() routine which I call at the top of every single >> routine in the library. >> >> Is there a chance for a fix at a higher level? >> >> Terry T. >> >> >>...

...s name fn <- paste(i, ".txt", sep="") # make the filename s <- read.delim(fn, header = FALSE) # now put it all together # …except that I don't want to reassign s, I want to evaluate it and make its value a variable with its own value. } } If this were Lisp I'd use backquotes (or "backticks", as some say) and commas—examples of read macros—to do this, but I can't find anything analogous for R. How might I accomplish this in R? Sincerely, Frank Tamborello, PhD W. M. Keck Postdoctoral Fellow School of Biomedical Informatics University of Texas Health Scien...

Since my previous question didn''t get much attention, I thought I''d make the subject more expressive. I didn''t realize the list had this much traffic. Is anyone using system or "backquote" to run commands in Rails? These work fine in webrick, but both return nil when running in Apache FCGI. In CGI mode, system seems to work, but backquote doesn''t.

Dear R-devel, There is a new feature in R-devel, which explicitly refers to LISP @ operator for splicing. > The backquote function bquote() has a new argument splice to enable splicing a computed list of values into an expression, like ,@ in LISP's backquote. Although the most upvoted SO question asking for exactly LISP's @ functionality in R doesn't seems to be addressed by this

Commit-ID: f7bb177a0dbd9750f78988a3636fa3c32418f6d7 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=f7bb177a0dbd9750f78988a3636fa3c32418f6d7 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Sat, 19 May 2018 02:39:42 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: parser:

Dear List, Is it possible to have function names like ? (unicode universal quantifier)? This question is inspired by agda source code, which supports this. http://www.cs.nott.ac.uk/~nad/listings/lib-0.4/Algebra.html It would be handy to use. My guess is, however, that it's not supportet in R. Regards, Steve

DTraceToolkit has a dtrace script (Proc/pidpersec.d) that refers to a variable mpid as below profile:::tick-1sec { printf("%-22Y %8d %6d\n", walltimestamp, `mpid, pids); pids = 0; } Where is `mpid getting picked from (it isn''t declared anywhere else)? What does the character ` in `mpid signify? I do not see any reference to this variable in the dtrace