similar to: Joining elements of an array into a single element

Having a hard time understanding the help files for tryCatch. Looking for a little help with the following statement which sits inside a for loop zest[i] <- tryCatch(sapply(getNodeSet(zdoc, "//zestimate/amount"), xmlValue), error=function() zest[i] <-"NA") zest is a numeric vector If the sapply statement evaluates to an error, I'd like to set the value of zest[i]

Can't seem to get the code below working. It gets stuck on line 24 inside the function hm; comments show the line in question. The function hm is called by sapply and is at the bottom of the code. Other stuff above line 24 works correctly including the first couple of lines of the function hm. Should I be using a different apply function or am I doing something wrong with xmlTreeParse ?

Question for all: Right now i have a Table in a mySQL DB that has a row called Ingredients. When the data is entered into the DB its enter like so from a text area: 1 1/2 lbs. beef top sirloin, thinly sliced 1/3 cup white sugar 1/3 cup rice wine vinegar 2 tablespoons frozen OJ concentrate 1 teaspoon salt 1 tablespoon soy sauce 1 cup long grain rice 2 cups water 1/4 cup cornstarch 2 teaspoons

glm(A~B+C+D+E+F,family = binomial(link = "logit"),data=tre,na.action=na.omit) Error in `contrasts<-`(`*tmp*`, value = "contr.treatment") : contrasts can be applied only to factors with 2 or more levels however, glm(A~B+C+D+E,family = binomial(link = "logit"),data=tre,na.action=na.omit) runs fine glm(A~B+C+D+F,family = binomial(link =

Thanks Tomas. Do note that my original post also mentioned a bug or doc error in the PCRE docs for this regexp: > - perl = TRUE does *not* give the documented result on at least one > system (which is "123456789", because "{,5}" is documented to not be a > quantifier, so it should only match the literal string "{,5}"). Duncan On 2024-08-01 6:49 a.m.,

Hi all, I'm on Ubuntu 18.04, running R-4.0.0 which I compiled from source, and using valgrind I am always seeing the following message. Does anybody else see that? Is that a known false positive? Any ideas how to fix/suppress? Seems related to TRE, do I need to upgrade that? (base) tdhock at maude-MacBookPro:~/R/binsegRcpp$ R --vanilla -d valgrind -e 'extSoftVersion()' ==9565==

Hello the list, As a simple example: > rm(list = ls())> setClass("tre", representation(x="numeric"))> setMethod("show", "tre", def = function(object) cat(object@x))[1] "show"> setMethod("summary", "tre", def = function(object) cat("This is a tre of value ", object@x, "\n"))Creating a generic

On 8/1/24 20:55, Duncan Murdoch wrote: > Thanks Tomas.? Do note that my original post also mentioned a bug or > doc error in the PCRE docs for this regexp: > >> ? - perl = TRUE does *not* give the documented result on at least one >> system (which is "123456789", because "{,5}" is documented to not be >> a quantifier, so it should only match the

On 5/30/23 17:45, Ben Bolker wrote: > Inspired by this old Stack Overflow question > > https://stackoverflow.com/questions/19765610/when-does-locale-affect-rs-regular-expressions > > > I was wondering why this is TRUE: > > Sys.setlocale("LC_ALL", "et_EE") > grepl("[A-Z]", "T") > > TRE's documentation at >

>>>>> Vinh Nguyen <vinhdizzo at gmail.com> >>>>> on Thu, 8 Oct 2015 20:21:32 -0700 writes: > Ahh, sorry for not googling the error message. Found > [this](http://r.789695.n4.nabble.com/Error-compiling-R-2-10-1-on-AIX-td1017862.html) > post that suggests modifying /src/extra/tre/tre-internal.h >

Each of the following calls crash ("core dumps") R (R --vanilla) on various versions and OSes: regexpr("a{2-}", "") sub("a{2-}", "") gsub("a{2-}", "") EXAMPLES: > sessionInfo() R version 2.11.1 Patched (2010-09-16 r52949) Platform: i386-pc-mingw32 (32-bit) ... > regexpr("a{2-}", "") Assertion

Each of the following calls crash ("core dumps") R (R --vanilla) on various versions and OSes: regexpr("a{2-}", "") sub("a{2-}", "") gsub("a{2-}", "") EXAMPLES: > sessionInfo() R version 2.11.1 Patched (2010-09-16 r52949) Platform: i386-pc-mingw32 (32-bit) ... > regexpr("a{2-}", "") Assertion

Ok, found the problem - on platforms that support it TRE uses wint_t (from wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed* int. TRE uses liberally conversions between int and tre_cint_t apparently assuming that the latter is unsigned so conversions back to int are suitable for comparisons etc. On other platforms wint_t is unsigned so it works. Manually defining tre_cint_t

Hello, I have a question about margins when plotting an unrooted tree (type="unrooted") with the 'ape' package ver. 1.7. When I plot an unrooted tree with: no.margin=TRUE it seems that the margins are still there. It appears to be only when type="unrooted". I'm plotting multiple plots using layout() and would like to be able to get rid of the margins or if

The issue seems related to R bug report 15012: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15012 As mentioned in the comments there, a pull request to the TRE library has recently been made, but I don't know about its status. Daniel ________________________________________ Von: R-devel <r-devel-bounces at r-project.org> im Auftrag von Tomas Kalibera <tomas.kalibera at

Very timely, as this is how I got into the problem I posted about earlier; maybe some of the problems I ran into will mean more to the you and the experts on this thread, Dr. Murdoch.For reference, I run Windows 7 64bit, and I am trying to build a 64 bit version of R-3.1.2. As we discussed offline, Dr. Murdoch, I've been trying to build R using more recent tools than GCC4.6.3 prerelease.

This seems to be a problem that goes back a long time - and I hope someone who understands what tre is suppossed to be doing will look at this. A short history of other people who have reported on this on different versions of AIX. I shall only add that I get the same results on AIX 5.3 TL7, AIX 6.1 TL9 and AIX 7.1 TL3. Basically, with settings that work for AIX and 32-bit - the only changes

Inspired by this old Stack Overflow question https://stackoverflow.com/questions/19765610/when-does-locale-affect-rs-regular-expressions I was wondering why this is TRUE: Sys.setlocale("LC_ALL", "et_EE") grepl("[A-Z]", "T") TRE's documentation at <https://laurikari.net/tre/documentation/regex-syntax/> says that a range "is shorthand for

On 2015-12-30 09:58, Michael Felt wrote: > On 2015-12-29 11:02, Michael Felt wrote: >> This seems to be a problem that goes back a long time - and I hope >> someone who understands what tre is suppossed to be doing will look >> at this. >> >> A short history of other people who have reported on this on >> different versions of AIX. I shall only add that I

On 2016-01-01 23:48, peter dalgaard wrote: > Nice catch you two!!! > > Happy New Year > -pd I am much happier with this great start! Simon - which compiler)s) did you use: xlc and xlfortran, or gcc/gfortran? I have made some changes to configure(.ac) so maybe my problems are self-inflicted. But would be good to know what environment you are using. Thanks for looking - and