Wolfgang Thaller [EMAIL PROTECTED] writes:
In what way is ISO-2022 non-reversible? Is it possible that a ISO-2022
file name that is converted to Unicode cannot be converted back any
more (assuming you know for sure that it was ISO-2022 in the first
place)?
I am no expert on ISO-2022 so the
Andrew Pimlott wrote:
[I think it is preferred to post this on haskell-cafe.]
Oops! I guess you're right.
On Fri, Mar 18, 2005 at 02:00:37PM -0800, Juan Carlos Arevalo Baeza wrote:
matchRuleST :: String - State RuleSet (Maybe Rule)
makeST :: String - StateT RuleSet IO ()
matchRuleST
On Sat, Mar 19, 2005 at 12:55:54PM +0100, Marcin 'Qrczak' Kowalczyk wrote:
Glynn Clements [EMAIL PROTECTED] writes:
The point is that a single program often generates multiple streams of
text, possibly for different audiences (e.g. humans and machines).
Different streams may require
Einar Karttunen wrote:
In what way is ISO-2022 non-reversible? Is it possible that a ISO-2022
file name that is converted to Unicode cannot be converted back any
more (assuming you know for sure that it was ISO-2022 in the first
place)?
I am no expert on ISO-2022 so the following
Marcin 'Qrczak' Kowalczyk wrote:
I'm talking about standard (XSI) curses, which will just pass
printable (non-control) bytes straight to the terminal. If your
terminal uses CP437 (or some other non-standard encoding), you can
just pass the appropriate bytes to waddstr() etc and the
David Roundy wrote:
That's not true, there could be many filesystems, each of which uses a
different encoding for the filenames. In the case of removable media, this
scenario isn't even unlikely.
I agree - I can quite easily see the situation occuring where a student
(say from japan) brings
On Sat, 19 Mar 2005, David Roundy wrote:
That's not true, there could be many filesystems, each of which uses a
different encoding for the filenames. In the case of removable media, this
scenario isn't even unlikely.
The nearest desktop machine to me right now has in its directory structure
Wolfgang Thaller wrote:
Of course, it's quite possible that the only test cases will be people
using UTF-8-only (or even ASCII-only) systems, in which case you won't
see any problems.
I'm kind of hoping that we can just ignore a problem that is so rare
that a large and well-known
On Sat, Mar 19, 2005 at 03:25:32AM -0800, Juan Carlos Arevalo Baeza wrote:
Andrew Pimlott wrote:
You might solve this by changing the type of matchRuleST:
matchRuleST :: MonadState RuleSet m = String - m (maybe Rule)
I don't know... The original using IO somehow offended me because it
Wolfgang Thaller [EMAIL PROTECTED] writes:
Also, IIRC, Java strings are supposed to be unicode, too -
how do they deal with the problem?
Java (Sun)
--
Filenames are assumed to be in the locale encoding.
a) Interpreting. Bytes which cannot be converted are replaced by U+FFFD.
b)
[moving to haskell-cafe, as this thread is getting long]
On Fri, Mar 18, 2005 at 07:18:29PM -0700, Kevin Atkinson wrote:
What follows is my first attempt of using Arrows to create a GUI Library
based on GTK+. It uses many ideas from Fruit (http://haskell.org/fruit/).
However it is based on
On Wed, Mar 16, 2005 at 11:55:18AM +, Ross Paterson wrote:
On Wed, Mar 16, 2005 at 03:54:19AM +, Ian Lynagh wrote:
Do you have a list of functions which behave differently in the new
release to how they did in the previous release?
(I'm not interested in changes that will affect
On Sat, 19 Mar 2005 [EMAIL PROTECTED] wrote:
[moving to haskell-cafe, as this thread is getting long]
On Fri, Mar 18, 2005 at 07:18:29PM -0700, Kevin Atkinson wrote:
What follows is my first attempt of using Arrows to create a GUI Library
based on GTK+. It uses many ideas from Fruit
On Sat, Mar 19, 2005 at 01:42:11PM -0800, Juan Carlos Arevalo Baeza wrote:
Andrew Pimlott wrote:
On Sat, Mar 19, 2005 at 03:25:32AM -0800, Juan Carlos Arevalo Baeza wrote:
Andrew Pimlott wrote:
You might solve this by changing the type of matchRuleST:
matchRuleST :: MonadState
Also, IIRC, Java strings are supposed to be unicode, too -
how do they deal with the problem?
Files are represented by instances of the File class:
[...]
The documentation for the File class doesn't mention encoding issues
at all.
... which led me to conclude that they don't deal with the problem
On Sat, Mar 19, 2005 at 12:17:46PM -0700, Kevin Atkinson wrote:
On Sat, 19 Mar 2005 [EMAIL PROTECTED] wrote:
I would also have expected loopFG to have been defined using fixIO.
Could you be more specific. Ie How?
For the type definitions
newtype FG' a b = FG' (Control - a - IO
On Sat, Mar 19, 2005 at 07:14:25PM +, Ian Lynagh wrote:
In the below, it looks like there is a bug in getDirectoryContents.
Yes, now fixed in CVS.
Also, the error from w.hs is going to stdout, not stderr.
It's a nuisance, but noone has got around to changing it.
Most importantly,
On Sat, Mar 19, 2005 at 03:04:04PM +, Glynn Clements wrote:
I'm not suggesting inventing conventions. I'm suggesting leaving such
issues to the application programmer who, unlike the library
programmer, probably has enough context to be able to reliably
determine the correct encoding in
Glynn Clements wrote:
To get a better idea, you would need to consult users whose language
doesn't use the roman alphabet, e.g. CJK or cyrillic. Unfortunately,
you don't usually find too many of them on lists such as this.
In Russia, we still have multiple one byte encodings for Cyrillic: KOI-8
On Sun, Mar 20, 2005 at 01:33:44AM +, [EMAIL PROTECTED] wrote:
On Sat, Mar 19, 2005 at 07:14:25PM +, Ian Lynagh wrote:
Most importantly, though: is there any way to remove this file without
doing something like an FFI import of unlink?
Is there anything LC_CTYPE can be set to
HList seems just like a tuple, but more powerful because one can
access the type structure directly, and more cumbersome because one
has to use lengthier constructors a 'nil' terminator. So why not just
make tuples synonyms for HLists, so one can use HLists with the
shorter notation, and have the
21 matches
Mail list logo
