Tristan Allwood wrote:

I've been playing around with hs-curses and utf8, and have discovered
that I need to use an ffi call at the top of my main to
setlocale(LC_ALL, "") in order to get the hscurses bindings to display
utf8-encoded strings correctly.

If I understand correctly, the fact that I need to do this means that
the ghc rts is either not setting the default locale, or is forcing it
to be a c-style one.  With that as my context I'm just wondering:

a) if this is a known issue

b) if there's a known work-around other than rolling your own ffi
    wrapped call (a library function that I'm not aware of)

c) any side effects this might have elsewhere

d) if I'm being stupid and could get this to work by just using env vars

Correct, the RTS does not set the locale. It used to at one stage, when we used the C isw* functions to implement Data.Char.isAlpha and so on, but now we use our own Unicode tables so we don't need to set the locale.

There probably ought to be a way to call setlocale via System.Posix, but it doesn't look like there is yet.

Setting the locale *might* have side-effects, for instance we noticed before that heap profiling broke in some locales because the RTS code to generate the .hp file was using fprintf to print numbers, and the number format depends on the locale. Strictly speaking this is a bug in GHC, we should be generating the heap profile data in a fixed known format. If this happens to you, please file a ticket.

Cheers,
        Simon

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to