From ccshan at post.harvard.edu Thu Jan 1 00:56:16 2009 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Thu Jan 1 00:48:44 2009 Subject: blame: mtl MonadReader instance for ContT References: <5ce89fb50812221019p49bdf464rc78c1cdade5099ed@mail.gmail.com> <5ce89fb50812291016oda99984u480414f4c9675f25@mail.gmail.com> Message-ID: <0h2u26-1v5.ln1@mantle.rutgers.edu> Nicolas Frisby wrote in article <5ce89fb50812291016oda99984u480414f4c9675f25@mail.gmail.com> in gmane.comp.lang.haskell.libraries: > I did come across that. They only call this particular lifting "not > natural," which doesn't seem much of a justification - unless they > mean natural in a more formal sense that isn't immediately obvious to > me. I agree it's not much of a justification. Maybe what they meant by "natural" is that the same code (using "ask" and "local") should work in the reader monad as in the continuation monad transformer applied to the reader monad. Here's an example to illustrate: import Control.Monad.Cont import Control.Monad.Reader example local = do x <- ask y <- local (1+) ask z <- ask return (x,y,z) local' f m = ContT $ \c -> do r <- ask local f (runContT m c) In ghci 6.8.2, I get *Main> runReader (runContT (example local) return) 1 (1,2,1) *Main> runReader (runContT (example local') return) 1 (1,2,2) > I revisited that paper upon finding the reference in your Delimited > Dynamic Binding, the examples of which finally lent some clarity to > the differences in the computational behaviors I was dealing with. Thanks for the encouragement. (: -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 100 Days to close Guantanamo and end torture http://100dayscampaign.org/ From lemming at henning-thielemann.de Fri Jan 2 09:47:15 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Jan 2 09:39:06 2009 Subject: Endo-Monoid of lists = differences lists Message-ID: How about a function for the Endo monoid, that lifts from a single value. toEndo :: (Monoid a) => a -> Endo a toEndo x = Endo (mappend x) For 'a' being a list type one would have a nice difference list. This may also occur in the documentation - both in the ones of Monoid.Endo and the of http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist . A similar application is Peano number with efficient addition. Would also be a nice type for ShowS. From ashley at semantic.org Sat Jan 3 22:46:51 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Jan 3 22:38:48 2009 Subject: time package in the GHC build Message-ID: Can I remove the time package from the GHC build process? I want to update it but I don't want to deal with GHC's autotools stuff or break the GHC build. -- Ashley Yakeley From igloo at earth.li Sun Jan 4 08:27:12 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 4 08:18:53 2009 Subject: time package in the GHC build In-Reply-To: References: Message-ID: <20090104132712.GA11541@matrix.chaos.earth.li> On Sat, Jan 03, 2009 at 07:46:51PM -0800, Ashley Yakeley wrote: > Can I remove the time package from the GHC build process? I've removed it. Thanks Ian From marcus at gabriel.name Sun Jan 4 16:13:00 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Sun Jan 4 16:04:44 2009 Subject: Proposal for Data.List.splitBy Message-ID: <4961265C.2090709@gabriel.name> We seem to have not added any splitters such as splitBy or split to Data.List despite the discussions. Here is yet another perspective with the hope that it will make it. For the record, see the threads * http://www.haskell.org/pipermail/libraries/2004-July/thread.html#2342 * http://www.haskell.org/pipermail/haskell-cafe/2006-July/thread.html#16559 * http://www.haskell.org/pipermail/libraries/2008-January/thread.html#8922 see the article * http://www.haskell.org/pipermail/libraries/2006-October/006072.html and see the wiki page * http://haskell.org/haskellwiki/List_function_suggestions Essentially, I believe that the difficulty in choosing a splitter for Data.List comes from the fact that it does not take much of a problem to solve before a simple splitter is just not enough whereupon you should just use a FSM, Alex, or Parsec for example. A way forward would be to state a few meta-properties and properties up front and then see if this leads to a reasonable solution for the simple problems that just need a solution that is "good enough." I would suggest that 1. a set of splitter words should be small in number, 2. such a set should fit within the spirit of the List module of the Haskell 98 standard libraries, 3. it should pick up where break and span left off, and 4. the results coming from this set of splitter words should be unsplittable. I would argue that the above suggestions imply at least two words * splitBy :: (a -> Bool) -> [a] -> [([a], [a])] and * split :: [a] -> [a] -> [([a], [a])] such that splitBy takes a predicate p, e.g., (=='\n'), and a list xs and such that split takes a list of equivalent delimiters ds, e.g., " \t", and a list xs. The functions splitBy and split should at least have the follow properites. > (concatMap (\(x1, x2) -> x1 ++ x2) $ splitBy p xs) == xs > splitBy _ [] == [([],[])] > splitBy (\x -> False) xs == [(xs,[])] > splitBy (\x -> True) xs == [([],[x1]),([],[x2]),([],[x3]), ...] and > (concatMap (\(x1, x2) -> x1 ++ x2) $ split ds xs) == xs > split _ [] == [([],[])] > split [] xs == [(xs,[])] > split xs xs == [([],[x1]),([],[x2]), ([],[x3]), ...] where xs == x1:x2:x2:...:[]. Examples would be > splitBy (=='/') "/a/b" == [("","/"),("a","/"),("b","")] > splitBy (=='/') "//aa//bb" == > [("","/"),("","/"),("aa","/"),("","/"),("bb","")] > splitBy (=='\n') "\na\nb" == [("","\n"),("a","\n"),("b","")] > split xs xs == [([],[x1]),([],[x2]), ([],[x3]), ...] > split " \t" "a\tb \tc\t d " == > [("a","\t"),("b"," "),("","\t"),("c","\t"),(""," "),("d"," ")] > split "/" "/a/b" == [("","/"),("a","/"),("b","")] This leaves the one remaining "simple" case which is splitting using a list such as "\r\n" which splitBy and split cannot handle easily. This leads to * splitUsing :: (Eq a) => [a] -> [a] -> [([a], [a])] such that > (concatMap (\(x1, x2) -> x1 ++ x2) $ splitUsing xs xs') == xs' > splitUsing _ [] == [([] , [])] > splitUsing [] xs == [(xs , [])] > splitUsing xs xs == [([] , xs)] Examples would be > splitUsing "\r\n" "a" == [("a", "")] > splitUsing "\r\n" "\r\n" == [("" , "\r\n")] > splitUsing "\r\n" "a\r\n" == [("a", "\r\n")] > splitUsing "\r\n" "a\r\n\r\n" == [("a", "\r\n"), ("" , "\r\n")] > splitUsing "\r\n" "a\r\nb" == [("a", "\r\n"), ("b", "")] > splitUsing "\r\n" "a\r\nb\r\n" == [("a", "\r\n"), ("b", "\r\n")] Wrapping up, based on a sort of logical extension, you could imagine * splitWhere :: ([a] -> Bool) -> [a] -> [([a], [a])] but I believe that this fourth word is one too many, cute, but not necessary. If the above three splitter words are not enough, then I would say that you need a more powerful tool beyond the spirit of the Haskell 98 standard List module. Just to check, the Haskell 98 List.lines function would be defined as > lines98 xs = map fst $ split "\n" xs and proper lines' and unlines' functions would be > lines' :: String -> Either [String] [String] > lines' [] = Left [] > lines' xs = > let res = split "\n" xs > nul = (null.snd.last) res > in (if nul then Left else Right) $ map fst res > > unlines' :: Either [String] [String] -> String > unlines' exss = intercalate "\n" $ either (id) (++[[]]) exss such that > unlines' . lines' == id This is to say, (Right [String]) if the original xs ends in '\n' and (Left [String]) if it does not. For your review, the attached file Split.hs defines and documents splitBy, split, splitUsing, and splitWhere, and the attached file SplitProperties.hs defines tests for these same words. Finally, I would propose adding splitBy, split, and splitUsing to Data.List as three words that fit within the spirit of the Haskell 98 List module, take off where break and span leave off, are unsplittable, and are "good enough". Cheers, - Marcus -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:marcus@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75 -------------- next part -------------- A non-text attachment was scrubbed... Name: Split.hs Type: text/x-haskell Size: 6707 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20090104/9822119d/Split-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: SplitProperties.hs Type: text/x-haskell Size: 8412 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20090104/9822119d/SplitProperties-0001.bin From lemming at henning-thielemann.de Sun Jan 4 17:22:15 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Jan 4 17:13:57 2009 Subject: different flavours of Monad Template Library Message-ID: I see now at least three MTL libraries at hackage, namely mtl mmtl mtl-tf They all define both the example data types and according type classes in modules with the same name. This way you can only use one of these packages in all packages you import. However the data types are defined the same way in the packages, only the classes differ. I wished, there would be one package defining only the datatypes, say "mtl-data", and three ones with the names "mtl", "mmtl", "mtl-tf" that define their classes with corresponding instances. These classes should be in different modules, so you can use different class frameworks in the same project. The data type package would be useful on its own and could be run on the simplest Haskell compilers, since no functional dependencies are required. However there is the compatibility problem: Currently Control.Monad.State exports also the MonadState class, which would no longer work. Maybe we can reserve Control.Monad.State for mtl, which exports Control.Monad.State.Data.Lazy from mtl-data and Control.Monad.State.Class from mtl. I assume that mmtl and mtl-tf are not as much used as mtl, such that it would not too bad to break compatibility for them. They could no longer export Control.Monad.State, but instead the user of mmtl has to import Control.Monad.State.Data from mtl-data. The class file of mmtl could be named Control.Monad.Modular.State.Class. (Replace "State" by "Writer", "Reader" and so on, and "mmtl" by "mtl-tf" in order to get all names that need to be adapted.) From lemming at henning-thielemann.de Sun Jan 4 17:25:32 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Jan 4 17:17:13 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <4961265C.2090709@gabriel.name> References: <4961265C.2090709@gabriel.name> Message-ID: On Sun, 4 Jan 2009, Marcus D. Gabriel wrote: > We seem to have not added any splitters such as splitBy or split to > Data.List despite the discussions. Here is yet another perspective > with the hope that it will make it. I assumed that the discussion was resolved by http://hackage.haskell.org/cgi-bin/hackage-scripts/package/split From marcus at gabriel.name Sun Jan 4 17:59:51 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Sun Jan 4 17:51:32 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: References: <4961265C.2090709@gabriel.name> Message-ID: <49613F67.3090305@gabriel.name> Henning Thielemann wrote: > > > On Sun, 4 Jan 2009, Marcus D. Gabriel wrote: > >> We seem to have not added any splitters such as splitBy or split to >> Data.List despite the discussions. Here is yet another perspective >> with the hope that it will make it. > > I assumed that the discussion was resolved by > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/split I did not have that impression. I saw, read, and played with this package, but some how I just thought that it was a shame that in 98 one did not continue just a little bit farther beyond span and break in the the List module and make splitBy and split, at least. These two with something to handle "\r\n" would do much for the simple cases. After this, give up and use a bigger hammer such as Alex, Parsec, etc. Maybe the correct stopping point is break and span whereupon you find a package at the correct level for what you need. But my feeling is that if splitBy and split had been in all along, they would have been useful, and the next step would be other modules and packages as we have. -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:marcus@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75 From ross at soi.city.ac.uk Sun Jan 4 18:50:28 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Jan 4 18:42:11 2009 Subject: different flavours of Monad Template Library In-Reply-To: References: Message-ID: <20090104235028.GA18161@soi.city.ac.uk> On Sun, Jan 04, 2009 at 11:22:15PM +0100, Henning Thielemann wrote: > I see now at least three MTL libraries at hackage, namely > mtl > mmtl > mtl-tf > > They all define both the example data types and according type classes > in modules with the same name. This way you can only use one of these > packages in all packages you import. However the data types are defined > the same way in the packages, only the classes differ. > > I wished, there would be one package defining only the datatypes, say > "mtl-data", and three ones with the names "mtl", "mmtl", "mtl-tf" that > define their classes with corresponding instances. These classes should > be in different modules, so you can use different class frameworks in the > same project. The data type package would be useful on its own and could > be run on the simplest Haskell compilers, since no functional > dependencies are required. I agree. I had a go at such a restructuring of mtl a while ago: http://darcs.haskell.org/packages/transformers/ http://darcs.haskell.org/packages/mtl-split/ The first is a Haskell 98 package that defines the monad transformers, operations and liftings, like the mtl-data suggestion. The second adds the FD-based classes. It's close to complete compatibility with mtl, except that State is a synonym for StateT Identity etc. The main problem was haddock's limitations with inter-package re-exports. > However there is the compatibility problem: Currently > Control.Monad.State exports also the MonadState class, which would no > longer work. Maybe we can reserve Control.Monad.State for mtl, which > exports Control.Monad.State.Data.Lazy from mtl-data and > Control.Monad.State.Class from mtl. I used Control.Monad.Trans.State.Lazy for the transformer. From lemming at henning-thielemann.de Sun Jan 4 19:07:00 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Jan 4 18:58:42 2009 Subject: different flavours of Monad Template Library In-Reply-To: <20090104235028.GA18161@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> Message-ID: On Sun, 4 Jan 2009, Ross Paterson wrote: > I agree. I had a go at such a restructuring of mtl a while ago: > > http://darcs.haskell.org/packages/transformers/ > http://darcs.haskell.org/packages/mtl-split/ I wondered, where the packages were gone ... > The first is a Haskell 98 package that defines the monad transformers, > operations and liftings, like the mtl-data suggestion. The second adds > the FD-based classes. It's close to complete compatibility with mtl, > except that State is a synonym for StateT Identity etc. The main > problem was haddock's limitations with inter-package re-exports. What is the current state, since Haddock has moved to GHC-API? At least 'transformers' seems to be distinct enough from current MTL and simple enough to be uploaded to Hackage right now. However, Control.Monad.Identity would conflict with MTL. Without that, 'transformers' could be even used together with the current MTL. From ross at soi.city.ac.uk Sun Jan 4 19:44:35 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Jan 4 19:36:18 2009 Subject: different flavours of Monad Template Library In-Reply-To: References: <20090104235028.GA18161@soi.city.ac.uk> Message-ID: <20090105004435.GA19040@soi.city.ac.uk> On Mon, Jan 05, 2009 at 01:07:00AM +0100, Henning Thielemann wrote: > On Sun, 4 Jan 2009, Ross Paterson wrote: >> The main problem was haddock's limitations with inter-package re-exports. > > What is the current state, since Haddock has moved to GHC-API? That makes no difference to this issue (#24 on the Haddock trac; #13 is also relevant). > At least 'transformers' seems to be distinct enough from current MTL > and simple enough to be uploaded to Hackage right now. OK, I've done that. > However, Control.Monad.Identity would conflict with MTL. Unfortunately that is necessary to make the split work. If we have a monad-classes-fd package, clients would have to depend on both it and transformers. From ajb at spamcop.net Sun Jan 4 19:53:53 2009 From: ajb at spamcop.net (ajb@spamcop.net) Date: Sun Jan 4 19:45:34 2009 Subject: different flavours of Monad Template Library In-Reply-To: <20090104235028.GA18161@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> Message-ID: <20090104195353.0afy7ngsg4g04kgw-nwo@webmail.spamcop.net> G'day all. Quoting Ross Paterson : > I agree. I had a go at such a restructuring of mtl a while ago: > > http://darcs.haskell.org/packages/transformers/ > http://darcs.haskell.org/packages/mtl-split/ I'm curious if anyone has tried restructuring MTL with coproducts rather than transformers. Coproducts seem more "natural", if slightly harder to write. Cheers, Andrew Bromage From allbery at ece.cmu.edu Sun Jan 4 21:33:21 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Jan 4 21:25:07 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <49613F67.3090305@gabriel.name> References: <4961265C.2090709@gabriel.name> <49613F67.3090305@gabriel.name> Message-ID: <0D958869-328D-4176-A325-9D4299825B68@ece.cmu.edu> On 2009 Jan 4, at 17:59, Marcus D. Gabriel wrote: > Henning Thielemann wrote: >> On Sun, 4 Jan 2009, Marcus D. Gabriel wrote: >>> We seem to have not added any splitters such as splitBy or split to >>> Data.List despite the discussions. Here is yet another perspective >>> with the hope that it will make it. >> >> I assumed that the discussion was resolved by >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/split > > I did not have that impression. The discussion demonstrated why there is no standard split in Data.List: nobody can agree on how it should work. Hence the Split package, which should allow us to find out which ones get used and which don't, and which are viable candidates for addition to Data.List. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From claudiusmaximus at goto10.org Mon Jan 5 01:19:08 2009 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Mon Jan 5 01:10:50 2009 Subject: piping with System.Process.createProcess Message-ID: <4961A65C.5050106@goto10.org> Greetings, I think I found a bug in the process package. GNU/Linux Debian Lenny ghc-6.8.2 process-1.0.1.1 The short version: UseHandle fails for input streams (subprocess can't read from it). The long version: > import System.Process > import System.IO (Handle, hGetLine, hPutStrLn, hIsEOF, hClose) > import System.Environment (getArgs) > import Control.Concurrent (forkIO, threadDelay) > import Control.Monad (forever, unless) Forward ------- A pipeline of processes defined in the "forwards" direction (where the next process's input handle is the previous process's output handle). > pipeForwards :: IO (Handle, Handle) > pipeForwards = do > (Just input, Just pipe, _, _) <- createProcess (proc "cat" []){ std_in = CreatePipe, std_out = CreatePipe } > (_, Just output, _, _) <- createProcess (proc "cat" []){ std_in = UseHandle pipe, std_out = CreatePipe } > return (input, output) Data would flow through this pipe from top to bottom, which I find to be intuitive. However, pipeForwards is broken; it fails with the message "cat: -: Resource temporarily unavailable". (The "cat" that fails is the "cat" with the UseHandle.) Backward -------- A pipeline of processes defined in the "backwards" direction (where the next process's output handle is the previous process's input handle). Data flows through this pipe from bottom to top, which I find to be more confusing. But at least it works. > pipeBackwards :: IO (Handle, Handle) > pipeBackwards = do > (Just pipe, Just output, _, _) <- createProcess (proc "cat" []){ std_in = CreatePipe, std_out = CreatePipe } > (Just input, _, _, _) <- createProcess (proc "cat" []){ std_in = CreatePipe, std_out = UseHandle pipe } > return (input, output) Scaffold -------- The main program pipes some data through one of the pipelines, depending on the command line arguments. > main :: IO () > main = do > args <- getArgs > (input, output) <- if null args then pipeForwards else pipeBackwards > forkIO $ reader output > forkIO $ writer input > mainLoop The reader thread will read all the lines from a handle and print them out. > whileNotM :: Monad m => m Bool -> m a -> m () > whileNotM t a = t >>= \b -> unless b $ a >> whileNotM t a > reader :: Handle -> IO () > reader h = whileNotM (hIsEOF h) (hGetLine h >>= putStrLn) The writer thread will write some lines to a handle and then close it. > writer :: Handle -> IO () > writer h = mapM_ (hPutStrLn h . replicate 10) ['a'..'z'] >> hClose h The main thread will do nothing, so far as can be observed, and exists solely to avoid premature termination of the program. > mainLoop :: IO () > mainLoop = forever $ threadDelay 1000000 Thanks for your attention, Claude -- http://claudiusmaximus.goto10.org From lemming at henning-thielemann.de Mon Jan 5 03:32:21 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 5 03:24:02 2009 Subject: different flavours of Monad Template Library In-Reply-To: <20090105004435.GA19040@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> <20090105004435.GA19040@soi.city.ac.uk> Message-ID: On Mon, 5 Jan 2009, Ross Paterson wrote: > On Mon, Jan 05, 2009 at 01:07:00AM +0100, Henning Thielemann wrote: > >> At least 'transformers' seems to be distinct enough from current MTL >> and simple enough to be uploaded to Hackage right now. > > OK, I've done that. > >> However, Control.Monad.Identity would conflict with MTL. > > Unfortunately that is necessary to make the split work. If we have > a monad-classes-fd package, clients would have to depend on both it > and transformers. How about Control.Monad.Trans.Identity which is re-exported by Control.Monad.Identity in mtl? I also like to have a function 'state', which replaces the former 'State' constructor. I can also submit a patch if you want that. From ross at soi.city.ac.uk Mon Jan 5 04:20:11 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jan 5 04:11:51 2009 Subject: different flavours of Monad Template Library In-Reply-To: References: <20090104235028.GA18161@soi.city.ac.uk> <20090105004435.GA19040@soi.city.ac.uk> Message-ID: <20090105092011.GA2050@soi.city.ac.uk> On Mon, Jan 05, 2009 at 09:32:21AM +0100, Henning Thielemann wrote: > On Mon, 5 Jan 2009, Ross Paterson wrote: >> On Mon, Jan 05, 2009 at 01:07:00AM +0100, Henning Thielemann wrote: >>> However, Control.Monad.Identity would conflict with MTL. >> >> Unfortunately that is necessary to make the split work. If we have >> a monad-classes-fd package, clients would have to depend on both it >> and transformers. > > How about Control.Monad.Trans.Identity which is re-exported by > Control.Monad.Identity in mtl? Hmm, it's a conflict between co-existing with mtl and using the Right Name for the transformers package, which is intended to be usable by itself. I prefer the latter, myself. > I also like to have a function 'state', which replaces the former 'State' > constructor. I can also submit a patch if you want that. You mean state :: (s -> (a, s)) -> State s a state f = StateT (Identity . f) and similarly for all the others? Sounds reasonable. From lemming at henning-thielemann.de Mon Jan 5 06:54:20 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 5 06:46:00 2009 Subject: different flavours of Monad Template Library In-Reply-To: <20090105092011.GA2050@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> <20090105004435.GA19040@soi.city.ac.uk> <20090105092011.GA2050@soi.city.ac.uk> Message-ID: On Mon, 5 Jan 2009, Ross Paterson wrote: > On Mon, Jan 05, 2009 at 09:32:21AM +0100, Henning Thielemann wrote: >> >> How about Control.Monad.Trans.Identity which is re-exported by >> Control.Monad.Identity in mtl? > > Hmm, it's a conflict between co-existing with mtl and using the > Right Name for the transformers package, which is intended to be > usable by itself. I prefer the latter, myself. You mean that Control.Monad.Trans.Identity is not a good name, because Identity is not a transformer? Then, how about Control.Monad.Base.Identity, Control.Monad.Primitive.Identity or so? Since mtl-split is not a drop-in replacement for mtl, we cannot expect a quick change from mtl to mtl-split in all the packages that currently import mtl. Thus we have to think about a route of transition and a package which can be installed in parallel to mtl is a first step, I think. >> I also like to have a function 'state', which replaces the former >> 'State' constructor. I can also submit a patch if you want that. > > You mean > > state :: (s -> (a, s)) -> State s a > state f = StateT (Identity . f) > > and similarly for all the others? Sounds reasonable. That's what I mean. From lemming at henning-thielemann.de Mon Jan 5 07:06:37 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 5 06:58:16 2009 Subject: different flavours of Monad Transformer Library In-Reply-To: <20090105092011.GA2050@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> <20090105004435.GA19040@soi.city.ac.uk> <20090105092011.GA2050@soi.city.ac.uk> Message-ID: On Mon, 5 Jan 2009, Ross Paterson wrote: > On Mon, Jan 05, 2009 at 09:32:21AM +0100, Henning Thielemann wrote: > >> I also like to have a function 'state', which replaces the former 'State' >> constructor. I can also submit a patch if you want that. > > You mean > > state :: (s -> (a, s)) -> State s a > state f = StateT (Identity . f) > > and similarly for all the others? Sounds reasonable. You have already added them, thanks! Maybe you can even add 'stateT' and the likes in order to give programmers a way of staying independent from the particular definition of StateT. From lemming at henning-thielemann.de Mon Jan 5 07:15:41 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 5 07:07:20 2009 Subject: different flavours of Monad Transformer Library In-Reply-To: <20090105092011.GA2050@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> <20090105004435.GA19040@soi.city.ac.uk> <20090105092011.GA2050@soi.city.ac.uk> Message-ID: On Mon, 5 Jan 2009, Ross Paterson wrote: > On Mon, Jan 05, 2009 at 09:32:21AM +0100, Henning Thielemann wrote: >> >> How about Control.Monad.Trans.Identity which is re-exported by >> Control.Monad.Identity in mtl? > > Hmm, it's a conflict between co-existing with mtl and using the > Right Name for the transformers package, which is intended to be > usable by itself. I prefer the latter, myself. It's me again ... The package contains Control.Monad.Trans which also conflicts with mtl. Maybe it can be split into Control.Monad.Trans.Class Control.Monad.IO.Class Which would no longer conflict with mtl and is cleaner I think (or did anyone, who wanted to import MonadIO class, expect it in Control.Monad.Trans?) From ross at soi.city.ac.uk Mon Jan 5 07:24:36 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jan 5 07:16:21 2009 Subject: different flavours of Monad Template Library In-Reply-To: References: <20090104235028.GA18161@soi.city.ac.uk> <20090105004435.GA19040@soi.city.ac.uk> <20090105092011.GA2050@soi.city.ac.uk> Message-ID: <20090105122436.GA3312@soi.city.ac.uk> On Mon, Jan 05, 2009 at 12:54:20PM +0100, Henning Thielemann wrote: > You mean that Control.Monad.Trans.Identity is not a good name, because > Identity is not a transformer? Yes, and that Control.Monad.Identity is the right name (and that the transformers package is supposed to be usable in its own right). > Since mtl-split is not a drop-in replacement for mtl, we cannot expect a > quick change from mtl to mtl-split in all the packages that currently > import mtl. Thus we have to think about a route of transition and a > package which can be installed in parallel to mtl is a first step, I > think. My understanding is that GHC will allow both to be installed, and allow packages that use transformers and those that use mtl to be used together in the same program. What you can't do is use both transformers and mtl directly in the same package, but that's no big loss. From lemming at henning-thielemann.de Mon Jan 5 07:43:14 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 5 07:34:54 2009 Subject: different flavours of Monad Transformer Library In-Reply-To: <20090105122436.GA3312@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> <20090105004435.GA19040@soi.city.ac.uk> <20090105092011.GA2050@soi.city.ac.uk> <20090105122436.GA3312@soi.city.ac.uk> Message-ID: On Mon, 5 Jan 2009, Ross Paterson wrote: > On Mon, Jan 05, 2009 at 12:54:20PM +0100, Henning Thielemann wrote: > >> Since mtl-split is not a drop-in replacement for mtl, we cannot expect a >> quick change from mtl to mtl-split in all the packages that currently >> import mtl. Thus we have to think about a route of transition and a >> package which can be installed in parallel to mtl is a first step, I >> think. > > My understanding is that GHC will allow both to be installed, and allow > packages that use transformers and those that use mtl to be used together > in the same program. What you can't do is use both transformers and > mtl directly in the same package, but that's no big loss. If this is true, then I will no longer complain. What about Hugs and others? From ross at soi.city.ac.uk Mon Jan 5 07:49:18 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jan 5 07:40:58 2009 Subject: different flavours of Monad Transformer Library In-Reply-To: References: <20090104235028.GA18161@soi.city.ac.uk> <20090105004435.GA19040@soi.city.ac.uk> <20090105092011.GA2050@soi.city.ac.uk> <20090105122436.GA3312@soi.city.ac.uk> Message-ID: <20090105124918.GB3312@soi.city.ac.uk> On Mon, Jan 05, 2009 at 01:43:14PM +0100, Henning Thielemann wrote: > On Mon, 5 Jan 2009, Ross Paterson wrote: >> My understanding is that GHC will allow both to be installed, and allow >> packages that use transformers and those that use mtl to be used together >> in the same program. What you can't do is use both transformers and >> mtl directly in the same package, but that's no big loss. > > If this is true, then I will no longer complain. What about Hugs and > others? Hugs should be OK: it won't complain about a conflict, and the modules of the same name will be compatible. I don't think any other compilers support functional dependencies, so they would have no mtl to preserve. From allbery at ece.cmu.edu Mon Jan 5 12:49:33 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Jan 5 12:41:29 2009 Subject: piping with System.Process.createProcess In-Reply-To: <4961A65C.5050106@goto10.org> References: <4961A65C.5050106@goto10.org> Message-ID: On 2009 Jan 5, at 1:19, Claude Heiland-Allen wrote: > Data would flow through this pipe from top to bottom, which I find to > be intuitive. However, pipeForwards is broken; it fails with the > message "cat: -: Resource temporarily unavailable". (The "cat" that > fails is the "cat" with the UseHandle.) Sounds like the runtime isn't switching the pipe to blocking read mode before handing it off to the subprocess. You should submit a bug report: http://hackage.haskell.org/trac/ghc/wiki/ReportABug -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From twanvl at gmail.com Tue Jan 6 06:06:17 2009 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue Jan 6 05:57:52 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord Message-ID: <49633B29.8030309@gmail.com> Hello list, About two and a half months ago I proposed that the following newtype (under the name "Down") be added to Data.Ord: newtype ReverseOrd a = ReverseOrd { getReverseOrd :: a } instance Ord ReverseOrd where a <= b = getReverseOrd b <= getReverseOrd a -- other methods, etc. I never followed up to that post, so I am doing that now. Since the discussion period has ended, let me summarize of responses: 1. Everyone is in favor of adding it 2. There is some criticism of the name 3. Some people (apfelmus) didn't like the getReverseOrd function As an alternative name, Isaac suggested "Reverse", "ReverseOrd" or "Opposite". I don't really like the name "Reverse", because that can mean many things: reversing a list, reverse order of composition, inverse/reverse a relation, etc. Although it is a bit verbose, "ReverseOrd" is the most clear. Concerning the "get" function: there is lots precedence in - Monoid wrappers (Sum, Product, Endo, etc.) - Applicative wrappers (ZipList, Const, etc.) - mtl types (State, Reader, etc.), To resolve the naming bikeshed issue, and because it has been a long time since the discussion ended, I propose an additional discussion period of 1 week, ending January 13. Twan From bertram.felgenhauer at googlemail.com Tue Jan 6 06:22:14 2009 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Tue Jan 6 06:13:54 2009 Subject: piping with System.Process.createProcess In-Reply-To: <4961A65C.5050106@goto10.org> References: <4961A65C.5050106@goto10.org> Message-ID: <20090106112214.GA4225@zombie.inf.tu-dresden.de> Claude Heiland-Allen wrote: > Greetings, > > I think I found a bug in the process package. > > GNU/Linux Debian Lenny > ghc-6.8.2 > process-1.0.1.1 Hmm, I can't reproduce it in ghc 6.8.3 or 6.10.1. IIRC, there were some changes with regards to pipes and broken pipe errors between 6.8.2 and 6.8.3, but details elude me. Can you try a newer ghc? Bertram From kahl at cas.mcmaster.ca Tue Jan 6 10:01:25 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Tue Jan 6 09:53:05 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <49633B29.8030309@gmail.com> (message from Twan van Laarhoven on Tue, 06 Jan 2009 12:06:17 +0100) References: <49633B29.8030309@gmail.com> Message-ID: <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> Twan van Laarhoven wrote: > > About two and a half months ago I proposed that the following newtype (under the > name "Down") be added to Data.Ord: > > newtype ReverseOrd a = ReverseOrd { getReverseOrd :: a } > > instance Ord ReverseOrd where > a <= b = getReverseOrd b <= getReverseOrd a > -- other methods, etc. > > [...] > > I don't really like the name "Reverse", Me neither... How about: -- intended for |qualified| import |as Ord|: newtype Dual a = Dual { unDual :: a } deriving Eq instance Ord a => Ord (Dual a) where Dual x <= Dual y = y <= x Dual x < Dual y = y < x Dual x >= Dual y = y >= x Dual x > Dual y = y > x Dual x `compare` Dual y = y `compare` x Dual x `min` Dual y = y `max` x Dual x `max` Dual y = y `min` x Wolfram From g9ks157k at acme.softbase.org Tue Jan 6 10:33:40 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Jan 6 10:25:16 2009 Subject: MonadPlus instance for ContT Message-ID: <200901061633.40320.g9ks157k@acme.softbase.org> Hello, I wonder why there isn?t a MonadPlus instance for ContT. In my opinion, this one would be natural: > instance (MonadPlus monad) => MonadPlus (ContT result monad) where > > mzero = ContT $ return mzero > > ContT cont1 `mplus` ContT cont2 = ContT $ liftM2 mplus cont1 cont2 return and liftM2 are the ones of (->) (o -> monad result). What do you think? Best wishes, Wolfgang From twanvl at gmail.com Tue Jan 6 10:58:50 2009 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue Jan 6 10:50:23 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> Message-ID: <49637FBA.50808@gmail.com> kahl@cas.mcmaster.ca wrote: > Me neither... > > How about: > > -- intended for |qualified| import |as Ord|: > newtype Dual a = Dual { unDual :: a } deriving Eq In my opinion "dual" is even worse: - "dual" is not a name that people think about when they want something sorted in descending order or they want a different priority queue, etc. I think of names like "reverse", "descending" and "something to do with order". - "dual" can mean many more things. First of all there are different dualities in mathematics, I guess this refers to the categorical dual. Then there are many ways to use that duality in Haskell. The first thing that comes to mind, and which is a closer fit, is newtype Op t a b = Op (t b a), the dual of a Control.Category style category. Twan From ganesh.sittampalam at credit-suisse.com Tue Jan 6 11:01:50 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Jan 6 10:54:16 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <49637FBA.50808@gmail.com> References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <49637FBA.50808@gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCAA4@ELON17P32001A.csfb.cs-group.com> Twan wrote: > kahl@cas.mcmaster.ca wrote: > > -- intended for |qualified| import |as Ord|: > > newtype Dual a = Dual { unDual :: a } deriving Eq > In my opinion "dual" is even worse: "opposite"? I'm also happy with anything suggested already. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From s.clover at gmail.com Tue Jan 6 11:26:09 2009 From: s.clover at gmail.com (Sterling Clover) Date: Tue Jan 6 11:16:24 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <49637FBA.50808@gmail.com> References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <49637FBA.50808@gmail.com> Message-ID: <0BE43067-B581-4B25-A5F7-DD831A871670@gmail.com> FlipOrd { unFlipOrd :: a } ? --S On Jan 6, 2009, at 10:58 AM, Twan van Laarhoven wrote: > kahl@cas.mcmaster.ca wrote: >> Me neither... >> How about: >> -- intended for |qualified| import |as Ord|: >> newtype Dual a = Dual { unDual :: a } deriving Eq > > In my opinion "dual" is even worse: > > - "dual" is not a name that people think about when they want > something sorted in descending order or they want a different > priority queue, etc. I think of names like "reverse", "descending" > and "something to do with order". > > - "dual" can mean many more things. First of all there are > different dualities in mathematics, I guess this refers to the > categorical dual. Then there are many ways to use that duality in > Haskell. The first thing that comes to mind, and which is a closer > fit, is newtype Op t a b = Op (t b a), the dual of a > Control.Category style category. > > Twan > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From deduktionstheorem at web.de Tue Jan 6 11:34:28 2009 From: deduktionstheorem at web.de (Stephan Friedrichs) Date: Tue Jan 6 11:26:11 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <49633B29.8030309@gmail.com> References: <49633B29.8030309@gmail.com> Message-ID: <49638814.2070402@web.de> Twan van Laarhoven wrote: > About two and a half months ago I proposed that the following newtype > (under the name "Down") be added to Data.Ord: > > newtype ReverseOrd a = ReverseOrd { getReverseOrd :: a } > > instance Ord ReverseOrd where > a <= b = getReverseOrd b <= getReverseOrd a > -- other methods, etc. IMHO this type is very important! I had to use a hack in my heap package [1] (see HeapPolicy class and XYPolicy phantom tpyes, they allow redefining an ordering relation), because there is no such thing in the base libraries. The aim was to make type safe distinctions between minimum- and maximum ordered heaps. With a ReverseOrd type, I could just provide a minimum ordered heap. Then it would be much more obvious, how to use the package. I'm not saying that the heap package is the one and only reason for introducinging something like ReverseOrd, but I am saying that it addresses a common problem one quickly encounters. As for the name of the newtype, I'd prefer ReverseOrd, as it best describes the intended usage: Reversing the ordering relation of a type. Other possibilities are: - FlipOrd (beacuse (flip compare) is the desired effect) - Descending[Ord] (opposed to ascending order) - Reorder (unfortunately doesn't describe how it's reordered) just my 2 cents :) > > [...] > Regards, Stephan [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr From kahl at cas.mcmaster.ca Tue Jan 6 12:15:46 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Tue Jan 6 12:07:26 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <49637FBA.50808@gmail.com> (message from Twan van Laarhoven on Tue, 06 Jan 2009 16:58:50 +0100) References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <49637FBA.50808@gmail.com> Message-ID: <20090106171546.6444.qmail@schroeder.cas.mcmaster.ca> Twan van Laarhoven replied: > kahl@cas.mcmaster.ca wrote: > > Me neither... > > > > How about: > > > > -- intended for |qualified| import |as Ord|: > > newtype Dual a = Dual { unDual :: a } deriving Eq > [...] > > - "dual" can mean many more things. Exactly --- that's why I propose qualified import, so one would use, e.g.: sort . map Ord.Dual clarifying that one is using the dual Ord instance. (Ordering duality is about the fact that the converse of an ordering relation is an ordering relation again; the Haskell type class |Ord| is the special case of linear orderings. ) This is standard terminology, and I think we should encourage such use of standard terminology and concepts. Of course, alternatives remain available, in the spirit of Henning Thielemann's ``Warm, fuzzy thing Transformer'': > It was argued that people avoid Haskell because of terms from Category > theory like 'Monad'. This problem can now be solved by a wrapper which > presents all the WWW without monads! Start e.g. at > > http://saxophone.jpberlin.de/MonadTransformer?source=http%3A%2F%2Fwww%2Ehaskell%2Eorg%2Fhaskellwiki%2FCategory%3AMonad&language=English ;-) Wolfram From rwbarton at math.harvard.edu Tue Jan 6 13:12:36 2009 From: rwbarton at math.harvard.edu (Reid Barton) Date: Tue Jan 6 13:04:11 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <20090106171546.6444.qmail@schroeder.cas.mcmaster.ca> References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <49637FBA.50808@gmail.com> <20090106171546.6444.qmail@schroeder.cas.mcmaster.ca> Message-ID: <20090106181236.GA6881@rwbarton.mit.edu> On Tue, Jan 06, 2009 at 05:15:46PM -0000, kahl@cas.mcmaster.ca wrote: [...] > Exactly --- that's why I propose qualified import, > so one would use, e.g.: > > sort . map Ord.Dual > > clarifying that one is using the dual Ord instance. > (Ordering duality is about the fact that > the converse of an ordering relation is an ordering relation again; > the Haskell type class |Ord| is the special case of linear orderings. > ) > > This is standard terminology, > and I think we should encourage > such use of standard terminology and concepts. In my part of the category-theory world, standard terminology is "opposite category" and thus "opposite ordering" (since a partial order is a special case of a category). But I would not be too surprised to hear "dual ordering" as well. (By the way, a much worse abuse of the name Dual already exists in Data.Monoid, to describe the operation of flipping the arguments of the multiplication in a monoid. This should certainly be called the opposite monoid. Google for "dual monoid" and you will find that all uses of that term are for other concepts.) > Of course, alternatives remain available, > in the spirit of Henning Thielemann's ``Warm, fuzzy thing Transformer'': > > > It was argued that people avoid Haskell because of terms from Category > > theory like 'Monad'. This problem can now be solved by a wrapper which > > presents all the WWW without monads! Start e.g. at > > > > http://saxophone.jpberlin.de/MonadTransformer?source=http%3A%2F%2Fwww%2Ehaskell%2Eorg%2Fhaskellwiki%2FCategory%3AMonad&language=English > > ;-) While "opposite" is a term used in category theory, it's also a perfectly ordinary word that has the right connotations to non-mathematicians. "Dual" is a little scary, I think. Regards, Reid From schlepptop at henning-thielemann.de Tue Jan 6 19:10:08 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 6 18:55:45 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <20090106171546.6444.qmail@schroeder.cas.mcmaster.ca> References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <49637FBA.50808@gmail.com> <20090106171546.6444.qmail@schroeder.cas.mcmaster.ca> Message-ID: <4963F2E0.8080309@henning-thielemann.de> kahl@cas.mcmaster.ca schrieb: > Of course, alternatives remain available, > in the spirit of Henning Thielemann's ``Warm, fuzzy thing Transformer'': > >> It was argued that people avoid Haskell because of terms from Category >> theory like 'Monad'. This problem can now be solved by a wrapper which >> presents all the WWW without monads! Start e.g. at >> >> http://saxophone.jpberlin.de/MonadTransformer?source=http%3A%2F%2Fwww%2Ehaskell%2Eorg%2Fhaskellwiki%2FCategory%3AMonad&language=English > > ;-) Thanks for quoting it! Btw. now you can also access it via a warmer, but less fuzzier URL: http://www.haskell.org.monadtransformer.parallelnetz.de/haskellwiki/Category:Monad I can easily add a replacement Ord.Dual -> "Somehow different" and "Existential quantification -> Hidden type variable" ... From stefan at cs.uu.nl Wed Jan 7 01:38:21 2009 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed Jan 7 01:29:57 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> Message-ID: <165B3128-BD17-407E-9321-2F1083314C70@cs.uu.nl> Twan, > How about: > > -- intended for |qualified| import |as Ord|: > newtype Dual a = Dual { unDual :: a } deriving Eq +1 for Dual. Cheers, Stefan From roconnor at theorem.ca Wed Jan 7 10:25:14 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Wed Jan 7 10:16:47 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <165B3128-BD17-407E-9321-2F1083314C70@cs.uu.nl> References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <165B3128-BD17-407E-9321-2F1083314C70@cs.uu.nl> Message-ID: On Wed, 7 Jan 2009, Stefan Holdermans wrote: > Twan, > >> How about: >> >> -- intended for |qualified| import |as Ord|: >> newtype Dual a = Dual { unDual :: a } deriving Eq > > +1 for Dual. +1 for Dual. The term seems common in lattice theory. I use it myself. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From mjj at Cs.Nott.AC.UK Wed Jan 7 12:23:05 2009 From: mjj at Cs.Nott.AC.UK (Mauro J. Jaskelioff) Date: Wed Jan 7 12:20:50 2009 Subject: different flavours of Monad Transformer Library (fwd) In-Reply-To: References: Message-ID: <4964E4F9.6000508@cs.nott.ac.uk> Hi, sorry for the late reply, I have no problem with your proposal (mtl-data). I'd prefer to have all the liftings in the same package, though (and not just separate the ones with FD). I also like Ross' idea of monads being synonyms for transformers at Id. It removes lots of repeated code. Wrt portability, I'm working an another experimental monad transformer library (http://www.cs.nott.ac.uk/~mjj/monatron ) which, unlike mmtl, does not try to be backwards compatible with mtl. It contains a core with full functionality (except operation overloading) which should work in Haskell 98+Rank2Functors. Lack of operation overloading means you have to be explicit about the liftings. (for example, declare you want the operation 'catch' lifted through 2 monad transformers) With other extensions (FD, multiparameter classes, etc.) you also get operation overloading. All the best, - Mauro Henning Thielemann wrote: > > I don't know whether you are on the libraries@haskell.org list ... > > ---------- Forwarded message ---------- > Date: Sun, 4 Jan 2009 23:50:28 +0000 > From: Ross Paterson > To: libraries@haskell.org > Subject: Re: different flavours of Monad Template Library > > On Sun, Jan 04, 2009 at 11:22:15PM +0100, Henning Thielemann wrote: >> I see now at least three MTL libraries at hackage, namely >> mtl >> mmtl >> mtl-tf >> >> They all define both the example data types and according type classes >> in modules with the same name. This way you can only use one of these >> packages in all packages you import. However the data types are defined >> the same way in the packages, only the classes differ. >> >> I wished, there would be one package defining only the datatypes, say >> "mtl-data", and three ones with the names "mtl", "mmtl", "mtl-tf" that >> define their classes with corresponding instances. These classes should >> be in different modules, so you can use different class frameworks in >> the >> same project. The data type package would be useful on its own and could >> be run on the simplest Haskell compilers, since no functional >> dependencies are required. > > I agree. I had a go at such a restructuring of mtl a while ago: > > http://darcs.haskell.org/packages/transformers/ > http://darcs.haskell.org/packages/mtl-split/ > > The first is a Haskell 98 package that defines the monad transformers, > operations and liftings, like the mtl-data suggestion. The second adds > the FD-based classes. It's close to complete compatibility with mtl, > except that State is a synonym for StateT Identity etc. The main > problem was haddock's limitations with inter-package re-exports. > >> However there is the compatibility problem: Currently >> Control.Monad.State exports also the MonadState class, which would no >> longer work. Maybe we can reserve Control.Monad.State for mtl, which >> exports Control.Monad.State.Data.Lazy from mtl-data and >> Control.Monad.State.Class from mtl. > > I used Control.Monad.Trans.State.Lazy for the transformer. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From bart at cs.pdx.edu Wed Jan 7 12:47:16 2009 From: bart at cs.pdx.edu (Bart Massey) Date: Wed Jan 7 12:39:01 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <165B3128-BD17-407E-9321-2F1083314C70@cs.uu.nl> Message-ID: theorem.ca> writes: > On Wed, 7 Jan 2009, Stefan Holdermans wrote: > > +1 for Dual. > +1 for Dual. The term seems common in lattice theory. I use it myself. Dual is horrible. The term is in general ambiguous and in this context gratuitously pseudo-technical. RevOrd, Reverse or Descending are about as good as I've heard. Bart Massey bart cs.pdx.edu From twanvl at gmail.com Wed Jan 7 13:48:07 2009 From: twanvl at gmail.com (Twan van Laarhoven) Date: Wed Jan 7 13:39:35 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <165B3128-BD17-407E-9321-2F1083314C70@cs.uu.nl> Message-ID: <4964F8E7.1080406@gmail.com> roconnor@theorem.ca wrote: > On Wed, 7 Jan 2009, Stefan Holdermans wrote: > >> Twan, >> >>> How about: >>> >>> -- intended for |qualified| import |as Ord|: >>> newtype Dual a = Dual { unDual :: a } deriving Eq >> >> >> +1 for Dual. > > > +1 for Dual. The term seems common in lattice theory. I use it myself. > Dual does seem to be the right term, but I suggest using DualOrd or DualOrdering instead. The fact that it can be imported qualified is no reason to confuse people, in many cases the function will not be imported qualified, since conflicts are very unlikely. To me just "dual" does not immediatly suggest a reverse ordering. Consider also: sortBy (comparing `on` Dual . fst) stuff vs. sortBy (comparing `on` DualOrd . fst) stuff In the first version it is not immediatly clear that dual has something to do with the ordering, and not just taking some kind of dual of something in some other way. Also, the record selector should be called getDual{Ord}, in accordance with the monoid wrappers and mtl types. In summary, I like: DualOrd{ering}, ReverseOrd{ering} and am okay with Desc{ending}. Twan From aslatter at gmail.com Wed Jan 7 15:28:08 2009 From: aslatter at gmail.com (Antoine Latter) Date: Wed Jan 7 15:19:40 2009 Subject: different flavours of Monad Transformer Library (fwd) In-Reply-To: <4964E4F9.6000508@cs.nott.ac.uk> References: <4964E4F9.6000508@cs.nott.ac.uk> Message-ID: <694519c50901071228ocf0de1y7d7a7e6d695d3643@mail.gmail.com> On Wed, Jan 7, 2009 at 11:23 AM, Mauro J. Jaskelioff wrote: > Hi, sorry for the late reply, > > I also like Ross' idea of monads being synonyms for transformers at Id. > It removes lots of repeated code. > There's a cost to that technique. Parsec3 introduced parsec as a monad transformer, and the parsec base monad is implemented as the transformer wrapped around the identity monad. There's a significant speed regression to doing so - I have a branch of Parsec3 which re-introduces a proper base monad and shares (some) code via typeclasses. This puts us back at Parsec2 numbers. I don't have any hard data on hand at the moment, it's been a while. -Antoine From kahl at cas.mcmaster.ca Wed Jan 7 15:34:40 2009 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Wed Jan 7 15:26:16 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <4964F8E7.1080406@gmail.com> (message from Twan van Laarhoven on Wed, 07 Jan 2009 19:48:07 +0100) References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <165B3128-BD17-407E-9321-2F1083314C70@cs.uu.nl> <4964F8E7.1080406@gmail.com> Message-ID: <20090107203440.9356.qmail@schroeder.cas.mcmaster.ca> Twan van Laarhoven replied: > >>> How about: > >>> > >>> -- intended for |qualified| import |as Ord|: > >>> newtype Dual a = Dual { unDual :: a } deriving Eq > >> > >> > >> +1 for Dual. > > > > > > +1 for Dual. The term seems common in lattice theory. I use it myself. > > > > Dual does seem to be the right term, but I suggest using DualOrd or DualOrdering > instead. The fact that it can be imported qualified is no reason to confuse > people, in many cases the function will not be imported qualified, since > conflicts are very unlikely. To me just "dual" does not immediatly suggest a > reverse ordering. Consider also: > sortBy (comparing `on` Dual . fst) stuff > vs. > sortBy (comparing `on` DualOrd . fst) stuff > In the first version it is not immediatly clear that dual has something to do > with the ordering, and not just taking some kind of dual of something in some > other way. I plead to accelerate the already perceptible shift towards more qualified imports, and to treat the unqualified import as the exception. Ord is a particularly good candidate for that, since it is hogging the whole partial-order namespace for the special case of linear orders. In your example, if there is only one occurrence of Dual in a large module, then > sortBy (comparing `on` Ord.Dual . fst) stuff would be natural. In other places, that module might use ``POrd.Dual''... However, if a module uses only Ord duality, and uses that a lot, then it may become more readable to use an unqualified import (still preferably with an explicit import list) and write > sortBy (comparing `on` Dual . fst) stuff For this special case, I don't want to force qualified import, but suggest it as standard usage, leaving open the more concise second option. The decision to use ``DualOrd'' takes away the concise option, saves only one character over ``Ord.Dual'', and requires more effort to remember --- why is it not ``OrdDual''? > Also, the record selector should be called getDual{Ord}, in accordance with the > monoid wrappers and mtl types. MTL seems to suggest ``runDual'' ;-) ``get*'' sounds far too imparative for my taste. Wolfram From iavor.diatchki at gmail.com Wed Jan 7 15:55:53 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Jan 7 15:47:24 2009 Subject: different flavours of Monad Transformer Library (fwd) In-Reply-To: <694519c50901071228ocf0de1y7d7a7e6d695d3643@mail.gmail.com> References: <4964E4F9.6000508@cs.nott.ac.uk> <694519c50901071228ocf0de1y7d7a7e6d695d3643@mail.gmail.com> Message-ID: <5ab17e790901071255x3519a8c0kb01e4881d271b25c@mail.gmail.com> Hello, While people are discussing different monad libraries---there is also monadLib that I and some of my colleagues use. It is fairly small and it works pretty well, I think. -Iavor On Wed, Jan 7, 2009 at 12:28 PM, Antoine Latter wrote: > On Wed, Jan 7, 2009 at 11:23 AM, Mauro J. Jaskelioff wrote: >> Hi, sorry for the late reply, >> >> I also like Ross' idea of monads being synonyms for transformers at Id. >> It removes lots of repeated code. >> > > There's a cost to that technique. > > Parsec3 introduced parsec as a monad transformer, and the parsec base > monad is implemented as the transformer wrapped around the identity > monad. > > There's a significant speed regression to doing so - I have a branch > of Parsec3 which re-introduces a proper base monad and shares (some) > code via typeclasses. This puts us back at Parsec2 numbers. > > I don't have any hard data on hand at the moment, it's been a while. > > -Antoine > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From schlepptop at henning-thielemann.de Wed Jan 7 16:27:09 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 7 16:12:45 2009 Subject: Proposal #2560 again: add newtype Down/ReverseOrd to Data.Ord In-Reply-To: <20090107203440.9356.qmail@schroeder.cas.mcmaster.ca> References: <49633B29.8030309@gmail.com> <20090106150125.6097.qmail@schroeder.cas.mcmaster.ca> <165B3128-BD17-407E-9321-2F1083314C70@cs.uu.nl> <4964F8E7.1080406@gmail.com> <20090107203440.9356.qmail@schroeder.cas.mcmaster.ca> Message-ID: <49651E2D.1040508@henning-thielemann.de> kahl@cas.mcmaster.ca schrieb: > I plead to accelerate the already perceptible shift towards more qualified > imports, and to treat the unqualified import as the exception. > > Ord is a particularly good candidate for that, > since it is hogging the whole partial-order namespace > for the special case of linear orders. > > In your example, if there is only one occurrence of Dual > in a large module, then > > > sortBy (comparing `on` Ord.Dual . fst) stuff > > would be natural. In other places, that module might use ``POrd.Dual''... +1 > However, if a module uses only Ord duality, > and uses that a lot, then it may become more readable to > use an unqualified import (still preferably with an explicit import list) See: http://www.haskell.org/haskellwiki/Import_modules_properly > and write > > > sortBy (comparing `on` Dual . fst) stuff > > For this special case, I don't want to force qualified import, > but suggest it as standard usage, > leaving open the more concise second option. +1 However I don't care about Dual vs. Opposite vs. Reverse. From waldmann at imn.htwk-leipzig.de Thu Jan 8 02:41:20 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Jan 8 02:32:59 2009 Subject: hsql[-mysql] Message-ID: <4965AE20.6020108@imn.htwk-leipzig.de> can we fix the situation with hsql[-mysql]? it seems there are three versions, all named "-1.7", and none of them working with recent ghc: * http://htoolkit.sourceforge.net/ original project site * http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsql (build failures with ghc-6.8, 6.10) * http://code.haskell.org/HSQL/ current maintainer's site (build failures with 6.10) Since I needed this, I adapted the *.cabal and Setup.hs so they work with ghc-6.8 and 6.10. Since I posted this remark http://article.gmane.org/gmane.comp.lang.haskell.libraries/10299 I got several requests for these. So I'm making them available here provisionally (named *-1.7.1): http://dfa.imn.htwk-leipzig.de/~waldmann/draft/HSQL/ ... but of course this only adds to the confusion. best regards, J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20090108/0dbfdbd6/signature.bin From waldmann at imn.htwk-leipzig.de Thu Jan 8 05:14:12 2009 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Jan 8 05:06:02 2009 Subject: cabal usage Message-ID: <4965D1F4.2020407@imn.htwk-leipzig.de> what is the recommended way (fewest keystrokes) for: * cabal install foo (download from hackage) * build failure => edit sources => repeat install on modified sources Is it really "cabal fetch foo" then "tar xvfz ~/.cabal/some/very/long/pathname.tgz" ? during the original "cabal install", sources seem to be in /tmp/TMPfoo-*/* but they are removed on failure. or - is this a workflow that should not happen (e.g. it might lead to confusing error messages later because "ghc-pkg list" shows the original version number if I forget to bump it while patching the sources) J.W. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20090108/a7bf1954/signature-0001.bin From duncan.coutts at worc.ox.ac.uk Thu Jan 8 07:30:19 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 8 07:19:30 2009 Subject: cabal usage In-Reply-To: <4965D1F4.2020407@imn.htwk-leipzig.de> References: <4965D1F4.2020407@imn.htwk-leipzig.de> Message-ID: <1231417819.14054.8.camel@lantern> On Thu, 2009-01-08 at 11:14 +0100, Johannes Waldmann wrote: > what is the recommended way (fewest keystrokes) for: > > * cabal install foo (download from hackage) > * build failure => edit sources => repeat install on modified sources > > Is it really "cabal fetch foo" > then "tar xvfz ~/.cabal/some/very/long/pathname.tgz" ? The darcs version of cabal-install supports an 'unpack' command which fetches a package and unpacks it into a subdir of the current dir. So the workflow would be: $ cabal unpack foo $ cd foo-x.y/ $ vi blah.hs $ cabal install > or - is this a workflow that should not happen > (e.g. it might lead to confusing error messages later > because "ghc-pkg list" shows the original version number > if I forget to bump it while patching the sources) Cabal can get somewhat confused when the installed version of a package is rather different from the version on hackage. In partthe packageicular if the dependencies are different. The darcs version of cabal-install handles this slightly better. So it's not essential to bump the version number, but with the current cabal-install it's wise to do so if you change the dependencies in the .cabal file. In future that may be less important. Of course making changes without bumping version numbers can cause confusion for people too, not just for the automatic tools. Version numbers are after all a label we use to communicate the identity of some chunk of code. Duncan From tphyahoo at gmail.com Thu Jan 8 11:12:35 2009 From: tphyahoo at gmail.com (Thomas Hartman) Date: Thu Jan 8 11:04:04 2009 Subject: Bug in network library, uncaught exception when dealing with ipv6 sockets Message-ID: <910ddf450901080812y234b41b9i229682943f5efb53@mail.gmail.com> There is an uncaught exception in the network library which is causing my HAppS demo website http://happstutorial.com to crash every couple of days. This has affected other people using HAppS as well, as described on postings to the HAppS users list. The bug, and workarounds, is described at http://code.google.com/p/happs/issues/detail?id=40 This message is to suggest a fix for the issue. The problem seems to me to be localized in the following bit of code, from -- http://hackage.haskell.org/packages/archive/network/2.2.0.1/doc/html/src/Network.html#accept *************************** #if defined(IPV6_SOCKET_SUPPORT) accept sock@(MkSocket _ AF_INET6 _ _ _) = do (sock', addr) <- Socket.accept sock (Just peer, _) <- getNameInfo [] True False addr handle <- socketToHandle sock' ReadWriteMode (PortNumber port) <- socketPort sock' return (handle, peer, port) #endif *************************** The problem is that getNameInfo can give rise to an IO exception, which should be caught at the library level. An exception IS caught at the library level when fetching peer for ipv4 packets, as follows. Since the code can never crash when fetching peer for ipv4 packets, it seems to me it shouldn't be allowed to crash when fetching peer for ipv6 packets either. ip v4 packet code: *************************** accept sock@(MkSocket _ AF_INET _ _ _) = do ~(sock', (SockAddrInet port haddr)) <- Socket.accept sock peer <- catchIO (do (HostEntry peer _ _ _) <- getHostByAddr AF_INET haddr return peer ) (\e -> inet_ntoa haddr) -- if getHostByName fails, we fall back to the IP address handle <- socketToHandle sock' ReadWriteMode return (handle, peer, port) *************************** My suggestion for fixing for ipv6 is as follows, basically having similar error catching as for ipv4. *************************** #if defined(IPV6_SOCKET_SUPPORT) accept sock@(MkSocket _ AF_INET6 _ _ _) = do (sock', addr@((SockAddrInet port haddr) )) <- Socket.accept sock (Just peer, _) <- catchIO ( getNameInfo [] True False addr ) (\e -> do peerAsIp <- inet_ntoa haddr return (Just peerAsIp, undefined)) handle <- socketToHandle sock' ReadWriteMode (PortNumber port) <- socketPort sock' return (handle, peer, port) #endif *************************** Des this seem reasonable? Of course, please advise if I should repost this issue to the ghc bugtracker, or similar. Thanks also to Matt Elder for being very generous with his time in helping me diagnose this. And also thanks to the others on the above-linked HAppS bug thread. Thomas. From tphyahoo at gmail.com Thu Jan 8 11:20:05 2009 From: tphyahoo at gmail.com (Thomas Hartman) Date: Thu Jan 8 11:11:33 2009 Subject: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <910ddf450901080812y234b41b9i229682943f5efb53@mail.gmail.com> References: <910ddf450901080812y234b41b9i229682943f5efb53@mail.gmail.com> Message-ID: <910ddf450901080820t607f735yfce5c1381c39185d@mail.gmail.com> And here's a refinement, without that ugly undefined cluttering things up: #if defined(IPV6_SOCKET_SUPPORT) accept sock@(MkSocket _ AF_INET6 _ _ _) = do (sock', addr@((SockAddrInet port haddr) )) <- Socket.accept sock (Just peer) <- catchIO ( return . fst =<< getNameInfo [] True False addr ) (\e -> return . Just =<< inet_ntoa haddr ) handle <- socketToHandle sock' ReadWriteMode (PortNumber port) <- socketPort sock' return (handle, peer, port) #endif 2009/1/8 Thomas Hartman : > There is an uncaught exception in the network library which is causing > my HAppS demo website > > http://happstutorial.com > > to crash every couple of days. This has affected other people using > HAppS as well, as described on postings to the HAppS users list. > > The bug, and workarounds, is described at > > http://code.google.com/p/happs/issues/detail?id=40 > > This message is to suggest a fix for the issue. > > The problem seems to me to be localized in the following bit of code, > from -- http://hackage.haskell.org/packages/archive/network/2.2.0.1/doc/html/src/Network.html#accept > > *************************** > > #if defined(IPV6_SOCKET_SUPPORT) > accept sock@(MkSocket _ AF_INET6 _ _ _) = do > > (sock', addr) <- Socket.accept sock > > (Just peer, _) <- getNameInfo [] True False addr > > > handle <- socketToHandle sock' ReadWriteMode > (PortNumber port) <- socketPort sock' > > > return (handle, peer, port) > > #endif > *************************** > > The problem is that getNameInfo can give rise to an IO exception, > which should be caught at the library level. An exception IS caught at > the library level when fetching peer for ipv4 packets, as follows. > Since the code can never crash when fetching peer for ipv4 packets, it > seems to me it shouldn't be allowed to crash when fetching peer for > ipv6 packets either. > > ip v4 packet code: > > *************************** > accept sock@(MkSocket _ AF_INET _ _ _) = do > ~(sock', (SockAddrInet port haddr)) <- Socket.accept sock > peer <- catchIO > (do > (HostEntry peer _ _ _) <- getHostByAddr AF_INET haddr > return peer > ) > (\e -> inet_ntoa haddr) > -- if getHostByName fails, we fall back to the IP address > handle <- socketToHandle sock' ReadWriteMode > return (handle, peer, port) > *************************** > > My suggestion for fixing for ipv6 is as follows, basically having > similar error catching as for ipv4. > > *************************** > > #if defined(IPV6_SOCKET_SUPPORT) > accept sock@(MkSocket _ AF_INET6 _ _ _) = do > (sock', addr@((SockAddrInet port haddr) )) <- Socket.accept sock > (Just peer, _) <- catchIO ( getNameInfo [] True False addr ) > (\e -> do peerAsIp <- inet_ntoa haddr > return (Just peerAsIp, undefined)) > > > handle <- socketToHandle sock' ReadWriteMode > (PortNumber port) <- socketPort sock' > return (handle, peer, port) > #endif > > *************************** > > Des this seem reasonable? > > Of course, please advise if I should repost this issue to the ghc > bugtracker, or similar. > > Thanks also to Matt Elder for being very generous with his time in > helping me diagnose this. And also thanks to the others on the > above-linked HAppS bug thread. > > Thomas. > From dons at galois.com Thu Jan 8 12:48:02 2009 From: dons at galois.com (Don Stewart) Date: Thu Jan 8 12:39:18 2009 Subject: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <910ddf450901080812y234b41b9i229682943f5efb53@mail.gmail.com> References: <910ddf450901080812y234b41b9i229682943f5efb53@mail.gmail.com> Message-ID: <20090108174802.GA22269@scytale.galois.com> tphyahoo: > > There is an uncaught exception in the network library which is causing > my HAppS demo website > > http://happstutorial.com If it is the Haskell network library, could you submit a patch there? -- Don From tphyahoo at gmail.com Thu Jan 8 13:11:03 2009 From: tphyahoo at gmail.com (Thomas Hartman) Date: Thu Jan 8 13:02:31 2009 Subject: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <910ddf450901081010y7ebbb9a3n739b7351007d1d26@mail.gmail.com> References: <910ddf450901080812y234b41b9i229682943f5efb53@mail.gmail.com> <20090108174802.GA22269@scytale.galois.com> <910ddf450901081010y7ebbb9a3n739b7351007d1d26@mail.gmail.com> Message-ID: <910ddf450901081011rd5e9512y7d1dc98699b4d0c5@mail.gmail.com> ok. http://hackage.haskell.org/trac/ghc/ticket/2927 2009/1/8 Thomas Hartman : > ok. > > http://hackage.haskell.org/trac/ghc/ticket/2927 > > 2009/1/8 Don Stewart : >> tphyahoo: >>> >>> There is an uncaught exception in the network library which is causing >>> my HAppS demo website >>> >>> http://happstutorial.com >> >> If it is the Haskell network library, could you submit a patch there? >> >> -- Don >> > From haskell at list.mightyreason.com Fri Jan 9 18:24:14 2009 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Fri Jan 9 18:15:40 2009 Subject: Announcing Haskell protocol-buffers 1.4.0 (the smashing recursive edition) Message-ID: <4967DC9E.3070302@list.mightyreason.com> Hello, What is protocol-buffers? Google's "..language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more." http://code.google.com/apis/protocolbuffers/docs/overview.html What is Haskell protocol-buffers? This provides a program 'hprotoc' which compiles a ".proto" file defining messages to Haskell modules, and the protocol-buffers API to access them and convert back and forth to the binary wire protocol, and protocol-buffers-descriptors which are messages which describe ".proto" files and allow for runtime reflection of annotated message definitions. The big addition to this version (which is 1.4.0) over the previous version (which was 1.2.0) is for when modules are in a dependency loop. The most common reason this happens is whenever a message is extended in the same proto file but outside of the message itself (e.g. at the top level). This was salved in previous versions by telling the user to create boilerplate header files (a .hs-boot file) and add a few {-# SOURCE #-} pragmas. This was primitive, and could not cover all the corner cases. Those days are gone. The new version of hprotoc uses the cutting edge version of haskell-src-exts (4.8.0) to generate not only the Haskell modules but also the hs-boot files and {-# SOURCE #-} pragmas! This is truly a glorious way to start the New Year. But wait, there is more! If a more than two messages define extensions of each other in a strongly connected dependency graph then the hs-boot files are not enough. For these strange cases hprotoc will now generate modules ending with 'Key.hs that separately define the extensions. You do not need to lift a finger, you never need to import these modules yourself, this all exists behind the scenes. Also, hprotoc goes way out its way to reduce the number of .hs-boot and 'Key.hs files, and it uses only a minimal set of {-# SOURCE #-} pragmas. It is so painless that if I did not put this into this announcement you might not even know. Now all generated should compile with no changes or additions. Of course, hprotoc still generates nothing for services and methods. Where to get the new shiny packages? hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers-descriptor http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc And you will need haskell-src-exts, version 0.4.8, by Niklas Broberg: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.4.8 (past version do not work and future versions will probably change enough to break compilation of hprotoc) Happy New Year, Chris Kuklewicz From ross at soi.city.ac.uk Sat Jan 10 10:46:43 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Jan 10 10:38:07 2009 Subject: different flavours of Monad Template Library In-Reply-To: References: <20090104235028.GA18161@soi.city.ac.uk> Message-ID: <20090110154643.GA6298@soi.city.ac.uk> I have uploaded these to hackage. The packages are: transformers: monad transformers, operations and liftings. This is all Haskell 98, and be used on its own, or as a base for packages defining monad classes. monads-fd: monad classes using functional dependencies, with instances for the transformers in the transformers package. This is mostly backwards-compatible with mtl. monads-tf: monad classes using type families, with instances for the transformers in the transformers package. This is mostly backwards-compatible with mtl-tf. From duncan.coutts at worc.ox.ac.uk Sat Jan 10 15:45:12 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jan 10 15:36:44 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: References: <4961265C.2090709@gabriel.name> Message-ID: <1231620312.4794.10.camel@localhost> On Sun, 2009-01-04 at 23:25 +0100, Henning Thielemann wrote: > On Sun, 4 Jan 2009, Marcus D. Gabriel wrote: > > > We seem to have not added any splitters such as splitBy or split to > > Data.List despite the discussions. Here is yet another perspective > > with the hope that it will make it. > > I assumed that the discussion was resolved by > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/split We should say that the split package is a way of continuing the discussion. The hope of some around here is that we can find a consensus on a small set of common split functions and add them to the Data.List module. I'm not sure if that goal is achievable but I think it's worth trying. Duncan From lemming at henning-thielemann.de Sat Jan 10 16:18:48 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 10 16:10:14 2009 Subject: different flavours of Monad Template Library In-Reply-To: <20090110154643.GA6298@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> <20090110154643.GA6298@soi.city.ac.uk> Message-ID: On Sat, 10 Jan 2009, Ross Paterson wrote: > I have uploaded these to hackage. The packages are: > > transformers: monad transformers, operations and liftings. > This is all Haskell 98, and be used on its own, or as a base > for packages defining monad classes. > > monads-fd: monad classes using functional dependencies, with instances > for the transformers in the transformers package. This is > mostly backwards-compatible with mtl. > > monads-tf: monad classes using type families, with instances for the > transformers in the transformers package. This is mostly > backwards-compatible with mtl-tf. Great! (will all people associate 'transformers' with 'monad transformers'?) From lemming at henning-thielemann.de Sat Jan 10 16:20:59 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 10 16:12:21 2009 Subject: different flavours of Monad Template Library In-Reply-To: <20090110154643.GA6298@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> <20090110154643.GA6298@soi.city.ac.uk> Message-ID: On Sat, 10 Jan 2009, Ross Paterson wrote: > I have uploaded these to hackage. The packages are: > > transformers: monad transformers, operations and liftings. > This is all Haskell 98, and be used on its own, or as a base > for packages defining monad classes. What are the changes from transformers-0.0.1.0 to transformers-0.1.0.0 ? From ross at soi.city.ac.uk Sat Jan 10 16:30:41 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Jan 10 16:22:19 2009 Subject: different flavours of Monad Template Library In-Reply-To: References: <20090104235028.GA18161@soi.city.ac.uk> <20090110154643.GA6298@soi.city.ac.uk> Message-ID: <20090110213041.GA19286@soi.city.ac.uk> On Sat, Jan 10, 2009 at 10:20:59PM +0100, Henning Thielemann wrote: > What are the changes from transformers-0.0.1.0 to transformers-0.1.0.0 ? Instances for Applicative and Alternative. Two versions of liftCallCC (one matching mtl and the right one). From lemming at henning-thielemann.de Sat Jan 10 20:47:07 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 10 20:38:47 2009 Subject: different flavours of Monad Transformer Library In-Reply-To: <20090110213041.GA19286@soi.city.ac.uk> References: <20090104235028.GA18161@soi.city.ac.uk> <20090110154643.GA6298@soi.city.ac.uk> <20090110213041.GA19286@soi.city.ac.uk> Message-ID: On Sat, 10 Jan 2009, Ross Paterson wrote: > On Sat, Jan 10, 2009 at 10:20:59PM +0100, Henning Thielemann wrote: >> What are the changes from transformers-0.0.1.0 to transformers-0.1.0.0 ? > > Instances for Applicative and Alternative. In order to let this work with old versions of base, you will have to import the special-functors compatibility package. From ashley at semantic.org Sun Jan 11 06:13:28 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Jan 11 06:04:49 2009 Subject: MonadPlus instance for ContT In-Reply-To: <200901061633.40320.g9ks157k@acme.softbase.org> References: <200901061633.40320.g9ks157k@acme.softbase.org> Message-ID: <4969D458.8010506@semantic.org> Wolfgang Jeltsch wrote: > Hello, > > I wonder why there isn?t a MonadPlus instance for ContT. In my opinion, this > one would be natural: > >> instance (MonadPlus monad) => MonadPlus (ContT result monad) where >> >> mzero = ContT $ return mzero >> >> ContT cont1 `mplus` ContT cont2 = ContT $ liftM2 mplus cont1 cont2 > > return and liftM2 are the ones of (->) (o -> monad result). > > What do you think? As long as it satisfies the MonadPlus rules. All of these: mplus mzero a = a mplus a mzero = a mplus (mplus a b) c = mplus a (mplus b c) mzero >>= k = mzero and one of these: mplus a b >>= k = mplus (a >>= k) (b >>= k) mplus (return a) b = return a -- Ashley Yakeley From marcus at gabriel.name Sun Jan 11 13:14:24 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Sun Jan 11 13:05:45 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <0D958869-328D-4176-A325-9D4299825B68@ece.cmu.edu> References: <4961265C.2090709@gabriel.name> <49613F67.3090305@gabriel.name> <0D958869-328D-4176-A325-9D4299825B68@ece.cmu.edu> Message-ID: <496A3700.6020802@gabriel.name> Brandon S. Allbery KF8NH wrote: > > On 2009 Jan 4, at 17:59, Marcus D. Gabriel wrote: >> Henning Thielemann wrote: >>> On Sun, 4 Jan 2009, Marcus D. Gabriel wrote: >>>> We seem to have not added any splitters such as splitBy or split to >>>> Data.List despite the discussions. Here is yet another perspective >>>> with the hope that it will make it. >>> >>> I assumed that the discussion was resolved by >>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/split >> >> I did not have that impression. > > The discussion demonstrated why there is no standard split in > Data.List: nobody can agree on how it should work. Hence the Split > package, which should allow us to find out which ones get used and > which don't, and which are viable candidates for addition to Data.List. > I did not really interpret the Split package this way, but thank you for pointing this out to me. Let me follow up with Duncan's response and see if I can explain myself better. -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:marcus@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75 From marcus at gabriel.name Sun Jan 11 14:14:57 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Sun Jan 11 14:06:18 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <1231620312.4794.10.camel@localhost> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> Message-ID: <496A4531.9050902@gabriel.name> Duncan Coutts wrote: > On Sun, 2009-01-04 at 23:25 +0100, Henning Thielemann wrote: > >> On Sun, 4 Jan 2009, Marcus D. Gabriel wrote: >> >> >>> We seem to have not added any splitters such as splitBy or split to >>> Data.List despite the discussions. Here is yet another perspective >>> with the hope that it will make it. >>> >> I assumed that the discussion was resolved by >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/split >> > > We should say that the split package is a way of continuing the > discussion. The hope of some around here is that we can find a consensus > on a small set of common split functions and add them to the Data.List > module. I'm not sure if that goal is achievable but I think it's worth > trying. > > Duncan > Let me see if I can explain what I was trying to bring to the discussion. Forget the code examples that I gave for now. You should realize that I am someone who was reading the discussion threads and felt that the group had the answer or answers, that there was no fighting going on as someone wrote somewhere, and that the key properties that the splitter functions should posses is contained in the e-mail threads but not grouped together. In other words, it was a nice discussion to read. So, let me formulate this from my point of view of how this comes together as I have read it. 1/ It's worth having some splitter functions in the Data.List module, so this is the goal. Otherwise, one leaves Data.List alone and the discussion should be whether or not one should simply use a Data.List.Split package to handle a set of useful idioms somewhere between Data.List and Text.ParserCombinators.Parsec in complexity. Possibly one would flush out Data.List.Split and even write it with a pedantic theme for new comers to Haskell for example. 2/ Some properties, in a loose sense of the term, are needed to constrain the choices and from the e-mail threads, I would say that this sums up as the following. P1. The number of splitter functions should be few in number, otherwise, make a package. P2. There should be no information loss, that is, keep the delimiters, keep the separators, keep the parts of the original list xs that satisfy a predicate p, do not lose information about the beginning and the end of the list relative to the first and last elements of the list respectively. The user of the function decides what to discard. P3. A split list should be unsplittable so as to recover the original list xs. (I made up the word unsplittable.) (P2 implies P3, but let us state this anyway.) >From the e-mail threads, I would say the above are the absolute minimum properties that the solution should have. If there is no agreement here, this would be interesting and should be discussed. I would go on to write that the e-mail threads and the properties above strongly imply in my mind the follow property: P4. A split list xs' should have the same relative order as the original list xs. (I am sure everyone finds this obvious, and in the e-mail threads I do not remember an exception, so let us state this clearly.) The next properties are not exactly what I read from the e-mail threads and are really more my personal view, but they are not in contradiction with what I read either. P5. The splitter functions should fit within the spirit of the Data.List module and even the original Haskell 98 List module in terms of type signature and complexity of implementation. P6. There should be at least one splitter function that takes a predicate p, a "by" word such as groupBy or nubBy. If there is agreement about P1 to P6, then this is a way to frame the discussion. If not, then I would say that this needs to be determined first, otherwise the goal stated above will be difficult to reach. The function intercalate was probably easy to add because it grasps a nice idiom, but with splitter functions there is the problem of adding more and more words and moving closer and closer to the power and complexity of Parsec for example. This next property is very much my point of view: P7. The splitter functions should take off where break and scan left off. I add this one because when I was first learning Haskell, I was using the List module quite a bit. I needed a splitBy word, and I thought that break and scan were for what I was looking, but they were not. So I wrote > splitBy :: (a -> Bool) -> [a] -> [([a], [a])] > splitBy p xs = > let (hd1, tl1) = break p xs > (hd2, tl2) = span p tl1 > in (hd1, hd2):(if null tl2 then [] else splitBy p tl2) which I eventually came to not like. To sum up, if we can agree that a set of splitter properties should fit within the context of Properties P1 to P7, then maybe forward movement can be made. If we cannot agree on these properties or another set, then splitter function idioms are too idiomatic, and a larger set of words are needed, so the investment should be in Data.List.Split. Cheers, - Marcus -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:marcus@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75 From dons at galois.com Sun Jan 11 17:30:53 2009 From: dons at galois.com (Don Stewart) Date: Sun Jan 11 17:22:01 2009 Subject: Arch Haskell News: Jan 11 2009 Message-ID: <20090111223053.GA1296@scytale.galois.com> Arch Haskell News: Jan 11 2009 Hey all, welcome to the first Arch Haskell News of 2009. (News about Haskell on the Arch Linux platform). Arch now has 827 Haskell packages in AUR. That?s an increase of 93 new packages in the last 48 days, or 1.9 new Haskell apps and libraries a day over the holiday season. Well done everyone!. Noteworthy * lhc-0.6.20081127: ?LHC Haskell Compiler? * cabal2arch-0.4.2: ?Create Arch Linux packages from Cabal packages? * timberc-1.0.2: ?The Timber Compiler.? * haskell-x11-1.4.5: ?A binding to the X11 graphics library? * haskell-curl-1.3.2.2: ?Haskell binding to libcurl? * alex-2.3.1: ?Alex is a tool for generating lexical analysers in Haskel * haskell-bytestring-trie-0.1: ?Efficient map from strings to values.? * haskell-llvm-0.5.0.1: ?Bindings to the LLVM compiler toolkit? * tetris-0.27178: ?A 2-D clone of Tetris? * haskell-network-bytestring-0.1.1.4: ?Fast and memory efficient low-level networking? * haskell-hdbc-1.1.6: ?Haskell Database Connectivity? http://archhaskell.wordpress.com/2009/01/11/arch-haskell-news-jan-11-2009/ Other news: * llvm support, http://archhaskell.wordpress.com/2009/01/11/llvm-haskell-bindings/ * new hdbc release, http://archhaskell.wordpress.com/2009/01/11/hdbc-haskell-database-suite-updated/ * salvia, new web framework, supported http://archhaskell.wordpress.com/2009/01/11/new-haskell-web-framework-salvia-and-orchid/ Bring on 2009 and the era of ubiquitous Haskell! -- Don From byorgey at seas.upenn.edu Sun Jan 11 18:56:12 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sun Jan 11 18:47:30 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <496A4531.9050902@gabriel.name> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> Message-ID: <20090111235612.GA9642@seas.upenn.edu> > P2. There should be no information loss, that is, keep the delimiters, > keep the separators, keep the parts of the original list xs that satisfy > a predicate p, do not lose information about the beginning and the end > of the list relative to the first and last elements of the list > respectively. The user of the function decides what to discard. > > P3. A split list should be unsplittable so as to recover the original > list xs. (I made up the word unsplittable.) (P2 implies P3, but let us > state this anyway.) I'm not sure I agree with this. The problem is that much (most?) of the time, people looking for a split function want to discard delimiters; for example, if you have a string like "foo;bar;baz" and you want to split it into ["foo","bar","baz"]. In this case it's really annoying to have to throw away the delimiters yourself, especially if you just get back a list like ["foo",";","bar",";","baz"] and have to decide which things are delimiters and which aren't, with no help from the type system. But, as you noted, throwing away information like this is bad from an elegance/formal properties point of view. This is exactly why I designed the Data.List.Split library as I did: the core internal splitting function is information-preserving, and by using various combinators the user can choose to throw away whatever information they are not interested in. -Brent From g9ks157k at acme.softbase.org Mon Jan 12 10:17:11 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Jan 12 10:08:47 2009 Subject: different flavours of Monad Template Library In-Reply-To: References: Message-ID: <200901121617.11639.g9ks157k@acme.softbase.org> Hello, it?s already problematic, that State, StateT etc. are under Control.Monad. While they are monads, they are also applicative functors, for example. And some ?monad transformers? are also applicative functor transformers and probably all of them are functor transformers. There are situations where you want to use these types only as applicative functors, for example when composing context-free parsers. Since they are all functors at least, it might be sensible to put them under Control.Functor. Or it might be a good idea to put them under Data in the module hierarchy. That way, a compatibility package could provide the old interface under Control.Monad and new stuff would be situated under Control.Functor or Data. During this restructuring, we could also rename State to StateTrans since values of State are not states but state transformers. There are similar problems with Cont since values of Cont type are not continuations but functions from continuations to results. It?s problematic when you deal with states and state transformers or continuations and Cont values. How do you name your local variables? I?d like to say ?state? for a state but it would also be sensible to say ?state? for a value of type State, i.e., a state transformer. Comments? Ideas? Best wishes, Wolfgang From g9ks157k at acme.softbase.org Mon Jan 12 10:20:38 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Jan 12 10:12:14 2009 Subject: different flavours of Monad Template Library In-Reply-To: References: <20090110154643.GA6298@soi.city.ac.uk> Message-ID: <200901121620.38641.g9ks157k@acme.softbase.org> Am Samstag, 10. Januar 2009 22:18 schrieb Henning Thielemann: > (will all people associate 'transformers' with 'monad transformers'?) They are also functor transformers. So a more generic name sounds reasonable. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Mon Jan 12 10:26:16 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Jan 12 10:17:38 2009 Subject: different flavours of Monad Template Library In-Reply-To: <20090110213041.GA19286@soi.city.ac.uk> References: <20090110213041.GA19286@soi.city.ac.uk> Message-ID: <200901121626.16324.g9ks157k@acme.softbase.org> Am Samstag, 10. Januar 2009 22:30 schrieb Ross Paterson: > On Sat, Jan 10, 2009 at 10:20:59PM +0100, Henning Thielemann wrote: > > What are the changes from transformers-0.0.1.0 to transformers-0.1.0.0 ? > > Instances for Applicative and Alternative. Great! And we should try to make Applicative a superclass of Monad and drop MonadPlus in favor of Alternative + Monad. It would be probably even better to have somethink like Alternative/MonadPlus for functors (since functors are the most general concept at this point) and drop Alternative and MonadPlus (or use the name ?Alternative? for this new class). It?s terrible to explain all this legacy (Applicative not being superclass of Monad, two different classes for monoid functors) to students and to mention Applicative in a class context which already mentions Monad. However, we?ll probably need something like John Meachem?s class alias proposal to make such a transition as smooth as possible. Anyone who wants to hack GHC in this regard? Best wishes, Wolfgang From g9ks157k at acme.softbase.org Mon Jan 12 10:30:04 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Jan 12 10:21:49 2009 Subject: different flavours of Monad Template Library In-Reply-To: <20090104195353.0afy7ngsg4g04kgw-nwo@webmail.spamcop.net> References: <20090104235028.GA18161@soi.city.ac.uk> <20090104195353.0afy7ngsg4g04kgw-nwo@webmail.spamcop.net> Message-ID: <200901121630.04816.g9ks157k@acme.softbase.org> Am Montag, 5. Januar 2009 01:53 schrieb ajb@spamcop.net: > I'm curious if anyone has tried restructuring MTL with coproducts > rather than transformers. Coproducts seem more "natural", if slightly > harder to write. Don?t know about coproducts but it sounds interesting. ;-) Do coproducts provide a way to compose different kinds of effects (state transformations, environment dependencies, etc.)? I always found it a bit annoying that types like StateT don?t cover just one concept but two: a specific effect (state transformations in this case) and composition of effects. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Mon Jan 12 10:43:32 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Jan 12 10:34:52 2009 Subject: MonadPlus instance for ContT In-Reply-To: <4969D458.8010506@semantic.org> References: <200901061633.40320.g9ks157k@acme.softbase.org> <4969D458.8010506@semantic.org> Message-ID: <200901121643.32581.g9ks157k@acme.softbase.org> Am Sonntag, 11. Januar 2009 12:13 schrieben Sie: > Wolfgang Jeltsch wrote: > > Hello, > > > > I wonder why there isn?t a MonadPlus instance for ContT. In my opinion, > > this > > > > one would be natural: > >> instance (MonadPlus monad) => MonadPlus (ContT result monad) where > >> > >> mzero = ContT $ return mzero > >> > >> ContT cont1 `mplus` ContT cont2 = ContT $ liftM2 mplus cont1 cont2 > > > > return and liftM2 are the ones of (->) (o -> monad result). > > > > What do you think? > > As long as it satisfies the MonadPlus rules. > > All of these: > > mplus mzero a = a > > mplus a mzero = a > > mplus (mplus a b) c = mplus a (mplus b c) > > mzero >>= k = mzero Should all be satisfied. > and one of these: > > mplus a b >>= k = mplus (a >>= k) (b >>= k) Should be satisfied. > mplus (return a) b = return a Obviously not satisfied in general. What has to be done to get such an instance into the libs? Best wishes, Wolfgang From g9ks157k at acme.softbase.org Mon Jan 12 10:45:56 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Jan 12 10:37:15 2009 Subject: different flavours of Monad Transformer Library (fwd) In-Reply-To: <694519c50901071228ocf0de1y7d7a7e6d695d3643@mail.gmail.com> References: <4964E4F9.6000508@cs.nott.ac.uk> <694519c50901071228ocf0de1y7d7a7e6d695d3643@mail.gmail.com> Message-ID: <200901121645.56520.g9ks157k@acme.softbase.org> Am Mittwoch, 7. Januar 2009 21:28 schrieb Antoine Latter: > On Wed, Jan 7, 2009 at 11:23 AM, Mauro J. Jaskelioff wrote: > > Hi, sorry for the late reply, > > > > I also like Ross' idea of monads being synonyms for transformers at Id. > > It removes lots of repeated code. > > There's a cost to that technique. > > Parsec3 introduced parsec as a monad transformer, and the parsec base > monad is implemented as the transformer wrapped around the identity > monad. > > There's a significant speed regression to doing so - I have a branch > of Parsec3 which re-introduces a proper base monad and shares (some) > code via typeclasses. This puts us back at Parsec2 numbers. > > I don't have any hard data on hand at the moment, it's been a while. > > -Antoine Isn?t it possible to make GHC more clever to remove this speed penalty? Best wishes, Wolfgang From lemming at henning-thielemann.de Mon Jan 12 10:47:31 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 12 10:38:46 2009 Subject: different flavours of Monad Template Library In-Reply-To: <200901121617.11639.g9ks157k@acme.softbase.org> References: <200901121617.11639.g9ks157k@acme.softbase.org> Message-ID: On Mon, 12 Jan 2009, Wolfgang Jeltsch wrote: > Hello, > > it?s already problematic, that State, StateT etc. are under Control.Monad. > While they are monads, they are also applicative functors, for example. And > some ?monad transformers? are also applicative functor transformers and > probably all of them are functor transformers. There are situations where > you want to use these types only as applicative functors, for example when > composing context-free parsers. I already posted something similar, with no response: http://www.haskell.org/pipermail/libraries/2007-October/008274.html Maybe this time is better? > During this restructuring, we could also rename State to StateTrans since > values of State are not states but state transformers. Right, I also like to use 'state' as identifier for a state, not for a stateful action. And I was confused, by Reader not being really a counterpart to Writer. If I want to read, what I wrote with Writer, I usually have to use a State monad, not Reader. 'Context' or 'Environment' seems to be a better name for 'Reader'. From ross at soi.city.ac.uk Mon Jan 12 10:57:41 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jan 12 10:49:01 2009 Subject: different flavours of Monad Template Library In-Reply-To: <200901121626.16324.g9ks157k@acme.softbase.org> References: <20090110213041.GA19286@soi.city.ac.uk> <200901121626.16324.g9ks157k@acme.softbase.org> Message-ID: <20090112155741.GA4444@soi.city.ac.uk> On Mon, Jan 12, 2009 at 04:26:16PM +0100, Wolfgang Jeltsch wrote: > And we should try to make Applicative a superclass of Monad and drop > MonadPlus in favor of Alternative + Monad. It would be probably > even better to have somethink like Alternative/MonadPlus for functors > (since functors are the most general concept at this point) and drop > Alternative and MonadPlus (or use the name 'Alternative' for this > new class). It's terrible to explain all this legacy (Applicative not > being superclass of Monad, two different classes for monoid functors) > to students and to mention Applicative in a class context which already > mentions Monad. The legacy hierarchy is a problem with transformers. Some of them are Applicative transformers: instance (Monoid w, Applicative m) => Applicative (WriterT w m) instance (Applicative m) => Applicative (ReaderT r m) so they're also defined as Functor transformers: instance (Functor m) => Functor (WriterT w m) instance (Functor m) => Functor (ReaderT r m) So far so good. But some others require the argument to be a Monad: instance (Monad m) => Applicative (StateT s m) instance (Monad m) => Applicative (ErrorT e m) but to be Applicative they must also be Functor, so we keep the old instances: instance (Monad m) => Functor (StateT s m) instance (Monad m) => Functor (ErrorT e m) We could change these to assume Functor, but then we'd have to add a Functor constraint to the Applicative instances. Hmm, on second thoughts that's probably the right way to go. From duncan.coutts at worc.ox.ac.uk Mon Jan 12 15:45:38 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 12 15:37:01 2009 Subject: haskell-platform mailing list Message-ID: <1231793138.28590.103.camel@localhost> Hi all, If you are interested in helping out with the haskell platform project then we invite you to subscribe to the haskell-platform mailing list. http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform This mailing list is for discussing practical stuff. We expect to discuss policy questions on the libraries mailing list. Issues like which packages to pick, what package QA standards to use etc would be discussed on the libraries mailing list. Those issues are for the community as a whole. Building and coordinating the actual releases will be done via the haskell-platform mailing list. Duncan From greg at gregorycollins.net Mon Jan 12 16:35:30 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Mon Jan 12 16:26:45 2009 Subject: Policy question re: Haskell Platform installer on OSX Message-ID: Hi all, I'm currently writing a program to take Cabal libraries and turn them into OSX .pkg files, for the Haskell platform's Mac installer. Where should the libraries be installed? The current GHC installer plops them down into /Library/Frameworks/GHC.framework/Versions/xxx/usr, and my thinking is that I'll keep it that way so that we can piggyback on GHC's uninstall script. Otherwise the platform project will need an uninstaller of its own. Thanks, G. -- Gregory Collins From dons at galois.com Mon Jan 12 16:38:33 2009 From: dons at galois.com (Don Stewart) Date: Mon Jan 12 16:30:07 2009 Subject: Policy question re: Haskell Platform installer on OSX In-Reply-To: References: Message-ID: <20090112213833.GN3582@scytale.galois.com> greg: > Hi all, > > I'm currently writing a program to take Cabal libraries and turn them > into OSX .pkg files, for the Haskell platform's Mac installer. > > Where should the libraries be installed? The current GHC installer plops > them down into /Library/Frameworks/GHC.framework/Versions/xxx/usr, and > my thinking is that I'll keep it that way so that we can piggyback on > GHC's uninstall script. Otherwise the platform project will need an > uninstaller of its own. Yeah, I'd make sure you can use ghc-pkg with the libs. That's what all the other unix distros do. From greg at gregorycollins.net Mon Jan 12 16:47:59 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Mon Jan 12 16:39:15 2009 Subject: Policy question re: Haskell Platform installer on OSX In-Reply-To: <20090112213833.GN3582@scytale.galois.com> (Don Stewart's message of "Mon, 12 Jan 2009 13:38:33 -0800") References: <20090112213833.GN3582@scytale.galois.com> Message-ID: Don Stewart writes: > greg: >> Hi all, >> >> I'm currently writing a program to take Cabal libraries and turn them >> into OSX .pkg files, for the Haskell platform's Mac installer. >> >> Where should the libraries be installed? The current GHC installer plops >> them down into /Library/Frameworks/GHC.framework/Versions/xxx/usr, and >> my thinking is that I'll keep it that way so that we can piggyback on >> GHC's uninstall script. Otherwise the platform project will need an >> uninstaller of its own. > > Yeah, I'd make sure you can use ghc-pkg with the libs. That's what all > the other unix distros do. Yep - the generated installers will run "ghc-pkg update" as a post-installation step, no matter where the files end up going on disk. The main issue on OSX is that the system installer doesn't do UNinstallation, otherwise I'd just add an uninstall hook that ran "ghc-pkg unregister". As it stands my options are "stick the Haskell platform libraries somewhere in /Library/Frameworks/GHC.framework and make use of the existing uninstaller" and "ship the Haskell platform with its own custom uninstall script". G -- Gregory Collins From haskell at list.mightyreason.com Mon Jan 12 17:06:31 2009 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Jan 12 16:57:49 2009 Subject: Policy change for regex libraries Message-ID: <496BBEE7.1000508@list.mightyreason.com> Before I go and add or change anything in the Haskell regex-posix library, I wanted to get some feedback. regex-posix provides Text.Regex.Posix, and is built on the regex-base package. regex-posix is also used as the backend for Text.Regex (the regex-compat package does this). I do not intend to change the behavior of the old Text.Regex API. The main issue is the behavior when returning a list of all matches of a Regex against a target text. I no longer think the current behavior is the right choice when it comes to zero-length matches. The current behavior is to return non-overlapping matches with the caveat that after the first zero-length match the search is ended. Note that the zero-length match may be occur at the end position of a previous non-zero-length match. Notably, no one has complained about this policy. But I no longer like it. So here are a few of my ideas of what to change it to: 0) No change, not worth the effort. 1) return the zero-length match, skip forward 1 character, and continue searching. If the consumer wishes the old policy they can truncate the list. This could also be filtered to resemble option 2 below. 2) Mimic "sed". It seems "sed" has a policy where a zero-length match is forbidden to occur at the end position of a non-zero-length match. "sed" does not stop with the first zero-length match. 3) implement additional execution options, so the user can choose a policy. The default policy choice left with the current behavior. 4) implement additional execution options, so the user can choose a policy. The default policy choice set to he behavior in (1). 5) Return valid matches starting from all positions, including overlapping matches. This I really do not like and one can run the search starting one character after the start of the last match to get this information. Matching "0123" and replacing all matches with themselves wrapped in angle brackets. The policies of 0, 1, and 2 above lead to (computed partly by hand): regex of "[0123]?" 0): "<0><1><2><3><>" 1): "<0><1><2><3><>" 2): "<0><1><2><3>" regex of "[012]?" 0): "<0><1><2>3<>" 1): "<0><1><2>3<>" 2): "<0><1><2>3<>" regex of "[013]?" 0): "<0><1><>23" 1): "<0><1><>2<3><>" 2): "<0><1>2<3>" regex of "[023]?" 0): "<0><>123" 1): "<0><>1<2><3><>" 2): "<0>1<2><3>" regex of "[123]?" 0): "<>0123" 1): "<>0<1><2><3><>" 2): "<>0<1><2><3>" regex of "[03]?" 0): "<0><>123" 1): "<0><>1<>2<3><>" 2): "<0>1<>2<3>" regex of "[03]?" 0): "<0><>123" 1): "<0><>1<>2<3><>" 2): "<0>1<>2<3>" regex of "[12]?" 0): "<>0123" 1): "<>0<1><2><>3<>" 2): "<>0<1><2>3<>" I am leaning to simply changing it from policy 0 to policy 1. Are there any objections? Perhaps I should set a deadline? Now where is that library policy... -- Chris From dons at galois.com Mon Jan 12 17:07:59 2009 From: dons at galois.com (Don Stewart) Date: Mon Jan 12 16:58:58 2009 Subject: Policy change for regex libraries In-Reply-To: <496BBEE7.1000508@list.mightyreason.com> References: <496BBEE7.1000508@list.mightyreason.com> Message-ID: <20090112220759.GQ3582@scytale.galois.com> Ensuring compatibilty with the usage described in "Real World Haskell" would make me really really really happy :) haskell: > Before I go and add or change anything in the Haskell regex-posix library, > I wanted to get some feedback. regex-posix provides Text.Regex.Posix, and > is built on the regex-base package. > > regex-posix is also used as the backend for Text.Regex (the regex-compat > package does this). I do not intend to change the behavior of the old > Text.Regex API. > > The main issue is the behavior when returning a list of all matches of a > Regex against a target text. I no longer think the current behavior is the > right choice when it comes to zero-length matches. > > The current behavior is to return non-overlapping matches with the caveat > that after the first zero-length match the search is ended. Note that the > zero-length match may be occur at the end position of a previous > non-zero-length match. > > Notably, no one has complained about this policy. But I no longer like it. > So here are a few of my ideas of what to change it to: > > 0) No change, not worth the effort. > > 1) return the zero-length match, skip forward 1 character, and continue > searching. If the consumer wishes the old policy they can truncate the > list. This could also be filtered to resemble option 2 below. > > 2) Mimic "sed". It seems "sed" has a policy where a zero-length match is > forbidden to occur at the end position of a non-zero-length match. "sed" > does not stop with the first zero-length match. > > 3) implement additional execution options, so the user can choose a policy. > The default policy choice left with the current behavior. > > 4) implement additional execution options, so the user can choose a policy. > The default policy choice set to he behavior in (1). > > 5) Return valid matches starting from all positions, including overlapping > matches. This I really do not like and one can run the search starting one > character after the start of the last match to get this information. > > Matching "0123" and replacing all matches with themselves wrapped in angle > brackets. The policies of 0, 1, and 2 above lead to (computed partly by > hand): > > regex of "[0123]?" > 0): "<0><1><2><3><>" > 1): "<0><1><2><3><>" > 2): "<0><1><2><3>" > > regex of "[012]?" > 0): "<0><1><2>3<>" > 1): "<0><1><2>3<>" > 2): "<0><1><2>3<>" > > regex of "[013]?" > 0): "<0><1><>23" > 1): "<0><1><>2<3><>" > 2): "<0><1>2<3>" > > regex of "[023]?" > 0): "<0><>123" > 1): "<0><>1<2><3><>" > 2): "<0>1<2><3>" > > regex of "[123]?" > 0): "<>0123" > 1): "<>0<1><2><3><>" > 2): "<>0<1><2><3>" > > regex of "[03]?" > 0): "<0><>123" > 1): "<0><>1<>2<3><>" > 2): "<0>1<>2<3>" > > regex of "[03]?" > 0): "<0><>123" > 1): "<0><>1<>2<3><>" > 2): "<0>1<>2<3>" > > regex of "[12]?" > 0): "<>0123" > 1): "<>0<1><2><>3<>" > 2): "<>0<1><2>3<>" > > I am leaning to simply changing it from policy 0 to policy 1. > > Are there any objections? > > Perhaps I should set a deadline? Now where is that library policy... > > -- > Chris > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From duncan.coutts at worc.ox.ac.uk Mon Jan 12 17:40:11 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 12 17:31:27 2009 Subject: Policy question re: Haskell Platform installer on OSX In-Reply-To: References: Message-ID: <1231800011.28590.124.camel@localhost> On Mon, 2009-01-12 at 16:35 -0500, Gregory Collins wrote: > Hi all, > > I'm currently writing a program to take Cabal libraries and turn them > into OSX .pkg files, for the Haskell platform's Mac installer. > > Where should the libraries be installed? The current GHC installer plops > them down into /Library/Frameworks/GHC.framework/Versions/xxx/usr, and > my thinking is that I'll keep it that way so that we can piggyback on > GHC's uninstall script. Otherwise the platform project will need an > uninstaller of its own. My guess is that it should be a separate framework, but if we could have some hacker that uses OSX confirm that for us, that'd be great. Of course another option in future is to simply have a single haskell platform framework that includes ghc. Again, input from the OSX users and hackers would be most welcome. Duncan From mail at justinbogner.com Mon Jan 12 17:46:16 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Mon Jan 12 17:37:40 2009 Subject: Policy change for regex libraries References: <496BBEE7.1000508@list.mightyreason.com> Message-ID: <873afoqh1j.fsf@justinbogner.com> Chris Kuklewicz writes: > Matching "0123" and replacing all matches with themselves wrapped in > angle brackets. The policies of 0, 1, and 2 above lead to (computed > partly by hand): > > regex of "[0123]?" > 0): "<0><1><2><3><>" > 1): "<0><1><2><3><>" > 2): "<0><1><2><3>" > > regex of "[012]?" > 0): "<0><1><2>3<>" > 1): "<0><1><2>3<>" > 2): "<0><1><2>3<>" > > regex of "[013]?" > 0): "<0><1><>23" > 1): "<0><1><>2<3><>" > 2): "<0><1>2<3>" > > regex of "[023]?" > 0): "<0><>123" > 1): "<0><>1<2><3><>" > 2): "<0>1<2><3>" > > regex of "[123]?" > 0): "<>0123" > 1): "<>0<1><2><3><>" > 2): "<>0<1><2><3>" > > regex of "[03]?" > 0): "<0><>123" > 1): "<0><>1<>2<3><>" > 2): "<0>1<>2<3>" > > regex of "[03]?" > 0): "<0><>123" > 1): "<0><>1<>2<3><>" > 2): "<0>1<>2<3>" > > regex of "[12]?" > 0): "<>0123" > 1): "<>0<1><2><>3<>" > 2): "<>0<1><2>3<>" > Policy 2 seems the most intuitive to me, I can't imagine a situation where you would want the empty match at the end of a non-empty match. On the other hand, I don't think I've ever used a regular expression that matched an empty string, so it's not particularly important to me. From mail at justinbogner.com Mon Jan 12 17:47:09 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Mon Jan 12 17:41:49 2009 Subject: Policy change for regex libraries References: <496BBEE7.1000508@list.mightyreason.com> <20090112220759.GQ3582@scytale.galois.com> Message-ID: <87y6xgp2fm.fsf@justinbogner.com> Don Stewart writes: > Ensuring compatibilty with the usage described in "Real World Haskell" > would make me really really really happy :) > I don't think RWH mentions the behaviour on empty matches, so it should be fine :) From haskell at list.mightyreason.com Mon Jan 12 18:00:17 2009 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Jan 12 17:51:34 2009 Subject: Policy change for regex libraries In-Reply-To: <20090112220759.GQ3582@scytale.galois.com> References: <496BBEE7.1000508@list.mightyreason.com> <20090112220759.GQ3582@scytale.galois.com> Message-ID: <496BCB81.9060208@list.mightyreason.com> Don Stewart wrote: > Ensuring compatibilty with the usage described in "Real World Haskell" > would make me really really really happy :) Now I have an even better reason to buy RWH, to keep me from making incompatible changes to the default settings. -- Chris From dons at galois.com Mon Jan 12 18:12:41 2009 From: dons at galois.com (Don Stewart) Date: Mon Jan 12 18:03:43 2009 Subject: Missing -lrt for shm* functions in the unix package Message-ID: <20090112231241.GT3582@scytale.galois.com> The module System.Posix.SharedMem was silently disabling the shm_* functions due to failing configuration tests on linux (needs the -lrt lib). This patch adds -lrt to the configure test/ buildinfo. -- Don Mon Jan 12 15:07:58 PST 2009 Don Stewart * Add check for -lrt to get the shm* functions. Subst. in buildinfo New patches: [Add check for -lrt to get the shm* functions. Subst. in buildinfo Don Stewart **20090112230758] hunk ./configure.ac 30 AC_CHECK_FUNCS([nanosleep]) AC_CHECK_FUNCS([ptsname]) AC_CHECK_FUNCS([setitimer]) + +# Avoid adding rt if absent or unneeded +AC_CHECK_LIB(rt, shm_open, [EXTRA_LIBS="$EXTRA_LIBS rt" CFLAGS="$CFLAGS -lrt"]) + +# needs -lrt on linux AC_CHECK_FUNCS([shm_open shm_unlink]) FP_CHECK_CONSTS([SIGABRT SIGALRM SIGBUS SIGCHLD SIGCONT SIGFPE SIGHUP SIGILL SIGINT SIGKILL SIGPIPE SIGQUIT SIGSEGV SIGSTOP SIGTERM SIGTSTP SIGTTIN SIGTTOU SIGUSR1 SIGUSR2 SIGPOLL SIGPROF SIGSYS SIGTRAP SIGURG SIGVTALRM SIGXCPU SIGXFSZ SIG_BLOCK SIG_SETMASK SIG_UNBLOCK], [ Context: [Avoid using IOError internals Ian Lynagh **20090104173221] [fix pthread linkage problem for openbsd Matthias Kilian **20081129000638 This should make my openbsd build slave happy when SplitObjs=NO. May be useful for other BSDs and even Linux, regardless wether you need -pthread or -lpthread. Time will tell... ] [catch up with exception changes Simon Marlow **20080927135428] [Bump version number to 2.3.1.0 Ian Lynagh **20080920160248] [TAG 6.10 branch has been forked Ian Lynagh **20080919123439] [follow library changes Ian Lynagh **20080903223616] [add category field Ross Paterson **20080824003014] [We now depend on concurrent (split off from base) Ian Lynagh **20080824135158] [Fix the build when CONST_SIGPOLL == -1 Ian Lynagh **20080823160346 We were defining, but not using, sigPOLL ] [Fix warnings in the unix package Ian Lynagh **20080821120138] [move some stuff here from System.Directory, now the dependencies are reversed Simon Marlow **20080821144754] [Follow extensible exceptions changes Ian Lynagh **20080623193152] [Allow C's unsetenv to return either void or int Ian Lynagh **20080703190603 Fixes, and patch from donn in, trac #2352. ] [Avoid using deprecated flags Ian Lynagh **20080616145425] [move __hscore_{mkstemp,getrlimit,setrlimit} here from base Ross Paterson **20080615224248] [TAG 2008-05-28 Ian Lynagh **20080528004441] Patch bundle hash: dd0767ff90044fe756b71c7e1bf58467ba9d7203 -------------- next part -------------- Mon Jan 12 15:07:58 PST 2009 Don Stewart * Add check for -lrt to get the shm* functions. Subst. in buildinfo New patches: [Add check for -lrt to get the shm* functions. Subst. in buildinfo Don Stewart **20090112230758] hunk ./configure.ac 30 AC_CHECK_FUNCS([nanosleep]) AC_CHECK_FUNCS([ptsname]) AC_CHECK_FUNCS([setitimer]) + +# Avoid adding rt if absent or unneeded +AC_CHECK_LIB(rt, shm_open, [EXTRA_LIBS="$EXTRA_LIBS rt" CFLAGS="$CFLAGS -lrt"]) + +# needs -lrt on linux AC_CHECK_FUNCS([shm_open shm_unlink]) FP_CHECK_CONSTS([SIGABRT SIGALRM SIGBUS SIGCHLD SIGCONT SIGFPE SIGHUP SIGILL SIGINT SIGKILL SIGPIPE SIGQUIT SIGSEGV SIGSTOP SIGTERM SIGTSTP SIGTTIN SIGTTOU SIGUSR1 SIGUSR2 SIGPOLL SIGPROF SIGSYS SIGTRAP SIGURG SIGVTALRM SIGXCPU SIGXFSZ SIG_BLOCK SIG_SETMASK SIG_UNBLOCK], [ Context: [Avoid using IOError internals Ian Lynagh **20090104173221] [fix pthread linkage problem for openbsd Matthias Kilian **20081129000638 This should make my openbsd build slave happy when SplitObjs=NO. May be useful for other BSDs and even Linux, regardless wether you need -pthread or -lpthread. Time will tell... ] [catch up with exception changes Simon Marlow **20080927135428] [Bump version number to 2.3.1.0 Ian Lynagh **20080920160248] [TAG 6.10 branch has been forked Ian Lynagh **20080919123439] [follow library changes Ian Lynagh **20080903223616] [add category field Ross Paterson **20080824003014] [We now depend on concurrent (split off from base) Ian Lynagh **20080824135158] [Fix the build when CONST_SIGPOLL == -1 Ian Lynagh **20080823160346 We were defining, but not using, sigPOLL ] [Fix warnings in the unix package Ian Lynagh **20080821120138] [move some stuff here from System.Directory, now the dependencies are reversed Simon Marlow **20080821144754] [Follow extensible exceptions changes Ian Lynagh **20080623193152] [Allow C's unsetenv to return either void or int Ian Lynagh **20080703190603 Fixes, and patch from donn in, trac #2352. ] [Avoid using deprecated flags Ian Lynagh **20080616145425] [move __hscore_{mkstemp,getrlimit,setrlimit} here from base Ross Paterson **20080615224248] [TAG 2008-05-28 Ian Lynagh **20080528004441] Patch bundle hash: dd0767ff90044fe756b71c7e1bf58467ba9d7203 From haskell at list.mightyreason.com Mon Jan 12 18:16:15 2009 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Mon Jan 12 18:07:33 2009 Subject: Policy change for regex libraries In-Reply-To: <873afoqh1j.fsf@justinbogner.com> References: <496BBEE7.1000508@list.mightyreason.com> <873afoqh1j.fsf@justinbogner.com> Message-ID: <496BCF3F.4080402@list.mightyreason.com> mail@justinbogner.com wrote: > Policy 2 seems the most intuitive to me, I can't imagine a situation > where you would want the empty match at the end of a non-empty match. On > the other hand, I don't think I've ever used a regular expression that > matched an empty string, so it's not particularly important to me. The authors of sed are in agreement with your intuition. But I think policy 2 as a recursive definition it is unusual. And I see policy 2 as very hard to summarize. The single-match is always easy to summarize: the leftmost longest match. Policy 1 for multiple matches can be summarized as: > All leftmost longest non-overlapping matches, where overlapping means sharing > the same matching characters. Policy 2 for multiple matches can be summarized as: > All leftmost longest non-overlapping matches, where overlapping means sharing > the same matching characters, excluding zero-length matches that coincide with > the end of a non-zero-length match. Policy 0 has been: > All leftmost longest non-overlapping matches, where overlapping means sharing > the same matching characters, stopping with the first zero-length match. Policy 5 would be even simpler in this language: > The longest match at each position where a match occurs. Policy 5 can be filtered to get policy 1. Policy 1 can be filtered to get policy 0 or to get policy 2. The best practices for a regexp search with multiple matches is to not use a regexp that can match zero-length bits of text (though it may be handy for finding newlines there are simpler ways). So let me also put for "Policy 6" > All leftmost longest non-overlapping matches, where overlapping means sharing > the same matching characters, excluding all zero-length matches. Note that the only zero-length POSIX extended regular expression matches are () which always matches or ^ or $ or ^$ (which is the same as $^). But the policy I choose here will likely be applied to other regular expression backends that can do fancier testing. Thanks for the comments! Chris From mail at justinbogner.com Mon Jan 12 18:36:03 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Mon Jan 12 18:27:27 2009 Subject: Policy change for regex libraries References: <496BBEE7.1000508@list.mightyreason.com> <873afoqh1j.fsf@justinbogner.com> <496BCF3F.4080402@list.mightyreason.com> Message-ID: <87tz84p064.fsf@justinbogner.com> Chris Kuklewicz writes: > The authors of sed are in agreement with your intuition. But I think > policy 2 as a recursive definition it is unusual. And I see policy 2 > as very hard to summarize. > > The single-match is always easy to summarize: the leftmost longest match. > > Policy 1 for multiple matches can be summarized as: > >> All leftmost longest non-overlapping matches, where overlapping means sharing >> the same matching characters. > > Policy 2 for multiple matches can be summarized as: > >> All leftmost longest non-overlapping matches, where overlapping means sharing >> the same matching characters, excluding zero-length matches that coincide with >> the end of a non-zero-length match. > > Policy 0 has been: > >> All leftmost longest non-overlapping matches, where overlapping means sharing >> the same matching characters, stopping with the first zero-length match. Given this point, policy 1 does indeed seem the most consistent behaviour. Thanks for the explanation! From dons at galois.com Mon Jan 12 18:51:42 2009 From: dons at galois.com (Don Stewart) Date: Mon Jan 12 18:42:45 2009 Subject: Missing headers from SharedMem.hsc Message-ID: <20090112235142.GU3582@scytale.galois.com> It was also missing HsUnix.h, so the #defines weren't propagating anyway. Mon Jan 12 15:07:58 PST 2009 Don Stewart * Add check for -lrt to get the shm* functions. Subst. in buildinfo Mon Jan 12 15:47:17 PST 2009 Don Stewart * SharedMem.hsc wasn't including HsUnixConfig.h, so no #defines were propagating New patches: [Add check for -lrt to get the shm* functions. Subst. in buildinfo Don Stewart **20090112230758] hunk ./configure.ac 30 AC_CHECK_FUNCS([nanosleep]) AC_CHECK_FUNCS([ptsname]) AC_CHECK_FUNCS([setitimer]) + +# Avoid adding rt if absent or unneeded +AC_CHECK_LIB(rt, shm_open, [EXTRA_LIBS="$EXTRA_LIBS rt" CFLAGS="$CFLAGS -lrt"]) + +# needs -lrt on linux AC_CHECK_FUNCS([shm_open shm_unlink]) FP_CHECK_CONSTS([SIGABRT SIGALRM SIGBUS SIGCHLD SIGCONT SIGFPE SIGHUP SIGILL SIGINT SIGKILL SIGPIPE SIGQUIT SIGSEGV SIGSTOP SIGTERM SIGTSTP SIGTTIN SIGTTOU SIGUSR1 SIGUSR2 SIGPOLL SIGPROF SIGSYS SIGTRAP SIGURG SIGVTALRM SIGXCPU SIGXFSZ SIG_BLOCK SIG_SETMASK SIG_UNBLOCK], [ [SharedMem.hsc wasn't including HsUnixConfig.h, so no #defines were propagating Don Stewart **20090112234717] hunk ./System/Posix/SharedMem.hsc 26 #include #include +#include "HsUnix.h" + import System.Posix.Types import System.Posix.Error import Foreign.C Context: [Avoid using IOError internals Ian Lynagh **20090104173221] [fix pthread linkage problem for openbsd Matthias Kilian **20081129000638 This should make my openbsd build slave happy when SplitObjs=NO. May be useful for other BSDs and even Linux, regardless wether you need -pthread or -lpthread. Time will tell... ] [catch up with exception changes Simon Marlow **20080927135428] [Bump version number to 2.3.1.0 Ian Lynagh **20080920160248] [TAG 6.10 branch has been forked Ian Lynagh **20080919123439] [follow library changes Ian Lynagh **20080903223616] [add category field Ross Paterson **20080824003014] [We now depend on concurrent (split off from base) Ian Lynagh **20080824135158] [Fix the build when CONST_SIGPOLL == -1 Ian Lynagh **20080823160346 We were defining, but not using, sigPOLL ] [Fix warnings in the unix package Ian Lynagh **20080821120138] [move some stuff here from System.Directory, now the dependencies are reversed Simon Marlow **20080821144754] [Follow extensible exceptions changes Ian Lynagh **20080623193152] [Allow C's unsetenv to return either void or int Ian Lynagh **20080703190603 Fixes, and patch from donn in, trac #2352. ] [Avoid using deprecated flags Ian Lynagh **20080616145425] [move __hscore_{mkstemp,getrlimit,setrlimit} here from base Ross Paterson **20080615224248] [TAG 2008-05-28 Ian Lynagh **20080528004441] [Add a test for #2038 (resourceLimit) Ian Lynagh **20080520163012] [Use the C wrappers for [gs]etrlimit Ian Lynagh **20080520162048 This is for #2038: macros are used in the Linux .h includes to redirect to a 64-bit version when large file support is enabled. ] [Use the __hscore_mkstemp wrapper from the base package Ian Lynagh **20080520162039 This is for #2038: macros are used in the Linux .h includes to redirect to a 64-bit version when large file support is enabled. ] [small doc tweak Simon Marlow **20080508114348] [add AC_SYS_LARGEFILE check to configure.ac jeremy.shaw@linspireinc.com**20080213223619 As explained in this thread: http://www.haskell.org/pipermail/haskell-cafe/2008-February/039549.html getSymbolicLinkStatus (and possibly other functions) return completely bogus results. This is because hsc2hs returns the offsets for stat64, but the library is built such that it calls the 32 bit lstat call. I copied the AC_SYS_LARGEFILE from ghc's configure.ac. So, I believe the library should now properly autodetect whether your system has large file support and do the right thing more often. I suspect that this would still be buggy if ghc was built without large file support, but the library was built with it enabled. However, as long as AC_SYS_LARGEFILE returns the same results for 'ghc' and 'unix', things should be ok ? ] [Throw a proper exception if getUserEntryForName fails to find an entry Ian Lynagh **20080115020547 Fixes trac #2033. ] [Add a test getUserEntryForName for trac #1976 Ian Lynagh **20080115020540] [protect against concurrent access to the signal handlers (#1922) Simon Marlow **20071204110839 ] [Fix some haddock links Ian Lynagh **20071126184521] [Throw a proper exception if getGroupEntryForName fails to find an entry Ian Lynagh **20071110235805 We used to get *** Exception: getGroupEntryForName: failed (Success) Fixes trac #1655 ] [fix framework failures Simon Marlow **20071029114606] [Remove incorrect comment Ian Lynagh **20071014101756] [Specify build-type: Configure Duncan Coutts **20071018125127] [Bump version number Ian Lynagh **20071014101806] [Support for 57600 and 115200 baudrates pweaver@galois.com**20071016191631] [Also guard the foreign declaration of __hsunix(grant|unlock)pt by HAVE_PTSNAME Clemens Fruhwirth **20071016143846] [Add basic pseudoterminal support. Bryan O'Sullivan **20070925113330] [check for shm_open/shm_unlink (for archs like OpenBSD without them) Don Stewart **20070916025218] [Add more entries to boring file Ian Lynagh **20070913210721] [Add a boring file Ian Lynagh **20070913204658] [in pPrPr_disableITimers (who made up that name?) call the RTS to disable the timer Simon Marlow **20070912145647 Since we switched to using timer_create() in the RTS, this function has been failing to disables the timer interrupts. This turns out to be the cause of the random framework failures in the test suite. Invoking the RTS to turn off the timer signal is the right thing. ] [TAG ghc-6.8 branched 2007-09-03 Ian Lynagh **20070903155840] [Suppress some warnings Ian Lynagh **20070902194033] [Remove redundant include/Makefile Ian Lynagh **20070828205715] [add cross-referencing between posix and process modules ijones@syntaxpolice.org**20070819073930] [get the SIG constants for ourselves, rather than relying on HsBaseConfig.h Ross Paterson **20070819233142] [FIX BUILD on OS X: Check for setitimer Roman Leshchinskiy **20070814020033 Fix suggested by Ian Lynagh ] [Remove bits left over from the old build system Ian Lynagh **20070811135134] [Move System.Posix.Signals from base Ian Lynagh **20070729215617 Also adds System.Posix.Process.Internals in order to make the deps work out. ] [Move throwErrnoPath* functions to base:Foreign.C.Error Ian Lynagh **20070722002956] [GHC.Handle no longer exports openFd Ian Lynagh **20070722000926] [disable the getLoginName test, see #1487 Simon Marlow **20070703105224] [Don't do "< /dev/null" when running the user001 test Ian Lynagh **20070623205408 It can cause the test to fail. ] [--configure-option and --ghc-option are now provided by Cabal Ross Paterson **20070604115617] [Add support for named semaphores and shared memory objects Daniel Franke **20070503220003] [Remove Makefile and package.conf.in (used in the old build system) Ian Lynagh **20070524142637] [We now depend on process Ian Lynagh **20070523181544] [We now depend on directory Ian Lynagh **20070519160513] [add includes: field Simon Marlow **20070517095025] [Fix calling getAllUserEntries twice (trac #1279). Ian Lynagh **20070504104956 It used to return [] on all but the first call. Patch from an unidentified guest. ] [Make it more obvious that the forkprocess01 test is really working Ian Lynagh **20070418114542] [Follow Cabal changes in Setup.hs Ian Lynagh **20070418114510] [Handle sysconf(3) return value -1 when checking _SC_GETGR_R_SIZE_MAX and _SC_GETPW_R_SIZE_MAX. bjorn@bringert.net**20070416214837 sysconf(3) returns -1 on failure, but this was not handled when checking _SC_GETGR_R_SIZE_MAX and _SC_GETPW_R_SIZE_MAX in System.Posix.User. This made getUserEntryForID, getUserEntryForName, getGroupEntryForID and getGroupEntryForName fail on OS X 10.4.9 on i386. Just checking that unistd.h defines _SC_GETGR_R_SIZE_MAX and _SC_GETPW_R_SIZE_MAX as was done before does not guarantee that sysconf(3) will succeed. sysconf(3) failure is now handled by using the same default values as were already used when sysconf(3) is not available, or the parameter names are not defined. ] [Added tests/user001.hs which tests all the get* functions in System.Posix.User. bjorn@bringert.net**20070416220012 I added this since I noticed that getUserEntryForID, getUserEntryForName, getGroupEntryForID and getGroupEntryForName failed on OS X 10.4.9 on i386. ] [Fix -Wall warnings Ian Lynagh **20070411005028] [Add missing case in removePrefix Ian Lynagh **20070411002604] [parse (but don't pass on) options for ./configure Ian Lynagh **20070406153756] [make Setup suitable for building the libraries with GHC Ian Lynagh **20061112214741] [Don't use Fd/FD in foreign decls Ian Lynagh **20070404155930 Using CInt makes it much easier to verify that it is right, and we won't get caught out by possible newtype switches between CInt/Int. ] [Fix C/Haskell type mismatches Ian Lynagh **20070404003625] [Follow type changes in base Ian Lynagh **20070403195237 (of the dubiously exported c_access and c_fcntl_write) ] [fix cut-and-pasto in error message Simon Marlow **20070308134418] [add tests from GHC testsuite Simon Marlow **20070305145258] [export the file-type modes, so that createDevice can be used Simon Marlow **20070305113316] [Provide nanosleep if we have it, and use it to implement usleep Simon Marlow **20070302132818 Fixes #1156 ] [don't retry usleep() on EINTR (see #850/#1156) Simon Marlow **20070302114118] [expand docs for forkProcess Simon Marlow **20070301151220] [add C wrappers for lstat() and mknod(). Fixes #1086. Simon Marlow **20070226110311] [README about building from darcs Ross Paterson **20070218110201] [TAG 6.6 release Ian Lynagh **20061011124740] [fix haddock syntax Simon Marlow **20060908111858] [Derive Show, Read, and Eq for UserEntry and GroupEntry John Goerzen **20060831145022] [bump version to 2.0 Simon Marlow **20060831140257] [Fix compilation issues with new getgrent/getpwent code John Goerzen **20060830134517] [Added support for getpwent/getgrent John Goerzen **20060830132550] [Added some Haddock docs for UserEntry and GroupEntry John Goerzen **20060829185932] [Add missing field gr_passwd to GroupEntry John Goerzen **20060829185536] [Whitespace changes for better alignment in unpackUserEntry John Goerzen **20060829185300] [Added pw_passwd and pw_gecos fields to UserEntry structure John Goerzen **20060829185051 System.Posix.User was missing pw_gecos and pw_passwd in UserEntry. I have added them, so now the full struct passwd is represented. ] [includes -> install-includes Ross Paterson **20060829123744] [exclude Setup.hs from build Ross Paterson **20060824183535] [add boilerplate Setup.hs Ross Paterson **20060824115019] [Added more documentation to System.Posix.Files Johan Tibell **20060813102350] [fix markup (#854) Ross Paterson **20060820002322] [change test for buildability Ross Paterson **20060819144834 Checking for dlfcn.h instead of creat() should make the Cabal build fail more gracefully under MinGW. ] [document args to executeFile Simon Marlow **20060809104559] [fix bogosity in getEnvironmentPrim Simon Marlow **20060531144640] [Track the GHC source tree reoganisation Simon Marlow **20060407041758] [TAG Initial conversion from CVS complete John Goerzen **20060112154138] [[project @ 2005-11-10 13:00:55 by simonmar] simonmar**20051110130055 some Haddock docs, from Isaac Jones. ] [[project @ 2005-11-10 12:58:32 by simonmar] simonmar**20051110125832 Some docs for System.Posix, from Bj?rn Bringert ] [TAG cmm-merge2 Unknown tagger**20060112152636] [[project @ 2005-09-20 22:54:33 by ross] ross**20050920225433 make the unix package independent. ] [[project @ 2005-09-20 16:35:26 by ross] ross**20050920163526 move RTLD_* tests down to unix package ] [[project @ 2005-09-19 23:24:31 by ross] ross**20050919232431 For compilers other than MSVC and GCC, assume inline has the C99 semantics. ] [[project @ 2005-08-10 10:07:22 by simonmar] simonmar**20050810100722 Fix queryFdOption ] [[project @ 2005-08-04 02:09:36 by wolfgang] wolfgang**20050804020936 Check for RTLD_DEFAULT in dlfcn.h and use it if it is available. (On Mac OS X its value is -2, and using NULL instead does not work.) MERGE TO STABLE ] [[project @ 2005-07-21 12:54:33 by simonmar] simonmar**20050721125433 Hack Makefiles so that 'make distclean' works even if the tree has not been configured, or 'make distclean' has already been run. This is to solve problems caused by 'make distclean' removing files that it needs itself - previously we were arranging to remove certain files right at the end of cleaning, but this is fragile. So now we assume that e.g. the X11 library is always enabled when we're cleaning. ] [[project @ 2005-05-10 10:40:12 by simonmar] simonmar**20050510104012 PATH_MAX fixes from Thomas Schwinge. ] [TAG arity-anal-branch-point Unknown tagger**20060112152625] [TAG ghc-assoc-branch-point Unknown tagger**20060112152625] [[project @ 2005-03-23 14:34:21 by ross] ross**20050323143421 add license files for individual packages ] [TAG nhc98-1-18-release Unknown tagger**20060112152623] [[project @ 2005-03-08 16:22:05 by simonmar] simonmar**20050308162205 Undo previous commit: it breaks when RLIM_INFINITY is defined to an expression that CPP doesn't understand. ] [[project @ 2005-03-08 04:45:38 by wolfgang] wolfgang**20050308044538 Mac OS X: Kill HaskellSupport.framework. Instead, look for GMP.framework (a framework-version of libgmp), else look for a normal -lgmp as usual. The other part of HaskellSupport.framework, dlcompat, is no longer needed (as of Mac OS X 10.3, it's included in libSystem). It's enough to just use the normal configure tests for -ldl. MERGE TO STABLE ] [[project @ 2005-03-05 14:32:09 by panne] panne**20050305143209 Warning police (for platforms where all resource limits can be represented, i.e. RLIM_INFINITY == RLIM_SAVED_MAX == RLIM_SAVED_CUR) ] [[project @ 2005-03-02 16:39:57 by ross] ross**20050302163958 *Config.h files are in include/ (MERGE to STABLE) ] [[project @ 2005-03-02 14:46:16 by simonmar] simonmar**20050302144616 distcleaning of things generated by configure ] [[project @ 2005-02-24 09:58:27 by simonmar] simonmar**20050224095827 nDoc fixes from Sven Panne. Generally fixing of Haddock links, adding some signatures, and in some cases exporting type constructors that are mentioned in the types of exported identifiers. ] [[project @ 2005-02-18 18:30:40 by ross] ross**20050218183040 Rename package description fields as in InstalledPackageInfo: options-ghc -> ghc-options options-hugs -> hugs-options options-nhc -> nhc-options extra-libs -> extra-libraries ] [[project @ 2005-02-18 15:06:47 by simonmar] simonmar**20050218150647 Rename fields in InstalledPackageInfo for consistency with PackageDescription & buildInfo: extra-libs (extraLibraries) --> extra-libraries (extraLibraries) extra-cc-opts (extraCcOpts) --> cc-options (ccOptions) extra-ld-opts (extraLdOpts) --> ld-options (ldOptions) extra-hugs-opts (extraHugsOpts) --> hugs-options (hugsOptions) extra-frameworks (extraFrameworks) --> frameworks (frameworks) ] [[project @ 2005-02-11 01:55:58 by ross] ross**20050211015558 track syntax changes: * add License-File and Synopsis fields * rename Hidden-Fields as Other-Fields These files are used only by Hugs, but are also useful as examples. ] [[project @ 2005-02-07 12:03:44 by simonmar] simonmar**20050207120344 Doc for handleToFd and fdToHandle ] [TAG ghc-6-4-branch-point Unknown tagger**20060112152610] [[project @ 2005-01-28 13:36:36 by simonmar] simonmar**20050128133636 Catch up with updates to platform #defines. Generally: use _HOST_ rather than _TARGET_ (except in Cabal where we have to retain compatibility with previous GHC versions). ] [[project @ 2005-01-25 17:06:40 by ross] ross**20050125170640 add Cabal package descriptions ] [[project @ 2005-01-21 12:35:38 by simonmar] simonmar**20050121123538 update the haddock fields (this one somehow got missed) ] [[project @ 2005-01-20 14:22:28 by simonmar] simonmar**20050120142228 Fill in the haddock-interfaces and haddock-html fields in the package.conf files. To do this I had to make some changes: - haddock-interfaces requires the value of $(datadir). We can't just plug this in, because $(datadir) might change at install-time (eg. a Windows installer can be placed anywhere, as can a Unix binary .tar.gz distribution). The current trick is for the compiler to splice in the value of $libdir in package.conf at runtime. So we could extend this mechanism and tell the compiler the value of $datadir via a command-line option, but that seems ugly. On Windows, $datadir==$libdir, so we don't need any changes: package.conf still uses $libdir, and a Windows installation is independent of its absolute location. Even 'make install' on Windows should have this property. On Unix: - for 'make install' and in-place execution, we just use absolute paths in package.conf - for a binary dist, we generate a package.conf that refers to $libdir and $datadir, and splice in the values at install-time (distrib/Makefile-bin.in). - Also, I renamed $libdir to $topdir to more closely reflect its actual meaning. This is somewhat malicious in that it will flush out all those clients using $libdir when they really shouldn't be :-) ] [[project @ 2005-01-06 11:27:48 by ross] ross**20050106112748 c_ftruncate is now in System.Posix.Internals ] [TAG pluggable-1-branch-point Unknown tagger**20060112152603] [[project @ 2004-12-02 15:57:06 by ross] ross**20041202155706 Hugs only: replace the CBITS pragma (files relative to cbits) with CFILES (files relative to the root of the package). ] [[project @ 2004-11-26 16:22:12 by simonmar] simonmar**20041126162212 Further integration with the new package story. GHC now supports pretty much everything in the package proposal. - GHC now works in terms of PackageIds (-) rather than just package names. You can still specify package names without versions on the command line, as long as the name is unambiguous. - GHC understands hidden/exposed modules in a package, and will refuse to import a hidden module. Also, the hidden/eposed status of packages is taken into account. - I had to remove the old package syntax from ghc-pkg, backwards compatibility isn't really practical. - All the package.conf.in files have been rewritten in the new syntax, and contain a complete list of modules in the package. I've set all the versions to 1.0 for now - please check your package(s) and fix the version number & other info appropriately. - New options: -hide-package P sets the expose flag on package P to False -ignore-package P unregisters P for this compilation For comparison, -package P sets the expose flag on package P to True, and also causes P to be linked in eagerly. -package-name is no longer officially supported. Unofficially, it's a synonym for -ignore-package, which has more or less the same effect as -package-name used to. Note that a package may be hidden and yet still be linked into the program, by virtue of being a dependency of some other package. To completely remove a package from the compiler's internal database, use -ignore-package. The compiler will complain if any two packages in the transitive closure of exposed packages contain the same module. You *must* use -ignore-package P when compiling modules for package P, if package P (or an older version of P) is already registered. The compiler will helpfully complain if you don't. The fptools build system does this. - Note: the Cabal library won't work yet. It still thinks GHC uses the old package config syntax. Internal changes/cleanups: - The ModuleName type has gone away. Modules are now just (a newtype of) FastStrings, and don't contain any package information. All the package-related knowledge is in DynFlags, which is passed down to where it is needed. - DynFlags manipulation has been cleaned up somewhat: there are no global variables holding DynFlags any more, instead the DynFlags are passed around properly. - There are a few less global variables in GHC. Lots more are scheduled for removal. - -i is now a dynamic flag, as are all the package-related flags (but using them in {-# OPTIONS #-} is Officially Not Recommended). - make -j now appears to work under fptools/libraries/. Probably wouldn't take much to get it working for a whole build. ] [[project @ 2004-11-18 16:39:54 by stolz] stolz**20041118163954 Push down more feature-tests ] [[project @ 2004-11-12 17:08:58 by stolz] stolz**20041112170858 Fix FFI-funniness, cf. http://www.haskell.org/pipermail/glasgow-haskell-users/2002-February/003020.html Noticed by: George Russell (again) ] [[project @ 2004-11-12 14:56:13 by stolz] stolz**20041112145613 Fix previous commit: Don't handle Solaris2-flag _POSIX_PTHREAD_SEMANTICS in configure at all but simply #ifdef solaris2_TARGET_OS #define ... it in the header-file. ] [[project @ 2004-11-12 13:22:56 by stolz] stolz**20041112132256 More getpw*_r result checks ] [[project @ 2004-11-12 12:12:53 by stolz] stolz**20041112121253 Push some unixisms from toplvl into package: usleep, SunOS-handling, getpw* ] [[project @ 2004-11-05 14:59:33 by stolz] stolz**20041105145933 Fix getpwnam_r-handling: getpwnam_r returns (always?) 0, you have to check result* (pppw[0])! Truss-log from querying first "root", then "" on SunOS 5.9: <- libc:__posix_getpwnam_r() = 0 "root" -> libc:__posix_getpwnam_r(0xff1bf8a8, 0xff1bf460, 0xff1bf490, 0x400) <- libc:__posix_getpwnam_r() = 0 Yes, that's 0 in both cases. (I wasn't even able to elicit an ERANGE btw.) Reported by: Peter Simons ] [[project @ 2004-10-27 10:51:15 by simonmar] simonmar**20041027105115 Fix bug in forkProcess: we weren't wrapping the forked IO action in the default exception handler, so exitFailure wasn't working properly. ] [[project @ 2004-10-15 09:42:02 by simonmar] simonmar**20041015094202 - sleep, usleep: make thread-safe - add Haddock comments ] [[project @ 2004-10-09 07:51:07 by panne] panne**20041009075107 Unbreak Hugs by moving pPrPr_disableITimers and execvpe to System.Posix.Internals (base package) and use it from System.Posix.Process (unix package). ] [[project @ 2004-10-08 18:35:50 by panne] panne**20041008183550 Unbreak Hugs, 2nd try... ] [[project @ 2004-10-08 17:48:57 by panne] panne**20041008174857 Unbreak Hugs: execvpe.c has gone ] [[project @ 2004-10-08 12:04:49 by ross] ross**20041008120449 revert previous change, so now these includes don't define PACKAGE_* ] [[project @ 2004-10-08 08:42:53 by dons] dons**20041008084253 Tweak the PACKAGE_* #undefs in a couple of other places, too. ] [[project @ 2004-10-06 10:13:08 by ross] ross**20041006101308 make the evil PACKAGE_* hacks consistent ] [[project @ 2004-09-30 03:13:23 by dons] dons**20040930031323 Implement System.Posix.User.getUserEntryFor{ID,Name} on platforms without reentrant versions of getpw{uid,nam}. This includes all the BSDs. While I'm here, close getGroupEntryFor* "Result too large" bug on OpenBSD, mentioned last year: http://www.haskell.org/pipermail/glasgow-haskell-bugs/2003-September/003601.html grBufSize was too small, apparently. Thanks to Ian Lynagh for hint to do the locking. ] [[project @ 2004-09-29 15:50:54 by simonmar] simonmar**20040929155055 Process reorganisation: the System.Process library moves into base, and System.Cmd is re-implemented in terms of it. Thanks to Krasimir Angelov, we have a version of System.Process that doesn't rely on the unix or Win32 libraries. Normally using unix/Win32 would be the right thing, but since we want to implement System.Cmd on top of this, and GHC uses System.Cmd, we can't introduce a bunch of .hsc dependencies into GHC's bootstrap libraries. So, the new version is larger, but has fewer dependencies. I imagine it shouldn't be too hard to port to other compilers. ] [[project @ 2004-09-22 09:14:23 by panne] panne**20040922091423 As a temporary measure, use an ultra-evil sledgehammer method to silence the PACKAGE_FOO clashes. The correct way of doing this would be splitting up HsPACKAGE.h and ghcconfig.h into two parts each: One part would be generated by autoheader and would contain the defines which are needed during package build time only. The other part would contain all kinds of stuff which is needed for using the given package (no PACKAGE_FOO defines here). For an example of this, see the OpenAL package. As an additional benefit, this would keep the namespace much cleaner, because 2nd kind of headers is typically smaller. No time for the real thing currently, hope the current workaround works... ] [[project @ 2004-09-18 12:50:00 by panne] panne**20040918125000 Make autoupdate 2.52 happy, mainly by using the new formats of AC_INIT and AC_OUTPUT. This has the nice side effect that all "packages" have now a name, a version, a bug-report address, and a tar name, yielding better output with "configure --help=recursive". Nuked an unused AC_STRUCT_ST_BLKSIZE test on the way. ] [[project @ 2004-09-15 15:55:45 by stolz] stolz**20040915155546 Add System.Posix.Signals.Exts which re-exports S.P.Signals and adds the two signals SIGINFO on (*BSD) and SIGWINCH (most Unices) which are not in POSIX. You should use cpp to test if those are defined before using them. This is encouraged by not providing dummy-definitions on platforms which do not offer that particular flavour. ] [[project @ 2004-09-09 06:55:47 by panne] panne**20040909065547 Unified the comments in (almost) empty aclocal.m4 files ] [[project @ 2004-09-03 07:46:56 by ross] ross**20040903074656 add empty aclocal.m4's (so we don't need aclocal) ] [[project @ 2004-09-02 15:18:10 by ross] ross**20040902151810 devolve some library-specific configuration ] [[project @ 2004-08-19 11:15:51 by simonmar] simonmar**20040819111552 Add filenames to all errors where it makes sense. I've added System.Posix.Error with a new family of error-throwing functions, throwErrnoPath*. This seemed to make the most sense: they don't belong in Foreign.C.Error (C by itself has no notion of paths). Fixes: [ 954378 ] getFileStatus does not include the file name in IO-Error ] [[project @ 2004-08-13 13:29:11 by simonmar] simonmar**20040813132911 Changes required be merge of backend-hacking-branch. Mostly config.h ==> ghcconfig.h. ] [[project @ 2004-05-13 09:55:59 by stolz] stolz**20040513095559 Inverted logic would call dlerror() after a successful dlclose() and cause a segfault. Noticed by: abe.egnor At gmail.com ] [[project @ 2004-03-09 11:37:14 by simonmar] simonmar**20040309113714 change the foreign import of waitpid to "safe", so that we can use it in a non-blocking way with the threaded RTS. ] [[project @ 2004-02-19 16:29:28 by stolz] stolz**20040219162928 Remove redundant _POSIX_PTHREAD_SEMANTICS. It's defined on the command line and also set too late/in the wrong place (after including system prototypes), anyway. ] [[project @ 2004-02-05 11:46:00 by ross] ross**20040205114600 Hugs only: use the configure-set variable INLINE_ONLY instead of `extern inline' (which works for gcc but not C99 compilers). ] [[project @ 2003-12-15 16:57:30 by ross] ross**20031215165730 include dirent.h to avoid warnings when compiling System.Posix.Directory ] [[project @ 2003-12-05 10:20:25 by ross] ross**20031205102025 solaris_TARGET_OS -> solaris2_TARGET_OS (and tweak the #define while I'm here) Works for Hugs, still untested for GHC, but presumably needed for STABLE. ] [[project @ 2003-11-15 22:31:18 by panne] panne**20031115223118 Decouple packages a bit more again: The prologue of the combined index is now generated via shell magic from the package prologues. As a nice side effect, some autoconf magic is gone, so configure.ac is effectively empty now (but not for long... :-) ] [[project @ 2003-11-10 15:32:45 by simonmar] simonmar**20031110153245 Change the documentation title from "Haskell Core Libraries" to "Haskell Hierarchical Libraries". ] [[project @ 2003-10-27 11:58:28 by stolz] stolz**20031027115828 - fix typo in error message - a bit of manual CSE for fcntl-flags - use Data.Bits instead of brains - make (unexported) function names a bit more consistent ] [[project @ 2003-10-24 14:46:13 by sof] sof**20031024144613 drop cygwin #ifdef; not an issue with current versions. merge to stable ] [[project @ 2003-10-24 14:38:27 by sof] sof**20031024143827 code tidyup merge to stable ] [[project @ 2003-10-23 23:32:43 by sof] sof**20031023233243 fdRead: drop superfluous array copying merge to stable ] [[project @ 2003-10-18 00:35:26 by ross] ross**20031018003526 Hugs only: add handleToFd ] [[project @ 2003-10-17 16:48:44 by ross] ross**20031017164845 Hugs only: add most of the rest of System.Posix (I wonder why SIG_UNBLOCK and SIG_SETMASK are switched in HsBase.h) ] [[project @ 2003-10-01 10:57:44 by wolfgang] wolfgang**20031001105744 New implementation & changed type signature of forkProcess forkProcess now has the following type: forkProcess :: IO () -> IO ProcessID forkProcessAll has been removed as it is unimplementable in the threaded RTS. forkProcess using the old type (IO (Maybe ProcessID)) was impossible to implement correctly in the non-threaded RTS and very hard to implement in the threaded RTS. The new type signature allows a clean and simple implementation. ] [[project @ 2003-09-24 13:42:15 by simonmar] simonmar**20030924134215 No reason we can't support sys/mman.h: move it to the ToDo section. ] [[project @ 2003-09-22 10:57:45 by simonmar] simonmar**20030922105745 Untested fix for Solaris to get the right versions of getgrnam_r and friends. I'd appreciate it if someone with a Solaris build could test this. ] [[project @ 2003-09-19 09:27:35 by simonmar] simonmar**20030919092735 Kill mktemp: it causes link warnings whenever someone uses -package unix on Linux & FreeBSD at least, and is bogus anyway. mktemp is still used to implement mkstemp when !GLASGOW_HASKELL and !HUGS. Why is this? ] [[project @ 2003-09-16 13:45:02 by simonmar] simonmar**20030916134502 fileExist should not throw an exception if the file does not exist. ] [[project @ 2003-09-15 20:59:07 by dons] dons**20030915205907 #ifdef's for the _PC_SYNC_IO, _PC_ASYNC_IO, _PC_FILESIZEBITS, _PC_SYMLINK_MAX. These 4 symbols are not universal: FreeBSD and Linux and the only OS's that appear to have them at the moment. ] [[project @ 2003-09-12 13:05:20 by simonmar] simonmar**20030912130520 Implement pathconf()/fpathconf() wrappers. ] [TAG ghc-6-2-branch-point Unknown tagger**20060112152454] [[project @ 2003-08-04 14:08:27 by panne] panne**20030804140827 Export TerminalAttributes abstractly ] [[project @ 2003-08-04 13:26:12 by panne] panne**20030804132614 More import tweaking for Haddock ] [[project @ 2003-08-04 13:22:05 by panne] panne**20030804132205 Export Module (abstractly), otherwise the user is unable to write signatures involving this type. Improves Haddock hyperlinks, too. ] [TAG ghc-6-0-OpenGL-merge3 Unknown tagger**20060112152446] [[project @ 2003-07-22 09:55:07 by ross] ross**20030722095507 jiggle to make System.Posix.Directory work for Hugs ] [[project @ 2003-07-16 13:04:55 by ross] ross**20030716130455 Sendfile is gone ] [[project @ 2003-06-22 09:02:15 by wolfgang] wolfgang**20030622090215 Revert last commit (remove "network" dependency again), as it was already fixed in a different way and I forgot to update... :-( ] [[project @ 2003-06-21 09:14:51 by wolfgang] wolfgang**20030621091451 Add package "network" to the list of dependencies, as it is needed by Sendfile. Fixes a link error when starting "ghci -package unix". ] [[project @ 2003-06-19 10:47:25 by simonmar] simonmar**20030619104726 Remove Network.Sendfile at request of Volker Stolz. We currently have some build problems with it (it depends on both unix and network packages). It might come back at some point in the future. ] [[project @ 2003-06-10 12:07:40 by simonmar] simonmar**20030610120740 - Use the right fdToHandle - some minor -Wall cleaning ] [[project @ 2003-06-10 10:58:06 by simonmar] simonmar**20030610105806 Move Network.Sendfile into the unix package to fix the build. ] [[project @ 2003-06-06 12:49:00 by stolz] stolz**20030606124900 Move System.Sendfile to Network.Sendfile: - Linux can sendfile() to a fd, but BSD couldn't - sendfile() on Linux is probably now disabled on most builds because of the LARGEFILE issue => Change API to use type Socket ] [[project @ 2003-06-06 12:41:12 by stolz] stolz**20030606124112 Obsolete ] [[project @ 2003-06-06 10:45:43 by stolz] stolz**20030606104543 Haddock: Add link to 'handleToFd' ] [[project @ 2003-06-03 14:01:38 by simonmar] simonmar**20030603140138 Hook up System.Posix.Temp. ] [[project @ 2003-06-03 11:31:45 by stolz] stolz**20030603113145 waitpid() may return EINTR, so use throwErrnoifMinus1Retry ] [[project @ 2003-06-03 08:55:13 by reid] reid**20030603085513 cvs ignorance for splits and way=p ] [[project @ 2003-05-28 12:36:29 by stolz] stolz**20030528123629 Can't use sendfile() with LARGEFILES on Linux ] [[project @ 2003-05-28 12:01:50 by stolz] stolz**20030528120150 No longer pertinent ] [[project @ 2003-05-27 12:59:54 by stolz] stolz**20030527125954 /me slaps haddock with a large piece of trout. Someone please remind me of running 'make html' before committing. ] [[project @ 2003-05-27 12:54:18 by stolz] stolz**20030527125418 Throw in mktemp() as well, as the non-GHC/Hugs case was essentially that. Advantage: At least on FreeBSD the linker will print out a warning whenever you use mktemp(). ] [[project @ 2003-05-27 10:18:58 by ross] ross**20030527101858 Hugs only: use fdToHandle (like GHC) ] [[project @ 2003-05-27 10:18:16 by ross] ross**20030527101816 Hugs only: make fdToHandle available ] [[project @ 2003-05-27 08:59:21 by stolz] stolz**20030527085921 Return file name as well Suggested by: Martin Norb?ck ] [[project @ 2003-05-27 08:20:42 by stolz] stolz**20030527082042 Add mkstemp() wrapper, including (unsafe) fallback for non-GHCs (fdToHandle required). Suggested by: Martin Sj?gren ] [[project @ 2003-05-23 18:35:55 by stolz] stolz**20030523183555 Need flags here as well. ] [[project @ 2003-05-23 16:36:48 by ross] ross**20030523163648 fix type error ] [[project @ 2003-05-23 14:31:46 by stolz] stolz**20030523143146 No (un)setenv until SUSv3 (e.g. Solaris 2.9). (fallback untested) ] [[project @ 2003-05-21 16:02:44 by stolz] stolz**20030521160244 Solaris2 needs _POSIX_PTHREAD_SEMANTICS for the getpw*_r() prototypes. Make libraries/unix/Makefile use a new variable unix_SRC_HSC2HS_OPTS which we configure in mk/config.mk. ] [TAG ghc-6-0-branch-point Unknown tagger**20060112152412] [[project @ 2003-05-21 15:07:55 by simonmar] simonmar**20030521150755 Revert previous commit, I've fixed Haddock instead. ] [[project @ 2003-05-21 14:58:36 by simonmar] simonmar**20030521145836 Flatten the doc structure a bit. ] [[project @ 2003-05-19 18:24:25 by reid] reid**20030519182425 cvs ignorance is bliss ] [[project @ 2003-05-18 06:47:42 by stolz] stolz**20030518064742 - My fault, so take ownership - Strip unnecessary #include while here ] [[project @ 2003-05-17 00:11:30 by ross] ross**20030517001130 Rename per-package configuration files from $(PACKAGE).conf.* to package.conf.*, making them easier to find (since each package is in a separate directory anyway). ] [[project @ 2003-05-16 12:03:55 by stolz] stolz**20030516120355 Look for 'bracket' in the right place ] [[project @ 2003-05-16 10:14:23 by simonmar] simonmar**20030516101423 Now that we have auto packages, it makes sense to keep all the interfaces for hierarchical libraries in the same directory tree. So now, instead of putting interfaces for package P in $libdir/imports/P, we put them all in $libdir/imports. Interfaces for old non-auto non-hierarchical packages now go in $libdir/hslibs-imports/P for package P. ] [[project @ 2003-05-16 08:25:30 by simonmar] simonmar**20030516082530 Move dlfcn.h to the "supported" list. ] [[project @ 2003-05-16 06:41:25 by stolz] stolz**20030516064127 - move System.DL to System.Posix.DynamicLinker - take ownership There's a compiler warning when passing the 'const char*' result from dlerror() to peekCString (discarded qualifier). Does an FFI-expert know how to get rid of this warning? ] [[project @ 2003-05-15 13:35:12 by ross] ross**20030515133512 add the DL modules (or whatever they're called) to Hugs ] [[project @ 2003-05-12 13:19:49 by wolfgang] wolfgang**20030512131949 Add #ifdefs for RLIMIT_AS and RLIM_SAVED_*, which are not defined on Mac OS X. ] [[project @ 2003-05-08 16:00:20 by ross] ross**20030508160020 extra #include's ] [[project @ 2003-04-11 23:42:54 by ross] ross**20030411234254 list modules that don't yet work with Hugs. ] [[project @ 2003-04-11 23:37:03 by ross] ross**20030411233703 replace Word with CTcflag ] [[project @ 2003-04-11 10:17:13 by ross] ross**20030411101713 use System.Posix.Internals ] [[project @ 2003-04-11 10:11:23 by ross] ross**20030411101124 rename GHC.Posix as System.Posix.Internals ] [[project @ 2003-04-11 10:00:07 by ross] ross**20030411100007 move environ from C to Haskell ] [[project @ 2003-04-11 09:43:38 by ross] ross**20030411094338 add some standard #includes ] [TAG galois-hbm-head Unknown tagger**20060112152340] [[project @ 2003-03-26 12:35:34 by simonmar] simonmar**20030326123534 Add getrlimit()/setrlimit() suppport ] [[project @ 2003-03-26 12:34:53 by simonmar] simonmar**20030326123453 wibble: add a newline at the end of the file ] [TAG before-galois-hbm Unknown tagger**20060112152337] [[project @ 2003-03-17 07:52:02 by stolz] stolz**20030317075202 Do not export c_sendfile (might not exist) ] [[project @ 2003-03-16 15:07:37 by stolz] stolz**20030316150737 (Hopefully) Fix #ifdef'ed branch Noticed by: Kirsten Chevalier ] [[project @ 2003-03-09 20:19:28 by panne] panne**20030309201930 Fixed markup confusion ("" vs. '') ] [[project @ 2003-03-07 16:22:49 by stolz] stolz**20030307162249 - Change Handle to Fd, so it's everybodies own fault if they forget to call hDuplicate - Revert size/offset to Int as lowest common denominator - Add sendfileByName ] [[project @ 2003-03-06 14:23:09 by stolz] stolz**20030306142309 Monad->Control.Monad ] [[project @ 2003-03-06 08:33:16 by stolz] stolz**20030306083316 - Haddockify documentation for parameters - Fix 'case vs. if' braino ] [[project @ 2003-03-05 18:38:09 by stolz] stolz**20030305183809 Steal 'squirt' from Haskell Web Server as fallback ] [[project @ 2003-03-05 18:14:05 by stolz] stolz**20030305181405 Pick up Maybe & Monad from new libraries ] [[project @ 2003-03-03 01:51:58 by stolz] stolz**20030303015200 Import System/DL* ] [[project @ 2003-03-01 16:34:12 by stolz] stolz**20030301163412 s/getEnvVar/getEnv/ ] [[project @ 2003-02-28 16:46:49 by stolz] stolz**20030228164649 Update comments to reflect new module System.Posix.Env ] [[project @ 2003-02-28 16:09:16 by stolz] stolz**20030228160916 Add System.Posix.Env ] [[project @ 2003-02-28 12:44:54 by stolz] stolz**20030228124454 Fix 'nice': -1 is a permissible return value in a successful situation ] [[project @ 2003-02-28 12:34:45 by stolz] stolz**20030228123445 - Rename System.Posix.Process.forkProcess to forkProcessAll - Move GHC.Conc.forkProcess to System.Posix with type 'Maybe ProcessID' Prompted by: George Russel ] [[project @ 2003-02-27 15:46:57 by stolz] stolz**20030227154657 - Add documentation for fd{Read,Write} & createPipe - Unbreak setFdOption which didn't set any options at all ] [[project @ 2003-02-27 13:27:50 by stolz] stolz**20030227132750 Move fd{Read,Write} to new layout. Use of memcpy() should bring a large performance increase compared to the old version. ] [[project @ 2003-02-17 11:43:55 by simonmar] simonmar**20030217114355 Comment wibbles ] [TAG before-speceval_2 Unknown tagger**20060112152311] [[project @ 2003-01-17 17:01:14 by stolz] stolz**20030117170114 - Add sendfile-API for pumping out data via sendfile(2) Currently supported are Linux (tested) & FreeBSD (not tested yet), others will throw a runtime error until I get around to implement a fallback. ] [[project @ 2002-12-26 21:01:46 by panne] panne**20021226210146 Once again: Make Haddock happy. Running Haddock in addition to ghc (i.e. use 'make all html' instead of plain 'make') before a commit would be nice, especially as buglets like this break a 3 hour RPM build just before it can finish... :-( ] [[project @ 2002-12-26 17:52:35 by wolfgang] wolfgang**20021226175235 Mac OS X doesn't have the sysconfig constants _SC_GETPW_R_SIZE_MAX and _SC_GETGR_R_SIZE_MAX, so add a configure check ] [[project @ 2002-12-19 13:52:55 by simonmar] simonmar**20021219135255 Fill in some more bits in the new Unix library: specifically the contents of PosixTTY and PosixDB (now System.Posix.Terminal and System.Posix.User respectively). We're now about 95% complete w.r.t. the old posix library. I've identified the reminaing bits to do in System/Posix.hs. ] [[project @ 2002-12-18 16:29:26 by simonmar] simonmar**20021218162926 "Auto" packages. The big change here is that it is no longer necessary to explicitly say '-package X' on the command line if X is a package containing hierarchical Haskell modules. All packages marked "auto" contribute to the import path, so their modules are always available. At link time, the compiler knows which packages are actually used by the program, and it links in only those libraries needed. There's one exception: one-shot linking. If you link a program using ghc -o prog A.o B.o ... then you need to explicitly add -package flags for each package required (except base & haskell98) because the compiler has no information about the package dependencies in this case. Package configs have a new field: auto, which is either True or False. Non-auto packages must be mentioned on the command-line as usual. Non-auto packages are still required for: - non-hierarchical libraries (to avoid polluting the module namespace) - packages with no Haskell content - if you want more than one version of a package, or packages providing overlapping functionality where the user must decide which one to use. Doc changes to follow... ] [[project @ 2002-12-12 13:42:48 by ross] ross**20021212134248 Changes to the exception interface, as discussed on the libraries list. 1) Move bracket and bracket_ from GHC.Exception (and hence System.IO) to haskell98/IO.hs. These two should now never be used (except in all-H98 programs), and this will save users of the new libraries from having to hide them. Use the ones in Control.Exception instead. 2) Define type IOError = IOException -- was Exception leaving the type of Prelude.ioError as IOError -> IO a, but adding to Control.Exception throwIO :: Exception -> IO a The result is a type distinction between the variants of catch and try: Prelude.catch :: IO a -> (IOError -> IO a) -> IO a Control.Exception.catch :: IO a -> (Exception -> IO a) -> IO a System.IO.Error.try :: IO a -> IO (Either IOError a) Control.Exception.try :: IO a -> IO (Either Exception a) These are breaking changes: the first one affects only import lists, but the second will bite in the following situations: - using ioError on general Exceptions: use throwIO instead. - using throw on IOErrors: if in the IO monad, use ioError instead. Otherwise, use throw (IOException e), but why are you throwing IO exceptions outside of the IO monad? Minor changes: - System.IO.Error now exports catch and try - moved try from GHC.Exception to System.IO.Error, because it's portable and can be shared by Hugs. ] [[project @ 2002-11-18 08:37:35 by stolz] stolz**20021118083735 readlink(2) does not append a NUL character to buffer. Noticed by: John Meacham ] [[project @ 2002-10-11 14:25:25 by stolz] stolz**20021011142525 'usleep' nightmare: Sometimes return type is void, sometimes int. ] [[project @ 2002-10-08 08:03:02 by wolfgang] wolfgang**20021008080302 Make the new Posix bindings compile on Mac OS X. Most notable, Mac OS X lacks *) lchown *) SIGPOLL I don't know of a replacement of either, so they are just left out when they are not detected by configure. ] [[project @ 2002-10-05 22:35:45 by panne] panne**20021005223545 Warning police #14: Help gcc a bit with variables which are not obviously always used. ] [[project @ 2002-09-14 09:35:00 by panne] panne**20020914093500 4th attempt to get a working RPM, but again: Make Haddock happy. Is doing a "make html" that hard before committing...? :-] ] [[project @ 2002-09-13 09:12:12 by simonmar] simonmar**20020913091212 - #include to get at get/setpriority. - #include "config.h", and protect other includes according to the configure results. ] [[project @ 2002-09-12 16:38:21 by simonmar] simonmar**20020912163822 More POSIX bits... we're getting there. ] [[project @ 2002-09-10 20:54:33 by panne] panne**20020910205433 No prologue.txt, no -p... ] [[project @ 2002-09-06 14:34:15 by simonmar] simonmar**20020906143415 Partial rewrite of the POSIX library. The main purpose of this sweep is to remove the last dependencies of the compiler on hslibs. When I've committed the associated compiler changes, only the 'base' package will be required to bootstrap the compiler. Additionally to build GHCi, the 'readline' and 'unix' packages will be required. The new POSIX library lives mostly in libraries/unix, with a few bits required for compiler bootstrapping in libraries/base. The 'base' package is mostly free of hsc2hs code to make bootstrapping from HC files easier, but the 'unix' package will use hsc2hs liberally. The old POSIX library continues to provide more-or-less the same interface as before, although some of the types are more correct now (previously lots of POSIX types were just mapped to Int). The new interface is largely the same as the old, except that some new functionality from the latest POSIX spec has been added (eg. symbolic links). So far, the new POSIX library has signal support, directory/file operations and lots of stuff from unistd.h. The module names are: System.Posix The main dude, exports everything System.Posix.Types All the POSIX types, using the same naming scheme as Foreign.C.Types, Eg. CUid, COff, etc. Many of these types were previously exported by GHC.Posix. Additionally exports the "nicer" names used by the old POSIX library for compatibility (eg. ProcessID == CPid, FileMode == CMode, etc.) All reasonable instances are derived for these types. System.Posix.Signals Signal support, contains most of which was in PosixProcPrim before. The RTS interface to the signal handling support has been rationalised slightly. System.Posix.Directory Directory support, most were in PosixFiles before. System.Posix.Files File operations, most were in PosixFiles before. System.Posix.Unistd (for want of a better name) Miscellaneous bits that mostly come from the unistd.h header file. PosixProcEnv before. The rest of the library should pan out like so: System.Posix.IO System.Posix.Error (maybe) System.Posix.Process System.Posix.Terminal (I've no doubt broken Win32 support, but I'm checking the build at the moment). ] Patch bundle hash: c4d4c9a6e9ae19460d5eed6dcb454f7781802c83 -------------- next part -------------- Mon Jan 12 15:07:58 PST 2009 Don Stewart * Add check for -lrt to get the shm* functions. Subst. in buildinfo Mon Jan 12 15:47:17 PST 2009 Don Stewart * SharedMem.hsc wasn't including HsUnixConfig.h, so no #defines were propagating New patches: [Add check for -lrt to get the shm* functions. Subst. in buildinfo Don Stewart **20090112230758] hunk ./configure.ac 30 AC_CHECK_FUNCS([nanosleep]) AC_CHECK_FUNCS([ptsname]) AC_CHECK_FUNCS([setitimer]) + +# Avoid adding rt if absent or unneeded +AC_CHECK_LIB(rt, shm_open, [EXTRA_LIBS="$EXTRA_LIBS rt" CFLAGS="$CFLAGS -lrt"]) + +# needs -lrt on linux AC_CHECK_FUNCS([shm_open shm_unlink]) FP_CHECK_CONSTS([SIGABRT SIGALRM SIGBUS SIGCHLD SIGCONT SIGFPE SIGHUP SIGILL SIGINT SIGKILL SIGPIPE SIGQUIT SIGSEGV SIGSTOP SIGTERM SIGTSTP SIGTTIN SIGTTOU SIGUSR1 SIGUSR2 SIGPOLL SIGPROF SIGSYS SIGTRAP SIGURG SIGVTALRM SIGXCPU SIGXFSZ SIG_BLOCK SIG_SETMASK SIG_UNBLOCK], [ [SharedMem.hsc wasn't including HsUnixConfig.h, so no #defines were propagating Don Stewart **20090112234717] hunk ./System/Posix/SharedMem.hsc 26 #include #include +#include "HsUnix.h" + import System.Posix.Types import System.Posix.Error import Foreign.C Context: [Avoid using IOError internals Ian Lynagh **20090104173221] [fix pthread linkage problem for openbsd Matthias Kilian **20081129000638 This should make my openbsd build slave happy when SplitObjs=NO. May be useful for other BSDs and even Linux, regardless wether you need -pthread or -lpthread. Time will tell... ] [catch up with exception changes Simon Marlow **20080927135428] [Bump version number to 2.3.1.0 Ian Lynagh **20080920160248] [TAG 6.10 branch has been forked Ian Lynagh **20080919123439] [follow library changes Ian Lynagh **20080903223616] [add category field Ross Paterson **20080824003014] [We now depend on concurrent (split off from base) Ian Lynagh **20080824135158] [Fix the build when CONST_SIGPOLL == -1 Ian Lynagh **20080823160346 We were defining, but not using, sigPOLL ] [Fix warnings in the unix package Ian Lynagh **20080821120138] [move some stuff here from System.Directory, now the dependencies are reversed Simon Marlow **20080821144754] [Follow extensible exceptions changes Ian Lynagh **20080623193152] [Allow C's unsetenv to return either void or int Ian Lynagh **20080703190603 Fixes, and patch from donn in, trac #2352. ] [Avoid using deprecated flags Ian Lynagh **20080616145425] [move __hscore_{mkstemp,getrlimit,setrlimit} here from base Ross Paterson **20080615224248] [TAG 2008-05-28 Ian Lynagh **20080528004441] [Add a test for #2038 (resourceLimit) Ian Lynagh **20080520163012] [Use the C wrappers for [gs]etrlimit Ian Lynagh **20080520162048 This is for #2038: macros are used in the Linux .h includes to redirect to a 64-bit version when large file support is enabled. ] [Use the __hscore_mkstemp wrapper from the base package Ian Lynagh **20080520162039 This is for #2038: macros are used in the Linux .h includes to redirect to a 64-bit version when large file support is enabled. ] [small doc tweak Simon Marlow **20080508114348] [add AC_SYS_LARGEFILE check to configure.ac jeremy.shaw@linspireinc.com**20080213223619 As explained in this thread: http://www.haskell.org/pipermail/haskell-cafe/2008-February/039549.html getSymbolicLinkStatus (and possibly other functions) return completely bogus results. This is because hsc2hs returns the offsets for stat64, but the library is built such that it calls the 32 bit lstat call. I copied the AC_SYS_LARGEFILE from ghc's configure.ac. So, I believe the library should now properly autodetect whether your system has large file support and do the right thing more often. I suspect that this would still be buggy if ghc was built without large file support, but the library was built with it enabled. However, as long as AC_SYS_LARGEFILE returns the same results for 'ghc' and 'unix', things should be ok ? ] [Throw a proper exception if getUserEntryForName fails to find an entry Ian Lynagh **20080115020547 Fixes trac #2033. ] [Add a test getUserEntryForName for trac #1976 Ian Lynagh **20080115020540] [protect against concurrent access to the signal handlers (#1922) Simon Marlow **20071204110839 ] [Fix some haddock links Ian Lynagh **20071126184521] [Throw a proper exception if getGroupEntryForName fails to find an entry Ian Lynagh **20071110235805 We used to get *** Exception: getGroupEntryForName: failed (Success) Fixes trac #1655 ] [fix framework failures Simon Marlow **20071029114606] [Remove incorrect comment Ian Lynagh **20071014101756] [Specify build-type: Configure Duncan Coutts **20071018125127] [Bump version number Ian Lynagh **20071014101806] [Support for 57600 and 115200 baudrates pweaver@galois.com**20071016191631] [Also guard the foreign declaration of __hsunix(grant|unlock)pt by HAVE_PTSNAME Clemens Fruhwirth **20071016143846] [Add basic pseudoterminal support. Bryan O'Sullivan **20070925113330] [check for shm_open/shm_unlink (for archs like OpenBSD without them) Don Stewart **20070916025218] [Add more entries to boring file Ian Lynagh **20070913210721] [Add a boring file Ian Lynagh **20070913204658] [in pPrPr_disableITimers (who made up that name?) call the RTS to disable the timer Simon Marlow **20070912145647 Since we switched to using timer_create() in the RTS, this function has been failing to disables the timer interrupts. This turns out to be the cause of the random framework failures in the test suite. Invoking the RTS to turn off the timer signal is the right thing. ] [TAG ghc-6.8 branched 2007-09-03 Ian Lynagh **20070903155840] [Suppress some warnings Ian Lynagh **20070902194033] [Remove redundant include/Makefile Ian Lynagh **20070828205715] [add cross-referencing between posix and process modules ijones@syntaxpolice.org**20070819073930] [get the SIG constants for ourselves, rather than relying on HsBaseConfig.h Ross Paterson **20070819233142] [FIX BUILD on OS X: Check for setitimer Roman Leshchinskiy **20070814020033 Fix suggested by Ian Lynagh ] [Remove bits left over from the old build system Ian Lynagh **20070811135134] [Move System.Posix.Signals from base Ian Lynagh **20070729215617 Also adds System.Posix.Process.Internals in order to make the deps work out. ] [Move throwErrnoPath* functions to base:Foreign.C.Error Ian Lynagh **20070722002956] [GHC.Handle no longer exports openFd Ian Lynagh **20070722000926] [disable the getLoginName test, see #1487 Simon Marlow **20070703105224] [Don't do "< /dev/null" when running the user001 test Ian Lynagh **20070623205408 It can cause the test to fail. ] [--configure-option and --ghc-option are now provided by Cabal Ross Paterson **20070604115617] [Add support for named semaphores and shared memory objects Daniel Franke **20070503220003] [Remove Makefile and package.conf.in (used in the old build system) Ian Lynagh **20070524142637] [We now depend on process Ian Lynagh **20070523181544] [We now depend on directory Ian Lynagh **20070519160513] [add includes: field Simon Marlow **20070517095025] [Fix calling getAllUserEntries twice (trac #1279). Ian Lynagh **20070504104956 It used to return [] on all but the first call. Patch from an unidentified guest. ] [Make it more obvious that the forkprocess01 test is really working Ian Lynagh **20070418114542] [Follow Cabal changes in Setup.hs Ian Lynagh **20070418114510] [Handle sysconf(3) return value -1 when checking _SC_GETGR_R_SIZE_MAX and _SC_GETPW_R_SIZE_MAX. bjorn@bringert.net**20070416214837 sysconf(3) returns -1 on failure, but this was not handled when checking _SC_GETGR_R_SIZE_MAX and _SC_GETPW_R_SIZE_MAX in System.Posix.User. This made getUserEntryForID, getUserEntryForName, getGroupEntryForID and getGroupEntryForName fail on OS X 10.4.9 on i386. Just checking that unistd.h defines _SC_GETGR_R_SIZE_MAX and _SC_GETPW_R_SIZE_MAX as was done before does not guarantee that sysconf(3) will succeed. sysconf(3) failure is now handled by using the same default values as were already used when sysconf(3) is not available, or the parameter names are not defined. ] [Added tests/user001.hs which tests all the get* functions in System.Posix.User. bjorn@bringert.net**20070416220012 I added this since I noticed that getUserEntryForID, getUserEntryForName, getGroupEntryForID and getGroupEntryForName failed on OS X 10.4.9 on i386. ] [Fix -Wall warnings Ian Lynagh **20070411005028] [Add missing case in removePrefix Ian Lynagh **20070411002604] [parse (but don't pass on) options for ./configure Ian Lynagh **20070406153756] [make Setup suitable for building the libraries with GHC Ian Lynagh **20061112214741] [Don't use Fd/FD in foreign decls Ian Lynagh **20070404155930 Using CInt makes it much easier to verify that it is right, and we won't get caught out by possible newtype switches between CInt/Int. ] [Fix C/Haskell type mismatches Ian Lynagh **20070404003625] [Follow type changes in base Ian Lynagh **20070403195237 (of the dubiously exported c_access and c_fcntl_write) ] [fix cut-and-pasto in error message Simon Marlow **20070308134418] [add tests from GHC testsuite Simon Marlow **20070305145258] [export the file-type modes, so that createDevice can be used Simon Marlow **20070305113316] [Provide nanosleep if we have it, and use it to implement usleep Simon Marlow **20070302132818 Fixes #1156 ] [don't retry usleep() on EINTR (see #850/#1156) Simon Marlow **20070302114118] [expand docs for forkProcess Simon Marlow **20070301151220] [add C wrappers for lstat() and mknod(). Fixes #1086. Simon Marlow **20070226110311] [README about building from darcs Ross Paterson **20070218110201] [TAG 6.6 release Ian Lynagh **20061011124740] [fix haddock syntax Simon Marlow **20060908111858] [Derive Show, Read, and Eq for UserEntry and GroupEntry John Goerzen **20060831145022] [bump version to 2.0 Simon Marlow **20060831140257] [Fix compilation issues with new getgrent/getpwent code John Goerzen **20060830134517] [Added support for getpwent/getgrent John Goerzen **20060830132550] [Added some Haddock docs for UserEntry and GroupEntry John Goerzen **20060829185932] [Add missing field gr_passwd to GroupEntry John Goerzen **20060829185536] [Whitespace changes for better alignment in unpackUserEntry John Goerzen **20060829185300] [Added pw_passwd and pw_gecos fields to UserEntry structure John Goerzen **20060829185051 System.Posix.User was missing pw_gecos and pw_passwd in UserEntry. I have added them, so now the full struct passwd is represented. ] [includes -> install-includes Ross Paterson **20060829123744] [exclude Setup.hs from build Ross Paterson **20060824183535] [add boilerplate Setup.hs Ross Paterson **20060824115019] [Added more documentation to System.Posix.Files Johan Tibell **20060813102350] [fix markup (#854) Ross Paterson **20060820002322] [change test for buildability Ross Paterson **20060819144834 Checking for dlfcn.h instead of creat() should make the Cabal build fail more gracefully under MinGW. ] [document args to executeFile Simon Marlow **20060809104559] [fix bogosity in getEnvironmentPrim Simon Marlow **20060531144640] [Track the GHC source tree reoganisation Simon Marlow **20060407041758] [TAG Initial conversion from CVS complete John Goerzen **20060112154138] [[project @ 2005-11-10 13:00:55 by simonmar] simonmar**20051110130055 some Haddock docs, from Isaac Jones. ] [[project @ 2005-11-10 12:58:32 by simonmar] simonmar**20051110125832 Some docs for System.Posix, from Bj?rn Bringert ] [TAG cmm-merge2 Unknown tagger**20060112152636] [[project @ 2005-09-20 22:54:33 by ross] ross**20050920225433 make the unix package independent. ] [[project @ 2005-09-20 16:35:26 by ross] ross**20050920163526 move RTLD_* tests down to unix package ] [[project @ 2005-09-19 23:24:31 by ross] ross**20050919232431 For compilers other than MSVC and GCC, assume inline has the C99 semantics. ] [[project @ 2005-08-10 10:07:22 by simonmar] simonmar**20050810100722 Fix queryFdOption ] [[project @ 2005-08-04 02:09:36 by wolfgang] wolfgang**20050804020936 Check for RTLD_DEFAULT in dlfcn.h and use it if it is available. (On Mac OS X its value is -2, and using NULL instead does not work.) MERGE TO STABLE ] [[project @ 2005-07-21 12:54:33 by simonmar] simonmar**20050721125433 Hack Makefiles so that 'make distclean' works even if the tree has not been configured, or 'make distclean' has already been run. This is to solve problems caused by 'make distclean' removing files that it needs itself - previously we were arranging to remove certain files right at the end of cleaning, but this is fragile. So now we assume that e.g. the X11 library is always enabled when we're cleaning. ] [[project @ 2005-05-10 10:40:12 by simonmar] simonmar**20050510104012 PATH_MAX fixes from Thomas Schwinge. ] [TAG arity-anal-branch-point Unknown tagger**20060112152625] [TAG ghc-assoc-branch-point Unknown tagger**20060112152625] [[project @ 2005-03-23 14:34:21 by ross] ross**20050323143421 add license files for individual packages ] [TAG nhc98-1-18-release Unknown tagger**20060112152623] [[project @ 2005-03-08 16:22:05 by simonmar] simonmar**20050308162205 Undo previous commit: it breaks when RLIM_INFINITY is defined to an expression that CPP doesn't understand. ] [[project @ 2005-03-08 04:45:38 by wolfgang] wolfgang**20050308044538 Mac OS X: Kill HaskellSupport.framework. Instead, look for GMP.framework (a framework-version of libgmp), else look for a normal -lgmp as usual. The other part of HaskellSupport.framework, dlcompat, is no longer needed (as of Mac OS X 10.3, it's included in libSystem). It's enough to just use the normal configure tests for -ldl. MERGE TO STABLE ] [[project @ 2005-03-05 14:32:09 by panne] panne**20050305143209 Warning police (for platforms where all resource limits can be represented, i.e. RLIM_INFINITY == RLIM_SAVED_MAX == RLIM_SAVED_CUR) ] [[project @ 2005-03-02 16:39:57 by ross] ross**20050302163958 *Config.h files are in include/ (MERGE to STABLE) ] [[project @ 2005-03-02 14:46:16 by simonmar] simonmar**20050302144616 distcleaning of things generated by configure ] [[project @ 2005-02-24 09:58:27 by simonmar] simonmar**20050224095827 nDoc fixes from Sven Panne. Generally fixing of Haddock links, adding some signatures, and in some cases exporting type constructors that are mentioned in the types of exported identifiers. ] [[project @ 2005-02-18 18:30:40 by ross] ross**20050218183040 Rename package description fields as in InstalledPackageInfo: options-ghc -> ghc-options options-hugs -> hugs-options options-nhc -> nhc-options extra-libs -> extra-libraries ] [[project @ 2005-02-18 15:06:47 by simonmar] simonmar**20050218150647 Rename fields in InstalledPackageInfo for consistency with PackageDescription & buildInfo: extra-libs (extraLibraries) --> extra-libraries (extraLibraries) extra-cc-opts (extraCcOpts) --> cc-options (ccOptions) extra-ld-opts (extraLdOpts) --> ld-options (ldOptions) extra-hugs-opts (extraHugsOpts) --> hugs-options (hugsOptions) extra-frameworks (extraFrameworks) --> frameworks (frameworks) ] [[project @ 2005-02-11 01:55:58 by ross] ross**20050211015558 track syntax changes: * add License-File and Synopsis fields * rename Hidden-Fields as Other-Fields These files are used only by Hugs, but are also useful as examples. ] [[project @ 2005-02-07 12:03:44 by simonmar] simonmar**20050207120344 Doc for handleToFd and fdToHandle ] [TAG ghc-6-4-branch-point Unknown tagger**20060112152610] [[project @ 2005-01-28 13:36:36 by simonmar] simonmar**20050128133636 Catch up with updates to platform #defines. Generally: use _HOST_ rather than _TARGET_ (except in Cabal where we have to retain compatibility with previous GHC versions). ] [[project @ 2005-01-25 17:06:40 by ross] ross**20050125170640 add Cabal package descriptions ] [[project @ 2005-01-21 12:35:38 by simonmar] simonmar**20050121123538 update the haddock fields (this one somehow got missed) ] [[project @ 2005-01-20 14:22:28 by simonmar] simonmar**20050120142228 Fill in the haddock-interfaces and haddock-html fields in the package.conf files. To do this I had to make some changes: - haddock-interfaces requires the value of $(datadir). We can't just plug this in, because $(datadir) might change at install-time (eg. a Windows installer can be placed anywhere, as can a Unix binary .tar.gz distribution). The current trick is for the compiler to splice in the value of $libdir in package.conf at runtime. So we could extend this mechanism and tell the compiler the value of $datadir via a command-line option, but that seems ugly. On Windows, $datadir==$libdir, so we don't need any changes: package.conf still uses $libdir, and a Windows installation is independent of its absolute location. Even 'make install' on Windows should have this property. On Unix: - for 'make install' and in-place execution, we just use absolute paths in package.conf - for a binary dist, we generate a package.conf that refers to $libdir and $datadir, and splice in the values at install-time (distrib/Makefile-bin.in). - Also, I renamed $libdir to $topdir to more closely reflect its actual meaning. This is somewhat malicious in that it will flush out all those clients using $libdir when they really shouldn't be :-) ] [[project @ 2005-01-06 11:27:48 by ross] ross**20050106112748 c_ftruncate is now in System.Posix.Internals ] [TAG pluggable-1-branch-point Unknown tagger**20060112152603] [[project @ 2004-12-02 15:57:06 by ross] ross**20041202155706 Hugs only: replace the CBITS pragma (files relative to cbits) with CFILES (files relative to the root of the package). ] [[project @ 2004-11-26 16:22:12 by simonmar] simonmar**20041126162212 Further integration with the new package story. GHC now supports pretty much everything in the package proposal. - GHC now works in terms of PackageIds (-) rather than just package names. You can still specify package names without versions on the command line, as long as the name is unambiguous. - GHC understands hidden/exposed modules in a package, and will refuse to import a hidden module. Also, the hidden/eposed status of packages is taken into account. - I had to remove the old package syntax from ghc-pkg, backwards compatibility isn't really practical. - All the package.conf.in files have been rewritten in the new syntax, and contain a complete list of modules in the package. I've set all the versions to 1.0 for now - please check your package(s) and fix the version number & other info appropriately. - New options: -hide-package P sets the expose flag on package P to False -ignore-package P unregisters P for this compilation For comparison, -package P sets the expose flag on package P to True, and also causes P to be linked in eagerly. -package-name is no longer officially supported. Unofficially, it's a synonym for -ignore-package, which has more or less the same effect as -package-name used to. Note that a package may be hidden and yet still be linked into the program, by virtue of being a dependency of some other package. To completely remove a package from the compiler's internal database, use -ignore-package. The compiler will complain if any two packages in the transitive closure of exposed packages contain the same module. You *must* use -ignore-package P when compiling modules for package P, if package P (or an older version of P) is already registered. The compiler will helpfully complain if you don't. The fptools build system does this. - Note: the Cabal library won't work yet. It still thinks GHC uses the old package config syntax. Internal changes/cleanups: - The ModuleName type has gone away. Modules are now just (a newtype of) FastStrings, and don't contain any package information. All the package-related knowledge is in DynFlags, which is passed down to where it is needed. - DynFlags manipulation has been cleaned up somewhat: there are no global variables holding DynFlags any more, instead the DynFlags are passed around properly. - There are a few less global variables in GHC. Lots more are scheduled for removal. - -i is now a dynamic flag, as are all the package-related flags (but using them in {-# OPTIONS #-} is Officially Not Recommended). - make -j now appears to work under fptools/libraries/. Probably wouldn't take much to get it working for a whole build. ] [[project @ 2004-11-18 16:39:54 by stolz] stolz**20041118163954 Push down more feature-tests ] [[project @ 2004-11-12 17:08:58 by stolz] stolz**20041112170858 Fix FFI-funniness, cf. http://www.haskell.org/pipermail/glasgow-haskell-users/2002-February/003020.html Noticed by: George Russell (again) ] [[project @ 2004-11-12 14:56:13 by stolz] stolz**20041112145613 Fix previous commit: Don't handle Solaris2-flag _POSIX_PTHREAD_SEMANTICS in configure at all but simply #ifdef solaris2_TARGET_OS #define ... it in the header-file. ] [[project @ 2004-11-12 13:22:56 by stolz] stolz**20041112132256 More getpw*_r result checks ] [[project @ 2004-11-12 12:12:53 by stolz] stolz**20041112121253 Push some unixisms from toplvl into package: usleep, SunOS-handling, getpw* ] [[project @ 2004-11-05 14:59:33 by stolz] stolz**20041105145933 Fix getpwnam_r-handling: getpwnam_r returns (always?) 0, you have to check result* (pppw[0])! Truss-log from querying first "root", then "" on SunOS 5.9: <- libc:__posix_getpwnam_r() = 0 "root" -> libc:__posix_getpwnam_r(0xff1bf8a8, 0xff1bf460, 0xff1bf490, 0x400) <- libc:__posix_getpwnam_r() = 0 Yes, that's 0 in both cases. (I wasn't even able to elicit an ERANGE btw.) Reported by: Peter Simons ] [[project @ 2004-10-27 10:51:15 by simonmar] simonmar**20041027105115 Fix bug in forkProcess: we weren't wrapping the forked IO action in the default exception handler, so exitFailure wasn't working properly. ] [[project @ 2004-10-15 09:42:02 by simonmar] simonmar**20041015094202 - sleep, usleep: make thread-safe - add Haddock comments ] [[project @ 2004-10-09 07:51:07 by panne] panne**20041009075107 Unbreak Hugs by moving pPrPr_disableITimers and execvpe to System.Posix.Internals (base package) and use it from System.Posix.Process (unix package). ] [[project @ 2004-10-08 18:35:50 by panne] panne**20041008183550 Unbreak Hugs, 2nd try... ] [[project @ 2004-10-08 17:48:57 by panne] panne**20041008174857 Unbreak Hugs: execvpe.c has gone ] [[project @ 2004-10-08 12:04:49 by ross] ross**20041008120449 revert previous change, so now these includes don't define PACKAGE_* ] [[project @ 2004-10-08 08:42:53 by dons] dons**20041008084253 Tweak the PACKAGE_* #undefs in a couple of other places, too. ] [[project @ 2004-10-06 10:13:08 by ross] ross**20041006101308 make the evil PACKAGE_* hacks consistent ] [[project @ 2004-09-30 03:13:23 by dons] dons**20040930031323 Implement System.Posix.User.getUserEntryFor{ID,Name} on platforms without reentrant versions of getpw{uid,nam}. This includes all the BSDs. While I'm here, close getGroupEntryFor* "Result too large" bug on OpenBSD, mentioned last year: http://www.haskell.org/pipermail/glasgow-haskell-bugs/2003-September/003601.html grBufSize was too small, apparently. Thanks to Ian Lynagh for hint to do the locking. ] [[project @ 2004-09-29 15:50:54 by simonmar] simonmar**20040929155055 Process reorganisation: the System.Process library moves into base, and System.Cmd is re-implemented in terms of it. Thanks to Krasimir Angelov, we have a version of System.Process that doesn't rely on the unix or Win32 libraries. Normally using unix/Win32 would be the right thing, but since we want to implement System.Cmd on top of this, and GHC uses System.Cmd, we can't introduce a bunch of .hsc dependencies into GHC's bootstrap libraries. So, the new version is larger, but has fewer dependencies. I imagine it shouldn't be too hard to port to other compilers. ] [[project @ 2004-09-22 09:14:23 by panne] panne**20040922091423 As a temporary measure, use an ultra-evil sledgehammer method to silence the PACKAGE_FOO clashes. The correct way of doing this would be splitting up HsPACKAGE.h and ghcconfig.h into two parts each: One part would be generated by autoheader and would contain the defines which are needed during package build time only. The other part would contain all kinds of stuff which is needed for using the given package (no PACKAGE_FOO defines here). For an example of this, see the OpenAL package. As an additional benefit, this would keep the namespace much cleaner, because 2nd kind of headers is typically smaller. No time for the real thing currently, hope the current workaround works... ] [[project @ 2004-09-18 12:50:00 by panne] panne**20040918125000 Make autoupdate 2.52 happy, mainly by using the new formats of AC_INIT and AC_OUTPUT. This has the nice side effect that all "packages" have now a name, a version, a bug-report address, and a tar name, yielding better output with "configure --help=recursive". Nuked an unused AC_STRUCT_ST_BLKSIZE test on the way. ] [[project @ 2004-09-15 15:55:45 by stolz] stolz**20040915155546 Add System.Posix.Signals.Exts which re-exports S.P.Signals and adds the two signals SIGINFO on (*BSD) and SIGWINCH (most Unices) which are not in POSIX. You should use cpp to test if those are defined before using them. This is encouraged by not providing dummy-definitions on platforms which do not offer that particular flavour. ] [[project @ 2004-09-09 06:55:47 by panne] panne**20040909065547 Unified the comments in (almost) empty aclocal.m4 files ] [[project @ 2004-09-03 07:46:56 by ross] ross**20040903074656 add empty aclocal.m4's (so we don't need aclocal) ] [[project @ 2004-09-02 15:18:10 by ross] ross**20040902151810 devolve some library-specific configuration ] [[project @ 2004-08-19 11:15:51 by simonmar] simonmar**20040819111552 Add filenames to all errors where it makes sense. I've added System.Posix.Error with a new family of error-throwing functions, throwErrnoPath*. This seemed to make the most sense: they don't belong in Foreign.C.Error (C by itself has no notion of paths). Fixes: [ 954378 ] getFileStatus does not include the file name in IO-Error ] [[project @ 2004-08-13 13:29:11 by simonmar] simonmar**20040813132911 Changes required be merge of backend-hacking-branch. Mostly config.h ==> ghcconfig.h. ] [[project @ 2004-05-13 09:55:59 by stolz] stolz**20040513095559 Inverted logic would call dlerror() after a successful dlclose() and cause a segfault. Noticed by: abe.egnor At gmail.com ] [[project @ 2004-03-09 11:37:14 by simonmar] simonmar**20040309113714 change the foreign import of waitpid to "safe", so that we can use it in a non-blocking way with the threaded RTS. ] [[project @ 2004-02-19 16:29:28 by stolz] stolz**20040219162928 Remove redundant _POSIX_PTHREAD_SEMANTICS. It's defined on the command line and also set too late/in the wrong place (after including system prototypes), anyway. ] [[project @ 2004-02-05 11:46:00 by ross] ross**20040205114600 Hugs only: use the configure-set variable INLINE_ONLY instead of `extern inline' (which works for gcc but not C99 compilers). ] [[project @ 2003-12-15 16:57:30 by ross] ross**20031215165730 include dirent.h to avoid warnings when compiling System.Posix.Directory ] [[project @ 2003-12-05 10:20:25 by ross] ross**20031205102025 solaris_TARGET_OS -> solaris2_TARGET_OS (and tweak the #define while I'm here) Works for Hugs, still untested for GHC, but presumably needed for STABLE. ] [[project @ 2003-11-15 22:31:18 by panne] panne**20031115223118 Decouple packages a bit more again: The prologue of the combined index is now generated via shell magic from the package prologues. As a nice side effect, some autoconf magic is gone, so configure.ac is effectively empty now (but not for long... :-) ] [[project @ 2003-11-10 15:32:45 by simonmar] simonmar**20031110153245 Change the documentation title from "Haskell Core Libraries" to "Haskell Hierarchical Libraries". ] [[project @ 2003-10-27 11:58:28 by stolz] stolz**20031027115828 - fix typo in error message - a bit of manual CSE for fcntl-flags - use Data.Bits instead of brains - make (unexported) function names a bit more consistent ] [[project @ 2003-10-24 14:46:13 by sof] sof**20031024144613 drop cygwin #ifdef; not an issue with current versions. merge to stable ] [[project @ 2003-10-24 14:38:27 by sof] sof**20031024143827 code tidyup merge to stable ] [[project @ 2003-10-23 23:32:43 by sof] sof**20031023233243 fdRead: drop superfluous array copying merge to stable ] [[project @ 2003-10-18 00:35:26 by ross] ross**20031018003526 Hugs only: add handleToFd ] [[project @ 2003-10-17 16:48:44 by ross] ross**20031017164845 Hugs only: add most of the rest of System.Posix (I wonder why SIG_UNBLOCK and SIG_SETMASK are switched in HsBase.h) ] [[project @ 2003-10-01 10:57:44 by wolfgang] wolfgang**20031001105744 New implementation & changed type signature of forkProcess forkProcess now has the following type: forkProcess :: IO () -> IO ProcessID forkProcessAll has been removed as it is unimplementable in the threaded RTS. forkProcess using the old type (IO (Maybe ProcessID)) was impossible to implement correctly in the non-threaded RTS and very hard to implement in the threaded RTS. The new type signature allows a clean and simple implementation. ] [[project @ 2003-09-24 13:42:15 by simonmar] simonmar**20030924134215 No reason we can't support sys/mman.h: move it to the ToDo section. ] [[project @ 2003-09-22 10:57:45 by simonmar] simonmar**20030922105745 Untested fix for Solaris to get the right versions of getgrnam_r and friends. I'd appreciate it if someone with a Solaris build could test this. ] [[project @ 2003-09-19 09:27:35 by simonmar] simonmar**20030919092735 Kill mktemp: it causes link warnings whenever someone uses -package unix on Linux & FreeBSD at least, and is bogus anyway. mktemp is still used to implement mkstemp when !GLASGOW_HASKELL and !HUGS. Why is this? ] [[project @ 2003-09-16 13:45:02 by simonmar] simonmar**20030916134502 fileExist should not throw an exception if the file does not exist. ] [[project @ 2003-09-15 20:59:07 by dons] dons**20030915205907 #ifdef's for the _PC_SYNC_IO, _PC_ASYNC_IO, _PC_FILESIZEBITS, _PC_SYMLINK_MAX. These 4 symbols are not universal: FreeBSD and Linux and the only OS's that appear to have them at the moment. ] [[project @ 2003-09-12 13:05:20 by simonmar] simonmar**20030912130520 Implement pathconf()/fpathconf() wrappers. ] [TAG ghc-6-2-branch-point Unknown tagger**20060112152454] [[project @ 2003-08-04 14:08:27 by panne] panne**20030804140827 Export TerminalAttributes abstractly ] [[project @ 2003-08-04 13:26:12 by panne] panne**20030804132614 More import tweaking for Haddock ] [[project @ 2003-08-04 13:22:05 by panne] panne**20030804132205 Export Module (abstractly), otherwise the user is unable to write signatures involving this type. Improves Haddock hyperlinks, too. ] [TAG ghc-6-0-OpenGL-merge3 Unknown tagger**20060112152446] [[project @ 2003-07-22 09:55:07 by ross] ross**20030722095507 jiggle to make System.Posix.Directory work for Hugs ] [[project @ 2003-07-16 13:04:55 by ross] ross**20030716130455 Sendfile is gone ] [[project @ 2003-06-22 09:02:15 by wolfgang] wolfgang**20030622090215 Revert last commit (remove "network" dependency again), as it was already fixed in a different way and I forgot to update... :-( ] [[project @ 2003-06-21 09:14:51 by wolfgang] wolfgang**20030621091451 Add package "network" to the list of dependencies, as it is needed by Sendfile. Fixes a link error when starting "ghci -package unix". ] [[project @ 2003-06-19 10:47:25 by simonmar] simonmar**20030619104726 Remove Network.Sendfile at request of Volker Stolz. We currently have some build problems with it (it depends on both unix and network packages). It might come back at some point in the future. ] [[project @ 2003-06-10 12:07:40 by simonmar] simonmar**20030610120740 - Use the right fdToHandle - some minor -Wall cleaning ] [[project @ 2003-06-10 10:58:06 by simonmar] simonmar**20030610105806 Move Network.Sendfile into the unix package to fix the build. ] [[project @ 2003-06-06 12:49:00 by stolz] stolz**20030606124900 Move System.Sendfile to Network.Sendfile: - Linux can sendfile() to a fd, but BSD couldn't - sendfile() on Linux is probably now disabled on most builds because of the LARGEFILE issue => Change API to use type Socket ] [[project @ 2003-06-06 12:41:12 by stolz] stolz**20030606124112 Obsolete ] [[project @ 2003-06-06 10:45:43 by stolz] stolz**20030606104543 Haddock: Add link to 'handleToFd' ] [[project @ 2003-06-03 14:01:38 by simonmar] simonmar**20030603140138 Hook up System.Posix.Temp. ] [[project @ 2003-06-03 11:31:45 by stolz] stolz**20030603113145 waitpid() may return EINTR, so use throwErrnoifMinus1Retry ] [[project @ 2003-06-03 08:55:13 by reid] reid**20030603085513 cvs ignorance for splits and way=p ] [[project @ 2003-05-28 12:36:29 by stolz] stolz**20030528123629 Can't use sendfile() with LARGEFILES on Linux ] [[project @ 2003-05-28 12:01:50 by stolz] stolz**20030528120150 No longer pertinent ] [[project @ 2003-05-27 12:59:54 by stolz] stolz**20030527125954 /me slaps haddock with a large piece of trout. Someone please remind me of running 'make html' before committing. ] [[project @ 2003-05-27 12:54:18 by stolz] stolz**20030527125418 Throw in mktemp() as well, as the non-GHC/Hugs case was essentially that. Advantage: At least on FreeBSD the linker will print out a warning whenever you use mktemp(). ] [[project @ 2003-05-27 10:18:58 by ross] ross**20030527101858 Hugs only: use fdToHandle (like GHC) ] [[project @ 2003-05-27 10:18:16 by ross] ross**20030527101816 Hugs only: make fdToHandle available ] [[project @ 2003-05-27 08:59:21 by stolz] stolz**20030527085921 Return file name as well Suggested by: Martin Norb?ck ] [[project @ 2003-05-27 08:20:42 by stolz] stolz**20030527082042 Add mkstemp() wrapper, including (unsafe) fallback for non-GHCs (fdToHandle required). Suggested by: Martin Sj?gren ] [[project @ 2003-05-23 18:35:55 by stolz] stolz**20030523183555 Need flags here as well. ] [[project @ 2003-05-23 16:36:48 by ross] ross**20030523163648 fix type error ] [[project @ 2003-05-23 14:31:46 by stolz] stolz**20030523143146 No (un)setenv until SUSv3 (e.g. Solaris 2.9). (fallback untested) ] [[project @ 2003-05-21 16:02:44 by stolz] stolz**20030521160244 Solaris2 needs _POSIX_PTHREAD_SEMANTICS for the getpw*_r() prototypes. Make libraries/unix/Makefile use a new variable unix_SRC_HSC2HS_OPTS which we configure in mk/config.mk. ] [TAG ghc-6-0-branch-point Unknown tagger**20060112152412] [[project @ 2003-05-21 15:07:55 by simonmar] simonmar**20030521150755 Revert previous commit, I've fixed Haddock instead. ] [[project @ 2003-05-21 14:58:36 by simonmar] simonmar**20030521145836 Flatten the doc structure a bit. ] [[project @ 2003-05-19 18:24:25 by reid] reid**20030519182425 cvs ignorance is bliss ] [[project @ 2003-05-18 06:47:42 by stolz] stolz**20030518064742 - My fault, so take ownership - Strip unnecessary #include while here ] [[project @ 2003-05-17 00:11:30 by ross] ross**20030517001130 Rename per-package configuration files from $(PACKAGE).conf.* to package.conf.*, making them easier to find (since each package is in a separate directory anyway). ] [[project @ 2003-05-16 12:03:55 by stolz] stolz**20030516120355 Look for 'bracket' in the right place ] [[project @ 2003-05-16 10:14:23 by simonmar] simonmar**20030516101423 Now that we have auto packages, it makes sense to keep all the interfaces for hierarchical libraries in the same directory tree. So now, instead of putting interfaces for package P in $libdir/imports/P, we put them all in $libdir/imports. Interfaces for old non-auto non-hierarchical packages now go in $libdir/hslibs-imports/P for package P. ] [[project @ 2003-05-16 08:25:30 by simonmar] simonmar**20030516082530 Move dlfcn.h to the "supported" list. ] [[project @ 2003-05-16 06:41:25 by stolz] stolz**20030516064127 - move System.DL to System.Posix.DynamicLinker - take ownership There's a compiler warning when passing the 'const char*' result from dlerror() to peekCString (discarded qualifier). Does an FFI-expert know how to get rid of this warning? ] [[project @ 2003-05-15 13:35:12 by ross] ross**20030515133512 add the DL modules (or whatever they're called) to Hugs ] [[project @ 2003-05-12 13:19:49 by wolfgang] wolfgang**20030512131949 Add #ifdefs for RLIMIT_AS and RLIM_SAVED_*, which are not defined on Mac OS X. ] [[project @ 2003-05-08 16:00:20 by ross] ross**20030508160020 extra #include's ] [[project @ 2003-04-11 23:42:54 by ross] ross**20030411234254 list modules that don't yet work with Hugs. ] [[project @ 2003-04-11 23:37:03 by ross] ross**20030411233703 replace Word with CTcflag ] [[project @ 2003-04-11 10:17:13 by ross] ross**20030411101713 use System.Posix.Internals ] [[project @ 2003-04-11 10:11:23 by ross] ross**20030411101124 rename GHC.Posix as System.Posix.Internals ] [[project @ 2003-04-11 10:00:07 by ross] ross**20030411100007 move environ from C to Haskell ] [[project @ 2003-04-11 09:43:38 by ross] ross**20030411094338 add some standard #includes ] [TAG galois-hbm-head Unknown tagger**20060112152340] [[project @ 2003-03-26 12:35:34 by simonmar] simonmar**20030326123534 Add getrlimit()/setrlimit() suppport ] [[project @ 2003-03-26 12:34:53 by simonmar] simonmar**20030326123453 wibble: add a newline at the end of the file ] [TAG before-galois-hbm Unknown tagger**20060112152337] [[project @ 2003-03-17 07:52:02 by stolz] stolz**20030317075202 Do not export c_sendfile (might not exist) ] [[project @ 2003-03-16 15:07:37 by stolz] stolz**20030316150737 (Hopefully) Fix #ifdef'ed branch Noticed by: Kirsten Chevalier ] [[project @ 2003-03-09 20:19:28 by panne] panne**20030309201930 Fixed markup confusion ("" vs. '') ] [[project @ 2003-03-07 16:22:49 by stolz] stolz**20030307162249 - Change Handle to Fd, so it's everybodies own fault if they forget to call hDuplicate - Revert size/offset to Int as lowest common denominator - Add sendfileByName ] [[project @ 2003-03-06 14:23:09 by stolz] stolz**20030306142309 Monad->Control.Monad ] [[project @ 2003-03-06 08:33:16 by stolz] stolz**20030306083316 - Haddockify documentation for parameters - Fix 'case vs. if' braino ] [[project @ 2003-03-05 18:38:09 by stolz] stolz**20030305183809 Steal 'squirt' from Haskell Web Server as fallback ] [[project @ 2003-03-05 18:14:05 by stolz] stolz**20030305181405 Pick up Maybe & Monad from new libraries ] [[project @ 2003-03-03 01:51:58 by stolz] stolz**20030303015200 Import System/DL* ] [[project @ 2003-03-01 16:34:12 by stolz] stolz**20030301163412 s/getEnvVar/getEnv/ ] [[project @ 2003-02-28 16:46:49 by stolz] stolz**20030228164649 Update comments to reflect new module System.Posix.Env ] [[project @ 2003-02-28 16:09:16 by stolz] stolz**20030228160916 Add System.Posix.Env ] [[project @ 2003-02-28 12:44:54 by stolz] stolz**20030228124454 Fix 'nice': -1 is a permissible return value in a successful situation ] [[project @ 2003-02-28 12:34:45 by stolz] stolz**20030228123445 - Rename System.Posix.Process.forkProcess to forkProcessAll - Move GHC.Conc.forkProcess to System.Posix with type 'Maybe ProcessID' Prompted by: George Russel ] [[project @ 2003-02-27 15:46:57 by stolz] stolz**20030227154657 - Add documentation for fd{Read,Write} & createPipe - Unbreak setFdOption which didn't set any options at all ] [[project @ 2003-02-27 13:27:50 by stolz] stolz**20030227132750 Move fd{Read,Write} to new layout. Use of memcpy() should bring a large performance increase compared to the old version. ] [[project @ 2003-02-17 11:43:55 by simonmar] simonmar**20030217114355 Comment wibbles ] [TAG before-speceval_2 Unknown tagger**20060112152311] [[project @ 2003-01-17 17:01:14 by stolz] stolz**20030117170114 - Add sendfile-API for pumping out data via sendfile(2) Currently supported are Linux (tested) & FreeBSD (not tested yet), others will throw a runtime error until I get around to implement a fallback. ] [[project @ 2002-12-26 21:01:46 by panne] panne**20021226210146 Once again: Make Haddock happy. Running Haddock in addition to ghc (i.e. use 'make all html' instead of plain 'make') before a commit would be nice, especially as buglets like this break a 3 hour RPM build just before it can finish... :-( ] [[project @ 2002-12-26 17:52:35 by wolfgang] wolfgang**20021226175235 Mac OS X doesn't have the sysconfig constants _SC_GETPW_R_SIZE_MAX and _SC_GETGR_R_SIZE_MAX, so add a configure check ] [[project @ 2002-12-19 13:52:55 by simonmar] simonmar**20021219135255 Fill in some more bits in the new Unix library: specifically the contents of PosixTTY and PosixDB (now System.Posix.Terminal and System.Posix.User respectively). We're now about 95% complete w.r.t. the old posix library. I've identified the reminaing bits to do in System/Posix.hs. ] [[project @ 2002-12-18 16:29:26 by simonmar] simonmar**20021218162926 "Auto" packages. The big change here is that it is no longer necessary to explicitly say '-package X' on the command line if X is a package containing hierarchical Haskell modules. All packages marked "auto" contribute to the import path, so their modules are always available. At link time, the compiler knows which packages are actually used by the program, and it links in only those libraries needed. There's one exception: one-shot linking. If you link a program using ghc -o prog A.o B.o ... then you need to explicitly add -package flags for each package required (except base & haskell98) because the compiler has no information about the package dependencies in this case. Package configs have a new field: auto, which is either True or False. Non-auto packages must be mentioned on the command-line as usual. Non-auto packages are still required for: - non-hierarchical libraries (to avoid polluting the module namespace) - packages with no Haskell content - if you want more than one version of a package, or packages providing overlapping functionality where the user must decide which one to use. Doc changes to follow... ] [[project @ 2002-12-12 13:42:48 by ross] ross**20021212134248 Changes to the exception interface, as discussed on the libraries list. 1) Move bracket and bracket_ from GHC.Exception (and hence System.IO) to haskell98/IO.hs. These two should now never be used (except in all-H98 programs), and this will save users of the new libraries from having to hide them. Use the ones in Control.Exception instead. 2) Define type IOError = IOException -- was Exception leaving the type of Prelude.ioError as IOError -> IO a, but adding to Control.Exception throwIO :: Exception -> IO a The result is a type distinction between the variants of catch and try: Prelude.catch :: IO a -> (IOError -> IO a) -> IO a Control.Exception.catch :: IO a -> (Exception -> IO a) -> IO a System.IO.Error.try :: IO a -> IO (Either IOError a) Control.Exception.try :: IO a -> IO (Either Exception a) These are breaking changes: the first one affects only import lists, but the second will bite in the following situations: - using ioError on general Exceptions: use throwIO instead. - using throw on IOErrors: if in the IO monad, use ioError instead. Otherwise, use throw (IOException e), but why are you throwing IO exceptions outside of the IO monad? Minor changes: - System.IO.Error now exports catch and try - moved try from GHC.Exception to System.IO.Error, because it's portable and can be shared by Hugs. ] [[project @ 2002-11-18 08:37:35 by stolz] stolz**20021118083735 readlink(2) does not append a NUL character to buffer. Noticed by: John Meacham ] [[project @ 2002-10-11 14:25:25 by stolz] stolz**20021011142525 'usleep' nightmare: Sometimes return type is void, sometimes int. ] [[project @ 2002-10-08 08:03:02 by wolfgang] wolfgang**20021008080302 Make the new Posix bindings compile on Mac OS X. Most notable, Mac OS X lacks *) lchown *) SIGPOLL I don't know of a replacement of either, so they are just left out when they are not detected by configure. ] [[project @ 2002-10-05 22:35:45 by panne] panne**20021005223545 Warning police #14: Help gcc a bit with variables which are not obviously always used. ] [[project @ 2002-09-14 09:35:00 by panne] panne**20020914093500 4th attempt to get a working RPM, but again: Make Haddock happy. Is doing a "make html" that hard before committing...? :-] ] [[project @ 2002-09-13 09:12:12 by simonmar] simonmar**20020913091212 - #include to get at get/setpriority. - #include "config.h", and protect other includes according to the configure results. ] [[project @ 2002-09-12 16:38:21 by simonmar] simonmar**20020912163822 More POSIX bits... we're getting there. ] [[project @ 2002-09-10 20:54:33 by panne] panne**20020910205433 No prologue.txt, no -p... ] [[project @ 2002-09-06 14:34:15 by simonmar] simonmar**20020906143415 Partial rewrite of the POSIX library. The main purpose of this sweep is to remove the last dependencies of the compiler on hslibs. When I've committed the associated compiler changes, only the 'base' package will be required to bootstrap the compiler. Additionally to build GHCi, the 'readline' and 'unix' packages will be required. The new POSIX library lives mostly in libraries/unix, with a few bits required for compiler bootstrapping in libraries/base. The 'base' package is mostly free of hsc2hs code to make bootstrapping from HC files easier, but the 'unix' package will use hsc2hs liberally. The old POSIX library continues to provide more-or-less the same interface as before, although some of the types are more correct now (previously lots of POSIX types were just mapped to Int). The new interface is largely the same as the old, except that some new functionality from the latest POSIX spec has been added (eg. symbolic links). So far, the new POSIX library has signal support, directory/file operations and lots of stuff from unistd.h. The module names are: System.Posix The main dude, exports everything System.Posix.Types All the POSIX types, using the same naming scheme as Foreign.C.Types, Eg. CUid, COff, etc. Many of these types were previously exported by GHC.Posix. Additionally exports the "nicer" names used by the old POSIX library for compatibility (eg. ProcessID == CPid, FileMode == CMode, etc.) All reasonable instances are derived for these types. System.Posix.Signals Signal support, contains most of which was in PosixProcPrim before. The RTS interface to the signal handling support has been rationalised slightly. System.Posix.Directory Directory support, most were in PosixFiles before. System.Posix.Files File operations, most were in PosixFiles before. System.Posix.Unistd (for want of a better name) Miscellaneous bits that mostly come from the unistd.h header file. PosixProcEnv before. The rest of the library should pan out like so: System.Posix.IO System.Posix.Error (maybe) System.Posix.Process System.Posix.Terminal (I've no doubt broken Win32 support, but I'm checking the build at the moment). ] Patch bundle hash: c4d4c9a6e9ae19460d5eed6dcb454f7781802c83 From alexander.dunlap at gmail.com Tue Jan 13 00:36:20 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Tue Jan 13 00:27:35 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <20090111235612.GA9642@seas.upenn.edu> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> <20090111235612.GA9642@seas.upenn.edu> Message-ID: <57526e770901122136w4e2b3f08n9da359aa639a86dc@mail.gmail.com> On Sun, Jan 11, 2009 at 3:56 PM, Brent Yorgey wrote: >> P2. There should be no information loss, that is, keep the delimiters, >> keep the separators, keep the parts of the original list xs that satisfy >> a predicate p, do not lose information about the beginning and the end >> of the list relative to the first and last elements of the list >> respectively. The user of the function decides what to discard. >> >> P3. A split list should be unsplittable so as to recover the original >> list xs. (I made up the word unsplittable.) (P2 implies P3, but let us >> state this anyway.) > > I'm not sure I agree with this. The problem is that much (most?) of > the time, people looking for a split function want to discard > delimiters; for example, if you have a string like "foo;bar;baz" and > you want to split it into ["foo","bar","baz"]. In this case it's > really annoying to have to throw away the delimiters yourself, > especially if you just get back a list like > ["foo",";","bar",";","baz"] and have to decide which things are > delimiters and which aren't, with no help from the type system. But, > as you noted, throwing away information like this is bad from an > elegance/formal properties point of view. This is exactly why I > designed the Data.List.Split library as I did: the core internal > splitting function is information-preserving, and by using various > combinators the user can choose to throw away whatever information > they are not interested in. > > -Brent > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > My personal opinion here is that there should be no split function in Data.List. Brent has put together a very nice splitting package; if we want this to be more accessible, we should put it in the Haskell Platform or whatever "blessing" procedure is established. Putting the split functions back into Data.List after they've already been added to a comprehensive splitting library is just going to be arbitrary no matter which ones we choose. Regards, Alex From duncan.coutts at worc.ox.ac.uk Tue Jan 13 04:45:48 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 13 04:37:13 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <57526e770901122136w4e2b3f08n9da359aa639a86dc@mail.gmail.com> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> <20090111235612.GA9642@seas.upenn.edu> <57526e770901122136w4e2b3f08n9da359aa639a86dc@mail.gmail.com> Message-ID: <1231839948.28590.179.camel@localhost> On Mon, 2009-01-12 at 21:36 -0800, Alexander Dunlap wrote: > My personal opinion here is that there should be no split function in > Data.List. Brent has put together a very nice splitting package; if we > want this to be more accessible, we should put it in the Haskell > Platform or whatever "blessing" procedure is established. That is a possibility. > Putting the split functions back into Data.List after they've already > been added to a comprehensive splitting library is just going to be > arbitrary no matter which ones we choose. Not necessarily arbitrary. The Data.List collection is not some canonical orthogonal basis of all list functions, it's a collection of frequently used (and mostly orthogonal, composable etc) list functions. So it may be that by looking at how split functions are used in Haskell code in general that we can identify one or two that are both reasonably general and used reasonably frequently. On the other hand we may find that there are not! :-) Duncan From marlowsd at gmail.com Tue Jan 13 06:13:23 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jan 13 06:04:49 2009 Subject: Missing headers from SharedMem.hsc In-Reply-To: <20090112235142.GU3582@scytale.galois.com> References: <20090112235142.GU3582@scytale.galois.com> Message-ID: <496C7753.5040003@gmail.com> Don Stewart wrote: > It was also missing HsUnix.h, so the #defines weren't propagating > anyway. > > > Mon Jan 12 15:07:58 PST 2009 Don Stewart > * Add check for -lrt to get the shm* functions. Subst. in buildinfo > > Mon Jan 12 15:47:17 PST 2009 Don Stewart > * SharedMem.hsc wasn't including HsUnixConfig.h, so no #defines were propagating I can't apply these here: $ darcs apply ~/sharedmem.patch darcs: Cannot apply this patch bundle, since we're missing: Thu Nov 10 12:58:32 GMT 2005 simonmar * [project @ 2005-11-10 12:58:32 by simonmar] Some docs for System.Posix, from Bj?rn Bringert this looks like an encoding issue, since in the history I have: Thu Nov 10 12:58:32 GMT 2005 simonmar * [project @ 2005-11-10 12:58:32 by simonmar] Some docs for System.Posix, from Bj[_\f6_]rn Bringert I tried with darcs 2.2.0rc1 and 1.0.9, same result. Anyone know what's going on here? (for the darcs-users folks, the repo to apply to is http://darcs.haskell.org/packages/unix). Cheers, Simon -------------- next part -------------- Mon Jan 12 15:07:58 PST 2009 Don Stewart * Add check for -lrt to get the shm* functions. Subst. in buildinfo Mon Jan 12 15:47:17 PST 2009 Don Stewart * SharedMem.hsc wasn't including HsUnixConfig.h, so no #defines were propagating New patches: [Add check for -lrt to get the shm* functions. Subst. in buildinfo Don Stewart **20090112230758] hunk ./configure.ac 30 AC_CHECK_FUNCS([nanosleep]) AC_CHECK_FUNCS([ptsname]) AC_CHECK_FUNCS([setitimer]) + +# Avoid adding rt if absent or unneeded +AC_CHECK_LIB(rt, shm_open, [EXTRA_LIBS="$EXTRA_LIBS rt" CFLAGS="$CFLAGS -lrt"]) + +# needs -lrt on linux AC_CHECK_FUNCS([shm_open shm_unlink]) FP_CHECK_CONSTS([SIGABRT SIGALRM SIGBUS SIGCHLD SIGCONT SIGFPE SIGHUP SIGILL SIGINT SIGKILL SIGPIPE SIGQUIT SIGSEGV SIGSTOP SIGTERM SIGTSTP SIGTTIN SIGTTOU SIGUSR1 SIGUSR2 SIGPOLL SIGPROF SIGSYS SIGTRAP SIGURG SIGVTALRM SIGXCPU SIGXFSZ SIG_BLOCK SIG_SETMASK SIG_UNBLOCK], [ [SharedMem.hsc wasn't including HsUnixConfig.h, so no #defines were propagating Don Stewart **20090112234717] hunk ./System/Posix/SharedMem.hsc 26 #include #include +#include "HsUnix.h" + import System.Posix.Types import System.Posix.Error import Foreign.C Context: [Avoid using IOError internals Ian Lynagh **20090104173221] [fix pthread linkage problem for openbsd Matthias Kilian **20081129000638 This should make my openbsd build slave happy when SplitObjs=NO. May be useful for other BSDs and even Linux, regardless wether you need -pthread or -lpthread. Time will tell... ] [catch up with exception changes Simon Marlow **20080927135428] [Bump version number to 2.3.1.0 Ian Lynagh **20080920160248] [TAG 6.10 branch has been forked Ian Lynagh **20080919123439] [follow library changes Ian Lynagh **20080903223616] [add category field Ross Paterson **20080824003014] [We now depend on concurrent (split off from base) Ian Lynagh **20080824135158] [Fix the build when CONST_SIGPOLL == -1 Ian Lynagh **20080823160346 We were defining, but not using, sigPOLL ] [Fix warnings in the unix package Ian Lynagh **20080821120138] [move some stuff here from System.Directory, now the dependencies are reversed Simon Marlow **20080821144754] [Follow extensible exceptions changes Ian Lynagh **20080623193152] [Allow C's unsetenv to return either void or int Ian Lynagh **20080703190603 Fixes, and patch from donn in, trac #2352. ] [Avoid using deprecated flags Ian Lynagh **20080616145425] [move __hscore_{mkstemp,getrlimit,setrlimit} here from base Ross Paterson **20080615224248] [TAG 2008-05-28 Ian Lynagh **20080528004441] [Add a test for #2038 (resourceLimit) Ian Lynagh **20080520163012] [Use the C wrappers for [gs]etrlimit Ian Lynagh **20080520162048 This is for #2038: macros are used in the Linux .h includes to redirect to a 64-bit version when large file support is enabled. ] [Use the __hscore_mkstemp wrapper from the base package Ian Lynagh **20080520162039 This is for #2038: macros are used in the Linux .h includes to redirect to a 64-bit version when large file support is enabled. ] [small doc tweak Simon Marlow **20080508114348] [add AC_SYS_LARGEFILE check to configure.ac jeremy.shaw@linspireinc.com**20080213223619 As explained in this thread: http://www.haskell.org/pipermail/haskell-cafe/2008-February/039549.html getSymbolicLinkStatus (and possibly other functions) return completely bogus results. This is because hsc2hs returns the offsets for stat64, but the library is built such that it calls the 32 bit lstat call. I copied the AC_SYS_LARGEFILE from ghc's configure.ac. So, I believe the library should now properly autodetect whether your system has large file support and do the right thing more often. I suspect that this would still be buggy if ghc was built without large file support, but the library was built with it enabled. However, as long as AC_SYS_LARGEFILE returns the same results for 'ghc' and 'unix', things should be ok ? ] [Throw a proper exception if getUserEntryForName fails to find an entry Ian Lynagh **20080115020547 Fixes trac #2033. ] [Add a test getUserEntryForName for trac #1976 Ian Lynagh **20080115020540] [protect against concurrent access to the signal handlers (#1922) Simon Marlow **20071204110839 ] [Fix some haddock links Ian Lynagh **20071126184521] [Throw a proper exception if getGroupEntryForName fails to find an entry Ian Lynagh **20071110235805 We used to get *** Exception: getGroupEntryForName: failed (Success) Fixes trac #1655 ] [fix framework failures Simon Marlow **20071029114606] [Remove incorrect comment Ian Lynagh **20071014101756] [Specify build-type: Configure Duncan Coutts **20071018125127] [Bump version number Ian Lynagh **20071014101806] [Support for 57600 and 115200 baudrates pweaver@galois.com**20071016191631] [Also guard the foreign declaration of __hsunix(grant|unlock)pt by HAVE_PTSNAME Clemens Fruhwirth **20071016143846] [Add basic pseudoterminal support. Bryan O'Sullivan **20070925113330] [check for shm_open/shm_unlink (for archs like OpenBSD without them) Don Stewart **20070916025218] [Add more entries to boring file Ian Lynagh **20070913210721] [Add a boring file Ian Lynagh **20070913204658] [in pPrPr_disableITimers (who made up that name?) call the RTS to disable the timer Simon Marlow **20070912145647 Since we switched to using timer_create() in the RTS, this function has been failing to disables the timer interrupts. This turns out to be the cause of the random framework failures in the test suite. Invoking the RTS to turn off the timer signal is the right thing. ] [TAG ghc-6.8 branched 2007-09-03 Ian Lynagh **20070903155840] [Suppress some warnings Ian Lynagh **20070902194033] [Remove redundant include/Makefile Ian Lynagh **20070828205715] [add cross-referencing between posix and process modules ijones@syntaxpolice.org**20070819073930] [get the SIG constants for ourselves, rather than relying on HsBaseConfig.h Ross Paterson **20070819233142] [FIX BUILD on OS X: Check for setitimer Roman Leshchinskiy **20070814020033 Fix suggested by Ian Lynagh ] [Remove bits left over from the old build system Ian Lynagh **20070811135134] [Move System.Posix.Signals from base Ian Lynagh **20070729215617 Also adds System.Posix.Process.Internals in order to make the deps work out. ] [Move throwErrnoPath* functions to base:Foreign.C.Error Ian Lynagh **20070722002956] [GHC.Handle no longer exports openFd Ian Lynagh **20070722000926] [disable the getLoginName test, see #1487 Simon Marlow **20070703105224] [Don't do "< /dev/null" when running the user001 test Ian Lynagh **20070623205408 It can cause the test to fail. ] [--configure-option and --ghc-option are now provided by Cabal Ross Paterson **20070604115617] [Add support for named semaphores and shared memory objects Daniel Franke **20070503220003] [Remove Makefile and package.conf.in (used in the old build system) Ian Lynagh **20070524142637] [We now depend on process Ian Lynagh **20070523181544] [We now depend on directory Ian Lynagh **20070519160513] [add includes: field Simon Marlow **20070517095025] [Fix calling getAllUserEntries twice (trac #1279). Ian Lynagh **20070504104956 It used to return [] on all but the first call. Patch from an unidentified guest. ] [Make it more obvious that the forkprocess01 test is really working Ian Lynagh **20070418114542] [Follow Cabal changes in Setup.hs Ian Lynagh **20070418114510] [Handle sysconf(3) return value -1 when checking _SC_GETGR_R_SIZE_MAX and _SC_GETPW_R_SIZE_MAX. bjorn@bringert.net**20070416214837 sysconf(3) returns -1 on failure, but this was not handled when checking _SC_GETGR_R_SIZE_MAX and _SC_GETPW_R_SIZE_MAX in System.Posix.User. This made getUserEntryForID, getUserEntryForName, getGroupEntryForID and getGroupEntryForName fail on OS X 10.4.9 on i386. Just checking that unistd.h defines _SC_GETGR_R_SIZE_MAX and _SC_GETPW_R_SIZE_MAX as was done before does not guarantee that sysconf(3) will succeed. sysconf(3) failure is now handled by using the same default values as were already used when sysconf(3) is not available, or the parameter names are not defined. ] [Added tests/user001.hs which tests all the get* functions in System.Posix.User. bjorn@bringert.net**20070416220012 I added this since I noticed that getUserEntryForID, getUserEntryForName, getGroupEntryForID and getGroupEntryForName failed on OS X 10.4.9 on i386. ] [Fix -Wall warnings Ian Lynagh **20070411005028] [Add missing case in removePrefix Ian Lynagh **20070411002604] [parse (but don't pass on) options for ./configure Ian Lynagh **20070406153756] [make Setup suitable for building the libraries with GHC Ian Lynagh **20061112214741] [Don't use Fd/FD in foreign decls Ian Lynagh **20070404155930 Using CInt makes it much easier to verify that it is right, and we won't get caught out by possible newtype switches between CInt/Int. ] [Fix C/Haskell type mismatches Ian Lynagh **20070404003625] [Follow type changes in base Ian Lynagh **20070403195237 (of the dubiously exported c_access and c_fcntl_write) ] [fix cut-and-pasto in error message Simon Marlow **20070308134418] [add tests from GHC testsuite Simon Marlow **20070305145258] [export the file-type modes, so that createDevice can be used Simon Marlow **20070305113316] [Provide nanosleep if we have it, and use it to implement usleep Simon Marlow **20070302132818 Fixes #1156 ] [don't retry usleep() on EINTR (see #850/#1156) Simon Marlow **20070302114118] [expand docs for forkProcess Simon Marlow **20070301151220] [add C wrappers for lstat() and mknod(). Fixes #1086. Simon Marlow **20070226110311] [README about building from darcs Ross Paterson **20070218110201] [TAG 6.6 release Ian Lynagh **20061011124740] [fix haddock syntax Simon Marlow **20060908111858] [Derive Show, Read, and Eq for UserEntry and GroupEntry John Goerzen **20060831145022] [bump version to 2.0 Simon Marlow **20060831140257] [Fix compilation issues with new getgrent/getpwent code John Goerzen **20060830134517] [Added support for getpwent/getgrent John Goerzen **20060830132550] [Added some Haddock docs for UserEntry and GroupEntry John Goerzen **20060829185932] [Add missing field gr_passwd to GroupEntry John Goerzen **20060829185536] [Whitespace changes for better alignment in unpackUserEntry John Goerzen **20060829185300] [Added pw_passwd and pw_gecos fields to UserEntry structure John Goerzen **20060829185051 System.Posix.User was missing pw_gecos and pw_passwd in UserEntry. I have added them, so now the full struct passwd is represented. ] [includes -> install-includes Ross Paterson **20060829123744] [exclude Setup.hs from build Ross Paterson **20060824183535] [add boilerplate Setup.hs Ross Paterson **20060824115019] [Added more documentation to System.Posix.Files Johan Tibell **20060813102350] [fix markup (#854) Ross Paterson **20060820002322] [change test for buildability Ross Paterson **20060819144834 Checking for dlfcn.h instead of creat() should make the Cabal build fail more gracefully under MinGW. ] [document args to executeFile Simon Marlow **20060809104559] [fix bogosity in getEnvironmentPrim Simon Marlow **20060531144640] [Track the GHC source tree reoganisation Simon Marlow **20060407041758] [TAG Initial conversion from CVS complete John Goerzen **20060112154138] [[project @ 2005-11-10 13:00:55 by simonmar] simonmar**20051110130055 some Haddock docs, from Isaac Jones. ] [[project @ 2005-11-10 12:58:32 by simonmar] simonmar**20051110125832 Some docs for System.Posix, from Bj?rn Bringert ] [TAG cmm-merge2 Unknown tagger**20060112152636] [[project @ 2005-09-20 22:54:33 by ross] ross**20050920225433 make the unix package independent. ] [[project @ 2005-09-20 16:35:26 by ross] ross**20050920163526 move RTLD_* tests down to unix package ] [[project @ 2005-09-19 23:24:31 by ross] ross**20050919232431 For compilers other than MSVC and GCC, assume inline has the C99 semantics. ] [[project @ 2005-08-10 10:07:22 by simonmar] simonmar**20050810100722 Fix queryFdOption ] [[project @ 2005-08-04 02:09:36 by wolfgang] wolfgang**20050804020936 Check for RTLD_DEFAULT in dlfcn.h and use it if it is available. (On Mac OS X its value is -2, and using NULL instead does not work.) MERGE TO STABLE ] [[project @ 2005-07-21 12:54:33 by simonmar] simonmar**20050721125433 Hack Makefiles so that 'make distclean' works even if the tree has not been configured, or 'make distclean' has already been run. This is to solve problems caused by 'make distclean' removing files that it needs itself - previously we were arranging to remove certain files right at the end of cleaning, but this is fragile. So now we assume that e.g. the X11 library is always enabled when we're cleaning. ] [[project @ 2005-05-10 10:40:12 by simonmar] simonmar**20050510104012 PATH_MAX fixes from Thomas Schwinge. ] [TAG arity-anal-branch-point Unknown tagger**20060112152625] [TAG ghc-assoc-branch-point Unknown tagger**20060112152625] [[project @ 2005-03-23 14:34:21 by ross] ross**20050323143421 add license files for individual packages ] [TAG nhc98-1-18-release Unknown tagger**20060112152623] [[project @ 2005-03-08 16:22:05 by simonmar] simonmar**20050308162205 Undo previous commit: it breaks when RLIM_INFINITY is defined to an expression that CPP doesn't understand. ] [[project @ 2005-03-08 04:45:38 by wolfgang] wolfgang**20050308044538 Mac OS X: Kill HaskellSupport.framework. Instead, look for GMP.framework (a framework-version of libgmp), else look for a normal -lgmp as usual. The other part of HaskellSupport.framework, dlcompat, is no longer needed (as of Mac OS X 10.3, it's included in libSystem). It's enough to just use the normal configure tests for -ldl. MERGE TO STABLE ] [[project @ 2005-03-05 14:32:09 by panne] panne**20050305143209 Warning police (for platforms where all resource limits can be represented, i.e. RLIM_INFINITY == RLIM_SAVED_MAX == RLIM_SAVED_CUR) ] [[project @ 2005-03-02 16:39:57 by ross] ross**20050302163958 *Config.h files are in include/ (MERGE to STABLE) ] [[project @ 2005-03-02 14:46:16 by simonmar] simonmar**20050302144616 distcleaning of things generated by configure ] [[project @ 2005-02-24 09:58:27 by simonmar] simonmar**20050224095827 nDoc fixes from Sven Panne. Generally fixing of Haddock links, adding some signatures, and in some cases exporting type constructors that are mentioned in the types of exported identifiers. ] [[project @ 2005-02-18 18:30:40 by ross] ross**20050218183040 Rename package description fields as in InstalledPackageInfo: options-ghc -> ghc-options options-hugs -> hugs-options options-nhc -> nhc-options extra-libs -> extra-libraries ] [[project @ 2005-02-18 15:06:47 by simonmar] simonmar**20050218150647 Rename fields in InstalledPackageInfo for consistency with PackageDescription & buildInfo: extra-libs (extraLibraries) --> extra-libraries (extraLibraries) extra-cc-opts (extraCcOpts) --> cc-options (ccOptions) extra-ld-opts (extraLdOpts) --> ld-options (ldOptions) extra-hugs-opts (extraHugsOpts) --> hugs-options (hugsOptions) extra-frameworks (extraFrameworks) --> frameworks (frameworks) ] [[project @ 2005-02-11 01:55:58 by ross] ross**20050211015558 track syntax changes: * add License-File and Synopsis fields * rename Hidden-Fields as Other-Fields These files are used only by Hugs, but are also useful as examples. ] [[project @ 2005-02-07 12:03:44 by simonmar] simonmar**20050207120344 Doc for handleToFd and fdToHandle ] [TAG ghc-6-4-branch-point Unknown tagger**20060112152610] [[project @ 2005-01-28 13:36:36 by simonmar] simonmar**20050128133636 Catch up with updates to platform #defines. Generally: use _HOST_ rather than _TARGET_ (except in Cabal where we have to retain compatibility with previous GHC versions). ] [[project @ 2005-01-25 17:06:40 by ross] ross**20050125170640 add Cabal package descriptions ] [[project @ 2005-01-21 12:35:38 by simonmar] simonmar**20050121123538 update the haddock fields (this one somehow got missed) ] [[project @ 2005-01-20 14:22:28 by simonmar] simonmar**20050120142228 Fill in the haddock-interfaces and haddock-html fields in the package.conf files. To do this I had to make some changes: - haddock-interfaces requires the value of $(datadir). We can't just plug this in, because $(datadir) might change at install-time (eg. a Windows installer can be placed anywhere, as can a Unix binary .tar.gz distribution). The current trick is for the compiler to splice in the value of $libdir in package.conf at runtime. So we could extend this mechanism and tell the compiler the value of $datadir via a command-line option, but that seems ugly. On Windows, $datadir==$libdir, so we don't need any changes: package.conf still uses $libdir, and a Windows installation is independent of its absolute location. Even 'make install' on Windows should have this property. On Unix: - for 'make install' and in-place execution, we just use absolute paths in package.conf - for a binary dist, we generate a package.conf that refers to $libdir and $datadir, and splice in the values at install-time (distrib/Makefile-bin.in). - Also, I renamed $libdir to $topdir to more closely reflect its actual meaning. This is somewhat malicious in that it will flush out all those clients using $libdir when they really shouldn't be :-) ] [[project @ 2005-01-06 11:27:48 by ross] ross**20050106112748 c_ftruncate is now in System.Posix.Internals ] [TAG pluggable-1-branch-point Unknown tagger**20060112152603] [[project @ 2004-12-02 15:57:06 by ross] ross**20041202155706 Hugs only: replace the CBITS pragma (files relative to cbits) with CFILES (files relative to the root of the package). ] [[project @ 2004-11-26 16:22:12 by simonmar] simonmar**20041126162212 Further integration with the new package story. GHC now supports pretty much everything in the package proposal. - GHC now works in terms of PackageIds (-) rather than just package names. You can still specify package names without versions on the command line, as long as the name is unambiguous. - GHC understands hidden/exposed modules in a package, and will refuse to import a hidden module. Also, the hidden/eposed status of packages is taken into account. - I had to remove the old package syntax from ghc-pkg, backwards compatibility isn't really practical. - All the package.conf.in files have been rewritten in the new syntax, and contain a complete list of modules in the package. I've set all the versions to 1.0 for now - please check your package(s) and fix the version number & other info appropriately. - New options: -hide-package P sets the expose flag on package P to False -ignore-package P unregisters P for this compilation For comparison, -package P sets the expose flag on package P to True, and also causes P to be linked in eagerly. -package-name is no longer officially supported. Unofficially, it's a synonym for -ignore-package, which has more or less the same effect as -package-name used to. Note that a package may be hidden and yet still be linked into the program, by virtue of being a dependency of some other package. To completely remove a package from the compiler's internal database, use -ignore-package. The compiler will complain if any two packages in the transitive closure of exposed packages contain the same module. You *must* use -ignore-package P when compiling modules for package P, if package P (or an older version of P) is already registered. The compiler will helpfully complain if you don't. The fptools build system does this. - Note: the Cabal library won't work yet. It still thinks GHC uses the old package config syntax. Internal changes/cleanups: - The ModuleName type has gone away. Modules are now just (a newtype of) FastStrings, and don't contain any package information. All the package-related knowledge is in DynFlags, which is passed down to where it is needed. - DynFlags manipulation has been cleaned up somewhat: there are no global variables holding DynFlags any more, instead the DynFlags are passed around properly. - There are a few less global variables in GHC. Lots more are scheduled for removal. - -i is now a dynamic flag, as are all the package-related flags (but using them in {-# OPTIONS #-} is Officially Not Recommended). - make -j now appears to work under fptools/libraries/. Probably wouldn't take much to get it working for a whole build. ] [[project @ 2004-11-18 16:39:54 by stolz] stolz**20041118163954 Push down more feature-tests ] [[project @ 2004-11-12 17:08:58 by stolz] stolz**20041112170858 Fix FFI-funniness, cf. http://www.haskell.org/pipermail/glasgow-haskell-users/2002-February/003020.html Noticed by: George Russell (again) ] [[project @ 2004-11-12 14:56:13 by stolz] stolz**20041112145613 Fix previous commit: Don't handle Solaris2-flag _POSIX_PTHREAD_SEMANTICS in configure at all but simply #ifdef solaris2_TARGET_OS #define ... it in the header-file. ] [[project @ 2004-11-12 13:22:56 by stolz] stolz**20041112132256 More getpw*_r result checks ] [[project @ 2004-11-12 12:12:53 by stolz] stolz**20041112121253 Push some unixisms from toplvl into package: usleep, SunOS-handling, getpw* ] [[project @ 2004-11-05 14:59:33 by stolz] stolz**20041105145933 Fix getpwnam_r-handling: getpwnam_r returns (always?) 0, you have to check result* (pppw[0])! Truss-log from querying first "root", then "" on SunOS 5.9: <- libc:__posix_getpwnam_r() = 0 "root" -> libc:__posix_getpwnam_r(0xff1bf8a8, 0xff1bf460, 0xff1bf490, 0x400) <- libc:__posix_getpwnam_r() = 0 Yes, that's 0 in both cases. (I wasn't even able to elicit an ERANGE btw.) Reported by: Peter Simons ] [[project @ 2004-10-27 10:51:15 by simonmar] simonmar**20041027105115 Fix bug in forkProcess: we weren't wrapping the forked IO action in the default exception handler, so exitFailure wasn't working properly. ] [[project @ 2004-10-15 09:42:02 by simonmar] simonmar**20041015094202 - sleep, usleep: make thread-safe - add Haddock comments ] [[project @ 2004-10-09 07:51:07 by panne] panne**20041009075107 Unbreak Hugs by moving pPrPr_disableITimers and execvpe to System.Posix.Internals (base package) and use it from System.Posix.Process (unix package). ] [[project @ 2004-10-08 18:35:50 by panne] panne**20041008183550 Unbreak Hugs, 2nd try... ] [[project @ 2004-10-08 17:48:57 by panne] panne**20041008174857 Unbreak Hugs: execvpe.c has gone ] [[project @ 2004-10-08 12:04:49 by ross] ross**20041008120449 revert previous change, so now these includes don't define PACKAGE_* ] [[project @ 2004-10-08 08:42:53 by dons] dons**20041008084253 Tweak the PACKAGE_* #undefs in a couple of other places, too. ] [[project @ 2004-10-06 10:13:08 by ross] ross**20041006101308 make the evil PACKAGE_* hacks consistent ] [[project @ 2004-09-30 03:13:23 by dons] dons**20040930031323 Implement System.Posix.User.getUserEntryFor{ID,Name} on platforms without reentrant versions of getpw{uid,nam}. This includes all the BSDs. While I'm here, close getGroupEntryFor* "Result too large" bug on OpenBSD, mentioned last year: http://www.haskell.org/pipermail/glasgow-haskell-bugs/2003-September/003601.html grBufSize was too small, apparently. Thanks to Ian Lynagh for hint to do the locking. ] [[project @ 2004-09-29 15:50:54 by simonmar] simonmar**20040929155055 Process reorganisation: the System.Process library moves into base, and System.Cmd is re-implemented in terms of it. Thanks to Krasimir Angelov, we have a version of System.Process that doesn't rely on the unix or Win32 libraries. Normally using unix/Win32 would be the right thing, but since we want to implement System.Cmd on top of this, and GHC uses System.Cmd, we can't introduce a bunch of .hsc dependencies into GHC's bootstrap libraries. So, the new version is larger, but has fewer dependencies. I imagine it shouldn't be too hard to port to other compilers. ] [[project @ 2004-09-22 09:14:23 by panne] panne**20040922091423 As a temporary measure, use an ultra-evil sledgehammer method to silence the PACKAGE_FOO clashes. The correct way of doing this would be splitting up HsPACKAGE.h and ghcconfig.h into two parts each: One part would be generated by autoheader and would contain the defines which are needed during package build time only. The other part would contain all kinds of stuff which is needed for using the given package (no PACKAGE_FOO defines here). For an example of this, see the OpenAL package. As an additional benefit, this would keep the namespace much cleaner, because 2nd kind of headers is typically smaller. No time for the real thing currently, hope the current workaround works... ] [[project @ 2004-09-18 12:50:00 by panne] panne**20040918125000 Make autoupdate 2.52 happy, mainly by using the new formats of AC_INIT and AC_OUTPUT. This has the nice side effect that all "packages" have now a name, a version, a bug-report address, and a tar name, yielding better output with "configure --help=recursive". Nuked an unused AC_STRUCT_ST_BLKSIZE test on the way. ] [[project @ 2004-09-15 15:55:45 by stolz] stolz**20040915155546 Add System.Posix.Signals.Exts which re-exports S.P.Signals and adds the two signals SIGINFO on (*BSD) and SIGWINCH (most Unices) which are not in POSIX. You should use cpp to test if those are defined before using them. This is encouraged by not providing dummy-definitions on platforms which do not offer that particular flavour. ] [[project @ 2004-09-09 06:55:47 by panne] panne**20040909065547 Unified the comments in (almost) empty aclocal.m4 files ] [[project @ 2004-09-03 07:46:56 by ross] ross**20040903074656 add empty aclocal.m4's (so we don't need aclocal) ] [[project @ 2004-09-02 15:18:10 by ross] ross**20040902151810 devolve some library-specific configuration ] [[project @ 2004-08-19 11:15:51 by simonmar] simonmar**20040819111552 Add filenames to all errors where it makes sense. I've added System.Posix.Error with a new family of error-throwing functions, throwErrnoPath*. This seemed to make the most sense: they don't belong in Foreign.C.Error (C by itself has no notion of paths). Fixes: [ 954378 ] getFileStatus does not include the file name in IO-Error ] [[project @ 2004-08-13 13:29:11 by simonmar] simonmar**20040813132911 Changes required be merge of backend-hacking-branch. Mostly config.h ==> ghcconfig.h. ] [[project @ 2004-05-13 09:55:59 by stolz] stolz**20040513095559 Inverted logic would call dlerror() after a successful dlclose() and cause a segfault. Noticed by: abe.egnor At gmail.com ] [[project @ 2004-03-09 11:37:14 by simonmar] simonmar**20040309113714 change the foreign import of waitpid to "safe", so that we can use it in a non-blocking way with the threaded RTS. ] [[project @ 2004-02-19 16:29:28 by stolz] stolz**20040219162928 Remove redundant _POSIX_PTHREAD_SEMANTICS. It's defined on the command line and also set too late/in the wrong place (after including system prototypes), anyway. ] [[project @ 2004-02-05 11:46:00 by ross] ross**20040205114600 Hugs only: use the configure-set variable INLINE_ONLY instead of `extern inline' (which works for gcc but not C99 compilers). ] [[project @ 2003-12-15 16:57:30 by ross] ross**20031215165730 include dirent.h to avoid warnings when compiling System.Posix.Directory ] [[project @ 2003-12-05 10:20:25 by ross] ross**20031205102025 solaris_TARGET_OS -> solaris2_TARGET_OS (and tweak the #define while I'm here) Works for Hugs, still untested for GHC, but presumably needed for STABLE. ] [[project @ 2003-11-15 22:31:18 by panne] panne**20031115223118 Decouple packages a bit more again: The prologue of the combined index is now generated via shell magic from the package prologues. As a nice side effect, some autoconf magic is gone, so configure.ac is effectively empty now (but not for long... :-) ] [[project @ 2003-11-10 15:32:45 by simonmar] simonmar**20031110153245 Change the documentation title from "Haskell Core Libraries" to "Haskell Hierarchical Libraries". ] [[project @ 2003-10-27 11:58:28 by stolz] stolz**20031027115828 - fix typo in error message - a bit of manual CSE for fcntl-flags - use Data.Bits instead of brains - make (unexported) function names a bit more consistent ] [[project @ 2003-10-24 14:46:13 by sof] sof**20031024144613 drop cygwin #ifdef; not an issue with current versions. merge to stable ] [[project @ 2003-10-24 14:38:27 by sof] sof**20031024143827 code tidyup merge to stable ] [[project @ 2003-10-23 23:32:43 by sof] sof**20031023233243 fdRead: drop superfluous array copying merge to stable ] [[project @ 2003-10-18 00:35:26 by ross] ross**20031018003526 Hugs only: add handleToFd ] [[project @ 2003-10-17 16:48:44 by ross] ross**20031017164845 Hugs only: add most of the rest of System.Posix (I wonder why SIG_UNBLOCK and SIG_SETMASK are switched in HsBase.h) ] [[project @ 2003-10-01 10:57:44 by wolfgang] wolfgang**20031001105744 New implementation & changed type signature of forkProcess forkProcess now has the following type: forkProcess :: IO () -> IO ProcessID forkProcessAll has been removed as it is unimplementable in the threaded RTS. forkProcess using the old type (IO (Maybe ProcessID)) was impossible to implement correctly in the non-threaded RTS and very hard to implement in the threaded RTS. The new type signature allows a clean and simple implementation. ] [[project @ 2003-09-24 13:42:15 by simonmar] simonmar**20030924134215 No reason we can't support sys/mman.h: move it to the ToDo section. ] [[project @ 2003-09-22 10:57:45 by simonmar] simonmar**20030922105745 Untested fix for Solaris to get the right versions of getgrnam_r and friends. I'd appreciate it if someone with a Solaris build could test this. ] [[project @ 2003-09-19 09:27:35 by simonmar] simonmar**20030919092735 Kill mktemp: it causes link warnings whenever someone uses -package unix on Linux & FreeBSD at least, and is bogus anyway. mktemp is still used to implement mkstemp when !GLASGOW_HASKELL and !HUGS. Why is this? ] [[project @ 2003-09-16 13:45:02 by simonmar] simonmar**20030916134502 fileExist should not throw an exception if the file does not exist. ] [[project @ 2003-09-15 20:59:07 by dons] dons**20030915205907 #ifdef's for the _PC_SYNC_IO, _PC_ASYNC_IO, _PC_FILESIZEBITS, _PC_SYMLINK_MAX. These 4 symbols are not universal: FreeBSD and Linux and the only OS's that appear to have them at the moment. ] [[project @ 2003-09-12 13:05:20 by simonmar] simonmar**20030912130520 Implement pathconf()/fpathconf() wrappers. ] [TAG ghc-6-2-branch-point Unknown tagger**20060112152454] [[project @ 2003-08-04 14:08:27 by panne] panne**20030804140827 Export TerminalAttributes abstractly ] [[project @ 2003-08-04 13:26:12 by panne] panne**20030804132614 More import tweaking for Haddock ] [[project @ 2003-08-04 13:22:05 by panne] panne**20030804132205 Export Module (abstractly), otherwise the user is unable to write signatures involving this type. Improves Haddock hyperlinks, too. ] [TAG ghc-6-0-OpenGL-merge3 Unknown tagger**20060112152446] [[project @ 2003-07-22 09:55:07 by ross] ross**20030722095507 jiggle to make System.Posix.Directory work for Hugs ] [[project @ 2003-07-16 13:04:55 by ross] ross**20030716130455 Sendfile is gone ] [[project @ 2003-06-22 09:02:15 by wolfgang] wolfgang**20030622090215 Revert last commit (remove "network" dependency again), as it was already fixed in a different way and I forgot to update... :-( ] [[project @ 2003-06-21 09:14:51 by wolfgang] wolfgang**20030621091451 Add package "network" to the list of dependencies, as it is needed by Sendfile. Fixes a link error when starting "ghci -package unix". ] [[project @ 2003-06-19 10:47:25 by simonmar] simonmar**20030619104726 Remove Network.Sendfile at request of Volker Stolz. We currently have some build problems with it (it depends on both unix and network packages). It might come back at some point in the future. ] [[project @ 2003-06-10 12:07:40 by simonmar] simonmar**20030610120740 - Use the right fdToHandle - some minor -Wall cleaning ] [[project @ 2003-06-10 10:58:06 by simonmar] simonmar**20030610105806 Move Network.Sendfile into the unix package to fix the build. ] [[project @ 2003-06-06 12:49:00 by stolz] stolz**20030606124900 Move System.Sendfile to Network.Sendfile: - Linux can sendfile() to a fd, but BSD couldn't - sendfile() on Linux is probably now disabled on most builds because of the LARGEFILE issue => Change API to use type Socket ] [[project @ 2003-06-06 12:41:12 by stolz] stolz**20030606124112 Obsolete ] [[project @ 2003-06-06 10:45:43 by stolz] stolz**20030606104543 Haddock: Add link to 'handleToFd' ] [[project @ 2003-06-03 14:01:38 by simonmar] simonmar**20030603140138 Hook up System.Posix.Temp. ] [[project @ 2003-06-03 11:31:45 by stolz] stolz**20030603113145 waitpid() may return EINTR, so use throwErrnoifMinus1Retry ] [[project @ 2003-06-03 08:55:13 by reid] reid**20030603085513 cvs ignorance for splits and way=p ] [[project @ 2003-05-28 12:36:29 by stolz] stolz**20030528123629 Can't use sendfile() with LARGEFILES on Linux ] [[project @ 2003-05-28 12:01:50 by stolz] stolz**20030528120150 No longer pertinent ] [[project @ 2003-05-27 12:59:54 by stolz] stolz**20030527125954 /me slaps haddock with a large piece of trout. Someone please remind me of running 'make html' before committing. ] [[project @ 2003-05-27 12:54:18 by stolz] stolz**20030527125418 Throw in mktemp() as well, as the non-GHC/Hugs case was essentially that. Advantage: At least on FreeBSD the linker will print out a warning whenever you use mktemp(). ] [[project @ 2003-05-27 10:18:58 by ross] ross**20030527101858 Hugs only: use fdToHandle (like GHC) ] [[project @ 2003-05-27 10:18:16 by ross] ross**20030527101816 Hugs only: make fdToHandle available ] [[project @ 2003-05-27 08:59:21 by stolz] stolz**20030527085921 Return file name as well Suggested by: Martin Norb?ck ] [[project @ 2003-05-27 08:20:42 by stolz] stolz**20030527082042 Add mkstemp() wrapper, including (unsafe) fallback for non-GHCs (fdToHandle required). Suggested by: Martin Sj?gren ] [[project @ 2003-05-23 18:35:55 by stolz] stolz**20030523183555 Need flags here as well. ] [[project @ 2003-05-23 16:36:48 by ross] ross**20030523163648 fix type error ] [[project @ 2003-05-23 14:31:46 by stolz] stolz**20030523143146 No (un)setenv until SUSv3 (e.g. Solaris 2.9). (fallback untested) ] [[project @ 2003-05-21 16:02:44 by stolz] stolz**20030521160244 Solaris2 needs _POSIX_PTHREAD_SEMANTICS for the getpw*_r() prototypes. Make libraries/unix/Makefile use a new variable unix_SRC_HSC2HS_OPTS which we configure in mk/config.mk. ] [TAG ghc-6-0-branch-point Unknown tagger**20060112152412] [[project @ 2003-05-21 15:07:55 by simonmar] simonmar**20030521150755 Revert previous commit, I've fixed Haddock instead. ] [[project @ 2003-05-21 14:58:36 by simonmar] simonmar**20030521145836 Flatten the doc structure a bit. ] [[project @ 2003-05-19 18:24:25 by reid] reid**20030519182425 cvs ignorance is bliss ] [[project @ 2003-05-18 06:47:42 by stolz] stolz**20030518064742 - My fault, so take ownership - Strip unnecessary #include while here ] [[project @ 2003-05-17 00:11:30 by ross] ross**20030517001130 Rename per-package configuration files from $(PACKAGE).conf.* to package.conf.*, making them easier to find (since each package is in a separate directory anyway). ] [[project @ 2003-05-16 12:03:55 by stolz] stolz**20030516120355 Look for 'bracket' in the right place ] [[project @ 2003-05-16 10:14:23 by simonmar] simonmar**20030516101423 Now that we have auto packages, it makes sense to keep all the interfaces for hierarchical libraries in the same directory tree. So now, instead of putting interfaces for package P in $libdir/imports/P, we put them all in $libdir/imports. Interfaces for old non-auto non-hierarchical packages now go in $libdir/hslibs-imports/P for package P. ] [[project @ 2003-05-16 08:25:30 by simonmar] simonmar**20030516082530 Move dlfcn.h to the "supported" list. ] [[project @ 2003-05-16 06:41:25 by stolz] stolz**20030516064127 - move System.DL to System.Posix.DynamicLinker - take ownership There's a compiler warning when passing the 'const char*' result from dlerror() to peekCString (discarded qualifier). Does an FFI-expert know how to get rid of this warning? ] [[project @ 2003-05-15 13:35:12 by ross] ross**20030515133512 add the DL modules (or whatever they're called) to Hugs ] [[project @ 2003-05-12 13:19:49 by wolfgang] wolfgang**20030512131949 Add #ifdefs for RLIMIT_AS and RLIM_SAVED_*, which are not defined on Mac OS X. ] [[project @ 2003-05-08 16:00:20 by ross] ross**20030508160020 extra #include's ] [[project @ 2003-04-11 23:42:54 by ross] ross**20030411234254 list modules that don't yet work with Hugs. ] [[project @ 2003-04-11 23:37:03 by ross] ross**20030411233703 replace Word with CTcflag ] [[project @ 2003-04-11 10:17:13 by ross] ross**20030411101713 use System.Posix.Internals ] [[project @ 2003-04-11 10:11:23 by ross] ross**20030411101124 rename GHC.Posix as System.Posix.Internals ] [[project @ 2003-04-11 10:00:07 by ross] ross**20030411100007 move environ from C to Haskell ] [[project @ 2003-04-11 09:43:38 by ross] ross**20030411094338 add some standard #includes ] [TAG galois-hbm-head Unknown tagger**20060112152340] [[project @ 2003-03-26 12:35:34 by simonmar] simonmar**20030326123534 Add getrlimit()/setrlimit() suppport ] [[project @ 2003-03-26 12:34:53 by simonmar] simonmar**20030326123453 wibble: add a newline at the end of the file ] [TAG before-galois-hbm Unknown tagger**20060112152337] [[project @ 2003-03-17 07:52:02 by stolz] stolz**20030317075202 Do not export c_sendfile (might not exist) ] [[project @ 2003-03-16 15:07:37 by stolz] stolz**20030316150737 (Hopefully) Fix #ifdef'ed branch Noticed by: Kirsten Chevalier ] [[project @ 2003-03-09 20:19:28 by panne] panne**20030309201930 Fixed markup confusion ("" vs. '') ] [[project @ 2003-03-07 16:22:49 by stolz] stolz**20030307162249 - Change Handle to Fd, so it's everybodies own fault if they forget to call hDuplicate - Revert size/offset to Int as lowest common denominator - Add sendfileByName ] [[project @ 2003-03-06 14:23:09 by stolz] stolz**20030306142309 Monad->Control.Monad ] [[project @ 2003-03-06 08:33:16 by stolz] stolz**20030306083316 - Haddockify documentation for parameters - Fix 'case vs. if' braino ] [[project @ 2003-03-05 18:38:09 by stolz] stolz**20030305183809 Steal 'squirt' from Haskell Web Server as fallback ] [[project @ 2003-03-05 18:14:05 by stolz] stolz**20030305181405 Pick up Maybe & Monad from new libraries ] [[project @ 2003-03-03 01:51:58 by stolz] stolz**20030303015200 Import System/DL* ] [[project @ 2003-03-01 16:34:12 by stolz] stolz**20030301163412 s/getEnvVar/getEnv/ ] [[project @ 2003-02-28 16:46:49 by stolz] stolz**20030228164649 Update comments to reflect new module System.Posix.Env ] [[project @ 2003-02-28 16:09:16 by stolz] stolz**20030228160916 Add System.Posix.Env ] [[project @ 2003-02-28 12:44:54 by stolz] stolz**20030228124454 Fix 'nice': -1 is a permissible return value in a successful situation ] [[project @ 2003-02-28 12:34:45 by stolz] stolz**20030228123445 - Rename System.Posix.Process.forkProcess to forkProcessAll - Move GHC.Conc.forkProcess to System.Posix with type 'Maybe ProcessID' Prompted by: George Russel ] [[project @ 2003-02-27 15:46:57 by stolz] stolz**20030227154657 - Add documentation for fd{Read,Write} & createPipe - Unbreak setFdOption which didn't set any options at all ] [[project @ 2003-02-27 13:27:50 by stolz] stolz**20030227132750 Move fd{Read,Write} to new layout. Use of memcpy() should bring a large performance increase compared to the old version. ] [[project @ 2003-02-17 11:43:55 by simonmar] simonmar**20030217114355 Comment wibbles ] [TAG before-speceval_2 Unknown tagger**20060112152311] [[project @ 2003-01-17 17:01:14 by stolz] stolz**20030117170114 - Add sendfile-API for pumping out data via sendfile(2) Currently supported are Linux (tested) & FreeBSD (not tested yet), others will throw a runtime error until I get around to implement a fallback. ] [[project @ 2002-12-26 21:01:46 by panne] panne**20021226210146 Once again: Make Haddock happy. Running Haddock in addition to ghc (i.e. use 'make all html' instead of plain 'make') before a commit would be nice, especially as buglets like this break a 3 hour RPM build just before it can finish... :-( ] [[project @ 2002-12-26 17:52:35 by wolfgang] wolfgang**20021226175235 Mac OS X doesn't have the sysconfig constants _SC_GETPW_R_SIZE_MAX and _SC_GETGR_R_SIZE_MAX, so add a configure check ] [[project @ 2002-12-19 13:52:55 by simonmar] simonmar**20021219135255 Fill in some more bits in the new Unix library: specifically the contents of PosixTTY and PosixDB (now System.Posix.Terminal and System.Posix.User respectively). We're now about 95% complete w.r.t. the old posix library. I've identified the reminaing bits to do in System/Posix.hs. ] [[project @ 2002-12-18 16:29:26 by simonmar] simonmar**20021218162926 "Auto" packages. The big change here is that it is no longer necessary to explicitly say '-package X' on the command line if X is a package containing hierarchical Haskell modules. All packages marked "auto" contribute to the import path, so their modules are always available. At link time, the compiler knows which packages are actually used by the program, and it links in only those libraries needed. There's one exception: one-shot linking. If you link a program using ghc -o prog A.o B.o ... then you need to explicitly add -package flags for each package required (except base & haskell98) because the compiler has no information about the package dependencies in this case. Package configs have a new field: auto, which is either True or False. Non-auto packages must be mentioned on the command-line as usual. Non-auto packages are still required for: - non-hierarchical libraries (to avoid polluting the module namespace) - packages with no Haskell content - if you want more than one version of a package, or packages providing overlapping functionality where the user must decide which one to use. Doc changes to follow... ] [[project @ 2002-12-12 13:42:48 by ross] ross**20021212134248 Changes to the exception interface, as discussed on the libraries list. 1) Move bracket and bracket_ from GHC.Exception (and hence System.IO) to haskell98/IO.hs. These two should now never be used (except in all-H98 programs), and this will save users of the new libraries from having to hide them. Use the ones in Control.Exception instead. 2) Define type IOError = IOException -- was Exception leaving the type of Prelude.ioError as IOError -> IO a, but adding to Control.Exception throwIO :: Exception -> IO a The result is a type distinction between the variants of catch and try: Prelude.catch :: IO a -> (IOError -> IO a) -> IO a Control.Exception.catch :: IO a -> (Exception -> IO a) -> IO a System.IO.Error.try :: IO a -> IO (Either IOError a) Control.Exception.try :: IO a -> IO (Either Exception a) These are breaking changes: the first one affects only import lists, but the second will bite in the following situations: - using ioError on general Exceptions: use throwIO instead. - using throw on IOErrors: if in the IO monad, use ioError instead. Otherwise, use throw (IOException e), but why are you throwing IO exceptions outside of the IO monad? Minor changes: - System.IO.Error now exports catch and try - moved try from GHC.Exception to System.IO.Error, because it's portable and can be shared by Hugs. ] [[project @ 2002-11-18 08:37:35 by stolz] stolz**20021118083735 readlink(2) does not append a NUL character to buffer. Noticed by: John Meacham ] [[project @ 2002-10-11 14:25:25 by stolz] stolz**20021011142525 'usleep' nightmare: Sometimes return type is void, sometimes int. ] [[project @ 2002-10-08 08:03:02 by wolfgang] wolfgang**20021008080302 Make the new Posix bindings compile on Mac OS X. Most notable, Mac OS X lacks *) lchown *) SIGPOLL I don't know of a replacement of either, so they are just left out when they are not detected by configure. ] [[project @ 2002-10-05 22:35:45 by panne] panne**20021005223545 Warning police #14: Help gcc a bit with variables which are not obviously always used. ] [[project @ 2002-09-14 09:35:00 by panne] panne**20020914093500 4th attempt to get a working RPM, but again: Make Haddock happy. Is doing a "make html" that hard before committing...? :-] ] [[project @ 2002-09-13 09:12:12 by simonmar] simonmar**20020913091212 - #include to get at get/setpriority. - #include "config.h", and protect other includes according to the configure results. ] [[project @ 2002-09-12 16:38:21 by simonmar] simonmar**20020912163822 More POSIX bits... we're getting there. ] [[project @ 2002-09-10 20:54:33 by panne] panne**20020910205433 No prologue.txt, no -p... ] [[project @ 2002-09-06 14:34:15 by simonmar] simonmar**20020906143415 Partial rewrite of the POSIX library. The main purpose of this sweep is to remove the last dependencies of the compiler on hslibs. When I've committed the associated compiler changes, only the 'base' package will be required to bootstrap the compiler. Additionally to build GHCi, the 'readline' and 'unix' packages will be required. The new POSIX library lives mostly in libraries/unix, with a few bits required for compiler bootstrapping in libraries/base. The 'base' package is mostly free of hsc2hs code to make bootstrapping from HC files easier, but the 'unix' package will use hsc2hs liberally. The old POSIX library continues to provide more-or-less the same interface as before, although some of the types are more correct now (previously lots of POSIX types were just mapped to Int). The new interface is largely the same as the old, except that some new functionality from the latest POSIX spec has been added (eg. symbolic links). So far, the new POSIX library has signal support, directory/file operations and lots of stuff from unistd.h. The module names are: System.Posix The main dude, exports everything System.Posix.Types All the POSIX types, using the same naming scheme as Foreign.C.Types, Eg. CUid, COff, etc. Many of these types were previously exported by GHC.Posix. Additionally exports the "nicer" names used by the old POSIX library for compatibility (eg. ProcessID == CPid, FileMode == CMode, etc.) All reasonable instances are derived for these types. System.Posix.Signals Signal support, contains most of which was in PosixProcPrim before. The RTS interface to the signal handling support has been rationalised slightly. System.Posix.Directory Directory support, most were in PosixFiles before. System.Posix.Files File operations, most were in PosixFiles before. System.Posix.Unistd (for want of a better name) Miscellaneous bits that mostly come from the unistd.h header file. PosixProcEnv before. The rest of the library should pan out like so: System.Posix.IO System.Posix.Error (maybe) System.Posix.Process System.Posix.Terminal (I've no doubt broken Win32 support, but I'm checking the build at the moment). ] Patch bundle hash: c4d4c9a6e9ae19460d5eed6dcb454f7781802c83 From Axel.Simon at ens.fr Tue Jan 13 06:55:51 2009 From: Axel.Simon at ens.fr (Axel Simon) Date: Tue Jan 13 06:47:22 2009 Subject: Missing headers from SharedMem.hsc In-Reply-To: <496C7753.5040003@gmail.com> References: <20090112235142.GU3582@scytale.galois.com> <496C7753.5040003@gmail.com> Message-ID: <1231847751.14043.21.camel@aconit> On Tue, 2009-01-13 at 11:13 +0000, Simon Marlow wrote: > Don Stewart wrote: > > It was also missing HsUnix.h, so the #defines weren't propagating > > anyway. > > > > > > Mon Jan 12 15:07:58 PST 2009 Don Stewart > > * Add check for -lrt to get the shm* functions. Subst. in buildinfo > > > > Mon Jan 12 15:47:17 PST 2009 Don Stewart > > * SharedMem.hsc wasn't including HsUnixConfig.h, so no #defines were propagating > > I can't apply these here: > > $ darcs apply ~/sharedmem.patch > darcs: Cannot apply this patch bundle, since we're missing: > Thu Nov 10 12:58:32 GMT 2005 simonmar > * [project @ 2005-11-10 12:58:32 by simonmar] > Some docs for System.Posix, from Bj?rn Bringert > > this looks like an encoding issue, since in the history I have: > > Thu Nov 10 12:58:32 GMT 2005 simonmar > * [project @ 2005-11-10 12:58:32 by simonmar] > Some docs for System.Posix, from Bj[_\f6_]rn Bringert > > I tried with darcs 2.2.0rc1 and 1.0.9, same result. > > Anyone know what's going on here? (for the darcs-users folks, the repo to > apply to is http://darcs.haskell.org/packages/unix). Yes, I have a patch with a Unicode character. The problem seems to be broken mail programs that confuse Latin-1 and UTF8. My problem was (I think) slightly easier since I have a correct UTF8 character in my repository and only receive mails in Latin-8 in which the UTF8 characters are not correctly converted (i.e. they are Garbage). Saving the patch, opening them as Latin-1 and saving them as UTF8 so far always worked. It looks to me that your darcs repository has a patch with a broken character encoding in it. However, maybe its just your terminal that's broken. my 2p, Axel. From alistair at abayley.org Tue Jan 13 08:44:09 2009 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jan 13 08:35:21 2009 Subject: ghc-6.10 and Exception vs OldException Message-ID: <79d7c4980901130544n23dd332fya7a5ac327e945a24@mail.gmail.com> I'm upgrading Takusen to compile with ghc-6.10, and I'm wondering what the recommended approach is for dealing with the new Exception module. What does one do if one wants to maintain a library that will build with ghc-6.10 and also older versions, as far back as 6.4, say? CPP hackery, or is there something more elegant? Alistair From gale at sefer.org Tue Jan 13 09:48:35 2009 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 13 09:39:49 2009 Subject: Policy question re: Haskell Platform installer on OSX In-Reply-To: <1231800011.28590.124.camel@localhost> References: <1231800011.28590.124.camel@localhost> Message-ID: <2608b8a80901130648s48c3e85aoa15378270b1a9b69@mail.gmail.com> Duncan Coutts wrote: > input from the OSX users and hackers would be most welcome. Manuel has done a ton of work on Mac installers for GHC, please make sure to get feedback from him on whatever you do. There are some very subtle points. In particular - there could be significant differences between Leopard and Tiger. I'm on Tiger, and Manuel is on Leopard. AFAIK Manuel never managed to get an installer working for Tiger based on his Leopard work. Thanks, Yitz From dons at galois.com Tue Jan 13 14:29:12 2009 From: dons at galois.com (Don Stewart) Date: Tue Jan 13 14:20:09 2009 Subject: [Haskell-cafe] Re: Arch Haskell News: Jan 11 2009 In-Reply-To: References: <20090111223053.GA1296@scytale.galois.com> Message-ID: <20090113192912.GE7184@scytale.galois.com> awaiting xmonad to support 6.10 ... phercek: > Hi, > > Any idea why ghc 6.10.1 is still in Testing repository on archlinux? > > Peter. > > Don Stewart wrote: > >Arch Haskell News: Jan 11 2009 > <--cut--> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From phercek at gmail.com Tue Jan 13 14:27:24 2009 From: phercek at gmail.com (Peter Hercek) Date: Tue Jan 13 14:21:18 2009 Subject: Arch Haskell News: Jan 11 2009 In-Reply-To: <20090111223053.GA1296@scytale.galois.com> References: <20090111223053.GA1296@scytale.galois.com> Message-ID: Hi, Any idea why ghc 6.10.1 is still in Testing repository on archlinux? Peter. Don Stewart wrote: > Arch Haskell News: Jan 11 2009 <--cut--> From duncan.coutts at worc.ox.ac.uk Tue Jan 13 16:25:21 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 13 16:16:34 2009 Subject: Policy question re: Haskell Platform installer on OSX In-Reply-To: <2608b8a80901130648s48c3e85aoa15378270b1a9b69@mail.gmail.com> References: <1231800011.28590.124.camel@localhost> <2608b8a80901130648s48c3e85aoa15378270b1a9b69@mail.gmail.com> Message-ID: <1231881921.28590.185.camel@localhost> On Tue, 2009-01-13 at 16:48 +0200, Yitzchak Gale wrote: > Duncan Coutts wrote: > > input from the OSX users and hackers would be most welcome. > > Manuel has done a ton of work on Mac installers for GHC, > please make sure to get feedback from him on whatever you do. > There are some very subtle points. Yes we'd very much like his advice if he has time to give it. One thing that we should try and do with the platform effort is to document these issues so that more than one or two people know the black arts involved in building installers on our supported platforms. > In particular - there could be significant differences between > Leopard and Tiger. I'm on Tiger, and Manuel is on Leopard. > AFAIK Manuel never managed to get an installer working for > Tiger based on his Leopard work. Tiger == OS 10.4 Leopard == OS 10.5 So the one built on 10.5 did not work with 10.4, but presumably an installer built on the older version will work on the newer version. Duncan From duncan.coutts at worc.ox.ac.uk Tue Jan 13 18:32:16 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 13 18:23:28 2009 Subject: ghc-6.10 and Exception vs OldException In-Reply-To: <79d7c4980901130544n23dd332fya7a5ac327e945a24@mail.gmail.com> References: <79d7c4980901130544n23dd332fya7a5ac327e945a24@mail.gmail.com> Message-ID: <1231889536.28590.260.camel@localhost> On Tue, 2009-01-13 at 13:44 +0000, Alistair Bayley wrote: > I'm upgrading Takusen to compile with ghc-6.10, and I'm wondering what > the recommended approach is for dealing with the new Exception module. > What does one do if one wants to maintain a library that will build > with ghc-6.10 and also older versions, as far back as 6.4, say? CPP > hackery, or is there something more elegant? There is the extensible-exceptions package. It provides the base-4 exceptions and works with at least base-3 (ghc-6.8). I don't know if it works with older versions of base that come with 6.4 or 6.6. Try it. It may well be possible to add support if it does not work yet. Otherwise another approach is to use cpp to define a few exception functions. See Cabal's Distribution/Compat/Exception.hs for an example of this approach, eg: catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a #ifdef NEW_EXCEPTION catchIO = Exception.catch #else catchIO = Exception.catchJust Exception.ioErrors #endif Duncan From gale at sefer.org Wed Jan 14 06:49:58 2009 From: gale at sefer.org (Yitzchak Gale) Date: Wed Jan 14 06:41:10 2009 Subject: Policy question re: Haskell Platform installer on OSX In-Reply-To: <1231881921.28590.185.camel@localhost> References: <1231800011.28590.124.camel@localhost> <2608b8a80901130648s48c3e85aoa15378270b1a9b69@mail.gmail.com> <1231881921.28590.185.camel@localhost> Message-ID: <2608b8a80901140349u408a55fdh97d5f3e472d8dd1f@mail.gmail.com> I wrote: >> In particular - there could be significant differences between >> Leopard and Tiger... Duncan Coutts wrote: > Tiger == OS 10.4 > Leopard == OS 10.5 > So the one built on 10.5 did not work with 10.4, but presumably an > installer built on the older version will work on the newer version. No, they are just incompatible. There are knotty differences between the C library structures on the two platforms. And there are differences in the installation paths. I suppose you also have to watch out for PPC vs. Intel. I can't say exactly what all those differences are though. You can download an environment that lets a developer working on Leopard set up installation packages for Tiger. But Manuel told me that he was unable to use it, because he couldn't re-use his work on the Leopard installer there. He would have to start from scratch. -Yitz From haskell at list.mightyreason.com Wed Jan 14 07:11:14 2009 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Jan 14 07:02:25 2009 Subject: Haskell platform related proposal: update regex to latest versions Message-ID: <496DD662.40301@list.mightyreason.com> I have added this to the trac wiki at http://trac.haskell.org/haskell-platform/wiki/Library/regex-base Chris Kuklewicz proposes: As the writer and maintainer of the regex-(base|posix|compat) packages I would like suggest the following. The Haskell platform should upgrade from the 0.72 version of regex-base to the 0.93.1 version. Similar updates to the latest releases of regex-posix and regex-compat would also be made. The old version has been kicking around too long, partly because I have not bothered to push updating the GHC bundle. The regex-base update adds makeRegexM and makeRegexOptsM which allow for saner error handling when compiling regular expressions, they use "fail" instead of "error". It would be possible to switch to !MonadError or perhaps the new exceptions, discussion of this is welcome. The older version of regex-base has lazy overlapping instances of !RegexContex which GHC allows and Hugs forbids, so the new version of regex-base has newtypes that force the user to be more explicit: {{{ newtype AllSubmatches f b = AllSubmatches {getAllSubmatches :: (f b)} newtype AllTextSubmatches f b = AllTextSubmatches {getAllTextSubmatches :: (f b)} newtype AllMatches f b = AllMatches {getAllMatches :: (f b)} newtype AllTextMatches f b = AllTextMatches {getAllTextMatches :: (f b) } }}} It would be possible to include most (or perhaps all) of the old instances, either as a sub-module or conditionally compiled, again discussion of this is welcome. From v.dijk.bas at gmail.com Wed Jan 14 07:54:47 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Jan 14 07:45:59 2009 Subject: Add Applicative instances for MTL types In-Reply-To: References: Message-ID: On Sat, Dec 20, 2008 at 7:09 PM, Bas van Dijk wrote: > Hello, > > In a project of mine I needed an Applicative instance for Identity and > noticed it didn't exist. So I decided to add Applicative (and > Alternative instances where possible) for all MTL types. > > When I was about to submit a library proposal I saw there already > existed one. So I added my patch to that ticket. > > My patch I different in that my Applicative instances don't require a > Monad constraint. This also means that most Functor instances now also > depend on Applicative rather than on Monad. > > See the ticket for the details: > > http://hackage.haskell.org/trac/ghc/ticket/2316 > > Discussion period: 5 weeks (taking the holidays into account) > > This is the old thread about this proposal: > > http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9140/focus=9154 > > regards, > > Bas > getCurrentTime >>= \c -> print (realToFrac (diffUTCTime c (readTime defaultTimeLocale "%c" "Sat Dec 20 19:09:00 2008")) / 60 / 60 / 24 / 7) ~ 3.5 weeks ago I sended this previous message ;-) Can we have some discussion about my patch? As listed in the ticket I have these questions: * Does it make sense adding Applicative counterparts to the Monad* classes? For example: o class Applicative f => ApplicativeError e g | f -> e where ... o class Applicative f => ApplicativeState s f | f -> s where ... o class Applicative f => ApplicativeReader r f | f -> r where ... o class (Applicative f, Monoid w) => ApplicativeWriter w f | f -> w where ... o class (Monoid w, ApplicativeReader r f, ApplicativeWriter w f, ApplicatveState s f) => ApplicativeRWS r w s f | f -> r, f -> w, f -> s where ... o class (Applicative m) => ApplicativeCont m where ... o class ApplicativeTrans t where lift :: Applicative f => f a -> t f a * Can we get rid of the Monad and MonadPlus constraints in the Applicative and Alternative instances for StateT and RWST? Thanks, Bas From duncan.coutts at worc.ox.ac.uk Wed Jan 14 08:41:02 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 14 08:32:13 2009 Subject: Add Applicative instances for MTL types In-Reply-To: References: Message-ID: <1231940462.28590.284.camel@localhost> On Wed, 2009-01-14 at 13:54 +0100, Bas van Dijk wrote: > On Sat, Dec 20, 2008 at 7:09 PM, Bas van Dijk wrote: > > Hello, > > > > In a project of mine I needed an Applicative instance for Identity and > > noticed it didn't exist. So I decided to add Applicative (and > > Alternative instances where possible) for all MTL types. > > > > When I was about to submit a library proposal I saw there already > > existed one. So I added my patch to that ticket. > > > > My patch I different in that my Applicative instances don't require a > > Monad constraint. This also means that most Functor instances now also > > depend on Applicative rather than on Monad. > > > > See the ticket for the details: > > > > http://hackage.haskell.org/trac/ghc/ticket/2316 > > > > Discussion period: 5 weeks (taking the holidays into account) > > > > This is the old thread about this proposal: > > > > http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9140/focus=9154 > ~ 3.5 weeks ago I sended this previous message ;-) > > Can we have some discussion about my patch? Yes please! I think we all want all the MTL monads to be instances of Applicative. I'm not sure if I am qualified to comment on the details of the patch however. If we don't get enough reviewers, we should try pinging people, like the original MTL authors, authors of similar mtl-esque packages etc. > As listed in the ticket I have these questions: > > * Does it make sense adding Applicative counterparts to the Monad* > classes? For example: > o class Applicative f => ApplicativeError e g | f -> e where ... > o class Applicative f => ApplicativeState s f | f -> s where ... > o class Applicative f => ApplicativeReader r f | f -> r where ... > o class (Applicative f, Monoid w) => ApplicativeWriter w f | f -> w where ... > o class (Monoid w, ApplicativeReader r f, ApplicativeWriter w f, > ApplicatveState s f) => ApplicativeRWS r w s f | f -> r, f -> w, f -> > s where ... > o class (Applicative m) => ApplicativeCont m where ... > o class ApplicativeTrans t where lift :: Applicative f => f a -> t f a That sounds like it wants to be an independent proposal. Duncan From ross at soi.city.ac.uk Wed Jan 14 08:50:54 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jan 14 08:42:07 2009 Subject: Add Applicative instances for MTL types In-Reply-To: References: Message-ID: <20090114135054.GA8682@soi.city.ac.uk> On Wed, Jan 14, 2009 at 01:54:47PM +0100, Bas van Dijk wrote: > On Sat, Dec 20, 2008 at 7:09 PM, Bas van Dijk wrote: > > In a project of mine I needed an Applicative instance for Identity and > > noticed it didn't exist. So I decided to add Applicative (and > > Alternative instances where possible) for all MTL types. > > > > When I was about to submit a library proposal I saw there already > > existed one. So I added my patch to that ticket. > > > > My patch I different in that my Applicative instances don't require a > > Monad constraint. This also means that most Functor instances now also > > depend on Applicative rather than on Monad. > > > > See the ticket for the details: > > > > http://hackage.haskell.org/trac/ghc/ticket/2316 The Functor instances could depend on Functor rather than Applicative. Even though Applicative is not a superclass of Monad, I think we ought to ensure that the instances are compatible. That is, if an Applicative is also a Monad, then we should have pure = return and (<*>) = ap. This fails for your ErrorT instance: ap runs the second computation only if the first succeeded, while (<*>) runs them both before checking for errors. It needs a Monad constraint (like StateT), though not an Error constraint. > * Can we get rid of the Monad and MonadPlus constraints in the > Applicative and Alternative instances for StateT and RWST? I don't think so: you need part of the value generated by the first computation, namely the state (inside the f), to construct the second one. You can do that in a Monad, but not in an Applicative. At Henning Thielemann's request, I've recently put up on hackage a restructuring of the mtl into three packages, to provide three different interfaces to the same monad transformers: transformers: a Haskell 98 package with the MonadTrans class, concrete monad transformers, operations and liftings. monads-fd: multi-parameter monad classes using functional dependencies, with instances for these transformers. (Almost backward-compatible with the mtl package.) monads-tf: monad classes using type families, with instances for these transformers. The first one includes Applicative instances like these. From v.dijk.bas at gmail.com Wed Jan 14 12:16:42 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Jan 14 12:07:52 2009 Subject: Add Applicative instances for MTL types In-Reply-To: <20090114135054.GA8682@soi.city.ac.uk> References: <20090114135054.GA8682@soi.city.ac.uk> Message-ID: Thanks for the reply. On Wed, Jan 14, 2009 at 2:50 PM, Ross Paterson wrote: > The Functor instances could depend on Functor rather than Applicative. Ok you mean like: instance Functor m => Functor (ErrorT e m) where fmap f = ErrorT . fmap (fmap f) . runErrorT instance Functor m => Functor (ListT m) where fmap f = ListT . fmap (fmap f) . runListT instance (Functor m) => Functor (ReaderT r m) where fmap f = ReaderT . fmap (fmap f) . runReaderT instance (Functor m, Monoid w) => Functor (WriterT w m) where fmap f = WriterT . fmap (\(x, w) -> (f x, w)) . runWriterT I could update the patch with this or I can create a separate ticket for it. What do you think? The latter instance indicates that WriterT should have its inner tuple reversed: newtype WriterT w m a = WriterT { runWriterT :: m (a, w) } --> newtype WriterT w m a = WriterT { runWriterT :: m (w, a) } Because then we can write the more consistent: instance (Functor m, Monoid w) => Functor (WriterT w m) where fmap f = WriterT . fmap (fmap f) . runWriterT But this is probably a ticket on it own. > Even though Applicative is not a superclass of Monad, I think we ought to > ensure that the instances are compatible. That is, if an Applicative > is also a Monad, then we should have pure = return and (<*>) = ap. Yes, but what if an Applicative isn't a Monad? We can't have two instances because they overlap: instance Monad m => Applicative (ErrorT e m) where pure = return (<*>) = ap instance Applicative m => Applicative (ErrorT e m) where pure = ErrorT . pure . pure ef <*> ex = ErrorT $ liftA2 (<*>) (runErrorT ef) (runErrorT ex) I think the latter is more useful because there are more Applicatives than Monads out there. > This fails for your ErrorT instance: ap runs the second computation > only if the first succeeded, while (<*>) runs them both before checking > for errors. It needs a Monad constraint (like StateT), though not an > Error constraint. But isn't 'runErrorT ex' only evaluated when 'runErrorT ef' returns 'Right f' because of lazy evaluation? >> * Can we get rid of the Monad and MonadPlus constraints in the >> Applicative and Alternative instances for StateT and RWST? > > I don't think so: you need part of the value generated by the first > computation, namely the state (inside the f), to construct the second one. > You can do that in a Monad, but not in an Applicative. Yes I thought so. > At Henning Thielemann's request, I've recently put up on hackage a > restructuring of the mtl into three packages, to provide three different > interfaces to the same monad transformers: > > transformers: a Haskell 98 package with the MonadTrans class, concrete > monad transformers, operations and liftings. > monads-fd: multi-parameter monad classes using functional dependencies, > with instances for these transformers. (Almost backward-compatible > with the mtl package.) > monads-tf: monad classes using type families, with instances for these > transformers. > > The first one includes Applicative instances like these. Yes I saw it. Very nice! What is the long term goal of these libraries? Are they intended to replace mtl one day? From dave at zednenem.com Wed Jan 14 13:56:14 2009 From: dave at zednenem.com (David Menendez) Date: Wed Jan 14 13:47:25 2009 Subject: Add Applicative instances for MTL types In-Reply-To: References: <20090114135054.GA8682@soi.city.ac.uk> Message-ID: <49a77b7a0901141056o1b9e1ed9nd68f66745b660180@mail.gmail.com> On Wed, Jan 14, 2009 at 12:16 PM, Bas van Dijk wrote: > On Wed, Jan 14, 2009 at 2:50 PM, Ross Paterson wrote: >> >> Even though Applicative is not a superclass of Monad, I think we ought to >> ensure that the instances are compatible. That is, if an Applicative >> is also a Monad, then we should have pure = return and (<*>) = ap. > > Yes, but what if an Applicative isn't a Monad? > > We can't have two instances because they overlap: > > instance Monad m => Applicative (ErrorT e m) where > pure = return > (<*>) = ap > > instance Applicative m => Applicative (ErrorT e m) where > pure = ErrorT . pure . pure > ef <*> ex = ErrorT $ liftA2 (<*>) (runErrorT ef) (runErrorT ex) > > I think the latter is more useful because there are more Applicatives > than Monads out there. The latter is just normal composition of applicative functors, in this case "Comp m (Either e)". newtype Comp f g x = Comp { unComp :: f (g x) } instance (Functor f, Functor g) => Functor (Comp f g) where fmap f = Comp . fmap (fmap f) . unComp instance (Applicative f, Applicative g) => Applicative (Comp f g) where pure = Comp . pure . pure f <*> x = Comp $ liftA2 (<*>) (unComp f) (unComp x) Given how easy it is to combine different functors and applicative functors, there isn't very much need for (applicative) functor transformers. I agree with Ross, the functor and applicative instances for monad transformers should satisfy these laws: fmap = liftM pure = return (<*>) = ap >> This fails for your ErrorT instance: ap runs the second computation >> only if the first succeeded, while (<*>) runs them both before checking >> for errors. It needs a Monad constraint (like StateT), though not an >> Error constraint. > > But isn't 'runErrorT ex' only evaluated when 'runErrorT ef' returns > 'Right f' because of lazy evaluation? No, in your definition, the effects of the transformed applicative functor are evaluated regardless of the error condition. Try this code: runState (runErrorT (throwError "!" <*> put False)) True The first definition of <*> returns (Left "!", True). The second returns (Left "!", False). -- Dave Menendez From v.dijk.bas at gmail.com Thu Jan 15 04:49:20 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu Jan 15 04:40:28 2009 Subject: Add Applicative instances for MTL types In-Reply-To: <49a77b7a0901141056o1b9e1ed9nd68f66745b660180@mail.gmail.com> References: <20090114135054.GA8682@soi.city.ac.uk> <49a77b7a0901141056o1b9e1ed9nd68f66745b660180@mail.gmail.com> Message-ID: On Wed, Jan 14, 2009 at 7:56 PM, David Menendez wrote: > No, in your definition, the effects of the transformed applicative > functor are evaluated regardless of the error condition. > > Try this code: > > runState (runErrorT (throwError "!" <*> put False)) True > > The first definition of <*> returns (Left "!", True). The second > returns (Left "!", False). I see it now. Thanks for correcting me. Then we should consider the first patch by Spencer Janssen again which satisfies these laws: pure = return (<*>) = ap Thanks, Bas From ben_moseley at mac.com Thu Jan 15 14:48:07 2009 From: ben_moseley at mac.com (Ben Moseley) Date: Thu Jan 15 14:39:17 2009 Subject: Control.Monad.Writer.Strict .... enough? Message-ID: <3D57D259-BEEB-4EC4-9ED5-DF32F87BE984@mac.com> Hi, In most of the 'mtl' variants on Hackage (with the notable exception of 'monadLib'), the Control.Monad.Writer.Strict main instance is: newtype Writer w a = Writer { runWriter :: (a, w) } instance (Monoid w) => Monad (Writer w) where return a = Writer (a, mempty) m >>= k = Writer $ case runWriter m of (a, w) -> case runWriter (k a) of (b, w') -> (b, w `mappend` w') ...ie the `mappend` is hidden inside a lazy "(,)" constructor. ...shouldn't the bind really be strict in the written monoid? (eg by replacing "(a,w)" with "(a,!w)" and using Bang Patterns). ...if so, is it worth submitting patch? --Ben From lemming at henning-thielemann.de Thu Jan 15 16:46:46 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 15 16:38:09 2009 Subject: Data instances for MTL types In-Reply-To: <20090114135054.GA8682@soi.city.ac.uk> References: <20090114135054.GA8682@soi.city.ac.uk> Message-ID: When trying to perform some tests with StrictCheck, I found that the monads from the 'transformers' package don't have Data instances. Can they be provided while keeping 'transformers' Haskell 98 and avoiding orphan instances? From ross at soi.city.ac.uk Thu Jan 15 16:55:48 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jan 15 16:46:55 2009 Subject: Data instances for MTL types In-Reply-To: References: <20090114135054.GA8682@soi.city.ac.uk> Message-ID: <20090115215547.GA9112@soi.city.ac.uk> On Thu, Jan 15, 2009 at 10:46:46PM +0100, Henning Thielemann wrote: > When trying to perform some tests with StrictCheck, I found that the > monads from the 'transformers' package don't have Data instances. Can > they be provided while keeping 'transformers' Haskell 98 and avoiding > orphan instances? They could be provided for GHC only using ifdef'd deriving clauses. From bjpop at csse.unimelb.edu.au Fri Jan 16 05:53:42 2009 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Fri Jan 16 05:44:58 2009 Subject: Recommendations for module hierarchy names for Python parser Message-ID: Hi all, I've written a parser for Python 3.0 using Happy and Alex and I want to make it available as a library. I'd like some feedback on choosing the right module hierarchy names. I guess it is fairly clear that it should go in: Language The following document already has space for Language.Python: http://www.haskell.org/~simonmar/lib-hierarchy.html The nub of my question is really what to do about version numbers of Python? Currently my parser only supports Python 3.0. In the near future I will also support an earlier version from the 2 series. In case you don't know Python, version 3.0 is the latest version, which was released late 2008. It is not backwards compatible with earlier versions. I think it would be difficult, and probably a bad idea to try to merge a parser for Python 3.0 with a parser for an earlier version. I don't think I should use: Language.Python, since it is not clear which version of Python it is. Would it be better to have: Language.Python30 -- for version 3.0 and say: Language.Python26 -- for version 2.6 Or would it be better to have something like: Language.Python.Version30 Language.Python.Version26 In general my strategy has been to follow the structure of Language.C, but they appear to only have one version. Cheers, Bernie. From schlepptop at henning-thielemann.de Fri Jan 16 06:37:04 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri Jan 16 06:21:43 2009 Subject: Recommendations for module hierarchy names for Python parser In-Reply-To: References: Message-ID: <49707160.8090902@henning-thielemann.de> Bernie Pope schrieb: > Or would it be better to have something like: > > Language.Python.Version30 > Language.Python.Version26 > > In general my strategy has been to follow the structure of Language.C, > but they appear to only have one version. I think the version number should be part of the module name for the reasons you mention. Is Language.Python.30 Language.Python.26 also possible? From Christian.Maeder at dfki.de Fri Jan 16 07:08:10 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 16 06:59:19 2009 Subject: Recommendations for module hierarchy names for Python parser In-Reply-To: <49707160.8090902@henning-thielemann.de> References: <49707160.8090902@henning-thielemann.de> Message-ID: <497078AA.7080107@dfki.de> Henning Thielemann wrote: > I think the version number should be part of the module name for the > reasons you mention. Is > > Language.Python.30 > Language.Python.26 > > also possible? Good question. Where is this documented? http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#hierarchical-modules "GHC supports a small extension to the syntax of module names: a module name is allowed to contain a dot ?.?." This would also allow lowercase letters following a dot. Given: http://www.haskell.org/onlinelibrary/lexemes.html modid -> conid (modules) conid -> large {small | large | digit | ' } I would add: modid -> modid . modid (or make it a qualified conid: qconid) So Python.30 should beillegal. Why not use V30 or Ver30. Cheers Christian From duncan.coutts at worc.ox.ac.uk Fri Jan 16 08:18:24 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jan 16 08:09:26 2009 Subject: Recommendations for module hierarchy names for Python parser In-Reply-To: References: Message-ID: <1232111904.28590.405.camel@localhost> On Fri, 2009-01-16 at 21:53 +1100, Bernie Pope wrote: > Or would it be better to have something like: > > Language.Python.Version30 > Language.Python.Version26 > > In general my strategy has been to follow the structure of Language.C, > but they appear to only have one version. There had been some discussion about variants in Language.C. Currently it does GNU C + C99 but if they were split then the suggestion was: Language.C.GNU Language.C.C99 Language.C.C89 Of course those are the common names of the versions. For Python where they are labelled with numbers rather than names then your suggestion of Language.Python.Version30 or Language.Python.V30 or whatever seems fine. Do you think it needs both digits? Would V2 and V3 not be enough? Surely V26 could read code intended for Python-2.4? And similarly a future Language.Python.V3 module that was compatible with Python-3.1 should still be able to read code for Python-3.0 right? Duncan From ross at soi.city.ac.uk Fri Jan 16 08:37:57 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Jan 16 08:29:05 2009 Subject: Data instances for MTL types In-Reply-To: References: <20090114135054.GA8682@soi.city.ac.uk> Message-ID: <20090116133757.GA4644@soi.city.ac.uk> On Thu, Jan 15, 2009 at 10:46:46PM +0100, Henning Thielemann wrote: > > When trying to perform some tests with StrictCheck, I found that the > monads from the 'transformers' package don't have Data instances. Can > they be provided while keeping 'transformers' Haskell 98 and avoiding > orphan instances? The Typeable and Data instances will be non-trivial, as they can't be derived for higher-order type constructors. From jpm at cs.uu.nl Fri Jan 16 08:43:31 2009 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Fri Jan 16 08:34:38 2009 Subject: Proposal #2875: Correct SYB's representation of Char In-Reply-To: <52f14b210812110706g53cf284agc752570821ace133@mail.gmail.com> References: <52f14b210812110706g53cf284agc752570821ace133@mail.gmail.com> Message-ID: <52f14b210901160543x2d9f3366ka41b26d83ab2d703@mail.gmail.com> Hello all, On Thu, Dec 11, 2008 at 16:06, Jos? Pedro Magalh?es wrote: > Hello all, > > SYB uses DataRep to represent datatypes: > > -- | Public representation of datatypes > data DataRep = AlgRep [Constr] > | IntRep > | FloatRep > | StringRep > | NoRep > > I believe that StringRep should be CharRep. Note that IntRep is used for > the primitive Int and Integer datatypes, FloatRep for Float and Double, and > StringRep (apparently) for Char. String, however, is represented as AlgRep > [[],(:)]: > > *Main> dataTypeOf 'p' > DataType {tycon = "Prelude.Char", datarep = StringRep} > *Main> dataTypeOf "p" > DataType {tycon = "Prelude.[]", datarep = AlgRep [[],(:)]} > > This makes sense, since String is not a primitive datatype. But it causes > the apparently wrong behavior: > > *Main> fromConstr (mkStringConstr (dataTypeOf "a") "ab") :: String > "*** Exception: mkStringConstr > *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: String > "*** Exception: constrIndex > > The correct way of using mkStringConstr is to construct a Char. This, > however, only works for strings with a single character: > > *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "b") :: Char > 'b' > *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: Char > *** Exception: gunfold > *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "") :: Char > *** Exception: gunfold > > I find this behavior counterintuitive. Therefore I propose to rename > StringRep to CharRep and mkStringConstr to mkCharConstr. For backwards > compatibility, this entails: > > * Deprecating mkStringConstr and StringConstr > * Deprecating mkStringRep and StringRep > * Introducing mkCharConstr and CharConstr > * Introducing mkCharRep and CharRep > > Additionally, due to deprecation warnings, the following have to change as > well: > > * libraries/template-haskell/Language/Haskell/TH/Quote.hs > * compiler/utils/Serialized.hs > > A patch is attached in #2875 ( > http://hackage.haskell.org/trac/ghc/ticket/2875). I propose a discussion > period of 4 weeks, therefore until the 8th of January. The discussion period is now over. According to the feedback from Neil, I will submit new patches where 'StringRep' disappears completely instead of being deprecated. The function 'mkStringRep', however, will be kept as deprecated (and will now use the new CharRep). Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090116/d16628c6/attachment.htm From johan.tibell at gmail.com Fri Jan 16 09:04:53 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Jan 16 08:55:57 2009 Subject: Recommendations for module hierarchy names for Python parser In-Reply-To: References: Message-ID: <90889fe70901160604u32264a98sad4b2a7331a7b132@mail.gmail.com> On Fri, Jan 16, 2009 at 11:53 AM, Bernie Pope wrote: > Would it be better to have: > > Language.Python30 -- for version 3.0 > > and say: > > Language.Python26 -- for version 2.6 > > Or would it be better to have something like: > > Language.Python.Version30 > Language.Python.Version26 Couldn't this lead to ambiguities (quite far) down the road? For example between Python 26.1 and Python 2.61? Cheers, Johan From eyal.lotem at gmail.com Fri Jan 16 12:32:19 2009 From: eyal.lotem at gmail.com (Eyal Lotem) Date: Fri Jan 16 12:23:23 2009 Subject: Fwd: glut bug In-Reply-To: References: Message-ID: Forwarding a bug report about GLUT... Eyal ---------- Forwarded message ---------- From: Eyal Lotem Date: Sun, Jan 11, 2009 at 4:01 PM Subject: glut bug To: Sven Panne Hi Sven, GLUT's build has a configure script. When that script says: "libGLUT... yes/no" its not actually looking just for libGLUT, but for various other libs such as libXmu. Additionally, when it fails to find these other libraries, and gets a "no", it still finishes the configure and build "successfully", but without the proper -l flags in the package description. This results in linkage failures of GLUT programs later. In my opinion the fix should include: A. Look for libXmu and any other such library in a separate configure item, so its clear what's missing. B. Failure to find necessary libraries should fail the configure/build/install, and not continue as if successful, only to fail later. Eyal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090116/570ab655/attachment.htm From v.dijk.bas at gmail.com Fri Jan 16 13:18:11 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Fri Jan 16 13:09:23 2009 Subject: Recommendations for module hierarchy names for Python parser In-Reply-To: <90889fe70901160604u32264a98sad4b2a7331a7b132@mail.gmail.com> References: <90889fe70901160604u32264a98sad4b2a7331a7b132@mail.gmail.com> Message-ID: On Fri, Jan 16, 2009 at 3:04 PM, Johan Tibell wrote: > On Fri, Jan 16, 2009 at 11:53 AM, Bernie Pope wrote: >> Or would it be better to have something like: >> >> Language.Python.Version30 >> Language.Python.Version26 > > Couldn't this lead to ambiguities (quite far) down the road? For > example between Python 26.1 and Python 2.61? Maybe use underscores to separate the digits: Language.Python.Version3 Language.Python.Version2_6 Bas From matti.niemenmaa+news at iki.fi Fri Jan 16 14:15:22 2009 From: matti.niemenmaa+news at iki.fi (Matti Niemenmaa) Date: Fri Jan 16 14:06:41 2009 Subject: Proposal #2960: Add instance Data.Traversable for Data.IntMap Message-ID: Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2960 Discussion period: 2 weeks This one should be a no-brainer. Data.Map has a Traversable instance, Data.IntMap doesn't. The proposal is to add one to Data.IntMap as well. From ross at soi.city.ac.uk Fri Jan 16 16:32:00 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Jan 16 16:23:05 2009 Subject: Proposal #2960: Add instance Data.Traversable for Data.IntMap In-Reply-To: References: Message-ID: <20090116213200.GA10271@soi.city.ac.uk> On Fri, Jan 16, 2009 at 09:15:22PM +0200, Matti Niemenmaa wrote: > Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2960 > Discussion period: 2 weeks > > This one should be a no-brainer. Data.Map has a Traversable instance, > Data.IntMap doesn't. The proposal is to add one to Data.IntMap as well. Yes From jeff at nokrev.com Fri Jan 16 23:52:50 2009 From: jeff at nokrev.com (Jeff Wheeler) Date: Fri Jan 16 23:43:54 2009 Subject: An Alternative Data.List.Zipper Message-ID: <1232167970.10485.7.camel@ulysses> Hi, I'm somewhat of a beginner in Haskell, so take what I say with a grain of salt, please. The ListZipper implementation seems very odd to me, and #haskell seemed to agree with me. The current package implements a Zipper with > data Zipper = Zipper ![a] ![a] which allows for empty zippers, among other things. Very strange to me. It also seems unnecessarily strict. There are also no expected typeclasses implemented, like Foldable or Traversable. I thought it would be interesting to try fixing these problems with a much cleaner design, and I'd like to share what I came up with: http://hpaste.org/14006 I'd very much appreciate some criticism of the code so that I can improve it. I'm not sure how best to provide this alternative on Hackage; should we make this merely a newer version of the old library, provide it in a conflicting package, or find a new namespace for it and provide it there? Thanks, Jeff Wheeler From kaol at iki.fi Sat Jan 17 04:15:25 2009 From: kaol at iki.fi (Kari Pahula) Date: Sat Jan 17 04:06:29 2009 Subject: Copyright for readline library Message-ID: <20090117091525.GA5939@piperka.net> I would use readline instead of editline to build ghc6 on Debian, but the readline library package in Hackage has a problem. I downloaded version 1.0.1.0 from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline and found this in System/Console/Readline.hsc: -- Module : System.Console.Readline -- Copyright : (c) unknown I'm afraid I can't use it as it is. Is there anything I could do to help to find the correct attribution for this file? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/libraries/attachments/20090117/a094d34b/attachment.bin From bjpop at csse.unimelb.edu.au Sat Jan 17 08:28:09 2009 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Sat Jan 17 08:19:23 2009 Subject: Recommendations for module hierarchy names for Python parser In-Reply-To: <1232111904.28590.405.camel@localhost> References: <1232111904.28590.405.camel@localhost> Message-ID: <34C539F6-7D6D-4A31-88FF-2656A6A666E4@csse.unimelb.edu.au> On 17/01/2009, at 12:18 AM, Duncan Coutts wrote: > On Fri, 2009-01-16 at 21:53 +1100, Bernie Pope wrote: > >> Or would it be better to have something like: >> >> Language.Python.Version30 >> Language.Python.Version26 >> >> In general my strategy has been to follow the structure of >> Language.C, >> but they appear to only have one version. > > There had been some discussion about variants in Language.C. Currently > it does GNU C + C99 but if they were split then the suggestion was: > > Language.C.GNU > Language.C.C99 > Language.C.C89 > > Of course those are the common names of the versions. For Python where > they are labelled with numbers rather than names then your > suggestion of > Language.Python.Version30 or Language.Python.V30 or whatever seems > fine. > Do you think it needs both digits? Would V2 and V3 not be enough? > Surely > V26 could read code intended for Python-2.4? And similarly a future > Language.Python.V3 module that was compatible with Python-3.1 should > still be able to read code for Python-3.0 right? Good point Duncan. Yes, I think the single digit is enough. I'm a bit torn between: Language.Python.Version3 and Language.Python.V3 The former is a bit long, but the latter is a bit obscure. I don't like the compromise of "Ver3"; it is hard to pronounce. Does anyone have a strong preference for or against the long or short version? If not, I will go with the long one. It's a pity module name components can't be just sequences of digits. Thanks everyone for your advice. Cheers, Bernie. From duncan.coutts at worc.ox.ac.uk Sat Jan 17 13:33:22 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jan 17 13:24:25 2009 Subject: Cabal 2.0 Message-ID: <1232217202.8432.34.camel@localhost> All, I've started a wiki page to collect ideas for Cabal 2 http://hackage.haskell.org/trac/hackage/wiki/Cabal-2 The basic idea for Cabal 2 is to learn lessons from our how the existing design has fared and how we can make a better design to tackle an expanded set of goals. I'd like the page to be about suggested design concepts. I don't want to fill it with "wouldn't it be nice if we had a feature to help me doing ..." I guess it would also be useful to make links on that page to some of the discussions we've had on various lists, eg on the ghc users and libraries mailing lists where various people have made criticisms of the current design and suggested alternatives and improvements. Duncan From duncan.coutts at worc.ox.ac.uk Sat Jan 17 13:40:58 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jan 17 13:31:54 2009 Subject: Participation in Cabal / Hackage development Message-ID: <1232217658.8432.42.camel@localhost> All, I just mentioned ideas for Cabal 2 but I should also like to talk about how we can go about increasing participation in the development effort. We currently have nearly 200 open tickets which include many important bugs and no shortage of good ideas for useful new features. Our limiting factor is developer time. Most of us use the Cabal / Hackage system in one way or another. Most of us are familiar with its annoyances and limitations. Unfortunately the number of people helping out has dropped rather in the past year or so. Perhaps we should run a little poll like the darcs hackers did to find out what we could do to increase participation so we can get on with building the tools that we all want, but a bit more quickly. Duncan From roconnor at theorem.ca Sat Jan 17 14:41:52 2009 From: roconnor at theorem.ca (roconnor@theorem.ca) Date: Sat Jan 17 14:32:53 2009 Subject: Opposite Applicative (Was: An Alternative Data.List.Zipper) In-Reply-To: <1232167970.10485.7.camel@ulysses> References: <1232167970.10485.7.camel@ulysses> Message-ID: In a not completely unrelated topic, can we have an OpApplicative newtype where f <*> x is x <**> f ? This would be helpful when traversing the reversed part of the Zipper. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From libraries at haskell.org Sat Jan 17 18:12:20 2009 From: libraries at haskell.org (network) Date: Sat Jan 17 18:03:24 2009 Subject: [network] #1: unpackFamily on Windows fails match Message-ID: <053.1587b5def64e355b370143b764e5c158@haskell.org> #1: unpackFamily on Windows fails match ------------------------+--------------------------------------------------- Reporter: igloo | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | ------------------------+--------------------------------------------------- Initially reported here: http://hackage.haskell.org/trac/ghc/ticket/2250 ---- In the HostEntry returned by Network.BSD.getHostByName, evaluating the hostFamily field causes the following error, which is pointing at the unpackFamily function: {{{ *** Exception: Network/Socket.hsc:(1711,17)-(1777,13): Non-exhaustive patterns in case }}} This occurs with 6.8.2 and 6.9.20080323 i386. The machine is running Windows Server 2008 x64. ---- I modified Network/BSD.hs to trace out the h_addrtype variable in Storable `HostEntry`'s peek, and it had the value 0x40002. The corresponding variable in the C struct should be a short, but is inferred to be CInt in the Haskell source, probably thanks to unpackFamily having type CInt -> Family. Due to that, it reads the family as an int, consuming the following length field as well. I hacked past this by giving the peek of h_addrtype an annotation of ":: IO CShort" and adding a fromIntegral at the call to unpackFamily to convert it to the CInt that the unpackFamily function expects. ---- Great stuff, thanks! It looks like it should be `CSaFamily` rather than `CInt`. Likewise `packFamily`, and I expect the whole library could do with an audit. ---- I can reproduce the exact bug on the following combinations: - GHC 6.8.2, x86, Windows XP - GHC 6.8.3, x86, Windows XP - GHC 6.8.2, x86, Windows Vista - GHC 6.8.3, x86, Windows Vista - GHC 6.8.2, x64, Windows Vista - GHC 6.8.3, x64, Windows Vista -- Ticket URL: network Networking-related facilities From libraries at haskell.org Sat Jan 17 18:15:49 2009 From: libraries at haskell.org (network) Date: Sat Jan 17 18:07:13 2009 Subject: [network] #1: unpackFamily on Windows fails match In-Reply-To: <053.1587b5def64e355b370143b764e5c158@haskell.org> References: <053.1587b5def64e355b370143b764e5c158@haskell.org> Message-ID: <062.a6ca6d9c3b178ce5b1ee09c13ec95859@haskell.org> #1: unpackFamily on Windows fails match -------------------+-------------------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Version: | Resolution: Keywords: | -------------------+-------------------------------------------------------- Changes (by igloo): * owner: somebody => -- Ticket URL: network Networking-related facilities From libraries at haskell.org Sat Jan 17 18:17:21 2009 From: libraries at haskell.org (network) Date: Sat Jan 17 18:08:20 2009 Subject: [network] #1: unpackFamily on Windows fails match In-Reply-To: <053.1587b5def64e355b370143b764e5c158@haskell.org> References: <053.1587b5def64e355b370143b764e5c158@haskell.org> Message-ID: <062.ac69428604040fec130d7e057081e87b@haskell.org> #1: unpackFamily on Windows fails match -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: component1 | Version: Resolution: | Keywords: -------------------------+-------------------------------------------------- Comment (by igloo): Testcase: {{{ module Main where import Network.BSD main = getHostByName "zao.se" >>= print }}} -- Ticket URL: network Networking-related facilities From igloo at earth.li Sat Jan 17 18:25:43 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jan 17 18:16:42 2009 Subject: extralibs and the haskell-platform In-Reply-To: <20081211143511.GA9331@matrix.chaos.earth.li> References: <20081211143511.GA9331@matrix.chaos.earth.li> Message-ID: <20090117232543.GA14389@matrix.chaos.earth.li> On Thu, Dec 11, 2008 at 02:35:11PM +0000, Ian Lynagh wrote: > > As the plan is for the extralibs to become part of the Haskell Platform, > I think we ought to have a BTS for them. I therefore propose that we > create a project on community.haskell.org for each of those that are > maintained by libraries@haskell.org. For now that will only provide a > BTS (trac), but once the GHC VCS switch has happened it would make sense > to move the authoritative darcs repos to community too. > > The packages in question are: > haskell-src > html > HUnit > mtl > network > parallel > stm I've created the community projects and tracs for all of these except HUnit, which already had a community project. I've also started to move the bug reports over. Thanks Ian From ashley at semantic.org Sun Jan 18 00:00:46 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Jan 17 23:52:01 2009 Subject: ANN: leapseconds-announced-2009 In-Reply-To: <8b2a1a960901162123w12d9cdcapbd7610ef7e568996@mail.gmail.com> References: <8b2a1a960901162123w12d9cdcapbd7610ef7e568996@mail.gmail.com> Message-ID: <4972B77E.9090808@semantic.org> Bjorn Buckwalter wrote: > leapseconds-announced is a pragmatic, if imperfect, improvement over > my past practices. It provides a LeapSecondTable with all leap seconds > announced to date (hence the name). Once the IERS announces[3] another > leap second the package will need an update and all code using it a > recompile. While this precludes its use in long-running production > applications it is eminently adequate for my one-off uses or for > applications that can afford to recompile infrequently. You should consider using the tz database, which provides a leap-seconds table in the "right/UTC" timezone (and much other useful information). -- Ashley Yakeley From bjorn.buckwalter at gmail.com Sun Jan 18 00:34:57 2009 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Sun Jan 18 00:26:05 2009 Subject: ANN: leapseconds-announced-2009 In-Reply-To: <4972B77E.9090808@semantic.org> References: <8b2a1a960901162123w12d9cdcapbd7610ef7e568996@mail.gmail.com> <4972B77E.9090808@semantic.org> Message-ID: <8b2a1a960901172134l648db485sec2a9548d9b24c81@mail.gmail.com> On Sun, Jan 18, 2009 at 00:00, Ashley Yakeley wrote: > Bjorn Buckwalter wrote: >> >> leapseconds-announced is a pragmatic, if imperfect, improvement over >> my past practices. It provides a LeapSecondTable with all leap seconds >> announced to date (hence the name). Once the IERS announces[3] another >> leap second the package will need an update and all code using it a >> recompile. While this precludes its use in long-running production >> applications it is eminently adequate for my one-off uses or for >> applications that can afford to recompile infrequently. > > You should consider using the tz database, which provides a leap-seconds > table in the "right/UTC" timezone (and much other useful information). Thanks for the pointer. My "source" is the Earth Orientation Parameter (EOP) data at http://www.celestrak.com/SpaceData/; specifically I autogenerate the module from http://www.celestrak.com/SpaceData/eop19620101.txt. Probably looks more complicated than necessary but I'm parsing the file anyway for other purposes. -Bjorn From ashley at semantic.org Sun Jan 18 00:37:26 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Jan 18 00:28:39 2009 Subject: ANN: leapseconds-announced-2009 In-Reply-To: <8b2a1a960901172134l648db485sec2a9548d9b24c81@mail.gmail.com> References: <8b2a1a960901162123w12d9cdcapbd7610ef7e568996@mail.gmail.com> <4972B77E.9090808@semantic.org> <8b2a1a960901172134l648db485sec2a9548d9b24c81@mail.gmail.com> Message-ID: <1232257046.31376.31.camel@glastonbury> On Sun, 2009-01-18 at 00:34 -0500, Bjorn Buckwalter wrote: > Thanks for the pointer. My "source" is the Earth Orientation Parameter > (EOP) data at http://www.celestrak.com/SpaceData/; specifically I > autogenerate the module from > http://www.celestrak.com/SpaceData/eop19620101.txt. Probably looks > more complicated than necessary but I'm parsing the file anyway for > other purposes. With tz, though, you could discover the table at run-time and so be more likely to be up to date. -- Ashley Yakeley From marcus at gabriel.name Sun Jan 18 06:02:43 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Sun Jan 18 05:53:44 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <20090111235612.GA9642@seas.upenn.edu> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> <20090111235612.GA9642@seas.upenn.edu> Message-ID: <49730C53.7080009@gabriel.name> Brent Yorgey wrote: >> P2. There should be no information loss, that is, keep the delimiters, >> keep the separators, keep the parts of the original list xs that satisfy >> a predicate p, do not lose information about the beginning and the end >> of the list relative to the first and last elements of the list >> respectively. The user of the function decides what to discard. >> >> P3. A split list should be unsplittable so as to recover the original >> list xs. (I made up the word unsplittable.) (P2 implies P3, but let us >> state this anyway.) > > I'm not sure I agree with this. Thanks for stating this. Dropping P3 would change my thinking about this topic, that is, if we drop P3, then I would prefer that no splitter functions are added to Data.List and that it is left as is. > The problem is that much (most?) of > the time, people looking for a split function want to discard > delimiters; for example, if you have a string like "foo;bar;baz" and > you want to split it into ["foo","bar","baz"]. I agree with this comment when thinking about strings and what I would do most of the time and from a pragmatic point of view. > In this case it's > really annoying to have to throw away the delimiters yourself, > especially if you just get back a list like > ["foo",";","bar",";","baz"] and have to decide which things are > delimiters and which aren't, I certainly understand this point, however, > with no help from the type system. -- P5. The splitter functions should fit within the spirit of the -- Data.List module and even the original Haskell 98 List module -- in terms of type signature and complexity of implementation. In my mind, the idea of adding a few splitter functions to Data.List does not preclude Data.List.Split. From my perspective of P5 above, within the spirit of Data.List, you can work with things like a, [a], (a,b), Maybe a, Eq a, ... . If you wish to do more, a separate module would be in order as you have done. > But, > as you noted, throwing away information like this is bad from an > elegance/formal properties point of view. This is exactly why I > designed the Data.List.Split library as I did: the core internal > splitting function is information-preserving, and by using various > combinators the user can choose to throw away whatever information > they are not interested in. Perfect. So, as you see it, are there one, two, or three functions in or hiding in Data.List.Split.Internals that can be factored and placed into Data.List that are in line with P1 to P7? You do not actually need to agree to P1 to P7, it is a conceptual exercise. The idea is that Data.List.Split would flow more naturally from Data.List with these few functions added to it. Finally, as concrete examples or to clarify points, the words split, delimiter, separator and variations thereof have been used. This already implies a theme. Do you conceptualize of Data.List.Split as primarily to help programmers from other backgrounds to be able to manipulate strings, that is, supply some nice idioms but generalized from [Char] to [a]? If I were to write organizeBy :: ([a] -> Bool) -> [a] -> [([a], [a])] could you think of a specification such that this function would be a work horse in implementing Data.List.Split.Internals and Data.List.Split? Alex had the point of view later in this thread that now that Data.List.Split exists, anything that we move to Data.List will be arbitrary in the cutoff. Duncan responded by advancing the idea that by examining what is happening in Haskell code, we may find a few useful functions for Data.List. My intermediate idea would be to examine Data.List.Split and Data.List.Split.Internals and think about factoring very general idioms that could be placed into Data.List, would be the work horse for implementing Data.List.Split.Internals and Data.List.Split, and would be in line with P1 to P7, which I acknowledge is my point of view. If a few words could be found that fit the above, they would merit Data.List. Finally, this whole thread brings up the question in my mind about module design. As work is put into Data.List.Split, what is the guiding principle that prevents it from becoming Data.List.Extensions or to be a bit more direct, Data.List.TheFunctionsThatWereForgotten? At , we have > An important caveat: we should strive to keep things flexible yet > SIMPLE. The more complicated things get, the closer this gets to just > being a general parsing or regex library. So the right balance needs > to be struck. I agree, and we have > A theoretical module which contains implementations/combinators for > implementing every possible method of list-splitting known to man. > This way no one has to argue about what the correct interface for > split is, we can just have them all. Is not this Data.List? In other words, what idea or theme does a new Haskell programmer use to decide to first look into Data.List as opposed to Data.List.Split and vice versa? Cheers, - Marcus -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:marcus@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75 From duncan.coutts at worc.ox.ac.uk Sun Jan 18 08:46:23 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 18 08:37:16 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <49730C53.7080009@gabriel.name> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> <20090111235612.GA9642@seas.upenn.edu> <49730C53.7080009@gabriel.name> Message-ID: <1232286383.8432.59.camel@localhost> On Sun, 2009-01-18 at 12:02 +0100, Marcus D. Gabriel wrote: > Brent Yorgey wrote: > >> P2. There should be no information loss, that is, keep the > delimiters, > >> keep the separators, keep the parts of the original list xs that > satisfy > >> a predicate p, do not lose information about the beginning and the > end > >> of the list relative to the first and last elements of the list > >> respectively. The user of the function decides what to discard. > >> > >> P3. A split list should be unsplittable so as to recover the original > >> list xs. (I made up the word unsplittable.) (P2 implies P3, but let us > >> state this anyway.) > > > > I'm not sure I agree with this. > > Thanks for stating this. Dropping P3 would change my > thinking about this topic, that is, if we drop P3, then > I would prefer that no splitter functions are added to > Data.List and that it is left as is. > > > The problem is that much (most?) of > > the time, people looking for a split function want to discard > > delimiters; for example, if you have a string like "foo;bar;baz" and > > you want to split it into ["foo","bar","baz"]. > > I agree with this comment when thinking about strings and what > I would do most of the time and from a pragmatic point of view. Indeed, the existing Data.List.words is certainly lossy and deliberately so. It's also useful and widely used. On the other hand it is a widely held view that Data.List.lines should not be lossy, ie that Data.List.unlines . Data.List.lines should be the identity. In the current implementation of lines . unlines it is not the case because of the way it handles a trailing newline. Duncan From marcus at gabriel.name Sun Jan 18 09:11:22 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Sun Jan 18 09:02:23 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <1232286383.8432.59.camel@localhost> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> <20090111235612.GA9642@seas.upenn.edu> <49730C53.7080009@gabriel.name> <1232286383.8432.59.camel@localhost> Message-ID: <4973388A.4070408@gabriel.name> Duncan Coutts wrote: > On Sun, 2009-01-18 at 12:02 +0100, Marcus D. Gabriel wrote: > >> Brent Yorgey wrote: >> >>>> P2. There should be no information loss, that is, keep the >>>> >> delimiters, >> >>>> keep the separators, keep the parts of the original list xs that >>>> >> satisfy >> >>>> a predicate p, do not lose information about the beginning and the >>>> >> end >> >>>> of the list relative to the first and last elements of the list >>>> respectively. The user of the function decides what to discard. >>>> >>>> P3. A split list should be unsplittable so as to recover the original >>>> list xs. (I made up the word unsplittable.) (P2 implies P3, but let us >>>> state this anyway.) >>>> >>> I'm not sure I agree with this. >>> >> Thanks for stating this. Dropping P3 would change my >> thinking about this topic, that is, if we drop P3, then >> I would prefer that no splitter functions are added to >> Data.List and that it is left as is. >> >> >>> The problem is that much (most?) of >>> the time, people looking for a split function want to discard >>> delimiters; for example, if you have a string like "foo;bar;baz" and >>> you want to split it into ["foo","bar","baz"]. >>> >> I agree with this comment when thinking about strings and what >> I would do most of the time and from a pragmatic point of view. >> > > Indeed, the existing Data.List.words is certainly lossyand deliberately > so. It's also useful and widely used. > > On the other hand it is a widely held view that Data.List.lines should > not be lossy, ie that Data.List.unlines . Data.List.lines should be the > identity. In the current implementation of lines . unlines it is not the > case because of the way it handles a trailing newline. > > Duncan > An argument for not placing any fundamental splitter functions in Data.List that are lossy if I ever read one. The user of these functions should explicitly choose to lose information. Then the documentation in the Haskell 98 report might have stated instead something like unlines . lines == id iff xs ends with '\n' which would at least be up front. Cheers, - Marcus From duncan.coutts at worc.ox.ac.uk Sun Jan 18 09:30:12 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 18 09:21:04 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <4973388A.4070408@gabriel.name> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> <20090111235612.GA9642@seas.upenn.edu> <49730C53.7080009@gabriel.name> <1232286383.8432.59.camel@localhost> <4973388A.4070408@gabriel.name> Message-ID: <1232289012.8432.81.camel@localhost> On Sun, 2009-01-18 at 15:11 +0100, Marcus D. Gabriel wrote: > Duncan Coutts wrote: > > On Sun, 2009-01-18 at 12:02 +0100, Marcus D. Gabriel wrote: > > > >> Brent Yorgey wrote: > >> > >>>> P2. There should be no information loss, that is, keep the > >>>> > >> delimiters, > >> > >>>> keep the separators, keep the parts of the original list xs that > >>>> > >> satisfy > >> > >>>> a predicate p, do not lose information about the beginning and the > >>>> > >> end > >> > >>>> of the list relative to the first and last elements of the list > >>>> respectively. The user of the function decides what to discard. > >>>> > >>>> P3. A split list should be unsplittable so as to recover the original > >>>> list xs. (I made up the word unsplittable.) (P2 implies P3, but let us > >>>> state this anyway.) > >>>> > >>> I'm not sure I agree with this. > >>> > >> Thanks for stating this. Dropping P3 would change my > >> thinking about this topic, that is, if we drop P3, then > >> I would prefer that no splitter functions are added to > >> Data.List and that it is left as is. > >> > >> > >>> The problem is that much (most?) of > >>> the time, people looking for a split function want to discard > >>> delimiters; for example, if you have a string like "foo;bar;baz" and > >>> you want to split it into ["foo","bar","baz"]. > >>> > >> I agree with this comment when thinking about strings and what > >> I would do most of the time and from a pragmatic point of view. > >> > > > > Indeed, the existing Data.List.words is certainly lossyand deliberately > > so. It's also useful and widely used. > > > > On the other hand it is a widely held view that Data.List.lines should > > not be lossy, ie that Data.List.unlines . Data.List.lines should be the > > identity. In the current implementation of lines . unlines it is not the > > case because of the way it handles a trailing newline. > An argument for not placing any fundamental splitter functions > in Data.List that are lossy if I ever read one. > > The user of these functions should explicitly choose to lose > information. Then the documentation in the Haskell 98 report > might have stated instead something like > > unlines . lines == id iff xs ends with '\n' > > which would at least be up front. Of course, the properties should have been specified. But are you also really saying that 'words' should have been omitted from the List module? Duncan From marcus at gabriel.name Sun Jan 18 11:14:50 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Sun Jan 18 11:05:52 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <1232289012.8432.81.camel@localhost> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> <20090111235612.GA9642@seas.upenn.edu> <49730C53.7080009@gabriel.name> <1232286383.8432.59.camel@localhost> <4973388A.4070408@gabriel.name> <1232289012.8432.81.camel@localhost> Message-ID: <4973557A.50108@gabriel.name> Duncan Coutts wrote: > On Sun, 2009-01-18 at 15:11 +0100, Marcus D. Gabriel wrote: > >> Duncan Coutts wrote: >> >>> On Sun, 2009-01-18 at 12:02 +0100, Marcus D. Gabriel wrote: >>> >>> >>>> Brent Yorgey wrote: >>>> >>>> >>>>>> P2. There should be no information loss, that is, keep the >>>>>> >>>>>> >>>> delimiters, >>>> >>>> >>>>>> keep the separators, keep the parts of the original list xs that >>>>>> >>>>>> >>>> satisfy >>>> >>>> >>>>>> a predicate p, do not lose information about the beginning and the >>>>>> >>>>>> >>>> end >>>> >>>> >>>>>> of the list relative to the first and last elements of the list >>>>>> respectively. The user of the function decides what to discard. >>>>>> >>>>>> P3. A split list should be unsplittable so as to recover the original >>>>>> list xs. (I made up the word unsplittable.) (P2 implies P3, but let us >>>>>> state this anyway.) >>>>>> >>>>>> >>>>> I'm not sure I agree with this. >>>>> >>>>> >>>> Thanks for stating this. Dropping P3 would change my >>>> thinking about this topic, that is, if we drop P3, then >>>> I would prefer that no splitter functions are added to >>>> Data.List and that it is left as is. >>>> >>>> >>>> >>>>> The problem is that much (most?) of >>>>> the time, people looking for a split function want to discard >>>>> delimiters; for example, if you have a string like "foo;bar;baz" and >>>>> you want to split it into ["foo","bar","baz"]. >>>>> >>>>> >>>> I agree with this comment when thinking about strings and what >>>> I would do most of the time and from a pragmatic point of view. >>>> >>>> >>> Indeed, the existing Data.List.words is certainly lossyand deliberately >>> so. It's also useful and widely used. >>> >>> On the other hand it is a widely held view that Data.List.lines should >>> not be lossy, ie that Data.List.unlines . Data.List.lines should be the >>> identity. In the current implementation of lines . unlines it is not the >>> case because of the way it handles a trailing newline. >>> > > >> An argument for not placing any fundamental splitter functions >> in Data.List that are lossy if I ever read one. >> >> The user of these functions should explicitly choose to lose >> information. Then the documentation in the Haskell 98 report >> might have stated instead something like >> >> unlines . lines == id iff xs ends with '\n' >> >> which would at least be up front. >> > > Of course, the properties should have been specified. But are you also > really saying that 'words' should have been omitted from the List > module? > Good catch, very good catch. Historically, it is there, so pragmatically, it stays. This go backs to my question about module, package, or library design. A set of Data.List design criteria could have been set up such that > unlines :: [String] -> String > unwords :: [String] -> String were not in List of Haskell 98 but in a smaller, specific module, something similar to Data.Char for example. I recall that when I was first learning Haskell and browsed List under Hugs, these two functions stood out compared to everything else simply because of their type signature. Well Duncan, you kind of undermined the perspective that I was trying to construct. You pushed my view to Alex's one about simply leaving Data.List alone and moving forward with Data.List.Split. Assuming this, then from a very pragmatic point of view, I would tell a new programmer to Haskell to study Data.List first, and if you do not find for what you are looking, try Data.List.Split. Still, I am curious what Brent will write. Cheers, - Marcus From bjorn.buckwalter at gmail.com Sun Jan 18 11:15:21 2009 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Sun Jan 18 11:06:18 2009 Subject: ANN: leapseconds-announced-2009 In-Reply-To: <1232257046.31376.31.camel@glastonbury> References: <8b2a1a960901162123w12d9cdcapbd7610ef7e568996@mail.gmail.com> <4972B77E.9090808@semantic.org> <8b2a1a960901172134l648db485sec2a9548d9b24c81@mail.gmail.com> <1232257046.31376.31.camel@glastonbury> Message-ID: <8b2a1a960901180815v7103b4c0v74dbb6620d4d3ac5@mail.gmail.com> On Sun, Jan 18, 2009 at 00:37, Ashley Yakeley wrote: > On Sun, 2009-01-18 at 00:34 -0500, Bjorn Buckwalter wrote: >> Thanks for the pointer. My "source" is the Earth Orientation Parameter >> (EOP) data at http://www.celestrak.com/SpaceData/; specifically I >> autogenerate the module from >> http://www.celestrak.com/SpaceData/eop19620101.txt. Probably looks >> more complicated than necessary but I'm parsing the file anyway for >> other purposes. > > With tz, though, you could discover the table at run-time and so be more > likely to be up to date. Ah yes. However, just like "time" this library does not attempt to solve that particular problem. The purpose of leapseconds-announced is to be dead easy to use (no IO and treading of the LeapSecondTable to the usage point), at the cost of longevity. Of course, as I pointed out in the announcement this trade-off isn't suitable for all applications. -Bjorn From thomas.dubuisson at gmail.com Sun Jan 18 12:04:17 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sun Jan 18 11:55:36 2009 Subject: Participation in Cabal / Hackage development In-Reply-To: <1232217658.8432.42.camel@localhost> References: <1232217658.8432.42.camel@localhost> Message-ID: <4c44d90b0901180904s2d4d8b06i66367638a4475ae1@mail.gmail.com> On Sat, Jan 17, 2009 at 6:40 PM, Duncan Coutts wrote: > All, > > I just mentioned ideas for Cabal 2 but I should also like to talk about > how we can go about increasing participation in the development effort. > We currently have nearly 200 open tickets which include many important > bugs and no shortage of good ideas for useful new features. > > Our limiting factor is developer time. > > Most of us use the Cabal / Hackage system in one way or another. Most of > us are familiar with its annoyances and limitations. Unfortunately the > number of people helping out has dropped rather in the past year or so. > > Perhaps we should run a little poll like the darcs hackers did to find > out what we could do to increase participation so we can get on with > building the tools that we all want, but a bit more quickly. First, I'd like to thank Duncan for all the hard work on Cabal/cabal-install. It seems you're a little irritated by the lack of fellow developers - which doesn't seem like an uncommon problem lately as we've seen from Darcs and also a YHC mailing from Neil. In my case, its been a lack of time and some shame over not following through last time I intended to contribute to Cabal. As for running a poll, I don't have anything to blame my lack of participation on except time. This situation will hopefully change over the coming months and I'll contribute to the community more. For those looking at contributing, don't go to the cabal home page but the hackage homepage. For example, I just found: http://hackage.haskell.org/trac/hackage/wiki/SourceGuide Thomas From benja.fallenstein at gmail.com Sun Jan 18 12:17:09 2009 From: benja.fallenstein at gmail.com (Benja Fallenstein) Date: Sun Jan 18 12:08:07 2009 Subject: Improved documentation for Bool (Was: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt) In-Reply-To: References: <20090115153438.GA1340@hustlerturf.com> <496F6128.7080108@complete.org> <20090117211232.lcjuj0m4w8w0k0cg-nwo@webmail.spamcop.net> <20090118134157.GA4458@soi.city.ac.uk> Message-ID: On Sun, Jan 18, 2009 at 5:48 PM, wrote: > I noticed the Bool datatype isn't well documented. Since Bool is not a > common English word, I figured it could use some haddock to help clarify it > for newcomers. > > -- |The Bool datatype is named after George Boole (1815-1864). > -- The Bool type is the coproduct of the terminal object with itself. Russell, this does seem like it might be very helpful, but it might be useful to include a note about what category you are working in. People may sometimes naively assume that one is working in the category of Haskell/Hugs/GHC data types and Haskell functions, in which there are no terminal -- or initial -- objects ('undefined' and 'const undefined' are distinct maps between any two objects X and Y), or else in the similar category without lifted bottoms, in which the empty type is terminal and the unit type isn't ('undefined' and 'const ()' are both maps from any object X to the unit type). These niceties will not confuse the advanced reader, but it may help the beginner if you are more explicit. - Benja P.S. :-) From scsibug at imap.cc Sun Jan 18 17:19:30 2009 From: scsibug at imap.cc (Greg Heartsfield) Date: Sun Jan 18 17:10:28 2009 Subject: patch: Network.URI relativeFrom documentation Message-ID: <20090118221930.GA24612@pmac.gateway.2wire.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20090118/0ccd4584/attachment.bin From byorgey at seas.upenn.edu Mon Jan 19 13:41:19 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Mon Jan 19 13:32:12 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <49730C53.7080009@gabriel.name> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> <20090111235612.GA9642@seas.upenn.edu> <49730C53.7080009@gabriel.name> Message-ID: <20090119184119.GA15805@seas.upenn.edu> On Sun, Jan 18, 2009 at 12:02:43PM +0100, Marcus D. Gabriel wrote: > > But, > > as you noted, throwing away information like this is bad from an > > elegance/formal properties point of view. This is exactly why I > > designed the Data.List.Split library as I did: the core internal > > splitting function is information-preserving, and by using various > > combinators the user can choose to throw away whatever information > > they are not interested in. > > Perfect. So, as you see it, are there one, two, or three functions > in or hiding in Data.List.Split.Internals that can be factored and > placed into Data.List that are in line with P1 to P7? You do not > actually need to agree to P1 to P7, it is a conceptual exercise. > The idea is that Data.List.Split would flow more naturally from > Data.List with these few functions added to it. Not really. You are welcome to look at the source of Data.List.Split.Internals yourself; you will see that the core functions on top of which everything else is implemented use various internal data types, to more accurately reflect the richness of information that is present in the most general case. If we were to add these core functions to Data.List.Split, we would have to add these new data types as well, which seems to go against the spirit of simplicity found in Data.List. And in any case, the core functions are not very easy or convenient to use on their own. Let me be clear---I am not against adding some splitting functions to Data.List, if consensus as to what these functions should be is reached. But literally pulling a few things out of Data.List.Split as you propose is not the way to go, as I think you will agree if you look at the source. > Finally, as concrete examples or to clarify points, the words > split, delimiter, separator and variations thereof have been > used. This already implies a theme. Do you conceptualize > of Data.List.Split as primarily to help programmers from other > backgrounds to be able to manipulate strings, that is, supply > some nice idioms but generalized from [Char] to [a]? No, I see it as a useful tool for manipulating lists in general. > If I were to write > > organizeBy :: ([a] -> Bool) -> [a] -> [([a], [a])] > > could you think of a specification such that this function > would be a work horse in implementing Data.List.Split.Internals > and Data.List.Split? I could, but I think the result would be rather uglier and harder to understand than the current implementation. > Finally, this whole thread brings up the question in my mind > about module design. As work is put into Data.List.Split, what > is the guiding principle that prevents it from becoming > Data.List.Extensions or to be a bit more direct, > Data.List.TheFunctionsThatWereForgotten? Are you serious? It seems quite clear to me that Data.List.Split will *not* turn into that. For one thing, it contains only list-splitting functions; for another thing, I do not foresee putting that much more work into it. > > A theoretical module which contains implementations/combinators for > > implementing every possible method of list-splitting known to man. > > This way no one has to argue about what the correct interface for > > split is, we can just have them all. > > Is not this Data.List? In other words, what idea or theme does > a new Haskell programmer use to decide to first look into Data.List > as opposed to Data.List.Split and vice versa? I was being sort of facetious in that quote. =) -Brent From marcus at gabriel.name Mon Jan 19 15:45:38 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Mon Jan 19 15:36:35 2009 Subject: Proposal for Data.List.splitBy In-Reply-To: <20090119184119.GA15805@seas.upenn.edu> References: <4961265C.2090709@gabriel.name> <1231620312.4794.10.camel@localhost> <496A4531.9050902@gabriel.name> <20090111235612.GA9642@seas.upenn.edu> <49730C53.7080009@gabriel.name> <20090119184119.GA15805@seas.upenn.edu> Message-ID: <4974E672.7010109@gabriel.name> Brent Yorgey wrote: > Not really. You are welcome to look at the source of > Data.List.Split.Internals yourself; Fair enough, I will look at it. > > Let me be clear---I am not against adding some splitting functions to > Data.List, if consensus as to what these functions should be is > reached. Not to worry, this was clear to me. I am sorry if my thread obscured this. > If I were to write > > organizeBy :: ([a] -> Bool) -> [a] -> [([a], [a])] > > could you think of a specification such that this function > would be a work horse in implementing Data.List.Split.Internals > and Data.List.Split? > > I could, but I think the result would be rather uglier and harder to > understand than the current implementation. I understand. I do not perceive that I have expressed very well the way that I am trying to conceptualise of this, but the observation of yours above makes me conclude that adding a few splitter functions to Data.List would just be arbitrary. (Alex already stated this point of view.) > > Finally, this whole thread brings up the question in my mind > about module design. As work is put into Data.List.Split, what > is the guiding principle that prevents it from becoming > Data.List.Extensions or to be a bit more direct, > Data.List.TheFunctionsThatWereForgotten? > > Are you serious? Well, actually yes, I was serious, but see below. > It seems quite clear to me that Data.List.Split will > *not* turn into that. For one thing, it contains only list-splitting > functions; for another thing, I do not foresee putting that much more > work into it. Ok, I was on a tangent. Given this above, no, I was not serious. > A theoretical module which contains implementations/combinators for > implementing every possible method of list-splitting known to man. > This way no one has to argue about what the correct interface for > split is, we can just have them all. >> Is not this Data.List? In other words, what idea or theme does >> a new Haskell programmer use to decide to first look into Data.List >> as opposed to Data.List.Split and vice versa? > > I was being sort of facetious in that quote. =) Ok, once again, I was on a tangent and drifting off topic. In my defence, my parents-in-law were here for my Son's birthday which in Alsace means a lot of good food and wine which also means I should not write e-mails at night after such an event :). -- So, to conclude, when I first started using Haskell 98, at one point in time I was looking for some splitter idioms in the List module. The functions break and span were close, but not it. The functions > lines :: String -> [String] > unlines :: [String] -> String > > words :: String -> [String] > unwords :: [String] -> String seemed out of place compared to everything else in the List module just because of their type signature whereupon it seemed even more odd that I could not just split /etc/passwd or /etc/group on ':' with something directly suited to the task that was in the List module as an example. Thanks for the thread, - Marcus -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:marcus@gabriel.name From kaol at iki.fi Mon Jan 19 20:06:50 2009 From: kaol at iki.fi (Kari Pahula) Date: Mon Jan 19 19:57:43 2009 Subject: Copyright for readline library In-Reply-To: <20090117091525.GA5939@piperka.net> References: <20090117091525.GA5939@piperka.net> Message-ID: <20090120010650.GA26357@piperka.net> On Sat, Jan 17, 2009 at 11:15:25AM +0200, Kari Pahula wrote: > I would use readline instead of editline to build ghc6 on Debian, but In the end, I didn't. At first, it wouldn't detect and use libedit-dev but on the later builds, I saw that it did. Some problem between the chair and the monitor, most likely. Still, this doesn't look good and bears to be fixed, IMHO: > -- Copyright : (c) unknown From duncan.coutts at worc.ox.ac.uk Tue Jan 20 05:39:30 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 20 05:30:50 2009 Subject: [Haskell-cafe] Cabal dependencies In-Reply-To: <50b5ae760901151538t16a35203o5b409202b9588929@mail.gmail.com> References: <50b5ae760901151538t16a35203o5b409202b9588929@mail.gmail.com> Message-ID: <1232447970.8432.173.camel@localhost> On Thu, 2009-01-15 at 18:38 -0500, Stephen Hicks wrote: > Hi, > > I'm having some difficulty specifying dependencies in my .cabal file > for a package I'm looking to upload to hackage soon. The difficulty > is as follows. I basically want to specify > parsec (>= 2.1 && < 3.0.0) || (> 3.0.0 && < 4) When we first introduced this kind of version range syntax we were unsure if it was too general or not. We want to be able to translate into other systems and they're typically more restrictive. Internally we can easily represent the above expression as it uses arbitrary unions and intersections. However the external parser still only allows two clauses (I think it's two). Personally I'm all for lifting that restriction. Yes it makes it a bit harder for translating into some systems but I don't see that as a real issue. If the package really does require the more complex version range then forcing the package author to lie by using a less expressive syntax does not help. We can still make the same choice at the point when we translate into native packages. Also, as it happens there is a way of getting around the restriction anyway, which makes the restriction effectively pointless. That is by listing the same dependency more than once. All the version constraints must be satisfied so you can write: build-depends: parsec >= 2.1 && < 4, parsec < 3.0.0 || > 3.0.0 (have I got that right?) So I'd be interested to get feedback on lifting the restriction and the impact that might have on translation into native packages. > The problem is that 3.0.0 as it exists on hackage is missing a > constructor that I need (namely, Postfix, in the compatibility > module). The bug was fixed and will presumably work fine if a newer > version of parsec is ever uploaded to hackage, and my package works > fine with older parsecs as well - I just want to exclude this one > version. How can I go about doing that? Try the above. > A secondary question is this - I can actually compile with version > 3.0.0 by just not using this constructor, although it does reduce the > package's functionality. I've seen flags in various .cabal files, and > presumably I could invent a flag to make it work with 3.0.0, but I'm > confused about how these flags are set. Yes, if you need compatibility with older versions of Cabal then you'd need to use a flag. If you're prepared to require Cabal-1.6 or later then you can use the cpp macro: #if MIN_VERSION_parsec(3,0,0) though of course that only gives you >= 3.0.0, you'd need more tricky combinations to get == 3.0.0, perhaps by assuming >= 3.0.1 is ok. For older Cabal versions the main option is a flag, like so: flag parsec3 ... if flag(parsec3) build-depends: parsec == 3.0.0 cpp-options: -DUSING_BAD_PARSEC else build-depends: parsec > 3.0.0 || < 3.0.0 > Specifically, cabal-install has never asked me anything about flags, > so what's the point? Or does it automatically set whichever flags > satisfy the dependencies? It tries to work out what flags to set automatically (based on the platform, the available packages and flag defaults in each package). You can override them from the command line if you want to or need to. Duncan From duncan.coutts at worc.ox.ac.uk Tue Jan 20 06:46:17 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 20 06:37:05 2009 Subject: Participation in Cabal / Hackage development In-Reply-To: <4c44d90b0901180904s2d4d8b06i66367638a4475ae1@mail.gmail.com> References: <1232217658.8432.42.camel@localhost> <4c44d90b0901180904s2d4d8b06i66367638a4475ae1@mail.gmail.com> Message-ID: <1232451977.8432.193.camel@localhost> On Sun, 2009-01-18 at 17:04 +0000, Thomas DuBuisson wrote: > On Sat, Jan 17, 2009 at 6:40 PM, Duncan Coutts > wrote: > > All, > > > > I just mentioned ideas for Cabal 2 but I should also like to talk about > > how we can go about increasing participation in the development effort. > > We currently have nearly 200 open tickets which include many important > > bugs and no shortage of good ideas for useful new features. > > > > Our limiting factor is developer time. > > > > Most of us use the Cabal / Hackage system in one way or another. Most of > > us are familiar with its annoyances and limitations. Unfortunately the > > number of people helping out has dropped rather in the past year or so. > > > > Perhaps we should run a little poll like the darcs hackers did to find > > out what we could do to increase participation so we can get on with > > building the tools that we all want, but a bit more quickly. > > First, I'd like to thank Duncan for all the hard work on > Cabal/cabal-install. Ta :-) > It seems you're a little irritated by the lack > of fellow developers - which doesn't seem like an uncommon problem > lately as we've seen from Darcs and also a YHC mailing from Neil. I'm not irritated, but I'm well aware that we have a lot of work that everyone wants us to do and we're not getting it done as quickly as anybody would like. > In my case, its been a lack of time and some shame over not following > through last time I intended to contribute to Cabal. As for running a > poll, I don't have anything to blame my lack of participation on > except time. This situation will hopefully change over the coming > months and I'll contribute to the community more. Yes, I know lack of time is the main thing for most people. I just want to check that there are not too many other hurdles in people's way. For example people used to complain about the difficulty in understanding the code. I hope that's improved a bit and that the code guide you mention helps. Improving it further is of course one of the things we need help with. There may be other things of course that I can't see, being a bit too close to the project. I'm glad to hear you're going to try to make time. It's much appreciated. > For those looking at contributing, don't go to the cabal home page but > the hackage homepage. For example, I just found: > > http://hackage.haskell.org/trac/hackage/wiki/SourceGuide Yes, amongst other resources linked from http://hackage.haskell.org/trac/hackage/wiki/ Duncan From duncan.coutts at worc.ox.ac.uk Tue Jan 20 07:14:22 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 20 07:05:09 2009 Subject: Participation in Cabal / Hackage development In-Reply-To: <1232217658.8432.42.camel@localhost> References: <1232217658.8432.42.camel@localhost> Message-ID: <1232453662.8432.209.camel@localhost> On Sat, 2009-01-17 at 18:40 +0000, Duncan Coutts wrote: > All, > > I just mentioned ideas for Cabal 2 but I should also like to talk about > how we can go about increasing participation in the development effort. > We currently have nearly 200 open tickets which include many important > bugs and no shortage of good ideas for useful new features. > > Our limiting factor is developer time. A secondary issue is design. We get lots of feature requests "there should be a way do to X". But there's quite a bit of work to get from there to a point where we can start coding. It's not even the design of the code that's the issue, but how the feature really should work. What the user interaction should be and how it should interact with other features. We've got dozens of tickets in our tracker in this state where they're not yet ready for someone to pick them up and implement it in an evening. This is certainly a barrier for anyone interested in Hacking on Cabal, they're not going to pick these tickets where it's not at all clear what they would have to implement. This is particularly noticeable if you look at the tickets not assigned to any milestone. See the last section in this report: http://hackage.haskell.org/trac/hackage/report/12 A few random examples: #214 Package security #293 allow installation of non-haskell or haskell script executables #330 Support general documentation, not just haddock #364 cabal should allow source to be installed with/added to binary packages #457 cabal list: filter by pattern #237 Support addition of links to Cabal project pages #313 line counting Perhaps we need to make this more explicit in our bug tracker, have a milestone for tickets in limbo that need more design work. It might help to draw attention to them from people who want to see the feature implemented if we make it clear we cannot start work on them until various design issues are clarified. Duncan From alistair at abayley.org Tue Jan 20 11:27:42 2009 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jan 20 11:18:34 2009 Subject: Main-Is not creating executable Message-ID: <79d7c4980901200827s2234f87fp496ca8af0282d1a5@mail.gmail.com> I have this in Takusen.cabal: Executable miniunit_tests Main-Is: Test/MiniUnit/Main.hs Build-Depends: base, mtl Extensions: CPP CPP-Options: "-DNEW_EXCEPTION" (as well as the Library section). When it builds, the modules compile fine, but then I get: Warning: output was redirected with -o, but no output will be generated because there is no Main module. The ghc command (from setup -v build): Building executable: miniunit_tests... Creating dist\build\miniunit_tests (and its parents) Creating dist\build\miniunit_tests\miniunit_tests-tmp (and its parents) c:\ghc\ghc-6.10.1\bin\ghc.exe -o dist\build\miniunit_tests\miniunit_tests.exe -- make -hide-all-packages -no-user-package-conf -i -idist\build\miniunit_tests\min iunit_tests-tmp -i. -idist\build\autogen -Idist\build\autogen -Idist\build\miniu nit_tests\miniunit_tests-tmp -optP-DNEW_EXCEPTION -optP-include -optPdist\build\ autogen\cabal_macros.h -odir dist\build\miniunit_tests\miniunit_tests-tmp -hidir dist\build\miniunit_tests\miniunit_tests-tmp -stubdir dist\build\miniunit_tests \miniunit_tests-tmp -package QuickCheck-1.2.0.0 -package Takusen-0.8.4 -package base-4.0.0.0 -package mtl-1.1.0.2 -package old-time-1.0.0.1 -package time-1.1.2. 2 -O -XCPP .\Test/MiniUnit/Main.hs I don't see ghc flag -main-is in here. What do I need to do to get it to build the executable? Also, is there a way to get it to just build miniunit_tests.exe i.e. without rebuilding the library and another executable target? Alistair From dominic.steinitz at blueyonder.co.uk Tue Jan 20 11:56:15 2009 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Tue Jan 20 11:47:21 2009 Subject: Bug in Cabal? Message-ID: I couldn't seem to logon to the trac to report this. I'm working on windows (not linux as the chmod might suggest). zlib-0.5.0.0>runghc Setup.hs configure --package-db=..\..\ghc\ghc-6.10.1\fpf.package.conf --docdir=..\..\haskell_packages\doc\zlib-0.5.0.0 --libdir=..\..\haskell_packages --bindir=..\..\haskell_packages\bin Configuring zlib-0.5.0.0... zlib-0.5.0.0>runghc Setup.hs build Preprocessing library zlib-0.5.0.0... Building zlib-0.5.0.0... ghc-6.10.1\bin\ar.exe: creating dist\build\libHSzlib-0.5.0.0.a zlib-0.5.0.0>runghc Setup.hs install Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: permission denied (Access is denied.) Cabal seesm to create certain things as read only. I can work around this by chmod a+w ..\ThirdParty\haskell_packages\zlib-0.5.0.0\ghc-6.10.1\include\* chmod a+w ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* rm ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* I suspect most people haven't tripped over this as once something is installed they don't tend to install it again. Dominic. From libraries at haskell.org Tue Jan 20 14:30:32 2009 From: libraries at haskell.org (network) Date: Tue Jan 20 14:21:28 2009 Subject: [network] #2: Socket related IO cannot be be interrupted on Windows Message-ID: <053.05e53ff0cd744a94c706df2d01db2402@haskell.org> #2: Socket related IO cannot be be interrupted on Windows ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Originally reported here: http://hackage.haskell.org/trac/ghc/ticket/2943 ---- While playing with socket communication, I noticed that socket IO cannot be interrupted or killed. The attached program simply hangs, irregardless whether is was complied using the -threaded flag or not. {{{ import Network import Control.Concurrent main = withSocketsDo $ do tid <- forkIO $ do s <- listenOn (PortNumber 1234) accept s return () threadDelay 2000000 killThread tid }}} -- Ticket URL: network Networking-related facilities From alistair at abayley.org Tue Jan 20 15:30:45 2009 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jan 20 15:21:35 2009 Subject: Main-Is not creating executable In-Reply-To: <79d7c4980901200827s2234f87fp496ca8af0282d1a5@mail.gmail.com> References: <79d7c4980901200827s2234f87fp496ca8af0282d1a5@mail.gmail.com> Message-ID: <79d7c4980901201230h65e43ffahc6fb18efc4d49432@mail.gmail.com> 2009/1/20 Alistair Bayley : > I have this in Takusen.cabal: > > Executable miniunit_tests > Main-Is: Test/MiniUnit/Main.hs > Build-Depends: base, mtl > Extensions: CPP > CPP-Options: "-DNEW_EXCEPTION" > > (as well as the Library section). When it builds, the modules compile > fine, but then I get: > > Warning: output was redirected with -o, but no output will be > generated because there is no Main module. My fault. Turns out the module in Test/MiniUnit/Main.hs must be just Main, not Test.MiniUnit.Main i.e. module Main where... But the second question still stands: can I selectively build the various targets in the .cabal file? Alistair From libraries at haskell.org Tue Jan 20 15:53:45 2009 From: libraries at haskell.org (network) Date: Tue Jan 20 15:44:44 2009 Subject: [network] #3: Cannot call connect with a socket that is already bound. Message-ID: <053.8e75acf45ae07ca636cefdaa560d2a7a@haskell.org> #3: Cannot call connect with a socket that is already bound. ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Originally reported here: http://hackage.haskell.org/trac/ghc/ticket/2784 ---- {{{ > import Network.Socket > sock <- socket AF_INET Datagram 0 Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.0.1 ... linking ... done. > bindSocket sock (SockAddrInet aNY_PORT iNADDR_ANY) > connect sock undefined *** Exception: user error (connect: can't peform connect on socket in status Bound) }}} Network.Socket.connect checks the !SocketStatus of the socket: {{{ if currentStatus /= NotConnected }}} From [http://www.opengroup.org/onlinepubs/000095399/functions/connect.html The Open Group Base Specifications Issue 6]: "If the socket has not already been bound to a local address, connect() shall bind it to an address which, unless the socket's address family is AF_UNIX, is an unused local address." -- Ticket URL: network Networking-related facilities From libraries at haskell.org Tue Jan 20 15:58:59 2009 From: libraries at haskell.org (network) Date: Tue Jan 20 15:49:52 2009 Subject: [network] #4: sIsReadable and sIsWritable return true after socket is closed. Message-ID: <053.f8bcb4ffb86b3c6f10d5d6a2144e0531@haskell.org> #4: sIsReadable and sIsWritable return true after socket is closed. ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ First reported here: http://hackage.haskell.org/trac/ghc/ticket/2774 ---- {{{ > import Network.Socket > s <- socket AF_INET Stream 6 Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.0.1 ... linking ... done. > bindSocket s (SockAddrInet 0 0) > listen s 1 > sClose s > sIsReadable s True > sIsWritable s True }}} sIsReadable and sIsWritable return true when the !SocketStatus is Connected or Listening. sClose does not change the status. Perhaps a new status Closed should be added to !SocketStatus. -- Ticket URL: network Networking-related facilities From libraries at haskell.org Tue Jan 20 16:18:04 2009 From: libraries at haskell.org (network) Date: Tue Jan 20 16:08:56 2009 Subject: [network] #5: getAddrInfo and addrFamily not in scope on Windows GHC 6.8 Message-ID: <053.0643763ccd7cb6ed3024ae5cebbb6b95@haskell.org> #5: getAddrInfo and addrFamily not in scope on Windows GHC 6.8 ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Originally reported here: http://hackage.haskell.org/trac/ghc/ticket/2726 ---- import Network.Socket ... getAddrInfo ... addrFamily -- gives me not in scope on Windows. The same code works on Unix. ---- Looking at the code, these are only available if `IPV6_SOCKET_SUPPORT` is defined. I don't know more than that off the top of my head. -- Ticket URL: network Networking-related facilities From greg at gregorycollins.net Tue Jan 20 16:18:38 2009 From: greg at gregorycollins.net (Gregory Collins) Date: Tue Jan 20 16:09:31 2009 Subject: Bug in Cabal? In-Reply-To: (Dominic Steinitz's message of "Tue, 20 Jan 2009 16:56:15 +0000 (UTC)") References: Message-ID: Dominic Steinitz writes: > I couldn't seem to logon to the trac to report this. I'm working on windows > (not linux as the chmod might suggest). > > zlib-0.5.0.0>runghc Setup.hs > configure --package-db=..\..\ghc\ghc-6.10.1\fpf.package.conf > --docdir=..\..\haskell_packages\doc\zlib-0.5.0.0 > --libdir=..\..\haskell_packages > --bindir=..\..\haskell_packages\bin > Configuring zlib-0.5.0.0... > > zlib-0.5.0.0>runghc Setup.hs build > Preprocessing library zlib-0.5.0.0... > Building zlib-0.5.0.0... > ghc-6.10.1\bin\ar.exe: creating dist\build\libHSzlib-0.5.0.0.a > > zlib-0.5.0.0>runghc Setup.hs > install > Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: > permission denied (Access is denied.) This couldn't be a umask issue, could it? G. -- Gregory Collins From duncan.coutts at worc.ox.ac.uk Tue Jan 20 19:11:37 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 20 19:02:22 2009 Subject: Main-Is not creating executable In-Reply-To: <79d7c4980901201230h65e43ffahc6fb18efc4d49432@mail.gmail.com> References: <79d7c4980901200827s2234f87fp496ca8af0282d1a5@mail.gmail.com> <79d7c4980901201230h65e43ffahc6fb18efc4d49432@mail.gmail.com> Message-ID: <1232496697.8432.215.camel@localhost> On Tue, 2009-01-20 at 20:30 +0000, Alistair Bayley wrote: > 2009/1/20 Alistair Bayley : > > I have this in Takusen.cabal: > > > > Executable miniunit_tests > > Main-Is: Test/MiniUnit/Main.hs > > Build-Depends: base, mtl > > Extensions: CPP > > CPP-Options: "-DNEW_EXCEPTION" > > > > (as well as the Library section). When it builds, the modules compile > > fine, but then I get: > > > > Warning: output was redirected with -o, but no output will be > > generated because there is no Main module. > > > My fault. Turns out the module in Test/MiniUnit/Main.hs must be just > Main, not Test.MiniUnit.Main i.e. > module Main where... Right. See http://hackage.haskell.org/trac/hackage/ticket/179 > But the second question still stands: can I selectively build the > various targets in the .cabal file? Not yet, sorry. This is something that we will be able to do easily with the Cabal-2.x features, though we may well be able to do it before then, at least for "big" targets like executables and libs. So it's worth filing a feature request ticket. I usually ask for suggestions for the user interaction but in this case the obvious seems to be: cabal build miniunit_tests Btw, what you really want here is proper support for testsuites, rather than executable: http://hackage.haskell.org/trac/hackage/ticket/215 Duncan From duncan.coutts at worc.ox.ac.uk Wed Jan 21 04:19:09 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 21 04:09:56 2009 Subject: Bug in Cabal? In-Reply-To: References: Message-ID: <1232529549.8432.229.camel@localhost> On Tue, 2009-01-20 at 16:56 +0000, Dominic Steinitz wrote: > I couldn't seem to logon to the trac to report this. The details are on the hackage trac front page: http://hackage.haskell.org/trac/hackage/ If you don't want to register an account you can use the guest account. User name is "guest" and password "haskell'" (note the apostrophe at the end). > I'm working on windows (not linux as the chmod might suggest). XP or Vista? > zlib-0.5.0.0>runghc Setup.hs > configure --package-db=..\..\ghc\ghc-6.10.1\fpf.package.conf > --docdir=..\..\haskell_packages\doc\zlib-0.5.0.0 > --libdir=..\..\haskell_packages > --bindir=..\..\haskell_packages\bin > Configuring zlib-0.5.0.0... > > zlib-0.5.0.0>runghc Setup.hs build > Preprocessing library zlib-0.5.0.0... > Building zlib-0.5.0.0... > ghc-6.10.1\bin\ar.exe: creating dist\build\libHSzlib-0.5.0.0.a > > zlib-0.5.0.0>runghc Setup.hs > install > Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: > permission denied (Access is denied.) > > Cabal seesm to create certain things as read only. I can work around this by We use System.Directory.copyFile which copies the permissions from the original file to the destination file. Could you confirm that this is working correctly. Are the permissions of the source and destination files exactly the same? Was the source file created read-only? > chmod a+w ..\ThirdParty\haskell_packages\zlib-0.5.0.0\ghc-6.10.1\include\* > > chmod a+w ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* > > rm ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* > > I suspect most people haven't tripped over this as once something is installed > they don't tend to install it again. This looks like: http://hackage.haskell.org/trac/hackage/ticket/454 But for every file not just .exe files. For .exe files Cabal does the permission copying itself. I do not understand why it just started occurring, since ghc-6.8 and 6.10 seem to have the same code for copyFile and copyPermissions. We'll need more help to understand and fix this one. I think the right solution will be that we do not copy permissions at all but either set permissions to precise values or do nothing and use defaults. On Unix we have a similar issue with umasks. Duncan From schlepptop at henning-thielemann.de Wed Jan 21 05:20:13 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 21 05:05:06 2009 Subject: Main-Is not creating executable In-Reply-To: <1232496697.8432.215.camel@localhost> References: <79d7c4980901200827s2234f87fp496ca8af0282d1a5@mail.gmail.com> <79d7c4980901201230h65e43ffahc6fb18efc4d49432@mail.gmail.com> <1232496697.8432.215.camel@localhost> Message-ID: <4976F6DD.4030808@henning-thielemann.de> Duncan Coutts schrieb: >> But the second question still stands: can I selectively build the >> various targets in the .cabal file? > > Not yet, sorry. I use to selectively build executables depending on Cabal flags, where the executable section starts with Executable test If !flag(buildTests) Buildable: False With cabal configure -fbuildTests I enable building them. From Alistair.Bayley at invesco.com Wed Jan 21 06:10:25 2009 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Wed Jan 21 06:01:39 2009 Subject: Main-Is not creating executable In-Reply-To: <4976F6DD.4030808@henning-thielemann.de> References: <79d7c4980901200827s2234f87fp496ca8af0282d1a5@mail.gmail.com><79d7c4980901201230h65e43ffahc6fb18efc4d49432@mail.gmail.com><1232496697.8432.215.camel@localhost> <4976F6DD.4030808@henning-thielemann.de> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA911025DE6@GBLONXMB02.corp.amvescap.net> > From: libraries-bounces@haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Henning Thielemann > Duncan Coutts schrieb: > > >> But the second question still stands: can I selectively build the > >> various targets in the .cabal file? > > > > Not yet, sorry. > > I use to selectively build executables depending on Cabal flags, where > the executable section starts with > > Executable test > If !flag(buildTests) > Buildable: False > > > With cabal configure -fbuildTests I enable building them. Cool. This morning it occurred to me that flags might be usable for this. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From dominic.steinitz at blueyonder.co.uk Wed Jan 21 13:01:39 2009 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Wed Jan 21 12:52:36 2009 Subject: Bug in Cabal? References: <1232529549.8432.229.camel@localhost> Message-ID: Duncan Coutts worc.ox.ac.uk> writes: > The details are on the hackage trac front page: > http://hackage.haskell.org/trac/hackage/ > If you don't want to register an account you can use the guest account. > User name is "guest" and password "haskell'" (note the apostrophe at the > end). I did try but got the following. Forbidden TICKET_CREATE privileges are required to perform this operation I believe there is some interaction between the proxy we use at work and the trac. Other users in our organisation have also had the same problem. > XP or Vista? XP > > Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: > > permission denied (Access is denied.) > > > > Cabal seesm to create certain things as read only. I can work around this by > > We use System.Directory.copyFile which copies the permissions from the > original file to the destination file. Could you confirm that this is > working correctly. Are the permissions of the source and destination > files exactly the same? Was the source file created read-only? haskell_packages is empty to start with and the package gets built successfully. Attributes are copied over successfully. The actual source files *are* read only as they are kept in our source control system which marks them this way for unchecked out files. Built files are read / write. >ls -ltr haskell_packages\doc\zlib-0.5.0.0 total 2 -r--r--r-- 1 user group 1327 Jan 21 11:37 LICENSE When I rebuild the package *without* having cleaned out haskell_packages then I get the access error. I think this is because cabal (copyFile) doesn't want to overwrite a read only file even though the directory permissions should allow it to do so. > This looks like: > http://hackage.haskell.org/trac/hackage/ticket/454 > > But for every file not just .exe files. For .exe files Cabal does the > permission copying itself. I do not understand why it just started > occurring, since ghc-6.8 and 6.10 seem to have the same code for > copyFile and copyPermissions. I don't seem to have the problem for binaries (because cabal builds them afresh with read / write permission) so I don't know if it's related or not (but it seems unlikely). >ls -ltr haskell_packages\bin total 18004 -rwxrwxrwx 1 user group 4066816 Jan 21 11:38 cabal.exe -rwxrwxrwx 1 user group 13649408 Jan 21 11:39 haddock.exe -rwxrwxrwx 1 user group 718336 Jan 21 11:39 HsColour.exe > We'll need more help to understand and fix this one. I think the right > solution will be that we do not copy permissions at all but either set > permissions to precise values or do nothing and use defaults. On Unix we That seems the correct thing to do. Let me know if you need any more information. Dominic. From dons at galois.com Wed Jan 21 13:41:25 2009 From: dons at galois.com (Don Stewart) Date: Wed Jan 21 13:32:34 2009 Subject: 1000 libraries Message-ID: <20090121184125.GA19671@scytale.galois.com> We've done it! http://hackage.haskell.org/cgi-bin/hackage-scripts/stats 274 users have uploaded 3161 versions of 1000 packages. Thanks everyone who has written a library or tool or app and released it, for making hackage and cabal a success! This has gone further, perhaps more than anything else, towards making it possible to use Haskell in industry. The lucky 1000th package is: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/threadPool-0.1 threadPool: Runs other programs in the manner of a thread pool Takes a single, optional argument which is the number of threads (the default is three). Give it the commands to run, one per line, through standard input. Author Brian Jaress Now, onto 10k libraries! -- Don From kyagrd at gmail.com Wed Jan 21 14:42:40 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Wed Jan 21 14:35:50 2009 Subject: 1000 libraries In-Reply-To: <20090121184125.GA19671@scytale.galois.com> References: <20090121184125.GA19671@scytale.galois.com> Message-ID: Don Stewart wrote: > We've done it! Thanks for the good news. Maybe it's already getting more important organizing existing uesful set of libraries as mata-packages. Are there updates on haskell-platform? From alistair at abayley.org Thu Jan 22 06:56:08 2009 From: alistair at abayley.org (Alistair Bayley) Date: Thu Jan 22 06:46:53 2009 Subject: cabal-1.6.0.1 won't build with ghc-6.6.1 in WinXP Message-ID: <79d7c4980901220356x5d80a35asa662e27b00b5cca6@mail.gmail.com> I'm trying to build cabal-1.6.0.1 with ghc-6.6.1 on WinXP. "setup -v configure" fails with this output: Configuring Cabal-1.6.0.1... Flags chosen: base3=False, base4=False Dependency base <3: using base-2.1.1 Dependency filepath >=1 && <1.2: using filepath-1.0 Using Cabal-0 compiled by ghc-6.6 Using compiler: ghc-6.6.1 Using install prefix: C:\Program Files\Haskell Binaries installed in: C:\Program Files\Haskell\bin Libraries installed in: C:\Program Files\Haskell\Cabal-1.6.0.1\ghc-6.6.1 Private binaries installed in: C:\Program Files\Haskell\Cabal-1.6.0.1 Data files installed in: C:\Program Files\Haskell\Cabal-1.6.0.1 Documentation installed in: C:\Program Files\Haskell\doc\Cabal-1.6.0.1 No alex found Using ar found on system at: c:\ghc\ghc-6.6.1\bin\ar.exe No c2hs found No cpphs found No ffihugs found Using gcc version 3.4.2 found on system at: c:\ghc\ghc-6.6.1\gcc.exe Using ghc version 6.6.1 found on system at: c:\ghc\ghc-6.6.1\bin\ghc.exe Using ghc-pkg version 6.6.1 found on system at: c:\ghc\ghc-6.6.1\bin\ghc-pkg.exe No greencard found No haddock found No happy found No hmake found Using hsc2hs version 0.66 found on system at: c:\ghc\ghc-6.6.1\bin\hsc2hs.exe No hscolour found No hugs found No jhc found Using ld found on system at: c:\ghc\ghc-6.6.1\gcc-lib\ld.exe No nhc98 found No pkg-config found No ranlib found No strip found No tar found setup: fdGetMode: invalid argument (Invalid argument) Any clues as to what might be wrong? There are no buildinfo files produced, so I can't just ignore and proceed with setup build. Alistair From duncan.coutts at worc.ox.ac.uk Thu Jan 22 17:17:45 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 22 17:08:26 2009 Subject: cabal-1.6.0.1 won't build with ghc-6.6.1 in WinXP In-Reply-To: <79d7c4980901220356x5d80a35asa662e27b00b5cca6@mail.gmail.com> References: <79d7c4980901220356x5d80a35asa662e27b00b5cca6@mail.gmail.com> Message-ID: <1232662665.8432.333.camel@localhost> On Thu, 2009-01-22 at 11:56 +0000, Alistair Bayley wrote: > I'm trying to build cabal-1.6.0.1 with ghc-6.6.1 on WinXP. "setup -v [...] > setup: fdGetMode: invalid argument (Invalid argument) > > Any clues as to what might be wrong? There are no buildinfo files > produced, so I can't just ignore and proceed with setup build. Thanks for the bug report. I filed the details here: http://hackage.haskell.org/trac/hackage/ticket/473 I've pushed a patch to Cabal HEAD. Would you mind checking that it fixes the issue for you and I'll push the fix to the 1.6 branch so that it'll get into the upcomming 1.6.0.2 release. Thanks. Duncan From lemming at henning-thielemann.de Fri Jan 23 09:34:07 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Jan 23 09:24:51 2009 Subject: Binary: Put -> Builder Message-ID: Is there a way to get the underlying Builder of a 'put' of a Binary instance? How does the Char instance of Binary serialize? From alistair at abayley.org Fri Jan 23 11:46:02 2009 From: alistair at abayley.org (Alistair Bayley) Date: Fri Jan 23 11:36:44 2009 Subject: cabal-1.6.0.1 won't build with ghc-6.6.1 in WinXP In-Reply-To: <1232662665.8432.333.camel@localhost> References: <79d7c4980901220356x5d80a35asa662e27b00b5cca6@mail.gmail.com> <1232662665.8432.333.camel@localhost> Message-ID: <79d7c4980901230846x7a59dcc7i2d71e6508ecad1cc@mail.gmail.com> > Thanks for the bug report. I filed the details here: > http://hackage.haskell.org/trac/hackage/ticket/473 > > I've pushed a patch to Cabal HEAD. Would you mind checking that it fixes > the issue for you and I'll push the fix to the 1.6 branch so that it'll > get into the upcomming 1.6.0.2 release. It seems to work. I can build under ghc-6.6 now (although I get loads of linker errors, which is another problem to sort out). Turns out that with ghc-6.6, the Maybe instance of Monoid is missing (it's in 6.8 onwards), so I had to change Setup to handle this. Thanks for the rapid turnaround. Alistair From duncan.coutts at worc.ox.ac.uk Fri Jan 23 14:53:12 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jan 23 14:43:46 2009 Subject: cabal-1.6.0.1 won't build with ghc-6.6.1 in WinXP In-Reply-To: <79d7c4980901230846x7a59dcc7i2d71e6508ecad1cc@mail.gmail.com> References: <79d7c4980901220356x5d80a35asa662e27b00b5cca6@mail.gmail.com> <1232662665.8432.333.camel@localhost> <79d7c4980901230846x7a59dcc7i2d71e6508ecad1cc@mail.gmail.com> Message-ID: <1232740392.8432.343.camel@localhost> On Fri, 2009-01-23 at 16:46 +0000, Alistair Bayley wrote: > > Thanks for the bug report. I filed the details here: > > http://hackage.haskell.org/trac/hackage/ticket/473 > > > > I've pushed a patch to Cabal HEAD. Would you mind checking that it fixes > > the issue for you and I'll push the fix to the 1.6 branch so that it'll > > get into the upcomming 1.6.0.2 release. > > It seems to work. I can build under ghc-6.6 now (although I get loads > of linker errors, which is another problem to sort out). > > Turns out that with ghc-6.6, the Maybe instance of Monoid is missing > (it's in 6.8 onwards), so I had to change Setup to handle this. I presume you mean both problems are in your package and not in Cabal right? > Thanks for the rapid turnaround. No problem. Duncan From duncan.coutts at worc.ox.ac.uk Fri Jan 23 15:03:52 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jan 23 14:54:26 2009 Subject: Binary: Put -> Builder In-Reply-To: References: Message-ID: <1232741032.8432.352.camel@localhost> On Fri, 2009-01-23 at 15:34 +0100, Henning Thielemann wrote: > Is there a way to get the underlying Builder of a 'put' of a Binary > instance? The binary package exposes the Data.Binary.Builder module so you can use the Builder monoid directly. There is no need to go via the Put wrapper. There is no way to get at the 'current' state of the underlying Builder value. In principle, it could provide the normal writer monad access functions. What is the use case? Is there anything you can do with direct access you cannot do with Put operations? If you want to inspect the data already written then I suggest you do not. It would involve running the whole thing twice (because internally it's something like a difference list). > How does the Char instance of Binary serialize? http://hackage.haskell.org/packages/archive/binary/0.4.4/doc/html/src/Data-Binary.html#line-486 -- Char is serialised as UTF-8 instance Binary Char where ... Duncan From ross at soi.city.ac.uk Fri Jan 23 15:54:24 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Jan 23 15:45:08 2009 Subject: Binary: Put -> Builder In-Reply-To: <1232741032.8432.352.camel@localhost> References: <1232741032.8432.352.camel@localhost> Message-ID: <20090123205424.GA10431@soi.city.ac.uk> On Fri, Jan 23, 2009 at 08:03:52PM +0000, Duncan Coutts wrote: > On Fri, 2009-01-23 at 15:34 +0100, Henning Thielemann wrote: > > Is there a way to get the underlying Builder of a 'put' of a Binary > > instance? > > The binary package exposes the Data.Binary.Builder module so you can use > the Builder monoid directly. There is no need to go via the Put > wrapper. > > There is no way to get at the 'current' state of the underlying Builder > value. In principle, it could provide the normal writer monad access > functions. What is the use case? I imagine one might want to make a Builder for a composite object, using the Binary instances of some types. And one might want to go the other way too, defining a Binary instance using an existing Builder. From schlepptop at henning-thielemann.de Fri Jan 23 16:08:55 2009 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Fri Jan 23 15:52:55 2009 Subject: Binary: Put -> Builder In-Reply-To: <1232741032.8432.352.camel@localhost> References: <1232741032.8432.352.camel@localhost> Message-ID: <497A31E7.5020606@henning-thielemann.de> Duncan Coutts schrieb: > On Fri, 2009-01-23 at 15:34 +0100, Henning Thielemann wrote: >> Is there a way to get the underlying Builder of a 'put' of a Binary >> instance? > > The binary package exposes the Data.Binary.Builder module so you can use > the Builder monoid directly. There is no need to go via the Put > wrapper. I know, but the Binary class provides only a 'put' method in the 'PutM' monad. I can wrap Put in a newtype with Monoid instance in order to get what I want, but I hoped it would be simpler. >> How does the Char instance of Binary serialize? > > http://hackage.haskell.org/packages/archive/binary/0.4.4/doc/html/src/Data-Binary.html#line-486 > > -- Char is serialised as UTF-8 > instance Binary Char where > ... Since this does not appear in the documentation, this is undocumented behaviour? Just a Haddock deficiency, I know. From dons at galois.com Sat Jan 24 16:59:57 2009 From: dons at galois.com (Don Stewart) Date: Sat Jan 24 16:50:34 2009 Subject: Arch Haskell News: Jan 24 2009 Message-ID: <20090124215957.GE29877@scytale.galois.com> http://archhaskell.wordpress.com/2009/01/24/arch-haskell-news-jan-24-2009/ A regular update of Haskell in Arch Linux Arch now has 864 Haskell packages in AUR. That?s an increase of 37 new packages in the last 13 days, or 2.8 new Haskell apps and libraries a day so far in January. From dons at galois.com Sat Jan 24 18:58:18 2009 From: dons at galois.com (Don Stewart) Date: Sat Jan 24 18:48:55 2009 Subject: Tag cloud for hackage Message-ID: <20090124235818.GG29877@scytale.galois.com> http://donsbot.wordpress.com/2009/01/24/what-is-haskell-good-for/ The diversity, and focus, might be a surprise to some outside Haskell-land. From duncan.coutts at worc.ox.ac.uk Sat Jan 24 21:15:44 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jan 24 21:06:12 2009 Subject: Tag cloud for hackage In-Reply-To: <20090124235818.GG29877@scytale.galois.com> References: <20090124235818.GG29877@scytale.galois.com> Message-ID: <1232849744.8432.442.camel@localhost> On Sat, 2009-01-24 at 15:58 -0800, Don Stewart wrote: > http://donsbot.wordpress.com/2009/01/24/what-is-haskell-good-for/ > > The diversity, and focus, might be a surprise to some outside Haskell-land. Yet another cool thing to get onto the front hackage page on the new server. Though obviously we'd have to make all the tags clickable :-) So much to do... Duncan From dons at galois.com Sat Jan 24 21:18:36 2009 From: dons at galois.com (Don Stewart) Date: Sat Jan 24 21:09:17 2009 Subject: Tag cloud for hackage In-Reply-To: <1232849744.8432.442.camel@localhost> References: <20090124235818.GG29877@scytale.galois.com> <1232849744.8432.442.camel@localhost> Message-ID: <20090125021836.GH30447@scytale.galois.com> duncan.coutts: > On Sat, 2009-01-24 at 15:58 -0800, Don Stewart wrote: > > http://donsbot.wordpress.com/2009/01/24/what-is-haskell-good-for/ > > > > The diversity, and focus, might be a surprise to some outside Haskell-land. > > Yet another cool thing to get onto the front hackage page on the new > server. Though obviously we'd have to make all the tags clickable :-) > So much to do... Yep. Do you have a goal for happs/hackage? Release during Utrecht hackathon? From duncan.coutts at worc.ox.ac.uk Sun Jan 25 08:06:34 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 25 07:57:03 2009 Subject: Tag cloud for hackage In-Reply-To: <20090125021836.GH30447@scytale.galois.com> References: <20090124235818.GG29877@scytale.galois.com> <1232849744.8432.442.camel@localhost> <20090125021836.GH30447@scytale.galois.com> Message-ID: <1232888794.8432.449.camel@localhost> On Sat, 2009-01-24 at 18:18 -0800, Don Stewart wrote: > duncan.coutts: > > On Sat, 2009-01-24 at 15:58 -0800, Don Stewart wrote: > > > http://donsbot.wordpress.com/2009/01/24/what-is-haskell-good-for/ > > > > > > The diversity, and focus, might be a surprise to some outside Haskell-land. > > > > Yet another cool thing to get onto the front hackage page on the new > > server. Though obviously we'd have to make all the tags clickable :-) > > So much to do... > > Yep. > > Do you have a goal for happs/hackage? Release during Utrecht hackathon? My current plan is to release Cabal-1.6.0.2 and cabal-install-0.6.2 and then get on with the platform release, but that will involve at least having a new server running to collect build reports. Running that for a while should give us some feedback. I think it's a reasonable target to try and get it running properly at the next Utrecht hackathon. However to switch over we need not just feature parity but some way to deal with the other services running on hackage.haskell.org. Duncan From libraries at haskell.org Mon Jan 26 10:23:57 2009 From: libraries at haskell.org (network) Date: Mon Jan 26 10:14:32 2009 Subject: [network] #2: Socket related IO cannot be be interrupted on Windows In-Reply-To: <053.05e53ff0cd744a94c706df2d01db2402@haskell.org> References: <053.05e53ff0cd744a94c706df2d01db2402@haskell.org> Message-ID: <062.402ca815949b3ee94da7db148c07b887@haskell.org> #2: Socket related IO cannot be be interrupted on Windows ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonmar Type: defect | Status: assigned Priority: major | Milestone: Component: network | Version: Resolution: | Keywords: ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar * status: new => assigned Comment: This is because `accept` makes a safe FFI call on Windows, whereas on Unix it uses `threadWaitRead` to wait for a connection (`threadWaitRead` is interruptible, but not available on Windows). It looks to me like it ought to be interruptible without `-threaded`, I don't completely understand what's going on there. Ideally we would have an IO manager thread on Windows and handle this in the same way as other blocking IO operations, but that's a big job. -- Ticket URL: network Networking-related facilities From libraries at haskell.org Mon Jan 26 10:24:26 2009 From: libraries at haskell.org (network) Date: Mon Jan 26 10:15:12 2009 Subject: [network] #2: Socket related IO cannot be be interrupted on Windows In-Reply-To: <053.05e53ff0cd744a94c706df2d01db2402@haskell.org> References: <053.05e53ff0cd744a94c706df2d01db2402@haskell.org> Message-ID: <062.6d0384d9e4a9dd5388f3970f1bd42f66@haskell.org> #2: Socket related IO cannot be be interrupted on Windows ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Resolution: | Keywords: ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: simonmar => * status: assigned => new Comment: oops, didn't mean to assign ownership. -- Ticket URL: network Networking-related facilities From alistair at abayley.org Tue Jan 27 04:08:43 2009 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jan 27 03:59:13 2009 Subject: ghc-6.6 + cabal-1.6 - can't find header files Message-ID: <79d7c4980901270108mdcf2521y4e8b14951920b677@mail.gmail.com> I'm puzzled as to why this build fails (ghc-6.6.1, cabal-1.6 (actually HEAD, I think, but close enough, and winXP). The sqlite.h header file is in C:\Progra~1\sqlite3\, which is clearly given with the -I option. Alistair c:\ghc\ghc-6.6.1\bin\ghc.exe -package-name Takusen-0.8.4 --make -hide-all-packag es -no-user-package-conf -i -idist\build -i. -idist\build\autogen -Idist\build\a utogen -Idist\build -IC:\Progra~1\sqlite3\ -IC:/PROGRA~1/POSTGR~1/8.1/include -I C:/PROGRA~1/POSTGR~1/8.1/include/server -IC:\Oracle\product\10.2.0\client_1\oci\ include -optP-include -optPdist\build\autogen\cabal_macros.h -odir dist\build -h idir dist\build -package QuickCheck-1.0.1 -package base-2.1.1 -package mtl-1.0.1 -package time-1.1.1 -O -cpp Database.ODBC.Enumerator Database.ODBC.OdbcFunction s Database.Oracle.Enumerator Database.Oracle.OCIConstants Database.Oracle.OCIFun ctions Database.PostgreSQL.Enumerator Database.PostgreSQL.PGFunctions Database.S qlite.Enumerator Database.Sqlite.SqliteFunctions Database.Enumerator Database.Ut il Database.Stub.Enumerator Control.Exception.MonadIO Foreign.C.UTF8 Database.In ternalEnumerator [ 7 of 15] Compiling Database.Sqlite.SqliteFunctions ( Database/Sqlite/SqliteFun ctions.lhs, dist\build/Database/Sqlite/SqliteFunctions.o ) C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc4176_0\ghc4176_0.hc:8:20: sqlite.h: No such file or directory .. [many more "implicit declaration of function" warnings follow as a result of this one] From alistair at abayley.org Tue Jan 27 14:02:35 2009 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jan 27 13:53:04 2009 Subject: ghc-6.6 + cabal-1.6 - can't find header files In-Reply-To: <79d7c4980901270108mdcf2521y4e8b14951920b677@mail.gmail.com> References: <79d7c4980901270108mdcf2521y4e8b14951920b677@mail.gmail.com> Message-ID: <79d7c4980901271102n736fcad4ldf393b517aa84372@mail.gmail.com> 2009/1/27 Alistair Bayley : > I'm puzzled as to why this build fails (ghc-6.6.1, cabal-1.6 (actually > HEAD, I think, but close enough, and winXP). The sqlite.h header file > is in C:\Progra~1\sqlite3\, which is clearly given with the -I option. Turns out it's the trailing backslash in the path C:\Progra~1\sqlite3\ (same error for slashes, too). !? Sorry for the noise. Alistair From duncan.coutts at worc.ox.ac.uk Tue Jan 27 15:56:37 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 27 15:46:57 2009 Subject: ghc-6.6 + cabal-1.6 - can't find header files In-Reply-To: <79d7c4980901271102n736fcad4ldf393b517aa84372@mail.gmail.com> References: <79d7c4980901270108mdcf2521y4e8b14951920b677@mail.gmail.com> <79d7c4980901271102n736fcad4ldf393b517aa84372@mail.gmail.com> Message-ID: <1233089797.8432.554.camel@localhost> On Tue, 2009-01-27 at 19:02 +0000, Alistair Bayley wrote: > 2009/1/27 Alistair Bayley : > > I'm puzzled as to why this build fails (ghc-6.6.1, cabal-1.6 (actually > > HEAD, I think, but close enough, and winXP). The sqlite.h header file > > is in C:\Progra~1\sqlite3\, which is clearly given with the -I option. > > Turns out it's the trailing backslash in the path C:\Progra~1\sqlite3\ > (same error for slashes, too). !? I am very surprised. Is that problem at the gcc level? Does specifying paths with trailing dir separator cause this problem for gcc in a simple test case? If it really is a problem with gcc on windows perhaps ghc can use an updated gcc in future releases or we could try stripping trailing dir separators on include dirs in Cabal. Duncan From alistair at abayley.org Tue Jan 27 17:08:45 2009 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jan 27 16:59:14 2009 Subject: ghc-6.6 + cabal-1.6 - can't find header files In-Reply-To: <1233089797.8432.554.camel@localhost> References: <79d7c4980901270108mdcf2521y4e8b14951920b677@mail.gmail.com> <79d7c4980901271102n736fcad4ldf393b517aa84372@mail.gmail.com> <1233089797.8432.554.camel@localhost> Message-ID: <79d7c4980901271408u758450bet6ba4663865f44d2d@mail.gmail.com> 2009/1/27 Duncan Coutts : > On Tue, 2009-01-27 at 19:02 +0000, Alistair Bayley wrote: >> 2009/1/27 Alistair Bayley : >> > I'm puzzled as to why this build fails (ghc-6.6.1, cabal-1.6 (actually >> > HEAD, I think, but close enough, and winXP). The sqlite.h header file >> > is in C:\Progra~1\sqlite3\, which is clearly given with the -I option. >> >> Turns out it's the trailing backslash in the path C:\Progra~1\sqlite3\ >> (same error for slashes, too). !? > > I am very surprised. Is that problem at the gcc level? Does specifying > paths with trailing dir separator cause this problem for gcc in a simple > test case? > > If it really is a problem with gcc on windows perhaps ghc can use an > updated gcc in future releases or we could try stripping trailing dir > separators on include dirs in Cabal. I think it's only ghc-6.6, but I'll retest against 6.8 and 6.10. If it's only 6.6 then I'm not going to sweat it. Alistair From duncan.coutts at worc.ox.ac.uk Tue Jan 27 18:38:52 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 27 18:29:11 2009 Subject: ghc-6.6 + cabal-1.6 - can't find header files In-Reply-To: <79d7c4980901271408u758450bet6ba4663865f44d2d@mail.gmail.com> References: <79d7c4980901270108mdcf2521y4e8b14951920b677@mail.gmail.com> <79d7c4980901271102n736fcad4ldf393b517aa84372@mail.gmail.com> <1233089797.8432.554.camel@localhost> <79d7c4980901271408u758450bet6ba4663865f44d2d@mail.gmail.com> Message-ID: <1233099532.8432.571.camel@localhost> On Tue, 2009-01-27 at 22:08 +0000, Alistair Bayley wrote: > 2009/1/27 Duncan Coutts : > > On Tue, 2009-01-27 at 19:02 +0000, Alistair Bayley wrote: > >> 2009/1/27 Alistair Bayley : > >> > I'm puzzled as to why this build fails (ghc-6.6.1, cabal-1.6 (actually > >> > HEAD, I think, but close enough, and winXP). The sqlite.h header file > >> > is in C:\Progra~1\sqlite3\, which is clearly given with the -I option. > >> > >> Turns out it's the trailing backslash in the path C:\Progra~1\sqlite3\ > >> (same error for slashes, too). !? > > > > I am very surprised. Is that problem at the gcc level? Does specifying > > paths with trailing dir separator cause this problem for gcc in a simple > > test case? > > > > If it really is a problem with gcc on windows perhaps ghc can use an > > updated gcc in future releases or we could try stripping trailing dir > > separators on include dirs in Cabal. > > I think it's only ghc-6.6, but I'll retest against 6.8 and 6.10. If > it's only 6.6 then I'm not going to sweat it. That doesn't make a lot of sense to me. It's gcc that finds the header files. It could be ghc-6.6 that is somehow messing up passing flags on to gcc, but that would also be surprising. You can build with -v and see how ghc is invoking gcc, and try those commands manually etc. Duncan From alistair at abayley.org Wed Jan 28 03:28:36 2009 From: alistair at abayley.org (Alistair Bayley) Date: Wed Jan 28 03:19:03 2009 Subject: ghc-6.6 + cabal-1.6 - can't find header files In-Reply-To: <1233099532.8432.571.camel@localhost> References: <79d7c4980901270108mdcf2521y4e8b14951920b677@mail.gmail.com> <79d7c4980901271102n736fcad4ldf393b517aa84372@mail.gmail.com> <1233089797.8432.554.camel@localhost> <79d7c4980901271408u758450bet6ba4663865f44d2d@mail.gmail.com> <1233099532.8432.571.camel@localhost> Message-ID: <79d7c4980901280028v248a3ab9j3398c5603e2323cc@mail.gmail.com> > That doesn't make a lot of sense to me. It's gcc that finds the header > files. It could be ghc-6.6 that is somehow messing up passing flags on > to gcc, but that would also be surprising. Below are the gcc version and ghc commands for 6.6.1, 6.8.1, & 6.10.1. Puzzling that 6.8.1 works while 6.6.1 doesn't, given that they both use the same gcc. There must be something else going on. Like I said, I'm not going to worry about it much. ghc-hq aren't going to release a fix for ghc-6.6 now, are they? I will fix Setup.hs so that the trailing path separator is stripped. Alistair ------ ghc-6.6.1 gcc (GCC) 3.4.2 (mingw-special) c:\ghc\ghc-6.6.1\bin\ghc.exe -package-name Takusen-0.8.4 --make -hide-all-packag es -no-user-package-conf -i -idist\build -i. -idist\build\autogen -Idist\build\a utogen -Idist\build -IC:\Program Files\sqlite3\ -IC:/PROGRA~1/POSTGR~1/8.1/inclu de -IC:/PROGRA~1/POSTGR~1/8.1/include/server -IC:\Oracle\product\10.2.0\client_1 \oci\include -optP-include -optPdist\build\autogen\cabal_macros.h -odir dist\bui ld -hidir dist\build -package QuickCheck-1.0.1 -package base-2.1.1 -package mtl- 1.0.1 -package time-1.1.1 -O -cpp Database.ODBC.Enumerator Database.ODBC.OdbcFun ctions Database.Oracle.Enumerator Database.Oracle.OCIConstants Database.Oracle.O CIFunctions Database.PostgreSQL.Enumerator Database.PostgreSQL.PGFunctions Datab ase.Sqlite.Enumerator Database.Sqlite.SqliteFunctions Database.Enumerator Databa se.Util Database.Stub.Enumerator Control.Exception.MonadIO Foreign.C.UTF8 Databa se.InternalEnumerator ------ ghc-6.8.1 gcc (GCC) 3.4.2 (mingw-special) c:\ghc\ghc-6.8.1\bin\ghc.exe -package-name Takusen-0.8.4 --make -hide-all-packag es -no-user-package-conf -i -idist\build -i. -idist\build\autogen -Idist\build\a utogen -Idist\build -IC:\Program Files\sqlite3\ -IC:/PROGRA~1/POSTGR~1/8.1/inclu de -IC:/PROGRA~1/POSTGR~1/8.1/include/server -IC:\Oracle\product\10.2.0\client_1 \oci\include -optP-include -optPdist\build\autogen\cabal_macros.h -odir dist\bui ld -hidir dist\build -stubdir dist\build -package QuickCheck-1.1.0.0 -package ba se-3.0.0.0 -package mtl-1.1.0.0 -package old-time-1.0.0.0 -package time-1.1.2.0 -O -XCPP Database.ODBC.Enumerator Database.ODBC.OdbcFunctions Database.Oracle.En umerator Database.Oracle.OCIConstants Database.Oracle.OCIFunctions Database.Post greSQL.Enumerator Database.PostgreSQL.PGFunctions Database.Sqlite.Enumerator Dat abase.Sqlite.SqliteFunctions Database.Enumerator Database.Util Database.Stub.Enu merator Control.Exception.MonadIO Foreign.C.UTF8 Database.InternalEnumerator ------ ghc-6.10.1 gcc (GCC) 3.4.5 (mingw-vista special r3) c:\ghc\ghc-6.10.1\bin\ghc.exe -package-name Takusen-0.8.4 --make -hide-all-packa ges -no-user-package-conf -i -idist\build -i. -idist\build\autogen -Idist\build\ autogen -Idist\build -IC:\Program Files\sqlite3\ -IC:/PROGRA~1/POSTGR~1/8.1/incl ude -IC:/PROGRA~1/POSTGR~1/8.1/include/server -IC:\Oracle\product\10.2.0\client_ 1\oci\include -optP-DNEW_EXCEPTION -optP-DNEW_EXCEPTION -optP-include -optPdist\ build\autogen\cabal_macros.h -odir dist\build -hidir dist\build -stubdir dist\bu ild -package QuickCheck-1.2.0.0 -package base-4.0.0.0 -package mtl-1.1.0.2 -pack age old-time-1.0.0.1 -package time-1.1.2.2 -O -O2 -O2 -XCPP Database.ODBC.Enumer ator Database.ODBC.OdbcFunctions Database.Oracle.Enumerator Database.Oracle.OCIC onstants Database.Oracle.OCIFunctions Database.PostgreSQL.Enumerator Database.Po stgreSQL.PGFunctions Database.Sqlite.Enumerator Database.Sqlite.SqliteFunctions Database.Enumerator Database.Util Database.Stub.Enumerator Control.Exception.Mon adIO Foreign.C.UTF8 Database.InternalEnumerator From duncan.coutts at worc.ox.ac.uk Wed Jan 28 08:13:02 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 28 08:03:23 2009 Subject: permissions api in directory package is useless (and possibly harmful) Message-ID: <1233148382.26754.103.camel@localhost> All, We need to think about a new better permissions api for the System.Directory module. The current api and also the implementation are at best useless and possibly harmful. I've been trying to debug various permission problems related to installing files with Cabal on Unix and Windows. Half the problems seem to stem from the permissions api and the copying of permissions in copyFile. data Permissions = Permissions { readable :: Bool, writable :: Bool, executable :: Bool, searchable :: Bool } getPermissions :: FilePath -> IO Permissions setPermissions :: FilePath -> Permissions -> IO () These are clearly designed for the unix permissions model, however they do not map onto it very usefully. get/setPermissions only get the user permissions, not the group or other. So for example if I have a file: -rw-rw-rw- 1 duncan users 0 2009-01-28 12:34 foo then setPermissions "foo" (Permissions True False False False) only removes write permissions from me, not from everyone else: -r--rw-rw- 1 duncan users 0 2009-01-28 12:34 foo which cannot be what we wanted. It's also pretty useless for installing files globally. For that we want to say that a file is readable by everyone and only writable by the owner (usually root). It might even be ok to say only readable by everyone and writable by nobody, but we cannot even do that. Combine that with copyFile copying permissions and we can easily lock people out or install world-writable files depending on the umask of the user building the software. On windows getPermissions tells us almost nothing. In particular if it says the file is readable or writable, this is no guarantee that we can read or write the file. getPermissions does not look at permissions. It only consults the old DOS read-only attribute (and the file extension to tell us if a file is executable). Similarly, on windows setPermissions also only sets the read-only attribute. The read-only attribute should really be avoided. It has rather unhelpful semantics. For example moving a file over a read-only file fails, where as if windows permissions (ACLs) are used then it works as expected (same as on POSIX). The read-only attribute is only there for compatibility with heritage software, we should really never set it. There is also an implementation of copyPermissions, it's not actually exposed in System.Directory but it is used by copyFile. It calls stat to get the permissions and chmod to set them. The implementation is the same between unix and windows, on windows it uses the stat and chmod from the msvcrt library. On Unix copyPermissions does work and is probably the right thing for copyFile to do. It's the default behaviour of /bin/cp for example. However it does mean there is no easy efficient way to make a copy of a file where the destination file gets the default permissions, given the umask of the current user. This means that copyFile is not appropriate for installing files, since the user building a package is not necessarily the same as the one installing it and their umasks can and often are different. The unix install program does not copy permissions, instead it sets them explicitly. We have no portable way of doing the same. But we can at least use the System.Posix.Files.setFileMode to do it. One nice thing about copyFile is that it replaces the destination file atomically. However if we have to set the permissions in a second step then we loose this nice property. Ideally we would create the temporary file in the destination directory (exclusively and with permissions such that no other user could write to our file), we'd copy the data over, set the new destination permissions and atomically replace the destination file. The copyPermissions function on windows is useless. It does not copy permissions. The way that msvcrt implements stat and chmod means that the only "permissions" that are copied is the old DOS read-only attribute. Perhaps copying the read-only attribute is the right thing for copyFile to do, it's what the Win32 CopyFile function does, however it's never what I want to do for installing software package files. So, can we craft a useful api for permissions? We should consider what the defaults for copyfile etc should be with respect to permissions. Where those defaults are not helpful can we think of a way to let us do what we want (eg get default or specific permissions instead of copying permissions). Or is it impossible and we just have to use system-specific functions whenever we need something non-standard. In which case we need to make those functions better, they appear to be mostly lacking for the Win32 case. In either case I'm sure the existing permissions api needs to be deprecated with big flashing warnings. Duncan Oh, and while I'm thinking about it: it's not currently possible to open new/exclusive files with specific permissions and the open temp file functions on windows do not ensure the file is writable only by the current user. From duncan.coutts at worc.ox.ac.uk Wed Jan 28 08:13:49 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 28 08:04:04 2009 Subject: Bug in Cabal? In-Reply-To: References: <1232529549.8432.229.camel@localhost> Message-ID: <1233148429.26754.105.camel@localhost> Hia Dominic, I've looked into this a bit. I think I may now be less confused. :-) On Wed, 2009-01-21 at 18:01 +0000, Dominic Steinitz wrote: > > We use System.Directory.copyFile which copies the permissions from the > > original file to the destination file. Could you confirm that this is > > working correctly. Are the permissions of the source and destination > > files exactly the same? Was the source file created read-only? > > haskell_packages is empty to start with and the package gets built > successfully. Attributes are copied over successfully. The actual source files > *are* read only as they are kept in our source control system which marks them > this way for unchecked out files. Built files are read / write. Ok, that's fine. It's as we expect. > >ls -ltr haskell_packages\doc\zlib-0.5.0.0 > total 2 > -r--r--r-- 1 user group 1327 Jan 21 11:37 LICENSE Ah! Is that the only file that is read-only? That makes sense since it's an original source file from your read-only source control system. The System.Directory.copyFile function does not copy permissions (though it does try to) but it does (unhelpfully) copy the read-only attribute. > When I rebuild the package *without* having cleaned out haskell_packages then I > get the access error. I think this is because cabal (copyFile) doesn't want to > overwrite a read only file even though the directory permissions should allow > it to do so. Yes. The windows MoveFile function does not let us move a file over a file that has the read-only attribute. It's an annoying interaction between the semantics of old DOS/FAT read-only attribute and new windows file permissions (ACLs). The solution I think, is never to copy the read-only attribute when installing files. It's thoroughly unhelpful. I've got a patch to do this which I shall push to Cabal HEAD shortly. If you have a moment to help me test that it would be much appreciated. > > This looks like: > > http://hackage.haskell.org/trac/hackage/ticket/454 > > > > But for every file not just .exe files. For .exe files Cabal does the > > permission copying itself. I do not understand why it just started > > occurring, since ghc-6.8 and 6.10 seem to have the same code for > > copyFile and copyPermissions. > > I don't seem to have the problem for binaries (because cabal builds them afresh > with read / write permission) so I don't know if it's related or not (but it > seems unlikely). I think you're right that it's unrelated. Your problem is caused by Cabal copying the read-only attribute where as that ticket turns out to be more related to permissions (ACLs) and users and inherited permissions etc. Duncan From johan.tibell at gmail.com Wed Jan 28 08:57:22 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Jan 28 08:47:51 2009 Subject: permissions api in directory package is useless (and possibly harmful) In-Reply-To: <1233148382.26754.103.camel@localhost> References: <1233148382.26754.103.camel@localhost> Message-ID: <90889fe70901280557x4041b1bfo82b9e1522c88f924@mail.gmail.com> On Wed, Jan 28, 2009 at 2:13 PM, Duncan Coutts wrote: > We need to think about a new better permissions api for the > System.Directory module. The current api and also the implementation are > at best useless and possibly harmful. Perhaps there's something we can learn from the rearchitecture of Java's file handling that's happening in NIO 2. They're overhauling how files, directories, file systems, links, and metadata is handled. They address things such as providing both a lowest common denominator layer and platform specific "extensions". See for example http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf starting at slide 17. Cheers, Johan From duncan.coutts at worc.ox.ac.uk Wed Jan 28 09:21:56 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 28 09:12:16 2009 Subject: permissions api in directory package is useless (and possibly harmful) In-Reply-To: <90889fe70901280557x4041b1bfo82b9e1522c88f924@mail.gmail.com> References: <1233148382.26754.103.camel@localhost> <90889fe70901280557x4041b1bfo82b9e1522c88f924@mail.gmail.com> Message-ID: <1233152516.26754.106.camel@localhost> On Wed, 2009-01-28 at 14:57 +0100, Johan Tibell wrote: > On Wed, Jan 28, 2009 at 2:13 PM, Duncan Coutts > wrote: > > We need to think about a new better permissions api for the > > System.Directory module. The current api and also the implementation are > > at best useless and possibly harmful. > > Perhaps there's something we can learn from the rearchitecture of > Java's file handling that's happening in NIO 2. They're overhauling > how files, directories, file systems, links, and metadata is handled. > They address things such as providing both a lowest common denominator > layer and platform specific "extensions". > > See for example > http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf starting at > slide 17. Yes, I'm sure there are some good ideas to consider there. I looked at NIO1 and it's got some fairly sensible stuff. Duncan From jgoerzen at complete.org Wed Jan 28 16:00:35 2009 From: jgoerzen at complete.org (John Goerzen) Date: Wed Jan 28 15:51:02 2009 Subject: Issues with new Control.Exception Message-ID: <20090128210035.GA3762@hustlerturf.com> Hi everyone, Please CC me on replies as I'm not on this list. I've noticed several issues with Control.Exception, although I'm not sure I'm equipped well to fix them: * onException is undocumented * Catch doesn't work in many common cases anymore. In particular, the example right there in haddock is broken: catch (openFile f ReadMode) (\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e)) That's broken, of course, because the type of e isn't fixed. But it's also broken because openFile has a different return type than hPutStr. * The catchJust example references errorCalls, which is no longer in Control.Exception. * I like the new system overall, but it is annoying that we can't do the sort of catch that is contemplated in the example above anymore. This is especially annoying for me in several cases where I want to catch *any* exception and do things with it, especially when doing unit testing. * I wonder if the docs to Control.Exception could benefit from a review. I also notice that the comments about catchJust may no longer apply. * What is the expected life expectancy of OldException, and how does it interact with Exception? Can I use catch from OldException to still do what I want? If so, it might be nice to note how exactly catch works with new exceptions. Some of these I may be able to submit patches for in time, but right now I'm mainly trying to understand what the expected way to use the new exceptions is, so I'm probably not the right person to do it yet. -- John From dave at zednenem.com Wed Jan 28 16:50:09 2009 From: dave at zednenem.com (David Menendez) Date: Wed Jan 28 16:40:34 2009 Subject: Issues with new Control.Exception In-Reply-To: <20090128210035.GA3762@hustlerturf.com> References: <20090128210035.GA3762@hustlerturf.com> Message-ID: <49a77b7a0901281350p2d1e41cfke8a47348aabc3357@mail.gmail.com> On Wed, Jan 28, 2009 at 4:00 PM, John Goerzen wrote: > * Catch doesn't work in many common cases anymore. In particular, > the example right there in haddock is broken: > > catch (openFile f ReadMode) > (\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e)) > > That's broken, of course, because the type of e isn't fixed. > But it's also broken because openFile has a different return type > than hPutStr. I think the correct code would be something like this: catch (openFile f ReadMode) (\(e::SomeException) -> hPutStr stderr ("Couldn't open "++f++": " ++ show e)) >> throwIO e) Although it might be better to replace "SomeException" with "IOException". -- Dave Menendez From bertram.felgenhauer at googlemail.com Wed Jan 28 17:02:43 2009 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Wed Jan 28 16:54:56 2009 Subject: Issues with new Control.Exception In-Reply-To: <20090128210035.GA3762@hustlerturf.com> References: <20090128210035.GA3762@hustlerturf.com> Message-ID: <4980d606.0c11660a.33a7.6d10@mx.google.com> John Goerzen wrote: > * Catch doesn't work in many common cases anymore. In particular, > the example right there in haddock is broken: > > catch (openFile f ReadMode) > (\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e)) > > That's broken, of course, because the type of e isn't fixed. > But it's also broken because openFile has a different return type > than hPutStr. Which means it has been broken for quite some time. > * I like the new system overall, but it is annoying that > we can't do the sort of catch that is contemplated in the example > above anymore. This is especially annoying for me in several cases > where I want to catch *any* exception and do things with it, > especially when doing unit testing. You can actually do that - all you have to do is catch SomeException, say openFile f ReadMode `catch` \e -> do hPutStrLn stderr $ "Couldn't open " ++ f ++ ": " ++ show (e :: SomeException) throw e This works because SomeException is an instance of the Exception class with the obvious trivial implementations for toException and fromException. It should be documented, of course. onException does basically that - so it works for any exceptions: onException :: IO a -> IO b -> IO a onException io what = io `catch` \e -> do what throw (e :: SomeException) HTH, Bertram From duncan.coutts at worc.ox.ac.uk Thu Jan 29 06:43:39 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 29 06:34:03 2009 Subject: Bug in Cabal? In-Reply-To: <1233148429.26754.105.camel@localhost> References: <1232529549.8432.229.camel@localhost> <1233148429.26754.105.camel@localhost> Message-ID: <1233229419.26754.255.camel@localhost> On Wed, 2009-01-28 at 13:13 +0000, Duncan Coutts wrote: > The solution I think, is never to copy the read-only attribute when > installing files. It's thoroughly unhelpful. I've got a patch to do this > which I shall push to Cabal HEAD shortly. If you have a moment to help > me test that it would be much appreciated. I've attached a darcs patch against the Cabal-1.6 branch (rather than the head branch). darcs get --partial http://darcs.haskell.org/cabal-branches/cabal-1.6/ If you or anyone else can test it on Windows that'd be great. I checked it by setting the read-only attribute on a LICENSE file and where previously the attribute would get copied (preventing further re-installs) it is now not copied. On Unix it should solve this problem: http://hackage.haskell.org/trac/hackage/ticket/93 Though I've not tested that yet. The patch for the 1.6 branch is fairly minimal and doesn't change any API. In Cabal HEAD I'll do it slightly differently so that the code is more consistent and comprehensible, but it involves api changes to exposed utility functions. Duncan -------------- next part -------------- Wed Jan 28 18:11:15 GMT 2009 Duncan Coutts * Add Distribution.Compat.CopyFile module This is to work around the file permissions problems with the standard System.Directory.copyFile function. When installing files we do not want to copy permissions or attributes from the source files. On unix we want to use specific permissions and on windows we want to inherit default permissions. On unix: copyOrdinaryFile sets the permissions to -rw-r--r-- copyExecutableFile sets the permissions to -rwxr-xr-x Wed Jan 28 19:41:43 GMT 2009 Duncan Coutts * Use copyOrdinaryFile and copyExecutableFile instead of copyFile This is a minimal patch for the Cabal-1.6 branch only. New patches: [Add Distribution.Compat.CopyFile module Duncan Coutts **20090128181115 This is to work around the file permissions problems with the standard System.Directory.copyFile function. When installing files we do not want to copy permissions or attributes from the source files. On unix we want to use specific permissions and on windows we want to inherit default permissions. On unix: copyOrdinaryFile sets the permissions to -rw-r--r-- copyExecutableFile sets the permissions to -rwxr-xr-x ] { hunk ./Cabal.cabal 109 + Distribution.Compat.CopyFile, addfile ./Distribution/Compat/CopyFile.hs hunk ./Distribution/Compat/CopyFile.hs 1 +{-# OPTIONS -cpp #-} +-- OPTIONS required for ghc-6.4.x compat, and must appear first +{-# LANGUAGE CPP #-} +{-# OPTIONS_GHC -cpp #-} +{-# OPTIONS_NHC98 -cpp #-} +{-# OPTIONS_JHC -fcpp #-} +-- #hide +module Distribution.Compat.CopyFile ( + copyFile, + copyOrdinaryFile, + copyExecutableFile + ) where + +#ifdef __GLASGOW_HASKELL__ + +import Prelude hiding ( catch ) +import Control.Monad + ( when ) +import Control.Exception + ( throw, try, catch, bracket, bracketOnError, Exception(IOException) ) +import System.IO.Error + ( ioeSetLocation ) +import System.Directory + ( renameFile, removeFile ) +import Distribution.Compat.TempFile + ( openBinaryTempFile ) +import System.FilePath + ( takeDirectory ) +import System.IO + ( openBinaryFile, IOMode(ReadMode), hClose, hGetBuf, hPutBuf ) +import Foreign + ( allocaBytes ) + +#ifndef mingw32_HOST_OS +import System.Posix.Types + ( FileMode ) +import System.Posix.Internals + ( c_chmod ) +import Foreign.C + ( withCString, throwErrnoPathIfMinus1_ ) +#endif +#endif + + +copyOrdinaryFile, copyExecutableFile :: FilePath -> FilePath -> IO () + +#if defined(__GLASGOW_HASKELL__) && !defined(mingw32_HOST_OS) +copyOrdinaryFile fromFPath toFPath = do + copyFile fromFPath toFPath + setFileMode toFPath 0o644 -- file perms -rw-r--r-- + +copyExecutableFile fromFPath toFPath = do + copyFile fromFPath toFPath + setFileMode toFPath 0o755 -- file perms -rwxr-xr-x + +setFileMode :: FilePath -> FileMode -> IO () +setFileMode name m = + withCString name $ \s -> do + throwErrnoPathIfMinus1_ "setFileMode" name (c_chmod s m) +#else +copyOrdinaryFile = copyFile +copyExecutableFile = copyFile +#endif + +copyFile :: FilePath -> FilePath -> IO () +#ifdef __GLASGOW_HASKELL__ +copyFile fromFPath toFPath = + copy `catch` (\e -> case e of + IOException ioe -> + throw $ IOException $ ioeSetLocation ioe "copyFile" + _ -> throw e) + where copy = bracket (openBinaryFile fromFPath ReadMode) hClose $ \hFrom -> + bracketOnError openTmp cleanTmp $ \(tmpFPath, hTmp) -> + do allocaBytes bufferSize $ copyContents hFrom hTmp + hClose hTmp + renameFile tmpFPath toFPath + openTmp = openBinaryTempFile (takeDirectory toFPath) ".copyFile.tmp" + cleanTmp (tmpFPath, hTmp) = do try $ hClose hTmp + try $ removeFile tmpFPath + bufferSize = 4096 + + copyContents hFrom hTo buffer = do + count <- hGetBuf hFrom buffer bufferSize + when (count > 0) $ do + hPutBuf hTo buffer count + copyContents hFrom hTo buffer +#else +copyFile fromFPath toFPath = readFile fromFPath >>= writeFile toFPath +#endif hunk ./Makefile 16 -SOURCES=Distribution/*.hs Distribution/Simple/*.hs Distribution/PackageDescription/*.hs Distribution/Simple/GHC/*.hs Distribution/Simple/Build/*.hs +SOURCES=Distribution/*.hs Distribution/Simple/*.hs Distribution/PackageDescription/*.hs Distribution/Simple/GHC/*.hs Distribution/Simple/Build/*.hs Distribution/Compat/*.hs } [Use copyOrdinaryFile and copyExecutableFile instead of copyFile Duncan Coutts **20090128194143 This is a minimal patch for the Cabal-1.6 branch only. ] { hunk ./Distribution/Simple/GHC.hs 129 +import Distribution.Compat.CopyFile + ( copyExecutableFile ) hunk ./Distribution/Simple/GHC.hs 933 - copyFileVerbose verbosity + copyExe verbosity hunk ./Distribution/Simple/GHC.hs 970 +copyExe :: Verbosity -> FilePath -> FilePath -> IO () +copyExe verbosity src dest = do + info verbosity ("copy " ++ src ++ " to " ++ dest) + copyExecutableFile src dest + hunk ./Distribution/Simple/Haddock.hs 97 - removeDirectoryRecursive, copyFile) - + removeDirectoryRecursive) +import Distribution.Compat.CopyFile + ( copyFile ) hunk ./Distribution/Simple/Utils.hs 141 - ( copyFile, createDirectoryIfMissing, renameFile, removeDirectoryRecursive ) + ( createDirectoryIfMissing, renameFile, removeDirectoryRecursive ) hunk ./Distribution/Simple/Utils.hs 168 +import Distribution.Compat.CopyFile + ( copyOrdinaryFile ) hunk ./Distribution/Simple/Utils.hs 501 - copyFile src dest + copyOrdinaryFile src dest } Context: [Update changelog for 1.6.0.2 Duncan Coutts **20090123175629] [Fix installIncludeFiles to create target directories properly Duncan Coutts **20090122004836 Previously for 'install-includes: subdir/blah.h' we would not create the subdir in the target location. ] [filter -threaded when profiling is on Duncan Coutts **20090122014425 Fixes #317. Based on a patch by gleb.alexeev@gmail.com ] [Fix openNewBinaryFile on Windows with ghc-6.6 Duncan Coutts **20090122172100 fdToHandle calls fdGetMode which does not work with ghc-6.6 on windows, the workaround is not to call fdToHandle, but call openFd directly. Bug reported by Alistair Bayley, ticket #473. ] [Make 'ghc-options: -O0' a warning rather than an error Duncan Coutts **20090118141949] [Improve runE parse error message Duncan Coutts **20090116133214 Only really used in parsing config files derived from command line flags. ] [Ban ghc-options: --make Duncan Coutts **20081223170621 I dunno, some people... ] [Update changelog for 1.6.0.2 release Duncan Coutts **20081211142202] [Fix configCompilerAux to consider user-supplied program flags Duncan Coutts **20081209193320 This fixes a bug in cabal-install ] [Swap the order of global usage messages Duncan Coutts **20090113191810 Put the more important one first. ] [Enable the global command usage to be set Duncan Coutts **20090113181303 extend it rather than overriding it. Also rearrange slightly the default global --help output. ] [Bump version number to 1.6.0.2 Duncan Coutts **20081210231021] [Fake support for NamedFieldPuns in ghc-6.8 Duncan Coutts **20081208180018 Implement it in terms of the -XRecordPuns which was accidentally added in ghc-6.8 and deprecates in 6.10 in favor of NamedFieldPuns So this is for compatability so we can tell package authors always to use NamedFieldPuns instead. ] [Make getting ghc supported language extensions its own function Duncan Coutts **20081208175815] [Distributing a package with no synopsis and no description is inexcusable Duncan Coutts **20081205160719 Previously if one or the other or both were missing we only warned. Now if neither are given it's an error. We still warn about either missing. ] [Remove accidentally added bianry file Duncan Coutts **20081203000824] [Fix #396 and add let .Haddock find autogen modules Andrea Vezzosi **20081201114853] [Fix the date in the LICENSE file Duncan Coutts **20081202161457] [Improve the error on invalid file globs slightly Duncan Coutts **20081202135335] [Update changelog for 1.6.0.x fixes Duncan Coutts **20081122145758] [Make auto-generated *_paths.hs module warning-free. Thomas Schilling **20081106142734 On newer GHCs using {-# OPTIONS_GHC -fffi #-} gives a warning which can lead to a compile failure when -Werror is activated. We therefore emit this option if we know that the LANGUAGE pragma is supported (ghc >= 6.6.1). ] [Escape ld-options with the -optl prefix when passing them to ghc Duncan Coutts **20081103151931 Fixes ticket #389 ] [Simplify previous pkg-config fix Duncan Coutts **20081101200309] [Fix bug where we'd try to configure an empty set of pkg-config packages Duncan Coutts **20081101195512 This happened when the lib used pkg-config but the exe did not. It cropped up in hsSqlite3-0.0.5. ] [Ensure that the lib target directory is present when installing Duncan Coutts **20081017004437 Variant on a patch from Bryan O'Sullivan ] [Add GHC 6.10.1's extensions to the list in Language.Haskell.Extension Ian Lynagh **20081019141408] [Release kind is now rc Duncan Coutts **20081011183201] [TAG 1.6.0.1 Duncan Coutts **20081011182516] [Bump version to 1.6.0.1 Duncan Coutts **20081011182459] [Do not use the new meta-data fields yet Duncan Coutts **20081011182307 Avoid chicken and egg problem. We cannot upload Cabsl-1.6 to hackage until hackage is using Cabal-1.6 if it uses features that are introduced in 1.6. So just comment them out for now. ] [Export a compat function for older Setup.hs scripts Duncan Coutts **20081011182131 Makes it possible for alex and happy to work with cabal-1.2 -> 1.6 ] [Fix instructions in README for building with 6.6 and filepath Duncan Coutts **20081011002819] [Update release procedure in Makefile Duncan Coutts **20081010181445 Building the haddock docs requires building first. Arguably this is a Cabal bug. It should probably generate the "autogen" files for haddock and not just for build. ] [TAG 1.6.0.0 Duncan Coutts **20081010061435] [Bump version number to 1.6.0.0 Duncan Coutts **20081010052409] [Update changelog Duncan Coutts **20081010052354] [Remove the releaseNotes file Duncan Coutts **20081010052101 It did not actually contain any release notes and just duplicated information in the README which was confusing. ] [Merge the info from the releaseNotes file into the README file Duncan Coutts **20081010052020] [Fix haddock comment for haddock-0.8 Duncan Coutts **20081010050913] [Fix parsing of ld,cc,cpp-options for flags containing ',' Duncan Coutts **20081010050829 The ',' character is not used as a separator and is allowed within flag tokens. Fixes at least HsPerl5. ] [Update versions in regression check script Duncan Coutts **20081009223429] [Bump devel version number to 1.5.6 Duncan Coutts **20081009223350 To make easier to track recent Cabal / cabal-install changes ] [Update changelog Duncan Coutts **20081009223330] [Update the README Duncan Coutts **20081009221851] [Make sdist work for libs that use the Paths_pkgname module Duncan Coutts **20081009214507 Do it by just filtering that module out of the package description before running sdist etc. This isn't lovely because it steals that module name from the module namespace but at least it now works. Thanks to Jean-Philippe Bernardy for the first iteration of this patch. ] [xargs -s breaks solaris Duncan Coutts **20081008185041 Hopefully we can figure out a better fix for recent cygwin versions of xargs which are apparently broken. rolling back: Wed Oct 8 08:44:10 PDT 2008 Clemens Fruhwirth * Also respect the max. command line size in Makefile driven builds M ./Distribution/Simple/GHC.hs -7 +13 M ./Distribution/Simple/GHC/Makefile.hs -1 +1 M ./Distribution/Simple/GHC/Makefile.in -1 +1 ] [Also respect the max. command line size in Makefile driven builds Clemens Fruhwirth **20081008154410] [add missing exeExtension when stripping an executable Simon Marlow **20081007134757] [Add -no-auto-link-packages also to Makefile driven build Clemens Fruhwirth **20081007095454] [Also install dynamically linked executable (when present) Clemens Fruhwirth **20081006095107] [Use "-no-auto-link-packages" when using GHC to link Ian Lynagh **20081004111103 When making packages like ghc-prim we need GHC to not automatically try to link with base and haskell98. ] [Add a few type sigs to help hugs and as documentation Duncan Coutts **20081007214120 Thanks to Dimitry and Ross for identifying the problem. ] [Relax dependencyInconsistencies to allow the base-3,4 thing Duncan Coutts **20081002074142 Previously we said a package graph was inconsistent if two dependencies on the same package name specified different versions. Now we say that two such dependencies on different versions are ok if there is a direct dependency between those two package versions. So if your package graph ends up with both base 3 and base 4 in it, then that's ok because base 3 directly depends on base 4, so we declare it not to be an inconsistency. This removes the scary warnings at configure time (fixing ticket #366) and also adjusts the invariant and assertion of the InstallPlan ADT in cabal-install. ] [Document the bug-reports field Duncan Coutts **20081001042635] [Add bug-reports field to Cabal.cabal Duncan Coutts **20081001035605] [Add bug-reports url field Duncan Coutts **20081001035516 Ticket #323 ] [Update the package description a bit Duncan Coutts **20081001034350] [Specify a source repository for Cabal in Cabal.cabal Duncan Coutts **20081001034325] [Document the source-repository stuff Duncan Coutts **20081001033928] [Add some checks on the repository sections Duncan Coutts **20081001033755] [Use unknown rather than specific other repo kinds Duncan Coutts **20081001033637 We can still add more as necessary ] [Add support for specifying source repos in .cabal files Duncan Coutts **20080930222708 Ticket #58. Does not yet include checking. ] [Simplify parsing sections in the .cabal file Duncan Coutts **20080930215509 Allow flags, lib and exes in any order and handle unknown sections better. ] [Fix how Cabal makes the value for __GLASGOW_HASKELL__ Ian Lynagh **20080920212207 6.10.x was giving us 601 rather than 610. ] [Treat "cabal --flag command" as "cabal command --flag" Duncan Coutts **20080928070627 eg "cabal -v configure" to mean "cabal configure -v" For flags that are not recognised as global flags, pass them on to the sub-command. ] [Update the version number in the Makefile Ian Lynagh **20080920175306] [Correct the version number in the Makefile Ian Lynagh **20080920175105] [Update build-deps Ian Lynagh **20080920175053] [Fix building with GHC 6.6 Ian Lynagh **20080920162927] [TAG 6.10 branch has been forked Ian Lynagh **20080919123438] [TAG GHC 6.10 fork Ian Lynagh **20080919005020] [Rename --distdir flag to --builddir Duncan Coutts **20080920180326 Old aliases kept for compatibility ] [TAG 1.5.5 Duncan Coutts **20080919142307] [Bump version number to 1.5.5 Duncan Coutts **20080919140130 Ready to make the 1.6 branch ] [filter mingw include directories out of rts's installDirs Ian Lynagh **20080918142958 GHC < 6.10 put "$topdir/include/mingw" in rts's installDirs. This breaks when you want to use a different gcc, so we need to filter it out. ] [Tell gcc on Windows where include/mingw is Ian Lynagh **20080918135718 We need to tell the gcc bundled with GHC on Windows where its mingw include directory is ] [On windows, fail if ghc's gcc or ld are not found Duncan Coutts **20080917235745] [Allow addKnownProgram to be used as an update, not just insert Duncan Coutts **20080917225856 ie preserves any existing user-supplied path and args ] [Cope with gcc.exe and ld.exe not being where ex expect on Windows Ian Lynagh **20080917221228] [Implement openNewBinaryFile in a Compat module Ian Lynagh **20080917171257 This is like openBinaryTempFile except it doesn't mark the permissions with 600. This means datafailes get the right permissions when they are installed. This should really be in the base package. ] [Generalise the type of onException Ian Lynagh **20080917171233 Now it matches Control.Exception's type ] [Yet another go at making gcc -B work properly on windows Duncan Coutts **20080916232553 This time it should work on linux too! But more significantly it should work when the user specifies a particular gcc. It would be very bad if the user gave an alternative gcc but we still gave it -B for the lib files of ghc's gcc. This go is rather cleaner as it uses the new program post-conf system. ] [Pass any additional gcc options through to gcc when calling hsc2hs Duncan Coutts **20080916232502] [Add an additional program post-conf action Duncan Coutts **20080916210642 The post-conf action gets given the configured program and is allowed to do more IO and can add any extra required program args. Should make it easier to do the gcc -B thing or ld -x ] [Make the new permissions compat module compile Duncan Coutts **20080916210550 Needs cpp pragma as it has to work with just ghc --make Did I ever mention I that hate cpp and compat modules? ] [Fix the env var names used in the Paths module Duncan Coutts **20080916093525 Convert any '-' in the package name to '_' when generating the path env var as most shells do not allow '-' in env var names. ] [Check for -optl-s as well as an alias of the more common -optl-Wl,-s Duncan Coutts **20080913005432] [pass -B flag to help gcc find libraries on Windows dias@eecs.harvard.edu**20080827124436] [workaround for nhc98, which does not have System.Posix.Internals Malcolm.Wallace@cs.york.ac.uk**20080915092747] [Set GHCI_LIB to "" in "Setup makefile" if GHC libs are disabled Ian Lynagh **20080913144040] [In "Setup makefile", don't build the vanilla way if it's disabled Ian Lynagh **20080913143132 This needs a bit of a kludge, as the vanilla way doesn't really exist as far as the build system is concerned. It's just the absence of way. ] [Fix the permission that we give wrapper scripts Ian Lynagh **20080913124445] [Documentation only: more typos/punctuation Tim Chevalier **20080914051331] [Documentation only: grammar fix in comment Tim Chevalier **20080914051008] [Documentation only: fix typo in comment Tim Chevalier **20080913214843] [Remove unused 'breaks' util function Duncan Coutts **20080910235804] [follow library changes Ian Lynagh **20080903223608] [Fix to compile with base-1.0:Data.List Duncan Coutts **20080904233126 which did not have isInfixOf ] [Fix cabal_macros.h for package names containing '-' Duncan Coutts **20080903220116 As with the Paths_pkgname module, we map '-' to '_' as the former is not a valid character in cpp macro identifiers. Fixes cpp redefinition warnings. First reported by gwern. ] [Pass the interfaces for the transitive set of dependencies to haddock Ian Lynagh **20080903123813 Otherwise we don't get links to types from packages that we don't directly depend on. ] [Update CPP-Options in Cabal.cabal to define CABAL_VERSION=1,5,4 Ian Lynagh **20080902170348 It was still defining CABAL_VERSION=1,5,3 ] [Add more detail to the -Werror and -fvia-C checks Duncan Coutts **20080902171413 Also, ban rather than just warn about the -optl-Wl,-s hack now that Cabal strips exes by default. ] [Haddock 2: #include Simon Marlow **20080901145843] [package concurrent not available in nhc98 Malcolm.Wallace@cs.york.ac.uk**20080902092802] [Display the right message for sdist --snapshot Duncan Coutts **20080831221756] [Bump the version number to 1.5.4 Duncan Coutts **20080831220418 due to the PackageSet/Index api changes ] [Use a hopefully more robust method of determining the gcc version Duncan Coutts **20080831220145] [Simplify the handling of --with-prog= in build/haddock commands. Duncan Coutts **20080831215551 We allow extra rgs and the location of programs to be given to the build and haddock commands, not just at configure time. The code to do this is now simpler and more general. This should not be the default use mode however since it involves configuring the programs each time where as doing it at configure time allows it to be done once and saved. Further, specifying a different version of the program at build time than at configure time is likely to fail, especially for the compiler programs. Changing the compiler really requires reconfiguring. ] [Update the haddock command help text Duncan Coutts **20080831215325 The haddock command now supports --haddock-options= ] [Add flags to build command for specifying program paths Duncan Coutts **20080831215135 So we're going to allow --with-PROG for the build and haddock commands, in addition to the existing --PROG-options= flags. ] [Use the new Program utils to simplify code in Configure Duncan Coutts **20080831215054] [Add some more handy Program utils Duncan Coutts **20080831214813 Mostly for dealing with lists of programs so that client code doesn't need quite to much flip foldl' (flip thing) Add specific helpers for reconfiguring programs and restoring a full ProgramConfiguration after usign read. ] [Don't redundantly pass programArgs in when calling programs. Duncan Coutts **20080831212526 That's already done by the Program framework so we were passing those extra args in twice. ] [Merge PackageSet and PackageIndex Duncan Coutts **20080830130250 Have just a single module that provides both the case sensitive and insensitive operations. Turns out we hardly use the case insensitive operations, and the places where we do are not performance sensitive at all. So we use the PackageSet implementation which stores the packages case sensitively and tack on the case insensitive operations but with linear time implementations rather than log time. For the merged module/type name use PackageIndex because that is what older released versions exported, so less needless client breakage. ] [Add checkPackageFileNames function to check portability of file names Duncan Coutts **20080827082349 Windows has restrictions on names of files and portable tar archives have some weird length restrictions too. Not yet used but should be used in sdist and hackage. ] [In wrappers, $executablename needs to expand to something with DESTDIR Ian Lynagh **20080828155554 The installed wrapper needs to call the executable in its final place, not inside the DESTDIR where we are constructing a package. ] [Allow passing haddock's location and options to "Setup haddock" Ian Lynagh **20080828142424] [We need to pass the CPP options to haddock 2 Ian Lynagh **20080828142303] [Add support for manually en/disabled flags Ian Lynagh **20080827170105 The immediate use for these is so that, in haddock, we can require ghc-paths normally, but in the GHC build we can manually turn off a flag so that this dependency isn't needed. We can't use a normal flag, or in the normal build Cabal would infer that the flag needs to be turned off if ghc-paths isn't available. ] [Add release date of 1.4.0.2 Duncan Coutts **20080826204810] [Ban package names that are not valid windows file names Duncan Coutts **20080826005502 At least for the purposes of distribution. So if you're on unix then you can call your package 'LPT1' if you feel you must, but you cannot distribute a package with this name. ] [Separate out and export installDirsOptions Duncan Coutts **20080826003240 The InstallDirs is a separate type so it's handy to have the command line and config file options for it available separately. It'd be useful in cabal-install for one thing. ] [Note the per-user install path on Windows in the README Duncan Coutts **20080824203923] [More changelog updates for 1.4.0.2 Duncan Coutts **20080824203744] [Teach Cabal about the PackageImports extension Ian Lynagh **20080825132352] [Rename --distpref to --distdir Duncan Coutts **20080825164258 It's more consistent with the other flag names for dirs. Kept the old name too, but it's not shown by --help. ] [We now depend on concurrent (split off from base) Ian Lynagh **20080824135145] [Bump version number to 1.5.3 Duncan Coutts **20080822160918] [Update changelog for recent 1.5.x changes Duncan Coutts **20080822160828] [Update changelog Duncan Coutts **20080802135452] [Don't pass cc-options to Haskell compilations Simon Marlow **20080821133421 This has no effect with GHC 6.9, and with earlier GHC's it was a misuse of cc-options. ] [Don't propagate cc-options to the InstalledPackageInfo Simon Marlow **20080821132551 cc-options is for options to be passed to C compilations in the current package. If we propagate those options to the InstalledPackageInfo, they get passed to C compilations in any package that depends on this one, which could be disastrous. I've seen cc-options like these: cc-options: -optc-std=c99 cc-options: -D_FILE_OFFSET_BITS=64 Cc-options: -Wall these are all clearly intended to be local, but are in fact currently propagated to all dependent packages. ] [Fix spelling of compatibility Duncan Coutts **20080818194951 At request of gwern who found that it was driving him nuts. ] [Minor info and help message improvements Duncan Coutts **20080813124957] [unbreak for non-GHC Malcolm.Wallace@cs.york.ac.uk**20080814182558] [Catch exit exceptions as well as IO exceptions after running programs Ian Lynagh **20080813213035 We need to catch IO exceptions for things like "couldn't find the program", but we also need to catch exit exceptions as Cabal uses them to signal what the program returned. ] [Fix for #333, "Setup sdist --snapshot fails" Duncan Coutts **20080821154913 Credit to Spencer Janssen. This is just a slight alternative to the fix he proposed. It simplifies prepareSnapshotTree. ] [Move Paths_pkgname and cabal_macros.h generation into their own modules Duncan Coutts **20080813193245] [fix imports for nhc98 Malcolm.Wallace@cs.york.ac.uk**20080813132112] [Add util rewriteFile :: FilePath -> String -> IO () Duncan Coutts **20080813192017 Write a file but only if it would have new content. If we would be writing the same as the existing content then leave the file as is so that we do not update the file's modification time. ] [Don't warn about missing strip.exe on Windows Duncan Coutts **20080812220415 We don't expect Windows systems to have the strip program anyway. ] [Flush stdout when printing debugging messages Duncan Coutts **20080812212236] [Add auto-generated CPP macros for package version testing Simon Marlow **20080811173016 Now when using CPP you get MIN_VERSION_(A,B,C) for each in build-depends, which is true if the version of in use is >= A.B.C, using the normal ordering on version numbers. This is done by auto-generating a header file dist/build/autogen/cabal_macros.h, and passing a -include flag when running CPP. ] [allow Cabal to use base-4 Simon Marlow **20080806130512] [Fix warnings in Windows Paths_pkgname module Duncan Coutts **20080812211349] [Fix the config-file field name of the install command's packagedb option Duncan Coutts **20080812171207] [Add alias type PackageId = PackageIdentifier Duncan Coutts **20080812171006] [Add data Platform = Platform Arch OS Duncan Coutts **20080812160941 Since we tend to pass them around together rather a lot. Also add a Text instance with a format like "i386-linux" ] [Don't use tab characters in the generated Paths module Duncan Coutts **20080812160731] [Make binary-dist do nothing in doc/Makefile, for now Ian Lynagh **20080810005135] [When running "Setup makefile", put "default: all" at the top of the Makefile Ian Lynagh **20080809211148 This make "make" work even if Makefile.local contains any targets. ] [Use 'ghc-pkg dump' instead of 'ghc-pkg describe *' David Waern**20080807190307 Does not implement lazy parsing of the output of ghc-pkg dump, so this is only a partial fix of #311. For more information about why we want to use ghc-pkg dump, see GHC ticket #2201. ] [Simplify InstalledPackageInfo parser and pretty printer Duncan Coutts **20080806122807 Using the new utils in ParseUtils. ] [Add parsse utils for simple flat formats. Duncan Coutts **20080806122613 Should help to simplify the InstalledPackageInfo parser and also for similar formats in cabal-install. ] [Tidy up the ppFields function and uses Duncan Coutts **20080806121315 Put the arguments in a more sensible order: ppFields :: [FieldDescr a] -> a -> Doc and make the implementation clearer. clean up the use of it in the PackageDescription.Parse module ] [Windows fixes Ian Lynagh **20080803201253] [setup makefile: put the source-dir suffix rules after the distdir suffix rules Simon Marlow **20080806130309 This matches the behaviour of 'setup build' works, and is robust to people accidentally having old preprocessed sources lying around in the source dir. ] [Generalise checkPackageFiles to any monad, not just IO Duncan Coutts **20080806001547 This is to let us use the same checks for virtual or in-memory file systems, like tarball contents. ] [Move parseFreeText into ParseUtils and use it more widely Duncan Coutts **20080806001352] [Document and refactor 'parsePackageDescription'. Thomas Schilling **20080804190324 Hopefully this makes this function more understandable and easier to modify. ] [Adjust registration to allow packages with no modules or objects Duncan Coutts **20080804155826 So ghc-pkg does not complain about missing files and dirs. ] [Don't try to install libHSfoo.a if the lib had no object files Duncan Coutts **20080804143817 To allow meta-packages. ] [Fix instance Monoid ConfigFlags for configStripExes Duncan Coutts **20080802002045] [Fix the Windows build Ian Lynagh **20080731194841] [Remove unused imports Ian Lynagh **20080730194526] [Make Cabal compatible with extensible exceptions Ian Lynagh **20080730183910 The code is now also more correct, e.g. when we are ignoring IO exceptions while trying to delete something, we don't also ignore timeout exceptions. ] [Document the "exposed" .cabal file field Duncan Coutts **20080731162807] [Remove unused imports Duncan Coutts **20080730182957] [Remove unused inDir util function Duncan Coutts **20080730165031] [Add an "exposed" field to the .cabal file library section Duncan Coutts **20080730164516 It's a bool flag that says if by default the library should be registered with the compiler as exposed/unhidden (for compilers which have such a concept, ie ghc). You might want to do this for packages which would otherwise pollute the module namespace or clash with other common packages. It should be very rarely used. The only current examples we know of are the ghc api package and the dph packages. ] [Rearrange the Monoid instances for Library, Executable, BuildInfo Duncan Coutts **20080730163432 No functional change, just moving code about. We now define the Monoid methods directly rather than in terms of emptyLibrary, unionLibrary etc. ] [Do the ghc rts ldOptions hack in a slightly more hygenic way Duncan Coutts **20080729195714] [Pass the right -F and --framework flags when running hsc2hs on OS X Ian Lynagh **20080729172757] [Tweak a test to not go via the pretty printer Ian Lynagh **20080729172750] [Fix linking with hsc2hs on OS X Ian Lynagh **20080729170215 We don't tell hsc2hs to link the actual Haskell packages, so with GHC's rts package we need to also filter out the -u flags. ] [Tweak whitespace Ian Lynagh **20080729163729] [Fix uses of verbosity > deafening to use >= Duncan Coutts **20080729191855 The maximum verbosity value is deafening so >= the correct test. This primarily affected haddock. ] [Do not use ',' as a list separator for the cpp/cc/ld-options fields Duncan Coutts **20080729170556 It breaks for some options like "ld-options: -Wl,-z,now" No existing .cabal files on hackage were using ',' as a list separator so this should not break anything. ] [Move docs for build-depends into the build information section Duncan Coutts **20080729162024 Since it is shared between libs and exes. Extend the documentation to describe the syntax of version constraints, including the new version range syntax "build-depends: foo ==1.2.*". ] [Remove references to cabal-setup from the documentation Duncan Coutts **20080729160950 Change to runhaskell Setup or cabal-install as appropriate. ] [Move the docs for the buildable field to a better place. Duncan Coutts **20080729160808 It doesn't need to be right up near the top. ] [Document more clearly that every modules must be listed Duncan Coutts **20080729160308 in one of the fields exposed-modules, other-modules or main-is Add an extra note to the section on the Paths_pkgname module as the fact that it's automatically generated confuses people. ] [Document the wildcard behaviour in data-files and extra-source-files fields Duncan Coutts **20080729155920] [Document the $os and $arch install path vars Duncan Coutts **20080729155654] [File globs must match at least one file or it's an error. Duncan Coutts **20080729154050] [Fix the semantics of the simple file globbing to be sane Duncan Coutts **20080729152624 I realised when I started to document it that the behaviour was not terribly consistent or sensible. The meaning now is: The limitation is that * wildcards are only allowed in place of the file name, not in the directory name or file extension. In particular, wildcards do not include directories contents recursively. Furthermore, if a wildcard is used it must be used with an extension, so "data-files: data/*" is not allowed. When matching a wildcard plus extension, a file's full extension must match exactly, so "*.gz" matches "foo.gz" but not "foo.tar.gz". The reason for providing only a very limited form of wildcard is to concisely express the common case of a large number of related files of the same file type without making it too easy to accidentally include unwanted files. ] [Allow $arch and $os in install paths. Duncan Coutts **20080729151952 Fixes ticket #312. For example a user could use: cabal configure --libsubdir="$pkgid/$compiler/$arch" if they wanted to have packages for multiple architectures co-exist in the same filestore area. ] [Use "pkg == 1.2.*" as the version wildcard syntax Duncan Coutts **20080729151612 Rather than "pkg ~ 1.2.*". This seemed to be the consensus. The syntax "pkg == 1.2.*" means "pkg >= 1.2 && < 1.3" and it is to encourage people to put upper bounds on api versions. ] [disambiguate Control.Exception.catch for nhc98 Malcolm.Wallace@cs.york.ac.uk**20080728164506] [more import qualification to help nhc98 Malcolm.Wallace@cs.york.ac.uk**20080728153629] [help nhc98's module disambiguator a bit Malcolm.Wallace@cs.york.ac.uk**20080724165753] [Pass -no-user-package-conf to ghc when not using UserPackageDB Duncan Coutts **20080729145040 Should eliminate the corner case where we're doing a global install but the user package db contains the exact same version as in the global package db. Perhaps we should warn in that case anyway since it's likely to go wrong later. ] [Substitute for $topdir when we read GHC's InstalledPackageInfo's Ian Lynagh **20080723112232] [Fix the location of gcc.exe in a Windows GHC installation Ian Lynagh **20080723101848] [Don't need the complex code in detecting hsc2hs anymore Duncan Coutts **20080720234019 Since we do not need to know if hsc2hs uses ghc or gcc as cc by default since in either case we now tell it to use gcc. ] [Always use gcc as cc with hsc2hs Duncan Coutts **20080720233759 Lookup what flags to use from the package index. Previously this was done by calling ghc as cc and passing -package flags to ghc. ghc would then lookup what extra flags to pass to gcc. We now do that ourselves directly and it's a good deal simpler and it's portable to the other haskell implementations. This is only a first go, the flags may not all be exactly right. Needs testing. ] [Add gccProgram Duncan Coutts **20080720232818 on Windows we have to find ghc's private copy of gcc.exe ] [Add PackageSet.topologicalOrder and reverseTopologicalOrder Duncan Coutts **20080720223731 with type :: PackageFixedDeps pkg => PackageSet pkg -> [pkg] ] [Change some PackageSet functions to return the package rather than the id Duncan Coutts **20080720221702 dependencyGraph and reverseDependencyClosure now return the full package rather than just the PackageIdentifier ] [Convert from PackageIndex to PackageSet Duncan Coutts **20080720194924 Turns out the feature to do case-insensitive lookups was only needed in cabal-install (and only in one little part) and elsewhere it causes problems. So use PackageSet instead. ] [If we have GHC >= 6.9 then use the new -optdep replacement flags Ian Lynagh **20080722163346] [And exitcode of 2 from ghc-pkg when doing describe '*' means no packages Ian Lynagh **20080722125759 This is a bit of a kludge around GHC's #2201, until Cabal is updated to use ghc-pkg dump. ] [Fix warnings and add a comment explaining why we pass -x to strip on OS X Ian Lynagh **20080720220851] [Pass -x to strip on OSX Duncan Coutts **20080720204609] [Generate expanded makefile rules directly, rather than using $(eval ...) Ian Lynagh **20080720194801 We used to do this with $(eval ...) and $(call ...) in the Makefile, but make 3.79.1 (which is what comes with msys) doesn't understand $(eval ...), so now we just stick the expanded loop directly into the Makefile we generate. ] [Put GHC's programArgs in GHC_OPTS when making a Makefile Ian Lynagh **20080715132429] [Pass -package-conf foo when using GHC as CC Ian Lynagh **20080713123958] [If we are using ghc as hsc2hs's cc, then tell it where package.conf is Ian Lynagh **20080713110548 if we have been told to use a specific one with --package-db ] [Fix installing datafiles Ian Lynagh **20080712173934 If datadir is foo and the datafile is bar then we should install it to $datadir/bar, not $datadir/foo/bar. ] [Fix the "Setup makefile" rules for C files Ian Lynagh **20080712173851] [If install is given a distPref, pass it on to copy and register Ian Lynagh **20080712121916] [derive Eq for ConfiguredProgram Duncan Coutts **20080711160138 a request from Saizan ] [Simplify ghc version test slightly Duncan Coutts **20080711142026] [Add a hack to copy .hs-boot files into dist/... Ian Lynagh **20080711000826 When a preprocessor generates a .hs file we need to put the .hs-boot file next to it so that GHC can find it. ] [Teach "Setup makefile" how to cope with multiple hs-source-dirs Ian Lynagh **20080711000726] [Fix some whitespace in Makefile.in Ian Lynagh **20080710231519] [In Makefile.in, put all the rules that mentions srcdir together Ian Lynagh **20080710231415] [Fix haddocking (with old haddocks?) Ian Lynagh **20080703154714] [Correct the order of args given by --PROG-options Duncan Coutts **20080710181437 They were getting reversed. Problem located by Igloo. ] [Remove the need for a compat Data.Map module Duncan Coutts **20080710154600 Stop using Map.alter, use the same solution as the PackageIndex module. ] [fix #if __GLASGOW_HASKELL__ test Ross Paterson **20080705105048 The problem is that #if __GLASGOW_HASKELL__ < NNN is also true for non-GHC. It should be #if __GLASGOW_HASKELL__ && __GLASGOW_HASKELL__ < NNN ] [help nhc98's import overlap resolver Malcolm.Wallace@cs.york.ac.uk**20080704140613] [massage a pattern-with-context around nhc98's typechecker Malcolm.Wallace@cs.york.ac.uk**20080704140541] [Fix using specified package databases Ian Lynagh **20080703001216 If we are using a specified package database, we need to tell GHC what it is when building ] [Fix the build with GHC 6.4.2: Data.Map.alter doesn't exist Ian Lynagh **20080703001151] [Allow installing executables in-place, and using shell script wrappers Ian Lynagh **20080629164939 GHC-only currently. ] [haddock typo Ian Lynagh **20080629114342] [Fix a haddock typo Ian Lynagh **20080629114239] [Update .darcs-boring Ian Lynagh **20080627182013] [TAG 2008-05-28 Ian Lynagh **20080528004259] [Remove the SetupWrapper module Duncan Coutts **20080628173010 It's not used in Cabal itself and while cabal-install used it previously, it now has its own extended implementation. ] [Update module headers Duncan Coutts **20080628172550 Use cabal-devel@haskell.org as the maintainer in most cases except for a few which were pre-existing modules copied from elsewhere or modules like L.H.Extension which really belong to libraries@haskell.org Remove the useless stability module. We have more detailed information on stability elsewhere (in the version number and user guide). Add more top level module documentation, taken from the source guide. ] [Whitespace changes, convert tabs to spaces Duncan Coutts **20080626200933] [Remove a couple old deprecated empty modules Duncan Coutts **20080626195204] [Add ModuleName as a new type instead of using String everywhere Duncan Coutts **20080626192939] [Tweaks to the readme, hopefully will reduce confusion Duncan Coutts **20080625232051] [Add compat InstalledPackageInfo types for older GHCs Duncan Coutts **20080621013727 We need these types for their Read instances so that we can still read older GHCs package db files when we make changes to the current InstalledPackageInfo type, or the types contained in it, like PackageIdentifier or License. ] [Add simple file name globbing (*) to data-files and extra-source-files Duncan Coutts **20080626171424] [Use conservative render style for display Duncan Coutts **20080619222258] [Include trailing newline in hscolour command description Duncan Coutts **20080619220940] [Add PackageSet, like PackageIndex but case sensitive Duncan Coutts **20080614003705 Actually it turns out that we don't need case insensitivity in many cases, mosty just for simple lookups in the UI. For everything else the ordinary Ord instance is much simpler. The fact that listing the contents of a PackageIndex doesn't come out in Ord order actually causes real problems in cabal-install and necessitates re-sorting. So we should move to using PackageSet in most cases and just leave the search and lookup operations in PackageIndex. ] [Add PackageName as a newtype Duncan Coutts **20080614002926] [No more need for the distinction between null and emptyBuildInfo Duncan Coutts **20080614001654 Now that we have removed the hsSourceDirs = [currentDir] default from emptyBuildInfo it is now equal to nullBuildInfo. ] [Add version wildcard syntax Duncan Coutts **20080619175006 build-depends: foo ~1.2.* means: build-depends: foo >=1.2 && <1.3 It's also valid everywhere else version ranges are used. ] [haddock-2.2 and later do now support the --hoogle flag Duncan Coutts **20080613205445] ['.' should not always be in hs-source dirs Duncan Coutts **20080613230352 We changed the parsing of list fields in the .cabal file so that it adds to the current value rather than replacing it. This allows you to put multiple entries for a list field and they all get concatenated. However that means that the '.' in the hsSourceDirs of emptyBuildInfo is always added to and not replaced like we did previously. That's not what we want in this case. We want to use '.' for hsSourceDirs *only* if hsSourceDirs is otherwise null. As it happens, due to the way the configurations code works, we're already filling in the default if it'd otherwise be null so we do not need '.' in the emptyBuildInfo at all. ] [Fix css location in generation of user guide Duncan Coutts **20080617133811] [Update changelog for 1.4.0.1 Duncan Coutts **20080617130434] [Makefile tweak, setup depends on Setup.hs Duncan Coutts **20080616175446] [force results inside withHaskellFile Ross Paterson **20080614160707 withUTF8FileContents now closes the file, so we need to force what we're computing from the contents before it's gone. ] [construct InstalledPackageInfo from scratch rather than by overriding Duncan Coutts **20080616171505 It means we catch any fields that get added. As it happens we were missing a field, though its value is supposed to be just [] which is the same value as we got from the default emptyInstalledPackageInfo. ] [Include the readme and the changelog in the tarball Duncan Coutts **20080612190558] [Move the mkGHCMakefile.sh out of the root dir Duncan Coutts **20080612190317 Having it there confuses people. They think they have to run it as part of the install process. ] [Put upper bounds on all the build-depends Duncan Coutts **20080612174958] [Add the 1.4.0.0 release to the changelog Duncan Coutts **20080612164242] [Add the 1.2.4.0 release to the changelog Duncan Coutts **20080612164144] [Update the README and convert it to markdown syntax Duncan Coutts **20080612162906] [Update the release notes Duncan Coutts **20080612154624] [Update copyright and authors list in the .cabal file Duncan Coutts **20080612154444] [base-1.0 does not have Data.Map.alter so use insertWith instead Duncan Coutts **20080612154309] [Lift the restriction that libraries must have exposed-modules Duncan Coutts **20080612092924 This allows libs that have only private modules or C code. This might be used to make libs that have non-exposed modules and only export C APIs. It could also be used to make packages that consist only of C code. That might be useful for bindings where it may make sense to split the C and Haskell code into separate packages. ] [Use the standard autogenModulesDir rather than a local copy Duncan Coutts **20080612092855] [Fix the register --gen-pkg-config flag Duncan Coutts **20080612092425 When specified without any file name it is supposed to use a default file name rather than be ignored completely. ] [Filter out the Paths_pkgname file in sdist Duncan Coutts **20080612091810 Fixes ticket #187 finally (I hope). ] [Switch the hugs code to safe file reading and writing Duncan Coutts **20080610180947] [Use writeFileAtomic everywhere instead of writeFile Duncan Coutts **20080610180727] [Switch to scoped file reading rather than lazy readFile Duncan Coutts **20080610180528] [Close the package.conf file after reading it Duncan Coutts **20080610180217 We had a bug on windows where we open and read ghc's package.conf database but because we did not consume the final newline we did not close the file. Then when we called ghc-pkg to register a package it failed because it could not rename the open file. ] [Add withFileContents and withUTF8FileContents Duncan Coutts **20080610180150 Safe block scoped reading of files. These guarantee that the file gets closed. ] [Fix pre-processing for haddock and executables Duncan Coutts **20080609233609 Now look in the right place to find the pre-processed source files belongign to executables. Fixes ticket #252. ] [Fail better when using haddock 2.x and the --hoogle flag Duncan Coutts **20080609190555 Fixes ticket #249 ] [Install haddock interface only when generated Duncan Coutts **20080609190251 This is actually Andrea Rossato's patch but it didn't merge cleanly due to more recent changes. Fixes ticket #250. ] [Install license file into the right place Duncan Coutts **20080609185840 even if the license file was kept in a subdir of the src tree. The canonical example was: license-file: debian/copyright It was being installed into $docdir/debian/ and failing since that dir did not exist. It's now installed into just $docdir. ] [Bump version due to api changes Duncan Coutts **20080529104714] [Put spaces round || and && when displaying version range expressions Duncan Coutts **20080529104214 This makes them much more readable. ] [Change the PackageIndex invariant so the buckets are ordered Duncan Coutts **20080529095346 Each bucket holds packages with the same name case-insensitively. Previously each buckets was internally unordered. Now they're ordered by the full package id which means first by package name case-sensitively and then by version. ] [Add thisPackageVersion and notThisPackageVersion Duncan Coutts **20080529092607 Util functions for makeing dependencies from package identifiers. thisPackageVersion (foo-1.0) = foo ==1.0 notThisPackageVersion (foo-1.0) = foo /=1.0 The latter is handy as a constraint in dependency resolution. ] [Add notThisVersion :: Version -> VersionRange Duncan Coutts **20080529092244 Opposite of ThisVersion, it means /= x.y but is actually implemented as > x.y || < x.y as we do not have not or not equal as primitives. ] [Note compatability issue in deprecation message for defaultUserHooks Duncan Coutts **20080527135830] [Write out Bool config values correctly Duncan Coutts **20080521153420 Used by cabal-install when writing the default ~/.cabal/config file. Previously it was using show for type Maybe Bool and writing out "Just True" when of course it should just be "True". ] [Rename doc/fptools.css to avoid the ghc build system cleaning it Duncan Coutts **20080520191700 The user guide gets built in two different ways. There's a target in Cabal's the top level Makefile and there is also the stuff that the ghc build system uses. The ghc build system expects to copy in doc/fptools.css and then delete it again on make clean. We want a persistent copy so that we can make the docs when we've just got a standalone Cabal build tree, so that's now kept as doc/Cabal.css. ] [Remove gnerated file (doc/fptools.css) Ian Lynagh *-20080511130035] [document data-dir field Bertram Felgenhauer **20080509131306] [add data-dir field to package config Bertram Felgenhauer **20080509130448 Cabal will look for data files to install relative to the directory given in the data-dir field, allowing package authors to better structure their source tree. There's no behavioural change by default. ] [Allow the bindir, libdir and libexec dir to be specified via env vars too Duncan Coutts **20080519173808 Same as for the datadir. Eg for package Foo, you'd use Foo_bindir=... Foo_datadir=... Foo_libexecdir=... ./Foo The next step would be generating a wrapper script that allows running the program inplace. It should also work for a library. ] [Remove unused import Duncan Coutts **20080513094301] [Do not display version tags Duncan Coutts **20080509094455] [Remove Distribution.Compat.Exception from other-modules Duncan Coutts **20080514171822] [Add PackageIndex.lookupPackageName and extra deletion functions Duncan Coutts **20080514162954] [Check invariant on every construction and elide on lookups Duncan Coutts **20080514154104] [Remove redundant Char test in parseBuildToolName Duncan Coutts **20080514153343 It was made redundant after the isSymbol test was removed. Spotted by Igloo. ] [Eliminate use of bracketOnError, use handle instead Duncan Coutts **20080514153206 It's actually more appropriate anyway. This means we don't need any Distribution.Compat.Exception. ] [Define bracketOnError in compat; fixes the build for GHC 6.4 Ian Lynagh *-20080514003919] [Add in {-# OPTIONS #-} for the benefit of ghc-6.4.x Duncan Coutts **20080514144728 Which do not grok OPTIONS_GHC or LANGUAGE pragmas ] [fix scope errors in non-GHC branch of an #ifdef Malcolm.Wallace@cs.york.ac.uk**20080514112530] [Prefix the datadir env var with the package name Duncan Coutts **20080514094203 Partly as it is more likely not to clash with other users and since in general different libs within a program may need different paths. ] [Made it possible to run executeables with data files in place. Johan Tibell **20080413134155 Added an environment variable, DATA_DIR, that is checked before the installation data directory is used. ] [Don't use Data.Char.isSymbol as it doesn't exist in base-1.0 Duncan Coutts **20080514083405 This is an alternative fix to creating a Distribution.Compat.Char ] [Modules that use cpp have to have cpp language prama to say so Duncan Coutts **20080514082913 Otherwise we cannot compile with just ghc --make which is actually essential for bootstrapping. ] [Make Distribution.Compat.Char for isSymbol; fixes the build with GHC 6.4 Ian Lynagh *-20080514004703] [Add new compat modules to Cabal file Ian Lynagh **20080514022119] [Make Distribution.Compat.Char for isSymbol; fixes the build with GHC 6.4 Ian Lynagh **20080514004703] [Hack around lack of Read for Map in GHC 6.4 Ian Lynagh **20080514004400 This is made worse by Show on Map being strange in GHC 6.4. The code could be better, but it works, and all the ugliness is in #if's that we can remove at some point down the line. ] [Define bracketOnError in compat; fixes the build for GHC 6.4 Ian Lynagh **20080514003919] [Print exit code and stderr for failing progs at debug level verbosity Duncan Coutts **20080513094055 Also adjust the verbosity level we get during configure at -v3 Should make it a bit easier to track down failing calls. ] [Remove a hardcoded "dist" Ian Lynagh **20080511181305] [Make the "dist" directory configurable Ian Lynagh **20080511155640] [Remove gnerated file (doc/fptools.css) Ian Lynagh **20080511130035] [Fix a bug in the unlitter Ian Lynagh **20080510233852 If we see a birdtrack while we are in latex mode, then we stay in latex mode - don't change into bird mode! ] [Display Cabal version in configure output with -v Duncan Coutts **20080509163507 eg "Using Cabal-1.5.1 compiled by ghc-6.8" Annoyingly ghc doesn't give us its full version number. ] [Add PackageIndex.reverseDependencyClosure Duncan Coutts **20080506234902 It's similar to dependencyClosure but looks at reverse dependencies. For example it's useful to find all packages that depend on broken packages and are thus themselves broken. ] [Improve style and performance of PackageIndex.dependencyClosure Duncan Coutts **20080506234447 Keep the completed set as another PackageIndex rather than a list. We want to return an index at the end anyway and in the mean time we want to do lots of lookups to see if we've visited previously. ] [Add PackageIndex.dependencyGraph that builds a Graph Duncan Coutts **20080506234326 Useful for some more tricky queries. ] [Remove a test for the specific kind of exception for nhc98 compatibility Duncan Coutts **20080506102804 This was the check for ghc-pkg failing. We cannot check for the exception being an ExitException since that assumes ghc's representation of the Exception type, whereas nhc98 defines: type Exception = IOError ] [Add PackageIndex.delete Duncan Coutts **20080506131603 We occasionally need to remove packages from an index eg to restrict the choices of a dependency resolver. ] [Cope better with ghc bug #2201, display a better error message Duncan Coutts **20080505085746 Otherwise it can (and does) really confuse people. The problem is that the command $ ghc-pkg-6.9 describe '*' --user returns a non-zero exit code if the user package db is empty. ghc-pkg intends this exit code to tell us if the query returned any results (one can use more complex queries as tests) but Cabal interprets it as failure. Indeed we cannot distinguish it from any other kind of failure from ghc-pkg. ] [Add PackageIndex.dependencyCycles Duncan Coutts **20080504131626 Finds any cycles (strongly connected components) in the dependencies of set of packages. This is useful for checking the correctness of installation plans. ] [Change dependencyInconsistencies to not take the pseudo top package Duncan Coutts **20080504130802 The one case where we need the pseudo top package we can use PackageIndex.insert instead to get the same effect and there are other cases in cabal-install where we do not want a pseudo top package. ] [Reverse the order of the args to PackageIndex.insert Duncan Coutts **20080504130317 To take the index last like the other functions and like Data.Map. It is actually more convenient that way round. ] [Revert the change about the --internal flag and a warning about haddock Duncan Coutts **20080501223131 Just a bit of confusion over the behaviour of the --executable flag. ] [Document --internal in Cabal.xml Joachim Breitner **20080501153356] [With --executable, --internal just adds --ignore-all-exports Joachim Breitner **20080501152544] [Implement --internal flag Joachim Breitner **20080501152421 Passing --internal to the haddock stage does these things: * Does not pass --hide parameter to haddock * Passes --ignore-all-exports parameter * Appends "(internal documentation)" to the title ] [Add an --internal flag to HaddockFlags Joachim Breitner **20080501145103] [Revert the other `fmap` to (.) Malcolm.Wallace@cs.york.ac.uk**20080501110006 To avoid needing a non-H'98 instance of Functor for (->). ] [Revert one change of (.) to fmap. It was not necessary and broke nhc98. Duncan Coutts **20080501104620 The other one was needed as we changed a type from Bool to Maybe Bool. ] [Add help command as per ticket #272 Duncan Coutts **20080430133740 "cabal help" behaves like "cabal --help" "cabal help cmd" behaves like "cabal cmd --help" Should still work with command line completion. ] [Change handling of bool command line args to allow an unset state Duncan Coutts **20080429201123 For bool valued flags we were always producing the command line string corresponding to a false flag value, even if the flag was not set. For example we'd always get "--disable-shared". It is important for cabal-install to be able to take an empty set of flags, override a few flags and turn the flags back into command line strings without getting a lot of extra defaults. Partly this is because we have to work with older versions of the Cabal library command line which does not recognise the new options. ] [Remove the feature for highlighting the default cases in --help output Duncan Coutts **20080429191206 Turns out it doesn't help us much because in many cases the initial/default flags are actually empty so we cannot identify the default values. ] [Make the old test code compile Duncan Coutts **20080428225729 Still a lot of bit rot, many of the full tests fail due to changed paths ] [Fix license parsing Duncan Coutts **20080428192255 Spotted by the testsuite which I'm trying to resurrect. ] [Fix fix for #224. Thomas Schilling **20080426164537 Changing from list of Dependencies to Maps resulted in the wrong Monoid instance being used. I'd still like to be able to run a test suite on this but that'd require a lot more work to do properly... ] [When multiple specifying list fields in the same section combine them Duncan Coutts **20080423201519 eg if you had: extensions: Foo extensions: Bar, Baz then previously we only ended up with [Bar, Baz]. Now we get them all. Only applies to list fields, for single fields the second value is taken and the first is silently discarded. This isn't good of course but the fix is harder since we're not in a context where we can report errors. Really we should just declare up front what kind of field it is and inherit the right behaviour automagically, either duplicates disallowed or allowed and combined with mappend. ] [Normalise file names in warning messages Duncan Coutts **20080423190457 We already do this for error messages. ] [Fix the check for -XFooBar ghc-options flags to be more permissive Duncan Coutts **20080423190243 Previously we rejected all such flags but that posed the problem that older versions of Cabal, like 1.1.6 did not understand new extensions so we could not actually follow the advice and use the extenion. So now we only warn about -X flags if they refer to old extensions that Cabal 1.1.6 knew about. If the .cabal file specifies cabal-version: >= 1.2 or similar (anything that excludes 1.1.6) then we warn about all -X flags. ] [Add checks for unknown OS Arch and Compiler names Duncan Coutts **20080423151410 They're ok locally but for distribution they need to be known. ] [Package check now take a GenericPackageDescription Duncan Coutts **20080423150354 Unfortunately in some cases we only have a already-configured PackageDescription to we have to expose a checkConfiguredPackage. We should refactor things so that we keep all the information even in a configured PackageDescription. ] [fix import for nhc98 Malcolm.Wallace@cs.york.ac.uk**20080422133009] [Make warning messages show the file name Duncan Coutts **20080422141909] [Update UTF8 code Duncan Coutts **20080422141539 Some code and test cases taken from the utf8-string package. Updated copyright notice appropriately (I think). ] [Don't nub extra-libs in unionBuildInfo Duncan Coutts **20080420192312 It's possible that we sometimes need to list the same library more than once if there are circular symbol references. ] [Fix unionBuildInfo Duncan Coutts **20080420180520 Fix ticket #264 to use nub only on the fields which are treated as sets. Probably we should be using the right types and mappend for each field. Change to construct a new value from scratch rather than overriding one of the two args. This helps to make sure we're updating all the field as we get a warning if we miss any. Turns out we were missing the ghc profiling and shared libs options which meant they were getting dropped. That had the effect of ghc-prof-options: in .cabal files being ignored. Thanks to 'midfield' from #haskell for spotting this. ] [Add newtype FlagName and FlagAssignment type alias Duncan Coutts **20080415204854 and use them in the appropriate places. ] [Add PackageIndex.insert and reverse merge/mappend Duncan Coutts **20080415203637 Packages in the second argument to merge now mask those in the first. ] [Make finalizePackageDescription use CompilerId type Duncan Coutts **20080413224111 Use the proper data type rather than a tuple (CompilerFlavor, Version) ] [Fix #224. We do not yet warn if the user specified a dependency that Thomas Schilling **20080413182659 did not occur in the package (it is just silently ignored.) ] [Add 'readP_to_E' function that takes the longest parse. Thomas Schilling **20080413182042] [Add simple test case for the dependency resolution case. This should Thomas Schilling **20080413132002 go into the test suite one day. ] [Fix/Add documentation. Thomas Schilling **20080413131839] [Change dependency resolution algorithm. Thomas Schilling **20080413131807 There were two reasons to do this. Firstly, this formulation makes it easier to add the --constraint command line flag that adds additional constraints on the packages that should be used. Secondly, with the orgininal algorithm it was possible to satisfy the constraint "foo < 1, foo > 2" if we had two versions of package "foo" which each satisfy one constraint. This patch fixes this by requiring the same package to satisfy both constraints (which of course is impossible in this case). ] [expose ghcOptions jeanphilippe.bernardy@gmail.com**20080417211221 This helps finding the options to pass to GHC API in various tools ] [expose tryGetConfigStateFile jeanphilippe.bernardy@gmail.com**20080417180248 This is needed by Yi to (try to) load an arbitrary project. ] [fix for #187 -- directory of Paths_packagename is included when looking for source files Andres Loeh **20080412204904] [Check for the required cabal version early in parsing Duncan Coutts **20080409154655 Previously we only checked the "cabal-version" field after parsing and all other configure processing. If the package really needs a later Cabal version it is of course highly likely that parsing or configure are going to fail and the user is not going to get the helpful error message about the version of Cabal required. So now we do the check early during parsing. If a later version is required and parsing subsequently fails, we now report the version issue, not the subsequent parse error. If parsing succeeds we still issue a warning which should be a useful hint to the user if subsequent configure processing fails. ] [Use relative file paths in .cabal parse error messages Duncan Coutts **20080409154030 Do this by normalising the file path in the error message and when looking for .cabal files, by looking in '.' rather than the absolute path of the current directory. ] [Remove unused import Duncan Coutts **20080409073352] [Fix for detecting ~/.cabal/ dir as a .cabal file Duncan Coutts **20080409073236 Which happened if you use cabal configure in your home dir. Now produced the right error message, or if you actually put a cabal project in your home dir, it might actually work. Also, do the same fix for findHookedPackageDesc. ] [Fix spelling in error message Duncan Coutts **20080408134610] [Fix names of profiling libs Duncan Coutts **20080407013449 I broke this recently when refactoring. Restore the original behaviour. Was generating "libHSfoo_p-1.0.a" when it should be "libHSfoo-1.0_p.a". ] [TAG 1.5.1 Duncan Coutts **20080329181329] Patch bundle hash: f9e7afe8e10496cf0d5a2e9421700180af2ac8a6 From duncan.coutts at worc.ox.ac.uk Thu Jan 29 18:59:40 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 29 18:49:52 2009 Subject: Bug in Cabal? In-Reply-To: <1233229419.26754.255.camel@localhost> References: <1232529549.8432.229.camel@localhost> <1233148429.26754.105.camel@localhost> <1233229419.26754.255.camel@localhost> Message-ID: <1233273580.26754.293.camel@localhost> On Thu, 2009-01-29 at 11:43 +0000, Duncan Coutts wrote: > On Wed, 2009-01-28 at 13:13 +0000, Duncan Coutts wrote: > > > The solution I think, is never to copy the read-only attribute when > > installing files. It's thoroughly unhelpful. I've got a patch to do this > > which I shall push to Cabal HEAD shortly. If you have a moment to help > > me test that it would be much appreciated. > > I've attached a darcs patch against the Cabal-1.6 branch (rather than > the head branch). > > darcs get --partial http://darcs.haskell.org/cabal-branches/cabal-1.6/ The patch is now in the 1.6 branch, along with a fix to make it work with other ghc versions. > If you or anyone else can test it on Windows that'd be great. I checked > it by setting the read-only attribute on a LICENSE file and where > previously the attribute would get copied (preventing further > re-installs) it is now not copied. > On Unix it should solve this problem: > http://hackage.haskell.org/trac/hackage/ticket/93 > Though I've not tested that yet. It appears to fix this problem too. > The patch for the 1.6 branch is fairly minimal and doesn't change any > API. In Cabal HEAD I'll do it slightly differently so that the code is > more consistent and comprehensible, but it involves api changes to > exposed utility functions. I've pushed these changes too now so it should also work in Cabal HEAD and with a saner api. Duncan