StatTag fails to run UTF-8 encoded files with umlaut characters

[mronkko]

I am linking to test case. This runs well in Rstudio, but causes an error in StatTag

https://nextcloud.jyu.fi/index.php/s/NHp6dRLbqoQyCQT

[lrasmus]

Thanks for reporting and providing example!

[lrasmus]

This one seems a bit tricker. This also affects our Windows version (similar problem reported in the RDotNet library). This needs a resolution, but I know I didn't have any luck when looking on the Windows side, and imagine the same thing is occurring here.

[mronkko]

If this cannot be easily solved, one workaround would be to provide the user a more informative error message. For example, when adding R files to StatTag, you could check for non-ASCII characters and warn the user that the file is likely to cause problems. This could be an interim solution until a proper fix is developed.

It took me a couple of hours to figure out that the non-ASCII characters was the problem. Getting a warning would have saved me that time and would have been useful.

[lrasmus]

@mronkko - thanks again for your helpful feedback! I spent some time trying to resolve the underlying issue, but will proceed with your suggested workaround for now.

An interesting thing I found is that it's not specifically the presence of non-ASCII characters. It appears to be just when assigning it to a variable. For example, this works:

##>>>ST:Value(Label="test", Frequency="On Demand", Type="Default", Decimals=0, Thousands=False)
q <- paste('красавица Наталья', 'Un apôtre', 'äbcd')
q
##<<<

But this fails:

##>>>ST:Value(Label="test", Frequency="On Demand", Type="Default", Decimals=0, Thousands=False)
ä <- paste('красавица Наталья', 'Un apôtre', 'äbcd')
ä
##<<<

[mronkko]

That will work. I do not think that limiting variable names to ASCII characters is a big issue, as long as the user is aware of it. I assume you will be publishing an updated version soon.