R pander doesn't show result with accentuated character - r

I've worked for some months with pander/rmarkdown/rstudio without problem, but on this new machine, something as simple as
library(pander)
cars$test="qsdféé"
pander(cars)
give me back "Error in table.expand(x, t.width, justify, sep.col) :
basic_string::_S_create"
I don't understand, because on my previous machine, it works without a flaw.
Same pander version (0.6.0), same configuration of Rstudio (default encoding utf-8), windows 7 on both sides.
It's quite strange because pander has no problem if I have only one accentuated character (car$test="qsdfé") but it's the second that trigger the problem.
In rmarkdown, it makes the compiler stop instantly, with no error message.

This is a bug, which doesn't have a solution (other than reverting R-version) as of now. There is an open issue on github: Link
Issue #296

Related

R I want to remove those red lines

I want to remove those red lines in r studio.
I upgraded to the latest version, according to someone's suggestion.
But it is not working.
The problem occurs when I write Korean words.
The default encoding is UTF-8.
I found a similar problem here, but it didn't work for me.
https://community.rstudio.com/t/why-and-where-is-a-an-unexpected-token-in-r-and-how-should-i-deal-with-it/26496/4
df$번호
df$이름
df$성별
This is a bug -- unfortunately, the RStudio diagnostics system does not correctly handle multibyte characters in R Markdown documents on Windows. This will hopefully be fixed in the next release (v1.3).

Output/the next command prompt overwrites long command in R

I'm seeing a very strange issue with R (v 3.3.2, running on the command line of a CentOS 7 linux box). If I execute a command that goes over one line in the terminal, the output appears at the beginning of the second line of the command. This didn't happen with previous versions of R, though it does happen with later versions I've installed. I am using Putty as the terminal, but it also happens if I use xterm.
To describe it better, it looks like this:
> tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaal=1 [before hitting enter]
> tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaal=1 [after enter, typing overwrites the a's now]
If the multiline command outputs something, that output occurs on the second line and overwrites the a's. If there is an error, then the error message terminates properly and the next prompt follows the error message. So does anyone have any ideas? Thanks in advance!
Update: After some more experimenting, I've found another odd behavior. If I use CTRL-R to search for a previous multiline command, and then execute it, the output or subsequent prompt appears at the same location in the command as where the cursor was. Here's another example:
(reverse-i-search)`1':tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaal=1[cursor on one before hitting enter]
[hit enter and then:]
>tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaal=1
aaaaaaaaal=>
Pretty strange. Hard to describe so its hard to find any evidence of other problems like this on stack-exchange or elsewhere. My feeling is it has to do with the readline library but it is strange because this doesn't happen in the shell command line, only in R as far as I can tell.
Update 2: I've found a potentially more revealing way to replicate this issue. If you manually add a bunch of newlines (by jamming CTRL-V CTRL-J repeatedly), then hit enter, the next prompt jumps right back up to underneath the last one. This is not what happens in the underlying shell (bash for me), or in previous versions of R that I can check.
Just to have the answer out there in case anyone else has this issue, the problem was that my system was using an old version of the readline library, 6.2, and the issue disappeared when updating it to the current version, 7.0. So it would seem that even though later versions of R will install with the outdated readline, they don't exactly work correctly.

gsub error message when addressing column in dataframe in RStudio

Since a couple of days I get the following error message in RStudio from time to time and can't figure out what is causing it.
When I write in the console window to address a data.frame followed by $ to address a specific column in the data.frame (for example df$SomeVariable), the following message is shown in the console window and is printed over an over with every letter I type
Error in gsub(reStrip, "", completions, perl = TRUE) :
input string 38 is invalid UTF-8
The error message doesn't have any real effect. Everything works just fine except the automatic completion of the variable name.
I'm using R version 3.4.4 and RStudio Version 1.0.143 on a Windows computer. In the R script I am currently working on I don't use gsub or any other "string" or regular expression function for that matter. The issue appeared with various data.frames and various types of variables in the data.frames (numeric, integer, date, factor, etc.). It also happens with various packages. Currently, I am using combinations of the packages readr, dplyr, plm, lfe, readstata13, infuser, and RPostgres. The issue disappears for a while after closing RStudio and opening it again but re-appears after working for a while.
Does anyone have an idea what may cause this and how to fix it?
I used to have the same problem a few days ago. I made some research and i found that when you import the dataset, you can change the encoding. Change the encoding to "latin1" and maybe that could fix your problem. Sorry for my poor english, im from Southamerica. Hope it works.

r plot shows up only when I type in console but not in script

I ran into a very weird problem: my R code for generating a plot only works if I type it into the console but not when I ran it inside the script (with Ctrl+Enter command)... It's the same problem with all plots (regular plots or ggplots). Also I tried it on two different computers and the same thing happened. Anyone have any idea why this is happening?
One possible reason: I installed the newest version of Rstudio on both computers so it might be an issue with the version. The exact same code worked before on an older version of rstudio...Could this be it? If so, how can I fix it?
I think I figured out what the problem was: the setting in the new version of Rstudio has a default option of outputting the plots inside the Rmarkdown script (at the very end of the script). And that's why I wasn't seeing them. You could change the setting such that it outputs in the console.
Try dev.off() to reset the graphics device.
This helps with a lot of weird graphics behaviour.
Probably too late for the original poster... However, I just ran into the same problem after installing an R update. The way I fixed it was to go to preferences, R markdown, and turn off "show inline output". For me, it was just coming out at the bottom of the chunk instead of in the plot window like I wanted. Hope that helps someone!
I just ran into this problem. I mistakenly put my plot() command inside the r markdown setup chunk. I moved it to its own code chunk and it ran as expected.

Error: invalid multibyte character in parser at line 1 and stop

Described as title, R stopped with the following error message:
Error: invalid multibyte character in parser at line 1
Usually, the error message emerges intermittently during R usage and it's hard to pin point the cause. Sometimes it pops up when I turn to R (using Rstudio) and the process stops.
I have tried reinstalling R, Rstudio, JDK maybe 5 times... to no avail.
source("Function.R", encoding="utf-8")
Please use 0.98 verion even though this version has a little problem with Data Viewer. https://support.rstudio.com/hc/en-us/articles/206569407-Older-Versions-of-RStudio. This is the known problem as posted by Josée Martens https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/rropen/o8Xhjo0Zes0/P8C0Wb56CAAJ
tool->global option ->code->saving-> default text encoding:UTF-8
use library(KoNLP)
rewrite r script without Korean
I succeed step no.3
Try updating your RStudio via "Tools" -> "Check for Package Updates", as shown in the screenshot below,and you may solve your problem.

Resources