Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encoding on windows #9

Open
sckott opened this issue Sep 18, 2014 · 19 comments
Open

encoding on windows #9

sckott opened this issue Sep 18, 2014 · 19 comments
Labels
Milestone

Comments

@sckott
Copy link
Owner

sckott commented Sep 18, 2014

Hey @noamross @richfitz @trinker @leeper

We're having problems with this pkg on windows. E.g.,

screen shot 2014-09-18 at 8 58 48 am

But on unix does

say("asdfsf", "longcat", length = 4)

 ----- 
 asdfsf 
 ------ 
    \   
     \
    .ハ,,ハ
    ( ゚ω゚)
    |つ  つ
    |    |
    |    |
    |    |
    |    |
    U " U

This is what longcat is in the pkg:

  longcat <-
    '
\n ----- \n %s \n ------ \n    \\\   \n     \\\
    .\uFF8A,,\uFF8A
    ( \uFF9F\u03C9\uFF9F)
    |\u3064  \u3064
%s
    U " U
    '

Any way to fix this to work on windows?

@sckott sckott added the bug label Sep 18, 2014
@leeper
Copy link
Contributor

leeper commented Sep 19, 2014

No solution, but returning a character string and printing with cat works in Rgui but not the console. E.g., cat(say("asdfsf", "longcat", length = 4, type="string")). So clearly Rgui is doing something to unicode character strings that it does not do under message/warning/error and R itself does not do at all.

@sckott
Copy link
Owner Author

sckott commented Sep 19, 2014

thanks @leeper - will keep digging

@sckott
Copy link
Owner Author

sckott commented Sep 28, 2014

@gavinsimpson any help on the encoding issue on Windows?

@richfitz
Copy link
Contributor

Sorry, Scott, I don't currently have access to a windows box

@sckott
Copy link
Owner Author

sckott commented Nov 4, 2014

meh, maybe we'll just put this on CRAN and say it doesn't work on Windows, seem okay @leeper @richfitz @gavinsimpson

@leeper
Copy link
Contributor

leeper commented Nov 4, 2014

I don't have time at the moment to try to figure it out, so that's fine.
Maybe putting it on CRAN will catch the attention of someone who can make
it work.

On Tue, Nov 4, 2014 at 5:13 AM, Scott Chamberlain [email protected]
wrote:

meh, maybe we'll just put this on CRAN and say it doesn't work on Windows,
seem okay @leeper https://github.com/leeper @richfitz
https://github.com/richfitz @gavinsimpson
https://github.com/gavinsimpson


Reply to this email directly or view it on GitHub
#9 (comment).

@sckott
Copy link
Owner Author

sckott commented Nov 5, 2014

Poll:

doesn't work:

@ateucher
Copy link
Contributor

ateucher commented Feb 6, 2015

I think the pertinent information is in here: http://cran.cnr.berkeley.edu/doc/manuals/r-devel/R-ints.html#Encodings-for-CHARSXPs.

Basically it seems like, on Windows, functions which use C code like message and warning can't properly deal with UTF-8 strings due to the Windows C compiler. It looks like cat and print have some sort of escape which gets around this... which is consistent with what @leeper observed (I experienced the same behaviour).

capture

I played around with iconv a bit to no avail. I don't think you can catch and modify a message or warning after it's called and before it's printed?

@sckott
Copy link
Owner Author

sckott commented Feb 6, 2015

@ateucher what if you use type="string", then call message(), etc. manually after it comes back? does that work okay?

@ateucher
Copy link
Contributor

ateucher commented Feb 6, 2015

Nope. I think as soon as message/warning get hold of it, it kills it:
capture

@sckott
Copy link
Owner Author

sckott commented Feb 6, 2015

okay, boo, well, not sure what to do then.

could just not use unicode characters and use the closest ascii characters...but you've kind of solved this another way by not using those that have unicode on windows

@ateucher
Copy link
Contributor

ateucher commented Feb 6, 2015

Yeah, could do gsub on the \u strings only if os == windows. But I wouldn't want to do it wholesale and make them look worse for everybody else. Some of those might be hard to find decent replacements for though!

@sckott
Copy link
Owner Author

sckott commented Feb 6, 2015

i think maybe we should just go with the solution you've already done - and push to CRAN!

@ateucher
Copy link
Contributor

ateucher commented Feb 6, 2015

Agreed! It does function on Windows, so we should go for it.

@sckott sckott modified the milestone: v1 Feb 6, 2015
@ateucher
Copy link
Contributor

ateucher commented Feb 8, 2015

So I guess this isn't really fixed yet - the appveyor build is failing on the examples using non-ascii characters (anxiouscat). Would you want to put those in a dontrun section?

@sckott
Copy link
Owner Author

sckott commented Feb 8, 2015

@ateucher it seems like its an issue with the match.arg https://ci.appveyor.com/project/sckott/cowsay/build/1.0.218#L366 or am i looking at it wrong

@ateucher
Copy link
Contributor

ateucher commented Feb 8, 2015

It is, but because on Windows get_who() removes anxiouscat etc from the vector whose names are used in match.arg. That's why they all work on Linux/Mac, but the animals with non-ASCII throw an error on Windows.

@sckott
Copy link
Owner Author

sckott commented Feb 8, 2015

I'll just remove the examples that don't work on windows...

@ateucher
Copy link
Contributor

ateucher commented Feb 8, 2015

Yeah, good idea. That's the simplest solution

sckott added a commit that referenced this issue Feb 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants