similar to: Error

Displaying 20 results from an estimated 10000 matches similar to: "Error"

2010 Sep 03
1
Weird erratic error and illogical error message, could someone explain this?
Hello, It's several days I try to track this bug, and even cannot cook a reproducible example. Yet, it occurs consistently in a long-running task after a variable period of time. Here is an example: ... my long-running code [as I said, cannot give something simple that produces this bug in a reproducible manner] Error in match(x, table, nomatch = 0L) : formal argument
2008 Jun 19
2
Pattern Matching Replacement
I would like to replace "\r\n" with "" in a character string, where "\r\n" exists only between < and >, how could I do that? Initial: characterString = "<XML><tag1 id=\"F\r\n2\"></t\r\nag1>\r\n<tag\r\n2></tag2></XML>" Result: characterString = "<XML><tag1
2008 Mar 06
1
Argument "nomatch" matched by multiple actual arguments ... %in% -> match?!?
When I run R CMD check R.oo on R v2.7.0 devel (2008-03-04 r44677) on WinXP I get the following error while testing examples: Error in match(x, table, nomatch = 0) : formal argument "nomatch" matched by multiple actual arguments Calls: setMethodS3 -> setMethodS3.default -> %in% -> match Execution halted How is that even possible with: > get("%in%") function (x,
2008 Jun 17
2
try catch block
How can I use the try catch block such that if this statement fails xml <- xmlTreeParse(xmlTxt, useInternal=TRUE) then this statement is executed xml <- xmlMalFormed() ? This code does not work but assuming its somewhere along these lines: tryCatch(xml <- xmlTreeParse(xmlTxt, useInternal=TRUE), xml <- xmlMalFormed(f1)) -- View this message in context:
2008 Jun 17
1
Scan document including "\n"
How do you read in a whole file while preserving end of line "\n" characters? Basically, read in a whole file as one string. Ex: <XML> <TAG> </TAG> </XML> After this file is read into a variable, it should really look like "<XML>\n<TAG>\n</TAG>\n</XML>\n" -- View this message in context:
2008 Jun 10
1
Parse XML
Could someone provide a link or examples of parsing XML document in R? Few specific questions below: For instance I can retrieve specific nodes using this: node <- xpathApply(xml, "//" %+% xtag, xmlValue) 1) I want to be able to retrieve parent node for this node, how can I do this? getParentNode() does not seem to cut it. 2) How can I retrieve children nodes for a particular
2019 Aug 15
2
Feature request: non-dropping regmatches/strextract
I do think keeping the default behavior is desirable for backwards compatibility; my suggestion is not to change default behavior but to add an optional argument that allows a different behavior. Although this can be implemented in a user-defined function, retaining empty matches facilitates programmatic use, and seems to be something that should be available in base R. It is available, for
2016 Feb 19
2
Grandstream Early Dial
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bryant, Thanks for your reply. It didn't work immediately, I had to create a second context, or else it was looping between the second and first line. This seems to work: [earlydial] ; Test Early Dial exten => _.,1,Set(l_Extension=${EXTEN}) exten => _.,n,Goto(earlydial2,${l_Extension},1) [earlydial2] exten => _.,n,Goto(noMatch,1)
2016 Sep 10
1
table(exclude = NULL) always includes NA
Looking at the code of function 'table' in R devel r71227, I see that the part "remove NA level if it was added only for excluded in factor(a, exclude=.)" is not quite right. In is.na(a) <- match(a0, c(exclude,NA), nomatch=0L) , I think that what is intended is a[a0 %in% c(exclude,NA)] <- NA . So, it should be is.na(a) <- match(a0, c(exclude,NA),
2000 Nov 20
2
precision, incorrect(?) tapply() NA's
Hi, Summary: I ran into some unexpected behavior in approx() and tapply() that introduced NA's in "clean" data due to (?) numerical accuracy/round off. The culprit seems to be in match() that coerces it's arguments to character, loosing precision in the process. [R development version 1.2.0, 08 Nov 2000, on Linux] Example: > r > [1] 0.6931472 0.6931472 0.6931472
2000 Nov 20
2
precision, incorrect(?) tapply() NA's
Hi, Summary: I ran into some unexpected behavior in approx() and tapply() that introduced NA's in "clean" data due to (?) numerical accuracy/round off. The culprit seems to be in match() that coerces it's arguments to character, loosing precision in the process. [R development version 1.2.0, 08 Nov 2000, on Linux] Example: > r > [1] 0.6931472 0.6931472 0.6931472
2007 May 02
2
I need help
hello, I need help because I don't understand the syntaxe "else" how can I write it for example I writed a script to cut missings values and I have errors > if(na==length(C)){ + pos=match(0,match(donGeno[[na-1]],donGeno[[na]],nomatch=0)) + for(k in 1:(na-1)) { + if(pos==1) {donGeno[[k]] <-
2022 Mar 14
1
Icecast 2.5 beta3 release
Good morning, the Icecast Project is very pleased to have released the next beta of Icecast, version 2.5 beta3. As this is a beta usage in production should be with caution. Please see the full news entry linked below for details. New features (extract): * Overall * Improved relay configuration including multi-upstream support * Improved directory configuration including updated
2022 Mar 14
1
Icecast 2.5 beta3 release
Good morning, the Icecast Project is very pleased to have released the next beta of Icecast, version 2.5 beta3. As this is a beta usage in production should be with caution. Please see the full news entry linked below for details. New features (extract): * Overall * Improved relay configuration including multi-upstream support * Improved directory configuration including updated
2010 Aug 10
1
partial match of one column in data frame to another character vector
Here is some data (dput output below) > myData id group 1 D599 A 2 002-0004 B 3 F01932 A 18 F16 B 19
2022 Mar 16
1
Icecast 2.5 beta3 release
Hello, is there any plan for a binary (windows systems) release for the beta 3 or shall I wait for the public release out of beta stage? Thank you Best regards Il giorno lun 14 mar 2022 alle ore 11:59 Philipp Schafft < phschafft at de.loewenfelsen.net> ha scritto: > Good morning, > > the Icecast Project is very pleased to have released the next beta > of Icecast, version 2.5
2022 Mar 16
1
Icecast 2.5 beta3 release
Hello, is there any plan for a binary (windows systems) release for the beta 3 or shall I wait for the public release out of beta stage? Thank you Best regards Il giorno lun 14 mar 2022 alle ore 11:59 Philipp Schafft < phschafft at de.loewenfelsen.net> ha scritto: > Good morning, > > the Icecast Project is very pleased to have released the next beta > of Icecast, version 2.5
2008 Sep 12
1
match and incomparables
Hello, I was playing around with the newly implemented 'incomparables' argument in 'match' and realized the argument does not behave anything like I expected. Can someone explain what is going on here? Sorry if I'm misreading the documentation. > match(1:3, 1:3, incomparables=1) [1] NA 2 3 # This seems right, the 1 in 'x' is 'incomparable' >
2010 Jun 29
2
POSIXlt matching bug
I came across the below mis-feature/bug using match with POSIXlt objects (from strptime) in R 2.11.1 (though this appears to be an old issue). > x <- as.POSIXlt(Sys.Date()) > table <- as.POSIXlt(Sys.Date()+0:5) > length(x) [1] 1 > x %in% table # I expect TRUE [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE > match(x, table) # I expect 1 [1] NA NA NA NA NA NA NA NA
2015 Jan 23
1
:: and ::: as .Primitives?
Hi, On 01/23/2015 07:01 AM, luke-tierney at uiowa.edu wrote: > On Thu, 22 Jan 2015, Michael Lawrence wrote: > >> On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: >>> >>> For default methods there ought to be a way to create those so the >>> default method is computed at creation or load time and stored in an >>>