Can't we just have the usual .Internal module convention, where people who
want internals can get at them if they need to, and most people get a
simpler interface? It's amazingly frustrating when you have a library that
does 99% of what you need it to do, except for one tiny internal detail
that th
for what it is worth, I would like to see both System.IO and Directory
export "internal functions" where the filepath is a Raw Byte representation.
I have utilities that regularly scan 100,000 of files and hash the path
the details of which are irrelevant to this discussion, the point being
that t
On 11/6/2011 5:18 PM, Ian Lynagh wrote:
7.2.2 will be a minimal bugfix release, fixing only bugs that cannot be
worked around. Please let us know if you find any showstoppers.
#5531 is still there and no workarounds are known. Also, it's specific
for post 7.0.Xs. Not sure if this counts as sho
Quoth John Millikin ,
...
> One is to give low-level access, using abstractions as close to the
> real API as possible. In this model, "unix" would provide functions
> like [[ rename :: ByteString -> ByteString -> IO () ]], and I would
> know that it's not going to do anything weird to the paramete
2011/11/6 Max Bolingbroke :
> On 6 November 2011 04:14, John Millikin wrote:
>> For what it's worth, on my Ubuntu system, Nautilus ignores the locale
>> and just treats all paths as either UTF8 or invalid.
>> To me, this seems like the most reasonable option; the concept of
>> "locale encoding" is
It's looking good but base is still untrusted out of the box. Is this right?
Chris
-Original Message-
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Ian Lynagh
Sent: 06 November 2011 13:19
To: glasgow-haskell-users@haskell.o
On 6 November 2011 04:14, John Millikin wrote:
> For what it's worth, on my Ubuntu system, Nautilus ignores the locale
> and just treats all paths as either UTF8 or invalid.
> To me, this seems like the most reasonable option; the concept of
> "locale encoding" is entirely vestigal, and should onl
We are pleased to announce the first release candidate for GHC 7.2.2:
http://www.haskell.org/ghc/dist/7.2.2-rc1/
This includes the source tarball, installers for OS X and Windows, and
bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD.
7.2.2 will be a minimal bugfix releas