June 2007 - Libraries

darcs patch: Speed up number printing and remove the need for Array...
by John Meacham 27 Jun '07

27 Jun '07

Fri Jun 8 11:23:53 PDT 2007 John Meacham <john(a)repetae.net> * Speed up number printing and remove the need for Array by using the standard 'intToDigit' routine

2 1

Proposal: fix for getOpt (missing feature)
by Malcolm Wallace 26 Jun '07

26 Jun '07

Proposal: to fix a missing feature in the Haskell implementation of GNU getOpt. Currently, long option names _must_ have two dashes (e.g. --foo), whereas this patch permits a single dash (e.g. -foo) where there is no short option name to be confused with it (e.g. -f).

6 6

RE: wxHaskell working with 2.8.4 wxWidgets and 6.6.1
by Simon Peyton-Jones 26 Jun '07

26 Jun '07

David | you might be pleased to here that wxHaskell is now working quite well with | the latest versions of wxWidgets and GHC i.e. versions 2.8.4 and 6.6.1 | respectively. I realise you are probably too senior to deal with such | project details directly but the GHC site does not have a general contact | address and wouldn't let me register an account to report this on any | internal forum etc. Since I am very new to Haskell -- this is in fact my | first project with wxWidgets and Haskell, could you please suggest someone | to whom I could pass on the details of the mods I have made etc to get | wxHaskell working in the current environment. Well done! There's a special mailing list just for WxHaskell users, who I am cc'ing. It's not very active though, so I'm also ccing libraries(a)haskell.org. A small bunch of folk are interested in maintaining WxHasekell, and you should definitely talk to them. I'm ccing the ones I know of, and I enclose the last message I had from them (Oct 2006). I hope this points you in the right direction. Thank you for contributing in such a concrete way. Incidentally, you can join any of the Haskell mailing lists rather easily. Simon

2 1

IPv6 patch for BSD/KAME
by Bryan O'Sullivan 25 Jun '07

25 Jun '07

Bryan O'Sullivan wrote: > It seems to be an oddity with OS X. Here's a well-timed patch that > Thomas Schilling sent two days ago, which seems to be appropriate: > > http://www.haskell.org/pipermail/libraries/2007-June/007644.html That should indeed fix the build for BSD boxes. However, the underlying problem is that the existence of a s6_addr32 field in in6_addr isn't required by RFC 2553. So I'll cook up a patch that uses s6_addr, which *is* required, and hence ought to be more portable. <b

2 2

Re: filepath should not return trailing path separators
by Andriy Palamarchuk 22 Jun '07

22 Jun '07

----- Original Message ---- From: Neil Mitchell <ndmitchell(a)gmail.com> > In various discussions I think people argued for both - in "foo/" > there is no filename, since foo has been explicitly marked as a > directory. I guess in this case foo is actually the leafname, or > something. For what it is worth I'm for having directory names without slashes. I believe it is a more expected form, it is also simpler to handle. Andriy ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091

1 0

Data.Set and instance Read (Set a)
by Otakar Smrz 21 Jun '07

21 Jun '07

Dear library maintainers, I have come across a conflict with the Data.Set library, namely that its definition of the instance of Read assumes the default instance for reading lists: instance (Read a, Ord a) => Read (Set a) where readsPrec p = readParen (p > 10) $ \ r -> do ("fromList",s) <- lex r (xs,t) <- reads s return (fromList xs,t) The conflict arises when I define my own instance for reading a non-polymorphic list, like in: instance Read [SomeType] Then Hugs protests that: ERROR file:{Hugs}\packages\base\Data\Set.hs:542 - Cannot justify constraints in instance member binding *** Expression : readsPrec *** Type : Read (Set a) => Int -> ReadS (Set a) *** Given context : Read (Set a) *** Constraints : Read [a] Fortunately, I do not need the Data.Set library, and can prevent the problem by an explicit empty import: import Data.Set () However, a simple fix for it might be welcome by others as well: instance (Read a, Read [a], Ord a) => Read (Set a) where ... Thanks for you attention. Best regards, Otakar Smrz

2 1

Subtle bug in Data.ByteString and/or GHC (perhaps)
by Nils Anders Danielsson 19 Jun '07

19 Jun '07

Hi, The following program prints different outputs depending on whether optimisations are turned on or not (using GHC 6.6.1 and binary 0.3): module Bug (main) where import Data.Binary import Data.Binary.Put import Data.Binary.Get import Data.Binary.Builder import qualified Data.ByteString.Lazy as BL import qualified Data.ByteString.Base as BB append' :: BL.ByteString -> BL.ByteString -> BL.ByteString append' = BL.append -- append' (BB.LPS xs) (BB.LPS ys) = BB.LPS (xs ++ ys) encode' :: Char -> BL.ByteString encode' x = encode (st `seq` 'a') `append'` toLazyByteString builder where (st, builder) = unPut (put x) decode' :: BL.ByteString -> Char decode' s = decode s' where (_, s', _) = runGetState (get :: Get Char) s 0 main :: IO () main = mapM_ (print . test) "abc" where test x = decode' (encode' x) == x $ ghc --make -O Bug.hs -main-is Bug.main -o bug [...] $ ./bug True False False $ rm Bug.o; ghc --make Bug.hs -main-is Bug.main -o bug [...] $ ./bug True True True If the commented-out version of append' (which is a bit lazier than the other one) is used instead, then this problem disappears. The commented-out version is the one used in the darcs version of Data.ByteString, so the problem above has, in a sense, already been fixed. However, it is disconcerting that the result of a program can depend on optimisation flags, and changing the strictness of a function should only make a (pure) program more or less defined, not change a result from True to False. Hence I wonder if anyone knows the real cause of this bug, and what the risk of encountering similar bugs in the future is. It took lots of time to find and fix the problem above (which of course came up in a larger piece of code), so I hope that I won't encounter similar problems again. My guess is that the problem has something to do with unsound rewrite rules in Data.ByteString, by the way. Or maybe the problem lies in GHC's optimiser. -- /NAD

3 9

filepath should not return trailing path separators
by Bryan O'Sullivan 15 Jun '07

15 Jun '07

Hi, Neil - I'm writing some filesystem traversal code using filepath at the moment, and I am a bit disappointed to find it more error-prone and cumbersome than I had hoped. The root of my problem is that splitFileName leaves a trailing path separator on the end of the first element of the tuple it returns: splitFileName "foo/bar" ==> ("foo/", "bar") If I'm recursing up a file hierarchy towards the root directory (a common thing to do), this trailing path separator is a pain. Either I forget that it's there and infinitely loop in the same directory over and over again, due to this behaviour: splitFileName "foo/" ==> ("foo/", "") Or I have to remove it, with an unaesthetically named function: splitFileName (dropTrailingPathSeparator "foo/") ==> ("", "foo") Having the trailing path separator omitted in the result of splitFileName and friends would both get rid of the possibility of the recursion bug (I'm surely not the only one who'll be bitten by it) and greatly reduce the frequency of the need to import and call dropTrailingPathSeparator. I don't know how open the library is to such a change, now that GHC 6.6.1 ships with filepath, but I consider the current behaviour to be quite unfortunate and undesirable, and very much worth fixing. FWIW, Python's os.path.split has the trailing-"/"-elision behaviour I am advocating. Thanks for your work on filepath. I am glad to have it; I'd just be gladder if it wasn't so tricksy. Regards, <b

3 2

Re: [Haskell-cafe] dangerous inlinePerformIO in Data.Binary(?)
by dons＠cse.unsw.edu.au 15 Jun '07

15 Jun '07

Moved to libraries@ u.stenzel: > Greetings, > > I was trying to understand the magic inside Data.Binary, and found two > somewhat suspicious uses of inlinePerformIO, which imho has a far too > innocuous name: > > | toLazyByteString :: Builder -> L.ByteString > | toLazyByteString m = S.LPS $ inlinePerformIO $ do > | buf <- newBuffer defaultSize > | return (runBuilder (m `append` flush) (const []) buf) > > Why is this safe? Considering the GHC implementation of IO, isn't there > a real danger that 'newBuffer defaultSize' is floated out and therefore > every invocation of 'toLazyByteString' starts out with the same buffer? > Isn't that exactly the reason why unsafePerformIO and runST are declared > NOINLINE? Yes, that breaks the first rule of inlinePerformIO: * don't use it around code that directly allocates. I've submitted a patch to use unsafePerformIO here. > The other occurence is: > > | unsafeLiftIO :: (Buffer -> IO Buffer) -> Builder > | unsafeLiftIO f = Builder $ \ k buf -> inlinePerformIO $ do > | buf' <- f buf > | return (k buf') > > which might be safe, since 'f buf' cannot float out of the lambda which > binds 'buf', but still, all this stuff is inlined, something constant > might get plugged in the place of buf and the result might be floated > out to give us an even harder to find Heisenbug. And this use is indeed also critical for performance, its how we use direct cascades of FFI writes to fill buffers in a an ST style. > Am I missing something and this is actually safe? If not, what can be We belive the latter use is safe, but it's been 6 months since I've thought about this. Duncan, you've thought a bit more about this recently. Any rules we can use here? > done to avoid such errors? I'd really hate to find building blocks that > crumble under pressure in standard libraries... -- Don

1 0

darcs patch: Remove unsafeCoerce-importing kludgery in favor of Uns...
by Isaac Dupree 14 Jun '07

14 Jun '07

this patch is just for 'base', I didn't look at other libraries Fri Jun 1 16:36:25 EDT 2007 Isaac Dupree <id(a)isaac.cedarswampstudios.org> * Remove unsafeCoerce-importing kludgery in favor of Unsafe.Coerce

5 14