July 2005 - Libraries

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

Re: [Haskell-cafe] cabal --user question
by Isaac Jones 11 Jul '05

11 Jul '05

There's no way to do this yet. The plan is to allow sections in a single package to depend on each-other as in WASH, and for cabal to handle the "local" package.conf business. This feature has the highest priority, and shouldn't be too hard, but is not yet implemented. peace, isaac

2 2

Re: RFC: Time Library 0.1
by pkeeken＠students.cs.uu.nl 11 Jul '05

11 Jul '05

i looked at the Time library, it looks really good and more complete than the current ghc one and i am thinking of using it for a project. But i only seem to miss a function for getting a week number from a calendar date like: ctWeek :: CalendarTime -> Int or is there another way for doing it, i still dont completely get this thing with ISOweek. Peter ps: having more documentation (with clear examples) would be great, which should be the case with all (ghc) documentation! :) > Sorry for the hiatus, my job has left less free time to work on this. > > Please take a look at a first attempt at writing a replacement for the standard time library. > http://semantic.org/TimeLib/ > > Take a look at the Haddock documentation: > http://semantic.org/TimeLib/doc/html/ > > Download the source: > http://semantic.org/TimeLib/TimeLib-0.1.tar.gz > > Or keep up-to-date: > darcs get http://semantic.org/TimeLib/TimeLib/ > > It needs GHC 6.4. Just run "make" to build the library, tests and documentation. There's also a cabal file (as a completely separate build process), but I've been having trouble with that on Mac OS X. > > I'm particularly interested in comments from people who try to write little applications for it. What did you have trouble with? What made no sense? > > Some points: > > 1. There is no leap second table provided, though there is a type (LeapSecondTable) for such things. Any software compiled with a fixed table would soon become out of date. > > 2. There is no table of time-zones provided, since these also change. However, if there's a good way of getting this from the TZ database on the machine, I'll add that. > > It is actually possible to get the local time-zone for any given time, indeed one of the test programs finds your local summertime transitions. The Timezone type includes name, minutes of offset, and a "summertime" flag. > > 3. I allow multiple calendars with the DayEncoding class. GregorianDay is the most obvious instance, but there are some other useful ones such as ISOWeek. And anyone interested in local cultural calendars can plug their own in here. > > 4. The TimeLocale type comes from the already existing System.Locale. > > 5. I've tried to balance simplicity and functionality. Of course, the majority of people will only be interested in ordinary Gregorian date and time, so I have a simple CalendarTime type synonym with associated functions: > http://semantic.org/TimeLib/doc/html/System.Time.Calendar.html#8 > > 6. It's not possible to expunge POSIX time. I've hidden it, but it's used behind the scenes. Why? Because it's the only way to do sensible arithmetic on UTC times without knowing the leap second table and without worrying about one-second offsets. > > 7. I include Data.Fixed which provides a fixed-point arithmetic type (wrapper around Integer). It probably should be in a separate package. It allows dealing with seconds as a single thing, rather than as an integer/picoseconds pair. > > 8. I don't have any text-parsing functionality. This is a fair amount of work, so it would be good to know sensible requirements. > > -- > Ashley Yakeley, Seattle WA > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

1 0

Can Cabal use GHC's preprocessor?
by Brian Smith 11 Jul '05

11 Jul '05

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? Thanks, Brian

2 1

Cabal and Tool Dependencies
by Brian Smith 11 Jul '05

11 Jul '05

1. How can I tell what tool dependencies a package has? For example, how can I tell from a .cabal package that Happy 1.14 or later, or Alex 2.0 is required for the package to build properly? I am making a simple tool that uses .cabal files to build programs and I would like to be able to say "This package requires Happy 1.14 to be installed" upon loading the .cabal file (before the user runs "./Setup.hs build"). 2. Is it possible to register binary (executable) packages? For example, I would like to "register" Happy 1.15 with Cabal, somehow, so that Cabal knows what version of Happy I have installed. This would eliminate the need for me to use --with-happy, etc. when configuring. Thanks, Brian

2 1