search for: __no__

...h()#>>> bb is a data.frame search()#-- as it was 'at the beginning' data.class(bb)# "data.frame" data.class(b1)# "list" db1 <- as.data.frame(b1) ##>> Error: no applicable method for "as.data.frame" ## And -- as a matter of fact -- there are __NO__ methods for as.data.frame... ## The following helps: as.data.frame.default <- function (x, row.names = NULL, optional = F, ...) data.frame(x, row.names=row.names, ...) db1 <- as.data.frame(b1) summary(db1) #--> ok attach(bees, pos = 1) search()#- just still at pos = 2 .. attach(be...

...',n,'})\\1', collapse="") ## can have empty n ans <- grep(pattern, txt, value=TRUE, ...) cat(sprintf("pattern '%s' : ", pattern)); print(ans, quote=FALSE) invisible(ans) } grep1r({}, tx)# '.{1,}' : because of _greedy_ matching there is __no__ repetiion! grep1r(100,tx)# i.e., these both give an empty match : character(0) ## matching at most once: grep1r(1, tx)# matches all 5 starting with "foo" grep1r(2, tx)# ditto : all have more than 2 chars grep1r(3, tx)# not "foo": those with more than 3 chars grep1r(4, tx)#...

Dear Sirs, while > regexpr('(.{1,2})\\1', 'foo') [1] 2 attr(,"match.length") [1] 2 attr(,"useBytes") [1] TRUE yields the correct match, an incremented upper bound in > regexpr('(.{1,3})\\1', 'foo') [1] -1 attr(,"match.length") [1] -1 attr(,"useBytes") [1] TRUE incorrectly yields no match. R versions tested: 2.11.1

On Tuesday 10 July 2007 01:38, Scott Michel wrote: > As Chandler pointed out, LL/SC isn't blocking. It belongs to the > optimistic concurrency class of constructs. One of the earliest papers > (IIRC, the first paper) on LL/SC was: > > Herlihy, M. 1993. A methodology for implementing highly concurrent data > objects. ACM Trans. Program. Lang. Syst. 15, 5 (Nov. 1993), 745-770.

...en you are reinventing the wheel, it doesn't give you a dependency on > the wheel, is that what you're saying? No. I'm not saying that at all. If you actually took a look at LLVM, you'd notice that it stands alone. It has very few dependencies upon outside code and it generates __no__ dependencies to outside code or libraries. From previous experience developing for LLVM, I happen to know that unnecessary dependencies are not viewed favorably. > The idea is to review the atomic_ops model, and if it makes sense, just > reuse it. (e.g., atomic_ops seems to have (basic?) su...

Torvald Riegel wrote: > On Monday 09 July 2007 19:33, Scott Michel wrote: >> Torvald Riegel wrote: >>> Hi, >>> >>> I'd like to see support for something like this. I have some comments, >>> and I think there is existing work that you can reuse. >> "reuse within the compiler." > > within the LLVM compiler framework, to be