- Libraries - Haskell.org

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

darcs patch: add README to warn about autoreconf
by cdsmith＠twu.net 13 Jun '07

13 Jun '07

Fri Jun 1 11:55:27 MDT 2007 cdsmith(a)twu.net * add README to warn about autoreconf

4 3

Patch - Control.Monad.Reader documentation
by Andriy Palamarchuk 12 Jun '07

12 Jun '07

Added Haddock documentation. Converted the existing module documentation to Haddock format. Created examples. Per Jeff Newberns permission included parts his tutorial "All About Monads" http://haskell.org/all_about_monads/. See the ticket for details: http://hackage.haskell.org/trac/ghc/ticket/1410 Haddock output: http://hackage.haskell.org/trac/ghc/attachment/ticket/1410/Control-Monad-Re… http://hackage.haskell.org/trac/ghc/attachment/ticket/1410/Control-Monad-Re… Andriy ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

2 1

Re: Control.Monad.Cont documentation
by Andriy Palamarchuk 12 Jun '07

12 Jun '07

Here is the final, corrected version of the patch for Control.Monad.Cont documentation. There were no big changes in content since the previous version. The deadline for the ticket passed long ago, so I assume it is ready for commit. Please commit if there is no comments. The previous submission was broken by major changes in the module. The patch, Haddock output, source are attached to the ticket: http://hackage.haskell.org/trac/ghc/ticket/1169 Directly review Haddock source here: http://hackage.haskell.org/trac/ghc/attachment/ticket/1169/Control-Monad-Co… http://hackage.haskell.org/trac/ghc/attachment/ticket/1169/Control-Monad-Co… Comments, questions? Andriy ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/

2 1

net001 test failure
by Simon Marlow 12 Jun '07

12 Jun '07

The test net001 from the network package is failing on my RedHat 9 box, so I went investigating. Bear in mind I'm completely ignorant of IPV6. This test invokes Network.listenOn (PortNumber 22222) and gets: socket: unsupported operation (Address family not supported by protocol) This machine has getaddrinfo(), so the IPV6 support is enabled. listenOn does this: proto <- getProtocolNumber "tcp" let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_PASSIVE] , addrProtocol = proto } addrs <- getAddrInfo (Just hints) Nothing (Just serv) Exception.bracketOnError (socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr)) ... and addrs is: [AddrInfo {addrFlags = [AI_PASSIVE], addrFamily = AF_INET6, addrSocketType = Stream, addrProtocol = 6, addrAddress = [::]:22222, addrCanonName = Nothing},AddrInfo {addrFlags = [AI_PASSIVE], addrFamily = AF_INET, addrSocketType = Stream, addrProtocol = 6, addrAddress = 0.0.0.0:22222, addrCanonName = Nothing}] So the first address in the list is an IPV6 address, but socket refuses to open the socket because (I assume) IPV6 is not really supported. What should we do in this case? Should listenOn try all the available addresses until it finds one that works? Cheers, Simon

2 3

Cabal and Haddock
by Adrian Hey 11 Jun '07

11 Jun '07

Hello, When building a package (on windows) the Haddock stage seems to go wrong.. runghc Setup.hs haddock It's looking for base.haddock (presumably) under C:/ghc/ghc-6.6.1\html\libraries\base but it's actually at.. C:/ghc/ghc-6.6.1\doc\html\libraries\base Does anyone know why it's looking in the wrong place and how can I can get it to look in the right place? (AFAICS there's no way to influence Haddock from the .cabal file, but maybe I'm missing something). Also, if I move the html dir up one level to where it seems to be looking it still doesn't work. Haddock still gives the error.. Warning: cannot use package base-2.1.1: HTML directory C:/ghc/ghc-6.6.1\html\libraries\base does not exist. Thanks -- Adrian Hey

3 3

System.Time crash
by David Waern 07 Jun '07

07 Jun '07

Hi, This line of code using the System.Time library crashes with ghc-6.6.1 in Windows XP: print (TOD 12387213982173921131231231 0) TOD is a constructor that creates a ClockTime. The crash seems to happen when a ClockTime with a large enough TOD is show'ed. Is this a known bug? /David

2 3

Stack overflow with Data.Binary
by Grzegorz 06 Jun '07

06 Jun '07

Hi, I just spent some time trying to find a stack overflow bug. I seem to have narrowed it down to somewhere probably related to the default Binary instances. It only seems to overflow when compiling with -prof. The following is a reasonably minimal example. Any ideas of what might be going on? -- foo.hs -- compiled with: -- ghc -O2 -prof --make foo.hs -- $ ./foo < okok -- Stack space overflow: current size 8388608 bytes. -- Use `+RTS -Ksize' to increase it. import Data.IntMap import qualified Data.ByteString.Lazy as BS import Data.Binary main = do s <- BS.getContents print . size . snd $ (decode $ s::(IntMap Double,IntMap (Int,Maybe String))) -- Grzegorz

4 10

Length returned by CStringLen functions
by Alistair Bayley 05 Jun '07

05 Jun '07

Hello, [I sent this to the cafe list a week or two ago, but it was buried at the end of a message about optimisation, and got no responses.] In Foreign.C.String, the Haddock comment for CStringLen states: "A string with explicit length information in bytes..." and for CWString something similar: "A wide character string with explicit length information in bytes..." I know this is a blatant lie, though, because the code (unless I've grossly misunderstood it) for newCStringLen, withStringLen, newCWStringLen, and withCWStringLen all return the number of Haskell Chars in the String i.e. the number of Unicode chars, NOT the number of bytes. However, for the sake of inconsistency, the peekC{W}StringLen functions take, respectively, the number of Word8 or Word16/Word32 elements (whether CWString is Word16 or Word32 depends on your plaform, apparently) in the C{W}String array/buffer. So the outputs from newCStringLen etc are not reliably usable as inputs to their duals (peekCStringLen etc.) The only cases that they do work in this way is where the CStrings are encoded with fixed-width encodings i.e. there are no surrogate units in the encoding. So we have three different approaches: 1. Haddock comments say bytes 2. with/newC{W}StringLen returns unicode char count 3. peekC{W}StringLen expects Word8 or Word16 count (1) and (3) can be considered equivalent, in the sense that if you know the number of Word16 units then you know the number of Word8 units, and vice versa. It'd be nice if we could have one consistent approach. For a start, I think we should eliminate (2), because it's dead easy the get the number of unicode chars from a String. So whether to settle on (1) or (3) depends on what the most likely use case is for the length information. Presumably it's going to be passed to a foreign function which expects the length either in bytes or in Word16/Word32 units. Does anyone have any evidence or opinion as to which case is the most common: bytes, or encoding units? Alistair

2 1

Shouldn't System.Process.runInteractiveCommand close inherited descriptors above 2?
by Tomasz Zielonka 05 Jun '07

05 Jun '07

Hello! My coworker just experienced a strange situation: a network connection wasn't automatically closed when the process finished. It was because a child process unneccesarily inherited this connection's descriptor. So the question is: shouldn't runInteractiveCommand / runInteractiveProcess close descriptors greater then 2 in the child process? The following program shows this behaviour on Linux: import System.Process import System.IO main = do h1 <- openFile "/etc/passwd" ReadMode (_, pout, _, phandle) <- runInteractiveCommand "ls -l /proc/self/fd" hGetContents pout >>= putStr waitForProcess phandle hClose h1 The result: tomekz@tomekz:~/devel/haskell/interactive-process-filedes$ ./IP total 5 lr-x------ 1 tomekz tomekz 64 2007-06-04 11:50 0 -> pipe:[22830] l-wx------ 1 tomekz tomekz 64 2007-06-04 11:50 1 -> pipe:[22831] l-wx------ 1 tomekz tomekz 64 2007-06-04 11:50 2 -> pipe:[22832] lr-x------ 1 tomekz tomekz 64 2007-06-04 11:50 3 -> /etc/passwd lr-x------ 1 tomekz tomekz 64 2007-06-04 11:50 4 -> /proc/13687/fd As you can see, the "ls" process inherits the file descriptor to /etc/passwd from the Haskell program process. This is in GHC 6.6. I wonder if anyone explicitly wants such behavior, but even if so, IMHO the default behaviour should be to close such descriptors. I think the current situation could even cause some security problems. Best regards Tomek

6 10