April 2005 - Libraries

Trie implementation
by Keith Wansbrough 11 Mar '06

11 Mar '06

Hi... I was writing some code yesterday to walk over a directory tree, and needed a Trie. Not seeing one around, I wrote a basic implementation of the functions I needed (attached below). Has anyone else done this? Should I polish it up and offer it for inclusion in Data? --KW 8-)

7 8

Cabal and c2hs
by Dominic Steinitz 06 May '05

06 May '05

I am trying to migrate some old code to cabal. It uses c2hs. Now I wasn't sure I had c2hs installed so I ran cabal anyway. 1. Why isn't configure telling me where c2hs is? It tells me where hsc2hs is! 2. Why is cabal telling me it can't find a source when the source is present? Thanks, Dominic. Here's ping.cabal: Name: Ping Version: 0.0 License: BSD3 Author: Dominic Steinitz Synopsis: The Haskell equivalent of ping Executable: ping Main-Is: test.hs Other-modules: IP_ICMP.chs When I run ./Setup configure, I didn't see any message saying whether c2hs was installed and when I run ./Setup build I get the following: [dom@tility ping]$ ./Setup build Preprocessing executables for Ping-0.0... can't find source for IP_ICMP.chs in ["."] But the source is there: [dom@tility ping]$ ls codes.hs dist/ ip_icmp.h ping.cabal Setup* Setup.hs test.hs CVS/ IP_ICMP.chs Makefile ping.cabal~ Setup.hi Setup.o

4 10

NewBinary Library
by Peter Simons 06 May '05

06 May '05

Hi, the NewBinary library used to be available via Darcs at this place: http://www.n-heptane.com/nhlabca/repos/NewBinary It appears, though, that this repository has vanished. Does anyone know what happened? Is anyone aware of the new home of the library? Peter

2 1

Who maintains haskell-src?
by Niklas Broberg 03 May '05

03 May '05

The reason I ask is my haskell-src-exts (http://www.cs.chalmers.se/~d00nibro/haskell-src-exts) library that extends the haskell-src modules with support for syntactic extensions. I believe this functionality is something that most users of haskell-src are interested in, so perhaps it might be a good idea to actually add my extensions to the standard package. It won't be this very minute since there are some issues, but if I get a clearance I'll make an effort to work them out. /Niklas

3 3

package license fields
by Daan Leijen 03 May '05

03 May '05

Dear Cabal design team, I see that the license field in the package descriptions must be one of the following values: GPL, LGPL, BSD3, BSD4, PublicDomain, AllrightReserved or OtherLicense. Can (should?) we add the "WxWidgets" license? (essentially L-GPL but allows commercial use). -- Daan

2 3

Bug in Cabal creating user package.conf
by Ashley Yakeley 30 Apr '05

30 Apr '05

I don't know if this has already been mentioned, but there's a bug in Cabal which I noticed when I tried to configure a package: $ runghc Setup.hs configure ... configure: Reading installed packages... cannot parse package list It turns out Setup created a user package.conf consisting of the two characters "[]" without a newline, which it was then unable to parse. Adding a newline fixed the problem. -- Ashley Yakeley, Seattle WA

2 2

RE: Cabal vs Haskell [sic]
by Simon Marlow 29 Apr '05

29 Apr '05

On 23 April 2005 00:21, ross(a)soi.city.ac.uk wrote: > On Fri, Apr 22, 2005 at 11:28:21PM +0100, Simon Peyton-Jones wrote: >> And this observation points towards a simpler solution: rather than >> invisibly pre-pend the package name, just get the programmer to do >> so. So package P exposes a module called P.M and package Q exposes >> Q.M. All P's internal modules are called P.something, and similarly >> for Q. (We rely on some social mechanism for allocating new package >> names, as now.) Now of course you can import P.M and Q.M in a single >> module. > > This would obscure the hierarchy a bit. A common current practice is > a variant of this: modules either have allocated names or their names > have the form > > allocated prefix + proper name + whatever you like > > e.g. Graphics.Rendering.OpenGL.GL.Texturing.Queries -- it seems to > work pretty well, and should scale, as long as the proper names are > distinct, e.g. package names or otherwise allocated. Right. Also, prepending package names to module names to avoid the overlap restriction suffers from another difficulty: versioning. You can't combine two versions of a package without including the version number in the module names of all the modules in the package. But then you end up with source code that has to be edited when the version of a package changes, which is highly undesirable. IMO, it's a good thing that package names and versions are separate from module names. It means we can (mostly) stick to the original aim of using the module hierarchy to reflect functionality, and not clutter it up with version numbers and other administravia. Cheers, Simon

8 14

RE: Help! no environment variable expansion in package files ?!?
by Simon Marlow 29 Apr '05

29 Apr '05

On 28 April 2005 15:24, Daan Leijen wrote: >> I suggest you use CPP ('gcc -E -undef -traditional -P' or 'cpphs'). >> This is what we use in GHC to get values into the package.conf files. >> e.g. in a Makefile you would write something like: >> >> > This does not work for me. For the *binary* installer for windows, > I use a batch file (.bat). The user unzips the binary files (.hi & .o) > in some location and runs "register.bat" which calls ghc-pkg with > the .pkg files. This batch file sets the current directory (= the > install directory) as an environment variable that used to be expanded > in the .pkg files. Now, I need to generate those .pkg files inside > the .bat file which seems a lot of extra work, if it works at all.. Ah, I see. I'll look into re-enabling this feature in 6.4.1. For the time being, maybe write a little Haskell program to transform .pkg files? > Another thing that causes me trouble is that I seem to need to > list all exposed modules explicitly. For me, this means that I > need to put those modules into the configure script which makes > everything much more fragile. Is there a way to use a wildcard, > ie. saying "expose everything in here"? Sorry, no. I started to implement something like that, but it turned out to be a lot harder than I thought (can't remember why, exactly). Cheers, Simon

2 1

RE: Help! no environment variable expansion in package files ?!?
by Simon Marlow 29 Apr '05

29 Apr '05

On 28 April 2005 14:37, Daan Leijen wrote: > I am trying to prepare a new release of wxHaskell based > on ghc 6.4 but I am in despair. It seems that the new > package descriptions do no longer allow environment > variables in there. For example: > > import-dirs:${wxhlibdir}/imports > > I would like the ${wxhlibdir} to be replaced by the > value in the environment. This feature is absolutely > *essential* to get the windows installer working. > I use a batch file that gets the current directory > and puts that in the environment before call ghc-pkg. > > On unix, I can use sed to make it work, but this does > not hold for windows. What can I do to allow the user > to install wxhaskell at arbitrary places using just a > batch file? (ie. we can not assume that cygwin is available) > I can hardly believe if no one has thought of this before, > so I hope it is just a syntax issue. I didn't port the feature to the new version of ghc-pkg. Sorry about that, the reasons were that (a) there are other ways to do it, and (b) the other ways are in general better, because you can substitute multiple values for a variable. I suggest you use CPP ('gcc -E -undef -traditional -P' or 'cpphs'). This is what we use in GHC to get values into the package.conf files. e.g. in a Makefile you would write something like: package.conf : package.conf.in gcc -E -undef -traditional -P -x c $< >$@ \ -DWXHLIBDIR='"$(wxhlibdir)"' (untested; I copied this mostly from GHC's build system). Another option, if you use autoconf, is to process the file using the configure script. Cheers, Simon

2 1

Help! no environment variable expansion in package files ?!?
by Daan Leijen 28 Apr '05

28 Apr '05

Hi all, I am trying to prepare a new release of wxHaskell based on ghc 6.4 but I am in despair. It seems that the new package descriptions do no longer allow environment variables in there. For example: import-dirs:${wxhlibdir}/imports I would like the ${wxhlibdir} to be replaced by the value in the environment. This feature is absolutely *essential* to get the windows installer working. I use a batch file that gets the current directory and puts that in the environment before call ghc-pkg. On unix, I can use sed to make it work, but this does not hold for windows. What can I do to allow the user to install wxhaskell at arbitrary places using just a batch file? (ie. we can not assume that cygwin is available) I can hardly believe if no one has thought of this before, so I hope it is just a syntax issue. All the best, -- Daan. ps. If someone knows a solution, please tell me soon as this is my last day the university and thus my last opportunity to build a wxHaskell release on multiple platforms.

1 0