From johan.tibell at gmail.com Tue Dec 1 02:19:36 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Dec 1 01:54:41 2009 Subject: [network] new tickets submission unavailable In-Reply-To: References: <90889fe70911300823h11c575b5o38c2236db1e91268@mail.gmail.com> <694519c50911300839v5725351cqfff1b6cecf820b98@mail.gmail.com> Message-ID: <90889fe70911302319s396537f2t89488602cbd0a6cc@mail.gmail.com> Hi, On Mon, Nov 30, 2009 at 6:34 PM, Valery V. Vorotyntsev wrote: > On Mon, Nov 30, 2009 at 6:39 PM, Antoine Latter wrote: >> My user (AntoineLatter) gets the following error when navigating to that URL: >> >>>>>>> >> Forbidden >> >> TICKET_CREATE privileges are required to perform this operation >> <<<<< > > +1 This is new. I'll file a ticket to community [at] haskell.org for it. Thanks, Johan From mietek at gmail.com Tue Dec 1 06:25:06 2009 From: mietek at gmail.com (=?UTF-8?Q?Mietek_B=C4=85k?=) Date: Tue Dec 1 06:00:15 2009 Subject: Guarantees regarding finalizers In-Reply-To: <4B13DA9C.2070204@gmail.com> References: <13dd2de20911260435q29619d0av4b12661dd8931478@mail.gmail.com> <13dd2de20911260441x7751680cwae75f7fee00fe8d6@mail.gmail.com> <4B13DA9C.2070204@gmail.com> Message-ID: <13dd2de20912010325n38f877a8m1db8fa26f7fb19b5@mail.gmail.com> > The docs are rather backward. ?Foreign.ForeignPtr finalizers are guaranteed > to run, Foreign.Concurrent finalizers are not. ?I'll fix the docs, thanks > for the report. Thanks for the reply. Unfortunately, I'm running into the following error message when trying to use a Foreign.ForeignPtr finalizer: "foo: error: a C finalizer called back into Haskell. This was previously allowed, but is disallowed in GHC 6.10.2 and later. To create finalizers that may call back into Haskll, use Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr." Is there a technical reason why the Foreign.Concurrent finalizers aren't guaranteed to run? Best regards, -- Mietek B?k From marlowsd at gmail.com Tue Dec 1 07:13:03 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Dec 1 06:48:14 2009 Subject: Guarantees regarding finalizers In-Reply-To: <13dd2de20912010325n38f877a8m1db8fa26f7fb19b5@mail.gmail.com> References: <13dd2de20911260435q29619d0av4b12661dd8931478@mail.gmail.com> <13dd2de20911260441x7751680cwae75f7fee00fe8d6@mail.gmail.com> <4B13DA9C.2070204@gmail.com> <13dd2de20912010325n38f877a8m1db8fa26f7fb19b5@mail.gmail.com> Message-ID: <4B15084F.4000400@gmail.com> On 01/12/2009 11:25, Mietek B?k wrote: >> The docs are rather backward. Foreign.ForeignPtr finalizers are guaranteed >> to run, Foreign.Concurrent finalizers are not. I'll fix the docs, thanks >> for the report. > > Thanks for the reply. Unfortunately, I'm running into the following > error message when trying to use a Foreign.ForeignPtr finalizer: > > "foo: error: a C finalizer called back into Haskell. > This was previously allowed, but is disallowed in GHC 6.10.2 and later. > To create finalizers that may call back into Haskll, use > Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr." > > Is there a technical reason why the Foreign.Concurrent finalizers > aren't guaranteed to run? It's hard to make it work reliably, and arguably finalizers shouldn't be used in this way [1]. Haskell finalizers are run in separate threads, but separate threads don't normally prevent the Haskell program from exiting, so there would be an inconsistency if we made a special case for finalizers. Another problem is that you often find you need to express dependencies between finalizers, but that is not supported (the finalizers all run concurrently), and even if it were supported, it would probably be necessary to run the GC repeatedly until we run out of finalizers. Cheers, Simon [1] "Destructors, Finalizers, and Synchronization", Boehm, Hans-J. http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html From duncan.coutts at googlemail.com Tue Dec 1 07:47:45 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Tue Dec 1 07:22:34 2009 Subject: MTL vs Transformers. Any status update? In-Reply-To: <20091130235027.GA2434@soi.city.ac.uk> References: <20091127081650.fd48e441.mle+hs@mega-nerd.com> <20091127003302.GA29911@soi.city.ac.uk> <1259426449.4896.74853.camel@localhost> <20091128165650.GA15637@soi.city.ac.uk> <1259499786.4896.79853.camel@localhost> <20091129133530.GA10045@soi.city.ac.uk> <1259521342.4896.81324.camel@localhost> <29bf512f0911291108o7404d83bg710bedca6189fbfe@mail.gmail.com> <1259524136.4896.81549.camel@localhost> <7fb8f82f0911291629t4f225b46ufb214331c0f5decc@mail.gmail.com> <20091130235027.GA2434@soi.city.ac.uk> Message-ID: <1259671665.4896.91555.camel@localhost> On Mon, 2009-11-30 at 23:50 +0000, Ross Paterson wrote: > I think the pedagogical issue can be handled in other ways, and that > making compatibility with the current mtl an overriding requirement > would be unduly constraining. In any case there would be no complete > compatibility, as transformers adds Applicative and Alternative instances, > and also changes the constraints on Functor instances. I'd advocate doing it the "best" way, whatever the experts agree that is. Then we can handle the transition using the tools and procedures available. The reason I suggest calling it mtl-2 is not for compatibility but to make it easier to explain to package authors what we recommend they do. Duncan From gracjanpolak at gmail.com Wed Dec 2 09:14:45 2009 From: gracjanpolak at gmail.com (Gracjan Polak) Date: Wed Dec 2 09:00:32 2009 Subject: HaXR, maintainer Message-ID: Hi libraries! There is a beautiful HaXR XML-RPC client and server library out there that I use in connection with BlogLiteratively. I needed to change HaXR a bit to support my language encoding (Polish). http://hackage.haskell.org/package/haxr If nobody else steps up I'd like to take maintainership of HaXR. I have preliminary encouragement from Sigbjorn Finne, the original author. So, let the patches flow to me! -- Gracjan From gracjanpolak at gmail.com Wed Dec 2 10:21:16 2009 From: gracjanpolak at gmail.com (Gracjan Polak) Date: Wed Dec 2 09:56:29 2009 Subject: HaXR, maintainer References: Message-ID: Gracjan Polak gmail.com> writes: > > ... Sigbjorn Finne, the original author. > that be Bjorn Bringert, sorry about the confusion. -- Gracjan From malcolm.wallace at cs.york.ac.uk Wed Dec 2 20:50:29 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Dec 2 20:25:26 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: <065.b13add13be386db792cfdd3e2a478791@localhost> References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> <065.b13add13be386db792cfdd3e2a478791@localhost> Message-ID: <948C28A4-E060-46D1-BDB7-9C24D19D927E@cs.york.ac.uk> > #3709: Data.Either.partitionEithers is not lazy enough > > This is a behavioural change, e.g.: > Main> case partitionEithers1 [Left 'a', error "Not me"] of (x : _, > _) -> x > Program error: Not me > Main> case partitionEithers2 [Left 'a', error "Not me"] of (x : _, > _) -> x > 'a' Yes, and isn't that the point of the bugfix? No non-bottoming program has changed, but fewer programs fail now. I find it hard to imagine that anyone could have been relying on getting a crash here. > Shouldn't it be discussed on the libraries list first? Possibly, although I believe we have never treated a change towards being more lazy as an API change before. Making something more strict usually provokes discussion, because it causes more programs to crash, but making things lazier is usually considered a bugfix. Copying to libraries@, to see if there are any objections. If there are, feel free to back out the patch. -> See http://hackage.haskell.org/trac/ghc/ticket/3709 Regards, Malcolm From greenrd at greenrd.org Wed Dec 2 00:27:46 2009 From: greenrd at greenrd.org (Robin Green) Date: Thu Dec 3 05:47:31 2009 Subject: Patches and forks for GHC 6.12 Message-ID: Some packages will need modifications to build or work with GHC 6.12 (in some cases, just modifications to the .cabal file). I've created this wiki page to track work people have done on that which hasn't yet been included into official packages or repositories: http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 Please add any ones you know of (or just email me and I'll add them for you). -- Robin From lemming at henning-thielemann.de Thu Dec 3 09:12:24 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Dec 3 08:47:51 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: <948C28A4-E060-46D1-BDB7-9C24D19D927E@cs.york.ac.uk> References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> <065.b13add13be386db792cfdd3e2a478791@localhost> <948C28A4-E060-46D1-BDB7-9C24D19D927E@cs.york.ac.uk> Message-ID: On Thu, 3 Dec 2009, Malcolm Wallace wrote: >> #3709: Data.Either.partitionEithers is not lazy enough >> >> This is a behavioural change, e.g.: >> Main> case partitionEithers1 [Left 'a', error "Not me"] of (x : _, _) -> x >> Program error: Not me >> Main> case partitionEithers2 [Left 'a', error "Not me"] of (x : _, _) -> x >> 'a' > > Yes, and isn't that the point of the bugfix? No non-bottoming program has > changed, but fewer programs fail now. I find it hard to imagine that anyone > could have been relying on getting a crash here. Making something more lazy can cause a memory leak. From marlowsd at gmail.com Thu Dec 3 10:37:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Dec 3 10:12:10 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> <065.b13add13be386db792cfdd3e2a478791@localhost> <948C28A4-E060-46D1-BDB7-9C24D19D927E@cs.york.ac.uk> Message-ID: <4B17DB27.9020306@gmail.com> On 03/12/2009 14:12, Henning Thielemann wrote: > > On Thu, 3 Dec 2009, Malcolm Wallace wrote: > >>> #3709: Data.Either.partitionEithers is not lazy enough >>> >>> This is a behavioural change, e.g.: >>> Main> case partitionEithers1 [Left 'a', error "Not me"] of (x : _, _) >>> -> x >>> Program error: Not me >>> Main> case partitionEithers2 [Left 'a', error "Not me"] of (x : _, _) >>> -> x >>> 'a' >> >> Yes, and isn't that the point of the bugfix? No non-bottoming program >> has changed, but fewer programs fail now. I find it hard to imagine >> that anyone could have been relying on getting a crash here. > > Making something more lazy can cause a memory leak. and a time leak, or a stack overflow. People might complain if we made foldl' more lazy :-) Cheers, Simon From malcolm.wallace at cs.york.ac.uk Thu Dec 3 20:19:10 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Dec 3 19:55:23 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: <4B17DB27.9020306@gmail.com> References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> <065.b13add13be386db792cfdd3e2a478791@localhost> <948C28A4-E060-46D1-BDB7-9C24D19D927E@cs.york.ac.uk> <4B17DB27.9020306@gmail.com> Message-ID: <37FB23B8-A533-4F3D-9E53-5501AA35B042@cs.york.ac.uk> >>> No non-bottoming program >>> has changed, but fewer programs fail now. I find it hard to imagine >>> that anyone could have been relying on getting a crash here. >> >> Making something more lazy can cause a memory leak. But in this case, leaving it strict would be responsible for a memory leak, whereas laziness removes the leak for some cases. In those cases where the lazy version still has a memory leak, the strict version also suffers from the same leak. > and a time leak, or a stack overflow. People might complain if we > made foldl' more lazy :-) I believe there is general agreement that Haskell library functions should be lazy by default. Where there is a compelling case for strictness, it is usually noted by changing the name, e.g. foldl vs foldl'. Where something has explicitly been strictified, of course making it lazy again would rightly provoke howls of protest. But where a function seems to be *un*intentionally too strict...? To come back to the specifics of partitionEithers, is anyone arguing that, in this case, the original over-strictness is either intentional, or useful? Regards, Malcolm From duncan.coutts at googlemail.com Fri Dec 4 12:22:05 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Dec 4 11:56:47 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: <37FB23B8-A533-4F3D-9E53-5501AA35B042@cs.york.ac.uk> References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> <065.b13add13be386db792cfdd3e2a478791@localhost> <948C28A4-E060-46D1-BDB7-9C24D19D927E@cs.york.ac.uk> <4B17DB27.9020306@gmail.com> <37FB23B8-A533-4F3D-9E53-5501AA35B042@cs.york.ac.uk> Message-ID: <1259947325.4778.727.camel@localhost> On Fri, 2009-12-04 at 01:19 +0000, Malcolm Wallace wrote: > >>> No non-bottoming program > >>> has changed, but fewer programs fail now. I find it hard to imagine > >>> that anyone could have been relying on getting a crash here. > >> > >> Making something more lazy can cause a memory leak. > To come back to the specifics of partitionEithers, is anyone arguing > that, in this case, the original over-strictness is either > intentional, or useful? I don't think anyone is complaining about this specific case. I think we agree that the general principle is to make things lazy except where there are compelling reasons to do otherwise. As another example, intersperse (and intercalate) could be made slightly more lazy with no loss of efficiency (indeed it looks like it could be an improvement): intersperse :: a -> [a] -> [a] intersperse _ [] = [] intersperse sep (x0:xs0) = x0 : go xs0 where go [] = [] go (x:xs) = sep : x : go xs vs the standard def: intersperse :: a -> [a] -> [a] intersperse sep [] = [] intersperse sep [x] = [x] intersperse sep (x:xs) = x : sep : intersperse sep xs intersperse '_' ('x' : undefined) = 'x' : undefined vs List.intersperse '_' ('x' : undefined) = undefined Duncan From nicolas.pouillard at gmail.com Fri Dec 4 16:01:11 2009 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Fri Dec 4 15:35:47 2009 Subject: [GHC] #3709: Data.Either.partitionEithers is not lazy enough In-Reply-To: <1259947325.4778.727.camel@localhost> References: <056.ddd6dbef542c6ca3bde6bd36bb5cb4f0@localhost> <065.b13add13be386db792cfdd3e2a478791@localhost> <948C28A4-E060-46D1-BDB7-9C24D19D927E@cs.york.ac.uk> <4B17DB27.9020306@gmail.com> <37FB23B8-A533-4F3D-9E53-5501AA35B042@cs.york.ac.uk> <1259947325.4778.727.camel@localhost> Message-ID: <1259960432-sup-8510@peray> Excerpts from Duncan Coutts's message of Fri Dec 04 18:22:05 +0100 2009: > On Fri, 2009-12-04 at 01:19 +0000, Malcolm Wallace wrote: > > >>> No non-bottoming program > > >>> has changed, but fewer programs fail now. I find it hard to imagine > > >>> that anyone could have been relying on getting a crash here. > > >> > > >> Making something more lazy can cause a memory leak. > > > To come back to the specifics of partitionEithers, is anyone arguing > > that, in this case, the original over-strictness is either > > intentional, or useful? > > I don't think anyone is complaining about this specific case. I think we > agree that the general principle is to make things lazy except where > there are compelling reasons to do otherwise. +1 (for a lazier partitionEithers, intersperse and intercalate) -- Nicolas Pouillard http://nicolaspouillard.fr From mauricio.antunes at gmail.com Wed Dec 9 15:52:41 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Wed Dec 9 15:27:18 2009 Subject: Checking dependencies with Distribution Message-ID: Hi, Can you help me understand how to check C library dependencies using Distribution.*? So far, reading Setup.hs from HDBC-mysql gave me a quick start. I believe what I need to do is to write a 'preConf' user hook. This preConf would probably mimic the behavior of autoconf macros provided by the library. Say, if that macro opens an include file and checks a string to confirm the version, that is what my preConf should do. But then I'm lost. Although my preConf probably doesn't need to add any information to the build process, I can't find how to actually break it if the proper version wasn't found, or how to emit a message saying "you need a newer version of library X". Thanks, Maur?cio From dominic at steinitz.org Thu Dec 10 03:29:43 2009 From: dominic at steinitz.org (Dominic Steinitz) Date: Thu Dec 10 03:04:28 2009 Subject: Checking dependencies with Distribution References: Message-ID: > Can you help me understand how to check C library dependencies > using Distribution.*? > > So far, reading Setup.hs from HDBC-mysql gave me a quick start. I > believe what I need to do is to write a 'preConf' user hook. > This may be of some use http://code.haskell.org/asn1/Setup.hs. I'm not sure if it's the best way of doing things (it almost certainly isn't) but there isn't a lot of documentation on this sort of thing. Regards, Dominic. From mauricio.antunes at gmail.com Thu Dec 10 05:30:25 2009 From: mauricio.antunes at gmail.com (=?ISO-8859-1?Q?Maur=ED=ADcio_CA?=) Date: Thu Dec 10 05:05:14 2009 Subject: Cabal, list of include files or directories Message-ID: Hi, I would like to check for a few include files, and read them, in my Setup file. However, the only structure where I can find info about include files seems to be BuildInfo, and this could only come from HookedBuildInfo in preConf and confHook. Both, however, give empty HookedBuildInfos. Thanks, Maur?cio From duncan.coutts at googlemail.com Fri Dec 11 12:17:50 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri Dec 11 11:52:08 2009 Subject: Advance warning to package authors of breakage with Cabal-1.8 In-Reply-To: <1259426248.4896.74838.camel@localhost> References: <1259426248.4896.74838.camel@localhost> Message-ID: <1260551870.9220.1813.camel@localhost> On Sat, 2009-11-28 at 16:37 +0000, Duncan Coutts wrote: > package authors, > > I'm preparing to release a new version of Cabal. This is the one that > will come with ghc-6.12. Another cause of breakage is due to a change in semantics of the treatment of dependencies of disabled components. Consider: Library [...] exposed-modules: [...] Happstack.Util.Testing, [...] -- The Happstack.Util.Testing module uses the HUnit package -- the library does not specify build-depends: HUnit -- on the other hand, the executable does, but it's disabled by default Executable happstack-util-tests Main-Is: Test.hs GHC-Options: -threaded Build-depends: HUnit hs-source-dirs: tests, src if flag(tests) Buildable: True Build-Depends: network else Buildable: False Now in Cabal-1.6 this builds, despite the fact that only the test program depends on HUnit and that test program is disabled. This is because Cabal used to take the dependencies of each component (exes, libs) and apply the union of them to all components. There are two changes in behaviour in Cabal-1.8, one is opt-in so that we don't break too many packages. The first is that each components dependencies are for that component alone. This is opt-in. You get the new behaviour if you use cabal-version: >=1.8. The other is that we omit dependencies of components that will not be built. This means we drag in fewer dependencies generally. However in this case it exposes the fact that the library actually needs a dependency that is only used by another component, and one that is disabled by default. On balance I think we don't want to make the second change opt-in, that the benefit of not dragging in the extra dependencies for most packages outweighs the couple packages that were relying on this corner case. I did build a large proportion of hackage and happstack-util-0.3.2 is the only one I found that is broken by this change. I expect the happstack maintainers can easily get a point release out. Duncan From johan.tibell at gmail.com Sun Dec 13 12:37:43 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun Dec 13 12:12:10 2009 Subject: [network] `setSocketOption' fails with `Linger' option In-Reply-To: References: Message-ID: <90889fe70912130937n4df4a7f4x9a1cf0ddf6e019b6@mail.gmail.com> Would you mind filing a ticket for this as well now when the trac instance is working? Thanks a lot! -- Johan On Mon, Nov 30, 2009 at 3:49 PM, Valery V. Vorotyntsev wrote: > See http://is.gd/57Ptu (Network.Socket.setSocketOption). > > `setSocketOption' uses FFI binding to setsockopt(2), named > `c_setsockopt'. > >> foreign import CALLCONV unsafe "setsockopt" >> ? c_setsockopt :: CInt -> CInt -> CInt -> Ptr CInt -> CInt -> IO CInt > > The binding treats OPTVAL (4th argument) as a pointer to `int'. This > is mostly fine but not when `SO_LINGER' option is being set. In the > latter case OPTVAL must be a pointer to `struct linger'. [1] > > ?[1] http://www.gnu.org/s/libc/manual/html_node/Socket_002dLevel-Options.html > > Haskell programs trying to set SO_LINGER socket option will > successfully compile but fail in runtime. > > ? ?$ runhaskell socket-linger.hs || echo X > ? ?$ runhaskell -DLINGER socket-linger.hs || echo X > ? ?socket-linger.hs: setSocketOption: invalid argument (Invalid argument) > ? ?X > > ? ?$ gcc -g -Wall -W -o /tmp/1 socket-linger.c && /tmp/1 || echo X > ? ?$ gcc -g -DLINGER_AS_INT -Wall -W -o /tmp/1 socket-linger.c && > /tmp/1 || echo X > ? ?setsockopt: Invalid argument > ? ?X > > (See attached files `socket-linger.c', `socket-linger.hs'.) > > The necessity of `SO_LINGER' option is controversial (see [2]). > I think it is better to comment the `Linger' constructor out of > Network/Socket.hsc. > > ?[2] http://www.developerweb.net/forum/archive/index.php/t-2982.html > > Cheers. > > -- > vvv > From valery.vv at gmail.com Sun Dec 13 16:10:10 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Sun Dec 13 15:44:17 2009 Subject: [network] getAddrInfo: invalid haddock (+ patch) In-Reply-To: <90889fe70912130932h2ef2b9c9p537cd9d266bc216d@mail.gmail.com> References: <90889fe70912130932h2ef2b9c9p537cd9d266bc216d@mail.gmail.com> Message-ID: Johan Tibell wrote: > Sorry for the long delay. The trac instance should be fixed now. It > would be great if you could try to add a new ticket. Done. http://trac.haskell.org/network/ticket/22 I could not attach the patch though: OSError: [Errno 13] Permission denied: '/srv/trac/network/attachments/ticket' Do you think it would be secure enough if we enable attaching files to tickets (for registered Trac accounts)? -----BEGIN BACKTRACE----- Traceback (most recent call last): File "/var/lib/python-support/python2.4/trac/web/main.py", line 387, in dispatch_request dispatcher.dispatch(req) File "/var/lib/python-support/python2.4/trac/web/main.py", line 237, in dispatch resp = chosen_handler.process_request(req) File "/var/lib/python-support/python2.4/trac/attachment.py", line 361, in process_request self._do_save(req, attachment) File "/var/lib/python-support/python2.4/trac/attachment.py", line 494, in _do_save attachment.insert(filename, upload.file, size) File "/var/lib/python-support/python2.4/trac/attachment.py", line 180, in insert os.makedirs(self.path) File "os.py", line 156, in makedirs makedirs(head, mode) File "os.py", line 159, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/srv/trac/network/attachments/ticket' -----END BACKTRACE----- Cheers. -- vvv From valery.vv at gmail.com Sun Dec 13 16:49:04 2009 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Sun Dec 13 16:23:11 2009 Subject: [network] `setSocketOption' fails with `Linger' option In-Reply-To: <90889fe70912130937n4df4a7f4x9a1cf0ddf6e019b6@mail.gmail.com> References: <90889fe70912130937n4df4a7f4x9a1cf0ddf6e019b6@mail.gmail.com> Message-ID: Johan Tibell wrote: > Would you mind filing a ticket for this as well now when the trac > instance is working? Sure thing. http://trac.haskell.org/network/ticket/23 -- vvv From johan.tibell at gmail.com Mon Dec 14 02:16:35 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Dec 14 01:51:00 2009 Subject: [network] `setSocketOption' fails with `Linger' option In-Reply-To: References: <90889fe70912130937n4df4a7f4x9a1cf0ddf6e019b6@mail.gmail.com> Message-ID: <90889fe70912132316n4ea6d5d3nc3e3cbc3526c0562@mail.gmail.com> On Sun, Dec 13, 2009 at 10:49 PM, Valery V. Vorotyntsev wrote: > Johan Tibell wrote: >> Would you mind filing a ticket for this as well now when the trac >> instance is working? > > Sure thing. > http://trac.haskell.org/network/ticket/23 Thanks! From gwern0 at gmail.com Mon Dec 14 11:06:13 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Mon Dec 14 10:40:20 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <200907171543.08914.g9ks157k@acme.softbase.org> References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> <200907171543.08914.g9ks157k@acme.softbase.org> Message-ID: On Fri, Jul 17, 2009 at 8:43 AM, Wolfgang Jeltsch wrote: > Am Sonntag, 12. Juli 2009 11:54 schrieb Nicolas Pouillard: >> Excerpts from Michael Snoyman's message of Sat Jul 11 22:03:49 +0200 2009: >> > I'm not opposed to using void instead of ignore. Out of curiosity, is >> > anyone interested in having the Functor version of void? I'm not sure I >> > see a reason to unnecessarily limit ourselves to Monads here. >> >> +1 to a functor version > > +1 > > The function could be used, for example, as a parser, and parsers are not > always monads. > >> What about 'discard'? > > Sounds good. > > Best wishes, > Wolfgang Approximately 5 months later, it seems no one has commented on it since. Too bad; it could've made it in in time for GHC 6.12. At this point I'd like to run another poll to see whether consensus has changed. If no one objects beyond what we've already seen, I'm going to submit a 'void :: f a -> f ()' patch as the most universal & general version, and hopefully it will be applied... You'll remember the last one wound up being: # Nothing - David Menendez - Henning Thielemann (?) - John Meachem (?) # Just ## Control.Monad.ignore :: m a -> m () - Isaac Dupree - Martijn van Steenbergen - Maur??cio - Michael Snoyman - Neil Mitchell ### Control.Monad.ignore:: f a -> f () - Edward Kmett ## Control.Monad.void m a -> m () (or void :: f a -> f ()) - Don Stewart - Iavor Diatchki - Jeff Wheeler - Johann Tibell - Malcolm Wallace - Michael Snoyman (as well) - Nicolas Pouillard - Stephan Friedrichs ## Control.Monad.discard :: f a -> f () - Nicolas Pouillard - Wolfgang Jeltsch -- gwern From deniz.a.m.dogan at gmail.com Mon Dec 14 11:21:57 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Mon Dec 14 10:56:22 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> <200907171543.08914.g9ks157k@acme.softbase.org> Message-ID: <7b501d5c0912140821o30eceac8j7a5b14385361fd25@mail.gmail.com> 2009/12/14 Gwern Branwen : > On Fri, Jul 17, 2009 at 8:43 AM, Wolfgang Jeltsch > wrote: >> Am Sonntag, 12. Juli 2009 11:54 schrieb Nicolas Pouillard: >>> Excerpts from Michael Snoyman's message of Sat Jul 11 22:03:49 +0200 2009: >>> > I'm not opposed to using void instead of ignore. Out of curiosity, is >>> > anyone interested in having the Functor version of void? I'm not sure I >>> > see a reason to unnecessarily limit ourselves to Monads here. >>> >>> +1 to a functor version >> >> +1 >> >> The function could be used, for example, as a parser, and parsers are not >> always monads. >> >>> What about 'discard'? >> >> Sounds good. >> >> Best wishes, >> Wolfgang > > Approximately 5 months later, it seems no one has commented on it > since. Too bad; it could've made it in in time for GHC 6.12. > > At this point I'd like to run another poll to see whether consensus > has changed. If no one objects beyond what we've already seen, I'm > going to submit a 'void :: f a -> f ()' patch as the most universal & > general version, and hopefully it will be applied... > > You'll remember the last one wound up being: > > # Nothing > - David Menendez > - Henning Thielemann (?) > - John Meachem (?) > > # Just > ## Control.Monad.ignore :: m a -> m () > - Isaac Dupree > - Martijn van Steenbergen > - Maur??cio > - Michael Snoyman > - Neil Mitchell > > ### Control.Monad.ignore:: ?f a -> f () > - Edward Kmett > > ## Control.Monad.void m a -> m () > (or void :: f a -> f ()) > > - Don Stewart > - Iavor Diatchki > - Jeff Wheeler > - Johann Tibell > - Malcolm Wallace > - Michael Snoyman (as well) > - Nicolas Pouillard > - Stephan Friedrichs > > ## Control.Monad.discard :: f a -> f () > - Nicolas Pouillard > - Wolfgang Jeltsch > > -- > gwern > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > If I may: discard++ -- Deniz Dogan From malcolm.wallace at cs.york.ac.uk Mon Dec 14 11:43:54 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Dec 14 11:17:59 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <7b501d5c0912140821o30eceac8j7a5b14385361fd25@mail.gmail.com> References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> <200907171543.08914.g9ks157k@acme.softbase.org> <7b501d5c0912140821o30eceac8j7a5b14385361fd25@mail.gmail.com> Message-ID: <697E82D1-E1F6-4446-8598-9B2C97C8875D@cs.york.ac.uk> >> ## Control.Monad.void m a -> m () >> (or void :: f a -> f ()) By the latter, I take it you mean void :: Functor f => f a -> f () void = fmap (const ()) thereby avoiding any premature restriction to Monad. I would be in favour of the generalisation (and of the name 'void'). >> ## Control.Monad.discard :: f a -> f () I vote against 'discard', mainly because I already use it frequently, as an infix operator discard :: Applicative f => f a -> f b -> f a It can be jolly useful to intersperse with the `apply` operator e.g. list item = empty `orElse` fmap (:) `apply` item `discard` satisfy ":" `apply` list Regards, Malcolm From qdunkan at gmail.com Mon Dec 14 13:23:11 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Dec 14 12:57:16 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <697E82D1-E1F6-4446-8598-9B2C97C8875D@cs.york.ac.uk> References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> <200907171543.08914.g9ks157k@acme.softbase.org> <7b501d5c0912140821o30eceac8j7a5b14385361fd25@mail.gmail.com> <697E82D1-E1F6-4446-8598-9B2C97C8875D@cs.york.ac.uk> Message-ID: <2518b95d0912141023t50662ce3o47ba49eb63908363@mail.gmail.com> Sorry, I didn't respond to the survey because I liked the idea, preferring the Functor versions of course, and I'm not fussy about the name. They'll all do for me. But if you want a vote, I'll jump on the void bandwagon just to make a deadlock less likely :) On Mon, Dec 14, 2009 at 8:43 AM, Malcolm Wallace wrote: > I vote against 'discard', mainly because I already use it frequently, as an > infix operator > > ? ?discard :: Applicative f => f a -> f b -> f a Isn't that (<*)? From malcolm.wallace at cs.york.ac.uk Mon Dec 14 14:03:35 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Dec 14 13:37:40 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: <2518b95d0912141023t50662ce3o47ba49eb63908363@mail.gmail.com> References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> <200907171543.08914.g9ks157k@acme.softbase.org> <7b501d5c0912140821o30eceac8j7a5b14385361fd25@mail.gmail.com> <697E82D1-E1F6-4446-8598-9B2C97C8875D@cs.york.ac.uk> <2518b95d0912141023t50662ce3o47ba49eb63908363@mail.gmail.com> Message-ID: > On Mon, Dec 14, 2009 at 8:43 AM, Malcolm Wallace > wrote: >> I vote against 'discard', mainly because I already use it >> frequently, as an >> infix operator >> >> discard :: Applicative f => f a -> f b -> f a > > Isn't that (<*)? Quite possibly. I find the chosen symbols for Applicative very difficult to remember though, and much prefer textual names. Regards, Malcolm From slyich at gmail.com Mon Dec 14 18:04:01 2009 From: slyich at gmail.com (Sergei Trofimovich) Date: Mon Dec 14 17:36:51 2009 Subject: darcs patch: fixed 'cabal sdist' Message-ID: <4b26c417.0f0db80a.561f.ffffa5d8@mx.google.com> Tue Dec 15 00:56:45 EET 2009 Sergei Trofimovich * fixed 'cabal sdist' It actually fixes './configure' regeneration for such distros, like gentoo, wich had to patch configure.ac and regenerate script toolchain. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1031 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20091214/385ec074/attachment.bin From slyich at gmail.com Wed Dec 16 16:37:45 2009 From: slyich at gmail.com (Sergei Trofimovich) Date: Wed Dec 16 16:10:28 2009 Subject: darcs patch: lower base requirement down to base-2 Message-ID: <4b2952de.100db80a.2658.3481@mx.google.com> Wed Dec 16 23:34:21 EET 2009 Sergei Trofimovich * lower base requirement down to base-2 At least ghc-6.6.1 is able to build it without problems. (package can be used in cabal-1.8, which is known to work on ghc-6.4+) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 2355 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20091216/481e96b8/attachment.bin From lemming at henning-thielemann.de Thu Dec 17 16:23:07 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Dec 17 15:57:02 2009 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> <200907171543.08914.g9ks157k@acme.softbase.org> Message-ID: On Mon, 14 Dec 2009, Gwern Branwen wrote: > You'll remember the last one wound up being: > > # Nothing > - David Menendez > - Henning Thielemann (?) > - John Meachem (?) What does it mean to be in category Nothing? I like the 'ignore' function, the name is not important for me and I prefer the Functor constraint. > # Just > ## Control.Monad.ignore :: m a -> m () > - Isaac Dupree > - Martijn van Steenbergen > - Maur??cio > - Michael Snoyman > - Neil Mitchell > > ### Control.Monad.ignore:: f a -> f () > - Edward Kmett > > ## Control.Monad.void m a -> m () > (or void :: f a -> f ()) > > - Don Stewart > - Iavor Diatchki > - Jeff Wheeler > - Johann Tibell > - Malcolm Wallace > - Michael Snoyman (as well) > - Nicolas Pouillard > - Stephan Friedrichs > > ## Control.Monad.discard :: f a -> f () > - Nicolas Pouillard > - Wolfgang Jeltsch From kyagrd at gmail.com Fri Dec 18 03:00:17 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Fri Dec 18 02:34:44 2009 Subject: First order formula parsers in Haskell (logic-TPTP and the one in Equinox) Message-ID: <4B2B3691.1090000@gmail.com> Dear Daniel Sch?ssler and Koen Classen, I've tried using both logic-TPTP and the parser in the Equinox theroem prover. I wanted to list issues I had when I tried using the parsers. logic-TPTP http://hackage.haskell.org/package/logic-TPTP is implemented with alex and happy, and it is very close to the specification to the TPTP syntax when you look at the happy source file. So, I think it works very nice for the people who wants to work on source to source transformation from TPTP syntax. It also comes with pretty printer and exporting to plain text TPTP syntax. It seems to be tested against the TPTP problem set and also random testing with formulae generated from One problem I had with logic-TPTP parser is about dealing with comments. The TPTP syntax specification states that comments can come in between any tokens. Howerver, logic-TPTP assumes that it is only at the top level, and not in between the formlua. As a result, it fails to parse such formulae, for example, the following one: fof(equality_reflexive, axiom, ! [X] # for all X : X=X # X is equal to itself ). This is valid according to the TPTP syntax specification, and all the theorem provers I know (at least the ones in the TPTP world) accepts such formulae. I believe that there is a reason Daniel's logic-TPTP keeps the comment since TPTP syntax specification also states that comment is not to be processed same as whitespace in case theorem prover implementation may use the content of the comment as extra information. However, it is just not correct to reject valid formulae which contains comments inside. For a quick fix, I would suggest either (1) provide another set of parsing functions parse' and parseFile' that ignores all comment (2) export the lexer so that the user can build such versions of parsing functions themselves which ignores all comment tokens. (Maybe, in the long run, the happy syntax definition should allow comments between tokens?) In contrast, the parser in Equinox http://www.cs.chalmers.se/~koen/folkung/ can parse the formulae above. It just seem to ignore all comments since Equinox internally does not make use of any comments. However, the problem for me about the current parser implementation in Equinox is that it transforms the syntax tree into some normalized form. For example the formula ! [X,Y] : ... seem to be parsed as ! [X] : ! [Y] : ... So, when one wants to maintain the original form during the transformation the parser in Equinox would not be desirable for him. -- Ahn, Ki Yung From marcus at gabriel.name Fri Dec 18 13:31:03 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Fri Dec 18 13:04:57 2009 Subject: parList implementation question Message-ID: <4B2BCA67.3040903@gabriel.name> Hello, In Control.Parallel.Strategies, parList is defined as parList strat [] = () parList strat (x:xs) = strat x `par` (parList strat xs) with parMap strat f xs = map f xs `using` parList strat. I have recently found that if I define forceParMap strat f xs = map f xs `using` forceParList strat where forceParList strat = foldl (\done -> (done>||) . strat) () then to date, forceParList via forceParMap gives faster results than parList via parMap. For example, in one experiment, parMap with parList run at 0.81 the time of the serial solution whereas forceParMap with forceParList run at 0.58 the time of the serial solution. This is to say, forceParList completed in 0.72 the time of parList. So, 1. Why is forceParList faster than parList? 2. Is this generic to the ghc runtime model or a particularity of the ghc implementation? Thanks in advance for the clarification, - Marcus From marcus at gabriel.name Sat Dec 19 04:26:20 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Sat Dec 19 04:00:11 2009 Subject: parList implementation question In-Reply-To: <6dbd4d000912181620y64207179rbe5148a48383015d@mail.gmail.com> References: <4B2BCA67.3040903@gabriel.name> <6dbd4d000912181620y64207179rbe5148a48383015d@mail.gmail.com> Message-ID: <4B2C9C3C.7090107@gabriel.name> Denis Bueno wrote: > On Fri, Dec 18, 2009 at 11:31, Marcus D. Gabriel wrote: >> than parList via parMap. For example, in one experiment, parMap >> with parList run at 0.81 the time of the serial solution whereas >> forceParMap with forceParList run at 0.58 the time of the serial >> solution. This is to say, forceParList completed in 0.72 the >> time of parList. So, > > I don't know your application, so it's hard to interpret your numbers. > > Are you sure those measurements are statistically significant? The particular example that I gave was a straightforward searchDepthFirst(1) algorithm. To parallelise it, I choose the initial, simple approach to determine the first list of successor nodes from an initial node and use parMap to apply the serial algorithm searchDepthFirst to this list and then reduce (concat) the list. With some RTS tuning and using a dedicated dual-core system, I was able for the problem above to reproduce the numbers that I cite above consistently to within about plus or minus a factor of 0.01. I have played with variations of this class of problem but not generally compared parList with forceParList across a broader class of problems. I like your question above. It helped me formulate this question: Is what I observed above significant or random? I hope it is not random. I guess the deeper question is how does one determine with confidence that parallised serial algorithm + startegy1 works for problem class1 and parallised serial algorithm + startegy2 works for problem class2 where both are better than the serial case for their respective class of problems across a given range of operating environments, e.g., -N2 to -N8 for 2 to 8 cores. - Marcus (1) "Algorithms, A Functional Programming Approach" by Fethi Rabhi and Guy Laplame. ISBN 0201-59604-0. From jnf at arcor.de Sat Dec 19 06:35:26 2009 From: jnf at arcor.de (jutaro) Date: Sat Dec 19 06:09:15 2009 Subject: Can the Haddock library expose more (then just reading interface files)? Message-ID: <26854367.post@talk.nabble.com> I've ported part of the Leksah metadata collection to use Haddock. But, now it comes, I have not created another backend, but would like to use Haddock as a library and call "createInterface" directly. So I need to change the exposed-modules section of haddock.cabal file to include: "Haddock.Types Haddock.Interface Haddock.Options" Would that be an acceptable patch for the general release, or do you feel it to be too unhygienic or something? The decision came because: 1. Leksah needs to write a binary format, so that the backend would have introduced new dependencies. (binary, binary-shared) 2. Leksah collects information from a variety of sources dynamically and needs a more flexible approach: - .hi files(installed packages without sources), - haddock (packages with sources that compiles) - parsing sources (projects you work on, which may for now not typecheck or compile). This can be better and more efficiently be implemented with a library approach. J?rgen -- View this message in context: http://old.nabble.com/Can-the-Haddock-library-expose-more-%28then-just-reading-interface-files%29--tp26854367p26854367.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From marcus at gabriel.name Sun Dec 20 08:57:52 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Sun Dec 20 08:31:40 2009 Subject: parList implementation question In-Reply-To: <4B2C9C3C.7090107@gabriel.name> References: <4B2BCA67.3040903@gabriel.name> <6dbd4d000912181620y64207179rbe5148a48383015d@mail.gmail.com> <4B2C9C3C.7090107@gabriel.name> Message-ID: <4B2E2D60.1060804@gabriel.name> Well, I finally put in place 6.12.1 and read the documentation for Control.Parallel.Strategies. All of my code for the application described below uses Done, demanding, sparking, (>|), and (>||) which are deprecated and which is what I used. Additionally, I need to understand Eval first to change my code. No point in responding until I determine what this means. Thanks nevertheless, - Marcus Marcus D. Gabriel wrote: > Denis Bueno wrote: >> On Fri, Dec 18, 2009 at 11:31, Marcus D. Gabriel wrote: >>> than parList via parMap. For example, in one experiment, parMap >>> with parList run at 0.81 the time of the serial solution whereas >>> forceParMap with forceParList run at 0.58 the time of the serial >>> solution. This is to say, forceParList completed in 0.72 the >>> time of parList. So, >> I don't know your application, so it's hard to interpret your numbers. >> >> Are you sure those measurements are statistically significant? > > The particular example that I gave was a straightforward > searchDepthFirst(1) algorithm. To parallelise it, I choose the > initial, simple approach to determine the first list of successor > nodes from an initial node and use parMap to apply the serial > algorithm searchDepthFirst to this list and then reduce (concat) > the list. > > With some RTS tuning and using a dedicated dual-core system, I was > able for the problem above to reproduce the numbers that I cite > above consistently to within about plus or minus a factor of 0.01. > > I have played with variations of this class of problem but not > generally compared parList with forceParList across a broader class > of problems. > > I like your question above. It helped me formulate this question: > > Is what I observed above significant or random? I hope it is not > random. > > I guess the deeper question is how does one determine with > confidence that > > parallised serial algorithm + startegy1 works for problem class1 > > and > > parallised serial algorithm + startegy2 works for problem class2 > > > where both are better than the serial case for their respective > class of problems across a given range of operating environments, > e.g., -N2 to -N8 for 2 to 8 cores. > > - Marcus > > (1) "Algorithms, A Functional Programming Approach" by Fethi Rabhi > and Guy Laplame. ISBN 0201-59604-0. -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:marcus@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75 From aslatter at gmail.com Sun Dec 20 21:10:52 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Dec 20 20:44:37 2009 Subject: MonadIO in mtl and transformers Message-ID: <694519c50912201810vabb8554hd08d5f2270f0aee4@mail.gmail.com> Folks, Would there be support for splitting off the MonadIO class from the mtl, and simple having Control.Monad.Trans re-export it? My proposed packaging of the functionality is here: http://community.haskell.org/~aslatter/code/monad-io Here's my problem which prompted this: I'm converting a library of mine over to the failure[1] package for returning errors, and the type on a lot of my functions is as follows: (MonadFailure MyFailureType m, MonadIO m) => Alpha -> Beta -> m Gamma The MonadFailure constraint is defined separate from its many instances, which would give the consumers of my library the choice between using the mtl or the transformers[2] library. Except that I also need a MonadIO constraint, for which I must pick from which package I choose it. Antoine [1] http://hackage.haskell.org/package/failure From michael at snoyman.com Mon Dec 21 00:03:09 2009 From: michael at snoyman.com (Michael Snoyman) Date: Sun Dec 20 23:36:55 2009 Subject: MonadIO in mtl and transformers In-Reply-To: <694519c50912201810vabb8554hd08d5f2270f0aee4@mail.gmail.com> References: <694519c50912201810vabb8554hd08d5f2270f0aee4@mail.gmail.com> Message-ID: <29bf512f0912202103iee845dcjab31affde086d077@mail.gmail.com> On Mon, Dec 21, 2009 at 4:10 AM, Antoine Latter wrote: > Folks, > > Would there be support for splitting off the MonadIO class from the > mtl, and simple having Control.Monad.Trans re-export it? > My proposed packaging of the functionality is here: > http://community.haskell.org/~aslatter/code/monad-io > > > Here's my problem which prompted this: > > I'm converting a library of mine over to the failure[1] package for > returning errors, and the type on a lot of my functions is as follows: > > (MonadFailure MyFailureType m, MonadIO m) => Alpha -> Beta -> m Gamma > > The MonadFailure constraint is defined separate from its many > instances, which would give the consumers of my library the choice > between using the mtl or the transformers[2] library. > > Except that I also need a MonadIO constraint, for which I must pick > from which package I choose it. > > Antoine > > [1] http://hackage.haskell.org/package/failure > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > +1, this is a great idea. I've had to purposely remove useful functions from safe-failure package due to this issue as well. I think we all agree that the best choice is to merge mtl and transformers, but since that discussion seems to have come to a stand-still, splitting off MonadIO and MonadTrans seems like a good second best. Of course, I won't complain if someone just fixes the mtl/transformers mess itself ;). Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091220/94f90095/attachment.html From twhitehead at gmail.com Mon Dec 21 00:38:25 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Dec 21 00:12:17 2009 Subject: Minor inefficiency in Data.Map and Data.Set? Message-ID: <200912210038.25647.twhitehead@gmail.com> I was looking at the Data.Map and Data.Set implementations and I think there is a slight inefficiency. Consider the Data.Map code {-------------------------------------------------------------------- [glue l r]: glues two trees together. Assumes that [l] and [r] are already balanced with respect to each other. --------------------------------------------------------------------} glue :: Map k a -> Map k a -> Map k a glue Tip r = r glue l Tip = l glue l r | size l > size r = let ((km,m),l') = deleteFindMax l in balance km m l' r | otherwise = let ((km,m),r') = deleteFindMin r in balance km m l r' The call to balance should not be needed as subtracting one item from the non- smaller of them cannot thrown them out of balance given they are already in balance with one another. The only way they could be made out of balance would be to subtract an item for smaller one. The replacement code is glue l r | sizeL > sizeR = let ((km,m),l') = deleteFindMax l in Bin sizeX km m l' r | otherwise = let ((km,m),r') = deleteFindMin r in Bin sizeX km m l r' where sizeL = size l sizeR = size r sizeX = sizeL + sizeR The Data.Set code is identical except for the key. Cheers! -Tyson From aslatter at gmail.com Mon Dec 21 00:47:39 2009 From: aslatter at gmail.com (Antoine Latter) Date: Mon Dec 21 00:21:23 2009 Subject: MonadIO in mtl and transformers In-Reply-To: <29bf512f0912202103iee845dcjab31affde086d077@mail.gmail.com> References: <694519c50912201810vabb8554hd08d5f2270f0aee4@mail.gmail.com> <29bf512f0912202103iee845dcjab31affde086d077@mail.gmail.com> Message-ID: <694519c50912202147u72d2de64yaf7364bfba6d43d2@mail.gmail.com> On Sun, Dec 20, 2009 at 11:03 PM, Michael Snoyman wrote: > > Of course, I won't complain if someone just fixes the mtl/transformers mess > itself ;). > Yes, that's the other valid solution. My request has been documented on GHC Trac in bug 3777: http://hackage.haskell.org/trac/ghc/ticket/3777 Antoine From michael at snoyman.com Mon Dec 21 01:27:56 2009 From: michael at snoyman.com (Michael Snoyman) Date: Mon Dec 21 01:01:41 2009 Subject: MonadIO in mtl and transformers In-Reply-To: <694519c50912202147u72d2de64yaf7364bfba6d43d2@mail.gmail.com> References: <694519c50912201810vabb8554hd08d5f2270f0aee4@mail.gmail.com> <29bf512f0912202103iee845dcjab31affde086d077@mail.gmail.com> <694519c50912202147u72d2de64yaf7364bfba6d43d2@mail.gmail.com> Message-ID: <29bf512f0912202227h45863776xef8e2d14a6be094d@mail.gmail.com> On Mon, Dec 21, 2009 at 7:47 AM, Antoine Latter wrote: > On Sun, Dec 20, 2009 at 11:03 PM, Michael Snoyman > wrote: > > > > Of course, I won't complain if someone just fixes the mtl/transformers > mess > > itself ;). > > > > Yes, that's the other valid solution. > > My request has been documented on GHC Trac in bug 3777: > http://hackage.haskell.org/trac/ghc/ticket/3777 > > Antoine > Is there any reason to export only MonadIO? MonadTrans seems like a good candidate for that split as well. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091221/2c2a1562/attachment.html From aslatter at gmail.com Mon Dec 21 01:42:56 2009 From: aslatter at gmail.com (Antoine Latter) Date: Mon Dec 21 01:16:40 2009 Subject: MonadIO in mtl and transformers In-Reply-To: <29bf512f0912202227h45863776xef8e2d14a6be094d@mail.gmail.com> References: <694519c50912201810vabb8554hd08d5f2270f0aee4@mail.gmail.com> <29bf512f0912202103iee845dcjab31affde086d077@mail.gmail.com> <694519c50912202147u72d2de64yaf7364bfba6d43d2@mail.gmail.com> <29bf512f0912202227h45863776xef8e2d14a6be094d@mail.gmail.com> Message-ID: <694519c50912202242r34eb0ce2wf5f5303cf42fbb9f@mail.gmail.com> On Mon, Dec 21, 2009 at 12:27 AM, Michael Snoyman wrote: > > > On Mon, Dec 21, 2009 at 7:47 AM, Antoine Latter wrote: >> >> On Sun, Dec 20, 2009 at 11:03 PM, Michael Snoyman >> wrote: >> > >> > Of course, I won't complain if someone just fixes the mtl/transformers >> > mess >> > itself ;). >> > >> >> Yes, that's the other valid solution. >> >> My request has been documented on GHC Trac in bug 3777: >> http://hackage.haskell.org/trac/ghc/ticket/3777 >> >> Antoine > > Is there any reason to export only MonadIO? MonadTrans seems like a good > candidate for that split as well. > > Michael > I guess I've never need the 'lift' function outside of code which used other bits of the mtl, so I did not export it. I'm struggling to come up with a concept which would unify a package containing both the MonadIO class and the MonadTrans class. The mtl made sense, as it contained shed-loads of other classes. Antoine From wren at community.haskell.org Mon Dec 21 05:09:27 2009 From: wren at community.haskell.org (wren ng thornton) Date: Mon Dec 21 04:37:23 2009 Subject: MonadIO in mtl and transformers In-Reply-To: <694519c50912202242r34eb0ce2wf5f5303cf42fbb9f@mail.gmail.com> References: <694519c50912201810vabb8554hd08d5f2270f0aee4@mail.gmail.com> <29bf512f0912202103iee845dcjab31affde086d077@mail.gmail.com> <694519c50912202147u72d2de64yaf7364bfba6d43d2@mail.gmail.com> <29bf512f0912202227h45863776xef8e2d14a6be094d@mail.gmail.com> <694519c50912202242r34eb0ce2wf5f5303cf42fbb9f@mail.gmail.com> Message-ID: <4B2F4957.7070303@community.haskell.org> Antoine Latter wrote: > Michael Snoyman wrote: >> Is there any reason to export only MonadIO? MonadTrans seems like a good >> candidate for that split as well. > > I guess I've never need the 'lift' function outside of code which used > other bits of the mtl, so I did not export it. > > I'm struggling to come up with a concept which would unify a package > containing both the MonadIO class and the MonadTrans class. The mtl > made sense, as it contained shed-loads of other classes. Maybe it'd be worth just rolling into base, instead of a separate package? Both MonadTrans and MonadIO seem as basic to me as MonadPlus. And I don't recall there ever being controversy about the design of either class. (Moving them to base may mess up folks using new base + old mtl ...but that seems fixable by forcing old+old or new+new.) -- Live well, ~wren From marlowsd at gmail.com Mon Dec 21 07:28:06 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Dec 21 07:02:15 2009 Subject: parList implementation question In-Reply-To: <4B2BCA67.3040903@gabriel.name> References: <4B2BCA67.3040903@gabriel.name> Message-ID: <4B2F69D6.10402@gmail.com> On 18/12/2009 18:31, Marcus D. Gabriel wrote: > Hello, > > In Control.Parallel.Strategies, parList is defined as > > parList strat [] = () > parList strat (x:xs) = strat x `par` (parList strat xs) > > with > > parMap strat f xs = map f xs `using` parList strat. > > I have recently found that if I define > > forceParMap strat f xs = map f xs `using` forceParList strat > > where > > forceParList strat = foldl (\done -> (done>||) . strat) () > > then to date, forceParList via forceParMap gives faster results > than parList via parMap. For example, in one experiment, parMap > with parList run at 0.81 the time of the serial solution whereas > forceParMap with forceParList run at 0.58 the time of the serial > solution. This is to say, forceParList completed in 0.72 the > time of parList. So, > > 1. Why is forceParList faster than parList? > 2. Is this generic to the ghc runtime model or a particularity > of the ghc implementation? I'm not sure. Your forceParList looks equivalent to parList, unless I'm misreading it. I recommend trying out the new parallel package, here: http://hackage.haskell.org/package/parallel which has a new implementation of Strategies. The version of parList you quoted above has a space leak problem which may be affecting your results. Cheers, Simon From marcus at gabriel.name Mon Dec 21 11:43:43 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Mon Dec 21 11:17:29 2009 Subject: parList implementation question In-Reply-To: <4B2F69D6.10402@gmail.com> References: <4B2BCA67.3040903@gabriel.name> <4B2F69D6.10402@gmail.com> Message-ID: <4B2FA5BF.9000309@gabriel.name> Thank you Simon, I will obtain parallel 2.2.0.1 and work with it. Actually, the reason I asked my question was because I did not think forceParList should yield better performance than parList (unless it was becasue of the foldl?). I read the release notes for 6.12.1 about the work done on the ghc parallel framework and did just a little bit more experimenting. You might find this of interesting. ghc 6.10.4 with parallel 1.1.0.1 (as reported before): Serial algorithm: 1.00 unit of time Parallel algorithm with parList: 0.81 units of time Parallel algorithm with forceParList: 0.58 units of time ghc 6.12.1 with parallel 1.1.0.1: Serial algorithm: 1.00 unit of time Parallel algorithm with parList: 0.58 units of time* Parallel algorithm with forceParList: 0.58 units of time* Interesting. Well, from my perspective, 6.12.1 is certainly an improvement here. Cheers, - Marcus Simon Marlow wrote: > > On 18/12/2009 18:31, Marcus D. Gabriel wrote: >> Hello, >> >> In Control.Parallel.Strategies, parList is defined as >> >> parList strat [] = () >> parList strat (x:xs) = strat x `par` (parList strat xs) >> >> with >> >> parMap strat f xs = map f xs `using` parList strat. >> >> I have recently found that if I define >> >> forceParMap strat f xs = map f xs `using` forceParList strat >> >> where >> >> forceParList strat = foldl (\done -> (done>||) . strat) () >> >> then to date, forceParList via forceParMap gives faster results >> than parList via parMap. For example, in one experiment, parMap >> with parList run at 0.81 the time of the serial solution whereas >> forceParMap with forceParList run at 0.58 the time of the serial >> solution. This is to say, forceParList completed in 0.72 the >> time of parList. So, >> >> 1. Why is forceParList faster than parList? >> 2. Is this generic to the ghc runtime model or a particularity >> of the ghc implementation? > > I'm not sure. Your forceParList looks equivalent to parList, unless > I'm misreading it. > > I recommend trying out the new parallel package, here: > > http://hackage.haskell.org/package/parallel > > which has a new implementation of Strategies. The version of parList > you quoted above has a space leak problem which may be affecting your > results. > > Cheers, > Simon From marcus at gabriel.name Mon Dec 21 13:01:18 2009 From: marcus at gabriel.name (Marcus D. Gabriel) Date: Mon Dec 21 12:35:06 2009 Subject: parList implementation question In-Reply-To: <4B2FA5BF.9000309@gabriel.name> References: <4B2BCA67.3040903@gabriel.name> <4B2F69D6.10402@gmail.com> <4B2FA5BF.9000309@gabriel.name> Message-ID: <4B2FB7EE.2010202@gabriel.name> Thanks Simon. Parallel 2.2.0.1 was straight forward. I just replaced rnf with rdeepseq and my original use of parMap worked like a charm giving twice the performance for my dual-core system as I original expected and now find. Thanks, - Marcus Marcus D. Gabriel wrote: > Thank you Simon, I will obtain parallel 2.2.0.1 and work with it. > Actually, the reason I asked my question was because I did not > think forceParList should yield better performance than parList > (unless it was becasue of the foldl?). > > I read the release notes for 6.12.1 about the work done on the ghc > parallel framework and did just a little bit more experimenting. > You might find this of interesting. > > ghc 6.10.4 with parallel 1.1.0.1 (as reported before): > Serial algorithm: 1.00 unit of time > Parallel algorithm with parList: 0.81 units of time > Parallel algorithm with forceParList: 0.58 units of time > > ghc 6.12.1 with parallel 1.1.0.1: > Serial algorithm: 1.00 unit of time > Parallel algorithm with parList: 0.58 units of time* > Parallel algorithm with forceParList: 0.58 units of time* > > Interesting. Well, from my perspective, 6.12.1 is certainly an > improvement here. > > Cheers, > - Marcus > > Simon Marlow wrote: > >> On 18/12/2009 18:31, Marcus D. Gabriel wrote: >> >>> Hello, >>> >>> In Control.Parallel.Strategies, parList is defined as >>> >>> parList strat [] = () >>> parList strat (x:xs) = strat x `par` (parList strat xs) >>> >>> with >>> >>> parMap strat f xs = map f xs `using` parList strat. >>> >>> I have recently found that if I define >>> >>> forceParMap strat f xs = map f xs `using` forceParList strat >>> >>> where >>> >>> forceParList strat = foldl (\done -> (done>||) . strat) () >>> >>> then to date, forceParList via forceParMap gives faster results >>> than parList via parMap. For example, in one experiment, parMap >>> with parList run at 0.81 the time of the serial solution whereas >>> forceParMap with forceParList run at 0.58 the time of the serial >>> solution. This is to say, forceParList completed in 0.72 the >>> time of parList. So, >>> >>> 1. Why is forceParList faster than parList? >>> 2. Is this generic to the ghc runtime model or a particularity >>> of the ghc implementation? >>> >> I'm not sure. Your forceParList looks equivalent to parList, unless >> I'm misreading it. >> >> I recommend trying out the new parallel package, here: >> >> http://hackage.haskell.org/package/parallel >> >> which has a new implementation of Strategies. The version of parList >> you quoted above has a space leak problem which may be affecting your >> results. >> >> Cheers, >> Simon >> From michael at snoyman.com Mon Dec 21 14:41:07 2009 From: michael at snoyman.com (Michael Snoyman) Date: Mon Dec 21 14:14:51 2009 Subject: MonadIO in mtl and transformers In-Reply-To: <4B2F4957.7070303@community.haskell.org> References: <694519c50912201810vabb8554hd08d5f2270f0aee4@mail.gmail.com> <29bf512f0912202103iee845dcjab31affde086d077@mail.gmail.com> <694519c50912202147u72d2de64yaf7364bfba6d43d2@mail.gmail.com> <29bf512f0912202227h45863776xef8e2d14a6be094d@mail.gmail.com> <694519c50912202242r34eb0ce2wf5f5303cf42fbb9f@mail.gmail.com> <4B2F4957.7070303@community.haskell.org> Message-ID: <29bf512f0912211141y7b1a00f6s3640063ca9790997@mail.gmail.com> On Mon, Dec 21, 2009 at 12:09 PM, wren ng thornton < wren@community.haskell.org> wrote: > Antoine Latter wrote: > >> Michael Snoyman wrote: >> >>> Is there any reason to export only MonadIO? MonadTrans seems like a good >>> candidate for that split as well. >>> >> >> I guess I've never need the 'lift' function outside of code which used >> other bits of the mtl, so I did not export it. >> >> I'm struggling to come up with a concept which would unify a package >> containing both the MonadIO class and the MonadTrans class. The mtl >> made sense, as it contained shed-loads of other classes. >> > > Maybe it'd be worth just rolling into base, instead of a separate package? > Both MonadTrans and MonadIO seem as basic to me as MonadPlus. And I don't > recall there ever being controversy about the design of either class. > (Moving them to base may mess up folks using new base + old mtl ...but that > seems fixable by forcing old+old or new+new.) > > -- > Live well, > ~wren > > By the way, does anyone have an update on where we stand wrt the mtl/transformers situation? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091221/4fd7f70a/attachment.html From aslatter at gmail.com Mon Dec 21 22:33:05 2009 From: aslatter at gmail.com (Antoine Latter) Date: Mon Dec 21 22:06:50 2009 Subject: ANN: Happstack 0.4.1 In-Reply-To: <54342.1261377119@n-heptane.com> References: <54342.1261377119@n-heptane.com> Message-ID: <694519c50912211933p257746abgca00c46a443264ac@mail.gmail.com> On Mon, Dec 21, 2009 at 6:31 AM, wrote: > Hello, > > That sort of missing symbol error at link time is often (but not always) a > sign that some libraries got recompiled but not others. So there are > references to the old symbol names hanging around. > > I would try to ghc-pkg unregister syb-with-class and everything that depends > on it, and then try cabal install happstack again. > I'm pretty well stumped at this point. I've cleared off everything and gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives me the same symbol not defined error in Happstack.Data.Xml.Base. But here's the spooky part, if I run it by hand like so: ghc --make src/Happstack/Data/Xml/Base.hs src/Happstack/Data/Default.hs src/Happstack/Data/ DeriveAll.hs src/Happstack/Data/Normalize.hs src/Happstack/Data/Migrate.hs after resolving issues due to CPP not being run, everything runs to completion, no errors. Also, the list of things we're pulling in during the template-haskell execution is much smaller (see bellow). Has anyone seen this, where template-haskell behaves different when run from cabal-install (or Setup.hs) than from ghc --make (or ghci)? >>>>> 2 of 5] Compiling Happstack.Data.Migrate ( src/Happstack/Data/Migrate.hs, src/Happstack/Data/Migrate.o ) [3 of 5] Compiling Happstack.Data.Default ( src/Happstack/Data/Default.hs, src/Happstack/Data/Default.o ) [4 of 5] Compiling Happstack.Data.DeriveAll ( src/Happstack/Data/DeriveAll.hs, src/Happstack/Data/DeriveAll.o ) [5 of 5] Compiling Happstack.Data.Xml.Base ( src/Happstack/Data/Xml/Base.hs, src/Happstack/Data/Xml/Base.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Loading package array-0.3.0.0 ... linking ... done. Loading package bytestring-0.9.1.5 ... linking ... done. Loading package containers-0.3.0.0 ... linking ... done. Loading package pretty-1.0.1.1 ... linking ... done. Loading package syb-0.1.0.2 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-with-class-0.6.1 ... linking ... done. mkUsageInfo: internal name? Element{tc a4av} <<<<< That was the successful build, using ghc --make. The error for te failing build is quoted bellow. Antoine > > > > On Sun 12/20/2009 2:06 AM , Antoine Latter aslatter@gmail.com sent: > > 2009/12/19 Jeremy Shaw : >> Happstack 0.4.1 STABLE is now available. > > At some point I was able to get happstack to build on GHC 6.12, but now I > can't. > > I'm getting errors in happstack-data, specifically it looks like > errors when I'm running TemplateHaskell during compile-time: > >>>>>> > [ 7 of 16] Compiling Happstack.Data.Xml.Base ( > src/Happstack/Data/Xml/Base.hs, dist/build/Happstack/Data/Xml/Base.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package array-0.3.0.0 ... linking ... done. > Loading package bytestring-0.9.1.5 ... linking ... done. > Loading package containers-0.3.0.0 ... linking ... done. > Loading package pretty-1.0.1.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package syb-with-class-0.6.1 ... linking ... done. > Loading package HUnit-1.2.2.1 ... linking ... done. > Loading package syb-0.1.0.2 ... linking ... done. > Loading package base-3.0.3.2 ... linking ... done. > Loading package old-locale-1.0.0.2 ... linking ... done. > Loading package time-1.1.4 ... linking ... done. > Loading package random-1.0.0.2 ... linking ... done. > Loading package QuickCheck-1.2.0.0 ... linking ... done. > Loading package extensible-exceptions-0.1.1.1 ... linking ... done. > Loading package mtl-1.1.0.2 ... linking ... done. > Loading package old-time-1.0.0.3 ... linking ... done. > Loading package parsec-2.1.0.1 ... linking ... done. > Loading package hsemail-1.3 ... linking ... done. > Loading package network-2.2.1.5 ... linking ... done. > Loading package SMTPClient-1.0.1 ... linking ... done. > Loading package filepath-1.1.0.3 ... linking ... done. > Loading package unix-2.4.0.0 ... linking ... done. > Loading package directory-1.0.1.0 ... linking ... done. > Loading package process-1.0.1.2 ... linking ... done. > Loading package hslogger-1.0.7 ... linking ... done. > Loading package deepseq-1.1.0.0 ... linking ... done. > Loading package parallel-2.2.0.1 ... linking ... done. > Loading package strict-concurrency-0.2.2 ... linking ... done. > Loading package unix-compat-0.1.2.1 ... linking ... done. > Loading package happstack-util-0.4.1 ... linking ... done. > Loading package binary-0.5.0.2 ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package HaXml-1.13.3 ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > ghc: > unknown symbol > `_sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure' > <<<<< > > If you check the load-list, we are loading syb-with-class. > > This is on Mac OS X 10.6 on a 64-bit intel chip, if that makes any > difference. > > Has anyone seen anything like this? Is it likely I've screwed up my > GHC install somehow? > > Antoine > > -- > > You received this message because you are subscribed to the Google Groups > "HAppS" group. > To post to this group, send email to happs@googlegroups.com. > To unsubscribe from this group, send email to > happs+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/happs?hl=en. > > > > From david.waern at gmail.com Tue Dec 22 13:13:02 2009 From: david.waern at gmail.com (David Waern) Date: Tue Dec 22 12:46:43 2009 Subject: Can the Haddock library expose more (then just reading interface files)? In-Reply-To: <26854367.post@talk.nabble.com> References: <26854367.post@talk.nabble.com> Message-ID: 2009/12/19 jutaro : > > I've ported part of the Leksah metadata collection to use Haddock. > But, now it comes, I have not created another backend, but would like to use > Haddock as a > library and call "createInterface" directly. > So I need to change the exposed-modules section of haddock.cabal file to > include: > "Haddock.Types Haddock.Interface Haddock.Options" > Would that be an acceptable patch for the general release, or do you feel it > to be too unhygienic or something? There has been some discussion about introducing a full-information format that haddock can produce that tools can read. It's not something anyone is working on at the moment, though. So while waiting for something like that, we could try to work something out. Exporting more of Haddock to the outside is a possibility. It would be interesting to know which parts of the Interface structure that you're after. David From michael at snoyman.com Tue Dec 22 15:15:01 2009 From: michael at snoyman.com (Michael Snoyman) Date: Tue Dec 22 14:48:44 2009 Subject: containers + cabal-install 0.8.0 issues? Message-ID: <29bf512f0912221215j817fc50y5e14af0e4745b67@mail.gmail.com> When trying to compile containers-0.2.0.1 with cabal-install 0.8.0, I get the following: Data/IntMap.hs:182:7: Could not find module `Data.Data': It is a member of the hidden package `base'. Perhaps you need to add `base' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. This does not occur when I install using the Setup.hs included with containers. Also, if I put a version range on base in containers.cabal (I tried >= 4 && < 5), it also works just fine. Any chance of getting a containers-0.2.0.2 released with a version range on base? Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20091222/1f453172/attachment-0001.html From ashley at semantic.org Wed Dec 23 03:45:02 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Dec 23 03:19:06 2009 Subject: ANN: time-extras 1.1.4 Message-ID: time-extras 1.1.4 contains Data instances for types defined in time-1.1.4. They are in a separate package because they require RankNTypes, which is not Haskell 2010. Get it from Hackage. http://hackage.haskell.org/package/time-extras -- Ashley Yakeley From slyich at gmail.com Wed Dec 23 14:24:59 2009 From: slyich at gmail.com (Sergei Trofimovich) Date: Wed Dec 23 13:57:26 2009 Subject: darcs patch: fixed 'cabal sdist' Message-ID: <4b326e46.100db80a.1d68.0454@mx.google.com> Tue Dec 15 00:56:45 EET 2009 Sergei Trofimovich * fixed 'cabal sdist' It actually fixes './configure' regeneration for such distros, like gentoo, wich had to patch configure.ac and regenerate script toolchain. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1031 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20091223/f120cfb3/attachment.bin From slyich at gmail.com Wed Dec 23 14:25:50 2009 From: slyich at gmail.com (Sergei Trofimovich) Date: Wed Dec 23 13:58:11 2009 Subject: darcs patch: lower base requirement down to base-2 Message-ID: <4b326e72.0e0db80a.4ed7.0830@mx.google.com> Wed Dec 16 23:34:21 EET 2009 Sergei Trofimovich * lower base requirement down to base-2 At least ghc-6.6.1 is able to build it without problems. (package can be used in cabal-1.8, which is known to work on ghc-6.4+) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 2355 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20091223/f1aef43c/attachment.bin From ndmitchell at gmail.com Wed Dec 23 16:31:21 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Dec 23 16:04:58 2009 Subject: Minor inefficiency in Data.Map and Data.Set? In-Reply-To: <200912210038.25647.twhitehead@gmail.com> References: <200912210038.25647.twhitehead@gmail.com> Message-ID: <404396ef0912231331u2fdbb330tdd18c81220732a0c@mail.gmail.com> Hi Tyson, Whenever I see the word inefficiency, I look for the benchmark that proves it :-) Have you benchmarked these two alternatives? If you can show that there is a measurable difference I'm sure someone will sit up and take note. Personally, I know nothing about the code involved, so you'd need to find someone who did to check your optimisation is valid (if it makes things go faster) Thanks, Neil On Mon, Dec 21, 2009 at 5:38 AM, Tyson Whitehead wrote: > I was looking at the Data.Map and Data.Set implementations and I think there > is a slight inefficiency. ?Consider the Data.Map code > > {-------------------------------------------------------------------- > ?[glue l r]: glues two trees together. > ?Assumes that [l] and [r] are already balanced with respect to each other. > --------------------------------------------------------------------} > glue :: Map k a -> Map k a -> Map k a > glue Tip r = r > glue l Tip = l > glue l r > ?| size l > size r = let ((km,m),l') = deleteFindMax l in balance km m l' r > ?| otherwise ? ? ? = let ((km,m),r') = deleteFindMin r in balance km m l r' > > The call to balance should not be needed as subtracting one item from the non- > smaller of them cannot thrown them out of balance given they are already in > balance with one another. ?The only way they could be made out of balance > would be to subtract an item for smaller one. ?The replacement code is > > glue l r > ?| sizeL > sizeR = let ((km,m),l') = deleteFindMax l in Bin sizeX km m l' r > ?| otherwise ? ? = let ((km,m),r') = deleteFindMin r in Bin sizeX km m l r' > ?where > ? ?sizeL = size l > ? ?sizeR = size r > ? ?sizeX = sizeL + sizeR > > The Data.Set code is identical except for the key. > > Cheers! ?-Tyson > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From ekmett at gmail.com Wed Dec 23 21:23:26 2009 From: ekmett at gmail.com (Edward Kmett) Date: Wed Dec 23 20:57:02 2009 Subject: Minor inefficiency in Data.Map and Data.Set? In-Reply-To: <404396ef0912231331u2fdbb330tdd18c81220732a0c@mail.gmail.com> References: <200912210038.25647.twhitehead@gmail.com> <404396ef0912231331u2fdbb330tdd18c81220732a0c@mail.gmail.com> Message-ID: <7fb8f82f0912231823k422317e6w96b7a52d1fdc1af7@mail.gmail.com> On Wed, Dec 23, 2009 at 4:31 PM, Neil Mitchell wrote: > Hi Tyson, > > Whenever I see the word inefficiency, I look for the benchmark that > proves it :-) > Hey Neil, I've spent quite a bit of time poring over the code in question trying to eke out performance when I was looking at ways to get it to perform nicely for unboxed data structures, so I'll try to serve as an independent set of eyes. Have you benchmarked these two alternatives? If you can show that there is a measurable difference I'm sure someone will sit up and take note. Personally, I know nothing about the code involved, so you'd need to find someone who did to check your optimisation is valid I'll vouch for the validity of the code change. Basically his code avoids trying to do the top level rotation when gluing 2 trees that are already within 1 level of each other together -- the invariant to be able to call 'glue'. Its a good point, and it checks out as correct that the call to balance is superfluous. I even quickchecked about a hundred thousand trees to make sure that the behavior doesn't change, but you can get there by programmatic transformation to satisfy for more rigorous among us: A 'sufficiently smart compiler' could spot that if it inlines balance in both locations, then CSE's the comparison between sizes, that the case for the comparison between sizes has already been done, then it could simplify the balance cases to just construct the Bin without rebalancing, and another CSE would then do the rest of the transformation, but it seems like a needlessly complex path, and while I haven't gone through the resulting STG output to see if it is actually occurring with optimizations enabled on the containers library, I'm somewhat dubious, given the number of phases that would have to happen in just the right order for this to be the case. More interestingly, if you start playing around with variants on these modules, like the one I was working on that unboxed the key/values using some fancy view machinery, the compiler would have to work ridiculously hard to spot the correct invariants across the inlining of both the call and the particular view, so I've already applied this patch to unboxed-containers in my working repository. I think that relying on the compiler to get that right seems a lot less straightforward than just fixing the algorithm to do the right amount of work. Considering that it is true to the style of the rest of the code in those modules to be explicit about what work is actually necessary and where by calling special case rebalancing combinators only when appropriate. (if it makes things go faster. As for benchmarks, frankly it'll vanish in the noise, the worst case is a few of extra stack frames getting constructed, a redundant addition, and some unnecessary comparisons in balance once per operation, and not at each level of the tree. I do support patching it just for correctness though. Glue gets called internally across a very wide array of operations, and in some sense the Data.Map/Data.Set code has become the de facto reference implementation for how to implement trees of bounded balance, so it'd be nice to have them be correct. -Edward Kmett > > Thanks, Neil > > On Mon, Dec 21, 2009 at 5:38 AM, Tyson Whitehead > wrote: > > I was looking at the Data.Map and Data.Set implementations and I think > there > > is a slight inefficiency. Consider the Data.Map code > > > > {-------------------------------------------------------------------- > > [glue l r]: glues two trees together. > > Assumes that [l] and [r] are already balanced with respect to each > other. > > --------------------------------------------------------------------} > > glue :: Map k a -> Map k a -> Map k a > > glue Tip r = r > > glue l Tip = l > > glue l r > > | size l > size r = let ((km,m),l') = deleteFindMax l in balance km m l' > r > > | otherwise = let ((km,m),r') = deleteFindMin r in balance km m l > r' > > > > The call to balance should not be needed as subtracting one item from the > non- > > smaller of them cannot thrown them out of balance given they are already > in > > balance with one another. The only way they could be made out of balance > > would be to subtract an item for smaller one. The replacement code is > > > > glue l r > > | sizeL > sizeR = let ((km,m),l') = deleteFindMax l in Bin sizeX km m l' > r > > | otherwise = let ((km,m),r') = deleteFindMin r in Bin sizeX km m l > r' > > where > > sizeL = size l > > sizeR = size r > > sizeX = sizeL + sizeR > > > > The Data.Set code is identical except for the key. > > > > Cheers! -Tyson > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > 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/20091223/e94ad923/attachment-0001.html From gwern0 at gmail.com Wed Dec 23 21:47:53 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Dec 23 21:21:29 2009 Subject: Replacing Data.List.sort Message-ID: Thought I'd mention http://hackage.haskell.org/trac/ghc/ticket/2143 as being in libraries@ bailiwick. It's been a while since http://neilmitchell.blogspot.com/2008/03/sorting-at-speed.html and http://haskell.org/pipermail/haskell-cafe/2008-March/thread.html#40164 but I hope with some Criterion benchmarks, the case for replacing the current GHC Data.List.sort with the YHC Data.List.sort becomes a no-brainer. (If people want to improve the Criterion benchmark and run it themselves to verify that YHC is always faster, that'd be great also!) -- gwern From gwern0 at gmail.com Fri Dec 25 10:35:43 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Fri Dec 25 10:09:15 2009 Subject: Adding Network.URI.escape Message-ID: Network.URI.escapeURIString is pretty much always used to make a String a URL or a part of a URL. The existing definition http://www.haskell.org/ghc/docs/6.10.4/html/libraries/network/Network-URI.html#v%3AescapeURIString forces one to do extra work by having to specify a `Char -> Bool`. More than a few packages & libraries simply define an 'escape' function `escapeURIString isAllowedInURI` (either inline or as a named function). This sort of repetition is unfortunate. The name 'escape' is commonly used to express exactly that functionality: http://holumbus.fh-wedel.de/hayoo/hayoo.html#0:escape What would people say to adding such a function? -- gwern -------------- next part -------------- A non-text attachment was scrubbed... Name: escape Type: application/octet-stream Size: 5243 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20091225/154d5f83/escape.obj From GK at ninebynine.org Fri Dec 25 16:19:09 2009 From: GK at ninebynine.org (Graham Klyne) Date: Fri Dec 25 15:52:49 2009 Subject: Adding Network.URI.escape In-Reply-To: References: Message-ID: <4B352C4D.2080603@ninebynine.org> Gwern Branwen wrote: > Network.URI.escapeURIString is pretty much always used to make a > String a URL or a part of a URL. > > The existing definition > http://www.haskell.org/ghc/docs/6.10.4/html/libraries/network/Network-URI.html#v%3AescapeURIString > forces one to do extra work by having to specify a `Char -> Bool`. > > More than a few packages & libraries simply define an 'escape' > function `escapeURIString isAllowedInURI` (either inline or as a named > function). This sort of repetition is unfortunate. Hmmm... I think that's not strictly correct - it should be 'escapeURIString isUnescapedInURI'. The form used above would leave literal '%' characters unescaped. > The name 'escape' is commonly used to express exactly that > functionality: http://holumbus.fh-wedel.de/hayoo/hayoo.html#0:escape > > What would people say to adding such a function? The reason that the 'escapeURIString' always takes the Char -> Bool function is that the rules for escaping can very between URI schemes, and between components within a single URI. For example, a literal '/' or '?' appearing within a path segment in an http: URI would need to be escaped, but that's not included by the common case of 'escapeURIString isUnescapedInURI'. The 'isAllowedInURI' function, IIRC, is a kind of least-common-denominator function that causes non-URI characters to be escaped so that the resulting string is at least syntactically valid according to RFC3986. But in some cases (i.e. for some schemes) this may not be enough - see RFC 3986, section 2.1 ("A percent-encoding mechanism is used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component" -- http://www.apps.ietf.org/rfc/rfc3986.html#sec-2.1 ); see also section 2.4. So, while one could define an additional function as you suggest, I'm not sure it is necessarily wise, because having the explicit function to designate characters to be escaped does at least draw attention to exactly which characters would be escaped in the context of use. But OTOH, if implementations tend to use 'escapeURIString isAllowedInURI' as you say, maybe this just creates an opportunity for additional errors. URI escaping is, to some extent, a necessarily messy and error-prone business - it's really hard to define a generic escaping mechanism that neatly covers all eventualities, because of the multiple stages of interpretation that can take place when actually using a URI. #g From duncan.coutts at googlemail.com Sun Dec 27 12:42:17 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Sun Dec 27 12:15:45 2009 Subject: Default install locations on Windows Message-ID: <1261935737.9220.105620.camel@localhost> All, For Cabal packages our default install locations on Windows are a bit of a mess. Firstly we do global installs by default. This used to make sense on Windows XP when everyone had admin permissions. It no longer makes sense for Vista or Windows 7. See this recent horror story from a new user: http://haskell.org/pipermail/haskell-cafe/2009-December/071310.html I've talked for a while about switching the default to per-user installs on Windows: http://hackage.haskell.org/trac/hackage/ticket/465 Now I'm not a regular Windows user so I would like some expert advice from Windows Haskell hackers. Specifically, are the default locations and layout for per-user installs OK? A related problem is that historically we tried to fudge things so that packages could be mostly relocatable by default. This is because Windows tends to make greater use of relocatable packages (giving users a choice of location at install time). There is a problem with relocatable packages that depend on libraries that contain data files: http://hackage.haskell.org/trac/hackage/ticket/466 My proposed solution for this is to not do anything special about data files for windows and use the same directory layout as on Unix. That is, change: datadir = case buildOS of Windows | hasLibs -> windowsProgramFilesDir "Haskell" | otherwise -> "$prefix" _other -> "$prefix" "share", to datadir = case buildOS of Windows -> "$prefix" _other -> "$prefix" "share", BTW, why do we not want the "share" subdir? It means currently we end up with a per-package directory at the top level containing the data files for that package. So then the per-user install locations on Windows 7 would be: prefix: C:\Users\${USER}\AppData\Roaming\cabal bindir: $prefix\bin libdir: $prefix libsubdir: $pkgid\$compiler libexecdir: $prefix\$pkgid datadir: $prefix datasubdir: $pkgid docdir: $prefix\doc\$pkgid htmldir: $docdir\html haddockdir: $htmldir Then separately I think we need explicit support for constructing prefix independent packages which could check for these issues. eg: cabal configure --prefix-independent Duncan From ndmitchell at gmail.com Sun Dec 27 13:24:32 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Dec 27 12:57:57 2009 Subject: Minor inefficiency in Data.Map and Data.Set? In-Reply-To: <7fb8f82f0912231823k422317e6w96b7a52d1fdc1af7@mail.gmail.com> References: <200912210038.25647.twhitehead@gmail.com> <404396ef0912231331u2fdbb330tdd18c81220732a0c@mail.gmail.com> <7fb8f82f0912231823k422317e6w96b7a52d1fdc1af7@mail.gmail.com> Message-ID: <404396ef0912271024i3e7183fakc6d4f7c88671e68f@mail.gmail.com> Hi, Sounds like we should apply then - unless anyone has a really good reason why not to. The code should be simple and correct, and we shouldn't ever rely on things like CSE. Thanks, Neil 2009/12/24 Edward Kmett : > On Wed, Dec 23, 2009 at 4:31 PM, Neil Mitchell??wrote: >> >> Hi Tyson, >> >> Whenever I see the word inefficiency, I look for the benchmark that >> proves it :-) > > Hey Neil, > I've spent quite a bit of time poring over the code in question trying to eke out performance when I was looking at ways to get it to perform nicely for unboxed data structures, so I'll try to serve as an independent set of eyes. >> >> Have you benchmarked these two alternatives? If you can show that >> >> there is a measurable difference I'm sure someone will sit up and take >> >> note. Personally, I know nothing about the code involved, so you'd >> >> need to find someone who did to check your optimisation is valid > > I'll vouch for the validity of the code change.?Basically his code avoids trying to do the top level rotation when gluing 2 trees that are already within 1 level of each other together -- the invariant to be able to call 'glue'. Its a good point, and it checks out as correct that the call to balance is superfluous. I even quickchecked about a hundred thousand trees to make sure that the behavior doesn't change, but you can get there by programmatic transformation to satisfy for more rigorous among us: > A 'sufficiently smart compiler' could spot that if it inlines balance in both locations, then CSE's the comparison between sizes, that the case for the comparison between sizes has already been done, then it could simplify the balance cases to just construct the Bin without rebalancing, and another CSE would then do the rest of the transformation, but it seems like a needlessly complex path, and while I haven't gone through the resulting STG output to see if it is actually occurring with optimizations enabled on the containers library, I'm somewhat dubious, given the number of phases that would have to happen in just the right order for this to be the case. > More interestingly, if you start playing around with variants on these modules, like the one I was working on that unboxed the key/values using some fancy view machinery, the compiler would have to work ridiculously hard to spot the correct invariants across the inlining of both the call and the particular view, so I've already applied this patch to unboxed-containers in my working repository. > I think that relying on the compiler to get that right seems a lot less straightforward than just fixing the algorithm to do the right amount of work. Considering that it is true to the style of the rest of the code in those modules to be explicit about what work is actually necessary and where by calling special case rebalancing combinators only when appropriate. >> >> (if?it makes things go faster. > > As for benchmarks, frankly it'll vanish in the noise, the worst case is a few of extra stack frames getting constructed, a redundant addition, and some unnecessary comparisons in balance once per operation, and not at each level of the tree.?I do support patching it just for correctness though. > Glue gets called internally across a very wide array of operations, and in some sense the Data.Map/Data.Set code has become the de facto reference implementation for how to implement trees of bounded balance, so it'd be nice to have them be correct. > -Edward Kmett >> >> >> Thanks, Neil >> >> On Mon, Dec 21, 2009 at 5:38 AM, Tyson Whitehead wrote: >> > I was looking at the Data.Map and Data.Set implementations and I think there >> > is a slight inefficiency. ?Consider the Data.Map code >> > >> > {-------------------------------------------------------------------- >> > ?[glue l r]: glues two trees together. >> > ?Assumes that [l] and [r] are already balanced with respect to each other. >> > --------------------------------------------------------------------} >> > glue :: Map k a -> Map k a -> Map k a >> > glue Tip r = r >> > glue l Tip = l >> > glue l r >> > ?| size l > size r = let ((km,m),l') = deleteFindMax l in balance km m l' r >> > ?| otherwise ? ? ? = let ((km,m),r') = deleteFindMin r in balance km m l r' >> > >> > The call to balance should not be needed as subtracting one item from the non- >> > smaller of them cannot thrown them out of balance given they are already in >> > balance with one another. ?The only way they could be made out of balance >> > would be to subtract an item for smaller one. ?The replacement code is >> > >> > glue l r >> > ?| sizeL > sizeR = let ((km,m),l') = deleteFindMax l in Bin sizeX km m l' r >> > ?| otherwise ? ? = let ((km,m),r') = deleteFindMin r in Bin sizeX km m l r' >> > ?where >> > ? ?sizeL = size l >> > ? ?sizeR = size r >> > ? ?sizeX = sizeL + sizeR >> > >> > The Data.Set code is identical except for the key. >> > >> > Cheers! ?-Tyson >> > _______________________________________________ >> > Libraries mailing list >> > Libraries@haskell.org >> > http://www.haskell.org/mailman/listinfo/libraries >> > >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > From gale at sefer.org Sun Dec 27 16:43:16 2009 From: gale at sefer.org (Yitzchak Gale) Date: Sun Dec 27 16:17:00 2009 Subject: ANN: time-extras 1.1.4 In-Reply-To: References: Message-ID: <2608b8a80912271343s43320175l35d46efae15ae97c@mail.gmail.com> On Wed, Dec 23, 2009 at 10:45 AM, Ashley Yakeley wrote: > time-extras 1.1.4 contains Data instances for types defined in time-1.1.4. > They are in a separate package because they require RankNTypes, which is not > Haskell 2010. Nice! It may be a bit late, but in my opinion you might consider changing the package name for future versions. Time is fundamental, ubiquitous, and yet quite complex. There are innumerable ways in which the time package is likely to be extended. Personally, I almost never use syb. Data instances are probably the last thing I would expect to find in a package called "time-extras". So to me this seems like a rather peculiar way to use up such a generic name. Thanks, Yitz From ashley at semantic.org Sun Dec 27 17:02:17 2009 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Dec 27 16:35:52 2009 Subject: ANN: time-extras 1.1.4 In-Reply-To: <2608b8a80912271343s43320175l35d46efae15ae97c@mail.gmail.com> References: <2608b8a80912271343s43320175l35d46efae15ae97c@mail.gmail.com> Message-ID: <1261951337.18677.4.camel@glastonbury> On Sun, 2009-12-27 at 23:43 +0200, Yitzchak Gale wrote: > It may be a bit late, but in my opinion you might consider changing the > package name for future versions. Time is fundamental, ubiquitous, > and yet quite complex. There are innumerable ways in which the time > package is likely to be extended. Personally, I almost never use syb. > Data instances are probably the last thing I would expect to find in > a package called "time-extras". So to me this seems like a rather > peculiar way to use up such a generic name. It really means "stuff that ought to be in time, but can't be due to language compatibility reasons". The time-extras package should probably be in the Haskell Platform, and it may eventually get merged into the time package. -- Ashley Yakeley From lennart at augustsson.net Mon Dec 28 07:57:32 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Dec 28 07:30:55 2009 Subject: ANN: time-extras 1.1.4 In-Reply-To: <2608b8a80912271343s43320175l35d46efae15ae97c@mail.gmail.com> References: <2608b8a80912271343s43320175l35d46efae15ae97c@mail.gmail.com> Message-ID: Data instances are not just there for syb. There are needed for many kinds of generic programming. For instance, the generic JSON serializer uses Data, and it's nice to be able to serialize even time related things. Another example (which I use a lot) is Uniplate. I see Typeable and Data as a way to provide a certain amount of reflection, and I think they should be derived wherever possible. Using them is a different matter; I think they should be used sparingly. But when you need them, they are very useful. -- Lennart On Sun, Dec 27, 2009 at 9:43 PM, Yitzchak Gale wrote: > On Wed, Dec 23, 2009 at 10:45 AM, Ashley Yakeley wrote: >> time-extras 1.1.4 contains Data instances for types defined in time-1.1.4. >> They are in a separate package because they require RankNTypes, which is not >> Haskell 2010. > > Nice! > > It may be a bit late, but in my opinion you might consider changing the > package name for future versions. Time is fundamental, ubiquitous, > and yet quite complex. There are innumerable ways in which the time > package is likely to be extended. Personally, I almost never use syb. > Data instances are probably the last thing I would expect to find in > a package called "time-extras". So to me this seems like a rather > peculiar way to use up such a generic name. > > Thanks, > Yitz > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From gale at sefer.org Mon Dec 28 08:08:33 2009 From: gale at sefer.org (Yitzchak Gale) Date: Mon Dec 28 07:41:57 2009 Subject: ANN: time-extras 1.1.4 In-Reply-To: References: <2608b8a80912271343s43320175l35d46efae15ae97c@mail.gmail.com> Message-ID: <2608b8a80912280508k20cf0fabm247555555ac2c762@mail.gmail.com> I wrote: >>> It may be a bit late, but in my opinion you might consider changing the >>> package name for future versions. Ashley Yakeley wrote: >> It really means "stuff that ought to be in time, but can't be due to >> language compatibility reasons". The time-extras package should probably >> be in the Haskell Platform, and it may eventually get merged into the >> time package. Lennart Augustsson wrote: > Data instances are not just there for syb... > I think they should be derived wherever possible. > Using them is a different matter; I think they should be used > sparingly. ?But when you need them, they are very useful. OK, thanks Ashley and Lennart for the explanations. Still - something more descriptive of the content, like time-generic or time-reflection or time-data-instances, might have been more informative. Hackage is quickly becoming an unnavigable tangled jungle. Thanks, Yitz From slyich at gmail.com Mon Dec 28 15:22:09 2009 From: slyich at gmail.com (Sergei Trofimovich) Date: Mon Dec 28 14:54:19 2009 Subject: darcs patch: fixed 'cabal sdist' Message-ID: <4b391327.23a0100a.1f4f.5741@mx.google.com> Tue Dec 15 00:56:45 EET 2009 Sergei Trofimovich * fixed 'cabal sdist' It actually fixes './configure' regeneration for such distros, like gentoo, wich had to patch configure.ac and regenerate script toolchain. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1031 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20091228/c3276d9c/attachment.bin From slyich at gmail.com Mon Dec 28 15:22:33 2009 From: slyich at gmail.com (Sergei Trofimovich) Date: Mon Dec 28 14:54:42 2009 Subject: darcs patch: lower base requirement down to base-2 Message-ID: <4b391340.0856100a.210c.2ac4@mx.google.com> Wed Dec 16 23:34:21 EET 2009 Sergei Trofimovich * lower base requirement down to base-2 At least ghc-6.6.1 is able to build it without problems. (package can be used in cabal-1.8, which is known to work on ghc-6.4+) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 2355 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20091228/0ffdd7b0/attachment.bin From duncan.coutts at googlemail.com Mon Dec 28 21:42:49 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Dec 28 21:16:13 2009 Subject: ANN: time-extras 1.1.4 In-Reply-To: References: Message-ID: <1262054569.9220.113554.camel@localhost> On Wed, 2009-12-23 at 00:45 -0800, Ashley Yakeley wrote: > time-extras 1.1.4 contains Data instances for types defined in > time-1.1.4. They are in a separate package because they require > RankNTypes, which is not Haskell 2010. Can you remind us why it's not reasonable to have the time package (conditionally) provide Data instances? I don't think we can say that we must restrict ourselves to the Haskell 2010 language extensions when the base package is using Rank2Types in its public API. We clearly need a general solution. It's silly to have every package have a separate companion that provides Data instances. In this instance, CPP doesn't seem like too bad a solution. The people who want to use the Data class are clearly not using compilers that do not support Rank2Types. Duncan From bulat.ziganshin at gmail.com Tue Dec 29 02:50:56 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Dec 29 02:24:30 2009 Subject: ANN: time-extras 1.1.4 In-Reply-To: <1262054569.9220.113554.camel@localhost> References: <1262054569.9220.113554.camel@localhost> Message-ID: <557472033.20091229105056@gmail.com> Hello Duncan, Tuesday, December 29, 2009, 5:42:49 AM, you wrote: > Can you remind us why it's not reasonable to have the time package > (conditionally) provide Data instances? > I don't think we can say that we must restrict ourselves to the Haskell > 2010 language extensions when the base package is using Rank2Types in > its public API. may be because this make time package compatible with hugs/nhc (if it makes)? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From malcolm.wallace at cs.york.ac.uk Tue Dec 29 06:03:02 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Dec 29 05:36:23 2009 Subject: ANN: time-extras 1.1.4 In-Reply-To: <1262054569.9220.113554.camel@localhost> References: <1262054569.9220.113554.camel@localhost> Message-ID: <768D5D4D-59D9-407F-9ACE-94A01259F5F7@cs.york.ac.uk> > I don't think we can say that we must restrict ourselves to the > Haskell > 2010 language extensions when the base package is using Rank2Types in > its public API. ... and this is one of the great flaws of the base package. Because of such non-standard extensions, the 'base' package API is _not_ universally available across all compilers. I strongly believe that 'base' is a misnomer, and we should consider hiding 'base' altogether, and creating a 'real-base' package that is (a) compliant to the language standards, (b) contains no compiler-specific modules or functions. Regards, Malcolm From igloo at earth.li Tue Dec 29 06:30:03 2009 From: igloo at earth.li (Ian Lynagh) Date: Tue Dec 29 06:03:23 2009 Subject: ANN: time-extras 1.1.4 In-Reply-To: <768D5D4D-59D9-407F-9ACE-94A01259F5F7@cs.york.ac.uk> References: <1262054569.9220.113554.camel@localhost> <768D5D4D-59D9-407F-9ACE-94A01259F5F7@cs.york.ac.uk> Message-ID: <20091229113003.GA14192@matrix.chaos.earth.li> On Tue, Dec 29, 2009 at 11:03:02AM +0000, Malcolm Wallace wrote: >> I don't think we can say that we must restrict ourselves to the >> Haskell >> 2010 language extensions when the base package is using Rank2Types in >> its public API. > > ... and this is one of the great flaws of the base package. > > Because of such non-standard extensions, the 'base' package API is _not_ > universally available across all compilers. I strongly believe that > 'base' is a misnomer, and we should consider hiding 'base' altogether, > and creating a 'real-base' package that is (a) compliant to the language > standards, I think it would be more efficient to achieve this by working on standardising the necesary extensions for H'2011. Thanks Ian From duncan.coutts at googlemail.com Tue Dec 29 12:39:20 2009 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Tue Dec 29 12:12:42 2009 Subject: ANN: time-extras 1.1.4 In-Reply-To: <768D5D4D-59D9-407F-9ACE-94A01259F5F7@cs.york.ac.uk> References: <1262054569.9220.113554.camel@localhost> <768D5D4D-59D9-407F-9ACE-94A01259F5F7@cs.york.ac.uk> Message-ID: <1262108360.9220.117145.camel@localhost> On Tue, 2009-12-29 at 11:03 +0000, Malcolm Wallace wrote: > > I don't think we can say that we must restrict ourselves to the > > Haskell > > 2010 language extensions when the base package is using Rank2Types in > > its public API. > > ... and this is one of the great flaws of the base package. > > Because of such non-standard extensions, the 'base' package API is > _not_ universally available across all compilers. I strongly believe > that 'base' is a misnomer, and we should consider hiding 'base' > altogether, and creating a 'real-base' package that is (a) compliant > to the language standards, (b) contains no compiler-specific modules > or functions. Sure, that'd also be a good solution. I do in principle support making base more portable and exporting the same API for all compilers. (I had to modify zlib the other day because of some ForeignPtr function which seems needlessly to be ghc-only.) In the mean time I don't see that it makes sense to do it using CPP for most core/platform packages and completely differently for the time package. Duncan From briand at aracnet.com Tue Dec 29 14:08:41 2009 From: briand at aracnet.com (Brian Denheyer) Date: Tue Dec 29 13:42:01 2009 Subject: template haskell (Debian & chart) Message-ID: <19258.21433.512550.293917@windy.deldotd.com> I need template haskell for chart. I installed the libghc6-src-ext-devs which supposedly provides template haskell, but I get the following error. *** Chasing dependencies: Chasing modules from: *Language.Haskell.TH.Syntax.Internals,*Language.Haskell.TH.Syntax,*Language.Haskell.TH.PprLib,*Language.Haskell.TH.Ppr,*Language.Haskell.TH.Lib,*Language.Haskell.TH.Quote,*Language.Haskell.TH Language/Haskell/TH/Syntax/Internals.hs:20:7: Could not find module `Data.Data': it is a member of the hidden package `base' locations searched: dist/build/Data/Data.hs dist/build/Data/Data.lhs Data/Data.hs Data/Data.lhs dist/build/autogen/Data/Data.hs dist/build/autogen/Data/Data.lhs I get the same error if I try cabal install template-haskell also. I can't tell if this is because there is a version problem or the library really isn't installed. Brian From marlowsd at gmail.com Wed Dec 30 06:37:15 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Dec 30 06:10:37 2009 Subject: ANN: Happstack 0.4.1 In-Reply-To: <694519c50912211933p257746abgca00c46a443264ac@mail.gmail.com> References: <54342.1261377119@n-heptane.com> <694519c50912211933p257746abgca00c46a443264ac@mail.gmail.com> Message-ID: <4B3B3B6B.3010102@gmail.com> On 22/12/09 03:33, Antoine Latter wrote: > On Mon, Dec 21, 2009 at 6:31 AM, wrote: >> Hello, >> >> That sort of missing symbol error at link time is often (but not always) a >> sign that some libraries got recompiled but not others. So there are >> references to the old symbol names hanging around. >> >> I would try to ghc-pkg unregister syb-with-class and everything that depends >> on it, and then try cabal install happstack again. >> > > I'm pretty well stumped at this point. I've cleared off everything and > gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives > me the same symbol not defined error in Happstack.Data.Xml.Base. > > But here's the spooky part, if I run it by hand like so: > > ghc --make src/Happstack/Data/Xml/Base.hs > src/Happstack/Data/Default.hs src/Happstack/Data/ > DeriveAll.hs src/Happstack/Data/Normalize.hs src/Happstack/Data/Migrate.hs > > after resolving issues due to CPP not being run, everything runs to > completion, no errors. Also, the list of things we're pulling in > during the template-haskell execution is much smaller (see bellow). > > Has anyone seen this, where template-haskell behaves different when > run from cabal-install (or Setup.hs) than from ghc --make (or ghci)? > >>>>>> > 2 of 5] Compiling Happstack.Data.Migrate ( > src/Happstack/Data/Migrate.hs, src/Happstack/Data/Migrate.o ) > [3 of 5] Compiling Happstack.Data.Default ( > src/Happstack/Data/Default.hs, src/Happstack/Data/Default.o ) > [4 of 5] Compiling Happstack.Data.DeriveAll ( > src/Happstack/Data/DeriveAll.hs, src/Happstack/Data/DeriveAll.o ) > [5 of 5] Compiling Happstack.Data.Xml.Base ( > src/Happstack/Data/Xml/Base.hs, src/Happstack/Data/Xml/Base.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > Loading package array-0.3.0.0 ... linking ... done. > Loading package bytestring-0.9.1.5 ... linking ... done. > Loading package containers-0.3.0.0 ... linking ... done. > Loading package pretty-1.0.1.1 ... linking ... done. > Loading package syb-0.1.0.2 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package syb-with-class-0.6.1 ... linking ... done. > mkUsageInfo: internal name? Element{tc a4av} > <<<<< Did you submit a ticket for this? I don't recall seeing one. Cheers, Simon From briand at aracnet.com Thu Dec 31 00:32:49 2009 From: briand at aracnet.com (Brian Denheyer) Date: Thu Dec 31 00:06:05 2009 Subject: template haskell (Debian & chart) In-Reply-To: <548520610912302052v4e089380jd36d124d7e4c1ed5@mail.gmail.com> References: <19258.21433.512550.293917@windy.deldotd.com> <548520610912302052v4e089380jd36d124d7e4c1ed5@mail.gmail.com> Message-ID: <19260.14209.647358.100893@windy.deldotd.com> Tim Docker writes: > Brian Denheyer wrote: > > I need template haskell for chart. > > > > I installed the libghc6-src-ext-devs which supposedly provides > > template haskell, but I get the following error. > > > Language/Haskell/TH/Syntax/Internals.hs:20:7: > > Could not find module `Data.Data': > > it is a member of the hidden package `base' > > locations searched: > > dist/build/Data/Data.hs > > dist/build/Data/Data.lhs > > Data/Data.hs > > Data/Data.lhs > > dist/build/autogen/Data/Data.hs > > dist/build/autogen/Data/Data.lhs > > I had this problem also. I was able to work around it by explicitly > requesting an older version of data-accessor-template: > > cabal install data-accessor-template-0.2.1.1 > > Henning: do you know why the above build fails when using v0.2.1.2 and > ghc-10.1.4? > > Tim Yes ! That works for me too. Thank you. I got confused, I though that data-accessor was part of the template library and so therefore maybe there was a problem with the versions being used in debian. Looks like data-accessor stands on it's own, and that it's really a problem with chart not being able to use the most recent version of data-accessor, is that right ? Brian From cgibbard at gmail.com Thu Dec 31 19:35:05 2009 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Dec 31 19:08:17 2009 Subject: nubBy, groupBy specification Message-ID: <89ca3d1f0912311635r25065a10me6b576b3fe4ffb60@mail.gmail.com> Hello, I've recently been irritated with (what I consider to be) broken versions of nubBy in GHC 6.10.4 and 6.12.1. For a while, groupBy was broken in the same way, but it seems to be fixed at least in 6.10.4. The problem is roughly caused by nubBy being specified only for symmetric relations, where this is actually a rather silly constraint, given that it captures a very common pattern of sieving (that at least I'd personally not want to have to write recursively every time). My most common usage of nubBy is actually probably nubBy (>=), (which has to be changed to nubBy (<=) for recent GHCs), and variations on it. This is extremely useful as a kind of lazier approximation of maximum or minimum. I occasionally use nubBy with equivalence relations (after these, I'd say (==) `on` foo is probably my next most common use case), but it's surprising how often that's actually not quite the right thing. Of course, there's also the inefficient but pretty example of constructing the list of primes using the divisibility relation and nubBy, which getting this wrong also breaks. What do people think of the following spec? nubBy f xs produces a subsequence ys of xs which satisfies: 1) f x y is False whenever x occurs before y in ys. 2) ys is maximal with respect to containment subject to condition 1. 3) The sequence of indices of selected elements is lexicographically minimal subject to conditions 1 and 2. (That is, the selections are made greedily.) Similarly, I think groupBy f xs should be specified as: groupBy f xs produces a list of lists yss of contiguous elements of xs such that: 1) concat yss = xs 2) Each element of yss is a nonempty list (y:ys) such that all (f y) ys. 3) The sequence of lengths of elements of ys is lexicographically maximal subject to conditions 1 and 2. (Again, this just means it greedily prefers to put elements in earlier lists rather than later ones.) Note that the code given in the Haskell 98 spec does the right thing with respect to these specifications, but Haskell 98 says that they're not specified for non-equivalence relations, while I think that they actually should be. A general policy that I think we should try to adopt is that the expression graph produced by a higher order function on lists, in terms of the supplied functions, should as far as reasonably possible maintain the left-to-right order of occurrences of elements as they occurred in the list. This makes the precise behaviour easy to remember, and tends to keep expression graphs easy to draw. foldr, foldl, scanr, scanl, mapAccumL, nubBy and groupBy (as specified above), all follow this rule (of course, many simpler HOFs do as well). mapAccumR as specified strangely does not, which makes it another thing I'd like to change. (See: http://cale.yi.org/index.php/Fold_Diagrams) cheers! - Cale