Output character encoding for ghc on OpenBSD

Simon Marlow marlowsd at gmail.com
Mon Apr 19 09:57:00 EDT 2010


On 18/04/2010 19:22, Matthias Kilian wrote:
> Hi,
>
> On Sun, Apr 18, 2010 at 10:53:22AM -0700, Judah Jacobson wrote:
>>> Anyway, the short story is that I have to either hard-code the
>>> character set to something like utf-8, or ghc will start to behave
>>> really strange (for example, ghci would terminate immediately if
>>> you just *type* a non-ASCII character).
>>
>> That sounds like it might be something to do with the haskeline
>> package, which ghci uses for user interaction.  Haskeline makes its
>> own FFI calls to translate raw input bytes into Unicode Chars.
>
> Oh, this may indeed be a second problem. However, the encoding
> problem itself also manifests in the `openTempFile001' test of the
> testsuite.  For example, with an unpatched ghc-6.12, the test fails
> with the following output:
>
> =====>  openTempFile001(normal) 1048 of 2375 [0, 38, 0]
> cd ./lib/IO&&  '/usr/obj/ports/ghc-6.12.2/ghc-6.12.2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf  -dno-debug-output -o openTempFile001 openTempFile001.hs>openTempFil
> e001.comp.stderr 2>&1
> cd ./lib/IO&&  ./openTempFile001</dev/null>openTempFile001.run.stdout 2>openTempFile001.run.stderr
> Wrong exit code (expected 0 , actual 1 )
> Stdout:
>
> Stderr:
> openTempFile001: ./test22236.txt: hClose: invalid argument (Illegal byte sequence)
>
> *** unexpected failure for openTempFile001(normal)

A few of the tests in the test suite assume a UTF-8 locale, so you're 
probably falling foul of that.  We could fix the tests - but we do want 
to test that the locale encoding is being respected in some way, so just 
adding hSetEncoding to those tests would be wrong.

Or you could just make those tests an expected failure on OpenBSD for 
the time being.

For the IO library, I expect you should default the encoding to Latin-1 
on OpenBSD.

Cheers,
	Simon


More information about the Glasgow-haskell-users mailing list