John Millikin wrote:
That was my understanding also, then QuickCheck found a
counter-example. It turns out that there are cases where a valid path
cannot be roundtripped in the GHC 7.2 encoding.
The issue is that [238,189,178] decodes to 0xEF72, which is within
the 0xEF00-0xEFFF range that
On Mon, Feb 6, 2012 at 10:05, Joey Hess j...@kitenet.net wrote:
John Millikin wrote:
That was my understanding also, then QuickCheck found a
counter-example. It turns out that there are cases where a valid path
cannot be roundtripped in the GHC 7.2 encoding.
The issue is that [238,189,178]
John Millikin wrote:
Perhaps I'm misunderstanding, but the definition of 'withFilePath' you
provided is definitely locale-dependent. Unless getFileSystemEncoding
is constant?
I think/hope it's locale dependent, but undecodable bytes are remapped,
so as long as the system's locale doesn't
Both packages now have much-improved support for non-UTF8 paths on
POSIX systems. There are no significant changes to Windows support in
this release.
system-filepath 0.4.5:
Hackage: http://hackage.haskell.org/package/system-filepath-0.4.5
API reference:
John Millikin wrote:
In GHC 7.2 and later, file path handling in the platform libraries
was changed to treat all paths as text (encoded according to locale).
This does not work well on POSIX systems, because POSIX paths are byte
sequences. There is no guarantee that any particular path will
On Sun, Feb 5, 2012 at 18:49, Joey Hess j...@kitenet.net wrote:
John Millikin wrote:
In GHC 7.2 and later, file path handling in the platform libraries
was changed to treat all paths as text (encoded according to locale).
This does not work well on POSIX systems, because POSIX paths are byte
On Sun, Feb 5, 2012 at 19:17, John Millikin jmilli...@gmail.com wrote:
--
$ ~/ghc-7.0.4/bin/ghci
Prelude writeFile .txt test
Prelude readFile .txt
test
Prelude
Sorry, that got a bit mangled in the email. Corrected
