From martine at danga.com Sat Mar 1 03:02:49 2008 From: martine at danga.com (Evan Martin) Date: Sat Mar 1 03:00:29 2008 Subject: building a helper binary with cabal Message-ID: <3a6f89fc0803010002g29b98f08qbecdd95eaea13d14@mail.gmail.com> [resent after subscribing to the list] I'm working on a package that requires building a helper binary as part of its install process. This binary is written in C (with good reason), and on a Debian system would be installed into a path like /usr/lib/myproject/mybinary, because it's only used internally by the main program binary. My setup is up to this point: > gccProgram :: Program > gccProgram = simpleProgram "gcc" > type BuildHook = PackageDescription -> LocalBuildInfo > -> UserHooks -> BuildFlags -> IO () > creplChildBuild :: BuildHook -> BuildHook > creplChildBuild oldhook desc buildinfo hooks flags = do > oldhook desc buildinfo hooks flags > rawSystemProgramConf (buildVerbose flags) gccProgram (buildPrograms flags) > ["child.c", "-o", buildDir buildinfo "child", "-ldl"] > buildHooks = simpleUserHooks { > hookedPrograms = [gccProgram], > buildHook = creplChildBuild (buildHook simpleUserHooks) > } > main = defaultMainWithHooks buildHooks However, it's unclear to me how to set up the install rule that would copy that binary into the appropriate place. Any tips? It seems I want to grab the "install" hook, but from there how do I specify where to install the file? There seem to be no helper functions to facilitate installing. (I appreciate that all of this is pretty new. So if it's not possible for me to do what I want, take it as an example of the sort of thing I'd like for Cabal to support...) From fmartini at gmail.com Sat Mar 1 04:39:11 2008 From: fmartini at gmail.com (Felix Martini) Date: Sat Mar 1 04:36:52 2008 Subject: every use of BSD4 on hackage is incorrect In-Reply-To: <1204323078.11558.76.camel@localhost> References: <1204323078.11558.76.camel@localhost> Message-ID: <6c0416190803010139v318ba06csbbc23670003852c1@mail.gmail.com> Right now i cannot see a reason why the cabal license field is an enumeration instead of a string. The purpose seems to be to direct people to preferred licenses of the Haskell community. If so this is the wrong approach imo. A good explanation of licensing on the haskell.org wiki is better. Btw. the Haddock headers in the GHC source code also use custom strings for the license field. Felix From duncan.coutts at worc.ox.ac.uk Sat Mar 1 05:29:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Mar 1 05:27:17 2008 Subject: every use of BSD4 on hackage is incorrect In-Reply-To: <6c0416190803010139v318ba06csbbc23670003852c1@mail.gmail.com> References: <1204323078.11558.76.camel@localhost> <6c0416190803010139v318ba06csbbc23670003852c1@mail.gmail.com> Message-ID: <1204367374.11558.85.camel@localhost> On Sat, 2008-03-01 at 10:39 +0100, Felix Martini wrote: > Right now i cannot see a reason why the cabal license field is an > enumeration instead of a string. The purpose seems to be to direct > people to preferred licenses of the Haskell community. If so this is > the wrong approach imo. It's not clear that that is the intention. This has been in the spec and the design since the very beginning. You'd have to ask someone who helped with the original spec to be sure of the intention. http://haskell.org/cabal/release/old/users-guide-0.1/x29.html#pkg-descr http://haskell.org/cabal/release/cabal-1.0/doc/pkg-spec-html/ It has always allowed for using any license. I suspect the intention was for convenience and to provide some consistency for common licenses, eg so we don't get packages specifying "gpl", "gpl2" "gpl-2" "GPL" and we have to wonder if those are all the same. In the common case it gives machine recognisable information. Duncan From duncan.coutts at worc.ox.ac.uk Sat Mar 1 06:21:17 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Mar 1 06:19:26 2008 Subject: building a helper binary with cabal In-Reply-To: <3a6f89fc0803010002g29b98f08qbecdd95eaea13d14@mail.gmail.com> References: <3a6f89fc0803010002g29b98f08qbecdd95eaea13d14@mail.gmail.com> Message-ID: <1204370477.11558.101.camel@localhost> On Sat, 2008-03-01 at 00:02 -0800, Evan Martin wrote: > [resent after subscribing to the list] > > I'm working on a package that requires building a helper binary as > part of its install process. I presume you mean a private binary that's needed at runtime, rather than a program like a code-gen needed at build time but not installed. Cabal does not have any direct support for private binaries, so you'll have to use a custom Setup.hs. Perhaps it should, if you can describe what you think is needed in general, file a feature request here: http://hackage.haskell.org/trac/hackage/ > This binary is written in C (with good > reason), and on a Debian system would be installed into a path like > /usr/lib/myproject/mybinary, because it's only used internally by the > main program binary. Cabal knows about the 'libexec' path which sounds like it might be what you want, though that doesn't include any package subdir (though perhaps it should - it is currently unused). Alternatively just install into the 'libdir' which does include the package subdir. let dirs = absoluteInstallDirs pkg_descr lbi copydest copyFileVerbose verbosity file (libdir dirs file) At runtime you can get the libexec and libdir that the user chose at configure time using the Paths_pkgname module which exports getLibDir and getLibexecDir amongst others. Duncan From martine at danga.com Sat Mar 1 12:17:54 2008 From: martine at danga.com (Evan Martin) Date: Sat Mar 1 12:15:35 2008 Subject: building a helper binary with cabal In-Reply-To: <1204370477.11558.101.camel@localhost> References: <3a6f89fc0803010002g29b98f08qbecdd95eaea13d14@mail.gmail.com> <1204370477.11558.101.camel@localhost> Message-ID: <3a6f89fc0803010917u2b0fc955n49bc052ea99f0643@mail.gmail.com> On Sat, Mar 1, 2008 at 3:21 AM, Duncan Coutts wrote: > I presume you mean a private binary that's needed at runtime, rather > than a program like a code-gen needed at build time but not installed. That's right. > Cabal does not have any direct support for private binaries, so you'll > have to use a custom Setup.hs. > > Perhaps it should, if you can describe what you think is needed in > general, file a feature request here: > http://hackage.haskell.org/trac/hackage/ I can't think of many scenarios where they'd really be needed. The two instances I've seen are: 1) to write a simplified (commands via stdin, output via stdout) interface to an API that I don't want to link in (or don't want to write bindings for) 2) this particular program, which would be written in Haskell except that it does some C libdl tricks > Cabal knows about the 'libexec' path which sounds like it might be what > you want, though that doesn't include any package subdir (though perhaps > it should - it is currently unused). Alternatively just install into the > 'libdir' which does include the package subdir. > > let dirs = absoluteInstallDirs pkg_descr lbi copydest > copyFileVerbose verbosity file (libdir dirs file) Thanks, this is very helpful! absoluteInstallDirs takes a few more args, so here's a longer example for the mailing list archives. I'm 98% of the way there, just need to figure out copyDest. >From the docs, it may be the case that copyDest is only available in the "copy" step? If that's right, does that mean the user needs to run the copy step manually? > type InstHook = PackageDescription -> LocalBuildInfo -> UserHooks > -> InstallFlags -> IO ()) > creplChildInst :: InstHook -> InstHook > creplChildInst oldhook desc buildinfo hooks flags = do > oldhook desc buildinfo hooks flags > let compilerpkg = compilerId (compiler buildinfo) > let copydest = -- XXX still haven't figured this one out > let dirtemplates = installDirTemplates buildinfo > let dirs = absoluteInstallDirs desc compilerpkg copydest dirtemplates > copyFileVerbose (installVerbose flags) (creplChildPath buildinfo) > (libdir dirs "child") > At runtime you can get the libexec and libdir that the user chose at > configure time using the Paths_pkgname module which exports getLibDir > and getLibexecDir amongst others. Cool, thanks. From martine at danga.com Sat Mar 1 12:40:40 2008 From: martine at danga.com (Evan Martin) Date: Sat Mar 1 12:38:19 2008 Subject: building a helper binary with cabal In-Reply-To: <3a6f89fc0803010917u2b0fc955n49bc052ea99f0643@mail.gmail.com> References: <3a6f89fc0803010002g29b98f08qbecdd95eaea13d14@mail.gmail.com> <1204370477.11558.101.camel@localhost> <3a6f89fc0803010917u2b0fc955n49bc052ea99f0643@mail.gmail.com> Message-ID: <3a6f89fc0803010940s6d51c40ftdfdcbb62b2dd21bb@mail.gmail.com> On Sat, Mar 1, 2008 at 9:17 AM, Evan Martin wrote: > > let dirs = absoluteInstallDirs pkg_descr lbi copydest > > copyFileVerbose verbosity file (libdir dirs file) > > Thanks, this is very helpful! > absoluteInstallDirs takes a few more args, so here's a longer example > for the mailing list archives. I'm 98% of the way there, just need to > figure out copyDest. I see now that there are two different absoluteInstallDirs and you were referring to the other one. It's much simpler now. Though my confusion about CopyDest remains... (Is there a way to search Hoogle for "functions returning CopyDest"?) From bjorn at bringert.net Sat Mar 1 17:05:10 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Sat Mar 1 17:02:50 2008 Subject: every use of BSD4 on hackage is incorrect In-Reply-To: <1204323078.11558.76.camel@localhost> References: <1204323078.11558.76.camel@localhost> Message-ID: On Fri, Feb 29, 2008 at 11:11 PM, Duncan Coutts wrote: > The following hackage packages specify in their .cabal file: > > license: BSD4 > > Which is the 4-clause BSD license, ie the one with the advertising > clause. > > cabal-upload-0.3 > Chart-0.5 > FiniteMap-0.1 > haxr-3000.0.1 > haxr-th-1.0 > hbeat-0.1 > htar-0.1 > pcap-0.4.2 > tar-0.1.1.1 > unix-compat-0.1.2.1 > > Inspecting the LICENSE files for every one of these packages reveals > that they actually use the 3-clause BSD license. Not a single hackage > package really uses the 4-clause BSD license. In every case that it has > been used it was just a confusion. > > We therefore propose to deprecate BSD4 as a valid license in .cabal > files: > http://hackage.haskell.org/trac/hackage/ticket/205 > > In the unlikely case that anyone really wants to use the 4-clause BSD > license they can still specify "license: OtherLicense" and put the text > in the accompanying LICENSE file. > > > Additionally, I propose to add the MIT license since there are a couple > packages that really use that and allow optional versions on the > licenses that are versioned, which includes the GPL and LGPL. > > Looking at OtherLicense we find common ones are MIT, variations on BSD3 > (2 clause and fewer, other informal variations), disjunctions of BSD3 / > GPL (ie dual licensing), conjunctions of BSD3 / GPL (ie some bits user > BSD some under GPL). Hi Duncan, thanks for pointing that out. I've fixed the 6 out of those 10 that are mine. I must have gotten that wrong some time long ago and then just copied the .cabal file to new projects. Consider this a vote for deprecating BSD4. /Bjorn From matti.niemenmaa+news at iki.fi Sun Mar 2 10:38:12 2008 From: matti.niemenmaa+news at iki.fi (Matti Niemenmaa) Date: Sun Mar 2 10:42:39 2008 Subject: Proposal: Add an instance for IArray (IOToDiffArray IOUArray) Bool (Trac #2133) Message-ID: An instance for 'IArray (IOToDiffArray IOUArray) Bool' is missing from Data.Array.Diff. There doesn't seem to be any good reason for this: all the other 'IArray UArray a' instances defined in Data.Array.IArray have corresponding instances. Bool is the sole exception. They cannot be added in user code without copying the entire Data.Array.Diff source, since the instances require internal functions which aren't exposed. Since all the instances are defined in exactly the same way, only varying the second type parameter, this requires practically zero work: just copy any of the other instances and replace the type parameter with Bool. A Show instance should also be provided. Both are in the patch (attached to the ticket). To be sure that the instances haven't been omitted because they don't work, I wrote a few QuickCheck properties (attached to the ticket) and it seems that it does work without any trouble. Suggested deadline for discussion: 17th March 2008. From matti.niemenmaa+news at iki.fi Sun Mar 2 10:48:25 2008 From: matti.niemenmaa+news at iki.fi (Matti Niemenmaa) Date: Sun Mar 2 10:47:40 2008 Subject: Proposal: Add an instance for IArray (IOToDiffArray IOUArray) Bool (Trac #2133) In-Reply-To: References: Message-ID: Matti Niemenmaa wrote: > Suggested deadline for discussion: 17th March 2008. And the Ticket link (I had to forget something): http://hackage.haskell.org/trac/ghc/ticket/2133 From duncan.coutts at worc.ox.ac.uk Sun Mar 2 13:11:54 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 2 13:09:37 2008 Subject: building a helper binary with cabal In-Reply-To: <3a6f89fc0803010940s6d51c40ftdfdcbb62b2dd21bb@mail.gmail.com> References: <3a6f89fc0803010002g29b98f08qbecdd95eaea13d14@mail.gmail.com> <1204370477.11558.101.camel@localhost> <3a6f89fc0803010917u2b0fc955n49bc052ea99f0643@mail.gmail.com> <3a6f89fc0803010940s6d51c40ftdfdcbb62b2dd21bb@mail.gmail.com> Message-ID: <1204481514.11558.111.camel@localhost> On Sat, 2008-03-01 at 09:40 -0800, Evan Martin wrote: > On Sat, Mar 1, 2008 at 9:17 AM, Evan Martin wrote: > > > let dirs = absoluteInstallDirs pkg_descr lbi copydest > > > copyFileVerbose verbosity file (libdir dirs file) > > > > Thanks, this is very helpful! > > absoluteInstallDirs takes a few more args, so here's a longer example > > for the mailing list archives. I'm 98% of the way there, just need to > > figure out copyDest. > > I see now that there are two different absoluteInstallDirs and you > were referring to the other one. It's much simpler now. Though my > confusion about CopyDest remains... The install phase is really two phases, copy and register. The copy phase has the CopyDest param. The default install hook just runs the copy and register phases. So you probably want to override the copy hook and not the install one. The hooks stuff is all really very confusing and unsatisfactory. > (Is there a way to search Hoogle for "functions returning CopyDest"?) No idea, ask Neil. In this case it would not have helped since it's not the result of any function directly. It's an arg that your function will be passed. It does appear in a covariant position at least. Duncan From conal at conal.net Sun Mar 2 15:06:33 2008 From: conal at conal.net (Conal Elliott) Date: Sun Mar 2 15:04:10 2008 Subject: hscolour -anchor via cabal ? Message-ID: Is there a way to get cabal to tell hscolour to add anchors for top-level defs (hscolour's -anchor option)? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080302/f0e4cce7/attachment.htm From duncan.coutts at worc.ox.ac.uk Sun Mar 2 16:00:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 2 15:57:43 2008 Subject: hscolour -anchor via cabal ? In-Reply-To: References: Message-ID: <1204491602.11558.131.camel@localhost> On Sun, 2008-03-02 at 12:06 -0800, Conal Elliott wrote: > Is there a way to get cabal to tell hscolour to add anchors for > top-level defs (hscolour's -anchor option)? >From a quick look at the code it looks like Cabal always passes the "-anchor" option to HsColour. Do you have a test case where that's not working? Run with -v to see how Cabal is calling HsColour. Duncan From martine at danga.com Sun Mar 2 17:34:25 2008 From: martine at danga.com (Evan Martin) Date: Sun Mar 2 17:32:01 2008 Subject: building a helper binary with cabal In-Reply-To: <1204481514.11558.111.camel@localhost> References: <3a6f89fc0803010002g29b98f08qbecdd95eaea13d14@mail.gmail.com> <1204370477.11558.101.camel@localhost> <3a6f89fc0803010917u2b0fc955n49bc052ea99f0643@mail.gmail.com> <3a6f89fc0803010940s6d51c40ftdfdcbb62b2dd21bb@mail.gmail.com> <1204481514.11558.111.camel@localhost> Message-ID: <3a6f89fc0803021434g13966616tbd73e1683cc90a06@mail.gmail.com> On Sun, Mar 2, 2008 at 10:11 AM, Duncan Coutts wrote: > The install phase is really two phases, copy and register. The copy > phase has the CopyDest param. The default install hook just runs the > copy and register phases. So you probably want to override the copy hook > and not the install one. It seems the default copy hook just runs the install hook, and that the install hook doesn't run the copy one... ? http://haskell.org/ghc/docs/latest/html/libraries/Cabal/src/Distribution-Simple.html#simpleUserHooks copyHook = \desc lbi _ f -> install desc lbi f, -- has correct 'copy' behavior with params I'm sure I'm just missing something here, but my "postCopy" hook doesn't seem to be running with "install -v3". > The hooks stuff is all really very confusing and unsatisfactory. I agree, but I can also appreciate how difficult it must be to design, and can acknowledge that it may be the case that it really just needs to be this complicated. Having used autoconf and friends before, one thing I really prefer about this system is that there are bazillion different types which helps prevent you from accidentally doing something like putting a intermediate object in the source dir or installing while ignoring the user's prefix. From dons at galois.com Sun Mar 2 20:10:10 2008 From: dons at galois.com (Don Stewart) Date: Sun Mar 2 20:07:59 2008 Subject: hscolour -anchor via cabal ? In-Reply-To: <1204491602.11558.131.camel@localhost> References: <1204491602.11558.131.camel@localhost> Message-ID: <20080303011010.GC31111@scytale.galois.com> duncan.coutts: > > On Sun, 2008-03-02 at 12:06 -0800, Conal Elliott wrote: > > Is there a way to get cabal to tell hscolour to add anchors for > > top-level defs (hscolour's -anchor option)? > > >From a quick look at the code it looks like Cabal always passes the > "-anchor" option to HsColour. Do you have a test case where that's not > working? Run with -v to see how Cabal is calling HsColour. > Btw, something that just occured to me: hscolour is GPL'd -- do we ever link against it as a library? Or are we careful to only call the binary? -- Don From duncan.coutts at worc.ox.ac.uk Sun Mar 2 20:37:16 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 2 20:34:53 2008 Subject: hscolour -anchor via cabal ? In-Reply-To: <20080303011010.GC31111@scytale.galois.com> References: <1204491602.11558.131.camel@localhost> <20080303011010.GC31111@scytale.galois.com> Message-ID: <1204508236.11558.146.camel@localhost> On Sun, 2008-03-02 at 17:10 -0800, Don Stewart wrote: > duncan.coutts: > > > > On Sun, 2008-03-02 at 12:06 -0800, Conal Elliott wrote: > > > Is there a way to get cabal to tell hscolour to add anchors for > > > top-level defs (hscolour's -anchor option)? > > > > >From a quick look at the code it looks like Cabal always passes the > > "-anchor" option to HsColour. Do you have a test case where that's not > > working? Run with -v to see how Cabal is calling HsColour. > > > > Btw, something that just occured to me: hscolour is GPL'd -- do we ever > link against it as a library? Or are we careful to only call the binary? It's called as a binary. You can convince yourself by checking the build-depends. Duncan From conal at conal.net Sun Mar 2 22:48:18 2008 From: conal at conal.net (Conal Elliott) Date: Sun Mar 2 22:45:54 2008 Subject: hscolour -anchor via cabal ? In-Reply-To: <1204491602.11558.131.camel@localhost> References: <1204491602.11558.131.camel@localhost> Message-ID: Thanks for questioning my assumption. hscolour is getting -anchor, after all. It's somehow failing to make anchors some classes. - Conal On Sun, Mar 2, 2008 at 1:00 PM, Duncan Coutts wrote: > > On Sun, 2008-03-02 at 12:06 -0800, Conal Elliott wrote: > > Is there a way to get cabal to tell hscolour to add anchors for > > top-level defs (hscolour's -anchor option)? > > >From a quick look at the code it looks like Cabal always passes the > "-anchor" option to HsColour. Do you have a test case where that's not > working? Run with -v to see how Cabal is calling HsColour. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080302/bdbc44d5/attachment.htm From Malcolm.Wallace at cs.york.ac.uk Mon Mar 3 04:59:10 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Mar 3 05:01:31 2008 Subject: hscolour -anchor via cabal ? In-Reply-To: References: <1204491602.11558.131.camel@localhost> Message-ID: <20080303095910.3f828a9b.Malcolm.Wallace@cs.york.ac.uk> "Conal Elliott" wrote: > Thanks for questioning my assumption. hscolour is getting -anchor, > after all. It's somehow failing to make anchors some classes. There was a bug in hscolour-1.8 whereby many top-level definitions failed to get an anchor - it is fixed in 1.9. If you have a reproducible case where it still fails, please let me know. However, there is also a more long-standing issue with class methods, which never get an anchor. This is primarily because they are tricky to recognise, purely lexically, in a reliable way. In any case, it is rare for the source defn of a class method to contain any more information than the generated haddock (because the method only has code if there is a default defn, and in most cases, you can't navigate to the instance code). Regards, Malcolm From alistair at abayley.org Wed Mar 5 04:24:09 2008 From: alistair at abayley.org (Alistair Bayley) Date: Wed Mar 5 04:21:41 2008 Subject: ANN: Takusen 0.8 Message-ID: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> Oleg and I are pleased to announce the release of Takusen 0.8. (Don Stewart did an interim 0.7 release for us a few weeks ago, and added us to Hackage. This release is a tidy-up of some loose ends, and some bug fixes. Hence, I've summarise the changes since the 0.6 release.) Changes since 0.6: - ODBC support. This still has a few gaps (and probably bugs and rough edges) but should be fairly usable. - support for reusable/persistent sessions, so you can hang onto the connection object between invocations of withSession (this was in release 0.6 but omitted from the release notes). - improvements to the Cabal Setup scripts, which should give better experiences for ghc-6.4, ghc-6.6, and ghc-6.8. The (eventual) 1.4 release of Cabal should be able to build our haddock docs, too. - improved UTF8 decoder (marshals directly from buffer). The release bundle: http://hackage.haskell.org/packages/archive/Takusen/0.8/Takusen-0.8.tar.gz The latest code: darcs get http://darcs.haskell.org/takusen Docs: http://darcs.haskell.org/takusen/doc/html/index.html A comprehensive description of API usage can be found in the documentation for module Database.Enumerator (look for the Usage section): http://darcs.haskell.org/takusen/doc/html/Database-Enumerator.html Future plans: - FreeTDS backend (Sybase and MS Sql Server) - support for Blobs and Clobs For those of you unfamiliar with Takusen, here is our HCAR blurb: Takusen is a library for accessing DBMS's. Like HSQL, we support arbitrary SQL statements (currently strings, extensible to anything that can be converted to a string). Takusen's `unique-selling-point' is safety and efficiency. We statically ensure all acquired database resources - such as cursors, connection and statement handles - are released, exactly once, at predictable times. Takusen can avoid loading the whole result set in memory, and so can handle queries returning millions of rows in constant space. Takusen also supports automatic marshalling and unmarshalling of results and query parameters. These benefits come from the design of query result processing around a left-fold enumerator. Currently we fully support ODBC, Oracle, Sqlite, and PostgreSQL. From alistair at abayley.org Wed Mar 5 04:29:31 2008 From: alistair at abayley.org (Alistair Bayley) Date: Wed Mar 5 04:27:01 2008 Subject: ANN: Takusen 0.8 In-Reply-To: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> Message-ID: <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> > Changes since 0.6: > > - ODBC support. This still has a few gaps (and probably bugs and rough edges) > but should be fairly usable. Doh! I had also meant to make a request: the ODBC code (and Setup.hs configuration) is only tested under Windows (XP). We'd love for people to test on *nix platforms and fill in the missing bits in the Setup script. Alistair From ross at soi.city.ac.uk Wed Mar 5 12:32:06 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Mar 5 12:29:35 2008 Subject: [Haskell-cafe] Re: ANN: Takusen 0.8 In-Reply-To: <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> Message-ID: <20080305173206.GA27155@soi.city.ac.uk> If you want to use your own Setup.hs, you need to specify a Build-Type of Custom, not Simple. Some tools will ignore your Setup.hs if you specify Simple. I guess the message "If possible use 'build-type: Simple'" is a bit confusing. From dons at galois.com Wed Mar 5 13:26:25 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 5 13:24:00 2008 Subject: [Haskell-cafe] Re: ANN: Takusen 0.8 In-Reply-To: <20080305173206.GA27155@soi.city.ac.uk> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> <20080305173206.GA27155@soi.city.ac.uk> Message-ID: <20080305182625.GA16716@scytale.galois.com> ross: > If you want to use your own Setup.hs, you need to specify a Build-Type of > Custom, not Simple. Some tools will ignore your Setup.hs if you specify > Simple. I guess the message "If possible use 'build-type: Simple'" is > a bit confusing. Yes, cabal-setup found this confusing. I wonder if its possible to just use flags for building the different takusen backends, rather than this automagic uber-discovery? -- Don From dons at galois.com Wed Mar 5 14:01:40 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 5 13:59:27 2008 Subject: Proposal: Add System.Exit.exitSuccess :: IO a In-Reply-To: <20080213223110.GG3264@scytale.galois.com> References: <20080213223110.GG3264@scytale.galois.com> Message-ID: <20080305190140.GF16789@scytale.galois.com> dons: > For symmetry with exitFailure :: IO a. Should be pretty uncontroversial. > > Patch attached. Consideration period: 2 weeks, or until there's no > traffic on the subject for a week. This has been applied. From alistair at abayley.org Wed Mar 5 17:45:57 2008 From: alistair at abayley.org (Alistair Bayley) Date: Wed Mar 5 17:43:27 2008 Subject: [Haskell-cafe] Re: ANN: Takusen 0.8 In-Reply-To: <20080305182625.GA16716@scytale.galois.com> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> <20080305173206.GA27155@soi.city.ac.uk> <20080305182625.GA16716@scytale.galois.com> Message-ID: <79d7c4980803051445x3d6a75dag2683977ffde5485f@mail.gmail.com> > ross: > > > If you want to use your own Setup.hs, you need to specify a Build-Type of > > Custom, not Simple. Some tools will ignore your Setup.hs if you specify > > Simple. I guess the message "If possible use 'build-type: Simple'" is > > a bit confusing. > > Yes, cabal-setup found this confusing. > > I wonder if its possible to just use flags for building the different > takusen backends, rather than this automagic uber-discovery? Mebbe... are you suggesting command-line flags, or cabal flags? I'm certainly open to suggestions for improving the install. Part of the motivation for discovery is that for PostgreSQL, you need to run a program (with various flags) which spits out the locations for include files, libs, etc (presumably because they can vary on different platforms? I'm not really sure why, being a Windows chimp myself). Once you do this, it's not much more effort to extend it to detect other DBMS installations, assuming they have standard layouts (Oracle certainly does). The alternative approach is what HSQL did (and I think HDBC, too), which is to have a base package, and then a separate package for each back-end. I considered this, but I much prefer to have the library available as a single download-build-install process. This makes for a nicer user experience (at the expense of more work for the package maintainer). Isn't this partly the point of cabal's Setup.hs i.e. to accommodate more complex build processes than cabal provides out-of-the-box? Obviously there's some pain, because the cabal API is not stable, but c'est la vie... Alistair From dons at galois.com Wed Mar 5 18:08:56 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 5 18:06:32 2008 Subject: [Haskell-cafe] Re: ANN: Takusen 0.8 In-Reply-To: <79d7c4980803051445x3d6a75dag2683977ffde5485f@mail.gmail.com> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> <20080305173206.GA27155@soi.city.ac.uk> <20080305182625.GA16716@scytale.galois.com> <79d7c4980803051445x3d6a75dag2683977ffde5485f@mail.gmail.com> Message-ID: <20080305230856.GC2942@scytale.galois.com> alistair: > > ross: > > > > > If you want to use your own Setup.hs, you need to specify a Build-Type of > > > Custom, not Simple. Some tools will ignore your Setup.hs if you specify > > > Simple. I guess the message "If possible use 'build-type: Simple'" is > > > a bit confusing. > > > > Yes, cabal-setup found this confusing. > > > > I wonder if its possible to just use flags for building the different > > takusen backends, rather than this automagic uber-discovery? > > Mebbe... are you suggesting command-line flags, or cabal flags? I'm > certainly open to suggestions for improving the install. > > Part of the motivation for discovery is that for PostgreSQL, you need > to run a program (with various flags) which spits out the locations > for include files, libs, etc (presumably because they can vary on > different platforms? I'm not really sure why, being a Windows chimp > myself). Once you do this, it's not much more effort to extend it to > detect other DBMS installations, assuming they have standard layouts > (Oracle certainly does). > > The alternative approach is what HSQL did (and I think HDBC, too), > which is to have a base package, and then a separate package for each > back-end. I considered this, but I much prefer to have the library > available as a single download-build-install process. This makes for a > nicer user experience (at the expense of more work for the package > maintainer). Yeah, I really like the single package model. And the Setup.hs does work -- I just can't use cabal 1.2.x or 1.3.x or 1.4.x with it :) So I was imagining cabal flags to select things, but again, this may not work for all backends. > Isn't this partly the point of cabal's Setup.hs i.e. to accommodate > more complex build processes than cabal provides out-of-the-box? > Obviously there's some pain, because the cabal API is not stable, but > c'est la vie... That's right. It's all some give and take. From duncan.coutts at worc.ox.ac.uk Wed Mar 5 18:57:39 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 5 18:55:08 2008 Subject: [Haskell-cafe] Re: ANN: Takusen 0.8 In-Reply-To: <20080305230856.GC2942@scytale.galois.com> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> <20080305173206.GA27155@soi.city.ac.uk> <20080305182625.GA16716@scytale.galois.com> <79d7c4980803051445x3d6a75dag2683977ffde5485f@mail.gmail.com> <20080305230856.GC2942@scytale.galois.com> Message-ID: <1204761459.11558.286.camel@localhost> On Wed, 2008-03-05 at 15:08 -0800, Don Stewart wrote: > alistair: > > > ross: > > > > > > > If you want to use your own Setup.hs, you need to specify a Build-Type of > > > > Custom, not Simple. Some tools will ignore your Setup.hs if you specify > > > > Simple. I guess the message "If possible use 'build-type: Simple'" is > > > > a bit confusing. > > > > > > Yes, cabal-setup found this confusing. > > > > > > I wonder if its possible to just use flags for building the different > > > takusen backends, rather than this automagic uber-discovery? > > > > Mebbe... are you suggesting command-line flags, or cabal flags? I'm > > certainly open to suggestions for improving the install. It would be possible to turn the backends on/off via configuration flags, like: flag odbc library if flag(odbc) exposed-modules: Blah.Backend.ODBC extra-libraries: odbc however that is considered a bit evil, changing the exposed interface based on flags. We did even consider banning that outright (except that the base package does it for the GHc.* modules). It also means that other packages cannot depend on a particular backend, they can only tell users to use certain configure flags. It cannot be automated. What do you do if the user does not have the ODBC or the postgresql C libs installed? Do they have to have all backends installed to use just one? The custom code in Setup.hs to find the flags by calling pg_config etc is perfectly ok. It is unfortunately a bit fragile however but I don't have any better suggestion at the moment. Duncan From gale at sefer.org Thu Mar 6 02:58:27 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Mar 6 02:55:52 2008 Subject: Cannot link to readline In-Reply-To: <2608b8a80803052356h4b4c8b7dn497d99e416073442@mail.gmail.com> References: <2608b8a80803052356h4b4c8b7dn497d99e416073442@mail.gmail.com> Message-ID: <2608b8a80803052358t3fd787abifbd1fe1f7a2a7587@mail.gmail.com> On Mac OS X 10.4, I can't link programs that use readline unless I explicitly specify the GNUreadline framework on the ghc command line: $ ghc --make fooText.hs [4 of 5] Compiling FooText ( FooText.hs, FooText.o ) [5 of 5] Compiling Main ( fooText.hs, fooText.o ) Linking fooText ... /usr/bin/ld: Undefined symbols: _rl_initialize _rl_unbind_key _add_history _readline collect2: ld returned 1 exit status $ ghc --make -framework GNUreadline fooText.hs Linking fooText ... $ Note that this happens for programs that explicitly use System.Console.Readline, not in general ghc use. Manuel M T Chakravarty wrote: > Did you specify -package readline? -package readline doesn't help. It only compiles if I say -framework GNUreadline. > The readline package spec should include the framework > option (if not, its a bug in the config of the readline package IMO). OK, I'll copy this to the libraries list then. Thanks, Yitz From judah.jacobson at gmail.com Thu Mar 6 03:18:45 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Mar 6 03:16:11 2008 Subject: Cannot link to readline In-Reply-To: <2608b8a80803052358t3fd787abifbd1fe1f7a2a7587@mail.gmail.com> References: <2608b8a80803052356h4b4c8b7dn497d99e416073442@mail.gmail.com> <2608b8a80803052358t3fd787abifbd1fe1f7a2a7587@mail.gmail.com> Message-ID: <6d74b0d20803060018s32e7e990l299cddee2fbf3271@mail.gmail.com> On Wed, Mar 5, 2008 at 11:58 PM, Yitzchak Gale wrote: > On Mac OS X 10.4, I can't link programs that use readline > unless I explicitly specify the GNUreadline framework > on the ghc command line: > > Note that this happens for programs that explicitly use > System.Console.Readline, not in general ghc use. > > Manuel M T Chakravarty wrote: > > Did you specify -package readline? > > -package readline doesn't help. It only compiles if I say > -framework GNUreadline. > > > The readline package spec should include the framework > > option (if not, its a bug in the config of the readline package IMO). I agree; the framework is supposed to be linked in automatically. Yitzchak, what version of GHC are you running? Is it a development build or a release? Also, what is the output of the following commands? ghc-pkg describe readline otool -L /usr/local/lib/ghc-6.8.2/ghc-6.8.2 [modified to fit the location/version of your ghc] -Judah From alistair at abayley.org Thu Mar 6 03:27:20 2008 From: alistair at abayley.org (Alistair Bayley) Date: Thu Mar 6 03:24:45 2008 Subject: [Haskell-cafe] Re: ANN: Takusen 0.8 In-Reply-To: <1204761459.11558.286.camel@localhost> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> <20080305173206.GA27155@soi.city.ac.uk> <20080305182625.GA16716@scytale.galois.com> <79d7c4980803051445x3d6a75dag2683977ffde5485f@mail.gmail.com> <20080305230856.GC2942@scytale.galois.com> <1204761459.11558.286.camel@localhost> Message-ID: <79d7c4980803060027n5b15864i132729a62b2f0d96@mail.gmail.com> > Yeah, I really like the single package model. And the Setup.hs does work > -- I just can't use cabal 1.2.x or 1.3.x or 1.4.x with it :) I beg to differ. We have three cabal Setup files in the repo: Setup.hs (for the 1.2 series), Setup-1162.hs, and Setup-114.hs. Setup.hs should work with ghc-6.8 out of the box, Setup-1162.hs should work with ghc-6.6 (once you've upgraded cabal to 1.1.6.2), and Setup-114 I just kept because, well, someone might find it useful. The idea is that you should upgrade cabal to the latest (currently 1.2) and use the Setup.hs, but in case you can't, the older Setup's are hanging around to help. That said, I haven't tested with the latest cabal release, so perhaps it's borken again. > What do you do if the user does not have the ODBC or the postgresql C > libs installed? Do they have to have all backends installed to use just > one? No, we do something you might consider fairly hideous. Having established which libraries are installed on the user's system, we then use that list to filter the module list. So if you don't have Oracle or Sqlite installed, the module list is pruned so that these modules are no longer present in the build. This isn't stricly necessary; another approach would be to simlply build all of the modules. This works fine with ghc (which uses gnu ld for linking). However, with ghci (which has a custom module loader and linker, I think), it seems to attempt to link all of the modules in the lib, and this fails badly if you don;t have every back-end DBMS client installed. The only way I could find to fix that was to adjust the build to only include modules that will link successfully (i.e. those for which you have a DBMS client installed). Alistair From gale at sefer.org Thu Mar 6 03:36:27 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Mar 6 03:33:54 2008 Subject: Cannot link to readline In-Reply-To: <6d74b0d20803060018s32e7e990l299cddee2fbf3271@mail.gmail.com> References: <2608b8a80803052356h4b4c8b7dn497d99e416073442@mail.gmail.com> <2608b8a80803052358t3fd787abifbd1fe1f7a2a7587@mail.gmail.com> <6d74b0d20803060018s32e7e990l299cddee2fbf3271@mail.gmail.com> Message-ID: <2608b8a80803060036r3a498df5nfe437815efb5d835@mail.gmail.com> I wrote: >> On Mac OS X 10.4, I can't link programs that use readline >> unless I explicitly specify the GNUreadline framework >> on the ghc command line... >> Note that this happens for programs that explicitly use >> System.Console.Readline, not in general ghc use. Manuel M T Chakravarty wrote: >>> The readline package spec should include the framework >>> option (if not, its a bug in the config of the readline package IMO). Judah Jacobson wrote: > I agree; the framework is supposed to be linked in automatically. > Yitzchak, what version of GHC are you running? Is it a development > build or a release? The release version 6.6.1, via the (former) standard download link on the GHC web site. > Also, what is the output of the following commands? Pasted below. Thanks, Yitz $ ghc-pkg describe readline name: readline version: 1.0 license: BSD3 copyright: maintainer: libraries@haskell.org stability: homepage: package-url: description: category: author: exposed: True exposed-modules: System.Console.Readline System.Console.SimpleLineEditor hidden-modules: import-dirs: /usr/local/lib/ghc-6.6.1/imports library-dirs: /usr/local/lib/ghc-6.6.1 hs-libraries: HSreadline extra-libraries: extra-ghci-libraries: include-dirs: /usr/local/lib/ghc-6.6.1/include includes: HsReadline.h depends: base-2.1.1 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: /usr/local/share/ghc-6.6.1/html/libraries/readline/readline.haddock haddock-html: /usr/local/share/ghc-6.6.1/html/libraries/readline $ otool -L /usr/local/lib/ghc-6.6.1/ghc-6.6.1 /usr/local/lib/ghc-6.6.1/ghc-6.6.1: GNUreadline.framework/Versions/A/GNUreadline (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.7) GMP.framework/Versions/A/GMP (compatibility version 7.0.0, current version 7.0.0) From ross at soi.city.ac.uk Thu Mar 6 04:11:29 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Mar 6 04:08:56 2008 Subject: [Haskell] ANN: Parsec 3.0.0 In-Reply-To: <1204786736.5936.18.camel@derek-laptop> References: <1204786736.5936.18.camel@derek-laptop> Message-ID: <20080306091129.GA6360@soi.city.ac.uk> [moving from haskell] On Thu, Mar 06, 2008 at 12:58:56AM -0600, Derek Elkins wrote: > This is a first release of the Parsec 3, the Google Summer of Code of > Paolo Martini. You'll need to change the Portability entry on each module, as it now uses MPTCs and FDs. From judah.jacobson at gmail.com Thu Mar 6 04:19:25 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Mar 6 04:16:50 2008 Subject: Cannot link to readline In-Reply-To: <2608b8a80803060036r3a498df5nfe437815efb5d835@mail.gmail.com> References: <2608b8a80803052356h4b4c8b7dn497d99e416073442@mail.gmail.com> <2608b8a80803052358t3fd787abifbd1fe1f7a2a7587@mail.gmail.com> <6d74b0d20803060018s32e7e990l299cddee2fbf3271@mail.gmail.com> <2608b8a80803060036r3a498df5nfe437815efb5d835@mail.gmail.com> Message-ID: <6d74b0d20803060119i3bc0f6b1jf93845a0bb055fae@mail.gmail.com> On Thu, Mar 6, 2008 at 12:36 AM, Yitzchak Gale wrote: > I wrote: > >> On Mac OS X 10.4, I can't link programs that use readline > >> unless I explicitly specify the GNUreadline framework > >> on the ghc command line... > >> Note that this happens for programs that explicitly use > >> System.Console.Readline, not in general ghc use. > > Manuel M T Chakravarty wrote: > > >>> The readline package spec should include the framework > >>> option (if not, its a bug in the config of the readline package IMO). > > > Judah Jacobson wrote: > > I agree; the framework is supposed to be linked in automatically. > > Yitzchak, what version of GHC are you running? Is it a development > > build or a release? > > The release version 6.6.1, via the (former) standard > download link on the GHC web site. > > > Also, what is the output of the following commands? > > $ ghc-pkg describe readline > name: readline > version: 1.0 Ah, OK. The readline package was changed in 6.8 to link with the framework automatically (it did not in 6.6.2 and earlier). If you don't want to update ghc, you can just download version 1.0.1 of readline from hackage and install it manually: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline-1.0.1.0 Hope that helps, -Judah From gale at sefer.org Thu Mar 6 04:33:04 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Mar 6 04:30:28 2008 Subject: Cannot link to readline In-Reply-To: <2608b8a80803060036r3a498df5nfe437815efb5d835@mail.gmail.com> References: <2608b8a80803052356h4b4c8b7dn497d99e416073442@mail.gmail.com> <2608b8a80803052358t3fd787abifbd1fe1f7a2a7587@mail.gmail.com> <6d74b0d20803060018s32e7e990l299cddee2fbf3271@mail.gmail.com> <2608b8a80803060036r3a498df5nfe437815efb5d835@mail.gmail.com> Message-ID: <2608b8a80803060133qa14fc92gea097146ee15fde6@mail.gmail.com> I wrote: >> On Mac OS X 10.4, I can't link programs that use readline >> unless I explicitly specify the GNUreadline framework >> on the ghc command line... That was for GHC 6.6.1, the current binary release version for my platform. Judah Jacobson wrote: > The readline package was changed in 6.8 to link with the > framework automatically... > you can just download version 1.0.1 Well, I just finished compiling 6.8.2 using MacPorts (thanks for that port!). There I have the opposite problem with linking - some symbols are doubly defined. Again, the problem goes away when I specify -framework GNUreadline on the ghc command line: $ ghc --make fooText.hs [4 of 5] Compiling FooText ( FooText.hs, FooText.o ) [5 of 5] Compiling Main ( fooText.hs, fooText.o ) Linking fooText ... /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning multiple definitions of symbol _BC /opt/local/lib/libreadline.dylib(terminal.so) definition of _BC /opt/local/lib/libncurses.dylib(lib_termcap.o) definition of _BC /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning multiple definitions of symbol _UP /opt/local/lib/libreadline.dylib(terminal.so) definition of _UP /opt/local/lib/libncurses.dylib(lib_termcap.o) definition of _UP /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning multiple definitions of symbol _PC /opt/local/lib/libreadline.dylib(terminal.so) definition of _PC /opt/local/lib/libncurses.dylib(lib_tputs.o) definition of _PC $ ghc --make -framework GNUreadline fooText.hs Linking fooText ... $ Here are the package desciption and otool for that build: a$ ghc-pkg describe readline name: readline version: 1.0.1.0 license: GPL copyright: maintainer: libraries@haskell.org stability: homepage: package-url: description: More information on readline can be found at . category: author: exposed: True exposed-modules: System.Console.Readline System.Console.SimpleLineEditor hidden-modules: import-dirs: /opt/local/lib/ghc-6.8.2/lib/readline-1.0.1.0 library-dirs: /opt/local/lib/ghc-6.8.2/lib/readline-1.0.1.0 hs-libraries: HSreadline-1.0.1.0 extra-libraries: readline ncurses extra-ghci-libraries: include-dirs: /opt/local/lib/ghc-6.8.2/lib/readline-1.0.1.0/include includes: HsReadline.h depends: base-3.0.1.0 process-1.0.0.0 hugs-options: cc-options: -I/opt/local/include ld-options: -L/opt/local/lib framework-dirs: frameworks: haddock-interfaces: /opt/local/share/doc/ghc/libraries/readline/readline.haddock haddock-html: /opt/local/share/doc/ghc/libraries/readline $ otool -L /opt/local/lib/ghc-6.8.2/ghc-6.8.2 /opt/local/lib/ghc-6.8.2/ghc-6.8.2: /opt/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.2.0) From gale at sefer.org Thu Mar 6 05:23:28 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Mar 6 05:20:53 2008 Subject: Cannot link to readline In-Reply-To: <2608b8a80803060133qa14fc92gea097146ee15fde6@mail.gmail.com> References: <2608b8a80803052356h4b4c8b7dn497d99e416073442@mail.gmail.com> <2608b8a80803052358t3fd787abifbd1fe1f7a2a7587@mail.gmail.com> <6d74b0d20803060018s32e7e990l299cddee2fbf3271@mail.gmail.com> <2608b8a80803060036r3a498df5nfe437815efb5d835@mail.gmail.com> <2608b8a80803060133qa14fc92gea097146ee15fde6@mail.gmail.com> Message-ID: <2608b8a80803060223s6b54eab0o2af81a76da9c2c4f@mail.gmail.com> I wrote: > Well, I just finished compiling 6.8.2 using MacPorts (thanks for > that port!). There I have the opposite problem with linking - > some symbols are doubly defined. Again, the problem > goes away when I specify -framework GNUreadline on the > ghc command line: After downloading readline 1.0.1.0 from hackage and installing it to both GHC 6.6.1 (binary installation) and GHC 6.8.2 (MacPorts), the problem went away for both compilers. The GNUreadline framework is now listed in the ghc-pkg description for both of them. Kind of odd. Thanks, Yitz From duncan.coutts at worc.ox.ac.uk Thu Mar 6 06:14:17 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 6 06:13:50 2008 Subject: [Haskell-cafe] Re: ANN: Takusen 0.8 In-Reply-To: <79d7c4980803060027n5b15864i132729a62b2f0d96@mail.gmail.com> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> <20080305173206.GA27155@soi.city.ac.uk> <20080305182625.GA16716@scytale.galois.com> <79d7c4980803051445x3d6a75dag2683977ffde5485f@mail.gmail.com> <20080305230856.GC2942@scytale.galois.com> <1204761459.11558.286.camel@localhost> <79d7c4980803060027n5b15864i132729a62b2f0d96@mail.gmail.com> Message-ID: <1204802057.11558.330.camel@localhost> On Thu, 2008-03-06 at 08:27 +0000, Alistair Bayley wrote: > > Yeah, I really like the single package model. And the Setup.hs does work > > -- I just can't use cabal 1.2.x or 1.3.x or 1.4.x with it :) > > I beg to differ. We have three cabal Setup files in the repo: Setup.hs > (for the 1.2 series), Setup-1162.hs, and Setup-114.hs. Setup.hs should > work with ghc-6.8 out of the box, Setup-1162.hs should work with > ghc-6.6 (once you've upgraded cabal to 1.1.6.2), and Setup-114 I just > kept because, well, someone might find it useful. The idea is that you > should upgrade cabal to the latest (currently 1.2) and use the > Setup.hs, but in case you can't, the older Setup's are hanging around > to help. > > That said, I haven't tested with the latest cabal release, so perhaps > it's borken again. I've no idea why people are talking about a Cabal 1.4 release, there's been no such thing. :-) BTW, it's not your responsibility to make your Setup.hs compatible with the current development version of Cabal, it's our aim to keep Cabal-1.4 compatible with existing Setup.hs scripts. That said, I did have a look at your Setup.hs and is does use rather a lot of internal Cabal apis. > > What do you do if the user does not have the ODBC or the postgresql C > > libs installed? Do they have to have all backends installed to use just > > one? > > No, we do something you might consider fairly hideous. Yes, I saw that and was appropriately horrified :-) > Having established which libraries are installed on the user's system, we > then use that list to filter the module list. So if you don't have > Oracle or Sqlite installed, the module list is pruned so that these > modules are no longer present in the build. This isn't stricly > necessary; another approach would be to simlply build all of the > modules. This works fine with ghc (which uses gnu ld for linking). > However, with ghci (which has a custom module loader and linker, I > think), Yes. > it seems to attempt to link all of the modules in the lib, and > this fails badly if you don;t have every back-end DBMS client > installed. Right. > The only way I could find to fix that was to adjust the > build to only include modules that will link successfully (i.e. those > for which you have a DBMS client installed). Yes, or split into multiple libs. I looked yesterday at a slightly nicer way of doing what you're already doing. We can use flags to turn on/off the various backends. What is tricky is doing that such that the default is chosen automagically. We have a way to set the default value of a flag, but just constants True/False. We don't have any mechanism to adjust flags based on code in Setup.hs. I'll ponder it. Duncan From alistair at abayley.org Thu Mar 6 06:32:19 2008 From: alistair at abayley.org (Alistair Bayley) Date: Thu Mar 6 06:29:43 2008 Subject: [Haskell-cafe] Re: ANN: Takusen 0.8 In-Reply-To: <1204802057.11558.330.camel@localhost> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> <20080305173206.GA27155@soi.city.ac.uk> <20080305182625.GA16716@scytale.galois.com> <79d7c4980803051445x3d6a75dag2683977ffde5485f@mail.gmail.com> <20080305230856.GC2942@scytale.galois.com> <1204761459.11558.286.camel@localhost> <79d7c4980803060027n5b15864i132729a62b2f0d96@mail.gmail.com> <1204802057.11558.330.camel@localhost> Message-ID: <79d7c4980803060332r7eead42fs2d45d320f8741c51@mail.gmail.com> > > However, with ghci (which has a custom module loader and linker, I > > think), > > it seems to attempt to link all of the modules in the lib, and > > this fails badly if you don;t have every back-end DBMS client > > installed. > > > The only way I could find to fix that was to adjust the > > build to only include modules that will link successfully (i.e. those > > for which you have a DBMS client installed). > > I looked yesterday at a slightly nicer way of doing what you're already > doing. We can use flags to turn on/off the various backends. What is > tricky is doing that such that the default is chosen automagically. To be fair, this is arguably ghci's fault. If the loader/linker in ghci was more like gnu ld, then we could just build all of the modules, and let the linker handle pulling in the optional bits. But I have no idea if ghc HQ plan to fix it. I don't know if there's another use case for this kind of behaviour that would justify adding it to cabal. Alistair From waldmann at imn.htwk-leipzig.de Thu Mar 6 09:28:12 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Mar 6 09:25:48 2008 Subject: Data.HashTable Message-ID: <47CFFF7C.2040901@imn.htwk-leipzig.de> Hello. When I insert 50 values in an empty hashtable, I get longest chains of length 10. Like this: import Data.HashTable ( HashTable ) import qualified Data.HashTable as H import System.Random main = do t <- H.new ( == ) H.hashInt sequence $ replicate 50 $ do x <- randomRIO ( 0 , 1000 ) H.update t x () lc <- H.longestChain t print lc output: [(831,()),(346,()),(773,()),(475,()),(812,()),(307,()),(113,()),(637,()),(100,())] This is not what I expected (quite the contrary). Did I miss something here? The access time is linear in the length of the longest chain? Perhaps the initial table (produced by "new") is too small, so the table is always overloaded? Looking at http://java.sun.com/javase/6/docs/api/java/util/HashMap.html they start out with table size 16 by default *and* (more importantly) they have a constructor that allows to set the initial table size and the load factor. Best regards, Johannes Waldmann. From haskell at list.mightyreason.com Thu Mar 6 09:33:53 2008 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Thu Mar 6 09:31:29 2008 Subject: Data.HashTable In-Reply-To: <47CFFF7C.2040901@imn.htwk-leipzig.de> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> Message-ID: <47D000D1.3040301@list.mightyreason.com> You probably want to install HsJudy if you need a good hashtable: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsJudy Cheers, Chris From jmaessen at alum.mit.edu Thu Mar 6 11:12:46 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Thu Mar 6 11:10:13 2008 Subject: Data.HashTable In-Reply-To: <47CFFF7C.2040901@imn.htwk-leipzig.de> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> Message-ID: On Mar 6, 2008, at 9:28 AM, Johannes Waldmann wrote: > Hello. > > When I insert 50 values in an empty hashtable, > I get longest chains of length 10. Like this: > > import Data.HashTable ( HashTable ) > import qualified Data.HashTable as H > import System.Random > > main = do > t <- H.new ( == ) H.hashInt > sequence $ replicate 50 $ do > x <- randomRIO ( 0 , 1000 ) > H.update t x () > lc <- H.longestChain t > print lc > > output: > [(831,()),(346,()),(773,()),(475,()),(812,()),(307,()),(113,()),(637, > ()),(100,())] The Data.HashTable code was tuned to favor relatively high bucket loads. Is that a good idea (I ask, having done some of this tuning myself)? It's been a long time since the code was re-tuned, and it's likely some of the decisions ought to change in light of changes in GHC's compiler, GC, and so forth. At the moment: -- ----------------------------------------------------------------------------- -- Parameters tABLE_MAX :: Int32 tABLE_MAX = 32 * 1024 * 1024 -- Maximum size of hash table tABLE_MIN :: Int32 tABLE_MIN = 8 hLOAD :: Int32 hLOAD = 7 -- Maximum average load of a single hash bucket hYSTERESIS :: Int32 hYSTERESIS = 64 -- entries to ignore in load computation {- Hysteresis favors long association-list-like behavior for small tables. -} It's likely modern versions of GHC would fare better with smaller settings of tABLE_MIN, hLOAD, and hYSTERESIS. I seem to recall that doubling the table used to be rather hard on the GC. -Jan > > > This is not what I expected (quite the contrary). > Did I miss something here? The access time is linear in > the length of the longest chain? > Perhaps the initial table (produced by "new") is too small, > so the table is always overloaded? > > > Looking at > http://java.sun.com/javase/6/docs/api/java/util/HashMap.html > they start out with table size 16 by default > *and* (more importantly) they have a constructor that allows > to set the initial table size and the load factor. > > > Best regards, Johannes Waldmann. > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From dons at galois.com Thu Mar 6 14:15:24 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 6 14:13:25 2008 Subject: Data.HashTable In-Reply-To: References: <47CFFF7C.2040901@imn.htwk-leipzig.de> Message-ID: <20080306191524.GB13492@scytale.galois.com> jmaessen: > On Mar 6, 2008, at 9:28 AM, Johannes Waldmann wrote: > > >Hello. > > > >When I insert 50 values in an empty hashtable, > >I get longest chains of length 10. Like this: > > > >import Data.HashTable ( HashTable ) > >import qualified Data.HashTable as H > >import System.Random > > > >main = do > > t <- H.new ( == ) H.hashInt > > sequence $ replicate 50 $ do > > x <- randomRIO ( 0 , 1000 ) > > H.update t x () > > lc <- H.longestChain t > > print lc > > > >output: > >[(831,()),(346,()),(773,()),(475,()),(812,()),(307,()),(113,()),(637, > >()),(100,())] > > The Data.HashTable code was tuned to favor relatively high bucket > loads. Is that a good idea (I ask, having done some of this tuning > myself)? It's been a long time since the code was re-tuned, and it's > likely some of the decisions ought to change in light of changes in > GHC's compiler, GC, and so forth. At the moment: After modifying it for the shootout, I noticed its missing a lot of inline stuff (i.e. tends not to get inlined or specialised). Needs a big overhaul. From jmaessen at alum.mit.edu Thu Mar 6 15:07:14 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Thu Mar 6 15:04:42 2008 Subject: Data.HashTable In-Reply-To: <20080306191524.GB13492@scytale.galois.com> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> <20080306191524.GB13492@scytale.galois.com> Message-ID: <748C5DBE-BCD8-4030-866D-6E8C1C8CC105@alum.mit.edu> On Mar 6, 2008, at 2:15 PM, Don Stewart wrote: > jmaessen: >> On Mar 6, 2008, at 9:28 AM, Johannes Waldmann wrote: >> >>> Hello. >>> >>> When I insert 50 values in an empty hashtable, >>> I get longest chains of length 10. Like this: >>> >>> import Data.HashTable ( HashTable ) >>> import qualified Data.HashTable as H >>> import System.Random >>> >>> main = do >>> t <- H.new ( == ) H.hashInt >>> sequence $ replicate 50 $ do >>> x <- randomRIO ( 0 , 1000 ) >>> H.update t x () >>> lc <- H.longestChain t >>> print lc >>> >>> output: >>> [(831,()),(346,()),(773,()),(475,()),(812,()),(307,()),(113,()), >>> (637, >>> ()),(100,())] >> >> The Data.HashTable code was tuned to favor relatively high bucket >> loads. Is that a good idea (I ask, having done some of this tuning >> myself)? It's been a long time since the code was re-tuned, and it's >> likely some of the decisions ought to change in light of changes in >> GHC's compiler, GC, and so forth. At the moment: > > After modifying it for the shootout, I noticed its missing a lot of > inline stuff (i.e. tends not to get inlined or specialised). Agreed. I'd be curious to see which is more important in practice: picking the right bucket and loading parameters or doing better specialization. Because the hash function is wrapped by the table itself (as opposed to eg. using a Hashable class---I think HBC did this) it's a bit harder to get meaningful specialization: the table itself acts as the dictionary for the hash function, which is the thing one wants inlined. A bit of hand-rolled worker/wrapper might do wonders, though. -Jan > > > Needs a big overhaul. From cgibbard at gmail.com Thu Mar 6 15:16:44 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Mar 6 15:14:07 2008 Subject: Data.HashTable In-Reply-To: <47CFFF7C.2040901@imn.htwk-leipzig.de> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> Message-ID: <89ca3d1f0803061216p3f429d15p6e91dc2f00be157a@mail.gmail.com> On 06/03/2008, Johannes Waldmann wrote: > Hello. > > When I insert 50 values in an empty hashtable, > I get longest chains of length 10. Like this: > The Data.HashTable included with GHC probably shouldn't be. In practice, Data.Map outperforms it in essentially all cases (Data.HashTable stops working beyond a certain size and so any asymptotic benefits, if they exist at all, don't have time to kick in). Moreover, Data.Map has a nice pure interface. The finite maps provided by Data.Map are not actually hash tables, but instead binary balanced trees, but who really cares? :) - Cale From waldmann at imn.htwk-leipzig.de Thu Mar 6 16:43:53 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Mar 6 16:41:17 2008 Subject: Data.HashTable In-Reply-To: <89ca3d1f0803061216p3f429d15p6e91dc2f00be157a@mail.gmail.com> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> <89ca3d1f0803061216p3f429d15p6e91dc2f00be157a@mail.gmail.com> Message-ID: <47D06599.8080806@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > In practice, Data.Map outperforms it in essentially all cases > (Data.HashTable stops working beyond a certain size and so any > asymptotic benefits, if they exist at all, don't have time to kick > in). What! I learned at school, and I teach my students, * balanced binary tree: costs are log(size) * hashtable: cost are essentially constant therefore, hashtable should be preferred in almost all cases (if you know a reasonable hash function and except where you need persistency, of course) the difference should be visible even for moderate sizes (e.g. 1000). With a reasonable implementation I expect log(1000) = 10 comparisons (and dereferencings) for the tree; while the hashtable should have the computation of the hash value (ideally, in registers), one memory access, and one comparison. ... but indeed some experiments with Data.Map and Data.Hashtable support the point you made. That's either good for Data.Map or bad for Data.Hashtable. PS: I did not manage to compile HsJudy-1.0 with ghc-6.8.2 (some hsc file missing - perhaps that should be auto-generated? how?) Best regards, Johannes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0GWZ3ZnXZuOVyMIRAn6FAJ4khFeY0F9dKnB0XyztmUEJq7SiGwCeMm7j cinyds0gCbVeHMcCLY4jP2w= =K9V5 -----END PGP SIGNATURE----- From ndmitchell at gmail.com Thu Mar 6 16:48:53 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Mar 6 16:46:15 2008 Subject: Data.HashTable In-Reply-To: <47D06599.8080806@imn.htwk-leipzig.de> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> <89ca3d1f0803061216p3f429d15p6e91dc2f00be157a@mail.gmail.com> <47D06599.8080806@imn.htwk-leipzig.de> Message-ID: <404396ef0803061348k75a5c668of616fced34ee4a91@mail.gmail.com> Hi > I learned at school, and I teach my students, > * balanced binary tree: costs are log(size) > * hashtable: cost are essentially constant All true, but log(1000) = 10 [nitpick, its nearly always log base 2, not base 10]. 10 ~= constant. > ... but indeed some experiments with Data.Map and Data.Hashtable > support the point you made. That's either good for Data.Map > or bad for Data.Hashtable. I think both of those are true. Hashtable isn't a natural functional data structure, so is ignored, so is not improved. I suspect a Trie would be a much better data structure for most of the uses of Hashtable, but alas there is not one in the standard libraries. Thanks Neil From sebastian.sylvan at gmail.com Thu Mar 6 17:16:22 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu Mar 6 17:13:46 2008 Subject: Data.HashTable In-Reply-To: <404396ef0803061348k75a5c668of616fced34ee4a91@mail.gmail.com> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> <89ca3d1f0803061216p3f429d15p6e91dc2f00be157a@mail.gmail.com> <47D06599.8080806@imn.htwk-leipzig.de> <404396ef0803061348k75a5c668of616fced34ee4a91@mail.gmail.com> Message-ID: <3d96ac180803061416p1433f1c1h8fb299a0213d32b0@mail.gmail.com> On Thu, Mar 6, 2008 at 9:48 PM, Neil Mitchell wrote: > Hi > > > I learned at school, and I teach my students, > > * balanced binary tree: costs are log(size) > > * hashtable: cost are essentially constant > > All true, but log(1000) = 10 [nitpick, its nearly always log base 2, > not base 10]. 10 ~= constant. > > > ... but indeed some experiments with Data.Map and Data.Hashtable > > support the point you made. That's either good for Data.Map > > or bad for Data.Hashtable. > > I think both of those are true. Hashtable isn't a natural functional > data structure, so is ignored, so is not improved. I suspect a Trie > would be a much better data structure for most of the uses of > Hashtable, but alas there is not one in the standard libraries. > How about this one? http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-IntMap.html You can use that to build a purely functional hash table quite easily I suspect (giving you worst case constant time lookup, and no fixed size nonsense, or re-hashing etc.). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080306/4c8dc1b8/attachment.htm From apfelmus at quantentunnel.de Thu Mar 6 17:48:59 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Mar 6 17:46:37 2008 Subject: Data.HashTable In-Reply-To: <47D06599.8080806@imn.htwk-leipzig.de> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> <89ca3d1f0803061216p3f429d15p6e91dc2f00be157a@mail.gmail.com> <47D06599.8080806@imn.htwk-leipzig.de> Message-ID: Johannes Waldmann wrote: > I learned at school, and I teach my students, > * balanced binary tree: costs are log(size) > * hashtable: costs are essentially constant Correction: * hashtable: costs are key size in bits which is always >= log(size) (because: pigeonhole principle) (The size being the number of elements stored, not a preallocated table size. But those two should be proportional anyway.) So, hash tables have no asymptotic benefits, it's all in the constant factors. Regards, apfelmus From jmaessen at alum.mit.edu Thu Mar 6 18:28:10 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Thu Mar 6 18:25:35 2008 Subject: Data.HashTable In-Reply-To: <3d96ac180803061416p1433f1c1h8fb299a0213d32b0@mail.gmail.com> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> <89ca3d1f0803061216p3f429d15p6e91dc2f00be157a@mail.gmail.com> <47D06599.8080806@imn.htwk-leipzig.de> <404396ef0803061348k75a5c668of616fced34ee4a91@mail.gmail.com> <3d96ac180803061416p1433f1c1h8fb299a0213d32b0@mail.gmail.com> Message-ID: <58A52C03-EED9-44EE-B18B-DC59E2AE86C5@alum.mit.edu> On Mar 6, 2008, at 5:16 PM, Sebastian Sylvan wrote: > > > On Thu, Mar 6, 2008 at 9:48 PM, Neil Mitchell > wrote: > Hi > > > I learned at school, and I teach my students, > > * balanced binary tree: costs are log(size) > > * hashtable: cost are essentially constant > > All true, but log(1000) = 10 [nitpick, its nearly always log base 2, > not base 10]. 10 ~= constant. > > > ... but indeed some experiments with Data.Map and Data.Hashtable > > support the point you made. That's either good for Data.Map > > or bad for Data.Hashtable. > > I think both of those are true. Hashtable isn't a natural functional > data structure, so is ignored, so is not improved. I suspect a Trie > would be a much better data structure for most of the uses of > Hashtable, but alas there is not one in the standard libraries. > > How about this one? > http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-IntMap.html > > You can use that to build a purely functional hash table quite > easily I suspect (giving you worst case constant time lookup, and no > fixed size nonsense, or re-hashing etc.). Indeed, during my last go-round on Data.HashTable I used an IntMap to verify several different implementations. But I only ended up putting back some small changes to hashing due to lack of time. -Jan-Willem Maessen > > > > -- > Sebastian Sylvan > +44(0)7857-300802 > UIN: 44640862 _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From haskell-libs at contacts.eelis.net Fri Mar 7 08:16:07 2008 From: haskell-libs at contacts.eelis.net (Eelis van der Weegen) Date: Fri Mar 7 08:13:30 2008 Subject: GetOpt bug causing it to mistakenly reject options as ambiguous Message-ID: <55603.213.84.80.149.1204895767.squirrel@webmail.nxs.nl> [This is a resend; I tried to post through gmane but the message never arrived.] There is a bug in System.Console.GetOpt causing it to mistakenly reject options as ambiguous. Testcase: > import System.Console.GetOpt > > type Color = String > > optsDesc :: [OptDescr Color] > optsDesc = [Option "" ["color", "colour"] (ReqArg id "color") "Foreground color"] > > main = do > let args = ["--col=blue"] > case getOpt RequireOrder optsDesc args of > (_, _, err:_) -> putStrLn err > _ -> return () Output: option `--col' is ambiguous; could be one of: --color=color, --colour=color Foreground color --color=color, --colour=color Foreground color This error is silly, because the two alternatives listed are the same option. The problem is caused by incorrect use of a generator in a list comprehension. I've attached a patch that fixes the problem. Regards, Eelis -------------- next part -------------- A non-text attachment was scrubbed... Name: GetOpt.hs.diff Type: text/x-patch Size: 861 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080307/f63eba78/GetOpt.hs.bin From waldmann at imn.htwk-leipzig.de Sat Mar 8 11:35:55 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Mar 8 11:33:01 2008 Subject: Data.HashTable In-Reply-To: <20080307230824.GA189982@localhost> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> <89ca3d1f0803061216p3f429d15p6e91dc2f00be157a@mail.gmail.com> <47D06599.8080806@imn.htwk-leipzig.de> <20080307230824.GA189982@localhost> Message-ID: <47D2C06B.8010507@imn.htwk-leipzig.de> Hello. I could build HsJudy-0.2, meanwhile. Thanks. It is not an immediate replacement for Data.Map or Data.HashTable, though? I figure I need some wrapper code (instances of Stringable and Refeable) but the documentation is somewhat terse. For Stringable I can guess the meaning of to/fromString, but I have no idea how I should implement the other methods. - (I also do not see why I need fromString.) For Refeable - what is the "Value" type? Best regards, Johannes. From gale at sefer.org Sun Mar 9 06:12:57 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Mar 9 06:10:12 2008 Subject: Cabal semantics for multiple compilers Message-ID: <2608b8a80803090312v3d3019f5o4efd9dd844ced3aa@mail.gmail.com> In anticipation of the upcoming release of the Mac OS X Tiger installer for GHC 6.8.2, the following questions arise: I currently have GHC 6.8.2 installed via MacPorts in /opt/local. When I use Cabal to install packages manually, they install into /usr/local. I think that is the correct behavior - if that package someday becomes a supported port, the port will install into /opt/local and I don't want to conflict with that. In general, I leave the entire /opt/local tree under the control of the automated port system. Now, what will happen when I install a second copy of GHC 6.8.2 into /usr/local using the installer? First question: What will --with-compiler=ghc-6.8.2 now mean if I forget to specify the full path? Will Cabal do something reasonable and not get confused? (Will it not get confused if I do remember to specify the full path?) Second question: When I install packages, both copies of GHC 6.8.2 will want to install them into /usr/local. Cabal uses directory names like "ghc-6.8.2" to keep installations for different compilers separate from each other. But what if both of the compilers are called "ghc-6.8.2"? Thanks, Yitz From duncan.coutts at worc.ox.ac.uk Sun Mar 9 15:45:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 9 15:42:25 2008 Subject: Cabal semantics for multiple compilers In-Reply-To: <2608b8a80803090312v3d3019f5o4efd9dd844ced3aa@mail.gmail.com> References: <2608b8a80803090312v3d3019f5o4efd9dd844ced3aa@mail.gmail.com> Message-ID: <1205091910.11558.489.camel@localhost> On Sun, 2008-03-09 at 12:12 +0200, Yitzchak Gale wrote: > In anticipation of the upcoming release of the > Mac OS X Tiger installer for GHC 6.8.2, the > following questions arise: > > I currently have GHC 6.8.2 installed via MacPorts > in /opt/local. When I use Cabal to install packages > manually, they install into /usr/local. I think that > is the correct behavior - if that package someday > becomes a supported port, the port will install > into /opt/local and I don't want to conflict with that. > In general, I leave the entire /opt/local tree under > the control of the automated port system. > > Now, what will happen when I install a second > copy of GHC 6.8.2 into /usr/local using the installer? > > First question: What will --with-compiler=ghc-6.8.2 > now mean if I forget to specify the full path? Will Cabal > do something reasonable and not get confused? > (Will it not get confused if I do remember to specify > the full path?) It will use whichever is the ghc-6.8.2 on the $PATH. Alternatively you can specify the full path. It'll also look for a ghc-pkg-6.8.2 in the same directory in which it found ghc-6.8.2 (unless you override using --with-hc-pkg=). It'll use that to discover what packages are registered. So it's quite possible to have multiple installations of ghc of various versions and indeed of other Haskell implementations. > Second question: When I install packages, both copies > of GHC 6.8.2 will want to install them into /usr/local. Cabal > uses directory names like "ghc-6.8.2" to keep installations > for different compilers separate from each other. But what > if both of the compilers are called "ghc-6.8.2"? Then they will clash. Don't do that :-) You can have two instances of the same version of GHC installed (though quite why you'd want to do that I'm not sure) but you will have to ensure that you use different places to install packages for each or they will clash and you will get mysterious linker errors or worse. Duncan From gale at sefer.org Sun Mar 9 19:37:57 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Mar 9 19:35:09 2008 Subject: Cabal semantics for multiple compilers In-Reply-To: <1205091910.11558.489.camel@localhost> References: <2608b8a80803090312v3d3019f5o4efd9dd844ced3aa@mail.gmail.com> <1205091910.11558.489.camel@localhost> Message-ID: <2608b8a80803091637m5112637ct3b28e8f539f92029@mail.gmail.com> I wrote: >> I currently have GHC 6.8.2 installed via MacPorts >> in /opt/local. When I use Cabal to install packages >> manually, they install into /usr/local... >> Now, what will happen when I install a second >> copy of GHC 6.8.2 into /usr/local using the installer? >> First question: What will --with-compiler=ghc-6.8.2 >> now mean if I forget to specify the full path? Duncan Coutts wrote: > It will use whichever is the ghc-6.8.2 on the $PATH. They'll both be in $PATH. So do you mean the first one? Will that work consistently throughout the install process? >> Second question: When I install packages, both copies >> of GHC 6.8.2 will want to install them into /usr/local. Cabal >> uses directory names like "ghc-6.8.2" to keep installations >> for different compilers separate from each other. But what >> if both of the compilers are called "ghc-6.8.2"? > Then they will clash. Don't do that :-) Ouch. I was afraid of that. This is going to be tricky. > You can have two instances of the same version > of GHC installed (though quite why you'd want to > do that I'm not sure) Well, a MacPorts port and a binary install each have their advantages and disadvantages. (Think ebuild vs. apt/yum/rpm on linux.) It is certainly conceivable that you'd want both, each configured differently. I will definitely need both to coexist at least for a while as I transition from MacPorts back to the binary install when it is ready. Another example: if we adopt Simon's idea of GHC distributions - and I think we should - then we are likely to see several such distributions, tailored for different needs, and some people installing more than one of them. Thanks, Yitz From duncan.coutts at worc.ox.ac.uk Sun Mar 9 20:25:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 9 20:22:32 2008 Subject: Cabal semantics for multiple compilers In-Reply-To: <2608b8a80803091637m5112637ct3b28e8f539f92029@mail.gmail.com> References: <2608b8a80803090312v3d3019f5o4efd9dd844ced3aa@mail.gmail.com> <1205091910.11558.489.camel@localhost> <2608b8a80803091637m5112637ct3b28e8f539f92029@mail.gmail.com> Message-ID: <1205108719.11558.684.camel@localhost> On Mon, 2008-03-10 at 01:37 +0200, Yitzchak Gale wrote: > Duncan Coutts wrote: > > It will use whichever is the ghc-6.8.2 on the $PATH. > > They'll both be in $PATH. So do you mean the first > one? Will that work consistently throughout the install > process? Yep. > >> Second question: When I install packages, both copies > >> of GHC 6.8.2 will want to install them into /usr/local. Cabal > >> uses directory names like "ghc-6.8.2" to keep installations > >> for different compilers separate from each other. But what > >> if both of the compilers are called "ghc-6.8.2"? > > > Then they will clash. Don't do that :-) > > Ouch. I was afraid of that. This is going to be tricky. Remember of course that you can do per-user installs. Indeed it's much easier, cabal-install does that by default. Duncan From gale at sefer.org Sun Mar 9 20:44:23 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Mar 9 20:41:36 2008 Subject: Cabal semantics for multiple compilers In-Reply-To: <1205108719.11558.684.camel@localhost> References: <2608b8a80803090312v3d3019f5o4efd9dd844ced3aa@mail.gmail.com> <1205091910.11558.489.camel@localhost> <2608b8a80803091637m5112637ct3b28e8f539f92029@mail.gmail.com> <1205108719.11558.684.camel@localhost> Message-ID: <2608b8a80803091744m5a2760edge346dcccb309e2cd@mail.gmail.com> I wrote: >>>> When I install packages, both copies >>>> of GHC 6.8.2 will want to install them into /usr/local. Duncan Coutts wrote: >>> Then they will clash. Don't do that :-) >> Ouch. I was afraid of that. This is going to be tricky. > Remember of course that you can do per-user installs. > Indeed it's much easier, cabal-install does that by default. Thanks for the tip. I'll think about that. -Yitz From dons at galois.com Tue Mar 11 14:13:15 2008 From: dons at galois.com (Don Stewart) Date: Tue Mar 11 14:10:32 2008 Subject: Proposal: add some missing tuple functions Message-ID: <20080311181315.GD8667@scytale.galois.com> Basic texts often define swap, fst3, snd3 and thd3 So let's add them to the rather bare Data.Tuple. The fst3.. series were approved to be added a couple of years ago, but I never got around to it. The patch is attached. -- Don -------------- next part -------------- New patches: [Some long missing tuple functions Don Stewart **20080311180851] { hunk ./Data/Tuple.hs 278 +-- | Swap components of a pair +swap (x,y) = (y,x) + +-- | Extract the first component of a triple. +fst3 :: (a,b,c) -> a +fst3 (x,_,_) = x + +-- | Extract the second component of a triple. +snd3 :: (a,b,c) -> a +snd3 (_,y,_) = y + +-- | Extract the third component of a triple. +thd3 :: (a,b,c) -> a +thd3 (_,_,z) = z + + } Context: [untabify Don Stewart **20080310005455] [untabify Don Stewart **20080308014256] [untabify Don Stewart **20080308014129] [untabify Don Stewart **20080308014040] [untabify Don Stewart **20080308013556] [untabify Don Stewart **20080308012457] [untabify Don Stewart **20080308012059] [untabify Don Stewart **20080307192727] [untabify Don Stewart **20080305033712] [untabify Don Stewart **20080305015827] [untabify Don Stewart **20080305012530] [untabify Don Stewart **20080305010343] [untabify Don Stewart **20080305010255] [untabify Don Stewart **20080305005041] [untabify Don Stewart **20080305005025] [untabify Don Stewart **20080304235330] [untabify Don Stewart **20080304225120] [untabify Don Stewart **20080304174827] [untabify Don Stewart **20080303195109] [untabify Don Stewart **20080303195002] [untabify Don Stewart **20080303194454] [untabify Don Stewart **20080228234443] [untabify Don Stewart **20080228185409] [untabify Don Stewart **20080228185356] [untabify Don Stewart **20080228185331] [export MVar, TVar, and STM non-abstractly Simon Marlow **20080228113035 As requested by Sterling Clover on ghc-users ] [Added Down class and improved groupWith fusion Max Bolingbroke **20080213212246] [untabify Don Stewart **20080227062836] [untabify Don Stewart **20080226070630] [mention explicitly that hIsEOF may block Simon Marlow **20080220141209] [untabify Don Stewart **20080219233644] [untabify Don Stewart **20080219233047] [untabify Don Stewart **20080219232910] [untabify Don Stewart **20080219225437] [untabify Don Stewart **20080219061513] [Add exitSuccess :: IO a. For symmetry with exitFailure Don Stewart **20080213222644] [untabify Don Stewart **20080218075732] [untabify Don Stewart **20080218065411] [untabify Don Stewart **20080215005543] [FIX dynamic001, dynamic002: further fixes to tuple printing Simon Marlow **20080211101908] [untabify Don Stewart **20080213221950] [untabify only Don Stewart **20080213221856] [whitespace only Don Stewart **20080207191939] [Whitespace only Don Stewart **20080207183954] [FIX dynamic001 dynamic002: isTupleTyCon had rotted Simon Marlow **20080205103904 In the patch "Tuple tycons have parens around their names", the names of the tuple tycons were changed to include parens, but isTupleTyCon was not updated to match, which made tuple types show as "(,) a b" rather than "(a,b)" ] [deforestation rules for enumFromThenTo; based on a patch from Robin Houston Ian Lynagh **20080203152755] [Generalise type of forever :: (Monad m) => m a -> m b Don Stewart **20080129191940] [FIX #1936: hGetBufNonBlocking was blocking on stdin/stdout/stderr Simon Marlow **20080124092203] [The default uncaught exception handler was adding an extra \n Simon Marlow **20080124091216] [add comment about lack of _chsize_s() Simon Marlow **20080123131248] [Windows: large file support for hFileSize and hSeek (#1771) Simon Marlow **20080123102904 ] [Export topHandler, topHandlerFastExit from GHC.TopHandler Ian Lynagh **20080120182429 We now use one of these in ghc when running with ghc -e ] [haddock attributes for haddock-2.0 Ross Paterson **20080120022308] [Data.List.sort: force elements from start to end. Bertram Felgenhauer **20071121101458 this prevents a stack overflow on sort (take 10^6 [1..]) ] [Fix comment on GHC.Ptr.minusPtr simonpj@microsoft.com**20080109114736] [Remove redundant imports of GHC.Err simonpj@microsoft.com**20080104091314 GHC.Base SOURCE-imports GHC.Err, and re-exports 'error'. So other modules need only import GHC.Base. This doesn't change the fact that these other modules are all compiled before GHC.Err, so they are all part of the module loop that starts with GHC.Base and finishes with GHC.Err. But it does reduce the occurrence of those SOURCE imports. ] [Tuple tycons have parens around their names simonpj@microsoft**20071220171812 The name of the pair TyCon, in the Typeable instance, should be "(,)" not ",". Don't merge to 6.8; it's a minor API change. ] [Add groupWith, sortWith, the, to support generalised list comprehensions simonpj@microsoft.com**20071220111929 This the base-library patch to support the main compiler patch Implement generalised list comprehensions It just adds three functions to GHC.Exts. ] [Add GHC.Prim to exposedModules in the Haddock 0.x hook David Waern *-20071209173931 Please merge to the stable branch ] [Add GHC.Prim to exposedModules in the Haddock 0.x hook David Waern **20071209173931 Please merge to the stable branch ] [Simplify the GHC.Prim hack in base.cabal/Setup.hs Ian Lynagh **20071202215758] [Implement 'openTempFile' for nhc98. Malcolm.Wallace@cs.york.ac.uk**20071207133335] [docs: describe the changes to forkIO, and document forkOnIO Simon Marlow **20071205091423] [doc only: use realToFrac instead of fromRational.toRational Simon Marlow **20071205091334] [Add singletonP to GHC.PArr Roman Leshchinskiy **20071205220859] [FIX #1621: bug in Windows code for getCPUTime Simon Marlow **20071205120118 We were reading the components of FILETIME as CLong, when they should be unsigned. Word32 seems to be the correct type here. ] [protect console handler against concurrent access (#1922) Simon Marlow **20071204153940] [protect against concurrent access to the signal handlers (#1922) Simon Marlow **20071204110817] [restore fdToHandle' to avoid breaking clients (#1109) Simon Marlow **20071130135122 ] [note about how to convert CTime (aka EpochTime) to UTCTime Simon Marlow **20071130101648] [Fix some URLs Ian Lynagh **20071126214213] [Fix some links in haddock docs Ian Lynagh **20071126184428] [Don't try to make haddock links to the mtl package as we don't depend on it Ian Lynagh **20071126170631] [Escape some special characters in haddock docs Ian Lynagh **20071126163443] [FIX BUILD: maybeUpdateFile: ignore failures when removing the target Simon Marlow **20071123092219] [FIX #1753 Simon Marlow **20071122094207 hClose should close the Handle and unlock the file even if calling close() fails for some reason. ] [remove lockFile.h from install-includes Simon Marlow **20071121102248] [oops, we forgot to export traceShow Simon Marlow **20071121094300] [Fix compilation with GHC 6.2.x Simon Marlow **20071121084341] [Move file locking into the RTS, fixing #629, #1109 Simon Marlow **20071120121053 File locking (of the Haskell 98 variety) was previously done using a static table with linear search, which had two problems: the array had a fixed size and was sometimes too small (#1109), and performance of lockFile/unlockFile was suboptimal due to the linear search. Also the algorithm failed to count readers as required by Haskell 98 (#629). Now it's done using a hash table (provided by the RTS). Furthermore I avoided the extra fstat() for every open file by passing the dev_t and ino_t into lockFile. This and the improvements to the locking algorithm result in a healthy 20% or so performance increase for opening/closing files (see openFile008 test). ] [Only overwrite GHC/Prim.hs and GHC/Primopwrappers.hs if they change Simon Marlow **20071120102042 This avoids make doing unnecessary work after 'setup makefile'. ] [fix comment Simon Marlow **20071116091227] [Fix ` characters in elem's haddock docs Ian Lynagh **20071110173052] [Filter out GHC.Prim also for the Haddock step David Waern **20071109000806 Please merge to the GHC 6.8.2 branch ] [Add module of special magic GHC desugaring helper functions Simon Marlow **20071102160054 Currently containing only one such helper: (>>>) for arrow desugaring ] [add Control.Category to the nhc98 build Malcolm.Wallace@cs.york.ac.uk**20071030120459] [fix nhc98 build: need a qualified Prelude import Malcolm.Wallace@cs.york.ac.uk**20071030120410] [Fix performance regression: re-instate -funbox-strict-fields Simon Marlow **20071029150730 Yikes! While investigating the increase in code size with GHC 6.8 relative to 6.6, I noticed that in the transition to Cabal for the libraries we lost -funbox-strict-fields, which is more or less depended on by the IO library for performance. I'm astonished that we didn't notice this earlier! To reduce the chances of this happening again, I put -funbox-strict-fields in the OPTIONS_GHC pragma of the modules that need it. {-# UNPACK #-} pragmas would be better, though. ] [FIX BUILD: Haddock 1.x fails to parse (Prelude..) Simon Marlow **20071029131921] [new Control.Category, ghc ticket #1773 Ashley Yakeley **20071029022526] [new Control.Compositor module Ashley Yakeley **20071013074851 The Compositor class is a superclass of Arrow. ] [Fix doc building with Haddock 0.9 Simon Marlow **20071024090947 I was using a recent build here, which is more tolerant. ] [FIX #1258: document that openTempFile is secure(ish) Simon Marlow **20071023130928 Also change the mode from 0666 to 0600, which seems like a more sensible value and matches what C's mkstemp() does. ] [Clean up .cabal file a bit Duncan Coutts **20071022132708 specify build-type and cabal-version >= 1.2 put extra-tmp-files in the right place use os(windows) rather than os(mingw32) ] [base in 6.8 and head branch should be version 3.0 Don Stewart **20071007150408] [FIX #1652: openTempFile should accept an empty string for the directory Simon Marlow **20071018122345] [clean up duplicate code Simon Marlow **20071017141311] [expose the value of +RTS -N as GHC.Conc.numCapabilities (see #1733) Simon Marlow **20071009132042] [typo Simon Marlow **20070917130703] [put extra-tmp-files field in the right place Simon Marlow **20070914140812] [Add more entries to boring file Ian Lynagh **20070913210500] [Add a boring file Ian Lynagh **20070913204641] [TAG 2007-09-13 Ian Lynagh **20070913215720] [FIX #1689 (openTempFile returns wrong filename) Tim Chevalier **20070913052025] [TAG ghc-6.8 branched 2007-09-03 Ian Lynagh **20070903155541] [Remove some incorrect rules; fixes #1658: CSE [of Doubles] changes semantics Ian Lynagh **20070904134140] [make hWaitForInput/hReady not fail with "invalid argument" on Windows Simon Marlow **20070830131115 See #1198. This doesn't fully fix it, because hReady still always returns False on file handles. I'm not really sure how to fix that. ] [Fix haddock docs in Hashtable Ian Lynagh **20070830154131] [Fix building HashTable: Use ord rather than fromEnum Ian Lynagh **20070830150214] [Better hash functions for Data.HashTable, from Jan-Willem Maessen Ian Lynagh **20070830142844] [Remove redundant include/Makefile Ian Lynagh **20070828205659] [Make arrays safer (e.g. trac #1046) Ian Lynagh **20070810163405] [delete configure droppings in setup clean Simon Marlow **20070824104100] [FIX #1282: 64-bit unchecked shifts are not exported from base Simon Marlow **20070823135033 I've exported these functions from GHC.Exts. They are still implemented using the FFI underneath, though. To avoid conditional exports, on a 64-bit build: uncheckedShiftL64# = uncheckShiftL# (etc.) which has a different type than the 32-bit version of uncheckedShiftL64#, but at least GHC.Exts exports the same names. ] [Fix hashInt Ian Lynagh **20070821140706 As pointed out in http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-August/009545.html the old behaviour was Prelude Data.HashTable> map hashInt [0..10] [0,-1,-1,-2,-2,-2,-3,-3,-4,-4,-4] Fixed according to the "Fibonacci Hashing" algorithm described in http://www.brpreiss.com/books/opus4/html/page213.html http://www.brpreiss.com/books/opus4/html/page214.html ] [test impl(ghc) instead of IsGHC Ross Paterson **20070819233500] [fpstring.h has moved to bytestring Ross Paterson **20070819233815] [remove now-unused SIG constants Ross Paterson **20070819233745] [include Win32 extra-libraries for non-GHC's too Ross Paterson **20070819233611] [Don't import Distribution.Setup in Setup.hs as we no longer need it Ian Lynagh **20070816151643] [Correct the swapMVar haddock doc Ian Lynagh **20070814145028] [install Typeable.h for use by other packages Malcolm.Wallace@cs.york.ac.uk**20070813112855] [Don't try to build modules no longer living in base. Malcolm.Wallace@cs.york.ac.uk**20070813112803] [Move Data.{Foldable,Traversable} back to base Ian Lynagh **20070812165654 The Array instances are now in Data.Array. ] [Remove bits left over from the old build system Ian Lynagh **20070811135019] [Move the datamap001 (our only test) to the containers package Ian Lynagh **20070803180932] [Data.Array* and Data.PackedString have now moved to their own packages Ian Lynagh **20070801235542] [Remove a number of modules now in a "containers" package Ian Lynagh **20070801223858] [Remove System.Posix.Signals (moving to unix) Ian Lynagh **20070729215213] [bytestring is now in its own package Ian Lynagh **20070729132215] [Export throwErrnoPath* functions Ian Lynagh **20070722002923] [Add simple haddock docs for throwErrnoPath* functions Ian Lynagh **20070722002817] [Move throwErrnoPath* functions from unix:System.Posix.Error Ian Lynagh **20070722002746] [Clarify the swapMVar haddock doc Ian Lynagh **20070807185557] [fix Haddock markup Simon Marlow **20070802081717] [Temporarily fix breakage for nhc98. Malcolm.Wallace@cs.york.ac.uk**20070801163750 A recent patch to System.IO introduced a cyclic dependency on Foreign.C.Error, and also inadvertently dragged along System.Posix.Internals which has non-H'98 layout, causing many build problems. The solution for now is to #ifndef __NHC__ all of the recent the openTempFile additions, and mark them non-portable once again. (I also took the opportunity to note a number of other non-portable functions in their Haddock comments.) ] [Generalise the type of synthesize, as suggested by Trac #1571 simonpj@microsoft**20070801125208 I have not looked at the details, but the type checker is happy with the more general type, and more general types are usually a Good Thing. ] [Fix fdToHandle on Windows Ian Lynagh **20070730133139 The old setmode code was throwing an exception, and I'm not sure it is meant to do what we need anyway. For now we assume that all FDs are both readable and writable. ] [Correct Windows OS name in cabal configuration Ian Lynagh **20070729161739] [Use cabal configurations rather than Setup hacks Ian Lynagh **20070729132157] [Handle buffers should be allocated with newPinnedByteArray# always Simon Marlow **20070725095550 Not just on Windows. This change is required because we now use safe foreign calls for I/O on blocking file descriptors with the threaded RTS. Exposed by concio001.thr on MacOS X: MacOS apparently uses smaller buffers by default, so they weren't being allocated as large objects. ] [fix Hugs implementation of openTempFile Ross Paterson **20070724114003] [Hugs only: avoid dependency cycle Ross Paterson **20070724113852] [open(Binary)TempFile is now portable Ian Lynagh **20070722152752] [Tweak temporary file filename chooser Ian Lynagh **20070722105445] [Move open(Binary)TempFile to System.IO Ian Lynagh **20070722010205] [Rename openFd to fdToHandle' Ian Lynagh **20070721235538 The name collision with System.Posix.IO.openFd made my brain hurt. ] [Add a test for Data.Map, for a bug on the libraries@ list Ian Lynagh **20070721002119] [fix Data.Map.updateAt Bertram Felgenhauer **20070718150340 See http://haskell.org/pipermail/libraries/2007-July/007785.html for a piece of code triggering the bug. updateAt threw away parts of the tree making up the map. ] [in hClose, free the handle buffer by replacing it with an empty one Simon Marlow **20070719161419 This helps reduce the memory requirements for a closed but unfinalised Handle. ] [Implement GHC.Environment.getFullArgs Ian Lynagh **20070717141918 This returns all the arguments, including those normally eaten by the RTS (+RTS ... -RTS). This is mainly for ghc-inplace, where we need to pass /all/ the arguments on to the real ghc. e.g. ioref001(ghci) was failing because the +RTS -K32m -RTS wasn't getting passed on. ] [Define stripPrefix; fixes trac #1464 Ian Lynagh **20070714235204] [no need to hide Maybe Malcolm.Wallace@cs.york.ac.uk**20070710154058] [Add a more efficient Data.List.foldl' for GHC (from GHC's utils/Util.lhs) Ian Lynagh **20070706205526] [Remove include-dirs ../../includes and ../../rts Ian Lynagh **20070705205356 We get these by virtue of depending on the rts package. ] [FIX #1131 (newArray_ allocates an array full of garbage) Simon Marlow **20070704102020 Now newArray_ returns a deterministic result in the ST monad, and behaves as before in other contexts. The current newArray_ is renamed to unsafeNewArray_; the MArray class therefore has one more method than before. ] [change nhc98 option from -prelude to --prelude Malcolm.Wallace@cs.york.ac.uk**20070702150355] [Word is a type synonym in nhc98 - so class instance not permitted. Malcolm.Wallace@cs.york.ac.uk**20070629122035] [fix bug in writes to blocking FDs in the non-threaded RTS Simon Marlow **20070628134320] [Modernize printf. lennart.augustsson@credit-suisse.com**20070628083852 Add instances for Int8, Int16, Int32, Int64, Word, Word8, Word16, Word32, and Word64. Handle + flag. Handle X, E, and G formatting characters. Rewrite internals to make it simpler. ] [Speed up number printing and remove the need for Array by using the standard 'intToDigit' routine John Meacham **20070608182353] [Use "-- //" (2 spaces) rather than "-- //" (1) to avoid tripping haddock up Ian Lynagh **20070627010930 Are we nearly there yet? ] [Use a combination of Haskell/C comments to ensure robustness. Malcolm.Wallace@cs.york.ac.uk**20070626095222 e.g. -- // ensures that _no_ preprocessor will try to tokenise the rest of the line. ] [Change C-style comments to Haskell-style. Malcolm.Wallace@cs.york.ac.uk**20070625094515 These two headers are only ever used for pre-processing Haskell code, and are never seen by any C tools except cpp. Using the Haskell comment convention means that cpphs no longer needs to be given the --strip option to remove C comments from open code. This is a Good Thing, because all of /* */ and // are valid Haskell operator names, and there is no compelling reason to forbid using them in files which also happen to have C-preprocessor directives. ] [makefileHook needs to generate PrimopWrappers.hs too Simon Marlow **20070622073424] [Hugs now gets MonadFix(mfix) from its prelude Ross Paterson **20070620000343] [Typo (consUtils.hs -> consUtils.h) Ian Lynagh **20070619124140] [install dependent include files and Typeable.h Bertram Felgenhauer **20070613041734] [update prototype following inputReady->fdReady change Simon Marlow **20070614095309] [FIX hGetBuf001: cut-and-pasto in readRawBufferNoBlock Simon Marlow **20070614094222] [fix description of CWStringLen Ross Paterson **20070605223345] [Remove unsafeCoerce-importing kludgery in favor of Unsafe.Coerce Isaac Dupree **20070601203625] [--configure-option and --ghc-option are now provided by Cabal Ross Paterson **20070604115233] [Data.PackedString: Data.Generics is GHC-only Ross Paterson **20070529232427] [Add Data instance for PackedString; patch from greenrd in trac #1263 Ian Lynagh **20070529205420] [Control.Concurrent documentation fix shae@ScannedInAvian.com**20070524163325] [add nhc98-options: field to .cabal file Malcolm.Wallace@cs.york.ac.uk**20070528122626] [add a dummy implementation of System.Timeout.timeout for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070528110309] [Add System.Timeout to base.cabal Ian Lynagh **20070527123314 Filtered out for non-GHC by Setup.hs. ] [add module Data.Fixed to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070525141021] [DIRS now lives in package Makefile, not script/pkgdirlist Malcolm.Wallace@cs.york.ac.uk**20070525111749] [delete unused constants Ross Paterson **20070525001741] [remove System.Cmd and System.Time too Malcolm.Wallace@cs.york.ac.uk**20070524163200] [remove locale as well Malcolm.Wallace@cs.york.ac.uk**20070524161943] [nhc98 version of instance Show (a->b) copied from Prelude Malcolm.Wallace@cs.york.ac.uk**20070524160615] [remove directory, pretty, and random bits from base for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070524160608] [Remove Makefile and package.conf.in (used in the old build system) Ian Lynagh **20070524142545] [Split off process package Ian Lynagh **20070523210523] [Fix comment: maperrno is in Win32Utils.c, not runProcess.c Ian Lynagh **20070523181331] [System.Locale is now split out Ian Lynagh **20070519132638] [Split off directory, random and old-time packages Ian Lynagh **20070519120642] [Remove Control.Parallel*, now in package parallel Ian Lynagh **20070518165431] [Remove the pretty-printing modules (now in package pretty( Ian Lynagh **20070518162521] [add install-includes: field Simon Marlow **20070517094948] [correct the documentation for newForeignPtr Simon Marlow **20070516082019] [When doing safe writes, handle EAGAIN rather than raising an exception Simon Marlow **20070515114615 It might be that stdin was set to O_NONBLOCK by someone else, and we should handle this case. (this happens with GHCi, I'm not quite sure why) ] [Use FilePath to make paths when building GHC/Prim.hs and GHC/PrimopWrappers.hs Ian Lynagh **20070514110409] [Build GHC/Prim.hs and GHC/PrimopWrappers.hs from Cabal Ian Lynagh **20070509142655] [fix imports for non-GHC Ross Paterson **20070513001138] [Give an example of how intersection takes elements from the first set Ian Lynagh **20070512160253] [further clarify the docs for 'evaluate' Malcolm.Wallace@cs.york.ac.uk**20070508101124] [improve documentation for evaluate Simon Marlow **20070508081712] [FIX: #724 (tee complains if used in a process started by ghc) Simon Marlow **20070507123537 Now, we only set O_NONBLOCK on file descriptors that we create ourselves. File descriptors that we inherit (stdin, stdout, stderr) are kept in blocking mode. The way we deal with this differs between the threaded and non-threaded runtimes: - with -threaded, we just make a safe foreign call to read(), which may block, but this is ok. - without -threaded, we test the descriptor with select() before attempting any I/O. This isn't completely safe - someone else might read the data between the select() and the read() - but it's a reasonable compromise and doesn't seem to measurably affect performance. ] [the "unknown" types are no longer required Simon Marlow **20070426135931] [Make Control.Exception buildable by nhc98. Malcolm.Wallace@cs.york.ac.uk**20070504105548 The nhc98 does not have true exceptions, but these additions should be enough infrastructure to pretend that it does. Only IO exceptions will actually work. ] [Trim imports, remove a cycle simonpj@microsoft**20070503123010 A first attempt at removing gratuitous cycles in the base package. I've removed the useless module GHC.Dynamic, which gets rid of a cycle; and trimmed off various unnecesary imports. This also fixes the IsString import problem. ] [Be less quiet about building the base package simonpj@microsoft**20070503093707] [Remove Splittable class (a vestige of linear implicit parameters) simonpj@microsoft**20070221104329] [Add IsString to exports of GHC.Exts simonpj@microsoft**20070221104249] [tweak documentation as per suggestion from Marc Weber on libraries@haskell.org Simon Marlow **20070426075921] [Add extra libraries when compiling with GHC on Windows Ian Lynagh **20070424213127] [Follow Cabal changes in Setup.hs Ian Lynagh **20070418114345] [inclusion of libc.h is conditional on __APPLE__ Malcolm.Wallace@cs.york.ac.uk**20070417085556] [MERGE: fix ugly uses of memcpy foreign import inside ST Simon Marlow **20070416101530 fixes cg026 ] [Fix configure with no --with-cc Ian Lynagh **20070415165143] [MacOS 10.3 needs #include as well Malcolm.Wallace@cs.york.ac.uk**20070414155507] [For nhc98 only, use hsc2hs to determine System.Posix.Types. Malcolm.Wallace@cs.york.ac.uk**20070413155831 Avoids the existing autoconf stuff, by introducing an auxiliary module called NHC.PosixTypes that uses hsc2hs, which is then simply re-exported from System.Posix.Types. ] [we need a makefileHook too Simon Marlow **20070413151307] [Remove unnecesary SOURCE import of GHC.Err in GHC.Pack Ian Lynagh **20070412235908] [add System.Posix.Types to default nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070412195026] [mark System.IO.openTempFile as non-portable in haddocks Malcolm.Wallace@cs.york.ac.uk**20070412135359] [Don't turn on -Werror in Data.Fixed Ian Lynagh **20070411155721 This may be responsible for the x86_64/Linux nightly build failing. ] [Fix -Wall warnings Ian Lynagh **20070411004929] [Add missing case in removePrefix Ian Lynagh **20070411002537] [Allow additional options to pass on to ./configure to be given Ian Lynagh **20070406151856] [Hugs only: fix location of unsafeCoerce Ross Paterson **20070406113731] [fix isPortableBuild test Ross Paterson **20070406111304] [Unsafe.Coerce doesn't need Prelude Ian Lynagh **20070405175930] [make Setup and base.cabal suitable for building the libraries with GHC Ian Lynagh **20070308163824] [HsByteArray doesn't exist Ian Lynagh **20070404163051] [Don't use Fd/FD in foreign decls Ian Lynagh **20070404155822 Using CInt makes it much easier to verify that it is right, and we won't get caught out by possible newtype switches between CInt/Int. ] [HsByteArray doesn't exist Ian Lynagh **20070404155732] [Fix braino Ian Lynagh **20070404144508] [Fix incorrect changes to C types in a foreign import for nhc98. Malcolm.Wallace@cs.york.ac.uk**20070404120954 If we use type CTime, it needs to be imported. Also, CTime is not an instance of Integral, so use some other mechanism to convert it. ] [Fix C/Haskell type mismatches Ian Lynagh **20070403194943] [add new module Unsafe.Coerce to build system Malcolm.Wallace@cs.york.ac.uk**20070403131333] [Fix type mismatches between foreign imports and HsBase.h Ian Lynagh **20070403001611 Merge to stable, checking for interface changes. ] [put 'unsafeCoerce' in a standard location Malcolm.Wallace@cs.york.ac.uk**20061113114103] [fix for nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070402141712] [Function crossMapP for fixing desugaring of comprehensions Manuel M T Chakravarty **20070402082906 Merge into 6.6 branch. ] [Add min/max handling operations for IntSet/IntMap jeanphilippe.bernardy@gmail.com**20070315072352] [Monoid instance for Maybe and two wrappers: First and Last. trac proposal #1189 Jeffrey Yasskin **20070309062550] [Fix the type of wgencat Ian Lynagh **20070329164223] [fix strictness of foldr/build rule for take, see #1219 Simon Marlow **20070327103941] [remove Makefile.inc (only affects nhc98) Malcolm.Wallace@cs.york.ac.uk**20070320120057] [copyBytes copies bytes, not elements; fixes trac #1203 Ian Lynagh **20070312113555] [Add ioeGetLocation, ioeSetLocation to System/IO/Error.hs; trac #1191 Ian Lynagh **20070304130315] [fix race condition in prodServiceThread Simon Marlow **20070307134330 See #1187 ] [Prevent duplication of unsafePerformIO on a multiprocessor Simon Marlow **20070306145424 Fixes #986. The idea is to add a new operation noDuplicate :: IO () it is guaranteed that if two threads have executed noDuplicate, then they are not duplicating any computation. We now provide two new unsafe operations: unsafeDupablePerformIO :: IO a -> a unsafeDupableInterleaveIO :: IO a -> IO a which are equivalent to the old unsafePerformIO and unsafeInterleaveIO respectively. The new versions of these functions are defined as: unsafePerformIO m = unsafeDupablePerformIO (noDuplicate >> m) unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) ] [expand docs for forkOS Simon Marlow **20070305160921] [document timeout limitations Peter Simons **20070228223540] [So many people were involved in the writing of this module that Peter Simons **20070228223415 it feels unfair to single anyone out as the lone copyright holder. ] [This patch adds a timeout function to the base libraries. Trac #980 is Peter Simons **20070126222615 concerned with this issue. The design guideline for this implementation is that 'timeout N E' should behave exactly the same as E as long as E doesn't time out. In our implementation, this means that E has the same myThreadId it would have without the timeout wrapper. Any exception E might throw cancels the timeout and propagates further up. It also possible for E to receive exceptions thrown to it by another thread. ] [PArr: fixed permutations Manuel M T Chakravarty **20070305055807] [Add Data.String, containing IsString(fromString); trac proposal #1126 Ian Lynagh **20070130134841 This is used by the overloaded strings extension (-foverloaded-strings in GHC). ] [GHC.PArr: add bounds checking Manuel M T Chakravarty **20070302053224] [Bump nhc98 stack size for System/Time.hsc sven.panne@aedion.de**20070301153009] [FDs are CInts now, fixing non-GHC builds sven.panne@aedion.de**20070225105620] [Fixed PArr.dropP Manuel M T Chakravarty **20070222032405 - Thanks to Audrey Tang for the bug report ] [Keep the same FD in both halves of a duplex handle when dup'ing Ian Lynagh **20070220141039 Otherwise we only close one of the FDs when closing the handle. Fixes trac #1149. ] [Remove more redundant FD conversions Ian Lynagh **20070220092520] [Fix FD changes on Windows Ian Lynagh **20070220091516] [Consistently use CInt rather than Int for FDs Ian Lynagh **20070219233854] [Fix the types of minView/maxView (ticket #1134) jeanphilippe.bernardy@gmail.com**20070210065115] [fix for hashString, from Jan-Willem Maessen (see #1137) Simon Marlow **20070215094304 ] [fix to getUSecOfDay(): arithmetic was overflowing Simon Marlow **20070214161719] [The Windows counterpart to 'wrapround of thread delays' Ian Lynagh **20070209173510] [wrapround of thread delays Neil Davies **20070129160519 * made the wrapround of the underlying O/S occur before the wrapround of the delayed threads by making threads delay in microseconds since O/S epoch (1970 - Unix, 1601 - Windows) stored in Word64. * removed redundant calls reading O/S realtime clock * removed rounding to 1/50th of sec for timers * Only for Unix version of scheduler. ] [Whitespace changes only Ian Lynagh **20070206232722] [Add some type sigs Ian Lynagh **20070206232439] [Use static inline rather than extern inline/inline Ian Lynagh **20070205203628 I understand this is more portable, and it also fixes warnings when C things we are wrapping are themselves static inlines (which FD_ISSET is on ppc OS X). ] [add derived instances for Dual monoid Ross Paterson **20070202190847] [add doc pointers to Foldable Ross Paterson **20070202110931 Could be applied to STABLE. ] [Eliminate some warnings Ian Lynagh **20060729220854 Eliminate warnings in the libraries caused by mixing pattern matching with numeric literal matching. ] [Remove IsString(fromString) from the Prelude Ian Lynagh **20070130124136] [Add Kleisli composition Don Stewart **20061113015442] [IsString is GHC-only (so why is it in the Prelude?) Ross Paterson **20070123183007] [Applicative and Monad instances for Tree Ross Paterson **20070115174510] [Add IsString class for overloaded string literals. lennart@augustsson.net**20061221210532] [Added examples, more detailed documentation to Data.List Extracting sublists functions Andriy Palamarchuk **20061204164710] [fix threadDelay Simon Marlow **20070117091702 In "Add support for the IO manager thread" I accidentally spammed part of "Make sure the threaded threadDelay sleeps at least as long as it is asked", which is why the ThreadDelay001 test has been failing. ] [update section on "blocking" Simon Marlow **20070116124328] [Fix crash with (minBound :: Int*) `div (-1) as result is maxBound + 1. Ian Lynagh **20070115142005] [version of example using Tomasz Zielonka's technique Ross Paterson **20070105175907] [Added Unknowns for higher kinds Pepe Iborra **20061108155938] [Improved the Show instance for Unknown Pepe Iborra **20060813111816] [Show instance for GHC.Base.Unknown mnislaih@gmail.com**20060801233530] [Introduce Unknowns for the closure viewer. Add breakpointCond which was missing mnislaih@gmail.com**20060725174537] [Fix missing comma in Fractional documentation Alec Berryman **20061201173237] [Mention that throwTo does not guarantee promptness of delivery simonpj@microsoft**20061211123215] [Add note about synhronous delivery of throwTo simonpj@microsoft**20061211122257] [documentation for installHandler Simon Marlow **20061205154927 merge to 6.6 ] [dos2unix Simon Marlow **20061204095439] [don't try to compile this on Unix Simon Marlow **20061204095427] [TAG 6.6 release Ian Lynagh **20061011124740] [TAG Version 2.1 Ian Lynagh **20061009114014] [Bump version number Ian Lynagh **20061009114009] [Add support for the IO manager thread on Windows Simon Marlow **20061201152042 Fixes #637. The test program in that report now works for me with -threaded, but it doesn't work without -threaded (I don't know if that's new behaviour or not, though). ] [deriving (Eq, Ord, Enum, Show, Read, Typeab) for ConsoleEvent Simon Marlow **20061201144032] [Make sure the threaded threadDelay sleeps at least as long as it is asked to Ian Lynagh **20061128204807] [Add comments about argument order to the definitions of gmapQ and constrFields simonpj@microsoft**20061124164505] [Hugs: add Control.Parallel.Strategies Ross Paterson **20061124161039] [Move instance of Show Ptr to Ptr.hs (fewer orphans) simonpj@microsoft.com**20061124100639] [Add type signatures simonpj@microsoft.com**20061124100621] [Add an example of the use of unfoldr, following doc feedback from dozer Don Stewart **20061124011249] [trim imports Ross Paterson **20061123190352] [Data.Graph is now portable (enable for nhc98) Malcolm.Wallace@cs.york.ac.uk**20061123174913] [remove Data.FunctorM and Data.Queue Ross Paterson **20061112001046 These were deprecated in 6.6, and can thus be removed in 6.8. ] [make Data.Graph portable (no change to the interface) Ross Paterson **20061122010040 The algorithm now uses STArrays on GHC and IntSets elsewhere. (Hugs has STArrays, but avoiding them saves a -98, and boxed arrays aren't fast under Hugs anyway.) ] [One less unsafeCoerce# in the tree Don Stewart **20061120120242] [typo in comment Ross Paterson **20061120115106] [fix shift docs to match ffi spec Ross Paterson **20061117003144] [(nhc98) use new primitive implementations of h{Put,Get}Buf. Malcolm.Wallace@cs.york.ac.uk**20061116173104] [The wrong 'cycle' was exported from Data.ByteString.Lazy.Char8, spotted by sjanssen Don Stewart **20061110021311] [LPS chunk sizes should be 16 bytes, not 17. Don Stewart **20061110021254] [Update comments on Prelude organisation in GHC/Base.lhs Ian Lynagh **20061115001926] [Control.Parallel.Strategies clean-up: Added export list to avoid exporting seq, fixed import list strangeness that haddock choked on, and moved the deprecated functions to a separate section. bringert@cs.chalmers.se**20061113224202] [Control.Parallel.Strategies: added NFData instances for Data.Int.*, Data.Word.*, Maybe, Either, Map, Set, Tree, IntMap, IntSet. bringert@cs.chalmers.se**20061113221843] [Control.Parallel.Strategies: deprecate sPar, sSeq, Assoc, fstPairFstList, force and sforce. bringert@cs.chalmers.se**20061113215219 Code comments indicated that sPar and sSeq have been superceded by sparking and demanding, and that Assoc, fstPairFstList, force and sforce are examples and hacks needed by the Lolita system. ] [add Control.Monad.Instances to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20061113113221] [Control.Parallel.Strategies: clarified documentation of parListChunk. bringert@cs.chalmers.se**20061112232904] [Added and cleaned up Haddock comments in Control.Parallel.Strategies. bringert@cs.chalmers.se**20061112220445 Many of the definitions in Control.Parallel.Strategies had missing or unclear Haddock comments. I converted most of the existing plain code comments to haddock comments, added some missing documentation and cleaned up the existing Haddock mark-up. ] [Fix broken pragmas; spotted by Bulat Ziganshin Ian Lynagh **20061111205916] [add doc link to bound threads section Ross Paterson **20060929103252] [hide Data.Array.IO.Internals Ross Paterson **20061111113248 It's hidden from haddock, and everything it exports is re-exported by Data.Array.IO. ] [add Data.Function Malcolm.Wallace@cs.york.ac.uk**20061110142710] [add Data.Function Ross Paterson **20061110141354] [whitespace only Ross Paterson **20061110141326] [move fix to Data.Function Ross Paterson **20061110141120] [import Prelude Ross Paterson **20061110140445] [Added Data.Function (Trac ticket #979). Nils Anders Danielsson **20061110122503 + A module with simple combinators working solely on and with functions. + The only new function is "on". + Some functions from the Prelude are re-exported. ] [__hscore_long_path_size is not portable beyond GHC Malcolm.Wallace@cs.york.ac.uk**20061110113222] [redefine writeFile and appendFile using withFile Ross Paterson **20061107140359] [add withFile and withBinaryFile (#966) Ross Paterson **20061107134510] [remove conflicting import for nhc98 Malcolm.Wallace@cs.york.ac.uk**20061108111215] [Add intercalate to Data.List (ticket #971) Josef Svenningsson **20061102122052] [non-GHC: fix canonicalizeFilePath Ross Paterson **20061107133902 I've also removed the #ifdef __GLASGOW_HASKELL__ from the proper Windows versions of a few functions. These will need testing with Hugs on Windows. ] [enable canonicalizePath for non-GHC platforms Simon Marlow **20061107121141] [Update documentation for hWaitForInput Simon Marlow **20061107111430 See #972 Merge to 6.6 branch. ] [Use unchecked shifts to implement Data.Bits.rotate Samuel Bronson **20061012125553 This should get rid of those cases, maybe lower the size enough that the inliner will like it? ] [fix Haddock module headers Ross Paterson **20061106124140] [fix example in docs Ross Paterson **20061106115628] [Add intercalate and split to Data.List Josef Svenningsson *-20061024172357] [Data.Generics.Basics is GHC-only Ross Paterson **20061102111736] [#ifdef around non-portable Data.Generics.Basics Malcolm.Wallace@cs.york.ac.uk**20061102103445] [Add deriving Data to Complex simonpj@microsoft**20061101102059] [minor clarification of RandomGen doc Ross Paterson **20061030230842] [rearrange docs a bit Ross Paterson **20061030161223] [Add intercalate and split to Data.List Josef Svenningsson **20061024172357] [Export pseq from Control.Parallel, and use it in Control.Parallel.Strategies Simon Marlow **20061027150141] [`par` should be infixr 0 Simon Marlow **20061027130800 Alas, I didn't spot this due to lack of testing, and the symptom is that an expression like x `par` y `seq z will have exactly the wrong parallelism properties. The workaround is to add parantheses. I think we could push this to the 6.6 branch. ] [fix example in comment Ross Paterson **20061023163925] [Use the new Any type for dynamics (GHC only) simonpj@microsoft**20061019160408] [add Data.Sequence to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20061012135200] [Remove Data.FiniteMap, add Control.Applicative, Data.Traversable, and Malcolm.Wallace@cs.york.ac.uk**20061012095605 Data.Foldable to the nhc98 build. ] [STM invariants tharris@microsoft.com**20061007123253] [Inline shift in GHC's Bits instances for {Int,Word}{,8,16,32,64} Samuel Bronson **20061009020906] [Don't create GHC.Prim when bootstrapping; we can't, and we don't need it Ian Lynagh **20061004165355] [Data.ByteString: fix lazyness of take, drop & splitAt Don Stewart **20061005011703 ByteString.Lazy's take, drop and splitAt were too strict when demanding a byte string. Spotted by Einar Karttunen. Thanks to him and to Bertram Felgenhauer for explaining the problem and the fix. ] [Fix syntax error that prevents building Haddock documentation on Windows brianlsmith@gmail.com**20060917013530] [Hugs only: unbreak typeRepKey Ross Paterson **20060929102743] [make hGetBufNonBlocking do something on Windows w/ -threaded Simon Marlow **20060927145811 hGetBufNonBlocking will behave the same as hGetBuf on Windows now, which is better than just crashing (which it did previously). ] [add typeRepKey :: TypeRep -> IO Int Simon Marlow **20060927100342 See feature request #880 ] [fix header comment Ross Paterson **20060926135843] [Add strict versions of insertWith and insertWithKey (Data.Map) jeanphilippe.bernardy@gmail.com**20060910162443] [doc tweaks, including more precise equations for evaluate Ross Paterson **20060910115259] [Sync Data.ByteString with stable branch Don Stewart **20060909050111 This patch: * hides the LPS constructor (its in .Base if you need it) * adds functions to convert between strict and lazy bytestrings * and adds readInteger ] [Typeable1 instances for STM and TVar Ross Paterson **20060904231425] [remove obsolete Hugs stuff Ross Paterson **20060904223944] [Cleaner isInfixOf suggestion from Ross Paterson John Goerzen **20060901143654] [New function isInfixOf that searches a list for a given sublist John Goerzen **20060831151556 Example: isInfixOf "Haskell" "I really like Haskell." -> True isInfixOf "Ial" "I really like Haskell." -> False This function was first implemented in MissingH as MissingH.List.contains ] [Better doc on Data.Map.lookup: explain what the monad is for jeanphilippe.bernardy@gmail.com**20060903133440] [fix hDuplicateTo on Windows Simon Marlow **20060901150016 deja vu - I'm sure I remember fixing this before... ] [Improve documentation of atomically simonpj@microsoft**20060714120207] [Add missing method genRange for StdGen (fixes #794) simonpj@microsoft**20060707151901 MERGE TO STABLE Trac #794 reports (correctly) that the implementation of StdGen only returns numbers in the range (0..something) rather than (minBound, maxBound), which is what StdGen's genRange claims. This commit fixes the problem, by implementing genRange for StdGen (previously it just used the default method). ] [mark nhc98 import hack Ross Paterson **20060831125219] [remove some outdated comments Simon Marlow **20060831104200] [import Control.Arrow.ArrowZero to help nhc98's type checker Malcolm.Wallace@cs.york.ac.uk**20060831101105] [remove Text.Regex(.Posix) from nhc98 build Malcolm.Wallace@cs.york.ac.uk**20060831101016] [add Data.Foldable.{msum,asum}, plus tweaks to comments Ross Paterson **20060830163521] [fix doc typo Ross Paterson **20060830134123] [add Data.Foldable.{for_,forM_} and Data.Traversable.{for,forM} Ross Paterson **20060830133805 generalizing Control.Monad.{forM_,forM} ] [Make length a good consumer simonpj@microsoft*-20060508142726 Make length into a good consumer. Fixes Trac bug #707. (Before length simply didn't use foldr.) ] [Add Control.Monad.forM and forM_ Don Stewart **20060824081118 flip mapM_ is more and more common, I find. Several suggestions have been made to add this, as foreach or something similar. This patch does just that: forM :: (Monad m) => [a] -> (a -> m b) -> m [b] forM_ :: (Monad m) => [a] -> (a -> m b) -> m () So we can write: Prelude Control.Monad> forM_ [1..4] $ \x -> print x 1 2 3 4 ] [Hide internal module from haddock in Data.ByteString Don Stewart **20060828011515] [add advice on avoiding import ambiguities Ross Paterson **20060827170407] [expand advice on importing these modules Ross Paterson **20060827164044] [add Haddock marker Ross Paterson **20060827115140] [Clarify how one hides Prelude.catch Don Stewart **20060826124346 User feedback indicated that an example was required, of how to hide Prelude.catch, so add such an example to the docs ] [Workaround for OSes that don't have intmax_t and uintmax_t Ian Lynagh **20060825134936 OpenBSD (and possibly others) do not have intmax_t and uintmax_t types: http://www.mail-archive.com/haskell-prime@haskell.org/msg01548.html so substitute (unsigned) long long if we have them, otherwise (unsigned) long. ] [add docs for par Simon Marlow **20060825110610] [document minimal complete definition for Bits Ross Paterson **20060824140504] [C regex library bits have moved to the regex-posix package Simon Marlow **20060824132311] [Add shared Typeable support (ghc only) Esa Ilari Vuokko **20060823003126] [this should have been removed with the previous patch Simon Marlow **20060824121223] [remove Text.Regx & Text.Regex.Posix Simon Marlow **20060824094615 These are subsumed by the new regex-base, regex-posix and regex-compat packages. ] [explicitly tag Data.ByteString rules with the FPS prefix. Don Stewart **20060824041326] [Add spec rules for sections in Data.ByteString Don Stewart **20060824012611] [Sync Data.ByteString with current stable branch, 0.7 Don Stewart **20060823143338] [add notes about why copyFile doesn't remove the target Simon Marlow **20060823095059] [copyFile: try removing the target file before opening it for writing Simon Marlow *-20060822121909] [copyFile: try removing the target file before opening it for writing Simon Marlow **20060822121909] [add alternative functors and extra instances Ross Paterson **20060821152151 * Alternative class, for functors with a monoid * instances for Const * instances for arrows ] [generate Haddock docs on all platforms Simon Marlow **20060821131612] [remove extra comma from import Ross Paterson **20060819173954] [fix docs for withC(A)StringLen Ross Paterson **20060818170328] [use Haskell'98 compliant indentation in do blocks Malcolm.Wallace@cs.york.ac.uk**20060818130810] [use correct names of IOArray operations for nhc98 Malcolm.Wallace@cs.york.ac.uk**20060818130714] [add mapMaybe and mapEither, plus WithKey variants Ross Paterson **20060817235041] [remove Text.Html from nhc98 build Malcolm.Wallace@cs.york.ac.uk**20060817135502] [eliminate more HOST_OS tests Ross Paterson **20060815190609] [Hugs only: disable unused process primitives Ross Paterson **20060813184435 These were the cause of Hugs bug #30, I think, and weren't used by Hugs anyway. ] [markup fix to Data.HashTable Ross Paterson **20060812103835] [revert removal of ghcconfig.h from package.conf.in Ross Paterson **20060812082702 as it's preprocessed with -undef (pointed out by Esa Ilari Vuokko) ] [fix Data.HashTable for non-GHC Ross Paterson **20060811231521] [remove deprecated 'withObject' Simon Marlow **20060811152350] [Jan-Willem Maessen's improved implementation of Data.HashTable Simon Marlow **20060811151024 Rather than incrementally enlarging the hash table, this version just does it in one go when the table gets too full. ] [Warning police: Make some prototypes from the RTS known sven.panne@aedion.de**20060811144629] [Warning police: Removed useless catch-all clause sven.panne@aedion.de**20060811142208] [reduce dependency on ghcconfig.h Ross Paterson **20060811124030 The only remaining use is in cbits/dirUtils.h, which tests solaris2_HOST_OS (Also System.Info uses ghcplatform.h and several modules import MachDeps.h to get SIZEOF_* and ALIGNMENT_* from ghcautoconf.h) ] [(non-GHC only) track MArray interface change Ross Paterson **20060810182902] [move Text.Html to a separate package Simon Marlow **20060810113017] [bump version to 2.0 Simon Marlow **20060810112833] [Remove deprecated Data.FiniteMap and Data.Set interfaces Simon Marlow **20060809153810] [move altzone test from ghc to base package Ross Paterson **20060809124259] [remove unnecessary #include "ghcconfig.h" Ross Paterson **20060809123812] [Change the API of MArray to allow resizable arrays Simon Marlow **20060809100548 See #704 The MArray class doesn't currently allow a mutable array to change its size, because of the pure function bounds :: (HasBounds a, Ix i) => a i e -> (i,i) This patch removes the HasBounds class, and adds getBounds :: (MArray a e m, Ix i) => a i e -> m (i,i) to the MArray class, and bounds :: (IArray a e, Ix i) => a i e -> (i,i) to the IArray class. The reason that bounds had to be incorporated into the IArray class is because I couldn't make DiffArray work without doing this. DiffArray acts as a layer converting an MArray into an IArray, and there was no way (that I could find) to define an instance of HasBounds for DiffArray. ] [deprecate this module. Simon Marlow **20060808100708] [add traceShow (see #474) Simon Marlow **20060807155545] [remove spurious 'extern "C" {' Simon Marlow **20060724160258] [Fix unsafeIndex for large ranges Simon Marlow **20060721100225] [disambiguate uses of foldr for nhc98 to compile without errors Malcolm.Wallace@cs.york.ac.uk**20060711161614] [make Control.Monad.Instances compilable by nhc98 Malcolm.Wallace@cs.york.ac.uk**20060711160941] [breakpointCond Lemmih **20060708055528] [UNDO: Merge "unrecognized long opt" fix from 6.4.2 Simon Marlow **20060705142537 This patch undid the previous patch, "RequireOrder: do not collect unrecognised options after a non-opt". I asked Sven to revert it, but didn't get an answer. See bug #473. ] [Avoid strictness in accumulator for unpackFoldr Don Stewart **20060703091806 The seq on the accumulator for unpackFoldr will break in the presence of head/build rewrite rules. The empty list case will be forced, producing an exception. This is a known issue with seq and rewrite rules that we just stumbled on to. ] [Disable unpack/build fusion Don Stewart **20060702083913 unpack/build on bytestrings seems to trigger a bug when interacting with head/build fusion in GHC.List. The bytestring001 testcase catches it. I'll investigate further, but best to disable this for now (its not often used anyway). Note that with -frules-off or ghc 6.4.2 things are fine. It seems to have emerged with the recent rules changes. ] [Import Data.ByteString.Lazy, improve ByteString Fusion, and resync with FPS head Don Stewart **20060701084345 This patch imports the Data.ByteString.Lazy module, and its helpers, providing a ByteString implemented as a lazy list of strict cache-sized chunks. This type allows the usual lazy operations to be written on bytestrings, including lazy IO, with much improved space and time over the [Char] equivalents. ] [Wibble in docs for new ForeignPtr functionsn Don Stewart **20060609075924] [comments for Applicative and Traversable Ross Paterson **20060622170436] [default to NoBuffering on Windows for a read/write text file Simon Marlow **20060622144446 Fixes (works around) #679 ] [remove dead code Simon Marlow **20060622144433] [clarify and expand docs Simon Marlow **20060622112911] [Add minView and maxView to Map and Set jeanphilippe.bernardy@gmail.com**20060616180121] [add signature for registerDelay Ross Paterson **20060614114456] [a few doc comments Ross Paterson **20060613142704] [Optimised foreign pointer representation, for heap-allocated objects Don Stewart **20060608015011] [Add the inline function, and many comments simonpj@microsoft.com**20060605115814 This commit adds the 'inline' function described in the related patch in the compiler. I've also added comments about the 'lazy' function. ] [small intro to exceptions Ross Paterson **20060525111604] [export breakpoint Simon Marlow **20060525090456] [Merge in changes from fps head. Highlights: Don Stewart **20060525065012 Wed May 24 15:49:38 EST 2006 sjanssen@cse.unl.edu * instance Monoid ByteString Wed May 24 15:04:04 EST 2006 Duncan Coutts * Rearange export lists for the .Char8 modules Wed May 24 14:59:56 EST 2006 Duncan Coutts * Implement mapAccumL and reimplement mapIndexed using loopU Wed May 24 14:47:32 EST 2006 Duncan Coutts * Change the implementation of the unfoldr(N) functions. Use a more compact implementation for unfoldrN and change it's behaviour to only return Just in the case that it actually 'overflowed' the N, so the boundary case of unfolding exactly N gives Nothing. Implement unfoldr and Lazy.unfoldr in terms of unfoldrN. Use fibonacci growth for the chunk size in unfoldr Wed May 24 08:32:29 EST 2006 sjanssen@cse.unl.edu * Add unfoldr to ByteString and .Char8 A preliminary implementation of unfoldr. Wed May 24 01:39:41 EST 2006 Duncan Coutts * Reorder the export lists to better match the Data.List api Tue May 23 14:04:32 EST 2006 Don Stewart * pack{Byte,Char} -> singleton. As per fptools convention Tue May 23 14:00:51 EST 2006 Don Stewart * elemIndexLast -> elemIndexEnd Tue May 23 13:57:34 EST 2006 Don Stewart * In the search for a more orthogonal api, we kill breakFirst/breakLast, which were of dubious value Tue May 23 12:24:09 EST 2006 Don Stewart * Abolish elems. It's name implied it was unpack, but its type didn't. it made no sense Tue May 23 10:42:09 EST 2006 Duncan Coutts * Minor doc tidyup. Use haddock markup better. Tue May 23 11:00:31 EST 2006 Don Stewart * Simplify the join() implementation. Spotted by Duncan. ] [add a way to ask the IO manager thread to exit Simon Marlow **20060524121823] [Sync with FPS head, including the following patches: Don Stewart **20060520030436 Thu May 18 15:45:46 EST 2006 sjanssen@cse.unl.edu * Export unsafeTake and unsafeDrop Fri May 19 11:53:08 EST 2006 Don Stewart * Add foldl1' Fri May 19 13:41:24 EST 2006 Don Stewart * Add fuseable scanl, scanl1 + properties Fri May 19 18:20:40 EST 2006 Don Stewart * Spotted another chance to use unsafeTake,Drop (in groupBy) Thu May 18 09:24:25 EST 2006 Duncan Coutts * More effecient findIndexOrEnd based on the impl of findIndex Thu May 18 09:22:49 EST 2006 Duncan Coutts * Eliminate special case in findIndex since it's handled anyway. Thu May 18 09:19:08 EST 2006 Duncan Coutts * Add unsafeTake and unsafeDrop These versions assume the n is in the bounds of the bytestring, saving two comparison tests. Then use them in varous places where we think this holds. These cases need double checking (and there are a few remaining internal uses of take / drop that might be possible to convert). Not exported for the moment. Tue May 16 23:15:11 EST 2006 Don Stewart * Handle n < 0 in drop and splitAt. Spotted by QC. Tue May 16 22:46:22 EST 2006 Don Stewart * Handle n <= 0 cases for unfoldr and replicate. Spotted by QC Tue May 16 21:34:11 EST 2006 Don Stewart * mapF -> map', filterF -> filter' ] [haddock fix Ross Paterson **20060518154723] [simplify indexing in Data.Sequence Ross Paterson **20060518154316] [Move Eq, Ord, Show instances for ThreadId to GHC.Conc Simon Marlow **20060518113339 Eliminates orphans. ] [Better error handling in the IO manager thread Simon Marlow **20060518113303 In particular, handle EBADF just like rts/posix/Select.c, by waking up all the waiting threads. Other errors are thrown, instead of just being ignored. ] [#define _REENTRANT 1 (needed to get the right errno on some OSs) Simon Marlow **20060518104151 Part 2 of the fix for threaded RTS problems on Solaris and possibly *BSD (Part 1 was the same change in ghc/includes/Rts.h). ] [copyCString* should be in IO. Spotted by Tomasz Zielonka Don Stewart **20060518012154] [add import Prelude to get dependencies right for Data/Fixed.hs Duncan Coutts **20060517222044 Hopefully this fixes parallel builds. ] [Fix negative index handling in splitAt, replicate and unfoldrN. Move mapF, filterF -> map', filter' while we're here Don Stewart **20060517020150] [Use our own realloc. Thus reduction functions (like filter) allocate on the Haskell heap. Makes around 10% difference. Don Stewart **20060513051736] [Last two CInt fixes for 64 bit, and bracket writeFile while we're here Don Stewart **20060512050750] [Some small optimisations, generalise the type of unfold Don Stewart **20060510043309 Tue May 9 22:36:29 EST 2006 Duncan Coutts * Surely the error function should not be inlined. Tue May 9 22:35:53 EST 2006 Duncan Coutts * Reorder memory writes for better cache locality. Tue May 9 23:28:09 EST 2006 Duncan Coutts * Generalise the type of unfoldrN The type of unfoldrN was overly constrained: unfoldrN :: Int -> (Word8 -> Maybe (Word8, Word8)) -> Word8 -> ByteString if we compare that to unfoldr: unfoldr :: (b -> Maybe (a, b)) -> b -> [a] So we can generalise unfoldrN to this type: unfoldrN :: Int -> (a -> Maybe (Word8, a)) -> a -> ByteString and something similar for the .Char8 version. If people really do want to use it a lot with Word8/Char then perhaps we should add a specialise pragma. Wed May 10 13:26:40 EST 2006 Don Stewart * Add foldl', and thus a fusion rule for length . {map,filter,fold}, that avoids creating an array at all if the end of the pipeline is a 'length' reduction **END OF DESCRIPTION*** Place the long patch description above the ***END OF DESCRIPTION*** marker. The first line of this file will be the patch name. This patch contains the following changes: M ./Data/ByteString.hs -8 +38 M ./Data/ByteString/Char8.hs -6 +12 ] [portable implementation of WordPtr/IntPtr for non-GHC Ross Paterson **20060510001826 plus much tweaking of imports to avoid cycles ] [add WordPtr and IntPtr types to Foreign.Ptr, with associated conversions Simon Marlow **20060509092606 As suggested by John Meacham. I had to move the Show instance for Ptr into GHC.ForeignPtr to avoid recursive dependencies. ] [add CIntPtr, CUIntPtr, CIntMax, CUIntMax types Simon Marlow **20060509092427] [add GHC.Dynamic Simon Marlow **20060509082739] [Two things. #if defined(__GLASGOW_HASKELL__) on INLINE [n] pragmas (for jhc). And careful use of INLINE on words/unwords halves runtime for those functions Don Stewart **20060509023425] [Make length a good consumer simonpj@microsoft**20060508142726 Make length into a good consumer. Fixes Trac bug #707. (Before length simply didn't use foldr.) ] [Trim imports simonpj@microsoft**20060508142557] [Make unsafePerformIO lazy simonpj@microsoft**20060508142507 The stricteness analyser used to have a HACK which ensured that NOINLNE things were not strictness-analysed. The reason was unsafePerformIO. Left to itself, the strictness analyser would discover this strictness for unsafePerformIO: unsafePerformIO: C(U(AV)) But then consider this sub-expression unsafePerformIO (\s -> let r = f x in case writeIORef v r s of (# s1, _ #) -> (# s1, r #) The strictness analyser will now find that r is sure to be eval'd, and may then hoist it out. This makes tests/lib/should_run/memo002 deadlock. Solving this by making all NOINLINE things have no strictness info is overkill. In particular, it's overkill for runST, which is perfectly respectable. Consider f x = runST (return x) This should be strict in x. So the new plan is to define unsafePerformIO using the 'lazy' combinator: unsafePerformIO (IO m) = lazy (case m realWorld# of (# _, r #) -> r) Remember, 'lazy' is a wired-in identity-function Id, of type a->a, which is magically NON-STRICT, and is inlined after strictness analysis. So unsafePerformIO will look non-strict, and that's what we want. ] [Sync with FPS head. Don Stewart **20060508122322 Mon May 8 10:40:14 EST 2006 Don Stewart * Fix all uses for Int that should be CInt or CSize in ffi imports. Spotted by Igloo, dcoutts Mon May 8 16:09:41 EST 2006 Don Stewart * Import nicer loop/loop fusion rule from ghc-ndp Mon May 8 17:36:07 EST 2006 Don Stewart * Fix stack leak in split on > 60M strings Mon May 8 17:50:13 EST 2006 Don Stewart * Try same fix for stack overflow in elemIndices ] [Fix all uses for Int that should be CInt or CSize in ffi imports. Spotted by Duncan and Ian Don Stewart **20060508010311] [Fixed import list syntax Sven Panne **20060507155008] [Faster filterF, filterNotByte dons@cse.unsw.edu.au**20060507042301] [Much faster find, findIndex. Hint from sjanssen dons@cse.unsw.edu.au**20060507033048] [Merge "unrecognized long opt" fix from 6.4.2 Sven Panne **20060506110519] [ dons@cse.unsw.edu.au**20060506061029 Sat May 6 13:01:34 EST 2006 Don Stewart * Do loopU realloc on the Haskell heap. And add a really tough stress test Sat May 6 12:28:58 EST 2006 Don Stewart * Use simple, 3x faster concat. Plus QC properties. Suggested by sjanssen and dcoutts Sat May 6 15:59:31 EST 2006 Don Stewart * dcoutt's packByte bug squashed With inlinePerformIO, ghc head was compiling: packByte 255 `compare` packByte 127 into roughly case mallocByteString 2 of ForeignPtr f internals -> case writeWord8OffAddr# f 0 255 of _ -> case writeWord8OffAddr# f 0 127 of _ -> case eqAddr# f f of False -> case compare (GHC.Prim.plusAddr# f 0) (GHC.Prim.plusAddr# f 0) which is rather stunning. unsafePerformIO seems to prevent whatever magic inlining was leading to this. Only affected the head. ] [Add array fusion versions of map, filter and foldl dons@cse.unsw.edu.au**20060505060858 This patch adds fusable map, filter and foldl, using the array fusion code for unlifted, flat arrays, from the Data Parallel Haskell branch, after kind help from Roman Leshchinskiy, Pipelines of maps, filters and folds should now need to walk the bytestring once only, and intermediate bytestrings won't be constructed. ] [fix for non-GHC Ross Paterson **20060504093044] [use bracket in appendFile (like writeFile) Ross Paterson **20060504091528] [writeFile: close the file on error Simon Marlow **20060504084505 Suggested by Ross Paterson, via Neil Mitchell ] [Sync with FPS head dons@cse.unsw.edu.au**20060503105259 This patch brings Data.ByteString into sync with the FPS head. The most significant of which is the new Haskell counting sort. Changes: Sun Apr 30 18:16:29 EST 2006 sjanssen@cse.unl.edu * Fix foldr1 in Data.ByteString and Data.ByteString.Char8 Mon May 1 11:51:16 EST 2006 Don Stewart * Add group and groupBy. Suggested by conversation between sjanssen and petekaz on #haskell Mon May 1 16:42:04 EST 2006 sjanssen@cse.unl.edu * Fix groupBy to match Data.List.groupBy. Wed May 3 15:01:07 EST 2006 sjanssen@cse.unl.edu * Migrate to counting sort. Data.ByteString.sort used C's qsort(), which is O(n log n). The new algorithm is O(n), and is faster for strings larger than approximately thirty bytes. We also reduce our dependency on cbits! ] [improve performance of Integer->String conversion Simon Marlow **20060503113306 See http://www.haskell.org//pipermail/libraries/2006-April/005227.html Submitted by: bertram.felgenhauer@googlemail.com ] [inline withMVar, modifyMVar, modifyMVar_ Simon Marlow **20060503111152] [Fix string truncating in hGetLine -- it was a pasto from Simon's code Simon Marlow **20060503103504 (from Don Stewart) ] [Merge in Data.ByteString head. Fixes ByteString+cbits in hugs Don Stewart **20060429040733] [Import Data.ByteString from fps 0.5. Don Stewart **20060428130718 Fast, packed byte vectors, providing a better PackedString. ] [fix previous patch Ross Paterson **20060501154847] [fixes for non-GHC Ross Paterson **20060501144322] [fix imports for mingw32 && !GHC Ross Paterson **20060427163248] [RequireOrder: do not collect unrecognised options after a non-opt Simon Marlow **20060426121110 The documentation for RequireOrder says "no option processing after first non-option", so it doesn't seem right that we should process the rest of the arguments to collect the unrecognised ones. Presumably the client wants to know about the unrecognised options up to the first non-option, and will be using a different option parser for the rest of the command line. eg. before: Prelude System.Console.GetOpt> getOpt' RequireOrder [] ["bar","--foo"] ([],["bar","--foo"],["--foo"],[]) after: Prelude System.Console.GetOpt> getOpt' RequireOrder [] ["bar","--foo"] ([],["bar","--foo"],[],[]) ] [fix for Haddock 0.7 Ashley Yakeley **20060426072521] [add Data.Fixed module Ashley Yakeley **20060425071853] [add instances Ross Paterson **20060424102146] [add superclasses to Applicative and Traversable Ross Paterson **20060411144734 Functor is now a superclass of Applicative, and Functor and Foldable are now superclasses of Traversable. The new hierarchy makes clear the inclusions between the classes, but means more work in defining instances. Default definitions are provided to help. ] [add Functor and Monad instances for Prelude types Ross Paterson **20060410111443] [GHC.Base.breakpoint Lemmih **20060407125827] [Track the GHC source tree reorganisation Simon Marlow **20060407041631] [in the show instance for Exception, print the type of dynamic exceptions Simon Marlow **20060406112444 Unfortunately this requires some recursve module hackery to get at the show instance for Typeable. ] [implement ForeignEnvPtr, newForeignPtrEnv, addForeignPtrEnv for GHC Simon Marlow **20060405155448] [add forkOnIO :: Int -> IO () -> IO ThreadId Simon Marlow **20060327135018] [Rework previous: not a gcc bug after all Simon Marlow **20060323161229 It turns out that we were relying on behaviour that is undefined in C, and undefined behaviour in C means "the compiler can do whatever the hell it likes with your entire program". So avoid that. ] [work around a gcc 4.1.0 codegen bug in -O2 by forcing -O1 for GHC.Show Simon Marlow **20060323134514 See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26824 ] [commit mysteriously missing parts of "runIOFastExit" patch Simon Marlow **20060321101535] [add runIOFastExit :: IO a -> IO a Simon Marlow **20060320124333 Similar to runIO, but calls stg_exit() directly to exit, rather than shutdownHaskellAndExit(). Needed for running GHCi in the test suite. ] [Fix a broken invariant Simon Marlow **20060316134151 Patch from #694, for the problem "empty is an identity for <> and $$" is currently broken by eg. isEmpty (empty<>empty)" ] [Add unsafeSTToIO :: ST s a -> IO a Simon Marlow **20060315160232 Implementation for Hugs is missing, but should be easy. We need this for the forthcoming nested data parallelism implementation. ] [Added 'alter' jeanphilippe.bernardy@gmail.com**20060315143539 Added 'alter :: (Maybe a -> Maybe a) -> k -> Map k a -> Map k a' to IntMap and Map This addresses ticket #665 ] [deprecate FunctorM in favour of Foldable and Traversable Ross Paterson **20060315092942 as discussed on the libraries list. ] [Simplify Eq, Ord, and Show instances for UArray Simon Marlow **20060313142701 The Eq, Ord, and Show instances of UArray were written out longhand with one instance per element type. It is possible to condense these into a single instance for each class, at the expense of using more extensions (non-std context on instance declaration). Suggestion by: Frederik Eaton ] [Oops typo in intSet notMember jeanphilippe.bernardy@gmail.com**20060311224713] [IntMap lookup now returns monad instead of Maybe. jeanphilippe.bernardy@gmail.com**20060311224502] [Added notMember to Data.IntSet and Data.IntMap jeanphilippe.bernardy@gmail.com**20060311085221] [add Data.Set.notMember and Data.Map.notMember John Meacham **20060309191806] [addToClockTime: handle picoseconds properly Simon Marlow **20060310114532 fixes #588 ] [make head/build rule apply to all types, not just Bool. John Meacham **20060303045753] [Avoid overflow when normalising clock times Ian Lynagh **20060210144638] [Years have 365 days, not 30*365 Ian Lynagh **20060210142853] [declare blkcmp() static Simon Marlow **20060223134317] [typo in comment in Foldable class Ross Paterson **20060209004901] [simplify fmap Ross Paterson **20060206095048] [update ref in comment Ross Paterson **20060206095139] [Give -foverlapping-instances to Data.Typeable simonpj@microsoft**20060206133439 For some time, GHC has made -fallow-overlapping-instances "sticky": any instance in a module compiled with -fallow-overlapping-instances can overlap when imported, regardless of whether the importing module allows overlap. (If there is an overlap, both instances must come from modules thus compiled.) Instances in Data.Typeable might well want to be overlapped, so this commit adds the flag to Data.Typeable (with an explanatory comment) ] [Add -fno-bang-patterns to modules using both bang and glasgow-exts simonpj@microsoft.com**20060203175759] [When splitting a bucket, keep the contents in the same order Simon Marlow **20060201130427 To retain the property that multiple inserts shadow each other (see ticket #661, test hash001) ] [add foldr/build optimisation for take and replicate Simon Marlow **20060126164603 This allows take to be deforested, and improves performance of replicate and replicateM/replicateM_. We have a separate problem that means expressions involving [n..m] aren't being completely optimised because eftIntFB isn't being inlined but otherwise the results look good. Sadly this has invalidated a number of the nofib benchmarks which were erroneously using take to duplicate work in a misguided attempt to lengthen their runtimes (ToDo). ] [Generate PrimopWrappers.hs with Haddock docs Simon Marlow **20060124131121 Patch originally from Dinko Tenev , modified to add log message by me. ] [[project @ 2006-01-19 14:47:15 by ross] ross**20060119144715 backport warning avoidance from Haddock ] [[project @ 2006-01-18 11:45:47 by malcolm] malcolm**20060118114547 Fix import of Ix for nhc98. ] [[project @ 2006-01-17 09:38:38 by ross] ross**20060117093838 add Ix instance for GeneralCategory. ] [TAG Initial conversion from CVS complete John Goerzen **20060112154126] Patch bundle hash: 83819f69b3b12919bfcf79a6fbeda00c676a5435 From lemming at henning-thielemann.de Wed Mar 12 03:01:54 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Mar 12 02:57:50 2008 Subject: runSTArray for multiple arrays Message-ID: Currently, runSTArray can handle only one array: runSTArray :: Ix i => (forall s . ST s (STArray s i e)) -> Array i e Would it be possible to access multiple arrays successively by a function like runSTArraySplit :: Ix i => (forall s . ST s (STArray s i e, a)) -> (Array i e, ST t a) Hm, this would not work, because type variables 's' in 'a' had to be converted to 't' as well. Are there other ideas to tackle this problem? From ndmitchell at gmail.com Wed Mar 12 07:42:04 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Mar 12 07:39:11 2008 Subject: Proposal: add some missing tuple functions In-Reply-To: <20080311181315.GD8667@scytale.galois.com> References: <20080311181315.GD8667@scytale.galois.com> Message-ID: <404396ef0803120442t2fca0b23r560233a632272734@mail.gmail.com> Hi > Basic texts often define > > swap, fst3, snd3 and thd3 > > So let's add them to the rather bare Data.Tuple. (+1). Obvious functions, certainly useful. Thanks Neil From bjorn at bringert.net Wed Mar 12 09:02:38 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Wed Mar 12 08:59:46 2008 Subject: non-maintainer uploads to hackageDB In-Reply-To: <20080225003558.GA4579@soi.city.ac.uk> References: <20080225003558.GA4579@soi.city.ac.uk> Message-ID: On Mon, Feb 25, 2008 at 1:35 AM, Ross Paterson wrote: > I think we need, perhaps not a policy, but some agreed etiquette regarding > uploads to hackageDB. (Please hold off on the technical suggestions > until we've decided what behaviour we want.) > > Personally, I'd rather have all maintainers doing their own uploads. > As I user, I'd like to know that someone takes responsibility for the > whole of a package I download, including the packaging, and will be > available for bug fixes and enhancements (such as making it work with > the next GHC release). > > As this is free software, there's nothing to stop someone forking a > package and maintaining their own version. Then as a user I'll need > to choose between the two, but I'll still be looking for a maintainer > of the whole package. It might be fair to ask that someone creating a > fork change the name of the package in some way, to avoid confusion > (and eating up the original maintainer's version numbers). > > This is a different situation from Linux or BSD distributions, where > primary releases are repackaged to conform with native conventions. > HackageDB is an upstream site, where people can make their own releases, > using a common package format (Cabal). (Similarly I don't think we > need the pristine+patches setup used by those distributions: maintainers > should just take care of the pristine.) I'm sorry I missed this when it was first posted. My suggested policy is that a non-maintainer who wants to upload a package should ask the maintainer first, and allow for a reasonable response time before uploading a package. If a package is uploaded against the maintainer's wishes, the maintainer should be allowed to request to have it removed. If the uploader is eager to have the package released, he is welcome to help fix the issues that the maintainer wants resolved before releasing. If the uploader still insists on uploading, he should fork the package. Hopefully this should be very rare. /Bj?rn From ross at soi.city.ac.uk Wed Mar 12 10:15:18 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Mar 12 10:12:26 2008 Subject: non-maintainer uploads to hackageDB In-Reply-To: References: <20080225003558.GA4579@soi.city.ac.uk> Message-ID: <20080312141518.GA9057@soi.city.ac.uk> On Wed, Mar 12, 2008 at 02:02:38PM +0100, Bjorn Bringert wrote: > My suggested policy is that a non-maintainer who wants to upload a > package should ask the maintainer first, and allow for a reasonable > response time before uploading a package. Having reflected a bit more, I see even less value in having a package uploaded by someone who isn't maintaining it. If I download something and have a problem with it, or have a suggested improvement, whom shall I contact? The answer to that is supposed to be the email address in the Maintainer field. If they take no responsibility for the package I'm trying to use, I'm going to regret downloading it. (Some abandoned software continues to be useful, but I'd prefer to see it marked as unmaintained, so that I know what I'm letting myself in for.) > If the uploader is eager to have the package released, he is welcome to > help fix the issues that the maintainer wants resolved before releasing. Sure, or send the maintainer packaging patches. That seems a more useful model to me. > If the uploader still insists on uploading, he should fork the package. > Hopefully this should be very rare. I have no problem with forks, as long as they're maintained (which is indeed rare). They should probably have a different name though, if the original is still active. From bertram.felgenhauer at googlemail.com Thu Mar 13 14:02:03 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu Mar 13 13:59:18 2008 Subject: runSTArray for multiple arrays In-Reply-To: References: Message-ID: <20080313180203.GB4363@zombie.inf.tu-dresden.de> Henning Thielemann wrote: > Currently, runSTArray can handle only one array: > > runSTArray :: Ix i => (forall s . ST s (STArray s i e)) -> Array i e > > Would it be possible to access multiple arrays successively by a function > like > > runSTArraySplit :: Ix i => > (forall s . ST s (STArray s i e, a)) -> > (Array i e, ST t a) > > Hm, this would not work, because type variables 's' in 'a' had to be > converted to 't' as well. Are there other ideas to tackle this problem? I tried making a type class for this, namely class EvalST st pure | st -> pure where freezeST :: st s -> ST s pure together with evalST :: EvalST st pure => (forall s. ST s (st s)) -> pure evalST f = runST (f >>= freezeST) I'll attach the complete module. Feel free to use, modify, etc. Unfortunately, the extra 's' type argument to the 'st' constructor makes this a bit cumbersome to use. In particular I needed wrapper types for arrays and pairs. On the positive side, the approach allows dealing with pure values, boxed and unboxed arrays, and STRefs (not implemented) in a uniform way. Example: *EvalST> evalST (do a <- newArray (0,0) 0; return (STPair (STPure 1) (STArray' a))) :: (Int, Array Int Int) (1,array (0,0) [(0,0)]) Is there any way to make evalST (do a <- newArray (0,0) 0; return (STPure 1, a)) :: (Int, Array Int Int) work? That's the prettiest interface I can imagine right now. Bertram -------------- next part -------------- A non-text attachment was scrubbed... Name: EvalST.hs Type: text/x-haskell Size: 1451 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080313/b62b5459/EvalST.bin From valery.vv at gmail.com Mon Mar 17 17:23:58 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Mar 17 17:20:45 2008 Subject: Cabal's configure doesn't notice missing headers Message-ID: Hi, while installing zlib[1] from hackage, I've discovered possible Cabal's misbehaviour. There was no `zlib.h' in my system. runhaskell Setup configure went fine, with no complaints. It was only during build step when missing header had been noticed and an error reported. apt-get install zlib1g-dev; and zlib cabal package installation succeeded, but... Closer to my question. `zlib.h' _is_ mentioned in zlib.cabal: includes: zlib.h According to documentation[2], `includes' "field applies to both header files that are already installed on the system and to those coming with the package to be isntalled." [NB the typo] I think that Cabal should complain of missing headers during configuration step. At least of the ones explicitly mentioned in `includes:' field. 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib-0.4.0.4 2. http://www.haskell.org/cabal/release/latest/doc/users-guide/x30.html#buildinfo -- vvv From duncan.coutts at worc.ox.ac.uk Mon Mar 17 19:52:18 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 17 19:49:08 2008 Subject: Cabal's configure doesn't notice missing headers In-Reply-To: References: Message-ID: <1205797938.7594.37.camel@localhost> On Mon, 2008-03-17 at 23:23 +0200, Valery V. Vorotyntsev wrote: > Hi, > > while installing zlib[1] from hackage, I've discovered possible Cabal's > misbehaviour. > > There was no `zlib.h' in my system. runhaskell Setup configure went fine, with > no complaints. It was only during build step when missing header had been > noticed and an error reported. > apt-get install zlib1g-dev; and zlib cabal package installation > succeeded, but... > > Closer to my question. `zlib.h' _is_ mentioned in zlib.cabal: > includes: zlib.h > According to documentation[2], `includes' "field applies to both header files > that are already installed on the system and to those coming with the package > to be isntalled." [NB the typo] > > I think that Cabal should complain of missing headers during configuration step. > At least of the ones explicitly mentioned in `includes:' field. Yes, I think so too. I mentioned this in ticket #177 http://hackage.haskell.org/trac/hackage/ticket/177#comment:5 Perhaps you could file a separate ticket about checking that all specified header files and C libs can be found at configure time. We'd want to use the same technique that autoconf uses. If you or anyone else wants to work on implementing the check then that'd be great. We're aiming for a Cabal-1.4 release in the next month or so. Duncan From Malcolm.Wallace at cs.york.ac.uk Tue Mar 18 07:23:06 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Mar 18 07:25:06 2008 Subject: haskell.org is accepted to GSoC Message-ID: <20080318112306.59770bdc.Malcolm.Wallace@cs.york.ac.uk> Google announced last night that Haskell.org has been accepted as a mentoring organisation for this year's Summer of Code (amongst 175 Open Source organisations). http://code.google.com/soc/2008/ The game is on! Student applications open at 1900 UTC on Mon 24th March, and close at 2400 UTC on Mon 31st March. In the meantime, my _strong_ suggestion is for students to search for ideas amongst the many lists available on the web: http://hackage.haskell.org/trac/summer-of-code/ http://haskell.org/haskellwiki/Hac_2007_II/Projects http://haskell.org/haskellwiki/Hac4/Projects and when crafting your proposal: * post it to an appropriate mailing list for comments e.g. haskell-cafe, libraries, wxHaskell, cabal-devel (prefix your subject line with [GSoC] to make it easy to find) * use feedback from the list to improve your proposal. Potential mentors will rank your final submitted proposal based on your ability and commitment to engage with the wider Haskell community, in addition to technical merit. Proposals that will benefit the entire Haskell world will generally be ranked more highly than niche projects with only a few potential users. So things like Cabal-hacking, darcs-hacking, compiler-hacking, are good, as are new libraries to do tasks that are in high demand. (This is not an exhaustive list.) Regards, Malcolm From gracjanpolak at gmail.com Tue Mar 18 09:46:28 2008 From: gracjanpolak at gmail.com (Gracjan Polak) Date: Tue Mar 18 09:46:53 2008 Subject: [ANN] Memory mapped files for POSIX and Windows Message-ID: Hi all, I just uploaded mmap to hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mmap The package provides memory mapping abstractions for both POSIX and Windows systems like Vista, Linux and Mac OSX. This library provides a wrapper to mmap(2) or MapViewOfFile, allowing files or devices to be lazily loaded into memory as strict or lazy ByteStrings, ForeignPtrs or even plain Ptrs, using the virtual memory subsystem to do on-demand loading. Modifications are also supported. Package includes a cp-like copy utility that uses different mechanisms to copy contents of file. Here come some statistics from using it on 90MB file: Windows: Prelude copy: 10.453 sec ByteString copy: 0.625 sec ByteString.Lazy copy: 0.516 sec MMap copy: 0.281 sec MMap copy lazy: 0.250 sec Linux: Prelude copy: 3.332 sec ByteString copy: 0.280 sec ByteString.Lazy copy: 0.292 sec MMap copy: 0.264 sec MMap copy lazy: 0.200 sec Mac OSX ppc Tiger 10.4 Prelude copy: 5.719 sec ByteString copy: 0.701 sec ByteString.Lazy copy: 0.864 sec MMap copy: 1.073 sec MMap copy lazy: 1.414 sec Hardware is different on those systems, so only relative comparison makes sense. Memory mapping provides significant advantages on Windows and Linux, not so on Mac OSX. Seems like mmap on Mac is not very well implemented. Any feedback is welcome! -- Gracjan From droundy at darcs.net Tue Mar 18 15:15:48 2008 From: droundy at darcs.net (David Roundy) Date: Tue Mar 18 15:12:32 2008 Subject: [ANN] Memory mapped files for POSIX and Windows In-Reply-To: References: Message-ID: <20080318191547.GP28119@darcs.net> On Tue, Mar 18, 2008 at 01:46:28PM +0000, Gracjan Polak wrote: > I just uploaded mmap to hackage: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mmap > > The package provides memory mapping abstractions for both POSIX and Windows > systems like Vista, Linux and Mac OSX. This library provides a wrapper to > mmap(2) or MapViewOfFile, allowing files or devices to be lazily loaded into > memory as strict or lazy ByteStrings, ForeignPtrs or even plain Ptrs, using > the virtual memory subsystem to do on-demand loading. Modifications are also > supported. > > Package includes a cp-like copy utility that uses different mechanisms to copy > contents of file. Here come some statistics from using it on 90MB file: Incidentally, you'll probably find that for large files, using mmap on Windows is a huge loser when compared with lazy bytestrings. As far as I understand, on Windows when a file is mmapped, its entire contents are immediately loaded into memory, so if you mmap a file that is larger than your memory, you pay a huge penalty on Windows. I'm not sure what the target audience for this library is, but I'd be surprised if it turns out to be useful for much more than toy projects (or posix-only projects), just because the Windows file system semantics are so screwed up. :( -- David Roundy Department of Physics Oregon State University From bulat.ziganshin at gmail.com Tue Mar 18 16:03:23 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Mar 18 16:01:28 2008 Subject: [ANN] Memory mapped files for POSIX and Windows In-Reply-To: <20080318191547.GP28119@darcs.net> References: <20080318191547.GP28119@darcs.net> Message-ID: <88062578.20080318230323@gmail.com> Hello David, Tuesday, March 18, 2008, 10:15:48 PM, you wrote: > Incidentally, you'll probably find that for large files, using mmap on > Windows is a huge loser when compared with lazy bytestrings. As far as I > understand, on Windows when a file is mmapped, its entire contents are > immediately loaded into memory, so if you mmap a file that is larger than > your memory, you pay a huge penalty on Windows. it's definitely not true, at least for my own experiments. although i never tried o map entire file to memory, but used only small window into file. mmaping for windows and linux implemented in http://www.haskell.org/library/StreamsBeta.tar.gz where it used just to make i/o faster. at least i tried but found undesirable effects, but not one you have mentioned -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Tue Mar 18 16:55:39 2008 From: dons at galois.com (Don Stewart) Date: Tue Mar 18 16:52:25 2008 Subject: [ANN] Memory mapped files for POSIX and Windows In-Reply-To: References: Message-ID: <20080318205539.GA550@scytale.galois.com> gracjanpolak: > Hi all, > > I just uploaded mmap to hackage: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mmap > > The package provides memory mapping abstractions for both POSIX and Windows > systems like Vista, Linux and Mac OSX. This library provides a wrapper to > mmap(2) or MapViewOfFile, allowing files or devices to be lazily loaded into > memory as strict or lazy ByteStrings, ForeignPtrs or even plain Ptrs, using > the virtual memory subsystem to do on-demand loading. Modifications are also > supported. > Cool. I spent a fair bit of time last year working on getting good performance on unix out of lazy bytestrings with individually mapped chunks. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-mmap-0.2.0 Can you talk about the relationship between these two packages? -- Don From gracjanpolak at gmail.com Wed Mar 19 06:14:00 2008 From: gracjanpolak at gmail.com (Gracjan Polak) Date: Wed Mar 19 06:10:59 2008 Subject: [ANN] Memory mapped files for POSIX and Windows References: <20080318191547.GP28119@darcs.net> <88062578.20080318230323@gmail.com> Message-ID: Bulat Ziganshin gmail.com> writes: > into file. mmaping for windows and linux implemented in > http://www.haskell.org/library/StreamsBeta.tar.gz where it used just > to make i/o faster. at least i tried but found undesirable effects, > but not one you have mentioned > I did not know about your package. Surely will look into it. -- Gracjan From gracjanpolak at gmail.com Wed Mar 19 06:23:25 2008 From: gracjanpolak at gmail.com (Gracjan Polak) Date: Wed Mar 19 06:20:26 2008 Subject: [ANN] Memory mapped files for POSIX and Windows References: <20080318205539.GA550@scytale.galois.com> Message-ID: Don Stewart galois.com> writes: > > Can you talk about the relationship between these two packages? I looked at your package very carefully and they are... different :) I tried to provide common API for both POSIX and Windows, so it is the lowest common denominator approach. Your API is read-only, my provides both reading and writing to/from Ptrs or ForeignPtrs. ByteStrings are layered on top of this. My lazy version can mmap files larger than available address space, yours cannot. Target audience is of course myself and few others that read files about 100MB in size semi-randomly. -- Gracjan From droundy at darcs.net Wed Mar 19 11:34:21 2008 From: droundy at darcs.net (David Roundy) Date: Wed Mar 19 11:31:02 2008 Subject: [ANN] Memory mapped files for POSIX and Windows In-Reply-To: <88062578.20080318230323@gmail.com> References: <20080318191547.GP28119@darcs.net> <88062578.20080318230323@gmail.com> Message-ID: <20080319153420.GT28119@darcs.net> On Tue, Mar 18, 2008 at 11:03:23PM +0300, Bulat Ziganshin wrote: > Hello David, > > Tuesday, March 18, 2008, 10:15:48 PM, you wrote: > > > Incidentally, you'll probably find that for large files, using mmap on > > Windows is a huge loser when compared with lazy bytestrings. As far as I > > understand, on Windows when a file is mmapped, its entire contents are > > immediately loaded into memory, so if you mmap a file that is larger than > > your memory, you pay a huge penalty on Windows. > > it's definitely not true, at least for my own experiments. although i > never tried o map entire file to memory, but used only small window > into file. mmaping for windows and linux implemented in > http://www.haskell.org/library/StreamsBeta.tar.gz where it used just > to make i/o faster. at least i tried but found undesirable effects, > but not one you have mentioned I've never tried this (since I don't have windows), but it's what I've been told. And no, you wouldn't have noticed unless you tried to mmap a large file in its entirety. It's a major difference in behavior, though, between posix and windows mmap. The former behaves essentially like a faster, better version of lazy IO (provided you don't try to modify the file in-place) that is a major improvement when under tight memory pressure (because it's file-backed memory). The latter is quite the opposite. -- David Roundy Department of Physics Oregon State University From igloo at earth.li Wed Mar 19 12:45:23 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Mar 19 12:42:05 2008 Subject: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <777240.31684.qm@web56405.mail.re3.yahoo.com> References: <216132.29104.qm@web56414.mail.re3.yahoo.com> <777240.31684.qm@web56405.mail.re3.yahoo.com> Message-ID: <20080319164523.GA14964@matrix.chaos.earth.li> On Fri, Feb 29, 2008 at 07:36:36PM -0800, Andriy Palamarchuk wrote: > Could somebody please commit the patch attached to > this ticket? Applied, thanks! Ian From dons at galois.com Wed Mar 19 13:18:35 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 19 13:15:28 2008 Subject: [ANN] Memory mapped files for POSIX and Windows In-Reply-To: References: <20080318205539.GA550@scytale.galois.com> Message-ID: <20080319171835.GA9086@scytale.galois.com> gracjanpolak: > Don Stewart galois.com> writes: > > > > Can you talk about the relationship between these two packages? > > I looked at your package very carefully and they are... different :) > > I tried to provide common API for both POSIX and Windows, so it is the > lowest common denominator approach. > > Your API is read-only, my provides both reading and writing to/from > Ptrs or ForeignPtrs. ByteStrings are layered on top of this. > > My lazy version can mmap files larger than available address space, > yours cannot. > > Target audience is of course myself and few others that read files > about 100MB in size semi-randomly. > Thanks for the info! Do you think we should merge these packages? Or are they really for difference use cases -- I wouldn't know when to use one over the other, currently. Do your lazy bytestrings support unmapping individiual chunks? How do you support files larger than the address space? -- Don From duncan.coutts at worc.ox.ac.uk Thu Mar 20 10:29:56 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 20 10:26:56 2008 Subject: building a helper binary with cabal In-Reply-To: <3a6f89fc0803021434g13966616tbd73e1683cc90a06@mail.gmail.com> References: <3a6f89fc0803010002g29b98f08qbecdd95eaea13d14@mail.gmail.com> <1204370477.11558.101.camel@localhost> <3a6f89fc0803010917u2b0fc955n49bc052ea99f0643@mail.gmail.com> <3a6f89fc0803010940s6d51c40ftdfdcbb62b2dd21bb@mail.gmail.com> <1204481514.11558.111.camel@localhost> <3a6f89fc0803021434g13966616tbd73e1683cc90a06@mail.gmail.com> Message-ID: <1206023396.7594.145.camel@localhost> Sorry, this dropped of my to-reply-to list, did you get this figured out? Duncan On Sun, 2008-03-02 at 14:34 -0800, Evan Martin wrote: > On Sun, Mar 2, 2008 at 10:11 AM, Duncan Coutts > wrote: > > The install phase is really two phases, copy and register. The copy > > phase has the CopyDest param. The default install hook just runs the > > copy and register phases. So you probably want to override the copy hook > > and not the install one. > > It seems the default copy hook just runs the install hook, and that > the install hook doesn't run the copy one... ? > > http://haskell.org/ghc/docs/latest/html/libraries/Cabal/src/Distribution-Simple.html#simpleUserHooks > copyHook = \desc lbi _ f -> install desc lbi f, -- has correct > 'copy' behavior with params > > I'm sure I'm just missing something here, but my "postCopy" hook > doesn't seem to be running with "install -v3". > > > The hooks stuff is all really very confusing and unsatisfactory. > > I agree, but I can also appreciate how difficult it must be to design, > and can acknowledge that it may be the case that it really just needs > to be this complicated. Having used autoconf and friends before, one > thing I really prefer about this system is that there are bazillion > different types which helps prevent you from accidentally doing > something like putting a intermediate object in the source dir or > installing while ignoring the user's prefix. From duncan.coutts at worc.ox.ac.uk Fri Mar 21 03:19:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Mar 21 03:16:04 2008 Subject: inotify bindings Message-ID: <1206083965.7594.201.camel@localhost> Hi Adam, Could you give us a comparison of the existing hinotify package and your new system-inotify package? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hinotify-0.2 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/system-inotify-0.1 What are the key differences? Do you think we could merge the best ideas and have a single package or are the approaches incompatible in some way? Thanks. Duncan From alistair at abayley.org Fri Mar 21 05:09:05 2008 From: alistair at abayley.org (Alistair Bayley) Date: Fri Mar 21 05:05:47 2008 Subject: ANN: Takusen 0.8.1 Message-ID: <79d7c4980803210209y30496aaeve42a0a88295afad3@mail.gmail.com> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Takusen-0.8.1 This is a fairly minor bugfix release. although there are some API changes. Mainly, we've re-exported a lot of the types from Database.InternalEnumerator in Database.Enumerator. This will hopefully address a common complaint that it's impossible to always write type sigs for functions doing database stuff. We've also tidied up some of the exports; there was stuff exposed that shouldn't have been. There's an outstanding bug involving datetime parameter marshaling in ODBC, which I have not had time to resolve (parameters after the datetime parameter get mangled somehow). I will be on holiday for a few weeks, so this will not be addressed by me for some time. Caveat user. The test suite highlights it, should someone else feel sufficiently motivated; I've been testing against PostgreSQL. Alistair From agl at imperialviolet.org Fri Mar 21 11:41:50 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Mar 21 11:38:35 2008 Subject: inotify bindings In-Reply-To: <1206083965.7594.201.camel@localhost> References: <1206083965.7594.201.camel@localhost> Message-ID: <396556a20803210841q4d53619ci9097c64cd9547e6@mail.gmail.com> On Fri, Mar 21, 2008 at 12:19 AM, Duncan Coutts wrote: > Could you give us a comparison of the existing hinotify package and your > new system-inotify package? Blink. Drat. I swear I searched on Hackage yesterday for inotify and only saw the GrowlNotify package. I guess I mistyped. Sorry about that. Can you delete system-inotify from Hackage? Probably best not to have two, almost identical, packages. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From dons at galois.com Fri Mar 21 13:42:32 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 21 13:39:17 2008 Subject: inotify bindings In-Reply-To: <396556a20803210841q4d53619ci9097c64cd9547e6@mail.gmail.com> References: <1206083965.7594.201.camel@localhost> <396556a20803210841q4d53619ci9097c64cd9547e6@mail.gmail.com> Message-ID: <20080321174232.GA11577@scytale.galois.com> agl: > On Fri, Mar 21, 2008 at 12:19 AM, Duncan Coutts > wrote: > > Could you give us a comparison of the existing hinotify package and your > > new system-inotify package? > > Blink. Drat. > > I swear I searched on Hackage yesterday for inotify and only saw the > GrowlNotify package. I guess I mistyped. > > Sorry about that. Can you delete system-inotify from Hackage? Probably > best not to have two, almost identical, packages. Well, at least do a merge first :) There's probably documentation, at a minimum, that can be salvaged. This is a rather novel situation for the Haskell community -- we're now to assume that a library has already been written, and is on hackage, rather than assuming no one's done it yet :-) Kudos to the Cabal and Hackage devs! -- Don From niklas.broberg at gmail.com Fri Mar 21 13:50:56 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Mar 21 13:47:34 2008 Subject: Defunct packages (was: inotify bindings) Message-ID: > Sorry about that. Can you delete system-inotify from Hackage? Probably > best not to have two, almost identical, packages. Putting this in a more general perspective - how do you mark a package in Hackage defunct? If there's a newer package with the same name superceding an older one then it's not a problem. But if you have no newer package, what then? To be specific, I'm wondering what to do with the hspr package that will be discontinued in the new upcoming HSP release. It would be great to have a flag somewhere that marks it deprecated. Cheers, /Niklas From dons at galois.com Fri Mar 21 13:56:22 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 21 13:52:59 2008 Subject: Defunct packages (was: inotify bindings) In-Reply-To: References: Message-ID: <20080321175622.GC11577@scytale.galois.com> niklas.broberg: > > Sorry about that. Can you delete system-inotify from Hackage? Probably > > best not to have two, almost identical, packages. > > Putting this in a more general perspective - how do you mark a package > in Hackage defunct? If there's a newer package with the same name > superceding an older one then it's not a problem. But if you have no > newer package, what then? > > To be specific, I'm wondering what to do with the hspr package that > will be discontinued in the new upcoming HSP release. It would be > great to have a flag somewhere that marks it deprecated. Yes, marking things as either "broken" or "deprecated", and filtering them from the default view, would be a good feature. -- Don From dons at galois.com Fri Mar 21 14:03:38 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 21 14:00:19 2008 Subject: [Haskell-cafe] ANN: Takusen 0.8.1 In-Reply-To: <79d7c4980803210209y30496aaeve42a0a88295afad3@mail.gmail.com> References: <79d7c4980803210209y30496aaeve42a0a88295afad3@mail.gmail.com> Message-ID: <20080321180338.GE11577@scytale.galois.com> alistair: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Takusen-0.8.1 > > This is a fairly minor bugfix release. although there are some API > changes. Mainly, we've re-exported a lot of the types from > Database.InternalEnumerator in Database.Enumerator. This will > hopefully address a common complaint that it's impossible to always > write type sigs for functions doing database stuff. > > We've also tidied up some of the exports; there was stuff exposed that > shouldn't have been. > > There's an outstanding bug involving datetime parameter marshaling in > ODBC, which I have not had time to resolve (parameters after the > datetime parameter get mangled somehow). I will be on holiday for a > few weeks, so this will not be addressed by me for some time. Caveat > user. The test suite highlights it, should someone else feel > sufficiently motivated; I've been testing against PostgreSQL. > > Alistair Great work Alistair! Thanks for your continuing work on Takusen. -- Don From duncan.coutts at worc.ox.ac.uk Fri Mar 21 15:26:56 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Mar 21 15:23:35 2008 Subject: Defunct packages (was: inotify bindings) In-Reply-To: <20080321175622.GC11577@scytale.galois.com> References: <20080321175622.GC11577@scytale.galois.com> Message-ID: <1206127616.7594.210.camel@localhost> On Fri, 2008-03-21 at 10:56 -0700, Don Stewart wrote: > niklas.broberg: > > > Sorry about that. Can you delete system-inotify from Hackage? Probably > > > best not to have two, almost identical, packages. > > > > Putting this in a more general perspective - how do you mark a package > > in Hackage defunct? If there's a newer package with the same name > > superceding an older one then it's not a problem. But if you have no > > newer package, what then? > > > > To be specific, I'm wondering what to do with the hspr package that > > will be discontinued in the new upcoming HSP release. It would be > > great to have a flag somewhere that marks it deprecated. > > Yes, marking things as either "broken" or "deprecated", and filtering > them from the default view, would be a good feature. Right, we'd need to record that extra bit of information. There is a generic tags mechanism we could take advantage of for storage. We should file a feature request: http://hackage.haskell.org/trac/hackage/newticket Duncan From niklas.broberg at gmail.com Fri Mar 21 15:38:23 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Mar 21 15:34:59 2008 Subject: Defunct packages (was: inotify bindings) In-Reply-To: <1206127616.7594.210.camel@localhost> References: <20080321175622.GC11577@scytale.galois.com> <1206127616.7594.210.camel@localhost> Message-ID: > We should file a feature request: > > http://hackage.haskell.org/trac/hackage/newticket http://hackage.haskell.org/trac/hackage/ticket/261 Cheers, /Niklas From haskell-libs at contacts.eelis.net Fri Mar 21 21:42:43 2008 From: haskell-libs at contacts.eelis.net (Eelis van der Weegen) Date: Fri Mar 21 21:39:17 2008 Subject: GetOpt bug causing it to mistakenly reject options as ambiguous Message-ID: <52717.213.84.80.149.1206150163.squirrel@webmail.nxs.nl> Eelis van der Weegen wrote: > There is a bug in System.Console.GetOpt causing > it to mistakenly reject options as ambiguous. Two weeks have passed since I reported this, with no response thus far. Does nobody care about fixing an easily reproducable, easily fixable bug? If so, would it not be more appropriate if the "Maintainer" field in the GetOpt Haddock docs said "N/A" instead of "libraries@haskell.org"? Eelis From dons at galois.com Fri Mar 21 21:49:54 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 21 21:46:40 2008 Subject: GetOpt bug causing it to mistakenly reject options as ambiguous In-Reply-To: <52717.213.84.80.149.1206150163.squirrel@webmail.nxs.nl> References: <52717.213.84.80.149.1206150163.squirrel@webmail.nxs.nl> Message-ID: <20080322014954.GA24202@scytale.galois.com> haskell-libs: > Eelis van der Weegen wrote: > > There is a bug in System.Console.GetOpt causing > > it to mistakenly reject options as ambiguous. > > Two weeks have passed since I reported this, > with no response thus far. Does nobody care about > fixing an easily reproducable, easily fixable > bug? > > If so, would it not be more appropriate if the > "Maintainer" field in the GetOpt Haddock docs > said "N/A" instead of "libraries@haskell.org"? > The issue is that it needs to be entered into the bug tracker, then the base libraries maintainer will take care of it. Could you file a ticket, with your patch, here: http://haskell.org/haskellwiki/Library_submissions Then Igloo can apply it, and close the ticket. It won't get lost, and authority will be properly delegated. Thanks for the contribution! -- Don From igloo at earth.li Fri Mar 21 22:20:26 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Mar 21 22:16:59 2008 Subject: GetOpt bug causing it to mistakenly reject options as ambiguous In-Reply-To: <52717.213.84.80.149.1206150163.squirrel@webmail.nxs.nl> References: <52717.213.84.80.149.1206150163.squirrel@webmail.nxs.nl> Message-ID: <20080322022026.GA16740@matrix.chaos.earth.li> Hi Eelis, On Sat, Mar 22, 2008 at 02:42:43AM +0100, Eelis van der Weegen wrote: > Eelis van der Weegen wrote: > > There is a bug in System.Console.GetOpt causing > > it to mistakenly reject options as ambiguous. > > Two weeks have passed since I reported this, > with no response thus far. Does nobody care about > fixing an easily reproducable, easily fixable > bug? Thanks for the patch! Duncan applied it to the GetOpt in Cabal on the 11th: http://www.haskell.org/pipermail/cabal-devel/2008-March/002405.html and Malcolm then applied it to base's GetOpt on the 12th: http://www.haskell.org/pipermail/cvs-libraries/2008-March/008332.html Unfortunately, it looks like they forgot to send a mail to let you know what had happened! Sorry about that. Thanks Ian From haskell-libs at contacts.eelis.net Fri Mar 21 22:26:19 2008 From: haskell-libs at contacts.eelis.net (Eelis van der Weegen) Date: Fri Mar 21 22:22:52 2008 Subject: GetOpt bug causing it to mistakenly reject options as ambiguous In-Reply-To: <20080322014954.GA24202@scytale.galois.com> References: <52717.213.84.80.149.1206150163.squirrel@webmail.nxs.nl> <20080322014954.GA24202@scytale.galois.com> Message-ID: <56961.213.84.80.149.1206152779.squirrel@webmail.nxs.nl> Don Stewart wrote: > Could you file a ticket, with your patch After pulling HEAD to prepare a proper darcs patch (as per library submission procedure), I found that Malcolm Wallace had actually already applied the fix. :-) Next time I'll follow procedure. Thanks Don, Malcolm. Eelis From ross at soi.city.ac.uk Fri Mar 21 22:28:34 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Mar 21 22:25:10 2008 Subject: GetOpt bug causing it to mistakenly reject options as ambiguous In-Reply-To: <20080322014954.GA24202@scytale.galois.com> References: <52717.213.84.80.149.1206150163.squirrel@webmail.nxs.nl> <20080322014954.GA24202@scytale.galois.com> Message-ID: <20080322022833.GA2084@soi.city.ac.uk> On Fri, Mar 21, 2008 at 06:49:54PM -0700, Don Stewart wrote: > The issue is that it needs to be entered into the bug tracker, > then the base libraries maintainer will take care of it. > > Could you file a ticket, with your patch, here: > > http://haskell.org/haskellwiki/Library_submissions > > Then Igloo can apply it, and close the ticket. It won't get lost, and > authority will be properly delegated. This should suffice, as it isn't an API change: http://hackage.haskell.org/trac/ghc/newticket?type=bug&component=libraries/base From duncan.coutts at worc.ox.ac.uk Sat Mar 22 17:59:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Mar 22 17:55:57 2008 Subject: Defunct packages (was: inotify bindings) In-Reply-To: References: <20080321175622.GC11577@scytale.galois.com> <1206127616.7594.210.camel@localhost> Message-ID: <1206223165.7594.224.camel@localhost> On Fri, 2008-03-21 at 20:38 +0100, Niklas Broberg wrote: > > We should file a feature request: > > > > http://hackage.haskell.org/trac/hackage/newticket > > http://hackage.haskell.org/trac/hackage/ticket/261 Thanks. I've added a comment and marked it as being reasonably easy. Don't take that as a sign that the overworked hackage maintainers will do it, take it as a message that any interested hacker should be able to grab the code and craft a patch. :-) darcs get --partial http://darcs.haskell.org/hackage-scripts/ Duncan From duncan.coutts at worc.ox.ac.uk Sat Mar 22 17:59:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Mar 22 17:56:26 2008 Subject: inotify bindings In-Reply-To: <396556a20803210841q4d53619ci9097c64cd9547e6@mail.gmail.com> References: <1206083965.7594.201.camel@localhost> <396556a20803210841q4d53619ci9097c64cd9547e6@mail.gmail.com> Message-ID: <1206223193.7594.226.camel@localhost> On Fri, 2008-03-21 at 08:41 -0700, Adam Langley wrote: > On Fri, Mar 21, 2008 at 12:19 AM, Duncan Coutts > wrote: > > Could you give us a comparison of the existing hinotify package and your > > new system-inotify package? > > Blink. Drat. > > I swear I searched on Hackage yesterday for inotify and only saw the > GrowlNotify package. I guess I mistyped. > > Sorry about that. Can you delete system-inotify from Hackage? Probably > best not to have two, almost identical, packages. Let's ask Lennart to take a look at the code and merge the best ideas. I don't think we should delete packages but we should see about marking packages as superseded: http://hackage.haskell.org/trac/hackage/ticket/261 Duncan From dons at galois.com Mon Mar 24 03:12:27 2008 From: dons at galois.com (Don Stewart) Date: Mon Mar 24 03:09:03 2008 Subject: Libraries need a new owner In-Reply-To: <47497409.6050601@iee.org> References: <47497409.6050601@iee.org> Message-ID: <20080324071227.GA9750@scytale.galois.com> ahey: > Hello Folks, > > As some of you will be aware, I have been working on various Map > implementations that currently live here.. > > http://code.haskell.org/collections/collections-ghc6.8 > > The libs in question being Data.Tree.AVL, Data.Trie.General and a few > other bits like Data.COrdering and the AVL based Data.Map/Set clones. > > Well, I have decided to stop work on these. So they need a new owner if > they're going to go anywhere. If anyone is interested in the job then I > suggest they contact myself or Jean-Philippe Bernardy. > > Of course I will be happy to provide any help or advise anyone who takes > over these libs may feel they need from me. I might even contribute a > few patches from time to time myself :-) > > Thanks How about we propose this work be done for Summer of Code. I've created a ticket here: http://hackage.haskell.org/trac/summer-of-code/ticket/1549 Add comments, or if you can mentor, add that information too! Let's get a new faster Data.Map and other containers ready to go by the end of the northern summer? -- Don From matthew.pocock at ncl.ac.uk Mon Mar 24 06:47:48 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Mon Mar 24 06:44:19 2008 Subject: [Haskell-cafe] Re: Libraries need a new owner In-Reply-To: <20080324071227.GA9750@scytale.galois.com> References: <47497409.6050601@iee.org> <20080324071227.GA9750@scytale.galois.com> Message-ID: <200803241047.49217.matthew.pocock@ncl.ac.uk> On Monday 24 March 2008, Don Stewart wrote: > Let's get a new faster Data.Map and other containers ready to go by the > end of the northern summer? And while we are visiting this, can I put in a vote for a seperation between the default Data.* container concrete implementations and associated classes? E.g. between the cannonical Map implementation and a Map class that could (if I felt mad) be backed by a list, or (if I was more sane) the cannonical Map datatype? This would go /at least/ for Map, Set, List. Matthew > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From gale at sefer.org Tue Mar 25 08:39:09 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Mar 25 08:35:36 2008 Subject: Cabal semantics for multiple compilers In-Reply-To: <2608b8a80803091637m5112637ct3b28e8f539f92029@mail.gmail.com> References: <2608b8a80803090312v3d3019f5o4efd9dd844ced3aa@mail.gmail.com> <1205091910.11558.489.camel@localhost> <2608b8a80803091637m5112637ct3b28e8f539f92029@mail.gmail.com> Message-ID: <2608b8a80803250539i1e094b8fheccd75f7dd5670ec@mail.gmail.com> I wrote: >>> When I install packages, both copies >>> of GHC 6.8.2 will want to install them into /usr/local. Cabal >>> uses directory names like "ghc-6.8.2" to keep installations >>> for different compilers separate from each other. But what >>> if both of the compilers are called "ghc-6.8.2"? Duncan Coutts wrote: >> Then they will clash. Don't do that :-) > Ouch. I was afraid of that. This is going to be tricky. Added http://hackage.haskell.org/trac/hackage/ticket/263 Regards, Yitz From ahey at iee.org Tue Mar 25 12:45:58 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Mar 25 12:43:58 2008 Subject: Libraries need a new owner In-Reply-To: <20080324071227.GA9750@scytale.galois.com> References: <47497409.6050601@iee.org> <20080324071227.GA9750@scytale.galois.com> Message-ID: <47E92C46.5020605@iee.org> Don Stewart wrote: > ahey: >> Hello Folks, >> >> As some of you will be aware, I have been working on various Map >> implementations that currently live here.. >> >> http://code.haskell.org/collections/collections-ghc6.8 >> >> The libs in question being Data.Tree.AVL, Data.Trie.General and a few >> other bits like Data.COrdering and the AVL based Data.Map/Set clones. >> >> Well, I have decided to stop work on these. So they need a new owner if >> they're going to go anywhere. If anyone is interested in the job then I >> suggest they contact myself or Jean-Philippe Bernardy. >> >> Of course I will be happy to provide any help or advise anyone who takes >> over these libs may feel they need from me. I might even contribute a >> few patches from time to time myself :-) >> >> Thanks > > How about we propose this work be done for Summer of Code. > > I've created a ticket here: > > http://hackage.haskell.org/trac/summer-of-code/ticket/1549 > > Add comments, or if you can mentor, add that information too! > > Let's get a new faster Data.Map and other containers ready to go by the > end of the northern summer? Hello Don, I'm not sure what you're proposing as the SOC project, but I don't think getting AVL based Data.Map/Set clones in Hackage is particularly suitable or challenging. This work is 99% done and also quite boring. It could be finished by the end of today if I set my mind to it :-) There are 3 significant things that really need doing IMO. 1- Try to reconcile the apparent differences between the collections package and Edison class APIs. I don't really understand either myself, but having multiple classes for "the same" things makes both implementors and test suite writers lives harder. The generalised trie class "GT" should still be kept separate as it needs some weird class methods in order to make new instances from old and can't really be finalised until this type families stuff is available anyway. 2- Write a polymorphic test and benchmarking suite for sets, maps, sequences etc. This would be really useful and is something that could reasonably be done as SOC project. But it may also be little boring :-( This could be based on classes defined as a result of 1 (above), or failing that the author would have to define yet another set of class APIs for test/benchmarking only. This may be the simpler approach as it doesn't assume anything about Edison or collections abstractions (it's just a way of testing concrete data structure implementations). 3- Produce some way of automatically deriving (efficient) generalised trie (GT) instances for user defined types. The API is huge and complex (and likely to get bigger still), so hand writing instances really isn't realistic in the long run. But this may be a bit premature for SOC as the GT class API itself is not yet complete or stable, and probably won't be until type families are available (and tested and documented and someone takes the trouble to finish it). So maybe this is something for next years SOC? That said, I know that type families are provisionally available, so maybe doing something with generalised tries might be possible. I don't mind mentoring anyone who wants to do something with any of this. Regards -- Adrian Hey From kolmodin at dtek.chalmers.se Tue Mar 25 13:50:46 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Tue Mar 25 13:27:28 2008 Subject: inotify bindings In-Reply-To: <20080321174232.GA11577@scytale.galois.com> References: <1206083965.7594.201.camel@localhost> <396556a20803210841q4d53619ci9097c64cd9547e6@mail.gmail.com> <20080321174232.GA11577@scytale.galois.com> Message-ID: <47E93B76.3040000@dtek.chalmers.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Don Stewart wrote: | agl: |> On Fri, Mar 21, 2008 at 12:19 AM, Duncan Coutts |> wrote: |>> Could you give us a comparison of the existing hinotify package and your |>> new system-inotify package? |> Blink. Drat. |> |> I swear I searched on Hackage yesterday for inotify and only saw the |> GrowlNotify package. I guess I mistyped. |> |> Sorry about that. Can you delete system-inotify from Hackage? Probably |> best not to have two, almost identical, packages. Very interesting to see another lib solving the same problem, with somewhat different approaches :) | Well, at least do a merge first :) Lets see where they differ: System-inotify provides a lower level interface where you call a 'next' function to get the next event, while the hinotify lib let you register callbacks to each watch which are then called when a event happen. The events in system-inotify is pretty much a 1:1 to the C event, while hinotify extracts the pieces set in the event into different constructors. Compare: data Event = Event { evwatch :: Watch ~ , evevents :: [ChangeEvent] -- Accessed, for example ~ , evalerts :: [Alert] ~ , evcookie :: Word32 ~ , evname :: B.ByteString ~ } deriving (Show) to: data Event = ~ Accessed ~ { isDirectory :: Bool ~ , maybeFilePath :: Maybe FilePath ~ } ~ | ... The latter event is passed to the callback to the particular watch, thus it does not contain as much data. Learning from the experience in bos blog[1] it is interesting to provide a lower level of abstraction too, which the higher level could be built on top. Neither of the packages delay the reading of events[1]. hinotify tries to be thread safe. System-inotify too, but I think it requires a patch or two before it really is. They are both small libs, and could both easily be adapted. I like the approach with several constructors for the Event data type, as the programmer can see what information is actually set for each event. For the hinotify lib, the callback API should probably be extracted into a separate module, so that both lower and higher APIs available. | There's probably documentation, at a minimum, that can be salvaged. Both packages refer to the docs upstream, not heavily documented themselves. :) | This is a rather novel situation for the Haskell community -- we're now | to assume that a library has already been written, and is on hackage, | rather than assuming no one's done it yet :-) Hah, yes. :) | Kudos to the Cabal and Hackage devs! Indeed. Cheers, ~ Lennart Kolmodin [1] http://www.serpentine.com/blog/2008/01/04/why-you-should-not-use-pyinotify/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6Tt24txYG4KUCuERAjY8AJ4+7LkNsBrpa1MQQSgB97JuSNzVzACdFd7D TUo+vgMqPJyBojYxvrtpOts= =N+wK -----END PGP SIGNATURE----- From dons at galois.com Tue Mar 25 17:17:23 2008 From: dons at galois.com (Don Stewart) Date: Tue Mar 25 17:13:59 2008 Subject: Libraries need a new owner In-Reply-To: <47E92C46.5020605@iee.org> References: <47497409.6050601@iee.org> <20080324071227.GA9750@scytale.galois.com> <47E92C46.5020605@iee.org> Message-ID: <20080325211723.GH31952@scytale.galois.com> ahey: > Don Stewart wrote: > >ahey: > >>Hello Folks, > >> > >>As some of you will be aware, I have been working on various Map > >>implementations that currently live here.. > >> > >>http://code.haskell.org/collections/collections-ghc6.8 > >> > >>The libs in question being Data.Tree.AVL, Data.Trie.General and a few > >>other bits like Data.COrdering and the AVL based Data.Map/Set clones. > >> > >>Well, I have decided to stop work on these. So they need a new owner if > >>they're going to go anywhere. If anyone is interested in the job then I > >>suggest they contact myself or Jean-Philippe Bernardy. > >> > >>Of course I will be happy to provide any help or advise anyone who takes > >>over these libs may feel they need from me. I might even contribute a > >>few patches from time to time myself :-) > >> > >>Thanks > > > >How about we propose this work be done for Summer of Code. > > > >I've created a ticket here: > > > > http://hackage.haskell.org/trac/summer-of-code/ticket/1549 > > > >Add comments, or if you can mentor, add that information too! > > > >Let's get a new faster Data.Map and other containers ready to go by the > >end of the northern summer? > > Hello Don, > > I'm not sure what you're proposing as the SOC project, but I don't think > getting AVL based Data.Map/Set clones in Hackage is particularly > suitable or challenging. This work is 99% done and also quite boring. > It could be finished by the end of today if I set my mind to it :-) I was more putting it in as a stub for you to round out to a full SoC proposal to work on data structure things.. :) > There are 3 significant things that really need doing IMO. > 1- Try to reconcile the apparent differences between the collections > package and Edison class APIs. I don't really understand either > myself, but having multiple classes for "the same" things makes > both implementors and test suite writers lives harder. > The generalised trie class "GT" should still be kept separate as > it needs some weird class methods in order to make new instances > from old and can't really be finalised until this type families > stuff is available anyway. > > 2- Write a polymorphic test and benchmarking suite for sets, maps, > sequences etc. This would be really useful and is something that > could reasonably be done as SOC project. But it may also be little > boring :-( > This could be based on classes defined as a result of 1 (above), > or failing that the author would have to define yet another set > of class APIs for test/benchmarking only. This may be the simpler > approach as it doesn't assume anything about Edison or collections > abstractions (it's just a way of testing concrete data structure > implementations). > > 3- Produce some way of automatically deriving (efficient) generalised > trie (GT) instances for user defined types. The API is huge and > complex (and likely to get bigger still), so hand writing instances > really isn't realistic in the long run. > But this may be a bit premature for SOC as the GT class API itself > is not yet complete or stable, and probably won't be until type > families are available (and tested and documented and someone > takes the trouble to finish it). > So maybe this is something for next years SOC? > > That said, I know that type families are provisionally available, so > maybe doing something with generalised tries might be possible. > I don't mind mentoring anyone who wants to do something with any of > this. Great! Would you like to revise the Soc ticket, with this information? Getting some usable generalised tries available would be a great result. -- Don From ahey at iee.org Thu Mar 27 10:16:25 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Mar 27 10:13:00 2008 Subject: Libraries need a new owner In-Reply-To: <20080325211723.GH31952@scytale.galois.com> References: <47497409.6050601@iee.org> <20080324071227.GA9750@scytale.galois.com> <47E92C46.5020605@iee.org> <20080325211723.GH31952@scytale.galois.com> Message-ID: <47EBAC39.2030307@iee.org> Don Stewart wrote: >> That said, I know that type families are provisionally available, so >> maybe doing something with generalised tries might be possible. >> I don't mind mentoring anyone who wants to do something with any of >> this. > > Great! Would you like to revise the Soc ticket, with this information? > > Getting some usable generalised tries available would be a great > result. Hello Don, I created a new Generalised Tries specific ticket.. http://hackage.haskell.org/trac/summer-of-code/ticket/1560 Do I need to do more? (not really sure how the whole process works). Who decides if proposals are good/ok/bad? Not me I assume :-) Regards -- Adrian Hey From valery.vv at gmail.com Fri Mar 28 18:15:37 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Fri Mar 28 18:11:52 2008 Subject: [hackagedb] plugins-1.1 FTBFS Message-ID: Hi, `plugins-1.1.tar.gz', available at HackageDB page[1], fails to configure. The darcs version[2] installs successfully. 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/plugins 2. http://code.haskell.org/~dons/code/hs-plugins What can we do to fix .tar.gz source distribution? -- vvv From dons at galois.com Fri Mar 28 18:27:37 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 28 18:23:57 2008 Subject: [hackagedb] plugins-1.1 FTBFS In-Reply-To: References: Message-ID: <20080328222737.GN32404@scytale.galois.com> valery.vv: > Hi, > > `plugins-1.1.tar.gz', available at HackageDB page[1], fails to configure. > The darcs version[2] installs successfully. > > 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/plugins > 2. http://code.haskell.org/~dons/code/hs-plugins > > What can we do to fix .tar.gz source distribution? > > -- Sigh, David G. did a snapshot and upload it seems, of a broken package. A correct 1.1 tarball could be constructed and uploaded in its place. -- Don From duncan.coutts at worc.ox.ac.uk Sat Mar 29 16:31:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Mar 29 16:27:14 2008 Subject: ANNOUNCE: Cabal-1.4 release candidate Message-ID: <20080329203104.5981084128@webmail219.herald.ox.ac.uk> Hi everyone, == Cabal-1.4 release candidate == The first release candidate of Cabal-1.4 is out: http://haskell.org/cabal/release/cabal-1.3.10/Cabal-1.3.10.tar.gz Please test and report bugs: http://hackage.haskell.org/trac/hackage/ The aim for the Cabal-1.4 release is to get various fixes and improvements into the hands of developers and to support a release of cabal-install. == cabal-install == A snapshot of cabal-install is available: http://haskell.org/cabal/release/cabal-install-0.4.6.tar.gz It requires the zlib and HTTP packages (both are available from hackage). Bug reports should go in the same trac as above. cabal-install is intended to be the standard command line interface to the whole Cabal/Hackage system. It replaces the "runhaskell Setup.hs" interface and a few other tools you may or may not have heard of (cabal-setup, cabal-upload, cabal-get). cabal-install is usable now and we will be making a proper release some time after the Cabal-1.4 release. == Compatibility == We have tried to preserve compatibility with all packages that worked with the Cabal-1.2.x series. That is, packages that can be built using Cabal (including custom Setup.hs scripts) but not packages that directly import and use the Cabal API. Packages that directly import and use the Cabal api will need updating. This affects packages that build distro packages for example, rpm debs etc. Currently we know of three packages on hackage where their Setup.hs scripts compile with 1.2 but fail to compile with 1.4. We expect to make one further change before the Cabal-1.4 release that will fix two of those packages. The one remaining package, Takusen, will require an update to be able to work with both Cabal-1.2.x and 1.4.x. A patch has been sent to the maintainers of Takusen. == Remaining issues == There are a couple issues we expect to fix before the Cabal-1.4.0 release: * stricter decoding of UTF-8 in .cabal files (we'll borrow the code from the utf8-string package) * compatibility with the couple Setup.hs scripts that use the function Distribution.PackageDescription.writeHookedBuildInfo There are also a few bug fixes and enhancements we think we can probably do in the 1.4.x stable series without breaking any APIs: http://hackage.haskell.org/trac/hackage/query?status=new&status=assigned& status=reopened&group=component&milestone=Cabal-1.4&order=priority == Credits == On behalf of the Cabal hackers and the community generally I'd like to thank the large number of people who have contributed patches during this development series. Previously I was rather worried that we were not getting enough contributors to fix bugs and do new feature development, but now I'm very pleased. :-) == Get involved == Of course there's still a lot to do! We have big plans for Cabal-2.0, cabal-install and the Hackage website. So if you're interested in helping out with this core infrastructure project then: * subscribe to the cabal-devel mailing list: http://www.haskell.org/mailman/listinfo/cabal-devel * grab the source: http://haskell.org/cabal/code.html * read the guide to the source code: http://hackage.haskell.org/trac/hackage/wiki/SourceGuide * take a look at our list of bugs and feature requests: http://hackage.haskell.org/trac/hackage/report/12 especially the easy tickets: http://hackage.haskell.org/trac/hackage/report/13 Duncan (wearing his Cabal release manager hat) From catamorphism at gmail.com Sat Mar 29 17:02:22 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Sat Mar 29 16:58:34 2008 Subject: Character escape codes in Parsec Message-ID: <4683d9370803291402i2fdbbb81k1ed2f2c0e7cee9de@mail.gmail.com> Hi all, I'm using the version of Text.ParserCombinators.Parsec.Token that ships with GHC 6.8.2. I'm trying to use the stringLiteral parser that makeTokenParser uses by default to parse strings that may contain hex ASCII escape codes of the form: \x [hex-digit] [hex-digit] For example, "\x0a" should parse to "\n". On the other hand, "\x0aE" should parse to "\nE". I don't get this behavior with Parsec, though: "\x0aE" parses to "\174". I can tell from looking at the source that a hex escape code is defined to be "\x" followed by an arbitrary-length sequence of hex digits. I think this is wrong, because in ASCII, such an escape sequence has exactly two digits. I can't exactly tell from looking at the source, but is the default token parser in Parsec supposed to be parsing ASCII strings? If so, isn't this a bug in Parsec? If not, and it's meant to be able to handle Unicode or something, I think the documentation should be clearer. I'd much welcome any enlightenment. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "and the things I'm working on are invisible to everyone"--Meg Hutchinson From flippa at flippac.org Sun Mar 30 11:01:39 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Sun Mar 30 10:56:59 2008 Subject: Character escape codes in Parsec In-Reply-To: <4683d9370803291402i2fdbbb81k1ed2f2c0e7cee9de@mail.gmail.com> References: <4683d9370803291402i2fdbbb81k1ed2f2c0e7cee9de@mail.gmail.com> Message-ID: On Sat, 29 Mar 2008, Tim Chevalier wrote: > I can't exactly tell from looking at the source, but is the default > token parser in Parsec supposed to be parsing ASCII strings? If so, > isn't this a bug in Parsec? If not, and it's meant to be able to > handle Unicode or something, I think the documentation should be > clearer. > My guess is it's not particularly "supposed" to be doing much, but it munches Char and so Unicode input is a distinct possibility. I'd also guess that after the \ it just reuses the existing hex literal function which definitely does need to handle arbitrary length . My approach is simple: when in doubt, write your own lexing functions - at least that way any nasty surprises are your own fault! -- flippa@flippac.org Performance anxiety leads to premature optimisation From valery.vv at gmail.com Sun Mar 30 13:31:37 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Sun Mar 30 13:27:44 2008 Subject: [hackagedb] plugins-1.1 FTBFS In-Reply-To: <20080328222737.GN32404@scytale.galois.com> References: <20080328222737.GN32404@scytale.galois.com> Message-ID: On 3/29/08, Don Stewart wrote: > Sigh, David G. did a snapshot and upload it seems, of a broken package. > > A correct 1.1 tarball could be constructed and uploaded in its place. Would you mind doing this? I don't have a Hackage username. -- Regards, vvv From catamorphism at gmail.com Sun Mar 30 15:04:08 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Sun Mar 30 15:00:20 2008 Subject: Character escape codes in Parsec In-Reply-To: References: <4683d9370803291402i2fdbbb81k1ed2f2c0e7cee9de@mail.gmail.com> Message-ID: <4683d9370803301204i2409c8fbq605c7d6ccd5d317b@mail.gmail.com> On 3/30/08, Philippa Cowderoy wrote: > My guess is it's not particularly "supposed" to be doing much, but it > munches Char and so Unicode input is a distinct possibility. I'd also > guess that after the \ it just reuses the existing hex literal function > which definitely does need to handle arbitrary length . > Well, yes, but I'd like to know what the spec is. If there is one, anyway! > My approach is simple: when in doubt, write your own lexing functions - at > least that way any nasty surprises are your own fault! > I'll do so if it comes to that, but if it's truly a bug, I'd prefer it to be fixed so that everyone can enjoy the results (even if it's me who ends up fixing it :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Accordingly, computer scientists commonly choose models which have bottoms, but prefer them topless." -- Davey & Priestley, _Introduction to Lattices and Order_ From flippa at flippac.org Sun Mar 30 15:24:47 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Sun Mar 30 15:20:10 2008 Subject: Character escape codes in Parsec In-Reply-To: <4683d9370803301204i2409c8fbq605c7d6ccd5d317b@mail.gmail.com> References: <4683d9370803291402i2fdbbb81k1ed2f2c0e7cee9de@mail.gmail.com> <4683d9370803301204i2409c8fbq605c7d6ccd5d317b@mail.gmail.com> Message-ID: On Sun, 30 Mar 2008, Tim Chevalier wrote: > On 3/30/08, Philippa Cowderoy wrote: > > My guess is it's not particularly "supposed" to be doing much, but it > > munches Char and so Unicode input is a distinct possibility. I'd also > > guess that after the \ it just reuses the existing hex literal function > > which definitely does need to handle arbitrary length . > > > > Well, yes, but I'd like to know what the spec is. If there is one, anyway! > Having just poked at the manual (http://legacy.cs.uu.nl/daan/download/parsec/parsec.html if you've not found it already), the spec for anything not specifiable in a LanguageDef is "per the Haskell lexing rules". It implements that correctly. -- flippa@flippac.org The task of the academic is not to scale great intellectual mountains, but to flatten them. From alistair at abayley.org Mon Mar 31 00:47:40 2008 From: alistair at abayley.org (Alistair Bayley) Date: Mon Mar 31 00:43:47 2008 Subject: Takusen. PostrgeSQL inserts - are they possible ? In-Reply-To: <47EEE48C.8070802@mail.ru> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> <20080305173206.GA27155@soi.city.ac.uk> <20080305182625.GA16716@scytale.galois.com> <79d7c4980803051445x3d6a75dag2683977ffde5485f@mail.gmail.com> <20080305230856.GC2942@scytale.galois.com> <1204761459.11558.286.camel@localhost> <79d7c4980803060027n5b15864i132729a62b2f0d96@mail.gmail.com> <1204802057.11558.330.camel@localhost> <79d7c4980803060332r7eead42fs2d45d320f8741c51@mail.gmail.com> <47EEE48C.8070802@mail.ru> Message-ID: <79d7c4980803302147r36d65ef6kddc85a02051cc0cf@mail.gmail.com> > execCommand db "INSERT INTO dmlTest.t (realVal, dblVal) VALUES (?,?)" > [newBindVal (10.1::Float), newBindVal (1023.6::Double)] > > or something like: > > dmlStatement = "INSERT INTO dmlTest.t (realVal, dblVal) VALUES (?,?)" > bindTypes = [bindType (undefined::Float), bindType (undefined::Double)] > bindParams = [bindP (10.1::Float), bindP (1023::Double)] > in > withPreparedStatement (prepareCommand "test" (sql dmlStatement) > bindTypes) $ \pstmt -> > withBoundStatement pstmt bindParams $ \bstmt -> execDML bstmt > > lead to the "Segmentation fault/access violation in generated code" crash. You are right; there are gaps in the docs for the DML operations. However, there is a note in the first section ("Usage"): - for a DML command with bind variables: cmdbind "insert into ..." [bindP ..., bindP ...] e.g. cmdbind "INSERT INTO dmlTest.t (realVal, dblVal) VALUES (?,?)" [ bindP (10.1::Float), bindP (1023::Double)] Let me know if this works for you or not. If you want to use the withPreparedStatement+withBoundStatement combo, then you need to be aware that the bound statement has already been executed when it is passed to the action that is the last argument of withBoundStatement (this seems to be a significant omission from the docs). So, you don't need to do execDML bstmt; a return () should suffice. Alistair