- Libraries - Haskell.org

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 28 Apr '05

28 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 28 Apr '05

28 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 28 Apr '05

28 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

Bug in Network.CGI
by Philippa Cowderoy 26 Apr '05

26 Apr '05

Network.CGI doesn't decode CRLFs in form data into \n. As it does text mode IO, this can lead to all sorts of fun with newlines doubling up on the browser end. -- flippa(a)flippac.org The task of the academic is not to scale great intellectual mountains, but to flatten them.

1 0

RE: Environment variable does not work (especially DARCS_EDITOR)
by Simon Marlow 26 Apr '05

26 Apr '05

On 26 April 2005 02:15, Benedikt Schmidt wrote: > Sorry for taking so long to reply. > > On Tue, 2005-04-19 at 11:36 +0100, Simon Marlow wrote: >> On 16 April 2005 20:41, Benedikt Schmidt wrote: >>> module Main where >>> import System.Cmd >>> main = rawSystem "nvi" [] > [ patch calling resetNonBlockingFD in runProcess ] >> If we did this, we would also need to re-enable non-blocking mode >> after the rawSystem completes. Also, this doesn't work well if >> runProcess is used and the Haskell program continues to run while >> the subprocess is executing, because the O_NONBLOCK flag is shared >> between parent and child. > > I didn't think about the flags beeing shared between parent and child. > > I tried using setFdOption first, but didn't see that rawSystem sets > stdin back to blocking mode when stdin is evaluated. > > This works for me now with ghc-6.4: > main = do stdin `seq` return () > bracket (setFdOption stdInput NonBlockingRead False) > (\_ -> setFdOption stdInput NonBlockingRead True) > (\_ -> rawSystem "nvi" []) > > >> So I suggest doing this for System.Cmd.{system,rawSystem} only. > > Would something like that be safe for system and rawSystem if all > arguments where forced before the setFdOption? If there are > several threads? You're right, it's not safe in general. Better to leave it up to the user - your fix is fine. I'll put an entry in the FAQ. Cheers, Simon

1 0

Cabal is a layer on Haskell
by Simon Marlow 26 Apr '05

26 Apr '05

On 26 April 2005 04:55, S. Alexander Jacobson wrote: > On Mon, 25 Apr 2005, John Meacham wrote: >> You can compare Cabal's way of doing things to what specific >> compilers have done, but not 'Haskell' because 'Haskell' doesn't >> concern itself with these issues. This is correct. > Yeah Simon Marlow corrected me on this one too. No I didn't :-p > Cabal should be thought of Cabal is part of the Haskell source not its > implementation: > > Me: My fundamental point here is that the meaning of code shouldn't > change depending on the location where it is interpreted. [...] > Concretely, the meaning of "import Data.List" in a > haskell module shouldn't depend on whether the module is on my > computer or yours. > > Simon: You can think of .cabal as part of the source if that helps. > It really is part of the source - but implemented and specified as > a layer on top of existing language and compiler technology, for > convenience and so that we can share the tools. You misinterpreted me. I'm simply saying that .cabal is part of the source of a Cabal package, not part of the Haskell source. Of course, since Cabal doesn't change the definition of Haskell. I'll state this clearly (again): Cabal is a layer on top of the Haskell language definition. It does not change Haskell, it is not "incompatible" with Haskell. It defines some things that are undefined in the Haskell definition. Cheers, Simon

1 0

The meaning of Cabal+Haskell
by Simon Marlow 26 Apr '05

26 Apr '05

On 26 April 2005 04:55, S. Alexander Jacobson wrote: > On Mon, 25 Apr 2005, John Meacham wrote: >> The haskell report (and hence the haskell language) specifies >> __nothing__ about how imported module names are actually mapped to >> code. This has always been left up to implementations. [...] >> This is why comparing haskell to cabal doesn't make sense, cabal is >> meerly one proposed implementation of behavior that is undefined by >> Haskell. > > That's what I thought too! But, Malcolm Wallace and Simon Marlow > corrected me a few posts back and they are the authors of the spec. > They say that, like Haskell, Cabal actually specifies __nothing__ > about how imported module names are mapped to code either. > > Me: My objection to Cabal is that it in fact DOES determine the > referent of an import statement (build-depends). > > Malcolm: I can see why you might object, if that were the case, but > Cabal does NOT in fact determine the referent! Cabal is just a > convenient way of grouping together the denotational /interface/ of > a large bunch of modules. The implementations of those modules can > be replaced at any time, provided they still meet the interface. > > Me: The Cabal spec says "build-depends: [...] a list of packages > [..] needed to build this one" > > Malcolm: "needed to build" tells me which interfaces must be > available at compile-time, no more and no less. > > Simon: Build-depends uses the source-code notion of interface, not > the object code. So, build-depends has the same meaning for all > compilers. Malcolm is pointing out that it's possible to substitute object code for a module as long as the replacement supports the same interface. The definition of "interface" in this case is compiler-dependent, so I think we should separate this observation from the discussion at hand - it's an extra complication (IMHO). You're interested in what the meaning of Cabal+Haskell is. Here's a succinct interpretation of the relationship: Haskell: "A program consists of a set of modules." Cabal+Haskell: "A program consists of a set of modules. I'm going to provide a way to construct that set of modules, by combining sets of modules called packages." Cheers, Simon

1 0