- Libraries - Haskell.org

Compatibility libraries
by Einar Karttunen 17 Jul '05

17 Jul '05

Hello In many invidual projects one is faced with challenges from the changing standard library. Currently it seems that each project uses a separate solution - maybe a common approach would be possible. I would be most interested in packaging a library which would implement GHC 6.4 base package for older releases (mainly GHC 6.2.x). GHC seems to have its own solution in fptools/ghc/lib/compat/ but having a cabal package and supporting e.g. Data.Map/Set could make things easier. Does this sound like a good idea or is there a much better solution? - Einar Karttunen

2 1

Cabal: some suggestions
by Manuel M T Chakravarty 15 Jul '05

15 Jul '05

I just replaced C->Haskell's (quite elaborate) make-based build system by a Cabal-based system. Overall, this worked quite well (but partially because I simplified some of c2hs's old structure anyway). So, here some feedback. * Having the ability to specify multiple source directories is quite important (at least for non-library packages). So, please include Cabal 1.0.1 or higher with GHC soon. * Installation is still too inflexible. In particular, the pre/post hooks (and I guess not only the installation ones) need to get the PackageDescription as an argument. Due to the lack of the PackageDescription, I had to add a ./configure mangled shell script that I invoke from the postInst hook. See http://www.cse.unsw.edu.au/~chak/repos/c2hs/Setup.hs <see appended code for postInst.sh.in - our web server won't serve it via http due to the filename> Essentially, I need to create wrapper scripts (like ghc) to pass an install-location dependent path to the main executable. (Actually, two scripts one for running the c2hs inplace in the build tree and one for after proper installation.) Wrapper scripts are really common, so ideally there should be special support for those. * There doesn't seem to be anything to handle documentation. * Maybe not really a Cabal problem, but --make with GHC on larger programs is quite tedious. When you change, say, Main.hs ghc walks through all the other modules telling you its skipping them, which takes quite a long time, only to spot a type in the change that you just makes...and then you can start looking at all the skipping messages again. It's not the skipping messages that bother me. It's how long ghc takes to figure out that it actually only needs to compile one file. This is actually the problem which bother me most at the moment. Anyway, its great to have Cabal. Manuel -=- postInst.sh.in -=- #!/bin/sh prefix=/home/chak/sandbox exec_prefix=${prefix} bindir=${exec_prefix}/bin libdir=${exec_prefix}/lib/c2hs-0.14.0 echo "Moving executable into $libdir/" /bin/sh install-sh -d $libdir /bin/sh install-sh -s -m 755 $bindir/c2hs $libdir/ echo "Installing wrapper and C2HS.hs" /bin/sh install-sh -c -m 755 c2hs/c2hs $bindir/ /bin/sh install-sh -c -m 644 c2hs/lib/C2HS.hs $libdir/

1 0

RE: Cabal Release Candidate
by Simon Marlow 15 Jul '05

15 Jul '05

On 15 July 2005 08:16, Isaac Jones wrote: > We basically have three dimensions of a single package to consider: > - hidden vs. exposed > - user vs. global vs. -package-conf > - versions > > I propose that -package-conf packages have priority over user packages > which have priority over global packages (are all three considered at > the same time?) > > What do we do if multiple "dimensions" of the same package are > exposed? Right now, ghc just quits, right? I propose: > > Pick the Exposed -package-conf package with greatest version number > > if none, the exposed user package with greatest version number > > if none, the exposed system package with the greatest version > number. Hmm, I had in mind something simpler, but slightly different: (a) Pick the exposed package with the greatest version number, from all the packages that we know about (-package-conf, user, global). (b) If multiple packages have the same name *and* version, we take the first one in the order -package-conf, user, global. This differs from your version when you want to install an *older* version in your user database. eg. /usr/lib/ghc/package.conf: foo-2.0 /home/simonmar/.ghc/package.conf: foo-1.0 I'll always get foo-2.0 by default, but you would get foo-1.0. In both cases you can force foo-1.0 with '-package foo-1.0'. In both cases you can force the opposite behaviour by copying foo-2.0 into the user package database and exposing/hiding it respectively. IMO, my version is a bit easier to understand. eg. in my version, both of these commands result in the same outcome when foo-2.0 is installed globally: $ ghc-pkg register foo-1.0 --user $ ghc-pkg register foo-1.0 --global but in your version they differ. [ stares out the window for a bit... ] You might well ask what the point of exposed vs. hidden is, in the light of these changes. Can't we just pretend all packages are exposed all the time? Here are some reasons why not: - -hide-all-packages is useful for forcing complete explicitness about dependencies. Code that wants to be portable should always be using this. - hiding is useful for overriding the defaults, for example if you want to install a newer version of a package but not make it the default, or if you need to avoid conflicts in the set of packages that GHC would otherwise enable by default. But it's true that in the light of these changes, setting the exposed flag to False in the package database will be a rare occurrence. Cheers, Simon

1 0

RE: Cabal Release Candidate
by Simon Marlow 15 Jul '05

15 Jul '05

On 14 July 2005 17:47, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I just discovered a problem. In GHC > 6.4, local modules take >> precedence over package modules. This causes a problem for the >> Cabal distribution, eg: >> >> $ ghc-6.4.1 Setup.lhs --make -o setup >> Chasing modules from: Setup.lhs >> ./Distribution/Simple.hs:61:1: lexical error >> >> ie. it picks up Distribution.Simple from the local copy rather than >> the installed version. The solution is simple, if a little >> inconvenient: the Cabal sources have to move into a subdirectory of >> the distribution. > > It's supposed to do this; use "make setup" (which just passes -cpp to > ghc) to create the setup file. It bootstraps itself, but I could move > the sources into a subdirectory anyway to make it possible to build it > either way. Yes, but the problem is that I can't do 'runghc Setup.lhs', because it fails as above. It works with GHC 6.4, though. Even if we fixed the compilation failures (perhaps with appropriate {-# OPTIONS #-} pragmas), 'runghc Setup.lhs' would still compile the whole of Cabal each time, which is sub-optimal. Putting the sources in a subdirectory would fix this infelicity, and you can still bootstrap using the Makefile. Cheers, Simon

1 0

RE: Cabal Release Candidate
by Simon Marlow 15 Jul '05

15 Jul '05

On 15 July 2005 08:16, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >> However, upgrading Cabal might still cause problems for GHC, because >> our build system relies on knowing what version of GHC you're >> building with to know what version of Cabal you're using. This is >> not really Cabal's problem. > > Hmm. I guess this can't be determined at GHC's build time. What is > this info used for? I just mean that GHC's build system is going to have to cope with different versions of the Cabal package, independently of the GHC version installed. In the future, this will be the case for all packages that GHC depends on, too. Cheers, Simon

1 0

RE: Cabal Release Candidate
by Simon Marlow 15 Jul '05

15 Jul '05

On 14 July 2005 14:45, Simon Marlow wrote: > When I installed the new Cabal globally (onto GHC 6.4), the old one > was hidden automatically, so the suggestion for unregistering the old > one in the README is unecessary. I take it back. If you don't unregister the old one, then "-package Cabal" results in an error from GHC ("Cabal matches multiple packages"), and building GHC fails. In hindsight this was a bad choice, I'm going to change it so that -package P picks the latest version of P if a particular version isn't specified. However, upgrading Cabal might still cause problems for GHC, because our build system relies on knowing what version of GHC you're building with to know what version of Cabal you're using. This is not really Cabal's problem. > So to summarise: > > - to install globally / with root access: should "just work" > > - to install just for me: copy+hide Cabal-1.0, then install the > new one with --user. > > I should really do something about this for 6.4.1. Everything seems a > bit adhoc, though. Perhaps: in the absence of any package flags to > the contrary, GHC could default to hiding all but the newest version > of packages which have more than one version exposed? I've made the following changes for 6.4.1: - -package P picks the latest version of P, instead of complaining if P is ambiguous. - -hide-package P hides all versions of P, instead of complaining if P is ambiguous. - -package P hides all other versions of P (this was advertised in the documentation, but wasn't actually implemented in 6.4) - if multiple packages with the same name are still exposed after the flags have been processed, then all except the latest version are hidden. This is aimed at reducing the error cases and making it DTRT for most people. Comments? Cheers, Simon

2 1

RE: Cabal Release Candidate
by Simon Marlow 14 Jul '05

14 Jul '05

I just discovered a problem. In GHC > 6.4, local modules take precedence over package modules. This causes a problem for the Cabal distribution, eg: $ ghc-6.4.1 Setup.lhs --make -o setup Chasing modules from: Setup.lhs ./Distribution/Simple.hs:61:1: lexical error ie. it picks up Distribution.Simple from the local copy rather than the installed version. The solution is simple, if a little inconvenient: the Cabal sources have to move into a subdirectory of the distribution. $ mkdir src $ mv Distribution Language src/ and add "hs-source-dir: src" to Cabal.cabal. I can't see another way around it; the new GHC behaviour is definitely better than before (it was requested by several people). This problem only affects Cabal. Cheers, Simon On 14 July 2005 14:45, Simon Marlow wrote: > Seems to install and work on the simple test I tried. > > A typo in the README: > > $ ghc-pkg describe Cabal-1.0 | ghc-pkg --user regiser - > > s/regiser/register/ > > I think we should separate the instructions for installing a new Cabal > into "root access" and "no root access" (and say something > Windows-compatible too, like "Administrator access"). > > When I installed the new Cabal globally (onto GHC 6.4), the old one > was hidden automatically, so the suggestion for unregistering the old > one in the README is unecessary. However, when installing the new > one with --user, you definitely *do* need to do this: > > $ ghc-pkg describe Cabal-1.0 | ghc-pkg --user register - > $ ghc-pkg --user hide Cabal-1.0 > > but you should do it *before* installing Cabal-1.1.1 (otherwise a > different sequence is required... sigh). > > So to summarise: > > - to install globally / with root access: should "just work" > > - to install just for me: copy+hide Cabal-1.0, then install the > new one with --user. > > I should really do something about this for 6.4.1. Everything seems a > bit adhoc, though. Perhaps: in the absence of any package flags to > the contrary, GHC could default to hiding all but the newest version > of packages which have more than one version exposed? > > Cheers, > Simon > > On 14 July 2005 07:52, Isaac Jones wrote: > >> I've updated the web page to have 1.0 (as Malcolm requested), and >> added 1.1.1, which is a "release candidate" for 1.2. Please forgive >> me for going insane with the version numbers. >> >> I'd appreciate it if early adopter types try out 1.1.1. In >> particular, check out the README wrt installing alongside-of or >> instead-of 1.0 with ghc 6.4. >> >> BTW, if anyone loves to manage releases and would like to relieve me >> of this duty so I can spend my time fixing bugs and adding features, >> just let me know ;) >> >> peace, >> >> isaac >> >> >> --------------------------------------------------------------- >> The Haskell Cabal >> The Common Architecture for Building Applications and Libraries. >> http://www.haskell.org/cabal >> >> IMPORTANT INFORMATION: >> >> See both the README file and the changelog for important interface >> changes and installation instructions. >> >> DOWNLOAD: >> >> The Haskell Cabal has reached version 1.1.1. This pre-release has a >> number of new features including a hook for testing, support for >> profiling, and support for _stub files, as well as several bug fixes. >> >> Download the Cabal here (source and debian versions available): >> http://www.haskell.org/cabal/download.html >> >> BUGS: >> >> Please report bugs and wish-list items to libraries(a)haskell.org and >> Isaac Jones: ijones(a)syntaxpolice.org. >> >> ABOUT: >> >> The Haskell Cabal is meant to be a part of a larger infrastructure >> for distributing, organizing, and cataloging Haskell Libraries and >> Tools. It is an effort to provide a framework for developers to more >> effectively contribute their software to the Haskell community. >> >> Specifically, the Cabal describes what a Haskell package is, how >> these packages interact with the language, and what Haskell >> implementations must to do to support packages. The Cabal also >> specifies some infrastructure (code) that makes it easy for tool >> authors to build and distribute conforming packages. >> >> The Cabal is only one contribution to the larger goal. In particular, >> the Cabal says nothing about more global issues such as how authors >> decide where in the module name space their library should live; how >> users can find a package they want; how orphan packages find new >> owners; and so on. >> >> NOTES: >> >> You cannot currently execute most setup scripts with "./Setup.lhs" >> since most systems do not have a runHaskell executable installed. >> You can compile it with ghc thusly: "ghc -package Cabal Setup.lhs -o >> setup" and then use the "setup" executable after that. >> >> This release is meant to provide the community with concrete >> information about how the interfaces are shaping up. This release >> does NOT fix the interfaces, we can't promise not to break anything >> that relies on these interfaces. We hope that Haskell authors will >> try to package their software using these tools, and let us know >> where they fall short. >> >> MORE INFORMATION: >> >> Please see the web site for the source code, interfaces, and >> especially the proposal, which will serve as documentation for this >> release: >> >> http://www.haskell.org/cabal/ >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

2 1

RE: Cabal Release Candidate
by Simon Marlow 14 Jul '05

14 Jul '05

Seems to install and work on the simple test I tried. A typo in the README: $ ghc-pkg describe Cabal-1.0 | ghc-pkg --user regiser - s/regiser/register/ I think we should separate the instructions for installing a new Cabal into "root access" and "no root access" (and say something Windows-compatible too, like "Administrator access"). When I installed the new Cabal globally (onto GHC 6.4), the old one was hidden automatically, so the suggestion for unregistering the old one in the README is unecessary. However, when installing the new one with --user, you definitely *do* need to do this: $ ghc-pkg describe Cabal-1.0 | ghc-pkg --user register - $ ghc-pkg --user hide Cabal-1.0 but you should do it *before* installing Cabal-1.1.1 (otherwise a different sequence is required... sigh). So to summarise: - to install globally / with root access: should "just work" - to install just for me: copy+hide Cabal-1.0, then install the new one with --user. I should really do something about this for 6.4.1. Everything seems a bit adhoc, though. Perhaps: in the absence of any package flags to the contrary, GHC could default to hiding all but the newest version of packages which have more than one version exposed? Cheers, Simon On 14 July 2005 07:52, Isaac Jones wrote: > I've updated the web page to have 1.0 (as Malcolm requested), and > added 1.1.1, which is a "release candidate" for 1.2. Please forgive > me for going insane with the version numbers. > > I'd appreciate it if early adopter types try out 1.1.1. In > particular, check out the README wrt installing alongside-of or > instead-of 1.0 with ghc 6.4. > > BTW, if anyone loves to manage releases and would like to relieve me > of this duty so I can spend my time fixing bugs and adding features, > just let me know ;) > > peace, > > isaac > > > --------------------------------------------------------------- > The Haskell Cabal > The Common Architecture for Building Applications and Libraries. > http://www.haskell.org/cabal > > IMPORTANT INFORMATION: > > See both the README file and the changelog for important interface > changes and installation instructions. > > DOWNLOAD: > > The Haskell Cabal has reached version 1.1.1. This pre-release has a > number of new features including a hook for testing, support for > profiling, and support for _stub files, as well as several bug fixes. > > Download the Cabal here (source and debian versions available): > http://www.haskell.org/cabal/download.html > > BUGS: > > Please report bugs and wish-list items to libraries(a)haskell.org and > Isaac Jones: ijones(a)syntaxpolice.org. > > ABOUT: > > The Haskell Cabal is meant to be a part of a larger infrastructure for > distributing, organizing, and cataloging Haskell Libraries and > Tools. It is an effort to provide a framework for developers to more > effectively contribute their software to the Haskell community. > > Specifically, the Cabal describes what a Haskell package is, how these > packages interact with the language, and what Haskell implementations > must to do to support packages. The Cabal also specifies some > infrastructure (code) that makes it easy for tool authors to build and > distribute conforming packages. > > The Cabal is only one contribution to the larger goal. In particular, > the Cabal says nothing about more global issues such as how authors > decide where in the module name space their library should live; how > users can find a package they want; how orphan packages find new > owners; and so on. > > NOTES: > > You cannot currently execute most setup scripts with "./Setup.lhs" > since most systems do not have a runHaskell executable installed. You > can compile it with ghc thusly: "ghc -package Cabal Setup.lhs -o > setup" and then use the "setup" executable after that. > > This release is meant to provide the community with concrete > information about how the interfaces are shaping up. This release > does NOT fix the interfaces, we can't promise not to break anything > that relies on these interfaces. We hope that Haskell authors will > try to package their software using these tools, and let us know where > they fall short. > > MORE INFORMATION: > > Please see the web site for the source code, interfaces, and > especially the proposal, which will serve as documentation for this > release: > > http://www.haskell.org/cabal/ > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: Can Cabal use GHC's preprocessor?
by Simon Marlow 14 Jul '05

14 Jul '05

On 11 July 2005 06:37, Isaac Jones wrote: > Brian Smith <brianlsmith(a)gmail.com> writes: > >> I have some source files which need CPP style preprocessing. Since I >> am using GHC, I would like to automatically use GHC's preprocessor >> instead of having to download and install cpphs. For example, I want >> to "runghc ./Setup.hs haddock" without cpphs installed. However, >> references to cpphs are hard-coded into Cabal. What is the best way >> to go about accomplishing this? > > I believe that if you say "ghc-options: -cpp" or whatever it is, then > it should use the "built-in" one for building. Don't list CPP as an > extension in this case. This may mess up the preprocessing during the > haddock command, fwiw. > > I'd recommend against doing this, though. The "built-in" one actually > just calls cpp, which does not accept all legal Haskell code. > Sticking to hscpp will help your code to be more portable as well. > > Another option is to patch the PreProcess.hs module to check to see if > cpphs exists and if not, to use "raw" cpp, or cpp through ghc or > something. If someone does this, they should also patch the sanity > checker to add a warning. I've fixed this now (as per your last paragraph above), and done some rudimentary testing. I didn't add a warning though; perhaps we should, but since it's using the same preprocessor that will be used when compiling with GHC anyway, I'm not sure a warning will be terribly helpful. I hope this can sneak into the Cabal release, but don't worry if not. Cheers, Simon

1 0

Re: RFC: Time Library 0.1
by Scott Turner 11 Jul '05

11 Jul '05

Very nice library. Here are some comments. How do I convert a DayAndTime to a CalendarTime in the local time zone? Due to summer time, the current time zone might be incorrect. One aspect which adds difficulty to the library is that common concepts are supported using obscure types. For example, adding a number of days has an expression like encodeDay (decodeDay day +1) which uses ModJulianDay, a representation most are unfamiliar with. Similarly, absolute differences between times are provided by AbsoluteTime which is TAI. The way to calculate absolute time differences based on UTCTime is via an excursion to TAITime. Modified Julian day and TAI give the library a solid foundation. However, many users wouldn't expect that adding a number of days to a Gregorian date would entail encoding and decoding, and as a result would have difficulty finding/understanding how it's done. Which is the code, 2005-07-11 or 53562? I try to answer that question whenever I use encodeDay or decodeDay. The time library's answer is counterintuitive. The names toModJulianDay and fromModJulianDay would be easier to deal with. Similarly for the other uses of encode/decode. Simon Marlow wrote: > The question is, what's the result of encodeUTC for an invalid > CalendarTime. It's decodeUTC which takes a calendar time. :-) More friendly than the DayEncoding class would be a DayDiff class that provides addDays and diffDays. Similarly, I'd like to see a class that provides addTime and diffTime (however the attendant leap second issue is resolved). UTCDiffTime, addUTCTime, and diffUTCTime intentionally ignore leap seconds. For example, diffUTCTime will return a 0 value for the duration of any event which occurs during a leap second. The "UTC" prefix poorly expresses the distinction between the two types of DiffTime, because UTC in comparison to POSIX time serves the opposite role. It's UTC which accounts for leap seconds so that correct absolute time differences can be recorded. NominalDiffTime, addNominalTime, and diffNominalTime would be better names than UTCDiffTime, etc. > ISSUE: What kind of "Gregorian arithmetic" should I add, if any? I'd like to see a way of representing Gregorian months, i.e. a partial time w/o day of year such as 2005-07. Also a class providing addMonths and diffMonths. A `dayOfMonth` function would map Gregorian months to GregorianDays. lastOfTheMonth m = dayOfMonth (addMonths 1 m) 0

1 0