July 2005 - Libraries

RE: Extending the dependency syntax
by Simon Marlow 30 Jul '05

30 Jul '05

On 28 July 2005 22:48, Duncan Coutts wrote: > My own personal opinion is that cabal/haskell packaging can be made > the most sucessful if we take advantage of the native packaging > systems and so make it possible to automate as much as possible the > process of wrapping a cabal package into a native package. I think we > will reach the greatest audience by this approach. I'd just like to add a big +1 to this comment - that was always my feeling when we were originally thinking about Cabal, but you're right that making the link between Cabal and native package tools hasn't received enough attention yet. Cheers, Simon

2 1

Time Library Date Normalisation and Arithmetic
by Ashley Yakeley 29 Jul '05

29 Jul '05

I'm thinking of something along these lines: Normalisation ------------- class (Eq a,Ord a) => Normalisable a where isNormal :: a -> Bool normaliseTruncate :: a -> a normaliseRollover :: a -> a The normalise functions would work like this: normaliseTruncate 2005/14/32 -> 2005/12/32 -> 2005/12/31 2005/-2/-4 -> 2005/01/-4 -> 2005/01/01 normaliseRollover 2005/14/32 -> 2006/02/32 -> 2006/03/04 2005/-2/-4 -> 2004/10/-4 -> 2004/09/26 (doing both steps in each call) Calendar Arithmetic ------------------- This is one way of providing arithmetic for such things as Gregorian dates: data TimeUnit d = TimeUnit addTimeUnitTruncate :: Integer -> d -> d addTimeUnitRollover :: Integer -> d -> d diffTimeUnitFloor :: d -> d -> Integer days :: (DayEncoding d) => TimeUnit d gregorianMonths :: (DayEncoding d) => TimeUnit d gregorianYears :: (DayEncoding d) => TimeUnit d So for instance, to add three months to a date d, you do this: d' = addTimeUnitTruncate gregorianMonths 3 d This might also be used for minutes and so forth. And you might also be able to do this: multipleTimeUnit :: Integer -> TimeUnit d -> TimeUnit d weeks = multipleTimeUnit 7 days There's an alternative way using classes, for days only: class (Integral u) => TimeUnit u where addTimeUnitTruncate :: (DayEncoding d) => u -> d -> d addTimeUnitRollover :: (DayEncoding d) => u -> d -> d diffTimeUnitFloor :: (DayEncoding d) => d -> d -> u newtype Days = Days Integer instance TimeUnit Days newtype GregorianMonths = GregorianMonths Integer instance TimeUnit GregorianMonths newtype GregorianYears = GregorianYears Integer instance TimeUnit GregorianYears d' = addTimeUnitTruncate (GregorianMonths 3) d My preference is for the former. -- Ashley Yakeley, Seattle WA

4 5

RE: Extending the dependency syntax
by Simon Marlow 29 Jul '05

29 Jul '05

On 28 July 2005 22:36, Duncan Coutts wrote: > While the sensible normal behaviour might be to just pick up as many > dependencies as the environment supports, packaging systems like to > know about all dependencies and control them. For example it is > normal to build a package on one system and deploy it on another. If > there are extra dependencies that are picked up (because they happen > to be in the build environment) it may cause a failure on the target > system because the dependency is not present. A very good point. > As an example consider Gtk2Hs which has a number of optional > dependencies (libglade, GConf, Mozilla). If you do a normal build then > it will automatically build all the optional bits for which the > dependencies are satisfied. This is what casual users want. > > However for packagers we provide a --enable-packager-mode flag which > turns off all automatic dependency decisions and so the packager must > explicitly specify --enable-gconf --enable-libglade etc. Thank you, you've provided an excellent example to demonstrate the flexibility of the scheme I proposed :-) I need one more operator, which I'll write ':', and which means the same as a Prolog cut(!). Don't worry if you're not familiar with Prolog, all will become clear. So here's how you express the Gtk dependencies: build-depends: ("packager-mode": ("enable-gconf": gconf>=1.0 [gconf] ||) ("enable-libglade": libglade>=1.0 [libglade] ||) ) || ( (gconf>=1.0 [gconf] ||) (libglade>=1.0 [libglade] ||) ) In words, this says - if "packager-mode" is defined, then - if "enable-gconf" is defined then require gconf>=1.0 and process the [gconf] stanza - if "enable-libglade" is defined then require libglade>=1.0 and process the [libglade] stanza - otherwise, - if gconf>=1.0 is available, process the [gconf] stanza - if libglade>=1.0 is available, process the [libglade] stanza I have to admit, I think this is beautiful. But I'm prepared to believe that others might prefer to go for something a bit more concrete. I imagine that the packager-mode concept is something that we'd want every package to conform to, so we don't want to require every packager to write the appropriate build-depends magic. OTOH, I still like the simplicity of the design. We could add built-in packager-mode support like this: (a) --packager-mode causes all dependencies inside a disjunction to fail by default, and (b) --enable-foo forces an optional dependency on foo to be required. So then the packager just writes build-depends: (gconf>=1.0 [gconf] ||) (libglade>=1.0 [libglade] ||) But this is starting to get a bit subtle. Cheers, Simon

2 1

RE: Extending the dependency syntax
by Simon Marlow 29 Jul '05

29 Jul '05

On 28 July 2005 23:33, Ian Lynagh wrote: > For libraries we(Debian)'d need to be guaranteed that the left-most of > the satisfactory options had been chosen. Absolutely - that was part of the (intended) specification. Cheers, Simon

1 0

Extending the dependency syntax
by Simon Marlow 29 Jul '05

29 Jul '05

So here's a strawman proposal to address some of the use cases raised recently[1] that Cabal doesn't currently support well. This is just a first attempt; I expect we'll need to make changes or start over if we discover cases that it doesn't handle. [1] http://www.haskell.org//pipermail/libraries/2005-July/004152.html http://www.haskell.org//pipermail/libraries/2005-July/004133.html Firstly, we define certain pseudo-packages on which dependencies can be expressed. The pseudo packages would consist of the compilers and pre-processors that Cabal understands, and any other tools required by the build process. eg. build-depends: ghc>=6.4 happy>=1.5 base>=1.0 Now, I suggest we expand the language of dependencies to include disjunction and optional stanzas. The syntax I have in mind is this: deps ::= adep* dep-expr ::= deps '||' dep-expr adep ::= pkg version-range | '(' dep-expr ')' | '[' stanza ']' The idea is that Cabal evaluates the dependencies trying disjunctions left-to-right, where optional stanzas [foo] are assumed to be satisfied. When a set of satisfying dependencies has been found, Cabal processes all the optional stanzas it contains. We now need to be able to accumulate values from fields specified multiple times, rather than require each field to be specified at most once. Note that a list of dependencies can be empty, so an optional dependency is specified as (|| dep). Here's an example where a library can be built by multiple compilers, where each compiler requires different modules to be compiled: ---------------- name: mylib version: 1.0 exposed-modules: My.Lib build-depends: base>=1.0 (ghc>=6.4 || ghc>=6.2 [ghc62] || hugs-any [hugs]) [ghc62] other-modules: Compat.Ghc62 [hugs] other-modules: Compat.Hugs ----------------- This covers Duncan's requirements, and Brian Smith's 1(a),1(b),1(d),2(a). 1(c) is not covered yet: > (c) Cabal depends on HUnit if DEBUG is set, but it doesn't depend on > HUnit if DEBUG is not set. (The dependency isn't controlled by the > existence of a package, but by a configuration option.) This is related to the concept of "configurations", which we need in Visual Studio too. The idea is that a package can be built in one of several different ways, where each way specifies different compiler options or other settings. A common use is to have "debug" and "release" configurations, where in the former we #define DEBUG, and in the latter we turn on -O. How might we include configurations in Cabal? A configuration selection behaves rather like a dependency that is satisfied by the environment - perhaps as a command line option to Setup.lhs. We could extend the dependency syntax to include a new kind of dependency: adep ::= ... | config Perhaps the concrete syntax for config is a string (eg. "DEBUG"). We can express the HUnit example now: ---------------- build-depends: base>=1.0 ("DEBUG" HUnit>=1.0 [debug] || [release]) [debug] other-modules: Tests ghc-options: -DDEBUG -Onot [release] ghc-options: -O ---------------- Comments? Cheers, Simon

5 6

Error manipulation functions
by Ian Lynagh 29 Jul '05

29 Jul '05

Hi all, I couldn't see a way to write any of these functions without using GHC.IOBase. Did I miss one? If not, can they (or something that would allow them to be written) please be added to System.IO.Error? import GHC.IOBase ( IOException(ioe_location), IOErrorType(UnsupportedOperation, HardwareFault) ) add_to_error_loc :: Exception -> String -> Exception add_to_error_loc (IOException ioe) s = IOException $ ioe { ioe_location = s ++ ": " ++ ioe_location ioe } add_to_error_loc e _ = e isUnsupportedOperationError :: IOError -> Bool isUnsupportedOperationError = isUnsupportedOperationErrorType . ioeGetErrorType isUnsupportedOperationErrorType :: IOErrorType -> Bool isUnsupportedOperationErrorType UnsupportedOperation = True isUnsupportedOperationErrorType _ = False Thanks Ian

1 0

RE: external core
by Simon Peyton-Jones 27 Jul '05

27 Jul '05

Good idea Josef Svenningsson at Chalmers is in charge of External Core these days. Let's see what he says. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of John | Meacham | Sent: 27 July 2005 03:23 | To: libraries(a)haskell.org | Subject: external core | | Now, the external core feature of ghc is great, but it is not utilized | very much. The main reason I think is that there is a large barrier to | entry in writing something that uses it since you need to parse/generate | it. | | It would be nice if there were a standard library that came with ghc (or | cabalized and portable even better) that could parse and pretty print | external core. | | ideally, one could write a simple pass-through core processor that | interacts with ghc in a single line and someone working on a new | optimization need only worry about that. | | Also, it would make it very easy for jhc to generate and parse ghc core | files (always an ulterior motive). I wanted to use jhcs front end to | generate ghc core so I could get a true measure of the difference in | just their back-end performance without taking into account ghc's | superior high-level optimizations. | | In any case. I think all the code is out there in ghc and it just needs | to be separated and cabalized. I know there was talk of creating a ghc | internals library, but it would be nice if this code were portable and | independent. | | John | | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: Cabal: Conditional code and dependencies
by Simon Marlow 26 Jul '05

26 Jul '05

On 25 July 2005 14:52, John Goerzen wrote: > On 2005-07-21, Brian Smith <brianlsmith(a)gmail.com> wrote: >> (b) A program requires some unix-specific code (package unix) or >> windows-specific code (package win32) depending on what operating >> system the program is built for. > > I just ran into this problem with making MissingH work on Windows. I > finally wound up providing a batch file for Windows users that hacks > the .cabal file, which then can be used to build the package on > Windows. Ugly, but works. We should try to avoid these sort of things, the reason being that external tools need to slurp .cabal files, so having them be dynamic creates problems. The main problem I see is Visual Studio, which in a sense is a GUI for editing .cabal files. If the .cabal file needs preprocessing, it means that someone using VS won't be able to load up your library in VS. Not saying you should have done this differently if there's no alternative, but I just wanted to point this out as an issue. Cheers, Simon

1 0

Cabal: Conditional code and dependencies
by Brian Smith 25 Jul '05

25 Jul '05

It would be useful to have mechanisms in Cabal like these: (1) Optional dependencies: "if package foo-1.0 is available, then my program depends on it; otherwise, my program does not depend on it." (see also #3 below). Special case: "my program would prefer package foo-1.2, but if that is not available, I will take any version of foo." Use cases: (a) A tool has an optional "XML export" feature that requires HaXml. If HaXml is available, then the XML export feature will be built. Otherwise, the tool will be built without it. (b) A program requires some unix-specific code (package unix) or windows-specific code (package win32) depending on what operating system the program is built for. (c) Cabal depends on HUnit if DEBUG is set, but it doesn't depend on HUnit if DEBUG is not set. (The dependency isn't controlled by the existence of a package, but by a configuration option.) (c) Let's say I send in a patch that adds a "getAppBinaryDirectory" function to System.Directory, and this patch makes it into version 1.1 of the base package. Then, Cabal 1.3 can say "If the base package version is 1.1, then we want it because it defines getAppBinaryDirectory, otherwise, we will just use base-1.0 and will provide our own implementation of that function." (2) "process this stanza if package foo-1.1 is available," etc. Use cases: (a) A tool comes in a command line version and a GUI version. The command-line version can be used independently of the existence of the GUI version. The GUI version requires wxHaskell. So, we want to say "build the GUI executable if wxHaskell is available, otherwise skip it." (b) A tool has a test suite that requires HUnit. If HUnit isn't available, then the test suite should not be built. (3) It would be useful if Cabal/GHC/Hugs/etc. #defined symbols for installed packages. This would allow us to write: module My.Program.Compat.Lib(foo1, foo2,foo3) #if __PACKAGE_foo__ >= 110 -- Is package foo-1.1 or later available? import Foo(foo1,foo2,foo3) #else foo1 = .... foo2 = .... foo3 = ... #endif Consider the following fragment from Cabal's Distribution.Compat.Directory. The Cabal authors know that the version of System.Directory that is in GHC before 6.02 includes the features Cabal needs. However, other Haskell implementations have no such version test: #if !__GLASGOW_HASKELL__ || __GLASGOW_HASKELL__ > 602 import System.Directory #else /* to end of file... */ ... #endif Instead, we could have: #if __PACKAGE_base__ >= 100 import System.Directory #else /* to end of file... */ getAppUserDataDirectory = .... #endif #if __PACKAGE_base__ < 110 getAppBinaryDirectory = ... #endif Regards, Brian

3 2

[Haskell-cafe] Arbitrary files in a Cabal package: how to install
by Dimitry Golubovsky 25 Jul '05

25 Jul '05

Ross Paterson wrote: I think there should be a new field (data-files?) listing files to be installed where the program can find them: - for GHC under Unix, in {prefix}/share/{exeName}/ - for GHC under Windows, in the same directory as the executable ({Program Files}/{packageID}) - For Hugs, in the same directory as the Main module ({Hugs}/programs/{exeName}) =================== Is there a way for a program/library included in the package to know its installation prefix (and other details) from the .cabal file at compile time (so the necessary path would be hardcoded during compilation) - maybe a CPP macro to be set when preprocessing the sources? I thought about a bit different approach. For each data file to be installed, define a separate stanza (just like for each executable), like this: extra-files: list -- (i. e. one or more files covered by this stanza) preprocess: command line -- (e. g. cp -p) destination: path -- (relative to the package installation root) "preprocess" command will be called on each file separately. It is assumed to - be aware of the OS environment it runs on, if applicable - read the file pointed to by its first parameter and write the file where the second parameter points to, after preprocessing. The minimal preprocessor is cp. If command line options are needed, they are part of the preprocess' value e. g. preprocess: gcc -E In some cases preprocessor may be a shell script placed somewhere within the package source tree. Relative path to the script is necessary then to specify. -- Dimitry Golubovsky Anywhere on the Web

1 0