search for: getencchar

...er with(list(2)...) is allowable; if it is not, it should presumably give an error. If it is, then ls shouldn't have problems with the resulting environment. > qq <- with(list(2),ls()) # An incorrect call (no names in list) > nchar(qq) Error in nchar(qq) : 'getEncChar' must be called on a CHARSXP # ls returned a bad object > qq [1]Error: 'getEncChar' must be called on a CHARSXP > qq[1] [1]Error: 'getEncChar' must be called on a CHARSXP > qq[2] [1] NA Apparently related: > with(list(a=1,2),ls()) Error in ls() : 'getEncChar...

...RSXP' not a 'list' Debugging to find which: i<-1 sip <- unlist(lapply(h,function(r) { i<<-i+1 #debug messages cat(i,"------------------>","\n"); print( r[[2]] ) #debug message r[[2]][['sip']] })) [1]Error in print.default(r[[2]]) : 'getEncChar' must be called on a CHARSXP Which occurs on the 122,204'th item. All entries r[[2]] are similar so I don't know why this happening? The strangest thing is that this error never happened a few days ago and the same code causes this to occur today. Any ideas would be helpful....

...t; shouldn't have problems with the resulting environment. >> >>> qq <- with(list(2),ls()) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 # An incorrect call (no >> >> names in list) >>> >>> nchar(qq) >> >> Error in nchar(qq) : 'getEncChar' must be called on a CHARSXP =A0# ls >> returned >> a bad object >>> >>> qq >> >> [1]Error: 'getEncChar' must be called on a CHARSXP >>> >>> qq[1] >> >> [1]Error: 'getEncChar' must be called on a CHARSXP &gt...

...Device", 1) : Incorrect number of arguments (1), expecting 0 for R_GD_nullDevice > > ## Same call made via a NativeSymbolInfo object: > sym <- getDLLRegisteredRoutines("grDevices")$.Call[["R_GD_nullDevice"]] > .Call(sym$address, 1) Error: 'getEncChar' must be called on a CHARSXP The error stems from the fact, that both do_External and do_dotcall expect CAR(args) to be a string, while it might be a NativeSymbolInfo object. checkValidSymbolId() already handles this, so the fix is to use the symbol name returned from resolveNativeRoutine()....

...years ago, where expanded syntax macros replaced the source code of the macro, but it was a documented, general, and optional part of the macro mechanism. Another little glitch: gg <- quote(x<-44); gg[[2]] <- character(0); eval(gg) Error in eval(expr, envir, enclos) : 'getEncChar' must be called on a CHARSXP This looks like an internal error that users shouldn't see. -s [[alternative HTML version deleted]]

...ot;00\")) ) , avg(NNO3_AT322_OUT_moy) AS Cond FROM Colonne_3 ") > Col3<-sqlQuery(con, query=cat(MyQuery)) SELECT first( format(DateHeure, "00")) ) , avg(NNO3_AT322_OUT_moy) AS Cond FROM Colonne_3 Erreur dans odbcQuery(channel, query, rows_at_time) : 'getEncChar' doit ?tre appel? sur un CHARSXP Do you have any idea on how to proceed? With Best regards Pascal Boisson ___________________________________________________________________________________ Protegeons ensemble l'environnement : avez-vous besoin d'imprimer ce courrier electronique ?...

i wonder about the following examples showing incoherence in how type conversions are done in r: x = TRUE x[2] = as.raw(1) # Error in x[2] = as.raw(1) : # incompatible types (from raw to logical) in subassignment type fix it seems that there is an attempt to coerce the raw value to logical here, which fails, even though as.logical(as.raw(1)) # TRUE likewise, x[2]

i wonder about the following examples showing incoherence in how type conversions are done in r: x = TRUE x[2] = as.raw(1) # Error in x[2] = as.raw(1) : # incompatible types (from raw to logical) in subassignment type fix it seems that there is an attempt to coerce the raw value to logical here, which fails, even though as.logical(as.raw(1)) # TRUE likewise, x[2]

Full_Name: Wacek Kusnierczyk Version: 2.8.0 and 2.10.0 r48163 OS: Ubuntu 8.04 Linux 32bit Submission from: (NULL) (129.241.198.172) the following code illustrates a problem with sprintf which consistently causes a segfault when applied to certain type of arguments. it also shows inconsistent consequences of the segfault: (e = tryCatch(stop(), error=identity)) # e is an error object

...4 e7 7f d9 f4 50 77 5c 19 a9 e0 b9 5e b2 dd 60 79 6c 13 ad 1e 17 98 11 1c [376] 91 db e5 5f 7e df 0f e7 43 57 c9 7d 01 6c 3e 1a 5d 0c 2f ab 99 6e a9 a8 88 [401] 57 1c 35 5a 7c 03 73 22 e4 b1 R-2.10.1 RC produces the following equally enigmatic output: > match(v,"") NULL Fehler: 'getEncChar' muss für CHARSXP aufgerufen werden So my provisional guess is the bug is somewhere in the part of the internal code for sub which is invoked whatever the value of fixed or perl. It is strange though that it makes a difference whether you specify fixed = TRUE or not. George Russell Prof...