July 2005 - Libraries

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

25 Jul '05

[moving to libraries] On Sun, Jul 24, 2005 at 02:32:27AM -0400, Dimitry Golubovsky wrote: > I am trying to use Cabal for buiding HSFFIG as a package. Among other > files to install I have the special template for hsc2hs which is a C > include file. If I specify it in the Includes: clause nothing happens: > it is not copied anywhere during installation. > > I need this file to be placed somewhere in the package instalation > location, so when programs are compiled with my package could include > that file. > > Of course I may specify additional step in the Makefile, but it would be > more consistent to do this in Cabal. > > How can arbitrary files be declared parts of a package, and destination > directories for them be specified? There are several programs like this (e.g. hsc2hs, happy), but specifying destination directories would be non-portable. 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})

1 0

WashNGo Won't Build
by Dominic Steinitz 24 Jul '05

24 Jul '05

I've just downloaded and tried to build WashNGo but I'm getting the errors below. Any help would be appreciated. Thanks, Dominic. make[2]: Entering directory `/home/dom/WashNGo-2.4.6/Mail' /usr//bin/ghc -M -optdep-exclude-directory=../Utility -package-name WASHMail -package text -i../Utility ContentDisposition.hs Email.hs EmailConfig.hs HeaderField.hs MIME.hs MailParser.hs Message.hs RFC2822.hs Could not find module `Unique': it is a member of package util-1.0, which is hidden (imported from Email.hs) make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/dom/WashNGo-2.4.6/Mail' make[2]: Entering directory `/home/dom/WashNGo-2.4.6/cgi' /usr//bin/ghc -M -package-name WASH-CGI -package text -i../Utility:../Mail:../WASH -optdep-exclude-directory=../WASH -optdep-exclude-directory=../Mail -optdep-exclude-directory=../Utility AbstractSelector.hs CGI.hs CGIConfig.hs CGIGraphics.hs CGIInternals.hs CGIMonad.hs CGIOutput.hs CGITypes.hs CGIXX.hs ContentType.hs Cookie.hs CookieIO.hs Debug.hs EventHandlers.hs Fields.hs Frames.hs GuaranteedCGI.hs HTMLMail.hs HTMLWrapper.hs Images.hs PPM.hs Persistent2.hs RawCGITypes.hs RawCGI.hs RawCGIInternal.hs StateItem.hs Style.hs Submit98.hs SubmitXX.hs Types.hs Could not find module `Unique': it is a member of package util-1.0, which is hidden (imported from CGIGraphics.hs) make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/dom/WashNGo-2.4.6/cgi' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/dom/WashNGo-2.4.6' make: *** [depend] Error 2

3 2

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

21 Jul '05

I haven't had time to think about the other points in your message yet, but wanted to comment on this one: On 21 July 2005 06:32, Brian Smith wrote: > (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 Absolutely - this thought also crossed my mind recently. We should agree on a convention. __PACKAGE_<name>__ seems reasonable, but what about the version number? We could adopt the same policy as __GLASGOW_HASKELL__, namely major*100+minor, and discard any futher dimensions in the version number (e.g. 1.1.1 and 1.1.2 both get __PACKAGE_foo__==101). This perhaps isn't as intuitive as it could be: people tend to write 110 when they want 101. So is there an alternate/better scheme? Cheers, Simon

3 3

RE: cabal permissions problems
by Simon Marlow 20 Jul '05

20 Jul '05

On 25 June 2005 23:47, Frederik Eaton wrote: > I think I remember running into something like this a long time ago > and mentioning it to someone, is it fixed in a new version of Cabal? > I'm using ghc 6.4... > > The problem is that executable files are installed to be only > executable by user: > > $ ls -al built/bin/ > total 3644 > drwxrwxr-x 2 frederik frederik 4096 2005-06-25 15:35 . > drwxrwxr-x 3 frederik frederik 4096 2005-06-24 19:57 .. > -rwxrw-r-- 1 frederik frederik 1183668 2005-06-25 15:40 fcq > -rwxrw-r-- 1 frederik frederik 2528637 2005-06-25 15:40 fcq-www.cgi > $ umask > 002 > > I haven't experienced this with any other installation procedures, > only Cabal. This is a problem with GHC's System.Directory.copyFile, which arises because getPermissions f1 >>= setPermissions f2 doesn't copy the full permissions on Unix. I've fixed copyFile. Cheers, Simon

1 0

RFC: Time Library 0.1
by Ashley Yakeley 19 Jul '05

19 Jul '05

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

9 22

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

18 Jul '05

On 18 July 2005 05:55, Isaac Jones wrote: > Brian Smith <brianlsmith(a)gmail.com> writes: >> In particular, can we just skip support for GHC 6.4? The >> installation instructions for GHC 6.4 are workable, but it looks >> like the GHC 6.4.1 experience will be much better. Plus, I think >> that the package management changes between GHC 6.4.0 and 6.4.1 will >> cause problems for people packaging their stuff using Cabal. So, >> could we just say that Cabal 1.2 requires GHC 6.2.2 or GHC 6.4.1 or >> later? > > I do indeed think that the next version of GHC will be better for > installing packages, but I don't think we should give up on 6.4. > OTOH, I don't think that it's a huge deal to just document the > difficulties. It's really no harder than removing the old Cabal > before installing the new one. Maybe we should just force everyone to > do that, or make that the default behavior for "make install". > That'll probably offend some folks' sensibilities. What do folks here > think? It's a tough one. Skipping 6.4 is somewhat attractive, because there are some serious problems with upgrading Cabal on GHC 6.4. However, if we put appropriate warnings into the Cabal README and describe what the problems are, I think that's enough. I also need to check whether GHC can still be built if Cabal has been upgraded. >> * It should be possible for Windows users to build Cabal 1.1.1 on >> both GHC 6.2.2 and GHC 6.4.1 without having GNU make installed. This >> process needs to be documented. I will wait to send you the docs >> until I find out if GHC 6.4(.0) will be supported in Cabal 1.2. > > Yes, I would like to support it. The only extra steps are those in > the "make setup" command, which is just a couple of extra flags to GHC > for bootstrapping. A batch file / shell script would actually work > just as well. The GNUMakefile is really just a glorified shell script. With 6.4+, I hope you can use "runghc Setup.lhs". With 6.2.2, typing some GHC commands manually is probably required (perhaps we could include a .bat file?). Cheers, Simon

1 0

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