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 **200