From duncan.coutts at worc.ox.ac.uk Sun Mar 1 13:24:15 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 1 13:13:09 2009 Subject: ANNOUNCE: tar 0.3.0.0 Message-ID: <1235931855.7915.145.camel@localhost> All, I'm pleased to announce a major new release of the tar package for handling ".tar" archive files. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/tar This release has a completely new and much improved API. See the hackage page for the API documentation. There are high level "all in one" functions for extracting or creating .tar files. More interestingly, it is easy to make variants by composing a pipeline. For example extracting a ".tar.gz" file is just: > Tar.unpack dir . Tar.read . GZip.decompress =<< BS.readFile tar Or creating a ".tar.bz2" file: > BS.writeFile tar . BZip.compress . Tar.write =<< Tar.pack base dir In addition it provides a full api for inspecting and constructing tar files without having to pack or unpack to local files. The functions are lazy which allows large archives to be processed in constant space. It is based on the tar handling code that has been in use in the cabal-install program for the last year or so. It has been tested on a large number of real world .tar.gz files so compatibility should be pretty good. There is also an 'htar' tool which is essentially a demo program for the tar library. It implements the common subset of the command line interface of the standard tar program, including gzip and bzip compression. Thanks to Christian Maeder for feedback on pre-release versions. Duncan From haskell at list.mightyreason.com Sun Mar 1 17:36:20 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Sun Mar 1 17:25:11 2009 Subject: major speed improvement: regex-tdfa reaches 1.0.0 Message-ID: <49AB0DE4.2020706@list.mightyreason.com> Announcing the version 1.0.0 release of regex-tdfa. I am proud of this release. This is not just a bug fix release. It is a serious improvement in the asymptotic running time. The previous versions allowed bad combinations of pattern and searched text length to scale badly in the length of the text. Previously the worst case for text of length N was O(N^3). The new worst case asymptotic runtime scaled as O(N). There is never any backtracking. And the worst case storage space is independent of N. The package is on hackage at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa The darcs repository is at http://darcs.haskell.org/packages/regex-unstable/regex-tdfa/ All non-overlapping matches are found and returned, along with all captured (parenthesized) subexpressions. The result is precisely what Posix extended regular expressions are supposed to return. To be concrete, consider example text with length of N of (2^n)+2: > longInput = replicate (2^n) 'a' ++ "bc" And define 4 worst-case-scenario patterns. I wrote the code and I know how to kill it: > wcs0 = "a*b" > wcs1 = "a*c" > wcs2 = "(a|aa)*b" > wcs3 = "(a|aa)*c" wcs0 is easy. wcs1 causes the old code to backtrack. wcs2 causes the old code's storage to scale as O(N). wcs3 causes both backtracking and O(N) storage with the old code. The old code's time scales as O(N) for wcs0, O(N^2) for wcs1 and wcs2, and O(N^3) for wcs3. The new code is always O(N). The actual timings for the old code on my G4 laptop for wcs on 2^8 and 2^9 and 2^10 are: Reason:compare-tdfa chrisk$ time ./Test-TDFA-np wcs3 8 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA-np wcs3 8 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(257,1)),(1,(-1,0))]] 263,776,756 bytes allocated in the heap user 0m1.017s sys 0m0.058s Reason:compare-tdfa chrisk$ time ./Test-TDFA-np wcs3 9 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA-np wcs3 9 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(513,1)),(1,(-1,0))]] 1,998,647,452 bytes allocated in the heap user 0m7.083s sys 0m0.289s Reason:compare-tdfa chrisk$ time ./Test-TDFA-np wcs3 10 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA-np wcs3 10 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(1025,1)),(1,(-1,0))]] 15,653,277,200 bytes allocated in the heap user 0m53.350s sys 0m2.056s The doubling of length is causing a nearly eight-fold time increase. The heap allocation is also increasing nearly eight-fold. The new code with the same input pattern and texts gives: Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 8 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 8 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(257,1)),(1,(-1,0))]] 2,135,324 bytes allocated in the heap user 0m0.017s sys 0m0.017s Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 9 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 9 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(513,1)),(1,(-1,0))]] 3,588,656 bytes allocated in the heap user 0m0.024s sys 0m0.017s Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 10 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 10 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(1025,1)),(1,(-1,0))]] 6,345,436 bytes allocated in the heap user 0m0.038s sys 0m0.018s Note that the heap allocation for the 1026 character example above is 2466 times less than the old code. That was too fast to prove the scaling, so take more input: Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 20 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 20 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(1048577,1)),(1,(-1,0))]] 5,708,574,848 bytes allocated in the heap user 0m26.023s sys 0m0.985s Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 wcs3 21 +RTS -sstderr 2>&1 | head -4 ./Test-TDFA2-0.99.19-np2 wcs3 21 +RTS -sstderr Test for [Char] Right [array (0,1) [(0,(2097153,1)),(1,(-1,0))]] 11,416,354,056 bytes allocated in the heap user 0m52.656s sys 0m1.985s The length and time both doubled, as did the heap allocation. And the new code has searched two million characters in the time the old code searched one thousand. How about away from the worst case scenario? On the testing suite the new code is running slightly slower: Reason:compare-tdfa chrisk$ time ./Test-TDFA-np -r 1 100 > /dev/null user 0m4.841s sys 0m3.019s Reason:compare-tdfa chrisk$ time ./Test-TDFA2-0.99.19-np2 -r 1 100 > /dev/null user 0m5.970s sys 0m3.012s So that is an increase of execution time of 14%. This small dip in performance might be reclaimable with more optimization. I think the gain in worst case performance already offsets the slight cost. The code for String is complete. The strict and lazy bytestrings and the (Seq Char) are currently using the String code for matching. This will be improved in a future release. Cheers, Chris The small print: regex-tdfa will still behave badly in space and time if given a pathological pattern, e.g. "(((a|aa){0,100}){0,100}){0,100}". But, I am hopeful than I can improve regex-tdfa to behave well with the patterns like this one. That is my vague goal for a future version 2.0.0 release. The very small print: I have been using ghc-6.10.1, and I think I have carried over cabal switches to make ghc-6.8.3 also work. The library probably can work with ghc-6.6, but the cabal file will need editing first as well as fixes to "Text.Regex.TDFA.NewDFA.copySTU". From lemming at henning-thielemann.de Sun Mar 1 18:21:45 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Mar 1 18:10:31 2009 Subject: Foldable and Traversable vs. FunctorM In-Reply-To: <200902270837.36426.ml@isaac.cedarswampstudios.org> References: <200902270837.36426.ml@isaac.cedarswampstudios.org> Message-ID: On Fri, 27 Feb 2009, Isaac Dupree wrote: > Henning Thielemann wrote: >> ? However 'foldMap' cannot utilize the additional information, namely >> Position and (Maybe e), respectively. In the first case this is sad, in >> the second case I consider this bad, since it is too easy to throw away >> and thus ignore the exception (Maybe e). Some kind of fold is always >> useful on these structures, but 'foldMap' is too limited. > > I'm not sure what you mean, but if you define Traversable in a sensible way, > then you can define Foldable with Data.Traversable.foldMapDefault and get a > sensible definition. This reminds me on using Data.Traversable.foldMapDefault for the definition of foldMap. So thanks for that hint! However, what I like to complain about is, that this foldMap is pretty useless, at least for me. Are there data structures beyond very simple ones (that is, list, tree, graphs of elements without additional information) where you can make any use of it? From thomas.dubuisson at gmail.com Mon Mar 2 04:53:03 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Mon Mar 2 00:41:20 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) Message-ID: <1235987583.11896.21.camel@Mavlo> All, http://hackage.haskell.org/trac/ghc/ticket/3058 Attached is a patch for Text.PrettyPrint.HughesPJ that adds a 'hex' function to print hexidecimal numbers. The only point that I exepect to be contended is it varies slightly from the surrounding functions in that it allows one to control the number of characters printed: > hex 5 31 0001f > hex 2 8 08 > hex 3 7495 d47 While we can argue about the consistancy issues, I almost always want to control the number of digits when dealing with hex. Hence I feel this is a reasonable special case. Secondary Issues: 1) Is there a repo for pretty? I didn't see one on code.haskell.org 2) If I submit a ticket+patch to move Text.PrettyPrint.HughesPJClass (from prettyclass, Augustsson) into Text.PrettyPrint (of the 'pretty' package) would anyone object? It feels mis-placed / I feel things need consolidated. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: prettyPrintHex.patch Type: text/x-patch Size: 991 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20090302/32cff86f/prettyPrintHex-0001.bin From duncan.coutts at worc.ox.ac.uk Mon Mar 2 07:55:29 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 2 07:44:19 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) In-Reply-To: <1235987583.11896.21.camel@Mavlo> References: <1235987583.11896.21.camel@Mavlo> Message-ID: <1235998529.7915.185.camel@localhost> On Mon, 2009-03-02 at 01:53 -0800, Thomas DuBuisson wrote: > All, > > http://hackage.haskell.org/trac/ghc/ticket/3058 > > Attached is a patch for Text.PrettyPrint.HughesPJ that adds a 'hex' > function to print hexidecimal numbers. > The only point that I exepect to be contended is it varies slightly from > the surrounding functions in that it allows one to control the number of > characters printed: There are a number of other functions from the Numeric module we should also consider. These are all the ones that return ShowS, the equivalent of the Doc type. showEFloat :: (RealFloat a) => Maybe Int -> a -> ShowS showFFloat :: (RealFloat a) => Maybe Int -> a -> ShowS showGFloat :: (RealFloat a) => Maybe Int -> a -> ShowS showHex :: (Integral a) => a -> ShowS showInt :: (Integral a) => a -> ShowS showIntAtBase :: (Integral a) => a -> (Int -> Char) -> a -> ShowS showOct :: (Integral a) => a -> ShowS showFloat :: (RealFloat a) => a -> ShowS showSigned :: (Real a) => (a -> ShowS) -> Int -> a -> ShowS > While we can argue about the consistancy issues, I almost always want to > control the number of digits when dealing with hex. Hence I feel this > is a reasonable special case. For some reason I thought I remembered that the Numeric show functions also allowed fixed width 0-padded display but it appears they do not, except by manually rendering and adding leading 0's. Note the show float functions take an optional precision. Perhaps that's a sensible approach for optional fixed width octal and hexadecimal display. > Secondary Issues: > 1) Is there a repo for pretty? I didn't see one on code.haskell.org It's on darcs.haskell.org along with ghc and the other core libs. > 2) If I submit a ticket+patch to move Text.PrettyPrint.HughesPJClass > (from prettyclass, Augustsson) into Text.PrettyPrint (of the 'pretty' > package) would anyone object? It feels mis-placed / I feel things need > consolidated. That's a much bigger change. I suggest a separate ticket and discussion for that. There's a rather large design space and range of use cases. Duncan From jgoerzen at complete.org Mon Mar 2 09:20:31 2009 From: jgoerzen at complete.org (John Goerzen) Date: Mon Mar 2 09:09:15 2009 Subject: [Haskell-cafe] ANNOUNCE: tar 0.3.0.0 In-Reply-To: <1235931855.7915.145.camel@localhost> References: <1235931855.7915.145.camel@localhost> Message-ID: <49ABEB2F.40807@complete.org> Duncan Coutts wrote: > All, > > I'm pleased to announce a major new release of the tar package for > handling ".tar" archive files. Very nice! I'm curious -- what specific variants of the tar format can it read and write? * PAX? * GNU tar sparse files? * POSIX ustar * various pre-posix archives? * Solaris tar? * Binary and text numbers in numeric fields? -- John > From ml at isaac.cedarswampstudios.org Mon Mar 2 09:39:08 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Mon Mar 2 09:28:04 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) In-Reply-To: <1235987583.11896.21.camel@Mavlo> References: <1235987583.11896.21.camel@Mavlo> Message-ID: <200903020939.08796.ml@isaac.cedarswampstudios.org> Thomas DuBuisson wrote: > The only point that I exepect to be contended is it varies slightly from > the surrounding functions in that it allows one to control the number of > characters printed: > > hex 5 31 > > 0001f > > > hex 2 8 > > 08 > > > hex 3 7495 > > d47 what about when it doesn't fit in the given number of characters? Show us the answer to: hex 1 31 -Isaac From duncan.coutts at worc.ox.ac.uk Mon Mar 2 11:15:02 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 2 11:03:59 2009 Subject: [Haskell-cafe] ANNOUNCE: tar 0.3.0.0 In-Reply-To: <49ABEB2F.40807@complete.org> References: <1235931855.7915.145.camel@localhost> <49ABEB2F.40807@complete.org> Message-ID: <1236010502.7915.240.camel@localhost> On Mon, 2009-03-02 at 08:20 -0600, John Goerzen wrote: > Duncan Coutts wrote: > > All, > > > > I'm pleased to announce a major new release of the tar package for > > handling ".tar" archive files. > > Very nice! > > I'm curious -- what specific variants of the tar format can it read and > write? It can read and write basic Unix V7 format, POSIX ustar and gnu formats. > * PAX? PAX is a compatible extension of Posix ustar. It just standardises some extra tar entry types ('x' and 'g'). These archives can be read and written but there is no special support for them. You would match on entryContents = OtherEntryType 'x' paxHeader _ -> and then parse the paxHeader which is a utf-8 file containing name/value pairs. > * GNU tar sparse files? No support. They'll get matched as OtherEntryType 'S'. However unlike PAX, GNU sparse format puts the sparse info directly in the tar header and that is not parsed and the lib does not provide direct access to the data for you to be able to do it yourself. > * POSIX ustar This is the standard format the library generates. > * various pre-posix archives? Yes, at least the basic data from the V7 format. Data in the top half of the header is ignored. > * Solaris tar? In so far as it is standard posix ustar yes. Again it uses some extra entry types like 'X' for extended info. These are preserved and you can access them but there is no special support for parsing the body of these entry types. > * Binary and text numbers in numeric fields? Only text at the moment. Binary ones are currently recognised and rejected with an error saying binary ones are not supported. Adding support would not be terribly hard. Patches gladly accepted. I've only found one tarball that uses it (generated by the perl Archive::Tar lib). My main use case so far for the library is for software distribution with .tar.gz files, where portability is important. So I've tested with all the .tar.gz and .tar.bz files I could get my hands on (quite a few on a gentoo system). I've not looked at or tested use cases like backups where important things include large file support, preserving permissions, sparse files etc. I've tried the star program's tar torture tests, but this should be automated into a testsuite. I've done no performance tuning except to check that it works in constant space. On a cached 97m tarball (glibc) the timings on my machine are: GNU tar uncompressed: $ time tar -tf glibc-2.6.1.tar > /dev/null real 0m0.126s user 0m0.052s sys 0m0.068s Haskell tar uncompressed: $ time htar -tf glibc-2.6.1.tar > /dev/null real 0m0.617s user 0m0.572s sys 0m0.040s GNU tar compressed: $ time tar -tzf glibc-2.6.1.tar.gz > /dev/null real 0m0.938s user 0m0.880s sys 0m0.056s Haskell tar compressed: $ time htar -tzf glibc-2.6.1.tar.gz > /dev/null real 0m1.207s user 0m1.188s sys 0m0.016s So it's slower but still perfectly good. Duncan From thomas.dubuisson at gmail.com Mon Mar 2 14:18:01 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Mon Mar 2 14:06:42 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) In-Reply-To: <200903020939.08796.ml@isaac.cedarswampstudios.org> References: <1235987583.11896.21.camel@Mavlo> <200903020939.08796.ml@isaac.cedarswampstudios.org> Message-ID: <4c44d90b0903021118p5e9c5b5dv781abda6e5cf9b9d@mail.gmail.com> > what about when it doesn't fit in the given number of characters? Show us the > answer to: > hex 1 31 That was my third example. As you can see from the source it will show the least significant bits in this case. > hex 1 31 f Thomas From thomas.dubuisson at gmail.com Mon Mar 2 20:16:19 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Mon Mar 2 16:04:31 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) In-Reply-To: <1235998529.7915.185.camel@localhost> References: <1235987583.11896.21.camel@Mavlo> <1235998529.7915.185.camel@localhost> Message-ID: <1236042979.11896.25.camel@Mavlo> On Mon, 2009-03-02 at 12:55 +0000, Duncan Coutts wrote: > On Mon, 2009-03-02 at 01:53 -0800, Thomas DuBuisson wrote: > > All, > > > > http://hackage.haskell.org/trac/ghc/ticket/3058 > There are a number of other functions from the Numeric module we should > also consider. These are all the ones that return ShowS, the equivalent > of the Doc type. I've added another patch to that ticket for consideration. It has hex, oct, intAtBase (plus padded variants). Also included are {e,f,g}float without any padding options. Padding floats could be touchy - perhaps it should be a separate patch by someone who would use such a feature and know what they want. Thoughts? Thomas From duncan.coutts at worc.ox.ac.uk Mon Mar 2 16:30:47 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 2 16:19:39 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) In-Reply-To: <1236042979.11896.25.camel@Mavlo> References: <1235987583.11896.21.camel@Mavlo> <1235998529.7915.185.camel@localhost> <1236042979.11896.25.camel@Mavlo> Message-ID: <1236029447.22402.1.camel@localhost> On Mon, 2009-03-02 at 17:16 -0800, Thomas DuBuisson wrote: > On Mon, 2009-03-02 at 12:55 +0000, Duncan Coutts wrote: > > On Mon, 2009-03-02 at 01:53 -0800, Thomas DuBuisson wrote: > > > All, > > > > > > http://hackage.haskell.org/trac/ghc/ticket/3058 > > There are a number of other functions from the Numeric module we should > > also consider. These are all the ones that return ShowS, the equivalent > > of the Doc type. > > I've added another patch to that ticket for consideration. It has hex, > oct, intAtBase (plus padded variants). Also included are {e,f,g}float > without any padding options. > > Padding floats could be touchy - perhaps it should be a separate patch > by someone who would use such a feature and know what they want. > > Thoughts? Presumably it would be uncontroversial for the float ones to behave the same as the ones from the existing Numeric module. Duncan From thomas.dubuisson at gmail.com Mon Mar 2 21:01:46 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Mon Mar 2 16:49:57 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) In-Reply-To: <1236029447.22402.1.camel@localhost> References: <1235987583.11896.21.camel@Mavlo> <1235998529.7915.185.camel@localhost> <1236042979.11896.25.camel@Mavlo> <1236029447.22402.1.camel@localhost> Message-ID: <1236045706.11896.29.camel@Mavlo> > > Padding floats could be touchy - perhaps it should be a separate patch > > by someone who would use such a feature and know what they want. > > > > Thoughts? > > Presumably it would be uncontroversial for the float ones to behave the > same as the ones from the existing Numeric module. Done, the new prettyNumeric.patch is with the ticket including hex, oct, ffloat, efloat, gfloat, signed, intByBase. Also, padded versions of hex, oct, intByBase. Thomas From duncan.coutts at worc.ox.ac.uk Mon Mar 2 17:02:58 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 2 16:52:27 2009 Subject: randomIO causing stack overflow ? In-Reply-To: References: Message-ID: <1236031378.22402.12.camel@localhost> On Sun, 2009-03-01 at 00:34 +0100, timtoorop@quicknet.nl wrote: > Hi, > I was just messing with randomIO for no particular reason, and it suddenly caused a stack overflow which would only go away after restarting ghci. > > Here's what I see in ghci 6.8.2 > http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=1642 > > mmorrow posted the same using ghci 6.10.1 > which gave the same stack overflow > > Anyone got any idea what causes this funny behavior? class Random a where ... snip ... randomIO :: IO a randomIO = getStdRandom random getStdRandom :: (StdGen -> (a,StdGen)) -> IO a getStdRandom f = atomicModifyIORef theStdGen (swap . f) where swap (v,g) = (g,v) So what happens when we do _ <- randomIO _ <- randomIO _ <- randomIO is that we're calling getStdRandom random many times and not inspecting the random numbers generated. That means the IORef containing the global rnd state (theStdGen) is now an unevaluated thunk that looks rather like: snd . random . snd . random . snd . random $ mkStdRNG 0 Now, if instead of doing it 3 times like above, you do it 100,000 times then you get a very big thunk indeed. Evaluating this thunk overflows the stack. Calling randomIO again and evaluating the result does not help. The internal IORef still contains the stack-overflowing thunk. Once in this situation we're stuffed. We've thrown away all the values that we could force that would let us evaluate the thunk when it was still small enough to do so. This problem could probably be fixed by adjusting the definition of getStdRandom like: getStdRandom :: (StdGen -> (a,StdGen)) -> IO a getStdRandom f = atomicModifyIORef theStdGen $! (swap . f) where swap (v,g) = g `seq` (g,v) Though even that may not do it. The StdGen data and stdNext functions may not be strict enough. data StdGen = StdGen Int32 Int32 It's not strict in the Int32 fields. I doubt that it needs to be so lazy. Duncan From rturk at science.uva.nl Mon Mar 2 17:16:58 2009 From: rturk at science.uva.nl (Remi Turk) Date: Mon Mar 2 17:05:40 2009 Subject: randomIO causing stack overflow ? In-Reply-To: <1236031378.22402.12.camel@localhost> References: <1236031378.22402.12.camel@localhost> Message-ID: <20090302221657.GA5802@frogstar.lan> On Mon, Mar 02, 2009 at 10:02:58PM +0000, Duncan Coutts wrote: > This problem could probably be fixed by adjusting the definition of > getStdRandom like: > > getStdRandom :: (StdGen -> (a,StdGen)) -> IO a > getStdRandom f = atomicModifyIORef theStdGen $! (swap . f) > where swap (v,g) = g `seq` (g,v) > > Though even that may not do it. The StdGen data and stdNext functions > may not be strict enough. > > data StdGen = StdGen Int32 Int32 > > It's not strict in the Int32 fields. I doubt that it needs to be so > lazy. If I was right a few years ago, making getStdRandom more strict is indeed enough, although it does change the behaviour of x <- randomRIO undefined which probably noone cares about anyway. There is also already a ticket for this and another problem: http://hackage.haskell.org/trac/ghc/ticket/427 Groeten, Remi From jnf at arcor.de Tue Mar 3 01:38:38 2009 From: jnf at arcor.de (=?ISO-8859-1?Q?J=FCrgen?= Nicklisch-Franken) Date: Tue Mar 3 01:27:21 2009 Subject: Failed to install leksah. (ghc-6.10.1 requires two versions of process) In-Reply-To: <87d4czi3zi.fsf@debian.domain> References: <87d4czi3zi.fsf@debian.domain> Message-ID: <1236062318.18282.14.camel@jutaro-laptop> Hallo Andy, I'm sorry but this seems to be a cabal problem to me and I'm not shure how to fix this. In leksah.cabal the prerequisite is process >=1.0.1.0. Why and how ghc can require two different versions of the process library, well I don't know. I forward your question to the ghc library and leksah mailing list and hope we get a solution. J?rgen Am Dienstag, den 03.03.2009, 13:12 +0800 schrieb Andy Stewart: > Dear developers, > > I have install ghc-6.10.1 and gtk2hs-0.10 in Debian. > When i use cabal (1.6.0.2) install leksah, i got below error: > > Resolving dependencies... > cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.0 however > process-1.0.1.0 was excluded because ghc-6.10.1 requires process ==1.0.1.1 > > How to fix this? > > Thanks! > > -- Andy From magnus at therning.org Tue Mar 3 03:23:37 2009 From: magnus at therning.org (Magnus Therning) Date: Tue Mar 3 03:12:18 2009 Subject: Re-opening #2474 Message-ID: I've again bumped into the issue I raised against old-locale: http://hackage.haskell.org/trac/ghc/ticket/2474 with a library submission in http://hackage.haskell.org/trac/ghc/ticket/2626 This resulted in no discussion at all on the list ( http://www.haskell.org/pipermail/libraries/2008-September/010709.html ) so would someone with privilege push the change into old-locale? I now I've not been following up properly on this, but hopefully that won't be held against me :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus identi.ca|twitter: magthe From dgorin at dc.uba.ar Tue Mar 3 06:00:23 2009 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Tue Mar 3 05:49:09 2009 Subject: Failed to install leksah. (ghc-6.10.1 requires two versions of process) In-Reply-To: <1236062318.18282.14.camel@jutaro-laptop> References: <87d4czi3zi.fsf@debian.domain> <1236062318.18282.14.camel@jutaro-laptop> Message-ID: <37494FB8-811D-40E6-A50D-49EFFF63C29D@dc.uba.ar> check http://haskell.org/pipermail/haskell-cafe/2009-January/054523.html On Mar 3, 2009, at 4:38 AM, J?rgen Nicklisch-Franken wrote: > Hallo Andy, > I'm sorry but this seems to be a cabal problem to me and I'm not shure > how to fix this. In leksah.cabal the prerequisite is process > >=1.0.1.0. > Why and how ghc can require two different versions of the process > library, well I don't know. I forward your question to the ghc library > and leksah mailing list and hope we get a solution. > > J?rgen > > > Am Dienstag, den 03.03.2009, 13:12 +0800 schrieb Andy Stewart: >> Dear developers, >> >> I have install ghc-6.10.1 and gtk2hs-0.10 in Debian. >> When i use cabal (1.6.0.2) install leksah, i got below error: >> >> Resolving dependencies... >> cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.0 >> however >> process-1.0.1.0 was excluded because ghc-6.10.1 requires process >> ==1.0.1.1 >> >> How to fix this? >> >> Thanks! >> >> -- Andy > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090303/6730c8a5/attachment.htm From duncan.coutts at worc.ox.ac.uk Tue Mar 3 06:10:29 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Mar 3 05:59:17 2009 Subject: Failed to install leksah. (ghc-6.10.1 requires two versions of process) In-Reply-To: <1236062318.18282.14.camel@jutaro-laptop> References: <87d4czi3zi.fsf@debian.domain> <1236062318.18282.14.camel@jutaro-laptop> Message-ID: <1236078629.22402.75.camel@localhost> On Tue, 2009-03-03 at 07:38 +0100, J?rgen Nicklisch-Franken wrote: > Hallo Andy, > I'm sorry but this seems to be a cabal problem to me and I'm not shure > how to fix this. In leksah.cabal the prerequisite is process >=1.0.1.0. > Why and how ghc can require two different versions of the process > library, well I don't know. I forward your question to the ghc library > and leksah mailing list and hope we get a solution. We really need to make a Cabal FAQ http://haskell.org/pipermail/haskell-cafe/2009-January/054523.html Duncan From prb at mult.ifario.us Tue Mar 3 18:53:09 2009 From: prb at mult.ifario.us (Paul Brown) Date: Tue Mar 3 18:41:50 2009 Subject: memory issues with cabal Message-ID: <2E6E0501-C391-4FAE-80BD-65B6327A3D93@mult.ifario.us> Hi, All -- I'm having some issues getting cabal-install to upgrade itself to the current version (Cabal 1.6.0.2, cabal-install 0.6.2): > $ cabal install Cabal cabal-install > Resolving dependencies... > cabal: memory allocation failed (requested 2097152 bytes) I've tried various combinations of ghc options and RTS options passed in without success. The machine has plenty of horsepower for the task (8 cores, 20GB of RAM; Mac OS X 10.5.6, ghc 6.10.0) if I could convince cabal to use it... Any magic flags or tricks for this one? Thanks in advance. Paul Brown prb@mult.ifario.us http://mult.ifario.us http://www.linkedin.com/in/paulrbrown From duncan.coutts at worc.ox.ac.uk Wed Mar 4 07:33:09 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 4 07:21:54 2009 Subject: memory issues with cabal In-Reply-To: <2E6E0501-C391-4FAE-80BD-65B6327A3D93@mult.ifario.us> References: <2E6E0501-C391-4FAE-80BD-65B6327A3D93@mult.ifario.us> Message-ID: <1236169989.22402.106.camel@localhost> On Tue, 2009-03-03 at 15:53 -0800, Paul Brown wrote: > Hi, All -- > > I'm having some issues getting cabal-install to upgrade itself to the > current version (Cabal 1.6.0.2, cabal-install 0.6.2): > > > $ cabal install Cabal cabal-install > > Resolving dependencies... > > cabal: memory allocation failed (requested 2097152 bytes) Are you by any chance using cabal-install version 0.5.x with ghc-6.10? That version of cabal-install goes into an infinite loop when resolving dependencies because it cannot cope with the fact that base 3 depends on base 4. If you've still got ghc-6.8 installed then you could: $ cabal install Cabal cabal-install -w ghc-6.8.3 otherwise you'll need to bootstrap cabal-install freshly with ghc-6.10. Duncan From prb at mult.ifario.us Wed Mar 4 11:30:03 2009 From: prb at mult.ifario.us (Paul Brown) Date: Wed Mar 4 11:18:43 2009 Subject: memory issues with cabal In-Reply-To: <1236169989.22402.106.camel@localhost> References: <2E6E0501-C391-4FAE-80BD-65B6327A3D93@mult.ifario.us> <1236169989.22402.106.camel@localhost> Message-ID: <96B398F5-790D-40B9-BAB1-375663F8795B@mult.ifario.us> On Mar 4, 2009, at 4:33 AM, Duncan Coutts wrote: > If you've still got ghc-6.8 installed then you could: > $ cabal install Cabal cabal-install -w ghc-6.8.3 > otherwise you'll need to bootstrap cabal-install freshly with > ghc-6.10. That was it! Works like a charm now, Duncan. Cheers. Paul Brown prb@mult.ifario.us http://mult.ifario.us http://www.linkedin.com/in/paulrbrown From claus.reinke at talk21.com Wed Mar 4 17:55:36 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 4 17:44:43 2009 Subject: containers: to be or not to be (strict, in this case)? Message-ID: [addressing libraries@ as the maintainer of containers] summary: could we please have equal support for all container operations, parameterised by element strictness? We are now starting to see issues with container strictness almost as often as we used to see the foldl/foldl' issue (the most recent example on cafe even used foldl' to accumulate an IntMap, unfortunately running into the non-strict nature of unionWith). As with foldl' itself, this is only partially a learning from experience issue: foldl' wasn't always available, and containers is rather inconsistent about supporting (element-)strict operations (Data.Map offers insertWith', Data.IntMap doesn't, neither offers strict unionWith; Data.Set is completely ambivalent about element strictness, depending on whether or not comparison is used). For the case of Maps, a partial workaround is known, namely to tie the availability of keys to evaluation of values. But this only works if key and value are supplied from the outside - which is not the case for the *With* family of functions (the supplied operation is applied to the old value, from within the Map, and the new value, from outside - there is no leverage to apply strictness), nor for map. Another workaround is to define your own strict insertWith', then to avoid the non-strict parts of the API: insertWith' op (k,v) m = maybe (IM.insert k v m) (\old->((IM.insert k) $! (v `op` old)) m) (IM.lookup k m) Apart from costing an extra lookup, that cannot be the intended way to use the API. If possible, I'd like to see both element-strict and element-non-strict containers supported, with otherwise the same APIs, and without a separate strict-containers package. The obvious disadvantage of code duplication (Data.Map has two definitions of insertWith) could perhaps be avoided, by parameterising the code over element strictness, as demonstrated here for Data.IntMap.insertWith: insertWithKey :: (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWithKey = insertWithKeyS ($) insertWithKey' :: (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWithKey' = insertWithKeyS ($!) type Strictness c a = (a -> c a) -> (a -> c a) -- constructor transformers insertWithKeyS :: Strictness IntMap a -> (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWithKeyS ($) f k x t = case t of Bin p m l r | nomatch k p m -> join k (Tip k $ x) p t | zero k m -> Bin p m (insertWithKeyS ($) f k x l) r | otherwise -> Bin p m l (insertWithKeyS ($) f k x r) Tip ky y | k==ky -> Tip k $ (f k x y) | otherwise -> join k (Tip k $ x) ky t Nil -> Tip k $ x The idea being to abstract over every application of the container constructors to the element type, then to supply either strict or non-strict application. Ultimately, one might prefer a type-constructor-based abstraction instead, to gain additional performance, but this should be at least as good as the current situation (perhaps with an INLINE on the parameterised versions), without the duplication. Btw, this variant is slightly stricter than Data.Map.insertWith', applying the strictness not only to the function passed in, but to all IntMap construction from the element type (seemed more consistent that way..). Claus From john at repetae.net Wed Mar 4 18:06:03 2009 From: john at repetae.net (John Meacham) Date: Wed Mar 4 17:54:38 2009 Subject: containers: to be or not to be (strict, in this case)? In-Reply-To: References: Message-ID: <20090304230602.GD2631@sliver.repetae.net> One can always turn a strict data structure into a non-strict one by introducing lazyness explicitly like data Box a = Box a deriving(Eq,Ord,..) then having Set (Box Int) for a set of lazy ints. It might make sense to make the strict implementation the default and emulate the lazy one with boxes like above. It would give us both with very little code duplication. John -- John Meacham - ?repetae.net?john? From derek.a.elkins at gmail.com Wed Mar 4 18:12:05 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Mar 4 18:00:45 2009 Subject: containers: to be or not to be (strict, in this case)? In-Reply-To: References: Message-ID: <1236208325.18175.1.camel@derek-laptop> On Wed, 2009-03-04 at 22:55 +0000, Claus Reinke wrote: > [addressing libraries@ as the maintainer of containers] > > summary: could we please have equal support for all container > operations, parameterised by element strictness? > > We are now starting to see issues with container strictness almost > as often as we used to see the foldl/foldl' issue (the most recent > example on cafe even used foldl' to accumulate an IntMap, > unfortunately running into the non-strict nature of unionWith). > > As with foldl' itself, this is only partially a learning from > experience issue: foldl' wasn't always available, and containers > is rather inconsistent about supporting (element-)strict operations > (Data.Map offers insertWith', Data.IntMap doesn't, neither offers > strict unionWith; Data.Set is completely ambivalent about element > strictness, depending on whether or not comparison is used). > > For the case of Maps, a partial workaround is known, namely > to tie the availability of keys to evaluation of values. But this only > works if key and value are supplied from the outside - which is > not the case for the *With* family of functions (the supplied > operation is applied to the old value, from within the Map, and > the new value, from outside - there is no leverage to apply > strictness), nor for map. > > Another workaround is to define your own strict insertWith', > then to avoid the non-strict parts of the API: > > insertWith' op (k,v) m = > maybe (IM.insert k v m) > (\old->((IM.insert k) $! (v `op` old)) m) > (IM.lookup k m) > > Apart from costing an extra lookup, that cannot be the intended > way to use the API. > > If possible, I'd like to see both element-strict and element-non-strict > containers supported, with otherwise the same APIs, and without a > separate strict-containers package. The obvious disadvantage of > code duplication (Data.Map has two definitions of insertWith) could > perhaps be avoided, by parameterising the code over element > strictness, as demonstrated here for Data.IntMap.insertWith: > > insertWithKey :: (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a > insertWithKey = insertWithKeyS ($) > > insertWithKey' :: (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a > insertWithKey' = insertWithKeyS ($!) > > type Strictness c a = (a -> c a) -> (a -> c a) -- constructor transformers > > insertWithKeyS :: Strictness IntMap a > -> (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a > insertWithKeyS ($) f k x t > = case t of > Bin p m l r > | nomatch k p m -> join k (Tip k $ x) p t > | zero k m -> Bin p m (insertWithKeyS ($) f k x l) r > | otherwise -> Bin p m l (insertWithKeyS ($) f k x r) > Tip ky y > | k==ky -> Tip k $ (f k x y) > | otherwise -> join k (Tip k $ x) ky t > Nil -> Tip k $ x > > The idea being to abstract over every application of the container > constructors to the element type, then to supply either strict or non-strict > application. Ultimately, one might prefer a type-constructor-based > abstraction instead, to gain additional performance, but this should > be at least as good as the current situation (perhaps with an INLINE > on the parameterised versions), without the duplication. > > Btw, this variant is slightly stricter than Data.Map.insertWith', > applying the strictness not only to the function passed in, but > to all IntMap construction from the element type (seemed more > consistent that way..). data MyContainerType elem = ... !elem ... data Box a = Box a type MyLazyContainerType elem = MyContainerType (Box elem) From ml at isaac.cedarswampstudios.org Wed Mar 4 19:45:18 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Wed Mar 4 19:34:03 2009 Subject: containers: to be or not to be (strict, in this case)? In-Reply-To: References: Message-ID: <200903041945.19154.ml@isaac.cedarswampstudios.org> Claus Reinke wrote: > The idea being to abstract over every application of the container > constructors to the element type, then to supply either strict or > non-strict application. Ultimately, one might prefer a > type-constructor-based abstraction instead, to gain additional performance, > but this should be at least as good as the current situation (perhaps with > an INLINE on the parameterised versions), without the duplication. the "Box" approach is attractive but performance-unoptimal... we can try that type-constructor stuff. Is it like: data IntMap_ strictness a = ... --(not including "strictness" values) data Strict data Lazy class Strictness s where ... well, it turns out to have similar performance issues to passing around ($) or ($!), except they'd be resolved in the compiler by SPECIALIZE rather than INLINE stuff (I guess). Anyway, the compiler basically can't optimize away Box at all. And changing the strictness of a Box-based IntMap, would be linear time rather than constant (zero) time for a purely newtype-based solution (if indeed they need to be separate types, rather than just different modules with different implementations of e.g. insertWith for the same data-type). -Isaac From john at repetae.net Thu Mar 5 04:23:46 2009 From: john at repetae.net (John Meacham) Date: Thu Mar 5 04:12:21 2009 Subject: containers: to be or not to be (strict, in this case)? In-Reply-To: <200903041945.19154.ml@isaac.cedarswampstudios.org> References: <200903041945.19154.ml@isaac.cedarswampstudios.org> Message-ID: <20090305092346.GA22893@sliver.repetae.net> On Wed, Mar 04, 2009 at 07:45:18PM -0500, Isaac Dupree wrote: > Claus Reinke wrote: > > The idea being to abstract over every application of the container > > constructors to the element type, then to supply either strict or > > non-strict application. Ultimately, one might prefer a > > type-constructor-based abstraction instead, to gain additional performance, > > but this should be at least as good as the current situation (perhaps with > > an INLINE on the parameterised versions), without the duplication. > > the "Box" approach is attractive but performance-unoptimal... > > we can try that type-constructor stuff. Is it like: > > data IntMap_ strictness a = ... --(not including "strictness" values) > data Strict > data Lazy > class Strictness s where ... > > well, it turns out to have similar performance issues to passing around ($) or > ($!), except they'd be resolved in the compiler by SPECIALIZE rather than > INLINE stuff (I guess). > > Anyway, the compiler basically can't optimize away Box at all. > > And changing the strictness of a Box-based IntMap, would be linear time rather > than constant (zero) time for a purely newtype-based solution (if indeed they > need to be separate types, rather than just different modules with different > implementations of e.g. insertWith for the same data-type). Hmm.. would it make sense to want to use both lazy and strict operations on the same data type? It seems like it could be useful which argues against making them distinct types. Actually, how many of the standard operations do we need strict versions of? most are strictness agnostic to begin with, it seems that just providing insert' alternatives for those ones that matter would be enough and leaving the implementation of the strict versions to the internals of the library. parameterizing by the application function and pervasive inlining like you said seems like a reasonable way to go about it. for Data.Set it seems like we would only need alternate versions of not more than a half dozen or so functions. Since only a few actually add elements to the set and the other operations are strictness preserving (as in, a union of strict sets is a strict set). John -- John Meacham - ?repetae.net?john? From allbery at ece.cmu.edu Fri Mar 6 13:47:49 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Mar 6 13:36:33 2009 Subject: [Haskell] string type class In-Reply-To: <200903061713.43573.g9ks157k@acme.softbase.org> References: <200903061233.36400.matthew.pocock@ncl.ac.uk> <200903061713.43573.g9ks157k@acme.softbase.org> Message-ID: <3F863341-3BE4-4BBF-8DD1-81A64FADE867@ece.cmu.edu> On 2009 Mar 6, at 11:13, Wolfgang Jeltsch wrote: > Am Freitag, 6. M?rz 2009 13:33 schrieb Matthew Pocock: >> It seems every time I look at hackage there is yet another stringy >> datatype. For lots of apps, the particular stringy datatype you use >> matters >> for performance but not algorithmic reasons. Perhaps this is a good >> time >> for someone to propose a stringy class? > > There is already the class IsString which was introduced for > overloaded string > literals. > > However, the name is terrible. No other Haskell class I know of has > an ?Is? at > its beginning. Classes don?t name properties (IsNum, IsMonoid, Has?). But their proper names were available. "String" is already taken for a concrete type, which complicates things; "IsString" was the simplest answer (and possibly avoided bikeshedding by being the answer nobody liked :) > Maybe you can also try to convince the masters of the IsString class > to change > the class name. My previous attempts through mailing list e-mails > seemed to > have no effect. :-( I think the problem here is you need to get buy-in from everyone involved, which includes libraries@ (String), ghc (IsString is recognized in order to enable string overloading), ByteString, and potentially anyone who uses any of the above. That said, if you want to officially propose it you need to read up on how to properly propose such changes to libraries@haskell.org. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20090306/51111667/PGP.bin From felipe.lessa at gmail.com Sat Mar 7 08:22:04 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sat Mar 7 08:10:30 2009 Subject: UArray for newtypes (LogFloat) Message-ID: Hello, So, I would like to make an UArray of LogFloat. They are a newtype of Double, but the type system can't see trough newtypes. So I wonder if it is acceptable to exploit the fact that the internal representation of newtypes don't change to use some safe unsafeCoerces and create an instance of IArray for UArray of LogFloat. I've looked at the core of the code below and it seems sane, and -Wall only warn about the orphan instance, so I would also like to ask to include this instance in logfloat package itself (I've sent a copy of this message to LogFloat's maintainer). {-# LANGUAGE MultiParamTypeClasses #-} import Data.Array.Base import Data.Array.Unboxed (UArray) import Data.Number.LogFloat import Unsafe.Coerce -- For testing below import Data.Array.Unboxed as U import Test.QuickCheck {-# INLINE from #-} from :: UArray a LogFloat -> UArray a Double from = unsafeCoerce {-# INLINE to #-} to :: UArray a Double -> UArray a LogFloat to = unsafeCoerce {-# INLINE func #-} func :: (LogFloat -> a -> LogFloat) -> (Double -> a -> Double) func = unsafeCoerce instance IArray UArray LogFloat where {-# INLINE bounds #-} bounds = bounds . from {-# INLINE numElements #-} numElements = numElements . from {-# INLINE unsafeArray #-} unsafeArray lu = to . unsafeArray lu . unsafeCoerce {-# INLINE unsafeAt #-} unsafeAt = unsafeCoerce . unsafeAt . from {-# INLINE unsafeReplace #-} unsafeReplace arr = to . unsafeReplace (from arr) . unsafeCoerce {-# INLINE unsafeAccum #-} unsafeAccum f arr = to . unsafeAccum (func f) (from arr) {-# INLINE unsafeAccumArray #-} unsafeAccumArray f initialValue lu = to . unsafeAccumArray (func f) (unsafeCoerce initialValue) lu test1 :: [Double] -> Bool test1 elms' = elms == U.elems arr where arr :: UArray Int LogFloat arr = U.listArray (1, length elms) elms elms = map (logFloat . abs) elms' test2 :: [Double] -> Bool test2 elms' = product elms == arr U.! 1 where arr :: UArray Int LogFloat arr = U.accumArray (*) 1 (1, 1) [(1,x) | x <- elms] elms = map (logFloat . abs) elms' main :: IO () main = quickCheck test1 >> quickCheck test2 -- Felipe. From felipe.lessa at gmail.com Sat Mar 7 20:06:58 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sat Mar 7 19:55:23 2009 Subject: UArray for newtypes (LogFloat) In-Reply-To: <49B30CE8.4020306@freegeek.org> References: <49B30CE8.4020306@freegeek.org> Message-ID: On Sat, Mar 7, 2009 at 9:10 PM, wren ng thornton wrote: > You can replace many of the coercions by using logToLogFloat and > logFromLogFloat. Those give an isomorphism without doing log/exp, which is > specialized for Double to be id (except logToLogFloat also checks isNaN). I used unsafeCoerce for saving the check cost as we know it is valid. > Though, as a general matter it seems that adding "deriving (IArray UArray)" > to the newtype declaration is sufficient. Doesn't even require > GeneralizedNewtypeDeriving. I'll push out a new release soon. Whoa, that's great news for me, didn't know it was possible. And thanks for acting so promptly. :) -- Felipe. From haskell at list.mightyreason.com Mon Mar 9 16:54:06 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Mon Mar 9 16:42:29 2009 Subject: ANN: Future 1.1.0 concurrency library Message-ID: <49B581EE.7050706@list.mightyreason.com> Hello, As a side effect of the discussion of the new C++ future/promise features at http://lambda-the-ultimate.org/node/3221 I have implemented a Haskell package called "future" at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/future This ought to do what C++ standard futures/promises do, plus a bit more. The main operation is > forkPromise :: IO a -> IO (Promise a) This sets the "IO a" operation running in a fresh thread. The eventual result can be accessed in many ways (non-blocking, blocking, blocking with timeout). > let one :: Int; one = 1 > p <- forkPromise (return (one+one)) > x <- get > y <- wait x is an Int with value 2. y is an (Either SomeException Int) with value (Right 2). The useful thing about futures, as opposed to various IVar packages, is handling the case where the forked operation ends with an exception. The exception becomes the return value of the promise. The "get" operation rethrows it, the "wait" operation returns it as (Left ...). There is also an "abort" command to kill a promise. The dead promise may then have an exceptions as its value. The "plus a bit more" than C++ is the nonblocking "addTodo" feature. This takes a continuation function from the "Either SomeException a" to an IO operation. These continuation functions get queued and they are run immediately after the the forked operation completes. Once completed any new "addTodo" continuations run immediately. These continuations allow you to race a list of action and take the first one done, or to collect the answers as they complete into a Chan. Both of those options are demonstrated in Future.hs as racePromises and forkPromises. It should be safe to use "unsafePerformIO . get" or "unsafePeformIO . wait" to get lazy access to the result, which is itself immutable once set. Cheers, Chris From bulat.ziganshin at gmail.com Mon Mar 9 17:04:55 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Mar 9 16:53:31 2009 Subject: ANN: Future 1.1.0 concurrency library In-Reply-To: <49B581EE.7050706@list.mightyreason.com> References: <49B581EE.7050706@list.mightyreason.com> Message-ID: <1539740870.20090310000455@gmail.com> Hello ChrisK, Monday, March 9, 2009, 11:54:06 PM, you wrote: >> p <- forkPromise (return (one+one)) >> x <- get >> y <- wait probably x <- get p y <- wait p -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Mon Mar 9 17:07:32 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Mar 9 16:56:12 2009 Subject: UArray for newtypes (LogFloat) In-Reply-To: References: Message-ID: <1675300215.20090310000732@gmail.com> Hello Felipe, Saturday, March 7, 2009, 4:22:04 PM, you wrote: > So, I would like to make an UArray of LogFloat. They are a newtype of Double this is possible in UArray reimplementation done in ArrayRef library http://haskell.org/haskellwiki/Library/ArrayRef although the library itself may be not compatible with ghc 6.10. try to search on hackage -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Mon Mar 9 17:36:36 2009 From: dons at galois.com (Don Stewart) Date: Mon Mar 9 17:25:58 2009 Subject: UArray for newtypes (LogFloat) In-Reply-To: <1675300215.20090310000732@gmail.com> References: <1675300215.20090310000732@gmail.com> Message-ID: <20090309213635.GA29326@whirlpool.galois.com> bulat.ziganshin: > Hello Felipe, > > Saturday, March 7, 2009, 4:22:04 PM, you wrote: > > > So, I would like to make an UArray of LogFloat. They are a newtype of Double > > this is possible in UArray reimplementation done in ArrayRef library > http://haskell.org/haskellwiki/Library/ArrayRef > although the library itself may be not compatible with ghc 6.10. > try to search on hackage > Can't you also just using generic newtype deriving? E.g. a UArr instance for free: {-# LANGUAGE GeneralizedNewtypeDeriving #-} import Data.Array.Vector newtype LogFloat = LogFloat Double deriving (Eq,Ord,Show,Num,UA) main = print . sumU $ replicateU 1000 (LogFloat pi) Which, btw, still triggers all the usual fusion: $wfold :: Double# -> Int# -> Double# $wfold = \ (ww_s14A :: Double#) (ww1_s14E :: Int#) -> case ww1_s14E of wild_B1 { __DEFAULT -> $wfold (+## ww_s14A 3.141592653589793) (+# wild_B1 1); 1000 -> ww_s14A $ time ./A LogFloat 3141.5926535897806 ./A 0.00s user 0.00s system 154% cpu 0.004 total -- Don From anton.tayanovskyy at gmail.com Sat Mar 14 08:15:14 2009 From: anton.tayanovskyy at gmail.com (Anton Tayanovskyy) Date: Sat Mar 14 08:03:21 2009 Subject: extensible-exceptions configuration failure, ghc 6.8.1, cabal 1.2.2.0 Message-ID: Hi, extensible-exceptions-0.1.1.0 # runghc Setup.hs configure Setup.hs: extensible-exceptions.cabal:21: Parse of field 'extensions' failed: It builds fine after upgrading cabal to 1.6; probably the correct dependency on cabal version is somewhere in between 1.2 and 1.6 Thanks, --A From thomas.dubuisson at gmail.com Sat Mar 14 11:22:15 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat Mar 14 11:10:21 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) In-Reply-To: <1236045706.11896.29.camel@Mavlo> References: <1235987583.11896.21.camel@Mavlo> <1235998529.7915.185.camel@localhost> <1236042979.11896.25.camel@Mavlo> <1236029447.22402.1.camel@localhost> <1236045706.11896.29.camel@Mavlo> Message-ID: <4c44d90b0903140822l15f3b8b4rbdd2f70bed92e016@mail.gmail.com> In a couple days it will be the two week mark and I'll be posting a summary of this conversation on the ticket. At this point I don't see any disagreement, just questions regarding the completeness of the patch (so I included many more functions from Numeric). The final type signatures are: efloat :: (RealFloat a) => Maybe Int -> a -> Doc ffloat :: (RealFloat a) => Maybe Int -> a -> Doc gfloat :: (RealFloat a) => Maybe Int -> a -> Doc hex :: (Integral a) => a -> Doc hexPad :: (Integral a) => a -> Int -> Doc intAtBase :: (Integral a) => a -> (Int -> Char) -> a -> Doc intAtBasePad :: (Integral a) => a -> (Int -> Char) -> a -> Int -> Doc oct :: (Integral a) => a -> Doc octPad :: (Integral a) => Maybe Int -> a -> Int -> Doc Which follows the Numeric module pretty close (except the *Pad functions, which are obvious devivations). Thomas On Mon, Mar 2, 2009 at 7:01 PM, Thomas DuBuisson wrote: >> > Padding floats could be touchy - perhaps it should be a separate patch >> > by someone who would use such a feature and know what they want. >> > >> > Thoughts? >> >> Presumably it would be uncontroversial for the float ones to behave the >> same as the ones from the existing Numeric module. > > Done, the new prettyNumeric.patch is with the ticket including hex, oct, > ffloat, efloat, gfloat, signed, intByBase. ?Also, padded versions of > hex, oct, intByBase. > > Thomas > > From ml at isaac.cedarswampstudios.org Sat Mar 14 19:58:23 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat Mar 14 19:46:34 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) In-Reply-To: <4c44d90b0903140822l15f3b8b4rbdd2f70bed92e016@mail.gmail.com> References: <1235987583.11896.21.camel@Mavlo> <1236045706.11896.29.camel@Mavlo> <4c44d90b0903140822l15f3b8b4rbdd2f70bed92e016@mail.gmail.com> Message-ID: <200903141958.23595.ml@isaac.cedarswampstudios.org> Thomas DuBuisson wrote: > In a couple days it will be the two week mark and I'll be posting a > summary of this conversation on the ticket. At this point I don't see > any disagreement, just questions regarding the completeness of the > patch (so I included many more functions from Numeric). The final > type signatures are: > > efloat :: (RealFloat a) => Maybe Int -> a -> Doc > ffloat :: (RealFloat a) => Maybe Int -> a -> Doc > gfloat :: (RealFloat a) => Maybe Int -> a -> Doc > hex :: (Integral a) => a -> Doc > hexPad :: (Integral a) => a -> Int -> Doc > intAtBase :: (Integral a) => a -> (Int -> Char) -> a -> Doc > intAtBasePad :: (Integral a) => a -> (Int -> Char) -> a -> Int -> Doc > oct :: (Integral a) => a -> Doc > octPad :: (Integral a) => Maybe Int -> a -> Int -> Doc > > Which follows the Numeric module pretty close (except the *Pad > functions, which are obvious devivations). are the "Pad" functions ones that (as mentioned above) are willing not just to add padding but to chop off higher-order digits? I find the name misleading. Also hexPad and intAtBasePad each add (compared to the non-Pad versions) an Int argument, but octPad adds an Int and a Maybe Int argument? why is this? -Isaac From thomas.dubuisson at gmail.com Sat Mar 14 20:31:01 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat Mar 14 20:19:06 2009 Subject: Ticket #3058: Add 'hex' to the pretty package (and other thoughts) In-Reply-To: <200903141958.23595.ml@isaac.cedarswampstudios.org> References: <1235987583.11896.21.camel@Mavlo> <1236045706.11896.29.camel@Mavlo> <4c44d90b0903140822l15f3b8b4rbdd2f70bed92e016@mail.gmail.com> <200903141958.23595.ml@isaac.cedarswampstudios.org> Message-ID: <4c44d90b0903141731n2625d717w32f7c3c876d5a851@mail.gmail.com> > are the "Pad" functions ones that (as mentioned above) are willing not just to > add padding but to chop off higher-order digits? ?I find the name misleading. Yes, and I agree the name is misleading. Does anyone have a suggestion of a better name? > Also hexPad and intAtBasePad each add (compared to the non-Pad versions) an > Int argument, but octPad adds an Int and a Maybe Int argument? ?why is this? That's not right - don't know how that error happened, perhaps a toy-version of the library was loaded. Here is a copy paste of the type signature and some uses: Prelude Text.PrettyPrint> :i octPad octPad :: (Integral a) => a -> Int -> Doc Prelude Text.PrettyPrint> octPad 10 2 12 Prelude Text.PrettyPrint> hexPad 133 3 085 Prelude Text.PrettyPrint> hexPad 133 2 85 Prelude Text.PrettyPrint> hexPad 133 1 5 From ganesh.sittampalam at credit-suisse.com Sun Mar 15 10:15:41 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sun Mar 15 10:04:09 2009 Subject: transformers versus mtl Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA914@ELON17P32001A.csfb.cs-group.com> Hi, What are the relative status of transformers and mtl? Are we trying to deprecate mtl use in favour of transformers (+ appropriate dependencies like monads-fd)? I see that the initial version of the Haskell Platform is planning to use mtl because of its status in extralibs - but if transformers is the way forward, then perhaps this should be changed? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From lemming at henning-thielemann.de Sun Mar 15 17:38:48 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Mar 15 17:26:51 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA914@ELON17P32001A.csfb.cs-group.com> References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA914@ELON17P32001A.csfb.cs-group.com> Message-ID: On Sun, 15 Mar 2009, Sittampalam, Ganesh wrote: > Hi, > > What are the relative status of transformers and mtl? Are we trying to > deprecate mtl use in favour of transformers (+ appropriate dependencies > like monads-fd)? I have actually done this step in all of my packages. > I see that the initial version of the Haskell Platform is planning to > use mtl because of its status in extralibs - but if transformers is the > way forward, then perhaps this should be changed? I prefer transformers + monad-fd + monad-tf or whatever as the standard implementation over mtl. From ben.franksen at online.de Sun Mar 15 18:50:15 2009 From: ben.franksen at online.de (Ben Franksen) Date: Sun Mar 15 18:38:28 2009 Subject: Eliminate/move class Alternative Message-ID: Hi, I propose to remove class Alternative and functions depending on it (optional, some, and many) from Control.Applicative. They can be moved into a separate module Control.Alternative if people desire such a class, but I doubt that it has many useful applications, at least in its present form. Rationale: Although the idea behind Alternative, i.e. generalize some of the functions commonly found in parser combinator libs, is a nice one, it doesn't work too well in practice, /even/ for the case that has inspired it (namely parsers). This is mostly due to the class method 'empty'. First of all, this is a bad name, /especially/ in the context of parsers, where 'empty' intuitively means 'recognize the empty sequence of tokens' which is definitely /not/ what Alternative's 'empty' means. (Indeed, this is normally be the meaning of 'pure' from class Applicative.) The 'empty' from Alternative rather means 'fail'. Yeah, I know that this name is already taken by class Monad. Many names would be better than 'empty', for instance 'none', or just 'failed'. (I'll stick with 'none' in what follows.) Second, and more important, is that some parser libs would like to, but cannot offer a sensible implementation for it. For instance, any error-correcting library of parser combinators (like those invented by Swierstra & Duponcheel) need to construct a valid result even in case of a failed parse. Thus, the user must be able to pass an argument to 'none' which would be possible only if it had a function type, like in class Alternative f where ... none :: a -> f a However, even this wouldn't be enough in practice because typically you will want to pass additional data, like an error message. How this can be properly generalized is something that needs more thought. Some of you might be tempted to say "if you don't like Alternative, just don't use it". However, not using it means additional effort, as I /would/ like to use class Applicative /and/ the <|> operator with its intended meaning, i.e. choice/alternative, and also the dependent functions (optional, many, etc). So currently I have to explicitly hide all the Alternative stuff, like this import Control.Applicative hiding (Alternative(..),optional,some,many) which is not nice at all. As a final point, class Alternative comes with no stated laws. While there are a number of standard classes where laws don't make much sense (like, e.g. Show, or Typeable), this is clearly not one of those cases: The docs say Alternative is "a monoid on applicative functors". This suggests associativity and left/right unit laws. However, this is most probably not the whole story, i.e. how are <|> and the ill-named 'empty' supposed to interact with the operations and laws for Applicative? Are we going to have the same dilemma here, as with MonadPlus vs. MonadZero/MonadOr, whatever? Conclusion: In its current form, class Alternative looks like it has been hastily cobbled together. Thus it has no place in Control.Applicative. Moving it into its own separate module is the least we can do. Cheers Ben From john at repetae.net Sun Mar 15 19:33:10 2009 From: john at repetae.net (John Meacham) Date: Sun Mar 15 19:21:11 2009 Subject: Eliminate/move class Alternative In-Reply-To: References: Message-ID: <20090315233310.GJ8842@sliver.repetae.net> I have the exact same issues with Alternative. My frisby parser library[1] is incompatable with the way Alternative is defined. It is particularly irksome because I have users that want to use the applicative syntax, but the Alternative definitions get in the way. Even if we don't get rid of it, moving many,some, etc.. into the class itself would be an improvement. But as was mentioned, it is quite unclear whether sensible definitions exist for all things we may want to be in alternative, or even what belongs in alternative at all. [1] http://repetae.net/computer/frisby/ John -- John Meacham - ?repetae.net?john? From ganesh.sittampalam at credit-suisse.com Mon Mar 16 04:48:34 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Mar 16 04:37:12 2009 Subject: transformers versus mtl In-Reply-To: References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA914@ELON17P32001A.csfb.cs-group.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA917@ELON17P32001A.csfb.cs-group.com> Henning Thielemann wrote: > On Sun, 15 Mar 2009, Sittampalam, Ganesh wrote: > >> I see that the initial version of the Haskell Platform is planning to >> use mtl because of its status in extralibs - but if transformers is >> the way forward, then perhaps this should be changed? > > I prefer transformers + monad-fd + monad-tf or whatever as the > standard implementation over mtl. Yes, so do I. >> What are the relative status of transformers and mtl? Are we trying >> to deprecate mtl use in favour of transformers (+ appropriate >> dependencies like monads-fd)? > > I have actually done this step in all of my packages. I think this makes perfect sense where the monad transformer types are not externally visible. I'm just concerned about what to do with packages where the types are part of the interface - it would be best to coordinate this to some extent to avoid incompatibilities. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From nicolas.pouillard at gmail.com Mon Mar 16 09:35:09 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon Mar 16 09:24:22 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA917@ELON17P32001A.csfb.cs-group.com> References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA914@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA917@ELON17P32001A.csfb.cs-group.com> Message-ID: <1237210493-sup-5365@ausone.inria.fr> Excerpts from Sittampalam, Ganesh's message of Mon Mar 16 08:48:34 UTC 2009: > Henning Thielemann wrote: > > On Sun, 15 Mar 2009, Sittampalam, Ganesh wrote: > > > >> I see that the initial version of the Haskell Platform is planning to > >> use mtl because of its status in extralibs - but if transformers is > >> the way forward, then perhaps this should be changed? > > > > I prefer transformers + monad-fd + monad-tf or whatever as the > > standard implementation over mtl. > > Yes, so do I. +1 too -- Nicolas Pouillard From noteed at gmail.com Mon Mar 16 09:40:01 2009 From: noteed at gmail.com (minh thu) Date: Mon Mar 16 09:28:01 2009 Subject: transformers versus mtl In-Reply-To: <1237210493-sup-5365@ausone.inria.fr> References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA914@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA917@ELON17P32001A.csfb.cs-group.com> <1237210493-sup-5365@ausone.inria.fr> Message-ID: <40a414c20903160640s512f0800rbd183a5c505c29ed@mail.gmail.com> 2009/3/16 Nicolas Pouillard : > Excerpts from Sittampalam, Ganesh's message of Mon Mar 16 08:48:34 UTC 2009: >> Henning Thielemann wrote: >> > On Sun, 15 Mar 2009, Sittampalam, Ganesh wrote: >> > >> >> I see that the initial version of the Haskell Platform is planning to >> >> use mtl because of its status in extralibs - but if transformers is >> >> the way forward, then perhaps this should be changed? >> > >> > I prefer transformers + monad-fd + monad-tf or whatever as the >> > standard implementation over mtl. >> >> Yes, so do I. > > +1 too Hi, What's the reason to prefer transformers over mtl ? Thanks, Thu From ross at soi.city.ac.uk Mon Mar 16 10:10:38 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Mar 16 09:58:40 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA917@ELON17P32001A.csfb.cs-group.com> References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA914@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA917@ELON17P32001A.csfb.cs-group.com> Message-ID: <20090316141038.GA4491@soi.city.ac.uk> On Mon, Mar 16, 2009 at 08:48:34AM -0000, Sittampalam, Ganesh wrote: > I think this makes perfect sense where the monad transformer types > are not externally visible. I'm just concerned about what to do with > packages where the types are part of the interface - it would be best > to coordinate this to some extent to avoid incompatibilities. Hmm, there seem to be over a hundred such packages. The monads-fd and monads-tf packages use the same module names, which will create incompatibilities if both appear in interfaces. I'm not sure what to do there. transformers+monads-fd tries to mirror mtl, so maybe monads-tf has to move. From g9ks157k at acme.softbase.org Mon Mar 16 10:23:03 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Mar 16 10:11:05 2009 Subject: Eliminate/move class Alternative In-Reply-To: References: Message-ID: <200903161523.04062.g9ks157k@acme.softbase.org> Am Sonntag, 15. M?rz 2009 23:50 schrieb Ben Franksen: > This is mostly due to the class method 'empty'. > > First of all, this is a bad name, /especially/ in the context of parsers, > where 'empty' intuitively means 'recognize the empty sequence of tokens' > which is definitely /not/ what Alternative's 'empty' means. (Indeed, this > is normally be the meaning of 'pure' from class Applicative.) > > The 'empty' from Alternative rather means 'fail'. Yeah, I know that this > name is already taken by class Monad. Many names would be better > than 'empty', for instance 'none', or just 'failed'. (I'll stick > with 'none' in what follows.) The parser fails so ?fail? might be a good name. However, when using an applicative style for writing parsers (in contrast to the ?imperative? do notation), you almost write a grammar of your language. And ?empty? just denotes the empty language. So the name might be not as bad as it first looks like. Best wishes, Wolfgang From ganesh.sittampalam at credit-suisse.com Mon Mar 16 10:29:05 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Mar 16 10:18:06 2009 Subject: transformers versus mtl In-Reply-To: <20090316141038.GA4491@soi.city.ac.uk> References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA914@ELON17P32001A.csfb.cs-group.com><16442B752A06A74AB4D9F9A5FF076E4B01ABA917@ELON17P32001A.csfb.cs-group.com> <20090316141038.GA4491@soi.city.ac.uk> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA923@ELON17P32001A.csfb.cs-group.com> Ross Paterson wrote: > On Mon, Mar 16, 2009 at 08:48:34AM -0000, Sittampalam, Ganesh wrote: >> I think this makes perfect sense where the monad transformer types >> are not externally visible. I'm just concerned about what to do with >> packages where the types are part of the interface - it would be best >> to coordinate this to some extent to avoid incompatibilities. > > Hmm, there seem to be over a hundred such packages. > > The monads-fd and monads-tf packages use the same module names, which > will create incompatibilities if both appear in interfaces. I'm not > sure what to do there. transformers+monads-fd tries to mirror mtl, > so maybe monads-tf has to move. That's an issue for the design of transformers that clearly needs to be fixed, but I was actually asking about if any focused mtl -> transformers transition is planned and how it will be managed, in terms of dealing with the non-interoperability between the types in each. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From mark.spezzano at chariot.net.au Tue Mar 17 01:00:28 2009 From: mark.spezzano at chariot.net.au (Mark Spezzano) Date: Tue Mar 17 00:48:42 2009 Subject: Cabal install error msg Message-ID: <000001c9a6bd$4b9deac0$e2d9c040$@spezzano@chariot.net.au> Hi all, I’m trying to do an install of OpenGL on Windows using Cabal I type >cabal.exe configure OpenGL And get sh: runProcess: does not exist (No such file or directory) What’s the cause? Cheers, Mark Spezzano No virus found in this outgoing message. Checked by AVG. Version: 7.5.557 / Virus Database: 270.11.15/2004 - Release Date: 16/03/2009 7:04 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20090317/4961c676/attachment.htm From duncan.coutts at worc.ox.ac.uk Tue Mar 17 06:05:13 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Mar 17 05:53:13 2009 Subject: Cabal install error msg In-Reply-To: <000001c9a6bd$4b9deac0$e2d9c040$@spezzano@chariot.net.au> References: <000001c9a6bd$4b9deac0$e2d9c040$@spezzano@chariot.net.au> Message-ID: <1237284313.22402.567.camel@localhost> On Tue, 2009-03-17 at 15:30 +1030, Mark Spezzano wrote: > Hi all, > I?m trying to do an install of OpenGL on Windows using Cabal > I type > >cabal.exe configure OpenGL > And get > sh: runProcess: does not exist (No such file or directory) > What?s the cause? The OpenGL package uses a ./configure script which needs sh.exe and various other programs. Cabal is trying to run sh.exe but it cannot find it. To build the OpenGL package on Windows you need to build it from within an MSYS shell (which provides sh.exe and the other required tools). There's also a ticket for the bad error message: #403 Bad error message when running ./configure fails to find sh http://hackage.haskell.org/trac/hackage/ticket/403 It should be very easy to improve the error message. Patches welcome. Duncan From haskell at list.mightyreason.com Wed Mar 18 08:23:58 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Wed Mar 18 08:11:57 2009 Subject: ANN: regex-tdfa-1.1.0 Message-ID: <49C0E7DE.6060106@list.mightyreason.com> I have just uploaded the new regex-tdfa-1.1.0 to hackage. This version is a small performance update to the old regex-tdfa-1.0.0 version. Previously all text (e.g. ByteString) being search was converted to String and sent through a single engine. The new version uses a type class and SPECIALIZE pragmas to avoid converting to String. This should make adding support for searching other Char containers easy to do. The new version includes six specialized engine loops to take advantage of obvious optimizations of the traversal. The previous version had only a couple of such engines. The new code paths have been tested for correctness and no performance degradations have shown up. -- Chris From jnf at arcor.de Wed Mar 18 18:34:19 2009 From: jnf at arcor.de (jutaro) Date: Wed Mar 18 18:22:13 2009 Subject: Dependency version problem with Cabal Message-ID: <22590000.post@talk.nabble.com> In my leksah.cabal file i have the package dependency Cabal >=1.6.0.1. When I have installed Cabal-1.6.0.2 as well a s1.6.0.1 I get the following warning: Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package ghc-6.10.1 requires Cabal-1.6.0.1 package leksah-0.4.3 requires Cabal-1.6.0.2 Why does this happen, as leksah does not require Cabal-1.6.0.2? How can I solve this problem? J?rgen Nicklisch-Franken -- View this message in context: http://www.nabble.com/Dependency-version-problem-with-Cabal-tp22590000p22590000.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From duncan.coutts at worc.ox.ac.uk Thu Mar 19 06:46:32 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 19 06:34:22 2009 Subject: Dependency version problem with Cabal In-Reply-To: <22590000.post@talk.nabble.com> References: <22590000.post@talk.nabble.com> Message-ID: <1237459592.22581.58.camel@localhost> On Wed, 2009-03-18 at 15:34 -0700, jutaro wrote: > In my leksah.cabal file i have the package dependency Cabal >=1.6.0.1. > When I have installed Cabal-1.6.0.2 as well a s1.6.0.1 I get the following > warning: > > Warning: This package indirectly depends on multiple versions of the same > package. This is highly likely to cause a compile failure. > package ghc-6.10.1 requires Cabal-1.6.0.1 > package leksah-0.4.3 requires Cabal-1.6.0.2 > > Why does this happen, as leksah does not require Cabal-1.6.0.2? > How can I solve this problem? The runghc Setup configure uses a simple algorithm to decide what versions of packages should be used. It always picks the latest installed versions. However then it checks if the configuration it picked means that directly or indirectly we end up depending on multiple versions of the same package. It does that check because depending on multiple versions of the same package is often a mistake and leads to compile failure. So it's saying that leksah requires Cabal-1.6.0.2 only because it went and picked the latest version of Cabal. Now in this case the warning is probably superfluous. It's unlikely that the bits of the Cabal library that ghc re-exports are bits that you directly import from Cabal. So it'll probably work. Note that you will not get the warning if you use the "cabal configure" (at least the latest version) or "cabal install" commands. That's because these two commands use a more sophisticated algorithm to decide what versions of packages should be used. In this case they would probably end up picking Cabal-1.6.0.1 and everything would be ok. If you want to use the runghc Setup configure method and don't like the warning you can tell it to pick a different version: runghc Setup configure --constraint="Cabal == 1.6.0.1" Duncan From ross at soi.city.ac.uk Thu Mar 19 13:07:29 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Mar 19 12:55:21 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA923@ELON17P32001A.csfb.cs-group.com> References: <20090316141038.GA4491@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA923@ELON17P32001A.csfb.cs-group.com> Message-ID: <20090319170729.GA4716@soi.city.ac.uk> On Mon, Mar 16, 2009 at 02:29:05PM -0000, Sittampalam, Ganesh wrote: > I was actually asking about if any focused mtl -> transformers > transition is planned and how it will be managed, in terms of dealing > with the non-interoperability between the types in each. There is no transition plan; transformers is a recent arrival. I think it's an improvement, but we haven't had the discussion yet. From ganesh.sittampalam at credit-suisse.com Thu Mar 19 13:14:22 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Mar 19 13:02:55 2009 Subject: transformers versus mtl In-Reply-To: <20090319170729.GA4716@soi.city.ac.uk> References: <20090316141038.GA4491@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA923@ELON17P32001A.csfb.cs-group.com> <20090319170729.GA4716@soi.city.ac.uk> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> Ross Paterson wrote: > On Mon, Mar 16, 2009 at 02:29:05PM -0000, Sittampalam, Ganesh wrote: >> I was actually asking about if any focused mtl -> transformers >> transition is planned and how it will be managed, in terms of dealing >> with the non-interoperability between the types in each. > > There is no transition plan; transformers is a recent arrival. > I think it's an improvement, but we haven't had the discussion yet. Would now be a good time to start it, or do we need more experience of transformers? >From my point of view, I'm trying to decide what I should be exposing in interfaces right now (in particular for the rmonad package on hackage). It seems like the answer is mtl, but if there will be a transition to transformers in the relatively near future, it would be easier to be a front-runner, since I don't think the package is very widely used. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From iavor.diatchki at gmail.com Thu Mar 19 19:39:49 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Mar 19 19:27:38 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> References: <20090316141038.GA4491@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA923@ELON17P32001A.csfb.cs-group.com> <20090319170729.GA4716@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> Message-ID: <5ab17e790903191639q36c87704s1abc9e7c374a0835@mail.gmail.com> Hello, I would like to point out that another option is monadLib, which has been around for a while. It was never marketed very much so it never become particularly popular but it works pretty well (my colleagues and I use it on a number of projects). -Iavor On Thu, Mar 19, 2009 at 10:14 AM, Sittampalam, Ganesh wrote: > Ross Paterson wrote: >> On Mon, Mar 16, 2009 at 02:29:05PM -0000, Sittampalam, Ganesh wrote: >>> I was actually asking about if any focused mtl -> transformers >>> transition is planned and how it will be managed, in terms of dealing >>> with the non-interoperability between the types in each. >> >> There is no transition plan; transformers is a recent arrival. >> I think it's an improvement, but we haven't had the discussion yet. > > Would now be a good time to start it, or do we need more experience > of transformers? > > >From my point of view, I'm trying to decide what I should be exposing > in interfaces right now (in particular for the rmonad package on > hackage). > It seems like the answer is mtl, but if there will be a transition to > transformers in the relatively near future, it would be easier to be a > front-runner, since I don't think the package is very widely used. > > Ganesh > > =============================================================================== > ?Please access the attached hyperlink for an important electronic communications disclaimer: > ?http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ?=============================================================================== > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From duncan.coutts at worc.ox.ac.uk Thu Mar 19 20:12:49 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 19 20:00:38 2009 Subject: transformers versus mtl In-Reply-To: <5ab17e790903191639q36c87704s1abc9e7c374a0835@mail.gmail.com> References: <20090316141038.GA4491@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA923@ELON17P32001A.csfb.cs-group.com> <20090319170729.GA4716@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> <5ab17e790903191639q36c87704s1abc9e7c374a0835@mail.gmail.com> Message-ID: <1237507969.22581.67.camel@localhost> On Thu, 2009-03-19 at 16:39 -0700, Iavor Diatchki wrote: > Hello, > > I would like to point out that another option is monadLib, which has > been around for a while. It was never marketed very much so it never > become particularly popular but it works pretty well (my colleagues > and I use it on a number of projects). Can you market it a bit more please :-). Tell us what the advantages of it are over mtl. I know you've told me in person but I'm sure I've forgotten the details :-). Duncan From ganesh.sittampalam at credit-suisse.com Fri Mar 20 04:16:10 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Fri Mar 20 04:05:01 2009 Subject: transformers versus mtl In-Reply-To: <1237507969.22581.67.camel@localhost> References: <20090316141038.GA4491@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA923@ELON17P32001A.csfb.cs-group.com> <20090319170729.GA4716@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> <5ab17e790903191639q36c87704s1abc9e7c374a0835@mail.gmail.com> <1237507969.22581.67.camel@localhost> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA946@ELON17P32001A.csfb.cs-group.com> Duncan Coutts wrote: > On Thu, 2009-03-19 at 16:39 -0700, Iavor Diatchki wrote: >> Hello, >> >> I would like to point out that another option is monadLib, which has >> been around for a while. It was never marketed very much so it >> never become particularly popular but it works pretty well (my >> colleagues and I use it on a number of projects). > > Can you market it a bit more please :-). Tell us what the advantages > of it are over mtl. Also, is there any scope for eliminating duplication by depending on transformers for the common datatypes etc? I'm sure monadLib has its own distinctive features but for those parts that are the same I feel we really should be trying to avoid incompatibilities. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From ross at soi.city.ac.uk Fri Mar 20 12:47:09 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Mar 20 12:34:59 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> References: <20090319170729.GA4716@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> Message-ID: <20090320164709.GA5568@soi.city.ac.uk> On Thu, Mar 19, 2009 at 05:14:22PM -0000, Sittampalam, Ganesh wrote: > Would now be a good time to start it, or do we need more experience > of transformers? Perhaps sooner would be better that later, as there are so many packages involved (~350, of which over 100 include mtl types and classes in their interfaces). I think it's necessary to split off the multi-parameter type classes from the rest, so that the transformers can be used either on their own or with type families, and clients of the different configurations can be used together. A transition will be disruptive, as only 30 of the packages have upper bounds on their mtl dependencies, but I think we can reduce the disruption. The combination transformers + monads-fd is close to a compatible replacement for mtl at the source level, except that State, Writer, etc are now type synonyms, which will break some code. Of course the package names are also different. We can't just rename monads-fd as mtl-2.0, because Control.Monad.Identity and Control.Monad.Trans are in the transformers package. But we could make a compatibility version of mtl along the lines of base3-compat. (And we need to rename the modules in monads-tf.) From alexander.dunlap at gmail.com Fri Mar 20 14:08:57 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Fri Mar 20 13:56:44 2009 Subject: transformers versus mtl In-Reply-To: <20090320164709.GA5568@soi.city.ac.uk> References: <20090319170729.GA4716@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> <20090320164709.GA5568@soi.city.ac.uk> Message-ID: <57526e770903201108h724a70a7m8a475fec1f1c0013@mail.gmail.com> On Fri, Mar 20, 2009 at 9:47 AM, Ross Paterson wrote: > On Thu, Mar 19, 2009 at 05:14:22PM -0000, Sittampalam, Ganesh wrote: >> Would now be a good time to start it, or do we need more experience >> of transformers? > > Perhaps sooner would be better that later, as there are so many packages > involved (~350, of which over 100 include mtl types and classes in their > interfaces). > > I think it's necessary to split off the multi-parameter type classes > from the rest, so that the transformers can be used either on their > own or with type families, and clients of the different configurations > can be used together. > > A transition will be disruptive, as only 30 of the packages have > upper bounds on their mtl dependencies, but I think we can reduce the > disruption. > > The combination transformers + monads-fd is close to a compatible > replacement for mtl at the source level, except that State, Writer, > etc are now type synonyms, which will break some code. ?Of course the > package names are also different. ?We can't just rename monads-fd as > mtl-2.0, because Control.Monad.Identity and Control.Monad.Trans are in > the transformers package. ?But we could make a compatibility version of > mtl along the lines of base3-compat. ?(And we need to rename the modules > in monads-tf.) > The other thing to think about is with regards to FunctionalDependencies vs. TypeFamilies. If we have two different libraries, one providing a TF interface and one providing an FD interface, we will naturally have some developers using one of them and others using another, based on personal preference. This is all well and good for application code, but it gets messy for libraries. If package foo declares some datatypes and makes them instances of monads-tf classes, and package bar declares some datatypes and makes them instances of monads-fd classes, then it will be hard for an application or another library to use both foo and bar in conjunction with each other because they will not be using the same monad classes. Would it be best practice for libraries to depend on *both* packages and declare instances for both classes? Alex From ganesh.sittampalam at credit-suisse.com Sat Mar 21 12:19:05 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sat Mar 21 12:07:00 2009 Subject: transformers versus mtl In-Reply-To: <20090320164709.GA5568@soi.city.ac.uk> References: <20090319170729.GA4716@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> <20090320164709.GA5568@soi.city.ac.uk> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> Ross Paterson wrote: > The combination transformers + monads-fd is close to a compatible > replacement for mtl at the source level, except that State, Writer, > etc are now type synonyms, which will break some code. Of course the > package names are also different. We can't just rename monads-fd as > mtl-2.0, because Control.Monad.Identity and Control.Monad.Trans are > in the transformers package. But we could make a compatibility > version of mtl along the lines of base3-compat. (And we need to > rename the modules in monads-tf.) The compatibility layer could continue to export the old separate types for State, Writer, etc, couldn't it? Are there any problems with adding transformers and monads-fd to extralibs pending the Haskell Platform being ready? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From ross at soi.city.ac.uk Sat Mar 21 12:40:53 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Mar 21 12:28:37 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> References: <20090320164709.GA5568@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> Message-ID: <20090321164053.GA4478@soi.city.ac.uk> On Sat, Mar 21, 2009 at 04:19:05PM -0000, Sittampalam, Ganesh wrote: > Ross Paterson wrote: > > The combination transformers + monads-fd is close to a compatible > > replacement for mtl at the source level, except that State, Writer, > > etc are now type synonyms, which will break some code. Of course the > > package names are also different. We can't just rename monads-fd as > > mtl-2.0, because Control.Monad.Identity and Control.Monad.Trans are > > in the transformers package. But we could make a compatibility > > version of mtl along the lines of base3-compat. (And we need to > > rename the modules in monads-tf.) > > The compatibility layer could continue to export the old separate types > for State, Writer, etc, couldn't it? It could, though then they'd be different types than the transformer versions. There's a trade-off. > Are there any problems with adding transformers and monads-fd to > extralibs pending the Haskell Platform being ready? That should work, but that wouldn't be till September/October. I'm not sure what the HP schedule is. Another possibility is to upload mtl-2.0 as a compatibility layer. From ganesh.sittampalam at credit-suisse.com Sat Mar 21 13:05:07 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sat Mar 21 12:53:48 2009 Subject: transformers versus mtl In-Reply-To: <20090321164053.GA4478@soi.city.ac.uk> References: <20090320164709.GA5568@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> <20090321164053.GA4478@soi.city.ac.uk> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA95E@ELON17P32001A.csfb.cs-group.com> Ross Paterson wrote: > On Sat, Mar 21, 2009 at 04:19:05PM -0000, Sittampalam, Ganesh wrote: >> The compatibility layer could continue to export the old separate >> types for State, Writer, etc, couldn't it? > > It could, though then they'd be different types than the transformer > versions. There's a trade-off. Yeah. I guess we could see how much stuff breaks first. It'll only be the things that rely on it being a real type *and* don't have an upper bound on their mtl deps. >> Are there any problems with adding transformers and monads-fd to >> extralibs pending the Haskell Platform being ready? > > That should work, but that wouldn't be till September/October. I'm > not sure what the HP schedule is. Another possibility is to upload > mtl-2.0 as a compatibility layer. I don't really understand the relationship between extralibs and hackage - I was assuming that changes to mtl had to go into extralibs to become official. Uploading to hackage as well would obviously help the migration happen sooner. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From lemming at henning-thielemann.de Sat Mar 21 17:38:59 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Mar 21 17:26:44 2009 Subject: transformers versus mtl In-Reply-To: <20090321164053.GA4478@soi.city.ac.uk> References: <20090320164709.GA5568@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> <20090321164053.GA4478@soi.city.ac.uk> Message-ID: On Sat, 21 Mar 2009, Ross Paterson wrote: >> Are there any problems with adding transformers and monads-fd to >> extralibs pending the Haskell Platform being ready? > > That should work, but that wouldn't be till September/October. I'm not > sure what the HP schedule is. Another possibility is to upload mtl-2.0 > as a compatibility layer. We already found out, that compatibility to mtl cannot be achieved with a package based on transformers. So why shall we rewrite mtl in terms of transformers+monad-fd at all? I welcome advertising transformers+monad-fd, but I don't see the benefits of breaking mtl. From ganesh.sittampalam at credit-suisse.com Sat Mar 21 17:53:39 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sat Mar 21 17:41:49 2009 Subject: transformers versus mtl In-Reply-To: References: <20090320164709.GA5568@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com><20090321164053.GA4478@soi.city.ac.uk> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> Henning Thielemann wrote: > On Sat, 21 Mar 2009, Ross Paterson wrote: > >>> Are there any problems with adding transformers and monads-fd to >>> extralibs pending the Haskell Platform being ready? >> >> That should work, but that wouldn't be till September/October. I'm >> not sure what the HP schedule is. Another possibility is to upload >> mtl-2.0 as a compatibility layer. > > We already found out, that compatibility to mtl cannot be achieved > with a package based on transformers. Can you elaborate on this or point me at the past discussion? I can't find anything from a quick look through the archives, apart from the issue that haddock will go wrong if mtl just re-exports things from transformers. > So why shall we rewrite mtl in > terms of transformers+monad-fd at all? I welcome advertising > transformers+transformers+monad-fd, > but I don't see the benefits of breaking mtl. If we don't make mtl and transformers use the same types, we will have some packages with interfaces that use one and some with interfaces that use the other for quite a long time to come. Also, if mtl stays in extralibs/the Haskell Platform but remains incompatible with transformers, then it will be in some way blessed which will hinder a move to transformers, but if we suddenly remove it then a lot of people will suddenly have to go and find it from hackage when previously they got it with GHC. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From iavor.diatchki at gmail.com Sat Mar 21 18:05:57 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Mar 21 17:53:39 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA946@ELON17P32001A.csfb.cs-group.com> References: <20090316141038.GA4491@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA923@ELON17P32001A.csfb.cs-group.com> <20090319170729.GA4716@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> <5ab17e790903191639q36c87704s1abc9e7c374a0835@mail.gmail.com> <1237507969.22581.67.camel@localhost> <16442B752A06A74AB4D9F9A5FF076E4B01ABA946@ELON17P32001A.csfb.cs-group.com> Message-ID: <5ab17e790903211505n55d251aai4cd07029a063d88c@mail.gmail.com> Hello, There are a number of reasons why I prefer monadLib over mtl. None of them are huge issues, which is why I never bothered to "spread the word" :) Anyway, here are some of the differences off the top of my head (not in order of importance) - Nicer packaging: monadLib has 1 module (or 3 depending on how you look at it), mtl has 21 - Conceptually simpler types: monadLib provides two base mondas (Id and Lift) and one transformer per effect. By combining these programmers can construct all the monads that they need. MTL also provides these, but in addition it provides other types which I think are unnecessary and make things look more complex then they are (RWS monad, strict/lazy version of monads, predefined base monads) - Correct back-tracking transformer, called ChoiceT. At least in the past MTL's ListT worked only for commutative monads, I am not sure if that was fixed. - In monadLib one can throw arbitrary exceptions (there is no need for an Error class). I never understood what's the point of the class Error. - MonadLib has a more general "MonadIO" class, called "InBase". It allows executing computations in the base monad of a tower of monads, even when the base monad is not IO. - MonadLib organizes the different effect operators in a slightly different hierarchy of classes which, in principle, allows for more fine-grained control over effect (e.g., you could have a type that ensure that a computation will only raise exceptions but not handle them). I think that's probably about it. As I said, none of these are huge issues, indeed monadLib was originally designed to replace mtl, so they are fairly similar in style and appearance. This never happened because it was in the early days of Haskell libraries and we had no good process for doing things like that. Also, I am not that interested in marketing :-) On Ganesh's question if monadLib could be written in terms of "transformers": no, because transformers uses a different list transformer. Furthermore, I would not be inclined to do it because it would add an extra unnecessary dependency to monadLib, and also I think that transformers has some of the same problems as mtl (17 modules, some of which define things like RWS). Apologies if was too critical of MTL, I think that it is a fine library which is clearly used by many people. I just think that monadLib is a bit nicer. -Iavor On Fri, Mar 20, 2009 at 1:16 AM, Sittampalam, Ganesh wrote: > Duncan Coutts wrote: >> On Thu, 2009-03-19 at 16:39 -0700, Iavor Diatchki wrote: >>> Hello, >>> >>> I would like to point out that another option is monadLib, which has >>> been around for a while. ? It was never marketed very much so it >>> never become particularly popular but it works pretty well (my >>> colleagues and I use it on a number of projects). >> >> Can you market it a bit more please :-). Tell us what the advantages >> of it are over mtl. > > Also, is there any scope for eliminating duplication by depending on > transformers for the common datatypes etc? I'm sure monadLib has its > own distinctive features but for those parts that are the same I feel > we really should be trying to avoid incompatibilities. > > Cheers, > > Ganesh > > =============================================================================== > ?Please access the attached hyperlink for an important electronic communications disclaimer: > ?http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ?=============================================================================== > > From ganesh.sittampalam at credit-suisse.com Sat Mar 21 18:22:07 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sat Mar 21 18:10:00 2009 Subject: transformers versus mtl In-Reply-To: <5ab17e790903211505n55d251aai4cd07029a063d88c@mail.gmail.com> References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA946@ELON17P32001A.csfb.cs-group.com> <5ab17e790903211505n55d251aai4cd07029a063d88c@mail.gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA961@ELON17P32001A.csfb.cs-group.com> Iavor Diatchki wrote: > On Ganesh's question if monadLib could be written in terms of > "transformers": no, because transformers uses a different list > transformer. I was only suggesting that the common types should be shared - obviously if the list transformer is different then it shouldn't be. > Furthermore, I would not be inclined to do it because > it would add an extra unnecessary dependency to monadLib, and also I > think that transformers has some of the same problems as mtl (17 > modules, some of which define things like RWS). Fair enough. On the other hand, the benefit would be that libraries based on monadLib would interoperate better with libraries based on transformers. monadLib itself would only re-export the things from transformers that form part of the monadLib design, so the extra modules wouldn't pollute monadLib itself. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From lemming at henning-thielemann.de Sat Mar 21 18:25:56 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Mar 21 18:13:45 2009 Subject: transformers versus mtl In-Reply-To: <5ab17e790903211505n55d251aai4cd07029a063d88c@mail.gmail.com> References: <20090316141038.GA4491@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA923@ELON17P32001A.csfb.cs-group.com> <20090319170729.GA4716@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA943@ELON17P32001A.csfb.cs-group.com> <5ab17e790903191639q36c87704s1abc9e7c374a0835@mail.gmail.com> <1237507969.22581.67.camel@localhost> <16442B752A06A74AB4D9F9A5FF076E4B01ABA946@ELON17P32001A.csfb.cs-group.com> <5ab17e790903211505n55d251aai4cd07029a063d88c@mail.gmail.com> Message-ID: On Sat, 21 Mar 2009, Iavor Diatchki wrote: > Hello, > There are a number of reasons why I prefer monadLib over mtl. None of > them are huge issues, which is why I never bothered to "spread the > word" :) Anyway, here are some of the differences off the top of my > head (not in order of importance) > - Nicer packaging: monadLib has 1 module (or 3 depending on how you > look at it), mtl has 21 I think modules are there to be used. So, at least for me, it's a good thing, that MTL uses separate modules for different concerns. My critics is more that MTL uses identifiers that are designed as if everything could be in one module. E.g. State and StateT should be better State.Base and State.Transformer. > - Conceptually simpler types: monadLib provides two base mondas (Id > and Lift) and one transformer per effect. I find this idea very elegant. Now in transformers the base monads like State, Reader, Writer are replaced by type synonyms that equal StateT Identity and so on. This way, 'put' and 'get' do not need to be type class methods, at least when accessing the top monad in a stack. However I still don't understand, why monadLib achieves the distinction between lazy and strict in the base monad, whereas transformers has still distinct lazy and strict transformers. > - In monadLib one can throw arbitrary exceptions (there is no need > for an Error class). I never understood what's the point of the class > Error. Error class was needed to implement the exception throwing as 'fail'. It's as broken as 'fail' belonging to Monad class. From lemming at henning-thielemann.de Sat Mar 21 18:55:00 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Mar 21 18:42:45 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> References: <20090320164709.GA5568@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> <20090321164053.GA4478@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> Message-ID: On Sat, 21 Mar 2009, Sittampalam, Ganesh wrote: > Henning Thielemann wrote: > >> We already found out, that compatibility to mtl cannot be achieved >> with a package based on transformers. > > Can you elaborate on this or point me at the past discussion? I can't > find anything from a quick look through the archives, apart from the > issue that haddock will go wrong if mtl just re-exports things from > transformers. In mtl State is a type with constructor State, whereas in transformers State is a type synonym with no custom constructor. So, if mtl uses the State type synonym from transformers it cannot be compatible with old mtl versions. >> So why shall we rewrite mtl in >> terms of transformers+monad-fd at all? I welcome advertising >> transformers+transformers+monad-fd, >> but I don't see the benefits of breaking mtl. > > If we don't make mtl and transformers use the same types, > we will have some packages with interfaces that use one and some > with interfaces that use the other for quite a long time to come. That's why I think that we should extensively tell people to use 'transformers' instead of 'mtl'. > Also, if mtl stays in extralibs/the Haskell Platform but remains > incompatible with transformers, then it will be in some way blessed > which will hinder a move to transformers, but if we suddenly remove > it then a lot of people will suddenly have to go and find it from > hackage when previously they got it with GHC. I don't like people forcing this way, as I for myself could spend my whole life keeping my Haskell libraries up-to-date without adding any feature or fixing any bug. I think, mtl should be removed from extralibs, but it should not be upgraded in an incompatible way. We would break packages, not more. I think, incompatibility between libraries based on mtl and those based on transformers is enough hassle to make developers think about a move to 'transformers'. I remember this was your motivation, too, right? From ganesh.sittampalam at credit-suisse.com Sun Mar 22 02:31:08 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sun Mar 22 02:19:49 2009 Subject: transformers versus mtl In-Reply-To: References: <20090320164709.GA5568@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> <20090321164053.GA4478@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> Henning Thielemann wrote: > In mtl State is a type with constructor State, whereas in > transformers State is a type synonym with no custom constructor. So, > if mtl uses the State type synonym from transformers it cannot be > compatible with old mtl versions. Oh right, we already discussed that in this thread. Essentially we have the choice of producing full compatibility by keeping the separate type in mtl, in which case State from mtl is not State from transformers, or partial compatibility by re-exporting the transformers one. We can test hackage (which isn't the entire world, but is a lot of it) to decide which to do. > I don't like people forcing this way, as I for myself could spend my > whole life keeping my Haskell libraries up-to-date without adding any > feature or fixing any bug. I think, mtl should be removed from > extralibs, but it should not be upgraded in an incompatible way. We > would break packages, not more. I think that after the relative chaos of the base 2 -> base 3 upgrade, the general policy nowadays is to minimise disruption when changing things. Completely removing a package from extralibs seems quite disruptive to me. > I think, incompatibility between > libraries based on mtl and those based on transformers is enough > hassle to make developers think about a move to 'transformers'. I > remember this was your motivation, too, right? I'm not convinced that individual developers would make this move very quickly, especially since the disruption wouldn't directly manifest in their packages, but only in things that use their packages. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From haskell at list.mightyreason.com Sun Mar 22 10:07:26 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Sun Mar 22 09:55:09 2009 Subject: ANN: regex-tdfa 1.1.1 Message-ID: <49C6461E.2030400@list.mightyreason.com> This is both a bug fix release and a feature release. The bug fix is a bit embarrassing, the indices were correct but the captured text was wrong in version 1.1.0. Oops. As of version 1.1.1 the following GNU extensions are recognized, all anchors: \` at beginning of entire text \' at end of entire text \< at beginning of word \> at end of word \b at either beginning or end of word \B at neither beginning nor end of word There is a "newSyntax" field of CompOptions that can enable/disable this syntax. These were requested by users of the Yi project. The "home page" is on the wiki and UPDATED a bit at http://haskell.org/haskellwiki/Regular_expressions#regex-tdfa The HADDOCK fails on hackage for now, but is up at http://darcs.haskell.org/packages/regex-unstable/regex-tdfa/doc/html/regex-tdfa/Text-Regex-TDFA.html The released code is on hackage at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa The darcs repository is at http://darcs.haskell.org/packages/regex-unstable/regex-tdfa/ Cheers, Chris From ross at soi.city.ac.uk Sun Mar 22 11:12:10 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Mar 22 10:59:53 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> References: <20090320164709.GA5568@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> <20090321164053.GA4478@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> Message-ID: <20090322151210.GA12995@soi.city.ac.uk> On Sun, Mar 22, 2009 at 06:31:08AM -0000, Sittampalam, Ganesh wrote: > Essentially we have the choice of producing full compatibility > by keeping the separate type in mtl, in which case State from mtl > is not State from transformers, or partial compatibility by > re-exporting the transformers one. Yes, we must choose between full compatibility with mtl and full compatibility with transformers. A quick implementation of the former is http://code.haskell.org/~ross/mtl-compat/ The separate versions of State etc are present, but deprecated. From allbery at ece.cmu.edu Sun Mar 22 11:56:00 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Mar 22 11:43:43 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> References: <20090320164709.GA5568@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> <20090321164053.GA4478@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> Message-ID: <8DD34F7E-E45A-4661-90E9-5F02F0528E6B@ece.cmu.edu> On 2009 Mar 22, at 2:31, Sittampalam, Ganesh wrote: > Henning Thielemann wrote: >> I don't like people forcing this way, as I for myself could spend my >> whole life keeping my Haskell libraries up-to-date without adding any >> feature or fixing any bug. I think, mtl should be removed from >> extralibs, but it should not be upgraded in an incompatible way. We >> would break packages, not more. > > I think that after the relative chaos of the base 2 -> base 3 upgrade, > the general policy nowadays is to minimise disruption when changing > things. Completely removing a package from extralibs seems quite > disruptive to me. But the ultimate objective is for all of extralibs to go away in favor of the Haskell Platform, isn't it? That will assuredly be disruptive, but the current situation is arguably even more disruptive because random packages are forced to update when ghc development leads to an update. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20090322/5f1a9f52/PGP.bin From ganesh.sittampalam at credit-suisse.com Sun Mar 22 17:23:27 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sun Mar 22 17:11:50 2009 Subject: transformers versus mtl In-Reply-To: <8DD34F7E-E45A-4661-90E9-5F02F0528E6B@ece.cmu.edu> References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> <8DD34F7E-E45A-4661-90E9-5F02F0528E6B@ece.cmu.edu> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA963@ELON17P32001A.csfb.cs-group.com> Brandon S. Allbery KF8NH wrote: > On 2009 Mar 22, at 2:31, Sittampalam, Ganesh wrote: >> Henning Thielemann wrote: >>> I don't like people forcing this way, as I for myself could spend my >>> whole life keeping my Haskell libraries up-to-date without adding >>> any feature or fixing any bug. I think, mtl should be removed from >>> extralibs, but it should not be upgraded in an incompatible way. We >>> would break packages, not more. >> >> I think that after the relative chaos of the base 2 -> base 3 >> upgrade, the general policy nowadays is to minimise disruption when >> changing things. Completely removing a package from extralibs seems >> quite disruptive to me. > > But the ultimate objective is for all of extralibs to go away in > favor of the Haskell Platform, isn't it? That will assuredly be > disruptive, At that point the recommended installation route will be of the Platform, not of "just GHC". The first Platform release will be precisely extralibs + cabal-install + deps, so there won't be any disruption assuming that people follow that recommendation. > but the current situation is arguably even more > disruptive because random packages are forced to update when ghc > development leads to an update. Agreed. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From duncan.coutts at worc.ox.ac.uk Sun Mar 22 21:39:29 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 22 21:27:10 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA963@ELON17P32001A.csfb.cs-group.com> References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> <8DD34F7E-E45A-4661-90E9-5F02F0528E6B@ece.cmu.edu> <16442B752A06A74AB4D9F9A5FF076E4B01ABA963@ELON17P32001A.csfb.cs-group.com> Message-ID: <1237772369.22581.146.camel@localhost> On Sun, 2009-03-22 at 21:23 +0000, Sittampalam, Ganesh wrote: > > But the ultimate objective is for all of extralibs to go away in > > favor of the Haskell Platform, isn't it? That will assuredly be > > disruptive, > > At that point the recommended installation route will be of the > Platform, not of "just GHC". The first Platform release will be > precisely extralibs + cabal-install + deps, so there won't be any > disruption assuming that people follow that recommendation. Right. Initially the platform will not add disruption. In the future, if the consensus is for breaking changes in library organisation then the platform provides the mechanism to manage that disruption in a way that is less painful (ie by coordinating the changes). That doesn't mean it's ok to make whatever changes you like all the time, but it should help minimise the pain with any changes we deem necessary. Duncan From ganesh.sittampalam at credit-suisse.com Mon Mar 23 04:38:26 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Mar 23 04:26:46 2009 Subject: transformers versus mtl In-Reply-To: <20090322151210.GA12995@soi.city.ac.uk> References: <20090320164709.GA5568@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com><20090321164053.GA4478@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com><16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> <20090322151210.GA12995@soi.city.ac.uk> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA965@ELON17P32001A.csfb.cs-group.com> Ross Paterson wrote: > On Sun, Mar 22, 2009 at 06:31:08AM -0000, Sittampalam, Ganesh wrote: >> Essentially we have the choice of producing full compatibility by >> keeping the separate type in mtl, in which case State from mtl is not >> State from transformers, or partial compatibility by re-exporting the >> transformers one. > > Yes, we must choose between full compatibility with mtl and full > compatibility with transformers. A quick implementation of the > former is > > http://code.haskell.org/~ross/mtl-compat/ > > The separate versions of State etc are present, but deprecated. Cool. I've been been playing around with regression testing hackage following Duncan's blog post on the subject - I've got a baseline test running now and will try your mtl-compat out next, and then a variant with the transformers compatibility. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From dons at galois.com Mon Mar 23 10:48:24 2009 From: dons at galois.com (Don Stewart) Date: Mon Mar 23 10:36:58 2009 Subject: Timeouts uploading to Hackage Message-ID: <20090323144824.GA28604@whirlpool.galois.com> A couple of users have reported timeouts uploading to Hackage. I've noticed upload times taking longer and longer of previous weeks. Ross, any thoughts? -- Don From Malcolm.Wallace at cs.york.ac.uk Mon Mar 23 11:00:06 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Mar 23 10:50:58 2009 Subject: Timeouts uploading to Hackage In-Reply-To: <20090323144824.GA28604@whirlpool.galois.com> References: <20090323144824.GA28604@whirlpool.galois.com> Message-ID: <20090323150006.1d17e6d5.Malcolm.Wallace@cs.york.ac.uk> Don Stewart wrote: > A couple of users have reported timeouts uploading to Hackage. > I've noticed upload times taking longer and longer of previous weeks. Uploads to Hackage have been rather flaky since day one, in my experience. I have often had two or three timeouts or complete hangs before an attempt finally succeeds. Since Hackage is hosted on the same machine as darcs.haskell.org, which also has had numerous connection problems, I just assumed this was normal. Regards, Malcolm From dons at galois.com Mon Mar 23 11:05:32 2009 From: dons at galois.com (Don Stewart) Date: Mon Mar 23 10:54:17 2009 Subject: Timeouts uploading to Hackage In-Reply-To: <20090323150006.1d17e6d5.Malcolm.Wallace@cs.york.ac.uk> References: <20090323144824.GA28604@whirlpool.galois.com> <20090323150006.1d17e6d5.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20090323150532.GC28604@whirlpool.galois.com> Malcolm.Wallace: > Don Stewart wrote: > > > A couple of users have reported timeouts uploading to Hackage. > > I've noticed upload times taking longer and longer of previous weeks. > > Uploads to Hackage have been rather flaky since day one, in my > experience. I have often had two or three timeouts or complete hangs > before an attempt finally succeeds. Since Hackage is hosted on the same > machine as darcs.haskell.org, which also has had numerous connection > problems, I just assumed this was normal. Shouldn't have any connection problems since we switched the routers 3 or 4 months ago. I wonder though how expensive the upload script is (it has to regenerate some things that are now quite big?) -- Don From ross at soi.city.ac.uk Mon Mar 23 11:26:35 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Mar 23 11:14:16 2009 Subject: Timeouts uploading to Hackage In-Reply-To: <20090323150532.GC28604@whirlpool.galois.com> References: <20090323144824.GA28604@whirlpool.galois.com> <20090323150006.1d17e6d5.Malcolm.Wallace@cs.york.ac.uk> <20090323150532.GC28604@whirlpool.galois.com> Message-ID: <20090323152635.GA3655@soi.city.ac.uk> On Mon, Mar 23, 2009 at 08:05:32AM -0700, Don Stewart wrote: > Malcolm.Wallace: > > Don Stewart wrote: > > > > > A couple of users have reported timeouts uploading to Hackage. > > > I've noticed upload times taking longer and longer of previous weeks. > > > > Uploads to Hackage have been rather flaky since day one, in my > > experience. I have often had two or three timeouts or complete hangs > > before an attempt finally succeeds. Since Hackage is hosted on the same > > machine as darcs.haskell.org, which also has had numerous connection > > problems, I just assumed this was normal. > > Shouldn't have any connection problems since we switched the routers 3 > or 4 months ago. I wonder though how expensive the upload script is (it > has to regenerate some things that are now quite big?) I experienced the same thing myself on the weekend, but I don't know what's causing it. The largest generated file is 10MB in the pipe, compressing to 840KB. The machine has 1.5GB. From dons at galois.com Mon Mar 23 11:42:44 2009 From: dons at galois.com (Don Stewart) Date: Mon Mar 23 11:31:17 2009 Subject: Timeouts uploading to Hackage In-Reply-To: <20090323152635.GA3655@soi.city.ac.uk> References: <20090323144824.GA28604@whirlpool.galois.com> <20090323150006.1d17e6d5.Malcolm.Wallace@cs.york.ac.uk> <20090323150532.GC28604@whirlpool.galois.com> <20090323152635.GA3655@soi.city.ac.uk> Message-ID: <20090323154244.GA371@whirlpool.galois.com> ross: > On Mon, Mar 23, 2009 at 08:05:32AM -0700, Don Stewart wrote: > > Malcolm.Wallace: > > > Don Stewart wrote: > > > > > > > A couple of users have reported timeouts uploading to Hackage. > > > > I've noticed upload times taking longer and longer of previous weeks. > > > > > > Uploads to Hackage have been rather flaky since day one, in my > > > experience. I have often had two or three timeouts or complete hangs > > > before an attempt finally succeeds. Since Hackage is hosted on the same > > > machine as darcs.haskell.org, which also has had numerous connection > > > problems, I just assumed this was normal. > > > > Shouldn't have any connection problems since we switched the routers 3 > > or 4 months ago. I wonder though how expensive the upload script is (it > > has to regenerate some things that are now quite big?) > > I experienced the same thing myself on the weekend, but I don't know > what's causing it. The largest generated file is 10MB in the pipe, > compressing to 840KB. The machine has 1.5GB. Seems like no one is able to upload at the moment? From deduktionstheorem at web.de Mon Mar 23 14:48:08 2009 From: deduktionstheorem at web.de (Stephan Friedrichs) Date: Mon Mar 23 14:35:48 2009 Subject: Timeouts uploading to Hackage In-Reply-To: <20090323154244.GA371@whirlpool.galois.com> References: <20090323144824.GA28604@whirlpool.galois.com> <20090323150006.1d17e6d5.Malcolm.Wallace@cs.york.ac.uk> <20090323150532.GC28604@whirlpool.galois.com> <20090323152635.GA3655@soi.city.ac.uk> <20090323154244.GA371@whirlpool.galois.com> Message-ID: <49C7D968.9090800@web.de> Don Stewart wrote: > [...] > > Seems like no one is able to upload at the moment? I just uploaded heap-0.6.0 (Mon Mar 23 18:22:35 UTC 2009) and both check and actual upload were quite quick! //Stephan From dons at galois.com Mon Mar 23 14:49:29 2009 From: dons at galois.com (Don Stewart) Date: Mon Mar 23 14:38:02 2009 Subject: Timeouts uploading to Hackage In-Reply-To: <49C7D968.9090800@web.de> References: <20090323144824.GA28604@whirlpool.galois.com> <20090323150006.1d17e6d5.Malcolm.Wallace@cs.york.ac.uk> <20090323150532.GC28604@whirlpool.galois.com> <20090323152635.GA3655@soi.city.ac.uk> <20090323154244.GA371@whirlpool.galois.com> <49C7D968.9090800@web.de> Message-ID: <20090323184929.GI371@whirlpool.galois.com> deduktionstheorem: > Don Stewart wrote: > > [...] > > > > Seems like no one is able to upload at the moment? > > I just uploaded heap-0.6.0 (Mon Mar 23 18:22:35 UTC 2009) and both check > and actual upload were quite quick! > A few packages have made it up now. From sfvisser at cs.uu.nl Mon Mar 23 15:59:13 2009 From: sfvisser at cs.uu.nl (Sebastiaan Visser) Date: Mon Mar 23 15:46:55 2009 Subject: Timeouts uploading to Hackage In-Reply-To: <20090323184929.GI371@whirlpool.galois.com> References: <20090323144824.GA28604@whirlpool.galois.com> <20090323150006.1d17e6d5.Malcolm.Wallace@cs.york.ac.uk> <20090323150532.GC28604@whirlpool.galois.com> <20090323152635.GA3655@soi.city.ac.uk> <20090323154244.GA371@whirlpool.galois.com> <49C7D968.9090800@web.de> <20090323184929.GI371@whirlpool.galois.com> Message-ID: <1D0BF887-5804-46F3-AC9D-88E51135F78D@cs.uu.nl> On Mar 23, 2009, at 7:49 PM, Don Stewart wrote: > deduktionstheorem: >> Don Stewart wrote: >>> [...] >>> >>> Seems like no one is able to upload at the moment? >> >> I just uploaded heap-0.6.0 (Mon Mar 23 18:22:35 UTC 2009) and both >> check >> and actual upload were quite quick! >> > > A few packages have made it up now. Mine have now made it up as well. Don't know what the problem was. Thanks. From iavor.diatchki at gmail.com Tue Mar 24 17:12:32 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Mar 24 17:00:07 2009 Subject: Replace SCC algorithm of containers Message-ID: <5ab17e790903241412i273588ajbfb8ddfc81272889@mail.gmail.com> Hello, Some time ago I implemented an algorithm that computes the strongly connected components of a graph that is considerably faster than the code in the containers package, at least for larger graphs. This has been available for a while in a separate package on hackage (GraphSCC). I propose that we merge the code into containers, and simply replace the relevant functions. Any objections? -Iavor From ganesh.sittampalam at credit-suisse.com Tue Mar 24 17:42:23 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Mar 24 17:30:40 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA965@ELON17P32001A.csfb.cs-group.com> References: <20090320164709.GA5568@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com><20090321164053.GA4478@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com><16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com><20090322151210.GA12995@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA965@ELON17P32001A.csfb.cs-group.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA976@ELON17P32001A.csfb.cs-group.com> Sittampalam, Ganesh wrote: > Ross Paterson wrote: >> On Sun, Mar 22, 2009 at 06:31:08AM -0000, Sittampalam, Ganesh wrote: >>> Essentially we have the choice of producing full compatibility by >>> keeping the separate type in mtl, in which case State from mtl is >>> not State from transformers, or partial compatibility by >>> re-exporting the transformers one. >> >> Yes, we must choose between full compatibility with mtl and full >> compatibility with transformers. A quick implementation of the >> former is >> >> http://code.haskell.org/~ross/mtl-compat/ >> >> The separate versions of State etc are present, but deprecated. > > Cool. I've been been playing around with regression testing hackage > following Duncan's blog post on the subject - I've got a baseline > test running now and will try your mtl-compat out next, I've tried this now. Various new failures, which I don't have time to investigate all of tonight, but the first one I looked at is in the 'cgi' package, and is because the Functor instances for ReaderT r m and WriterT w m now (correctly) depend on Functor m, whereas in mtl they depend on Monad m. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From iavor.diatchki at gmail.com Tue Mar 24 19:14:38 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Mar 24 19:02:12 2009 Subject: Fwd: transformers versus mtl In-Reply-To: <5ab17e790903241613s201b9ab6paf7aaab4f2a31ad1@mail.gmail.com> References: <20090320164709.GA5568@soi.city.ac.uk> <20090321164053.GA4478@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> <20090322151210.GA12995@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA965@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA976@ELON17P32001A.csfb.cs-group.com> <5ab17e790903241613s201b9ab6paf7aaab4f2a31ad1@mail.gmail.com> Message-ID: <5ab17e790903241614x5000eb5ch8a791491b1bb08b@mail.gmail.com> (Ganesh, sorry for the double post, I meant to send this to the list) Hello, On Tue, Mar 24, 2009 at 2:42 PM, Sittampalam, Ganesh wrote: > Sittampalam, Ganesh wrote: > ...the Functor instances for > ReaderT r m and WriterT w m now (correctly) depend on Functor m, > whereas in mtl they depend on Monad m. Does anyone ever use ReaderT and WriterT with a type that is not a monad (i.e., use them as functor transformers rather then monad transformers)? ?On the other hand, with the unfortunate lack of relation between Functor and Monad in Haskell, it seems these instances will not work if I try to transform a monad that does not have a functor instance. -Iavor From ross at soi.city.ac.uk Tue Mar 24 19:30:55 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Mar 24 19:18:31 2009 Subject: Fwd: transformers versus mtl In-Reply-To: <5ab17e790903241614x5000eb5ch8a791491b1bb08b@mail.gmail.com> References: <20090321164053.GA4478@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> <20090322151210.GA12995@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA965@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA976@ELON17P32001A.csfb.cs-group.com> <5ab17e790903241613s201b9ab6paf7aaab4f2a31ad1@mail.gmail.com> <5ab17e790903241614x5000eb5ch8a791491b1bb08b@mail.gmail.com> Message-ID: <20090324233055.GA7572@soi.city.ac.uk> On Tue, Mar 24, 2009 at 04:14:38PM -0700, Iavor Diatchki wrote: > On Tue, Mar 24, 2009 at 2:42 PM, Sittampalam, Ganesh > wrote: > > Sittampalam, Ganesh wrote: > > ...the Functor instances for > > ReaderT r m and WriterT w m now (correctly) depend on Functor m, > > whereas in mtl they depend on Monad m. > > Does anyone ever use ReaderT and WriterT with a type that is not a > monad (i.e., use them as functor transformers rather then monad > transformers)? On the other hand, with the unfortunate lack of > relation between Functor and Monad in Haskell, it seems these > instances will not work if I try to transform a monad that does not > have a functor instance. It's more that they're used polymorphically, and the constraint Monad m is now insufficient: Functor m is also needed. From ml at isaac.cedarswampstudios.org Tue Mar 24 19:39:04 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue Mar 24 19:26:52 2009 Subject: Fwd: transformers versus mtl In-Reply-To: <5ab17e790903241614x5000eb5ch8a791491b1bb08b@mail.gmail.com> References: <20090320164709.GA5568@soi.city.ac.uk> <5ab17e790903241613s201b9ab6paf7aaab4f2a31ad1@mail.gmail.com> <5ab17e790903241614x5000eb5ch8a791491b1bb08b@mail.gmail.com> Message-ID: <200903241939.09584.ml@isaac.cedarswampstudios.org> Iavor Diatchki wrote: > On Tue, Mar 24, 2009 at 2:42 PM, Sittampalam, Ganesh > > wrote: > > Sittampalam, Ganesh wrote: > > ...the Functor instances for > > ReaderT r m and WriterT w m now (correctly) depend on Functor m, > > whereas in mtl they depend on Monad m. > > ...?On the other hand, with the unfortunate lack of > relation between Functor and Monad in Haskell, it seems these > instances will not work if I try to transform a monad that does not > have a functor instance. well, if base monad `m` is not a Functor, then it seems decidedly odd to me for the transformed monad to become a Functor... the transformer would be doing more than you'd expect! But if you don't use (Functor (ReaderT r m)), only (Monad (ReaderT r m)), perhaps it works as well as could be expected? (Or maybe it doesn't work after all; then my logic here is useless) -Isaac From alexander.dunlap at gmail.com Tue Mar 24 20:36:26 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Tue Mar 24 20:24:01 2009 Subject: Fwd: transformers versus mtl In-Reply-To: <200903241939.09584.ml@isaac.cedarswampstudios.org> References: <20090320164709.GA5568@soi.city.ac.uk> <5ab17e790903241613s201b9ab6paf7aaab4f2a31ad1@mail.gmail.com> <5ab17e790903241614x5000eb5ch8a791491b1bb08b@mail.gmail.com> <200903241939.09584.ml@isaac.cedarswampstudios.org> Message-ID: <57526e770903241736y1e3d0702u759734683775d51c@mail.gmail.com> On Tue, Mar 24, 2009 at 4:39 PM, Isaac Dupree wrote: > Iavor Diatchki wrote: >> On Tue, Mar 24, 2009 at 2:42 PM, Sittampalam, Ganesh >> >> wrote: >> > Sittampalam, Ganesh wrote: >> > ...the Functor instances for >> > ReaderT r m and WriterT w m now (correctly) depend on Functor m, >> > whereas in mtl they depend on Monad m. >> >> ...?On the other hand, with the unfortunate lack of >> relation between Functor and Monad in Haskell, it seems these >> instances will not work if I try to transform a monad that does not >> have a functor instance. > > well, if base monad `m` is not a Functor, then it seems decidedly odd to me > for the transformed monad to become a Functor... the transformer would be > doing more than you'd expect! ?But if you don't use (Functor (ReaderT r m)), > only (Monad (ReaderT r m)), perhaps it works as well as could be expected? > (Or maybe it doesn't work after all; then my logic here is useless) > > -Isaac > I'm pretty sure all monads are functors. Alex From allbery at ece.cmu.edu Tue Mar 24 21:22:35 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Mar 24 21:10:27 2009 Subject: transformers versus mtl In-Reply-To: <57526e770903241736y1e3d0702u759734683775d51c@mail.gmail.com> References: <20090320164709.GA5568@soi.city.ac.uk> <5ab17e790903241613s201b9ab6paf7aaab4f2a31ad1@mail.gmail.com> <5ab17e790903241614x5000eb5ch8a791491b1bb08b@mail.gmail.com> <200903241939.09584.ml@isaac.cedarswampstudios.org> <57526e770903241736y1e3d0702u759734683775d51c@mail.gmail.com> Message-ID: <860E76AB-65E1-48AA-BC4D-FE9D90551A8F@ece.cmu.edu> On 2009 Mar 24, at 20:36, Alexander Dunlap wrote: > I'm pretty sure all monads are functors. All monads are functors, but IIRC not all Monads are Functors. But Monad includes a liftM which is the same as Functor's fmap (usually? something tickling me about possibly the list Monad?) so in fact you *could* synthesize a Functor from atop a Monad that isn't already a Functor. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20090324/a736a1dd/PGP.bin From aslatter at gmail.com Tue Mar 24 21:30:57 2009 From: aslatter at gmail.com (Antoine Latter) Date: Tue Mar 24 21:18:30 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA976@ELON17P32001A.csfb.cs-group.com> References: <20090320164709.GA5568@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> <20090321164053.GA4478@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> <20090322151210.GA12995@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA965@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA976@ELON17P32001A.csfb.cs-group.com> Message-ID: <694519c50903241830g6d6bf597l3d3d3d63f8241986@mail.gmail.com> On Tue, Mar 24, 2009 at 4:42 PM, Sittampalam, Ganesh wrote: > Sittampalam, Ganesh wrote: > > I've tried this now. Various new failures, which I don't have time > to investigate all of tonight, but the first one I looked at is in > the 'cgi' package, and is because the Functor instances for > ReaderT r m and WriterT w m now (correctly) depend on Functor m, > whereas in mtl they depend on Monad m. > As long as we're on the topic of class constraints, is there any reason that the Monad instance for ContT m has a class constraint on the type of 'm'? I'm pretty sure we can lose it, as well as the similar class constraint on the instance of MonadCont. That's one of the most important things about the (ContT m) monad to me - it's a monad transformer that doesn't hit the class dictionary of what it's wrapping around. Antoine From ross at soi.city.ac.uk Wed Mar 25 04:59:00 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Mar 25 04:46:32 2009 Subject: transformers versus mtl In-Reply-To: <694519c50903241830g6d6bf597l3d3d3d63f8241986@mail.gmail.com> References: <16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com> <20090321164053.GA4478@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com> <20090322151210.GA12995@soi.city.ac.uk> <16442B752A06A74AB4D9F9A5FF076E4B01ABA965@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA976@ELON17P32001A.csfb.cs-group.com> <694519c50903241830g6d6bf597l3d3d3d63f8241986@mail.gmail.com> Message-ID: <20090325085900.GA4079@soi.city.ac.uk> On Tue, Mar 24, 2009 at 08:30:57PM -0500, Antoine Latter wrote: > As long as we're on the topic of class constraints, is there any > reason that the Monad instance for ContT m has a class constraint on > the type of 'm'? I'm pretty sure we can lose it, as well as the > similar class constraint on the instance of MonadCont. I've now removed these constraints from the development versions of transformers, monads-fd and monads-tf. From manlio.perillo at gmail.com Wed Mar 25 17:54:37 2009 From: manlio.perillo at gmail.com (Manlio Perillo) Date: Wed Mar 25 17:42:10 2009 Subject: some comments about bytestring-show package Message-ID: <49CAA81D.70002@gmail.com> Hi. I have started to use the bytestring-show package, since I need to serialize a big data structure in a lazy bytestring. However I have noted some possible problems with the API: - sometime it is used the put prefix, other times the show prefix - the module Text.Show.ByteString, IMHO, should re-export the Put class from the Data.Binary.Put. Thanks to the author of the package. Manlio Perillo From ganesh.sittampalam at credit-suisse.com Sat Mar 28 06:58:18 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sat Mar 28 06:46:29 2009 Subject: transformers versus mtl In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA976@ELON17P32001A.csfb.cs-group.com> References: <20090320164709.GA5568@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA95D@ELON17P32001A.csfb.cs-group.com><20090321164053.GA4478@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA960@ELON17P32001A.csfb.cs-group.com><16442B752A06A74AB4D9F9A5FF076E4B01ABA962@ELON17P32001A.csfb.cs-group.com><20090322151210.GA12995@soi.city.ac.uk><16442B752A06A74AB4D9F9A5FF076E4B01ABA965@ELON17P32001A.csfb.cs-group.com> <16442B752A06A74AB4D9F9A5FF076E4B01ABA976@ELON17P32001A.csfb.cs-group.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA998@ELON17P32001A.csfb.cs-group.com> Sittampalam, Ganesh wrote: > Sittampalam, Ganesh wrote: >> Ross Paterson wrote: >>> On Sun, Mar 22, 2009 at 06:31:08AM -0000, Sittampalam, Ganesh wrote: >>>> Essentially we have the choice of producing full compatibility by >>>> keeping the separate type in mtl, in which case State from mtl is >>>> not State from transformers, or partial compatibility by >>>> re-exporting the transformers one. >>> >>> Yes, we must choose between full compatibility with mtl and full >>> compatibility with transformers. A quick implementation of the >>> former is >>> >>> http://code.haskell.org/~ross/mtl-compat/ >>> >>> The separate versions of State etc are present, but deprecated. >> >> Cool. I've been been playing around with regression testing hackage >> following Duncan's blog post on the subject - I've got a baseline >> test running now and will try your mtl-compat out next, > > I've tried this now. Various new failures, which I don't have time to > investigate all of tonight, but the first one I looked at is in the > 'cgi' package, and is because the Functor instances for ReaderT r m > and WriterT w m now (correctly) depend on Functor m, whereas in mtl > they depend on Monad m. Here's the list of failures - though it doesn't cover packages that weren't installable on my machine for some other reason like needing gtk2hs or a C library. blogination-0.5 Functor instances depending on Functor, instance collision Applicative/Alternative ErrorT category-extras-0.53.5 Functor instances depending on Functor cgi-3001.1.7.1 Functor instances depending on Functor encoding-0.5.1 instance collision: Monad Either logict-0.2.3 instance collision: Applicative Identity monad-param-0.0.2 Functor instances depending on Functor mueval-0.7.1 Functor instances depending on Functor xcb-types-0.5.1 instance collision: Applicative/Alternative ReaderT xmonad-contrib-0.8.1 instance collision: Error [a] and also packages that depend on the above directly or indirectly: bff, cflp,cgi-undecidable, fastcgi, gitit, kibro, xmonad-eval and if we go one step further and remove State etc (so they become type synonyms, repo here: http://urchin.earth.li/darcs/ganesh/mtl-compat ), the following extra failures: FileManip-0.3.2 Missing data constructor: State HAppS-Server-0.9.3 Missing data constructor: Reader HaLeX-1.1.1 Missing data constructor: State LambdaHack-0.1.20080413 Missing data constructor: State applicative-extras-0.1.4 instance Applicative (State a) which now (a) needs TypeSynonymInstances and (b) overlaps derive-0.1.4 instance Applicative (Writer a) which now (a) needs TypeSynonymInstances and (b) overlaps lambdabot-4.2.2.1 Missing data constructor: State open-witness-0.1.1 Missing data constructor: State random-fu-0.0.0.2 instance MonadRandom (State StdGen) - needs TypeSynonymInstances or rewrite with StateT yhccore-0.9.1 instance UniqueIdM (State a) - needs TypeSynonymInstances or rewrite with StateT and dependencies: FermatsLastMargin, HappSHelpers, HSHHelpers, HStringTemplateHelpers, bff, firstify, formlets, happstack-helpers, hugs2yc, ycextra So, thoughts on how to proceed? Personally I would be inclined to go the whole hog as there isn't that much breakage - the downside being that it'll be hard for any of these packages to be compatible with both old mtl and new mtl simultaneously, with the exception of "Functor instances depending on Functor" which can be solved by having both Functor and Monad in the constraints. I've started contacting the authors of the directly affected packages and asking them to add mtl<1.2 to their dependencies so that if we do go ahead with any change the disruption will be minimised. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== From johan.tibell at gmail.com Sat Mar 28 17:15:24 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat Mar 28 17:02:46 2009 Subject: Volunteering to take owner maintainer role for the network package Message-ID: <90889fe70903281415l37d56b01rc2f64392db632d79@mail.gmail.com> Hi, Since I'm making changes to the network library and pushing for new release Ian suggested that I take over the maintainer role for that package. Does anyone object to me taking over the maintainer role? Changes to the library will still be discussed on this mailing list of course. Note: There are other people (like the original authors) that know parts of the library better than me. I will defer questions I can't answer or changes I can't review to them. Cheers, Johan From kili at outback.escape.de Sun Mar 29 11:08:42 2009 From: kili at outback.escape.de (Matthias Kilian) Date: Sun Mar 29 10:56:23 2009 Subject: System.Posix.User: make get{Group,User}EntryFor* more portable Message-ID: <20090329150842.GA25577@petunia.outback.escape.de> Hi, some oddities let the user001 test of the unix package fail on getGroupEntryFor*. One reason is that sysconf(_SC_GETGR_R_SIZE_MAX) returns 1024 on OpenBSD, while getgr*_r(3) actually need a buffer of 1024 + 200 * sizeof(char*) bytes. Note that the grBufSize = 2048 workaround in User.hsc did not work on 64 bit machines with OpenBSD, even before the _SC_GETGR_R_SIZE_MAX sysconf had been introduced. Instead of fiddling with stupid numbers again, I just implemented the try / enlarge / try harder scheme mentioned for example at http://www.opengroup.org/onlinepubs/9699919799/functions/getgrgid.html And I did so for all four functions, just in case there are existing problems with other unices (OpenBSD only needs the getGroupEntryFor* fixes). My Haskell sucks badly, so if someone has a cleaner solution: feel free use it instead of my patch ;-) Ciao, Kili -------------- next part -------------- Sun Mar 29 16:42:52 CEST 2009 Matthias Kilian * Make get{Group,User}EntryBy{ID,Name} more portable. Retry with a larger buffer whenever getgrgid_r(3), getgrnam_r(3), getpwuid_r(3) or getpwnam_r(3) return ERANGE. Suggested in the examples sections of IEEE Std 1003.1-2008. While here, change the default for grBufSize back to 1024. New patches: [Make get{Group,User}EntryBy{ID,Name} more portable. Matthias Kilian **20090329144252 Ignore-this: 483362361add825012eac72d66e5b40b Retry with a larger buffer whenever getgrgid_r(3), getgrnam_r(3), getpwuid_r(3) or getpwnam_r(3) return ERANGE. Suggested in the examples sections of IEEE Std 1003.1-2008. While here, change the default for grBufSize back to 1024. ] { hunk ./System/Posix/User.hsc 170 #ifdef HAVE_GETGRGID_R getGroupEntryForID gid = do allocaBytes (#const sizeof(struct group)) $ \pgr -> - allocaBytes grBufSize $ \pbuf -> - alloca $ \ ppgr -> do - throwErrorIfNonZero_ "getGroupEntryForID" $ - c_getgrgid_r gid pgr pbuf (fromIntegral grBufSize) ppgr - throwErrnoIfNull "getGroupEntryForID" $ - peekElemOff ppgr 0 - unpackGroupEntry pgr + alloca $ \ ppgr -> do + throwErrorIfNonZero_ "getGroupEntryForID" $ + doubleAllocWhile isERANGE grBufSize $ \s b -> + c_getgrgid_r gid pgr b (fromIntegral s) ppgr + throwErrnoIfNull "getGroupEntryForID" $ + peekElemOff ppgr 0 + unpackGroupEntry pgr foreign import ccall unsafe "getgrgid_r" hunk ./System/Posix/User.hsc 193 #ifdef HAVE_GETGRNAM_R getGroupEntryForName name = do allocaBytes (#const sizeof(struct group)) $ \pgr -> - allocaBytes grBufSize $ \pbuf -> - alloca $ \ ppgr -> - withCString name $ \ pstr -> do - throwErrorIfNonZero_ "getGroupEntryForName" $ - c_getgrnam_r pstr pgr pbuf (fromIntegral grBufSize) ppgr - r <- peekElemOff ppgr 0 - when (r == nullPtr) $ - ioError $ flip ioeSetErrorString "no group name" - $ mkIOError doesNotExistErrorType - "getGroupEntryForName" - Nothing - (Just name) - unpackGroupEntry pgr + alloca $ \ ppgr -> + withCString name $ \ pstr -> do + throwErrorIfNonZero_ "getGroupEntryForName" $ + doubleAllocWhile isERANGE grBufSize $ \s b -> + c_getgrnam_r pstr pgr b (fromIntegral s) ppgr + r <- peekElemOff ppgr 0 + when (r == nullPtr) $ + ioError $ flip ioeSetErrorString "no group name" + $ mkIOError doesNotExistErrorType + "getGroupEntryForName" + Nothing + (Just name) + unpackGroupEntry pgr foreign import ccall unsafe "getgrnam_r" c_getgrnam_r :: CString -> Ptr CGroup -> CString hunk ./System/Posix/User.hsc 238 #if defined(HAVE_GETGRGID_R) || defined(HAVE_GETGRNAM_R) grBufSize :: Int #if defined(HAVE_SYSCONF) && defined(HAVE_SC_GETGR_R_SIZE_MAX) -grBufSize = sysconfWithDefault 2048 (#const _SC_GETGR_R_SIZE_MAX) +grBufSize = sysconfWithDefault 1024 (#const _SC_GETGR_R_SIZE_MAX) #else hunk ./System/Posix/User.hsc 240 -grBufSize = 2048 -- just assume some value (1024 is too small on OpenBSD) +grBufSize = 1024 #endif #endif hunk ./System/Posix/User.hsc 287 #ifdef HAVE_GETPWUID_R getUserEntryForID uid = do allocaBytes (#const sizeof(struct passwd)) $ \ppw -> - allocaBytes pwBufSize $ \pbuf -> - alloca $ \ pppw -> do - throwErrorIfNonZero_ "getUserEntryForID" $ - c_getpwuid_r uid ppw pbuf (fromIntegral pwBufSize) pppw - throwErrnoIfNull "getUserEntryForID" $ - peekElemOff pppw 0 - unpackUserEntry ppw + alloca $ \ pppw -> do + throwErrorIfNonZero_ "getUserEntryForID" $ + doubleAllocWhile isERANGE pwBufSize $ \s b -> + c_getpwuid_r uid ppw b (fromIntegral s) pppw + throwErrnoIfNull "getUserEntryForID" $ + peekElemOff pppw 0 + unpackUserEntry ppw foreign import ccall unsafe "getpwuid_r" c_getpwuid_r :: CUid -> Ptr CPasswd -> hunk ./System/Posix/User.hsc 317 #if HAVE_GETPWNAM_R getUserEntryForName name = do allocaBytes (#const sizeof(struct passwd)) $ \ppw -> - allocaBytes pwBufSize $ \pbuf -> - alloca $ \ pppw -> - withCString name $ \ pstr -> do - throwErrorIfNonZero_ "getUserEntryForName" $ - c_getpwnam_r pstr ppw pbuf (fromIntegral pwBufSize) pppw - r <- peekElemOff pppw 0 - when (r == nullPtr) $ - ioError $ flip ioeSetErrorString "no user name" - $ mkIOError doesNotExistErrorType - "getUserEntryForName" - Nothing - (Just name) - unpackUserEntry ppw + alloca $ \ pppw -> + withCString name $ \ pstr -> do + throwErrorIfNonZero_ "getUserEntryForName" $ + doubleAllocWhile isERANGE pwBufSize $ \s b -> + c_getpwnam_r pstr ppw b (fromIntegral s) pppw + r <- peekElemOff pppw 0 + when (r == nullPtr) $ + ioError $ flip ioeSetErrorString "no user name" + $ mkIOError doesNotExistErrorType + "getUserEntryForName" + Nothing + (Just name) + unpackUserEntry ppw foreign import ccall unsafe "getpwnam_r" c_getpwnam_r :: CString -> Ptr CPasswd hunk ./System/Posix/User.hsc 395 return $ if v == (-1) then def else v #endif +isERANGE :: Integral a => a -> Bool +isERANGE = (== eRANGE) . Errno . fromIntegral + +doubleAllocWhile :: (a -> Bool) -> Int -> (Int -> Ptr b -> IO a) -> IO a +doubleAllocWhile p s m = do + r <- allocaBytes s (m s) + if p r then doubleAllocWhile p (2 * s) m else return r + unpackUserEntry :: Ptr CPasswd -> IO UserEntry unpackUserEntry ptr = do name <- (#peek struct passwd, pw_name) ptr >>= peekCString } Context: [fix this test: we were overflowing the IO manager's pipe with too many signals Simon Marlow **20090310090916] [Add config.guess config.sub install-sh as extra-source-files Ian Lynagh **20090307161911] [Tweak an internal detail Ian Lynagh **20090304182836 We now use an EmptyDataDecl rather than recursive newtype as an argument to Ptr. As well as being prettier, this also avoids an infinite loop bug in haddock (trac #3066). ] [Remove an incorrect comment Ian Lynagh **20090304162531] [Remove some debugging CPP Ian Lynagh **20090226001636] [Rewrite of signal-handling. Simon Marlow **20090219100532 Ignore-this: 1579194c10020dc34af715c225a9f207 The API is the same (for now). The new implementation has the capability to define signal handlers that have access to the siginfo of the signal (#592), but this functionality is not exposed in this patch. #2451 is the ticket for the new API. The main purpose of bringing this in now is to fix race conditions in the old signal handling code (#2858). Later we can enable the new API in the HEAD. Implementation differences: - More of the signal-handling is moved into Haskell. We store the table of signal handlers in an MVar, rather than having a table of StablePtrs in the RTS. - In the threaded RTS, the siginfo of the signal is passed down the pipe to the IO manager thread, which manages the business of starting up new signal handler threads. In the non-threaded RTS, the siginfo of caught signals is stored in the RTS, and the scheduler starts new signal handler threads. ] [Don't put inline'd functions in HsUnix.h; fixes trac #2969 Ian Lynagh **20090211182906 If they are included into a C file which also has certain symbols defined, then the behaviour of the HsUnix.h functions can change (e.g. lstat can become the 32bit, rather than 64bit, version). ] [fix warnings Simon Marlow **20090203100254 Ignore-this: 2dd022ed50c3fa62b2d7839d780e959c ] [Add check for -lrt to get the shm* functions. Subst. in buildinfo Don Stewart **20090130113502 Ignore-this: d8e5f5bf086d9149e7b13b32bc6bd93a ] [SharedMem.hsc wasn't including HsUnixConfig.h, so no #defines were propagating Don Stewart **20090130113451 Ignore-this: 31548629fdfa469d80009a51883858e8 ] [Require Cabal version >= 1.6 Ian Lynagh **20090122011331] [Add "bug-reports" and "source-repository" info to the Cabal file Ian Lynagh **20090121182842 Also switched to the modern Cabal file format ] [generalise type of executeFile (#2948) Simon Marlow **20090114124726 Ignore-this: d8bb1f790d53ea4525d474a88cceaa91 ] [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] Patch bundle hash: b46b3e4da1a8e8cfbf0bd1542b40b384a08c8793 From duncan.coutts at worc.ox.ac.uk Tue Mar 31 05:55:08 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Mar 31 05:42:18 2009 Subject: Haskell Platform: status update and call for volunteers Message-ID: <1238493308.25888.1236.camel@localhost> All, We'd like to give you an update on the status of the Haskell Platform. Background ---------- For background on what the Haskell Platform is about see these slides: http://blog.well-typed.com/wp-content/uploads/2008/11/haskell-platform.pdf The wiki page also gives an overview and links to further resources: http://www.haskell.org/haskellwiki/Haskell_Platform Current status -------------- There are no more policy questions to resolve for the first release. It is a matter of getting things done. The first platform release will contain: * ghc-6.10.2 * the "extra libs" (exact list on the issue tracker wiki below) * haddock, happy and alex * the cabal command line tool and it's dependencies. The plan calls for binary installers for Windows and OSX, a generic source tarball for Unix, and native packages for distros. Currently however things are stalled because Don and I have been too busy to put serious time into the task of building installers. It is not fair for our time problems to hold everything up. Call for volunteers ------------------- We are calling for volunteers for an action group. We need volunteers to take charge of various platforms and to manage the overall release. We would like to release a beta at the upcoming Haskell Hackathon in Utrecht (April 17-19). However this will *only* happen if people volunteer to help build distributions for different platforms. In particular we need: * Release manager / coordinator * Website with downloads and release notes * Someone in charge of each platform: * Windows installer * OSX installer * Generic Unix source tarball * Distribution packages: debian, fedora, gentoo, arch, BSD* etc Don and I will be able to help coordinate things and point people in the direction of tasks that need doing. The person in charge of each platform is responsible for building appropriate native packages / installer and coordinating the effort to test that the stuff installs ok and works. If no one volunteers, we simply won't have an Haskell Platform release for that platform. Resources: * Meta-package: darcs get http://code.haskell.org/haskell-platform * Issue tracker: http://trac.haskell.org/haskell-platform/ * Mailing list: http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform Please join the mailing list and volunteer! In the medium term we want to organise things with two overlapping groups. A "doers" group and a "talkers" group. The "doers" group deals with actually building installers and packages and making releases. The "talkers" group is for making decisions (in consultation with the community in general) about which packages go into the platform and what standards to demand of them. We are looking for volunteers for the action group now. As we mentioned, for the first release there is nothing for the talkers to do, though there will be plenty to do for the second major release. Duncan and Don