Re: UTF-8 decoding error
Duncan Coutts schrieb:
On Fri, 2006-09-22 at 17:19 +0200, Christian Maeder wrote:
A simple script for the pgmF command
The only disadvantage is that the filename in error and warning messages
is quite useless:
I think you can fix this by pre-pending a {-# LINE #-} pragma in your
script. Something like:
May it be that import chasing takes longer now? I noticed quite a gap
before ghc started to compile my 624 modules.
Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
On Mon, 2006-10-09 at 13:55 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
On Fri, 2006-09-22 at 17:19 +0200, Christian Maeder wrote:
A simple script for the pgmF command
The only disadvantage is that the filename in error and warning messages
is quite useless:
I think you can fix this by pre-pending a {-# LINE #-} pragma in your
script. Something like:
May it be that import chasing takes longer now? I noticed quite a gap
before ghc started to compile my 624 modules.
Yes, since it has to run the pre-processor before it can look at the
imports.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
Fortress (sun's possibly-not-vaporware hpc language) supports arbitrary
unicode chars in code, and has an escape syntax for commonly used things.
Similarly, proof-general/isabelle supports tex-style escapes for symbols
greek. It seems to me that a pre-processor that turns human-friendly escapes
(e.g. \{lambda} rather than some magic number) into unicode and a slightly
intelligent IDE (or emacs mode?) would go most of the way to letting us use
up-side-down ys and curly as with all the visual beauty and editor niceness
that we have now with ascii.
Matthew
On Wednesday 20 September 2006 21:42, Duncan Coutts wrote:
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote:
How can I convince ghc version 6.5.20060919 to accept latin1 characters
in literals?
I wish to keep source files (containing umlauts in strings) that can be
compiled by either ghc-6.4.2 and ghc-6.6.
You can use numeric escapes like \222.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
On Sep 27, 2006, at 6:05 AM, Matthew Pocock wrote:
Fortress (sun's possibly-not-vaporware hpc language) supports
arbitrary
unicode chars in code, and has an escape syntax for commonly used
things.
I have spent the past week writing Fortress code (which runs in
parallel, even). But I'm perhaps a special case. :-)
Similarly, proof-general/isabelle supports tex-style escapes for
symbols
greek. It seems to me that a pre-processor that turns human-
friendly escapes
(e.g. \{lambda} rather than some magic number) into unicode and a
slightly
intelligent IDE (or emacs mode?) would go most of the way to
letting us use
up-side-down ys and curly as with all the visual beauty and editor
niceness
that we have now with ascii.
In Fortress we spent a *lot* of effort making the TWiki syntax as
painless as possible for stuff which we planned to use often (for
example, - and = turn into Unicode arrows, and the language syntax
is defined in terms of them). One source of both encouragement and
frustration is the fact that every unicode code point has an
associated description. We support using these descriptions---and
various shortenings of them, since they are too verbose for day-to-
day use. The frustration is that the names or their shortenings are
not necessarily unique. For characters which only occur in strings
this is less critical, but a little effort will go a long way.
One heuristic we've used is: if I do a diff on the ASCII
representation provided by my version control system, will I be able
to read the result?
We of course have a little program which processes an official
unicode character table (downloaded from the web) plus some
information about our special cases and uses it to generate the
appropriate conversion functions. This is important because Unicode
is constantly changing (mostly getting bigger).
-Jan-Willem Maessen
Fortress developer, Haskell hacker
Matthew
On Wednesday 20 September 2006 21:42, Duncan Coutts wrote:
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote:
How can I convince ghc version 6.5.20060919 to accept latin1
characters
in literals?
I wish to keep source files (containing umlauts in strings) that
can be
compiled by either ghc-6.4.2 and ghc-6.6.
You can use numeric escapes like \222.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
smime.p7s
Description: S/MIME cryptographic signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
Christian Maeder schrieb: Duncan Coutts schrieb: There is iconv. It could be used as a pre-processor with ghc's -F -pgmF -optF flags. NB: -F is missing in the Flag reference A simple script for the pgmF command #!/bin/sh iconv -f l1 -t utf-8 $2 $3 worked for me, thanks! The only disadvantage is that the filename in error and warning messages is quite useless: [ 15 of 400] Compiling Data.Generics2.Instances ( syb-generics/Data/Generics2/Instances.hs, syb-generics/Data/Generics2/Instances.o ) /tmp/ghc5667_0/ghc5667_248.hspp:299:17: Couldn't match expected type `forall a1. (Data ctx a1) = c (t a1)' against inferred type `c1 (t1 a1)' Expected type: (forall a2. (Data ctx a2) = c (t a2)) - Maybe (c [a]) Inferred type: c1 (t1 a1) - Maybe (c1 (t' a1)) In the expression: gcast1 In the definition of `dataCast1': dataCast1 _ = gcast1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
On Fri, 2006-09-22 at 17:19 +0200, Christian Maeder wrote:
Christian Maeder schrieb:
Duncan Coutts schrieb:
There is iconv. It could be used as a pre-processor with ghc's -F -pgmF
-optF flags.
NB: -F is missing in the Flag reference
A simple script for the pgmF command
#!/bin/sh
iconv -f l1 -t utf-8 $2 $3
worked for me, thanks!
The only disadvantage is that the filename in error and warning messages
is quite useless:
[ 15 of 400] Compiling Data.Generics2.Instances (
syb-generics/Data/Generics2/Instances.hs,
syb-generics/Data/Generics2/Instances.o )
/tmp/ghc5667_0/ghc5667_248.hspp:299:17:
I think you can fix this by pre-pending a {-# LINE #-} pragma in your
script. Something like:
#!/bin/sh
( echo {-# LINE 1 \$2\ #-} ; iconv -f l1 -t utf-8 $2 ) $3
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
Duncan Coutts schrieb:
/tmp/ghc5667_0/ghc5667_248.hspp:299:17:
I think you can fix this by pre-pending a {-# LINE #-} pragma in your
script. Something like:
#!/bin/sh
( echo {-# LINE 1 \$2\ #-} ; iconv -f l1 -t utf-8 $2 ) $3
Yes, thanks again!
C.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
Duncan Coutts schrieb: On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote: How can I convince ghc version 6.5.20060919 to accept latin1 characters in literals? I wish to keep source files (containing umlauts in strings) that can be compiled by either ghc-6.4.2 and ghc-6.6. You can use numeric escapes like \222. How about resolving http://cvs.haskell.org/trac/ghc/ticket/690 ? I would like to simple add a flag to ghc. How about adding an addional phase (and extension) to ghc before preprocessing? Your solution does not support good readability. Is there a ready tool that converts my source files as you suggested automatically? How does haddock handle characters in comments? I'm sort of stuck currently testing ghc-6.6 RC Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
On Thu, Sep 21, 2006 at 10:15:45AM +0200, Christian Maeder wrote: How does haddock handle characters in comments? Section 3.8.3 of the Haddock manual: 3.8.3. Character references Although Haskell source files may contain any character from the Unicode character set, the encoding of these characters as bytes varies between systems, so that only source files restricted to the ASCII character set are portable. Other characters may be specified in character and string literals using Haskell character escapes. To represent such characters in documentation comments, Haddock supports SGML-style numeric character references of the forms #D; and #xH; where D and H are decimal and hexadecimal numbers denoting a code position in Unicode (or ISO 10646). For example, the references #x3BB;, #x3bb; and #955; all represent the lower-case letter lambda. Not pretty, but it is portable and not limited to the Latin-1 subset. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
On Thu, 2006-09-21 at 10:15 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote:
How can I convince ghc version 6.5.20060919 to accept latin1 characters
in literals?
I wish to keep source files (containing umlauts in strings) that can be
compiled by either ghc-6.4.2 and ghc-6.6.
You can use numeric escapes like \222.
How about resolving http://cvs.haskell.org/trac/ghc/ticket/690 ?
I would like to simple add a flag to ghc. How about adding an addional
phase (and extension) to ghc before preprocessing?
Your solution does not support good readability. Is there a ready tool
that converts my source files as you suggested automatically? How does
haddock handle characters in comments?
There is iconv. It could be used as a pre-processor with ghc's -F -pgmF
-optF flags.
Sorry there isn't a better solution at the moment. You could petition
for an {-# ENCODING ISO-8859-1 #-} pragma as mentioned in that ticket.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
currently haddock correctly translates latin1 chars, ie. äöü to #xe4;#xf6;#xfc; So it would be nice if also ghc-6.6 could remain backward compatible by supporting latin1 sources. Christian Ross Paterson schrieb: On Thu, Sep 21, 2006 at 10:15:45AM +0200, Christian Maeder wrote: How does haddock handle characters in comments? Section 3.8.3 of the Haddock manual: 3.8.3. Character references Although Haskell source files may contain any character from the Unicode character set, the encoding of these characters as bytes varies between systems, so that only source files restricted to the ASCII character set are portable. Other characters may be specified in character and string literals using Haskell character escapes. To represent such characters in documentation comments, Haddock supports SGML-style numeric character references of the forms #D; and #xH; where D and H are decimal and hexadecimal numbers denoting a code position in Unicode (or ISO 10646). For example, the references #x3BB;, #x3bb; and #955; all represent the lower-case letter lambda. Not pretty, but it is portable and not limited to the Latin-1 subset. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
Duncan Coutts schrieb:
There is iconv. It could be used as a pre-processor with ghc's -F -pgmF
-optF flags.
NB: -F is missing in the Flag reference
A simple script for the pgmF command
#!/bin/sh
iconv -f l1 -t utf-8 $2 $3
worked for me, thanks!
Sorry there isn't a better solution at the moment. You could petition
for an {-# ENCODING ISO-8859-1 #-} pragma as mentioned in that ticket.
This seems unnecessary now.
Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote: How can I convince ghc version 6.5.20060919 to accept latin1 characters in literals? I wish to keep source files (containing umlauts in strings) that can be compiled by either ghc-6.4.2 and ghc-6.6. You can use numeric escapes like \222. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
Simon Marlow wrote: Christian Maeder wrote: I'm tempted to replace ä bei \228 in literals. What does haddock do with utf-8 in comments? Will DrIFT -- using read- and writeFile -- still work correctly? The problem I fear is that writeFile does not produce a utf-8 encoded file: writeFile t.hs main = putStrLn \äöüßÄÖÜ\ Using \228\246\252\223\196\214\220 instead of äöüßÄÖÜ only avoids conversion to utf-8 of the initial file l1.hs (attached), but the generated file t.hs is a latin-1 file in both cases. Cheers Christian *Main :l l1.hs Compiling Main ( l1.hs, interpreted ) Ok, modules loaded: Main. *Main main *Main :l t.hs Compiling Main ( t.hs, interpreted ) Ok, modules loaded: Main. *Main main äöüßÄÖÜ main = writeFile t.hs main = putStrLn \äöüßÄÖÜ\ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
Simon Marlow wrote: So - do you need Latin-1, or could you use UTF-8? I'm not amused to change the encoding of many haskell source files (particular of those that are not mine). These files can then no longer be compiled by earlier ghcs (though I don't understand, how ghc-6.4.1 recognises the lexical error). I'm tempted to replace ä bei \228 in literals. What does haddock do with utf-8 in comments? Will DrIFT -- using read- and writeFile -- still work correctly? Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
