May 2005 - Libraries - Haskell.org

RE: Extending Cabal
by Simon Marlow 13 May '05

13 May '05

On 12 May 2005 15:49, Isaac Jones wrote: > I don't mind this change much, it might even be good. One thing I > like about the old way, though, is that it encourages people to use > the hierarchical namespace, which is a nice way to organize things > whether you are building a library or an executable. > > But Cabal's purpose is to help folks build tools, not to enforce style > ;) I'd accept it if you feel that you need it. Anyone else have an > opinion? It's a trivial change to make, it doesn't break anything, and it lets us support more existing projects without substantial reorganisation of their file structure. Sounds like a no-brainer to me. Cheers, Simon

4 5

WARNING: package dependencies
by Simon Marlow 12 May '05

12 May '05

Yes, the module overlap restriction has started to bite us. It now turns out that you can't build GHC from CVS if you have wxHaskell installed. Why? Because wxHaskell depends on some older non-hierarchical packages (util in particular, which itself depends on lang). These package populate the top-level module namespace, and steal a bunch of module names that you might want to use in your program. In fact, GHC itself contains a module with the same name as one in the lang package: Generics. The error is real - if we *had* imported something from wxHaskell, then the program would contain two modules called Generics, and since the linker's name space is global, mayhem would ensue. Because we're doing separate compilation, GHC can't tell that we haven't actually imported anything from wxHaskell, so it has to be conservative and assume that we will. New GHCs are a bit stricter about complaining about duplicate modules, with the result that GHC fails to build. We know the reasons for this - they were all discussed at length in a recent thread. What can we do? 1. Package builders should be careful about dependencies. Don't depend on any non-hierarchical packages from an exposed package. Daan - can you fix wxHaskell? 2. The GHC build could start using -fignore-all-packages to insulate itself from the environment (or, simpler but more hacky: -ignore-package lang). This isn't a *solution* as such, because the problem affects everyone, not just us. 3. We could put some safeguards in place to avoid this happening in the future, e.g. warnings from Cabal and/or ghc-pkg. 4. Cabal needs to start using -fignore-all-packages. Isaac? Thoughts? Cheers, Simon

8 8

producing nice tarballs
by Duncan Coutts 11 May '05

11 May '05

Hi all, With my Gentoo Haskell packaging hat on I'd like to grumble slightly :-) There are a number of packages floating around that have various things 'odd' about them. It makes the lives of packaging people much easier if tarballs follow a standard convention. I suggest that the convention should be the same as what autoconf/automake does in the C world (because this is what packaging people are used to and what packaging tools work best with) So if you've got a cabal package with fields: name: FooBar version: 1.2.3 Then the tarball should be "FooBar-1.2.3.tar.gz" (or .zip or .tar.bz2). And that archive should unpack to "FooBar-1.2.3/". There are packages around where the cabal package name is all lower case but the tarball name is all upper case or mixed. Similarly there are packages which unpack to just the package name rather name & version. There are also packages with non-canonical version numbers, eg 5.01 gets normalised to 5.1. Cabal identifies these two version numbers but it's not clear that package authors are aware of this. I know these seem like trivial issues but consistency makes things much easier for (semi-)automatic tools. With the rise of cabal, I think this is a great opportunity to have tools that make it easy for package authors to "do the right thing". For example, the C coders who use automake get package tarball preperation for free. Indeed automake does some quite sophisiticated checks to make sure that a source tarball is complete and consitent (it unpacks the tarball, builds the package and uses it to produce another tarbal which it compares to the original). We (Gentoo packaging folk) are quite eager for cabal's "./setup sdist" feature to be fixed/improved (apparently there are some issues with it currently) so that package authors can be encouraged to use it and produce consistent tarballs that will make packaging that bit smoother. If it's not so high on everyone else's priority list we'll send patches! :-) Duncan

2 2

ANN: HaXml-1.13
by Malcolm Wallace 11 May '05

11 May '05

HaXml-1.13 ---------- http://haskell.org/HaXml/ Announcing a bug-fix refresh release of HaXml. Not many recent changes, but the most important ones are: * Bugfixes to the document validator: no more infinite loops. * Bugfixes to lexing mixed text and references between quote chars. * Updated to work with ghc-6.4's new package mechanism. * Fixes for building on Windows, with or without Cygwin. * Can be built with Cabal. Regards, Malcolm

1 0

RE: Request: Open Module Resolution
by Simon Marlow 11 May '05

11 May '05

On 10 May 2005 18:25, S. Alexander Jacobson wrote: > This was just a proof of concept. Transitively following imports > seems straightforward to add, you just need to be able to grab the -i > flag from the compiler command line. > > Not handling GHC extensions worries me more. Is the problem that the > Lamguage.Haskell.Parser does not handle them? That's right. > If so, where can I find the parser that does? Niklas Broberg has one, that was announced on this list a few days ago: http://www.haskell.org//pipermail/libraries/2005-April/003715.html Hopefully his work can be assimilated into the haskell-src package at some point. Cheers, Simon

1 0

RE: Request: Open Module Resolution
by Simon Marlow 10 May '05

10 May '05

On 10 May 2005 01:09, S. Alexander Jacobson wrote: > On Fri, 6 May 2005, Simon Marlow wrote: > >> Certainly. But there's no easy way to say this: I think you're >> going to have to do it yourself (or find some kind soul to do it). >> Of course we'll incorporate the changes as long as they don't break >> anything else. > > Ok, any reason the code below wouldn't work? Well, it doesn't transitively follow imports, and it doesn't handle GHC extensions. But if it works for your purposes then great - not modifying GHC is big win. Cheers, Simon

2 1

RE: WARNING: package dependencies
by Simon Marlow 10 May '05

10 May '05

On 10 May 2005 11:48, Tony Finch wrote: > On Tue, 10 May 2005, Simon Marlow wrote: >> >> 2. The GHC build could start using -fignore-all-packages to >> insulate itself from the environment (or, simpler but more >> hacky: -ignore-package lang). This isn't a *solution* as such, >> because the problem affects everyone, not just us. > > I'm slightly surprised that this isn't already the default, and that > probably explains the recent argument. In the C world the only > libraries that matter to the build environment are the ones you > explicitly pull in. Overlaps still matter but only within your > program. On the other hand Perl's module namespace is global, and a > (usually implicit) search path is used to resolve conflicts. FWIW, I tend to agree. -fhide-all-packages should be the default. (I know that others disagree, though). > I greatly prefer the former model. Perl is a real pain if you want > multiple parallel installations of slightly different versions of the > same code - you effectively need a separate Perl installation for each > installed version of a program that uses Perl. > > Perhaps the missing idea is the package configuration step, during > which its dependencies are resolved to installed libraries on the > build machine and any conflicts are dealt with. Actually this is what we're proposing to do in Cabal. Anyone using Cabal won't have to worry about these issues, but they will have to specify all package dependencies explicitly. > The package is > shipped with abstract dependencies (module names and perhaps version > numbers), but by the time the compiler gets involved these have been > resolved to paths in the file system. It's a bit higher level than that: the compiler does have an understanding of packages, but it just maps a package name to a library and a bunch of interface files. So essentially what you describe is the way it works (with Cabal, at least). Cheers, Simon

1 0

RE: WARNING: package dependencies
by Simon Marlow 10 May '05

10 May '05

On 10 May 2005 11:11, Daan Leijen wrote: > Simon Marlow wrote: > >> 1. Package builders should be careful about dependencies. Don't >> depend on any non-hierarchical packages from an exposed package. >> Daan - can you fix wxHaskell? >> >> > Yes, I probably can -- I guess it is time to move forward and forget > about compatability with older ghc's (< 6.2.2) > > However, I don't really understand what is wrong and what to fix :-) > (should I remove -package util and qualify explicitly in the code?) > > I can probably figure it out from the docs but maybe it would help > if someone could add some "simple guidelines for package writers" > documentation that would tell concretely what is good practice > (and what is bad practice). Depending on any hslibs package is bad practice. Ok? :-) Cheers, Simon

2 1

System.IO.openTempFile secure?
by Isaac Jones 10 May '05

10 May '05

Is the function System.IO.openTempFile secure in the sense that it picks the filename, tests for its existence, and creates it atomically? Either way, it's important that it's documented in Haddock, IMO. peace, isaac

3 2

RE: Request: Open Module Resolution
by Simon Marlow 09 May '05

09 May '05

On 05 May 2005 17:38, S. Alexander Jacobson wrote: > On Wed, 4 May 2005, Simon Marlow wrote: > >> Instead, let me point you at the place in GHC to insert your >> resolver. In the module Finder, we have: >> >> findModule :: HscEnv -> Module -> Bool -> IO FindResult > > Oh, this is great! Then let me be more precise in my request: > > I am looking for a way for the user to provide a function to handle > NotFound results. I want the user to be able to supply a function > that wraps findModule (with the exact same type signature). > >> You can almost replace findModule with your own resolver. However, >> the question is what do you do for modules like "Prelude": it sounds >> like you'll need to have pre-compiled code for all the standard >> libraries around (I assume you want to avoid using packages). > > So the wrapper function can let the default findModule function > operate and only handle the case where findModule returns NotFound. > > The key point here is I'd like a way to do this that doesn't requiring > recompiling GHC every time you change the wrapper function. > > And I'd like the ability to reuse these user findModule functions > with multiple Haskell compilers. > > Is this possible? Certainly. But there's no easy way to say this: I think you're going to have to do it yourself (or find some kind soul to do it). Of course we'll incorporate the changes as long as they don't break anything else. Cheers, Simon

2 1