September 2005 - Libraries

RE: cabal beginner issues (other-modules, build-depends)
by Simon Marlow 23 Sep '05

23 Sep '05

On 22 September 2005 23:02, Andrew Pimlott wrote: > 2. Similar comments apply to build-depends. I wrote a module Foo.hs: > > module Foo (foo) where > import Control.Monad.Identity > foo = runIdentity (return ()) > > and a cabal file (working from an example obviously): > > Name: foo > Version: 1.1 > License: BSD3 > Build-Depends: base > Exposed-modules: > Foo > > This built and installed without error, but when I created another > module that imports Foo and tried to compile it with "ghc > --make", I got undefined references to Control.Monad.Identity. > Eventually, I found that I need to add mtl to build-depends. > Again it would have been better to get an error during package > creation, and this was particulary tricky to figure out because > "build-depends" sounds like it should only affect package at > build-time. This is fixed in newer versions of Cabal when used with newer versions of GHC (6.4.1). Missing dependencies are now reported as build errors, because GHC is invoked with the -hide-all-packages option. Cheers, Simon

1 0

cabal beginner issues (other-modules, build-depends)
by Andrew Pimlott 23 Sep '05

23 Sep '05

Two issues I've encountered while trying out cabal: 1. The use of "other-modules" is a bit confusing. I realize now that other-modules must contain all modules in the source tree used by the exposed modules. However, since the package built and installed without error when I left out this field, I was surprised to get undefined references when I tried to use the package. I guess this happened because ghc --make found the other modules automatically, but cabal didn't. I would rather have the build step fail in this case. Maybe cabal shouldn't be using --make. 2. Similar comments apply to build-depends. I wrote a module Foo.hs: module Foo (foo) where import Control.Monad.Identity foo = runIdentity (return ()) and a cabal file (working from an example obviously): Name: foo Version: 1.1 License: BSD3 Build-Depends: base Exposed-modules: Foo This built and installed without error, but when I created another module that imports Foo and tried to compile it with "ghc --make", I got undefined references to Control.Monad.Identity. Eventually, I found that I need to add mtl to build-depends. Again it would have been better to get an error during package creation, and this was particulary tricky to figure out because "build-depends" sounds like it should only affect package at build-time. Another way to look at both issues is that if ghc can figure out other modules and packages itself, the user shouldn't be required to specify them in a cabal file. (I know there are other compilers than ghc.) I am using Debian ghc6 package 6.4-4.1. Andrew

2 1

Unexpected behaviour in Text.PrettyPrint.HughesPJ
by Anders Höckersten 22 Sep '05

22 Sep '05

Hi, I've been using the pretty printer in Text.PrettyPrint.HughesPJ lately, and I've encountered a behaviour that was very unexpected for me. If I define this small example: test = text "foo" <+> empty <> text "bar" Running 'show test' now gives the string "foobar" as a result (whereas I expected "foo bar").It seems the empty "eats" the space that I expect <+> to give me. So is this how the library is supposed to work or have I encountered a bug? Regards, Anders

1 0

HaXml Status
by Dominic Steinitz 20 Sep '05

20 Sep '05

Can anyone clarify this? I need to be able to handle namespaces some I'm using Graham Klyne's version http://www.ninebynine.org/Software/HaskellUtils/20040802-Haxml-1.12.zip. There is a 1.13 version on the HaXml website http://www.cs.york.ac.uk/fp/HaXml. From the words on the website, it doesn't look like 1.13 has incorporated Graham's changes. When I try and build Graham's version with GHC 6.4, I run into problems such as parseUriReference should really be parseURIReference and others (actually that's because of the Haskell HTTP package http://www.haskell.org/http/ rather than GHC). Does 1.13 support namespaces or is my best bet to go through Graham's version and update it so it builds with GHC 6.4 and the latest packages? Thanks, Dominic.

3 2

RE: cabal design
by Simon Marlow 19 Sep '05

19 Sep '05

On 16 September 2005 18:03, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> Ok, I've read through this discussion. Could somebody explain to me >> why this whole "virtualization" thing can't be solved by simply >> adding the flag >> >> --package-db=<file> >> >> to Cabal? It would be another option in the --user/--global family. >> The idea isn't new - I'm sure we've discussed this before. It seems >> to suffer from none of the problems of the other suggestions, but >> perhaps I'm missing something. For Hugs, the <file> would actually >> specify a directory. Additionally, --package-db=<file> is a step on >> the way to other things that we want to do (--in-place). > > The problem I have with --package-db= as a directory for Hugs (and > nhc, and jhc) is that it conflicts with the meaning of the --prefix > flag. That is, if you specify a package database, it changes the > location of the installation, which is not what you might expect. > Also, we'd have to make sure people don't try to use --prefix and > --package-db together in the case of Hugs (unless they're equal). Ah, I has read the section "Hugs Package Database" on the wiki and for some reason my brain had accepted it as The Truth rather than just a proposal. Nevertheless, such a setup is already possible using symbolic links, at least on Unix. I think that assuming a level of indirection between the package database and the actual installed location of the package is not a bad thing - Hugs will catch up. This isn't so bad. To be precise: --package-db works fully for GHC --package-db works fully for Hugs on Unix-like systems, using symbolic links. --package-db will not work on Windows with Hugs, currently. > Another option, since this will only really work for GHC, is to add > --ghc-options and --ghc-pkg-options and people can specifcy the > database they want, and it'll be clear that it's not a portable > option. That's ok, but not as attractive (IMO). Other systems will want to have the same facilities, and we'll end up with users of Cabal having to know the right --<foo>-options flags to pass to Cabal for their compiler. If we standardise on the idea of a package database as a filesystem path, which should be enough for everyone, then we can provide a portable interface. > So for the sake of those who haven't read the wiki page, here's my > --root= proposal. This basically directly implements "virtualization" > in Cabal: > > * For GHC > o --prefix now becomes $(ROOT)/$(PREFIX) > o the ghc-pkg file is stored in $(ROOT)/.whatever > o Cabal adds package-conf related flags to ghc and ghc-pkg to > look at $(ROOT)/.whatever. *this* is the bit I have a problem with. You haven't specified how we figure out the value of ".whatever", and it looks like it should vary depending on the value of $(ROOT), at least for GHC. Also, having both --root and --prefix is quite confusing - I don't think I fully grasp the significance of having both options, and I'm sure it'll confuse users. This just doesn't look as simple as the --package-db flag. We want the ability to specify the package db anyway, and this gives us virtualisation too. Two birds with one stone! Cheers, Simon

1 0

HaXml Status
by Dominic Steinitz 19 Sep '05

19 Sep '05

Malcolm, Thanks. I finally got Graham's version to build by: ./configure and then using the following Setup.hs and HaXml.cabal files. I haven't tried with Hugs or nhc. I had to modify a few bits of code on the way (e.g. changing parseUriReference to parseURIReference) but I assume that these will be fixed by the fact you are merging the two versions? Otherwise let me know and I will attempt to provide patches. Dominic. PS I may to expose a few more modules as I go along. [dom@tility HaXml]$ more Setup.hs import Distribution.Simple main = defaultMain [dom@tility HaXml]$ more HaXml.cabal name: HaXml version: 1.12 license: LGPL license-file: COPYRIGHT author: Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> homepage: http://www.cs.york.ac.uk/fp/HaXml/ category: Text synopsis: Utilities for manipulating XML documents description: Haskell utilities for parsing, filtering, transforming and generating XML documents. exposed-modules: Text.ParserCombinators.HuttonMeijerWallace, Text.ParserCombinators.Token, Text.XML.HaXml, Text.XML.HaXml.Combinators, Text.XML.HaXml.DtdToHaskell.Convert, Text.XML.HaXml.DtdToHaskell.Instance, Text.XML.HaXml.DtdToHaskell.TypeDef, Text.XML.HaXml.EntityHelpers, Text.XML.HaXml.Escape, Text.XML.HaXml.ExtEntity, Text.XML.HaXml.Haskell2Xml, Text.XML.HaXml.Html.Generate, Text.XML.HaXml.Html.Parse, Text.XML.HaXml.Html.Pretty, Text.XML.HaXml.Lex, Text.XML.HaXml.OneOfN, Text.XML.HaXml.Parse, Text.XML.HaXml.Pretty, Text.XML.HaXml.QName, Text.XML.HaXml.SubstitutePE, Text.XML.HaXml.Types, Text.XML.HaXml.Unicode, Text.XML.HaXml.Validate, Text.XML.HaXml.Verbatim, Text.XML.HaXml.Wrappers, Text.XML.HaXml.Xml2Haskell, Text.XML.HaXml.XParserUtils, Text.XML.HaXml.Xtract.Combinators, Text.XML.HaXml.Xtract.Lex, Text.XML.HaXml.Xtract.Parse hs-source-dirs: obj/ghc build-depends: base, haskell98, mtl, HTTP extensions: CPP ghc-options: -fglasgow-exts

1 0

RE: cabal design
by Simon Marlow 16 Sep '05

16 Sep '05

Ok, I've read through this discussion. Could somebody explain to me why this whole "virtualization" thing can't be solved by simply adding the flag --package-db=<file> to Cabal? It would be another option in the --user/--global family. The idea isn't new - I'm sure we've discussed this before. It seems to suffer from none of the problems of the other suggestions, but perhaps I'm missing something. For Hugs, the <file> would actually specify a directory. Additionally, --package-db=<file> is a step on the way to other things that we want to do (--in-place). It seems to me that the requirement is basically this: - To be able to install packages in a group, such that all packages in the group are registered in a single, separate, package database. the fact that in the proposed use cases the packages are also installed under a pseudo-root is a red herring as far as Cabal is concerned. We don't care where you install your packages or what files they contain. So the question becomes how to specify which "package group" a package should be registered in. I propose the simplest thing: tell Cabal the location of a package database. The other proposals (--prefix and --root) require Cabal to magically derive the location of the package database from the "root" directory, but that's magic that we don't need/want IMO. I'm happy to add support for GHC_PACKAGE_PATH, as requested in this discussion. Cheers, Simon

4 3

AVL library update
by Adrian Hey 15 Sep '05

15 Sep '05

Hello, I've put a new version 2.3 of Data.Tree.AVL here.. http://homepages.nildram.co.uk/~ahey/HLibs/Data.Tree.AVL/ Changes in this version include.. * Added genPush' and genPushMaybe' functions which provide strictness control which was missing from earlier versions. * Added symmetric difference to the set functions * I decided to use the prefix "assert" for partial function names. So there has been a bit of renaming (old names are still OK but deprecated, and I might have missed a few :-) Regards -- Adrian Hey

1 1

RE: cabal packaging and --libdir
by Simon Marlow 13 Sep '05

13 Sep '05

On 13 September 2005 10:52, Jens Petersen wrote: > I think a --libdir option is needed in Cabal to help packagers > that need to specific where libraries are installed. > > For example Fedora Core x86_64 (amd64) arch 64bit libs should be > installed under $prefix/lib64, whereas cabal assumes $prefix/lib. > > Could a --libdir please be added or is there another way? I had a proposal for this recently, but it hasn't been implemented yet: http://www.haskell.org//pipermail/libraries/2005-August/004232.html (there are earlier and later messages in that thread). Cheers, Simon

1 0

cabal packaging and --libdir
by Jens Petersen 13 Sep '05

13 Sep '05

I think a --libdir option is needed in Cabal to help packagers that need to specific where libraries are installed. For example Fedora Core x86_64 (amd64) arch 64bit libs should be installed under $prefix/lib64, whereas cabal assumes $prefix/lib. Could a --libdir please be added or is there another way? Jens -- Fedora Haskell packages http://haskell.org/fedora

1 0