RE: Template Haskell and the command line
Simon M has persuaded me that -D/-U are really cpp-specific flags. What's to stop you using the environment variables directly? Suppose you had getEnvVar :: String - Q (Maybe String) which is pretty much what System.getEnv does. Would that do the job? Then you could say DEBUG=yes ghc -fth Foo.hs Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of George Russell | Sent: 02 December 2003 15:32 | To: [EMAIL PROTECTED] | Subject: Template Haskell and the command line | | Template Haskell is frightfully good and we want to get rid of cpp and | use it instead, but there's one tiny problem, namely that for cpp it | is possible to define variables on the command line (-DSIMON=MARLOW and so | on) while with Template Haskell it doesn't seem to be. Could there be | some kind of dictionary, like the cpp environment variables, which the | Template Haskell code has access to? | | One obvious way would be to accept the -D/-U arguments, and provide Haskell | functions which look at them. | | Of course one /could/ presumably use System.getArgs and analyse the arguments | to ghc oneself, but that would mean making guesses about the current GHC syntax. | | In the meantime we shall still replace cpp with Template Haskell, but find | another way. Thanks for Template Haskell! | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: To show or not to show french accents
Hallo! On Thu, Dec 18, 2003 at 01:55:27PM +0100, [EMAIL PROTECTED] wrote: Well, I think there should probably be some internationalisation mechanism that tells the show function (to name one), according to some configuration, how to interpret a byte as a character. My understanding is that `show' should work with `read' and possibly produce output that can be parsed by the Haskell parser. It is not a pretty printing function. Frankly, I see no good reason why we should be satisfied we the dinosaurus 7 bits except perhaps because 7 bits is sufficient for english. I am talking about respect for non english speaking people. But if nobody cares ... I, too, speak a language that can't be fully expressed in ASCII, but I do not think that the behaviour of `show' should be changed in this respect. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.fu-mathe-team.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. pgp0.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Installation problem on suse 9.0.
[ moved to [EMAIL PROTECTED] ] i have running ghc on suse 7.3, but i can't install it on suse 9.0. the next error is raising during the HC files compilation: ... CTypes.hc:55265: warning: (near initialization for `CTypes_tpl890_closure.payload') CTypes.hc:55297: warning: excess elements in array initializer CTypes.hc:55297: warning: (near initialization for `CTypes_tpl891_closure.payload') CTypes.hc:55324: warning: excess elements in array initializer CTypes.hc:55324: warning: (near initialization for `CTypes_zdfReadCChar_closure.payload') CTypes.hc:55324: warning: excess elements in array initializer CTypes.hc:55324: warning: (near initialization for `CTypes_zdfReadCChar_closure.payload') CTypes.hc:55324: warning: excess elements in array initializer CTypes.hc:55324: warning: (near initialization for `CTypes_zdfReadCChar_closure.payload') Prologue junk?: czvw_ret: movl$0, 16(%esp) movl$0, 20(%esp) movl$0, 8(%esp) movl$0, 12(%esp) gmake[2]: *** [CTypes.o] Error 255 gmake[1]: *** [all] Error 1 gmake: *** [all] Error 1 Which GHC version are you compiling? Which GHC vesrion are you using to compile it? It might be related to a newer version of gcc: what version is installed on your system? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Running a final finaliser
I hope this question isn't too stupid, but I can't find any obvious way to do this from reading the ghc docs. What I want to do is call a final foreign function (a library shutdown routine) when Haskell terminates, but after all ForeignPtr finalisers have been run. I suppose I could implement some kind of finaliser counter so the last finalizer could tell it was the last finaliser and call the shutdown routine, but this seems a little awkward, especially as these days the FFI requires finalisers to be foreign functions. The other possibility that occurs to me is that I call performGC at the very end of the program, immediately before calling the library shutdown routine. But I'm not too sure whether that will guarantee that all finalizers have been run even if there are no live references to foreign objects at that point. (Using GC as described in the non-stop Haskell paper it seems possible that finalisers won't be run immediately in response to performGC.) Using an explicit reference count sounds fine to me. The runtime system doesn't support any ordering constraints between finalizers (it's a really hard problem in general), so the party line is you have to code it up yourself. Actually, I seem to recall that we were going to disable the running of finalizers at the end of the program completely, in which case you would have to add your cleanup code in the main thread, with an appropriate exception handler. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: To show or not to show french accents
Good evening, OK. I don't know Haskell enough to argue. But I can't resist pointing out that reading a single byte having the value 233 (that is 'é') is certainly simpler than reading the four characters \233, parse it, and translate it into a single byte having the value 233 representing no matter what character in your character table. But, I don't care that much and I'm sorry for this. Best regards, Francis Girard LE CONQUET France Selon Carsten Schultz [EMAIL PROTECTED]: Hallo! On Thu, Dec 18, 2003 at 01:55:27PM +0100, [EMAIL PROTECTED] wrote: Well, I think there should probably be some internationalisation mechanism that tells the show function (to name one), according to some configuration, how to interpret a byte as a character. My understanding is that `show' should work with `read' and possibly produce output that can be parsed by the Haskell parser. It is not a pretty printing function. Frankly, I see no good reason why we should be satisfied we the dinosaurus 7 bits except perhaps because 7 bits is sufficient for english. I am talking about respect for non english speaking people. But if nobody cares ... I, too, speak a language that can't be fully expressed in ASCII, but I do not think that the behaviour of `show' should be changed in this respect. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.fu-mathe-team.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. Original message : The following haskell program : -- module Main where accentLetters :: String accentLetters = éàô main :: IO () main = do putStr (show accentLetters) -- after being compiled will give the result : \233\224\244 But, exactly the same program, without the show function will give the result: éàô Is there some way to have show show all the printable characters, even those represented by a value greater than the US-ASCII 7 bits (127) ? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: To show or not to show french accents
On 2003-12-18 at 16:40+0100 [EMAIL PROTECTED] wrote: Good evening, OK. I don't know Haskell enough to argue. But I can't resist pointing out that reading a single byte having the value 233 (that is 'é') The problem is that if you are reading single bytes, 233 is not necessarily é. It might be 'shch' if you are in Russia, or iota if you are in Greece. While it's (almost) completely reasonable to expect 233 to display as é in Western Europe, it's completely unreasonable to hold that expectation across borders. is certainly simpler than reading the four characters \233, parse it, and translate it into a single byte but it isn't a single byte internally. Indeed, if you are in Russia you could reasonably expect reading a single byte 233 to be converted to the internal code 1257 (if I got the arithmetic right). Since Haskell specifies unicode, if you are operating in a Russian locale that's what ought to happen. What I don't understand is why you want show for this. As I mentioned earlier, to output strings and get accented characters, all you have to do is to output the string with putStr, and voilà, les signes diacritiques. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: To show or not to show french accents
I would support the point of view that show should output escapes when showing characters outside ASCII. This is sort of a transport format (together with read), therefore it must be a GCD for all possible input encodings. UTF-8 might be alternative, but it would require to be equally supported by all Haskell implementations. -- Dmitry M. Golubovsky South Lyon, MI ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.2
simonmar: The (Interactive) Glasgow Haskell Compiler -- version 6.2 We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 6.2. A binary distribution for mips64-sgi-irix is available at: ftp://ftp.cse.unsw.edu.au/pub/users/dons/ghc/6.2/ghc-6.2-mips64-sgi-irix.tar.bz2 This is an unregisterised build, with profiling libs, no docs and no GHCi. The mips64 port requires an external libgmp. This should come installed with the freeware packages for Irix. Happy mips'ing, Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
