Re: [Haskell] ANNOUNCE: jhc 0.7.4
On Sat, Jul 10, 2010 at 1:47 AM, John Meacham
Announcing jhc 0.7.4! There have been a few major changes, the main one being that there is now support for a garbage collector. This drastically increases the number of programs which are feasable to compile with jhc.
Hi John, This looks fantastic and fun to play with. A few issues: * running DrIFT on src/E/TypeCheck.hs fails with an illegal bytesequence in hGetContents. I'm guessing that this is only an issue when building DrIFT with GHC 6.12+, and that the file contains bytes illegal in UTF8. I deleted everything funny looking in the file and then it went smooth * The way you use sed doesn't work with the BSD sed that ships with my Mac Book. Installing GNU sed and using it works. Similarly, BSD find doesn't know about '-name', so make hl-clean results in sadness. * jhci works great, but jhc crashes when I try to compile something:
jhc test1.hs jhc 0.7.4 (tokfekyuvi-27) Finding Dependencies... Using Ho Cache: '/Users/alatter/.jhc/cache' Main [test1.hs] Typechecking... [1 of 1] Main (.............................................) test1.hs:9 - Warning: defaulting: t93 => Jhc.Basics.Integer Compiling... [1 of 1] Main <..................................................> Collected Compilation... -- typeAnalyzeMethods -- BoxifyProgram -- Boxy WorkWrap -- LambdaLift E jhc: <stdout>: hPutChar: invalid argument (Illegal byte sequence) <<<<<
Again, this seems like the handle is in UTF8 mode and we're trying to output something non-UTF8. * cabal install has a --jhc flag, but it doesn't seem to work:
cabal install byteorder --jhc Resolving dependencies... cabal: internal error: impossible <<<<< I have jhc installed in a non-standard location (under ${HOME}/usr) so I may need to have some environment variables set up. This is wil Cabal 1.8.0.4 and cabal-install 0.8.2
Keep up the good work! I have an implementation for STRefs I threw together this afternoon for jhc if you're interested. I can't test it properly, though, with the compiler crash above. Antoine
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/10 17:01 , Antoine Latter wrote:
* The way you use sed doesn't work with the BSD sed that ships with my Mac Book. Installing GNU sed and using it works. Similarly, BSD find doesn't know about '-name', so make hl-clean results in sadness.
Haven't looked at sed, but "-name" should work in any version of find. Are you sure about this? (maybe I'll suck down the source and audit for platform compatibility) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw44tgACgkQIn7hlCsL25WPQQCg12qq6Snxmpyuxweb56HJul5g GhwAnRu2zM0TWMJKUtY0OT76+vlF6GHY =6lf6 -----END PGP SIGNATURE-----
Brandon S Allbery KF8NH wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/10/10 17:01 , Antoine Latter wrote:
* The way you use sed doesn't work with the BSD sed that ships with my Mac Book. Installing GNU sed and using it works. Similarly, BSD find doesn't know about '-name', so make hl-clean results in sadness.
Haven't looked at sed, but "-name" should work in any version of find. Are you sure about this?
FWIW -name (and -iname) are supported by OSX-10.5 find. And it seems really odd to imagine a find that wouldn't support them... -- Live well, ~wren
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/10 17:15 , Brandon S Allbery KF8NH wrote:
Haven't looked at sed, but "-name" should work in any version of find. Are you sure about this?
(maybe I'll suck down the source and audit for platform compatibility)
Makefile.in, lines 865, 903, 907: "find -wholename" isn't portable. Makefile.in, line 93 and many others: combining commands with ";" is unreliably portable outside of a {;,,,;} construct (and portable to SVR4 only with the extra semicolons as shown above; GNU usually lets you omit them). Use multiple -e options instead. Also, all of the "find" invocations assume the default action is "-print"; this will silently fail on Solaris and other commercial Unixes based on SVR4. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw4/7cACgkQIn7hlCsL25XQugCdHazbd782RJEaM5zL64R1WhTm 2UcAoMrdqQEtzTw9Zh7FpKuPaqQ7rdck =Dq+I -----END PGP SIGNATURE-----
On Sat, Jul 10, 2010 at 07:18:15PM -0400, Brandon S Allbery KF8NH wrote:
On 7/10/10 17:15 , Brandon S Allbery KF8NH wrote: Makefile.in, lines 865, 903, 907: "find -wholename" isn't portable.
Hmm.. I'll have to find a work around for that.
Makefile.in, line 93 and many others: combining commands with ";" is unreliably portable outside of a {;,,,;} construct (and portable to SVR4 only with the extra semicolons as shown above; GNU usually lets you omit them). Use multiple -e options instead.
Hmm.. I am not sure where you mean, the Makefile.in is generated by automake and will be regenerated by autoreconf, where in the Makefile.am (which I wrote) are you refering to?
Also, all of the "find" invocations assume the default action is "-print"; this will silently fail on Solaris and other commercial Unixes based on SVR4.
Cool. fixed these. -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/10 20:09 , John Meacham wrote:
On Sat, Jul 10, 2010 at 07:18:15PM -0400, Brandon S Allbery KF8NH wrote:
On 7/10/10 17:15 , Brandon S Allbery KF8NH wrote: Makefile.in, lines 865, 903, 907: "find -wholename" isn't portable.
Hmm.. I'll have to find a work around for that.
Since you're not using (and don't need) -0, piping through grep should do fine.
Makefile.in, line 93 and many others: combining commands with ";" is unreliably portable outside of a {;,,,;} construct (and portable to SVR4 only with the extra semicolons as shown above; GNU usually lets you omit them). Use multiple -e options instead.
Hmm.. I am not sure where you mean, the Makefile.in is generated by automake and will be regenerated by autoreconf, where in the Makefile.am (which I wrote) are you refering to?
I'll have to look for the concordance; I also want to look more closely at the sed commands, as I *think* the semicolon usage should work on at least FreeBSD and OSX (no promises about Net- or Open-). - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw5DocACgkQIn7hlCsL25W3GgCdGwJCq4x1NOJPuweo/K4zplkF us0AoLI5lCt88C631K9FsT6ZQoMhWELk =hhNF -----END PGP SIGNATURE-----
On Sat, Jul 10, 2010 at 4:15 PM, Brandon S Allbery KF8NH
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7/10/10 17:01 , Antoine Latter wrote:
* The way you use sed doesn't work with the BSD sed that ships with my Mac Book. Installing GNU sed and using it works. Similarly, BSD find doesn't know about '-name', so make hl-clean results in sadness.
Haven't looked at sed, but "-name" should work in any version of find. Are you sure about this?
(maybe I'll suck down the source and audit for platform compatibility)
Here's the 'sed' error:
sed -e 's/^{-# OPTIONS[A-Z_]*/{-# OPTIONS_GHC -w /' -i src/FrontEnd/HsParser.hs sed: -i may not be used with stdin <<<<<
I don't know what's wrong with find on my Mac - I'm running 10.6, and 'which find' tells me I'm running from /usr/bin/find, which I haven't messed with. It isn't build critical, though. Antoine
- -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkw44tgACgkQIn7hlCsL25WPQQCg12qq6Snxmpyuxweb56HJul5g GhwAnRu2zM0TWMJKUtY0OT76+vlF6GHY =6lf6 -----END PGP SIGNATURE----- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/10 23:55 , Antoine Latter wrote:
Here's the 'sed' error:
> sed -e 's/^{-# OPTIONS[A-Z_]*/{-# OPTIONS_GHC -w /' -i src/FrontEnd/HsParser.hs sed: -i may not be used with stdin
Aha. "in-place sed" is a GNU-ism, although NetBSD and FreeBSD ports have native "sed_inplace". Most portable is to sed to a temp file and rename, or use an ed script. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw5QmcACgkQIn7hlCsL25XM2gCgpHim5UGl1J5ictN3HrKIAsqy 8kQAn28xZuT07Vdyad00rk3+fPaJOt9q =VYLC -----END PGP SIGNATURE-----
On Sat, Jul 10, 2010 at 10:55:14PM -0500, Antoine Latter wrote:
Here's the 'sed' error:
sed -e 's/^{-# OPTIONS[A-Z_]*/{-# OPTIONS_GHC -w /' -i src/FrontEnd/HsParser.hs sed: -i may not be used with stdin <<<<<
I just removed the sed command, it was just to suppress a bunch of warnings. I am not sure what OSX's sed had an issue with actually.
I don't know what's wrong with find on my Mac - I'm running 10.6, and 'which find' tells me I'm running from /usr/bin/find, which I haven't messed with. It isn't build critical, though.
I switch the -wholename to -path which my 10.5.8 OSX seems to think is okay and it works on linux. It isn't in the POSIX standard but appears widely supported. I was able to run and compile jhc on my 10.5.8 box, and run the regression test. but when the garbage collector is enabled (enabled with -fjgc) it doesn't work because posix_memalign does not exist. Can you check whether -fjgc works on 10.6? I wish I had some way to regression test OSX builds as part of my standard pre-release tests. Hmm... Windows cross compiling seems a little broken too, but the fix looks easy. I can add windows compilation to the regression test thankfully due to wine so I can fix it for the next release. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/11/10 00:10 , John Meacham wrote:
I switch the -wholename to -path which my 10.5.8 OSX seems to think is okay and it works on linux. It isn't in the POSIX standard but appears widely supported.
SVR4 find doesn't support either option, sadly. Then again, you may not care about Solaris or HP at this point.
I was able to run and compile jhc on my 10.5.8 box, and run the regression test. but when the garbage collector is enabled (enabled with -fjgc) it doesn't work because posix_memalign does not exist. Can you
http://stackoverflow.com/questions/196329/osx-lacks-memalign - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw5RPwACgkQIn7hlCsL25WxugCgpCyUEWnpCjP9cNFEN4BP1V1z LngAn2WsutlcGGIqjY8DgyPYzY2SpN3q =Yi9P -----END PGP SIGNATURE-----
On Sun, Jul 11, 2010 at 12:13:48AM -0400, Brandon S Allbery KF8NH wrote:
On 7/11/10 00:10 , John Meacham wrote:
I switch the -wholename to -path which my 10.5.8 OSX seems to think is okay and it works on linux. It isn't in the POSIX standard but appears widely supported.
SVR4 find doesn't support either option, sadly. Then again, you may not care about Solaris or HP at this point.
Hey, I used to work for sun on solaris :) Actually, I won't worry about it for now. It is fairly common to have gnu tools available on solaris machines, if it comes up again, I'll look into making an autoconf macro to find a working find or complain appropriately. It is only relevant for people compiling from the darcs repository and not the tarball so it isn't a huge issue.
I was able to run and compile jhc on my 10.5.8 box, and run the regression test. but when the garbage collector is enabled (enabled with -fjgc) it doesn't work because posix_memalign does not exist. Can you
http://stackoverflow.com/questions/196329/osx-lacks-memalign
Hmm.. but this pages seems to indicate it may exist on 10.6, In any case, I can work around missing it at the cost of some wasted memory. http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPag... John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/11/10 00:26 , John Meacham wrote:
On Sun, Jul 11, 2010 at 12:13:48AM -0400, Brandon S Allbery KF8NH wrote:
On 7/11/10 00:10 , John Meacham wrote:
I switch the -wholename to -path which my 10.5.8 OSX seems to think is okay and it works on linux. It isn't in the POSIX standard but appears widely supported.
SVR4 find doesn't support either option, sadly. Then again, you may not care about Solaris or HP at this point.
Hey, I used to work for sun on solaris :) Actually, I won't worry about
You *really* don't want to see what Horricle has done to poor old Sun. :( De facto, many of us have given up on it.
I was able to run and compile jhc on my 10.5.8 box, and run the regression test. but when the garbage collector is enabled (enabled with -fjgc) it doesn't work because posix_memalign does not exist. Can you
http://stackoverflow.com/questions/196329/osx-lacks-memalign
Hmm.. but this pages seems to indicate it may exist on 10.6, In any case, I can work around missing it at the cost of some wasted memory.
mress:50014 Z$ nm /System/Library/Frameworks/System.framework/System|grep mema 00000000000425a9 T _malloc_zone_memalign 00000000000dd5d8 T _posix_memalign 00000000000e1047 t _purgeable_memalign 000000000003b233 t _szone_memalign
...yep, looks as if.
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPag...
John
- -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw5SeoACgkQIn7hlCsL25UsGQCgzxBAhm/EuMrw7ljz7TYIb7Rr thoAmQFxxedFHZwmVDkhN8iOzI/kaSi4 =M3g7 -----END PGP SIGNATURE-----
On Sat, Jul 10, 2010 at 04:01:53PM -0500, Antoine Latter wrote:
* running DrIFT on src/E/TypeCheck.hs fails with an illegal bytesequence in hGetContents. I'm guessing that this is only an issue when building DrIFT with GHC 6.12+, and that the file contains bytes illegal in UTF8. I deleted everything funny looking in the file and then it went smooth
Hi, are you compiling from the tarball or the darcs repository? the tarball shouldn't require DrIFT to be installed. I had not tested DrIFT with 6.12 but that file should be in UTF8. Hmm... on OSX, is the default locale a UTF8 one? does ghc 6.12 properly encode to/from utf8 on it by defualt? could you check, I don't have a mac handy.
* The way you use sed doesn't work with the BSD sed that ships with my Mac Book. Installing GNU sed and using it works. Similarly, BSD find doesn't know about '-name', so make hl-clean results in sadness.
Hmm.. yeah, this has been reported before, but I was unable to reproduce the problem. But I may have accidentally been using a GNU sed, my mac at the time was highly gnu-ized. Could you send me a version that works.
* jhci works great, but jhc crashes when I try to compile something:
jhc test1.hs jhc 0.7.4 (tokfekyuvi-27) Finding Dependencies... Using Ho Cache: '/Users/alatter/.jhc/cache' Main [test1.hs] Typechecking... [1 of 1] Main (.............................................) test1.hs:9 - Warning: defaulting: t93 => Jhc.Basics.Integer Compiling... [1 of 1] Main <..................................................> Collected Compilation... -- typeAnalyzeMethods -- BoxifyProgram -- Boxy WorkWrap -- LambdaLift E jhc: <stdout>: hPutChar: invalid argument (Illegal byte sequence) <<<<<
Again, this seems like the handle is in UTF8 mode and we're trying to output something non-UTF8.
Hmm.. clearly something about the locale is wrong... It is outputing a unicode character there, but it shoudl translate adn display to utf8 just fine. perhaps ghc is not actually opening utf8 handles on your platform...
* cabal install has a --jhc flag, but it doesn't seem to work:
cabal install byteorder --jhc Resolving dependencies... cabal: internal error: impossible <<<<< I have jhc installed in a non-standard location (under ${HOME}/usr) so I may need to have some environment variables set up. This is wil Cabal 1.8.0.4 and cabal-install 0.8.2
The cabal support for jhc never worked actually, it wasn't written by me. There really isn't any easy way to integrate cabal with jhc right now, and even if there was, all of hackage has ghc specific dependencies. No doubt the solution to this problem will be involved, I have conciously decided to not think about the issue until I have full haskell 2010 support down pat. That will be more useful for writing portable programs in the short run.
Keep up the good work!
I have an implementation for STRefs I threw together this afternoon for jhc if you're interested. I can't test it properly, though, with the compiler crash above.
Try without the '-v' flag, it shouldn't try printing the non ascii character then. or modify src/Stats.hs and replacet all the C.<char> constants with ascii equivalants. If there is a good way to test whether the terminal supports non-ascii characters, that would be good to put a test in jhc for. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
John Meacham wrote:
On Sat, Jul 10, 2010 at 04:01:53PM -0500, Antoine Latter wrote:
* running DrIFT on src/E/TypeCheck.hs fails with an illegal bytesequence in hGetContents. I'm guessing that this is only an issue when building DrIFT with GHC 6.12+, and that the file contains bytes illegal in UTF8. I deleted everything funny looking in the file and then it went smooth
Hi, are you compiling from the tarball or the darcs repository? the tarball shouldn't require DrIFT to be installed. I had not tested DrIFT with 6.12 but that file should be in UTF8. Hmm... on OSX, is the default locale a UTF8 one? does ghc 6.12 properly encode to/from utf8 on it by defualt? could you check, I don't have a mac handy.
Generally OSX takes UTF16 to be the standard encoding (I don't recall if it's LE or BE), though UTF8 is supported almost everywhere. I haven't checked to see whether that would affect this particular task though. -- Live well, ~wren
On Sat, Jul 10, 2010 at 05:38:02PM -0400, wren ng thornton wrote:
John Meacham wrote:
On Sat, Jul 10, 2010 at 04:01:53PM -0500, Antoine Latter wrote:
* running DrIFT on src/E/TypeCheck.hs fails with an illegal bytesequence in hGetContents. I'm guessing that this is only an issue when building DrIFT with GHC 6.12+, and that the file contains bytes illegal in UTF8. I deleted everything funny looking in the file and then it went smooth
Hi, are you compiling from the tarball or the darcs repository? the tarball shouldn't require DrIFT to be installed. I had not tested DrIFT with 6.12 but that file should be in UTF8. Hmm... on OSX, is the default locale a UTF8 one? does ghc 6.12 properly encode to/from utf8 on it by defualt? could you check, I don't have a mac handy.
Generally OSX takes UTF16 to be the standard encoding (I don't recall if it's LE or BE), though UTF8 is supported almost everywhere. I haven't checked to see whether that would affect this particular task though.
Console IO should use the multibyte encoding, which is different than the wide encoding used in some places. Hmm.. on my OSX system the standard multibyte coding appears to be utf8. when you type 'locale' what shows up for LC_CTYPE? mine is en_US.UTF-8, if you set it to a utf8 locale, does jhc work properly? John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On Jul 11, 2010, at 9:38 AM, wren ng thornton wrote:
Generally OSX takes UTF16 to be the standard encoding (I don't recall if it's LE or BE), though UTF8 is supported almost everywhere. I haven't checked to see whether that would affect this particular task though.
Mac OS X 10.5 came with a lot of locales, including a lot of UTF-8 ones. Indeed, the default was a UTF-8 one. But it didn't come with *any* UTF-16 locales. (As tested by 'locale -a'.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/12/10 22:29 , Richard O'Keefe wrote:
On Jul 11, 2010, at 9:38 AM, wren ng thornton wrote:
Generally OSX takes UTF16 to be the standard encoding (I don't recall if it's LE or BE), though UTF8 is supported almost everywhere. I haven't checked to see whether that would affect this particular task though.
Mac OS X 10.5 came with a lot of locales, including a lot of UTF-8 ones. Indeed, the default was a UTF-8 one. But it didn't come with *any* UTF-16 locales. (As tested by 'locale -a'.)
wren is half right: at the level of Unixy APIs (and this includes anything that goes on in a Terminal window and anything that you will be doing from Haskell) you use UTF8, but OSX APIs --- that is, Carbon and Cocoa --- use UTF16. So for the purposes of ghc/jhc OSX is UTF8, but if someone wrote a "fully native" Cocoa-based runtime it would use UTF16. (Compare Win32 APIs to mingw APIs; very similar situation.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw8kXcACgkQIn7hlCsL25XMBwCghhWYpvyhhpG5L3tnOZQcJPIQ h8oAnA5c5kCbrjtD5bMe/yAyw/BDUTAl =p0QN -----END PGP SIGNATURE-----
wren is half right: at the level of Unixy APIs (and this includes anything that goes on in a Terminal window and anything that you will be doing from Haskell) you use UTF8, but OSX APIs --- that is, Carbon and Cocoa --- use UTF16. So for the purposes of ghc/jhc OSX is UTF8, but if someone wrote a "fully native" Cocoa-based runtime it would use UTF16. (Compare Win32 APIs to mingw APIs; very similar situation.)
I guess the question here is what it _means_ to say that "the standard encoding" is UTF-8 or UTF-16 or anything else. I took it to be an *external* property: "what is the expected/best supported encoding for *user* data". By that criterion, the only standard encoding for Mac OS X 5 would appear to be UTF-8; it did not come with any support for *user* data in UTF-16. If the question means "what is the encoding used by the kernel, or by the native interfaces to the kernel", that gets a different answer. I've now lost track: what did the original poster mean?
Brandon S Allbery KF8NH wrote:
wren is half right: at the level of Unixy APIs (and this includes anything that goes on in a Terminal window and anything that you will be doing from Haskell) you use UTF8, but OSX APIs --- that is, Carbon and Cocoa --- use UTF16. So for the purposes of ghc/jhc OSX is UTF8, but if someone wrote a "fully native" Cocoa-based runtime it would use UTF16. (Compare Win32 APIs to mingw APIs; very similar situation.)
Yeah, I've been doing too much Cocoa lately ;) Unfortunately, certain parts of Cocoa aren't UTF16, which is annoying. Standard terminal stuff should all be UTF8 though. -- Live well, ~wren
On Sat, Jul 10, 2010 at 4:33 PM, John Meacham
On Sat, Jul 10, 2010 at 04:01:53PM -0500, Antoine Latter wrote:
* running DrIFT on src/E/TypeCheck.hs fails with an illegal bytesequence in hGetContents. I'm guessing that this is only an issue when building DrIFT with GHC 6.12+, and that the file contains bytes illegal in UTF8. I deleted everything funny looking in the file and then it went smooth
Hi, are you compiling from the tarball or the darcs repository? the tarball shouldn't require DrIFT to be installed. I had not tested DrIFT with 6.12 but that file should be in UTF8. Hmm... on OSX, is the default locale a UTF8 one? does ghc 6.12 properly encode to/from utf8 on it by defualt? could you check, I don't have a mac handy.
Okay, I was using a third-party terminal app for which I don't know how to make print out UTF8. Things are better if I use a different one. I was going to look in to how to make DrIFT read and write UTF8 regardless of locale, but the IO layer for DrIFT is surprisingly complex, so never mind that. Now compiling with jhc I end up with: hs.out_code.c:85:2: error: #error Could not determine Byte Order Attached is a patch which fixes this for me, although I only have a Mac to test it on. Antoine
On Sun, Jul 11, 2010 at 01:20:26AM -0500, Antoine Latter wrote:
Now compiling with jhc I end up with: hs.out_code.c:85:2: error: #error Could not determine Byte Order
Attached is a patch which fixes this for me, although I only have a Mac to test it on.
Interesting. can you send me some information on your system? like the output of 'uname -a' and 'gcc --version'? Thanks for the patch, I'll apply it. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On 11 July 2010 07:46, John Meacham
On Sun, Jul 11, 2010 at 01:20:26AM -0500, Antoine Latter wrote:
Now compiling with jhc I end up with: hs.out_code.c:85:2: error: #error Could not determine Byte Order
Attached is a patch which fixes this for me, although I only have a Mac to test it on.
Interesting. can you send me some information on your system? like the output of 'uname -a' and 'gcc --version'?
FWIW I had the same problem. Mac OS X 10.6.4: """ $ uname -a Darwin REDACTED.ac.uk 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 $ gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. """ Cheers, Max
I think the default locale of the terminal app on snow leopard is utf-8.
I can also report that I have no problem compiling the tar version of
jhc 0.7.4 on snow leopard 10.6.4 using ghc 6.12.1, need to install the
editline package though.
On Sun, Jul 11, 2010 at 5:33 AM, John Meacham
On Sat, Jul 10, 2010 at 04:01:53PM -0500, Antoine Latter wrote:
* running DrIFT on src/E/TypeCheck.hs fails with an illegal bytesequence in hGetContents. I'm guessing that this is only an issue when building DrIFT with GHC 6.12+, and that the file contains bytes illegal in UTF8. I deleted everything funny looking in the file and then it went smooth
Hi, are you compiling from the tarball or the darcs repository? the tarball shouldn't require DrIFT to be installed. I had not tested DrIFT with 6.12 but that file should be in UTF8. Hmm... on OSX, is the default locale a UTF8 one? does ghc 6.12 properly encode to/from utf8 on it by defualt? could you check, I don't have a mac handy.
* The way you use sed doesn't work with the BSD sed that ships with my Mac Book. Installing GNU sed and using it works. Similarly, BSD find doesn't know about '-name', so make hl-clean results in sadness.
Hmm.. yeah, this has been reported before, but I was unable to reproduce the problem. But I may have accidentally been using a GNU sed, my mac at the time was highly gnu-ized. Could you send me a version that works.
* jhci works great, but jhc crashes when I try to compile something:
> jhc test1.hs jhc 0.7.4 (tokfekyuvi-27) Finding Dependencies... Using Ho Cache: '/Users/alatter/.jhc/cache' Main [test1.hs] Typechecking... [1 of 1] Main (.............................................) test1.hs:9 - Warning: defaulting: t93 => Jhc.Basics.Integer Compiling... [1 of 1] Main <..................................................> Collected Compilation... -- typeAnalyzeMethods -- BoxifyProgram -- Boxy WorkWrap -- LambdaLift E jhc: <stdout>: hPutChar: invalid argument (Illegal byte sequence) <<<<<
Again, this seems like the handle is in UTF8 mode and we're trying to output something non-UTF8.
Hmm.. clearly something about the locale is wrong... It is outputing a unicode character there, but it shoudl translate adn display to utf8 just fine. perhaps ghc is not actually opening utf8 handles on your platform...
* cabal install has a --jhc flag, but it doesn't seem to work:
> cabal install byteorder --jhc Resolving dependencies... cabal: internal error: impossible <<<<< I have jhc installed in a non-standard location (under ${HOME}/usr) so I may need to have some environment variables set up. This is wil Cabal 1.8.0.4 and cabal-install 0.8.2
The cabal support for jhc never worked actually, it wasn't written by me. There really isn't any easy way to integrate cabal with jhc right now, and even if there was, all of hackage has ghc specific dependencies. No doubt the solution to this problem will be involved, I have conciously decided to not think about the issue until I have full haskell 2010 support down pat. That will be more useful for writing portable programs in the short run.
Keep up the good work!
I have an implementation for STRefs I threw together this afternoon for jhc if you're interested. I can't test it properly, though, with the compiler crash above.
Try without the '-v' flag, it shouldn't try printing the non ascii character then. or modify src/Stats.hs and replacet all the C.<char> constants with ascii equivalants. If there is a good way to test whether the terminal supports non-ascii characters, that would be good to put a test in jhc for.
John
-- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- jinjing
participants (7)
-
Antoine Latter -
Brandon S Allbery KF8NH -
Jinjing Wang -
John Meacham -
Max Bolingbroke -
Richard O'Keefe -
wren ng thornton